users,您好!
I try to build a server with tls support by openser.I want to know how to know openser is with tls support.
I modify the config file followed TLS help file.and openser is started well,but how I know it's work right?
and my client is minisip,but always send error messenges to me "exception caught when creating tls server",why?
I did all the things ,but ....
Who can help me,or give me a example.
致
礼!
Kenny Yeh
上海金叶通讯科技有限公司
TEL:8621-6421-6758 ext.311
kenny(a)artdio.com.tw
2006-01-04
users,hello
Happly new year!
My problem:
1.I start openser with TLS support,follow the TLS help file,create a ca/demoCA/ and create cert.pem,private.pem,key.pem.openser is start well,but I cann't list the listen ports by openserctl ps,how I can be sure openser is started by TLS support?
2.My client is minisip phone that TLS support.but when I start minisip to registar,the error messenge is "exception caught when creating TLS server",I donn't know what's happend.
Please help me !
致
礼!
Kenny Yeh
上海金叶通讯科技有限公司
TEL:8621-6421-6758 ext.311
kenny(a)artdio.com.tw
2006-01-04
Hi,
probably a stupid question, but how to write the auth username passed on
authentication to an AVP?? I tried to access $ua pseudo variable in openser
to get it in to the AVP but it failed, obviously.As the docs says the pseudo
variables are accessible only for avp_print function.
Any help?
Thanks,
Bye,
Marcello
Hello,
First of all, Happy new year to all the readers of this mailing list !
I have a slightly strange issue with my openser installation. I am using a
mySQL database to store the users of my SIP server. I am trying to start the
server while the database is on a distant server. The logs are returning
this error, and I can't undrestand what went wrong :
0(0) AUTH module - initializing
0(0) AUTH_DB module - initializing
0(0) usrloc:preload_udomain: Wrong version v136410800 for table <aliases>,
expected v1001
0(0) register_udomain(): Error while preloading domain 'aliases'
0(0) domain_fixup(): Error while registering domain
ERROR: error -1 while trying to fix configuration
Do you have any clue ?
Antoine
Hi
I know this is off topic, but am sure lots of VoIP companies face this,
whats the best strategy to counter this, aside from Visa secure and
similar systems. On alarger scale have most just written off the charges
and costs incurred, or are there semi-elaborate ways of reducing the
risk. I address verification all seems a non-starter unless you wish to
block out entire ranges.
Any thoughts pointers would be great
Iqbal
Hello,
Attached is a patch that implements "swap_direction" parameter of acc
module. If you turn the parameter on in the configuration file:
modparam("acc", "swap_direction", 1)
then the acc module will swap Calling-Station-ID and Called-Station-ID
values when necessary (in this case BYE comming from the callee).
Put the patch in top level source directory (ser-0.9.x) and type:
patch -p0 < swap.patch
The patch should work with any 0.9.x release.
Note that Alan DeKok is wrong in thinking that this is a bug in SER.
This particular problem is a result of incomplete specification of
RADIUS use with SIP. I will commit the patch in CVS so it will be
included in future SER releases.
Jan.
On 23-12-2005 17:10, Lenir wrote:
> Please read the reply below from one of the maintainers of freeradius:
>
> "Lenir" <lenirsantiago(a)yahoo.com> wrote:
> > But if UserB hangs up on UserA: SER generates a stop-record where the
> > Calling-Station-Id is UserB and the Called-Station-Id is UserA, this
> > is the undesired and incorrect behavior.
>
> It would appear to be a bug in SER.
>
> > To me the Calling-Station-Id and the Called-Station-Id should be the
> > same for both start and stop records, am I right by thinking that?
>
> Yes.
>
> > According to the developers of SER/OpenSER, this is the correct
> > behavior, whoever sends the hangup signal (BYE or CANCEL) is
> > considered the Calling-Station-Id, and they are unwilling to modify or
> > create a patch to "fix" this.
>
> What they do for something inside of SER is their business. When they
> generate RADIUS packets, they should follow RADIUS standards and
> interoperability. The expectation, as you said, is that the
> Calling/Called-Station-Id doesn't change during a session. If it does, it's
> a bug and they should fix it.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
>
>
> -----Original Message-----
> From: 'Jan Janak' [mailto:jan@iptel.org]
> Sent: Thursday, November 17, 2005 10:33 AM
> To: Lenir
> Cc: 'Klaus Darilion'; serdev(a)iptel.org; serusers(a)iptel.org;
> devel(a)openser.org; users(a)openser.org
> Subject: Re: [Users] RE: [Serusers] Re: [Serdev] Inaccurate Radius
> Accounting
>
> On 17-11-2005 10:21, Lenir wrote:
> > In this case the radius proxy wont work, because you never can anticipate
> > who hangs up the call, thus radius wont know who hung up the
> call...Besides
> > all other voice applications/hardware (SIP and H323) that use radius do
> not
> > behave like that, the Called-Station-ID ALWAYS remains the same, as with
> the
> > Calling-Station-ID.
>
> Could you name those SIP applications that behave the way you describe ?
>
> Jan.
>
All,
We have had a new issue arise within openser, basically we
connect to a SIP carrier that uses Asterisk as a proxy. Naturally, this
carrier is hellbent on offloading the RTP traffic, thus the reinvites.
My issue is that they appear to be sending the second invite "too fast",
before the initial RTP even gets a chance to establish. This was working
just fine before, and I believe they changed something. Anyway, they're
refusing to help with this issue, so now I must "fix" it on my end.
OpenSER is in-part, the problem.. See below:
(Sorry if formatting is off, dump from tethereal ..)
0.000000 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:8886963856@206.80.70.47, with session description
0.001752 206.80.70.47 -> 204.13.233.13 SIP Status: 100 trying -- your
call is important to us
0.002723 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@sip.stl.netlogic.net, with session description
0.010327 206.80.70.54 -> 206.80.70.47 SIP Status: 100 Trying
0.292175 206.80.70.54 -> 206.80.70.47 SIP Status: 180 Ringing
0.292692 206.80.70.47 -> 204.13.233.13 SIP Status: 180 Ringing
2.016246 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.016893 206.80.70.47 -> 204.13.233.13 SIP/SDP Status: 200 OK, with
session description
2.050871 204.13.233.13 -> 206.80.70.47 SIP Request: ACK
sip:+1314xxxxxxx@206.80.70.54
2.051233 204.13.233.13 -> 206.80.70.47 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54 2.051827 206.80.70.47 -> 204.13.233.13
SIP Status: 100 trying
--<<KABOOM>>--
2.051956 206.80.70.47 -> 206.80.70.54 SIP/SDP Request: INVITE
sip:+1314xxxxxxx@206.80.70.54,
2.052112 206.80.70.47 -> 206.80.70.54 SIP Request: ACK
sip:+13142664000@206.80.70.54
2.053028 206.80.70.54 -> 206.80.70.47 SIP/SDP Status: 200 OK, with
session description
2.053336 206.80.70.54 -> 206.80.70.47 SIP Status: 503 Server error
Where you see "kaboom", is the problem. If you notice, the time between
the first ACK and second INVITE is about 1ms .. While this shouldn't be
a problem, you'll notice when the ACK/INVITES are getting statefully
forwarded, they're getting sent out of order. The end point is an
Asterisk machine, thus the 503 error.
Carrier_Ast --> OpenSER --> Netlogic_Ast
I am using loose_route to forward, just like everyone else, they are
even hitting loose_route in the correct order.. Thoughts? Suggestions?
This seems like something internal to OpenSER, I have tried butchering
the config to force the ACK out first and it just created more problems.
Thanks!
Matt S
hi all,
I am doing all my accounting and authorization in radius. I wanted to ask if there is a way of authenticating src_ips through radius like using the allow_trusted function from mysql. pls suggest me a way of authenticating src_ips via radius.
I also wanted multidomain support, but the domain module also depends on a database module. My idea was to do everything using radius.
Can someone help me in this regard. Any suggestions would help me a lot.
thanx in advance.
jayesh
Send instant messages to your online friends http://in.messenger.yahoo.com