Re: [OpenSIPS-Users] INVITE not forwarded, call fails
On 22/01/10 18:55, Bogdan-Andrei Iancu wrote: > Hi Lorenzo, > > rport stuff applies to VIA port and it used only for sending back the > replies (to a request). > > Your problem is the the Contact URI (the bogus port) which has nothing > to do with rport. perfect, thanks for clarifying this! but if the problem is a wrong port in the Contact uri, can't $source_uri fix the issue? (or fix_contact() maybe) do they update/write to the user location database? i've been experimenting with both, in the main route, but they don't seem to work, i.e. the ul always shows the wrong contact port.. > Regards, > Bogdan thanks, Lorenzo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] INVITE not forwarded, call fails
On 22/01/10 18:55, Bogdan-Andrei Iancu wrote: > Hi Lorenzo, > > rport stuff applies to VIA port and it used only for sending back the > replies (to a request). > > Your problem is the the Contact URI (the bogus port) which has nothing > to do with rport. perfect, thanks for clarifying this! but if the problem is a wrong port in the Contact uri, can't $source_uri fix the issue? (or fix_contact() maybe) do they update/write to the user location database? i've been experimenting with both, in the main route, but they don't seem to work, i.e. the ul always shows the wrong contact port.. > Regards, > Bogdan thanks, Lorenzo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Private IP in registered AOR causing failure
Hi Brian, So you have problems with a SUBSCRIBE that is internally generated by one of the presence modules? It is not a proxied request, right ? Regards, Bogdan opensipsl...@encambio.com wrote: > Hello list, > > An jeu., janv 21, 2010, opensipsl...@encambio.com schrieb: > >> An mer., janv 20, 2010, Bogdan-Andrei Iancu schrieb: >> >>> opensipsl...@encambio.com wrote: >>> Here's a record I see when I run 'opensipsctl ul show': AOR:: mylogin-osips Contact:: sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm Q=1 Expires:: 560 Callid:: 2b21cdfae784-av13rj1txbsq Cseq:: 2 User-agent:: Bigphone123 Received:: sip:85.182.68.45:2240;transport=TLS State:: CS_SYNC Flags:: 0 Cflag:: 64 Socket:: tls:80.200.123.45:5061 Methods:: 7999 OpenSIPS is trying to reach the private IP number above from time to time, and I see this in the logs: Jan 19 17:57:20 name.host.tld opensips[23432]: ERROR:tm:t_uac: attempt to send to 'sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm' failed >>> the problem is not the private IP in the contact, as opensips >>> properly saved the source IP (of the REGISTER) too -> see the >>> Received field. So the Received field will be used over the Contact >>> for sending the requests to UAC. >>> >>> Now, what probably goes wrong in your case is that when using >>> TLS/TCP (connection oriented protos), after the REGISTER, the >>> connection is dropped and opensips cannot open later a TCP >>> connection behind a NAT :(By default opensips closes the >>> inactive TCP connections. >>> >>> >> After running a socket listener on 192.168.0.31 on the OpenSIPS host: >> >>$ socat TCP4-LISTEN:2310,bind=192.168.0.31,reuseaddr - >>SUBSCRIBE sip:mylogin-os...@192.168.0.31:2310;transport=tls;line=2acy67zm >> SIP/2.0 >>Via: SIP/2.0/TCP 86.90.39.44;branch=G4z9hb82dK8.f144.0 >>To: ;tag=ty6sjh9iz9 >>From: ;tag=6c9d4319c74d756e6b696-baa1 >>CSeq: 11 SUBSCRIBE >>Call-ID: b1c04118-8...@86.90.39.44 >>Content-Length: 0 >>User-Agent: OpenSIPS (1.6.1-tls) >>Max-Forwards: 70 >>Event: dialog;sla >>Contact: >>Expires: 610 >> >> I'm trying to implement presence by using the presence, >> presence_xml, pua, and pua_bla modules. >> >> So it seems that one of these modules (see event dialog;sla) is >> getting the contact from the locations table (in AAA on our server) >> and ignoring the Received header. >> >> OpenSIPS replies to messages from UACs such as INVITE and CANCEL >> properly, and opens connections to the IP in Received. This problem >> is limited to the SUBSCRIBES sent from one of the presence modules. >> >> > ...and similar SUBSCRIBE messages (sent from one of the presence > modules) are not having this problem. They are almost the same as > the one above, but simply don't have a to tag. > > Greetings, > Brian > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] INVITE not forwarded, call fails
Hi Lorenzo, rport stuff applies to VIA port and it used only for sending back the replies (to a request). Your problem is the the Contact URI (the bogus port) which has nothing to do with rport. Regards, Bogdan lorenzo wrote: > On 22/01/10 16:24, Bogdan-Andrei Iancu wrote: > >> Hi Lorenzo, >> >> I would say the STUN fails - STUN is used to discover both the IP and >> PORT, so if the port is wrong, STUN failed. >> >> There is no issue with your cfg, simply stun did not manage to discover >> the correct port - note that STUN does not work with symmetrical NATs. >> > > Hi Bogdan, > > maybe i'm mistaken, but shouldn't it be rport that prevails here? > the fact i use rport in my request means opensips knows i want the ip > header's port to be stored and used to contact me, right? > > because the port that stun discovers is the one i used to connect to the > stun server, which is not necessarily the same i'm going to use to > connect to opensips! > > my undertanding is that if i'm using the rport parameter, i can specify > ANY port in the sip header while forging a request, since rport will > tell the UAS not to consider it! > > form rfc3581 (rport) : >"If the "sent-protocol" >component indicates an unreliable unicast transport protocol, such as >UDP, and there is no "maddr" parameter, but there is both a >"received" parameter and an "rport" parameter, the response MUST be >sent to the IP address listed in the "received" parameter, and the >port in the "rport" parameter." > > have i missed the point? > > >> Regards, >> Bogdan >> > > thanks, > Lorenzo > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS Crashed!!
Hi Neo, Can you reproduce the crash ? it looks to happen when you do a CANCEL . Regards, Bogdan Neo Anderson wrote: > Hi, > > Right now I am using OpenSIPS 1.5.3 no-tls version in production. > Suddenly OpenSIPS got crashed. > I did check coredump but can not understand it. > Please help me out to interpret it. > Here is the pastebin link which contains output of bt. > http://pastebin.com/m49520853 > > Thanks in advance!!! > > -- > VoipExpert > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Music On Hold Opensips
Hi all, what can be done with opensips for MOH is using rtpproxy - it has the ability to inject RTP streams. The idea is to catch the on-hold re-INVITE (with 0.0.0.0 in SDP) and to force rtpproxy to play music for it. Never tried it, but it might work. Regards, Bogdan osiris123d wrote: > I actually was looking into this last night and found this post from Bogdan > > http://n2.nabble.com/Request-for-Brain-storming-New-types-of-routes-in-config-tt2693231.html#a2693231 > > Bogdan mentions in the subject that he is just brainstorming about new types > of routing. > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] sched_yield()
Hi Alex, Bug was fixed - update from SVN. Regarding your observation on"forking" versus "no-forking" - in some cases (when not doing any blocking ops), a single proc may be faster that multiple procs on a single core machine - because the CPU power is the same and maximum used (no blocking), but in forking mode you have the overhead of proc switching and the loocking/synchronizing dead-times. Regards, Bogdan Alex Massover wrote: > Hi, > > Unfortunately 'fifo get_statistics' crashes opensips, I opened a bug. > But no chance that 1G is not enough, only about 400M is used for all linux > processes: > Mem: 3115120k total, 398360k used, 2716760k free, 536k buffers > > Maybe sched_yield() just cause problems on 2.3.62 or on vmware or on SMP? > > I'm trying now with fork=yes and children=1. > If I have only one working child, does it suppose to lock and shed_yeild() > itself from any reason? > > Meanwhile with single child OpenSIPS easily handles 4K of concurrent calls at > 15cps, load average is 0.00 (!) and CPU is about 96% idle. > > I wonder if single working child also hangs. > > -- > Best Regards, > Alex Massover > VoIP R&D TL > Jajah Inc. > >> -Original Message- >> From: users-boun...@lists.opensips.org [mailto:users- >> boun...@lists.opensips.org] On Behalf Of Andrei Dragus >> Sent: Friday, January 22, 2010 1:17 PM >> To: OpenSIPS users mailling list >> Subject: Re: [OpenSIPS-Users] sched_yield() >> >> Hi, >> >> The new f_malloc will not do anything extra when compared to the old >> one >> until memory usage goes way up. >> I've added a warning in mem/f_malloc.c so you can see when defrag >> starts. If you get this warning then it is clear that the problem is >> from high memory usage. >> >> 1 GB for 4k calls seems a lot ( 250k per call). You can try to use >> "opensipsctl fifo get_statistics shmem:" and see what the memory usage >> is for diferent number of concurrent calls ( 1k,2k,3k,4k), and if >> indeed >> the memory usage is that high we should investigate the cause. >> >> >> Alex Massover wrote: >> >>> Hi, >>> >>> Now shared memory is 1G (-m 1024), and all memory is dedicated to >>> >> the virtual machine (it was shared till now). >> >>> But it still happens, just not so often. >>> >>> I originate the calls for this stress test in Asterisk with the same >>> >> resources and looks like Asterisk performs much better than OpenSIPS. >> How can it be? >> >>> In my stress OpenSIPS does no blocking/slow requests. And it's just >>> >> 4K concurrent calls, each one is 2-3 min. >> >>> Maybe OpenSIPS does too much low level memory management and virtual >>> >> machine is not suitable for it (despite that Asterisk runs well over >> VMware)? >> >>> I'm not sure but I have a feeling that 1.4 performed better. What can >>> >> cause performance degradation in 1.6? Storing vars on dialog, new >> malloc()? >> >>> gdb) bt >>> #0 0xb78ad424 in __kernel_vsyscall () >>> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 >>> #2 0x080bf23d in new_avp () >>> #3 0x080bf53f in add_avp () >>> #4 0x08080e6e in pv_set_avp () >>> #5 0x0808229c in pv_set_value () >>> #6 0x08053c9d in do_assign () >>> #7 0x0805447a in do_action () >>> #8 0x08053ebf in run_action_list () >>> #9 0x08056e7a in do_action () >>> #10 0x08053ebf in run_action_list () >>> #11 0x08056e7a in do_action () >>> #12 0x08053ebf in run_action_list () >>> #13 0x080569d8 in do_action () >>> #14 0x08053ebf in run_action_list () >>> #15 0x08056e7a in do_action () >>> #16 0x08053ebf in run_action_list () >>> #17 0x08057d99 in run_top_route () >>> #18 0x0808ad6c in receive_msg () >>> #19 0x080bd2f2 in udp_rcv_loop () >>> #20 0x08069339 in main () >>> (gdb) quit >>> >>> >>> (gdb) bt >>> #0 0xb78ad424 in __kernel_vsyscall () >>> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 >>> #2 0xb76f52cd in build_cell () from /usr/lib/opensips/modules/tm.so >>> #3 0xb770ac4a in t_newtran () from /usr/lib/opensips/modules/tm.so >>> #4 0xb76ff7b8 in t_relay_to () from /usr/lib/opensips/modules/tm.so >>> #5 0xb770c501 in ?? () from /usr/lib/opensips/modules/tm.so >>> #6 0x08055030 in do_action () >>> #7 0x08053ebf in run_action_list () >>> #8 0x08095cf2 in eval_expr () >>> #9 0x080958d9 in eval_expr () >>> #10 0x08095919 in eval_expr () >>> #11 0x080554e2 in do_action () >>> #12 0x08053ebf in run_action_list () >>> #13 0x080569d8 in do_action () >>> #14 0x08053ebf in run_action_list () >>> #15 0x08056e7a in do_action () >>> #16 0x08053ebf in run_action_list () >>> #17 0x08057d99 in run_top_route () >>> #18 0x0808ad6c in receive_msg () >>> #19 0x080bd2f2 in udp_rcv_loop () >>> #20 0x08069339 in main () >>> >>> >>> -- >>> Best Regards, >>> Alex Massover >>> VoIP R&D TL >>> Jajah Inc. >>> >>> >>> -Original Message- From: users-boun...@lists.opensips.org [mailto:users- boun...@lists.opensips.org] On Behalf Of Andrei Drag
Re: [OpenSIPS-Users] sched_yield()
Hi Alex,
Our tests with 1.6 (before release) did not indicated any degradation
with performance. Of course this strongly depends on what kind of
scenario you have on the proxy.
So:
1) do you use dialog support ?
2) if 1) is yes, do you use profiling ?
3) if 2) is yes, do you put all calls in a single profile ?
if you indeed use dialog + profiling, maybe you should try to A) remove
profiling and B) remove dialog support, to see how the performance
changes (if it does).
Regards,
Bogdan
Alex Massover wrote:
> Hi,
>
> Now shared memory is 1G (-m 1024), and all memory is dedicated to the
> virtual machine (it was shared till now).
> But it still happens, just not so often.
>
> I originate the calls for this stress test in Asterisk with the same
> resources and looks like Asterisk performs much better than OpenSIPS. How can
> it be?
> In my stress OpenSIPS does no blocking/slow requests. And it's just 4K
> concurrent calls, each one is 2-3 min.
>
> Maybe OpenSIPS does too much low level memory management and virtual machine
> is not suitable for it (despite that Asterisk runs well over VMware)?
>
> I'm not sure but I have a feeling that 1.4 performed better. What can cause
> performance degradation in 1.6? Storing vars on dialog, new malloc()?
>
> gdb) bt
> #0 0xb78ad424 in __kernel_vsyscall ()
> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6
> #2 0x080bf23d in new_avp ()
> #3 0x080bf53f in add_avp ()
> #4 0x08080e6e in pv_set_avp ()
> #5 0x0808229c in pv_set_value ()
> #6 0x08053c9d in do_assign ()
> #7 0x0805447a in do_action ()
> #8 0x08053ebf in run_action_list ()
> #9 0x08056e7a in do_action ()
> #10 0x08053ebf in run_action_list ()
> #11 0x08056e7a in do_action ()
> #12 0x08053ebf in run_action_list ()
> #13 0x080569d8 in do_action ()
> #14 0x08053ebf in run_action_list ()
> #15 0x08056e7a in do_action ()
> #16 0x08053ebf in run_action_list ()
> #17 0x08057d99 in run_top_route ()
> #18 0x0808ad6c in receive_msg ()
> #19 0x080bd2f2 in udp_rcv_loop ()
> #20 0x08069339 in main ()
> (gdb) quit
>
>
> (gdb) bt
> #0 0xb78ad424 in __kernel_vsyscall ()
> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6
> #2 0xb76f52cd in build_cell () from /usr/lib/opensips/modules/tm.so
> #3 0xb770ac4a in t_newtran () from /usr/lib/opensips/modules/tm.so
> #4 0xb76ff7b8 in t_relay_to () from /usr/lib/opensips/modules/tm.so
> #5 0xb770c501 in ?? () from /usr/lib/opensips/modules/tm.so
> #6 0x08055030 in do_action ()
> #7 0x08053ebf in run_action_list ()
> #8 0x08095cf2 in eval_expr ()
> #9 0x080958d9 in eval_expr ()
> #10 0x08095919 in eval_expr ()
> #11 0x080554e2 in do_action ()
> #12 0x08053ebf in run_action_list ()
> #13 0x080569d8 in do_action ()
> #14 0x08053ebf in run_action_list ()
> #15 0x08056e7a in do_action ()
> #16 0x08053ebf in run_action_list ()
> #17 0x08057d99 in run_top_route ()
> #18 0x0808ad6c in receive_msg ()
> #19 0x080bd2f2 in udp_rcv_loop ()
> #20 0x08069339 in main ()
>
>
> --
> Best Regards,
> Alex Massover
> VoIP R&D TL
> Jajah Inc.
>
>
>> -Original Message-
>> From: users-boun...@lists.opensips.org [mailto:users-
>> boun...@lists.opensips.org] On Behalf Of Andrei Dragus
>> Sent: Thursday, January 21, 2010 3:43 PM
>> To: OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] sched_yield()
>>
>> My guess is that there is not enough shared memory. When an allocation
>> failes OpenSIPS tries to defragment memory to make room which takes a
>> lot of time and must be done under lock.
>>
>> Please try to increase the shared memory size and tell me if it
>> persists.
>>
>>
>> Alex Massover wrote:
>>
>>> Hi!
>>>
>>> Yes, with -DF_MALLOC.
>>>
>>> 1.6.1 from sources, I build deb package.
>>> I use 128M of shared and 10*1024*1024 private memory (can increase -
>>>
>> no problem).
>>
>>> H, "opensipsctl fifo get_statistics all" crashes/stops the
>>>
>> opensips.
>>
>>> 'fifo uptime' or 'fifo debug' are OK.
>>>
>>> strace while 'fifo get_statistics all':
>>> Process 9509 attached - interrupt to quit
>>> pause() = ? ERESTARTNOHAND (To be
>>>
>> restarted)
>>
>>> --- SIGUSR2 (User defined signal 2) @ 0 (0) ---
>>> sigreturn() = ? (mask now [])
>>> pause() = ? ERESTARTNOHAND (To be
>>>
>> restarted)
>>
>>> --- SIGCHLD (Child exited) @ 0 (0) ---
>>> sigreturn() = ? (mask now [])
>>> waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGUSR2}], WNOHANG) =
>>>
>> 9520
>>
>>> waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
>>> kill(0, SIGTERM)= 0
>>> --- SIGTERM (Terminated) @ 0 (0) ---
>>> --- SIGCHLD (Child exited) @ 0 (0) ---
>>> sigreturn() = ? (mask now [TERM])
>>> sigreturn() = ? (mask now [])
>>> rt_sigaction(SIGALRM, {0x8065920, [ALRM], SA_RESTART}, {SIG_DFL}, 8)
>>>
>>
Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)
Hi Oleg, The problem seams to be around the loose_route() part -> after the loose_route, the ACK is not sent to the GW, but it loop on the proxy. That is a typically behaviour when you misconfigure opensips and opensips believes that the GW IP is one of its own IPs. Is the GW IP added as "alias" in the script? or in the "domain" table? Regards, Bogdan Oleg Burlacu wrote: > > > Hi, > I'm running a statefull proxy that in most cases need to relay the > calls to a PSTN gateway. > After the migration to the Opensips 1.6.1, there is a problem with > compatibility / RR module and the gateway (Cisco AS5300). > Opensips does not relay 'correctly' (in my case) the ACK messages. The > Cisco gateway do not receive ACKs and hangup the call after a timeout. > The configuration script is developed on the sipwise template, but it > works perfectly in 1.4 version of Opensips. > > When debugging I see each time more and more headers in ACK packets > Record-Route: > Record-Route: > Record-Route: > Record-Route: > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2 > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2 > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2 > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2 > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405 > > When disabling the record_route(), and messages go from sip client > directly to the gateway - all in ok. > When communicating between 2 sip clients on the same proxy - the > messages are relayed correctly. > What can be the solution? > > > The entire message log: > > U xx.yy.17.20:5060 -> xx.yy.56.226:5060 > INVITE sip:987...@xx.yy.56.226 SIP/2.0. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed. > From: "unknown" ;tag=152937654c2b. > To: . > Contact: . > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 1 INVITE. > Max-Forwards: 70. > User-Agent: SJphone/1.65.377a (SJ Labs). > > > U xx.yy.56.226:5060 -> xx.yy.17.20:5060 > SIP/2.0 100 Trying. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed. > From: "unknown" ;tag=152937654c2b. > To: . > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 1 INVITE. > > > > U xx.yy.56.226:5060 -> xx.yy.17.20:5060 > SIP/2.0 407 Proxy Authentication Required. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed. > From: "unknown" ;tag=152937654c2b. > To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548. > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 1 INVITE. > > > > U xx.yy.17.20:5060 -> xx.yy.56.226:5060 > ACK sip:987...@xx.yy.56.226 SIP/2.0. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed. > From: "unknown" ;tag=152937654c2b. > To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548. > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 1 ACK. > Max-Forwards: 70. > User-Agent: SJphone/1.65.377a (SJ Labs). > Content-Length: 0. > > > > U xx.yy.17.20:5060 -> xx.yy.56.226:5060 > INVITE sip:987...@xx.yy.56.226 SIP/2.0. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0. > From: "unknown" ;tag=152937654c2b. > To: . > Contact: . > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 2 INVITE. > Max-Forwards: 70. > User-Agent: SJphone/1.65.377a (SJ Labs). > Content-Length: 362. > Content-Type: application/sdp. > Supported: replaces,norefersub,timer. > Proxy-Authorization: Digest > username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226",response="91a62cf62af7870c1e24d6c35857e78d". > > > > U xx.yy.56.226:5060 -> xx.yy.17.20:5060 > SIP/2.0 100 Trying. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0. > From: "unknown" ;tag=152937654c2b. > To: . > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 2 INVITE. > Server: OpenSIPS (1.6.1-notls (x86_64/linux)). > Content-Length: 0. > > > U xx.yy.56.226:5060 -> xx.yy.17.20:5060 > SIP/2.0 100 Giving a try. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0. > From: "unknown" ;tag=152937654c2b. > To: . > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 2 INVITE. > > > U xx.yy.56.226:5060 -> xx.yy.25.114:5060 > INVITE sip:987...@xx.yy.25.114:5060;transport=udp SIP/2.0. > Record-Route: . > Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0. > Via: SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0. > From: "unknown" ;tag=152937654c2b. > To: . > Contact: . > Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114. > CSeq: 2 INVITE. > Max-Forwards: 69. > > > > U xx.yy.25.114:5060 -> xx.yy.56.226:5060 > SIP/2.0 100 Trying. > Via: SIP/2.0/UDP > xx.yy.56.226;branch=z9hG4bKf69b.0ced9bb7.0,SIP/2.0/UDP > xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0. > Fr
users@lists.opensips.org
Hi Indiver, Could you share with us :).. I expect the files are raw RTP files... Regards, Bogdan Indiver wrote: > I found the solution and now i can hear my recorded files. > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] NAT helper : ping not sent
Hi Yannick,
You also need to :
1) force pinging to all registered contacts (see ping_nated_only param
http://www.opensips.org/html/docs/modules/devel/nathelper.html#id228173)
2) ping only the records which are marked as nated (see nat_bflag param
http://www.opensips.org/html/docs/modules/devel/usrloc.html#id228228)
Regards,
Bogdan
Yannick LE COENT wrote:
>
> Hello,
>
>
>
> I added the NAT helper module and added in my script the following line:
>
> modparam("nathelper", "natping_interval", 30)
>
>
>
> But I do not see 4 bytes (zero filled) UDP packets.
>
> What could be wrong?
>
>
>
> Thanks,
>
> Yannick
>
>
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] need help on dialplan module
Hi Ha, The modules user PERL like substitution. A fast google gives some docs on this: http://www.anaesthetist.com/mnm/perl/Findex.htm#regex.htm Regards, Bogdan ha do wrote: > Hi all > > could you please need me to understand the translation on dialplan module; > mysql> select * from dialplan; > ++--++--+---+---++--+---+ > | id | dpid | pr | match_op | match_exp | match_len | subst_exp | > repl_exp | attrs | > ++--++--+---+---++--+---+ > | 73 | 15 | 0 |1 | ^000 | 0 | ^(0)(.+) | > \2 | | > | 78 | 16 | 0 |1 | 000 | 0 | (000)(.+) | > 8\2 | | > | 76 | 14 | 0 |1 | ^000 | 0 | ^(000)(.+) | > 8\2 | | > | 75 | 15 | 0 |1 | ^55 | 0 | ^(55)(.+) | > \2 | | > ++--++--+---+---++--+---+ > > [r...@localhost ~]# opensipsctl fifo dp_translate 14 00055980007 > Output:: 855980007 > [r...@localhost ~]# opensipsctl fifo dp_translate 15 0007 > Output:: 007 > [r...@localhost ~]# opensipsctl fifo dp_translate 15 55980007 > Output:: 980007 > [r...@localhost ~]# opensipsctl fifo dp_translate 16 55980007 > Output:: 87 > > repl_exp : sometimes has value \2 or \1 - what does it mean?? does it > have other value? > what does the ^ mean?? > is there more special character?? > > where do i find more docs for translation rule > > Thank you > Ha` > > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Upgrade CDRTool from 6.9.9 to 7.0.X
Hi everybody, Are there any instructions to upgrade the CDRTool 6.9.9 to the last version 7.0.X? I don't see details about this in the docs directory. Many thanks, Juan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] INVITE not forwarded, call fails
On 22/01/10 16:24, Bogdan-Andrei Iancu wrote: > Hi Lorenzo, > > I would say the STUN fails - STUN is used to discover both the IP and > PORT, so if the port is wrong, STUN failed. > > There is no issue with your cfg, simply stun did not manage to discover > the correct port - note that STUN does not work with symmetrical NATs. Hi Bogdan, maybe i'm mistaken, but shouldn't it be rport that prevails here? the fact i use rport in my request means opensips knows i want the ip header's port to be stored and used to contact me, right? because the port that stun discovers is the one i used to connect to the stun server, which is not necessarily the same i'm going to use to connect to opensips! my undertanding is that if i'm using the rport parameter, i can specify ANY port in the sip header while forging a request, since rport will tell the UAS not to consider it! form rfc3581 (rport) : "If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter." have i missed the point? > Regards, > Bogdan thanks, Lorenzo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] INVITE not forwarded, call fails
Hi Lorenzo, I would say the STUN fails - STUN is used to discover both the IP and PORT, so if the port is wrong, STUN failed. There is no issue with your cfg, simply stun did not manage to discover the correct port - note that STUN does not work with symmetrical NATs. Regards, Bogdan lorenzo wrote: > On 09/12/09 18:09, Bogdan-Andrei Iancu wrote: > >> Hi Lorenzo, >> >> check with "opensipsctl ul show" how your phone is registered - what is >> important are the "contact" and "received" fields - which is present and >> which contains private IPs. >> > > > Hi Bogdan! > > first of all, thanks for the very late reply, been very busy lately! > > i've checked with "opensipsctl ul show", and what shows up is that my > app is recorded with the wrong port! i.e. not the one in the ip header, > but the one in the sip header.! it's as if rport was ignored! > > AOR:: asymmetric > Contact:: > sip:asymmet...@151.16.109.231:62560;transport=udp Q= > Expires:: 3565 > Callid:: 445710225...@151.16.109.231 > Cseq:: 1 > User-agent:: mjsip stack 1.6 > State:: CS_NEW > Flags:: 0 > Cflag:: 0 > Socket:: udp:88.149.188.29:5060 > Methods:: 4294967295 > > 62560 is wrong, while the ip is correct (which means that stun works > correctly) > > i probably misconfigured opensips.cfg, could you give me some advice? > > here's mine, in all its glory ;) > http://paste2.org/p/623910 > > btw, i'm running a very basic setup with no db, is that a problem? > > thanks a lot, > lorenzo > > >> Regards, >> Bogdan >> > > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] problem with uac registration
Hi Lorenzo, use debug=6 in your script and post the debug output (of Opensips) - the part relevant for processing the REGISTER. Regards, Bogdan lorenzo wrote: > On 16/11/09 15:49, Bogdan-Andrei Iancu wrote: > >> Hi Lorenzo, >> >> Check the followings: >> (1) your REGISTERS hits opensips (run an ngrep on opensips's machine) >> (2) check where the reply from opensips is sent to (maybe it is sent to >> wrong destination) >> > > > hi bogdan! > again, sorry for the late reply! > > (1) yes, they do hit opensips > (2) there's no reply for what i can see.. > > this is the parameters i'm feeding to ngrep: > sudo ngrep -tW byline port 5060 > > should be ok, right? > > if you need some excerpts of the debug log, just let me know (along with > the debug level needed) > > >> Regards, >> Bogdan >> > > thanks again, > lorenzo > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Unsuccessfull upgrade from 1.4.5 to 1.6.1 (RR module)
Hi,
I'm no expert but I think that the default opensips scripts handles the
downscript ACK with this code:
route(1) simple relays the message.
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if (is_method("BYE")) {
setflag(1); # do accounting ...
setflag(3); # ... even if the transaction
fails
}
route(1);
} else {
/* uncomment the following lines if you want to
enable presence */
##if (is_method("SUBSCRIBE") && $rd ==
"your.server.ip.address") {
## # in-dialog subscribe requests
## route(2);
## exit;
##}
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non loose-route, but stateful ACK;
must be an ACK after a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching transaction
... ignore and discard.\n");
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
Hope it helps,
Regards,
2010/1/21 Oleg Burlacu
>
>
> Hi,
> I'm running a statefull proxy that in most cases need to relay the calls to
> a PSTN gateway.
> After the migration to the Opensips 1.6.1, there is a problem with
> compatibility / RR module and the gateway (Cisco AS5300).
> Opensips does not relay 'correctly' (in my case) the ACK messages. The
> Cisco gateway do not receive ACKs and hangup the call after a timeout.
> The configuration script is developed on the sipwise template, but it works
> perfectly in 1.4 version of Opensips.
>
> When debugging I see each time more and more headers in ACK packets
> Record-Route:
> Record-Route:
> Record-Route:
> Record-Route:
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP xx.yy.56.226;branch=z9hG4bKa636.94cf333.2
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111423e34b43aea64e671405
>
> When disabling the record_route(), and messages go from sip client directly
> to the gateway - all in ok.
> When communicating between 2 sip clients on the same proxy - the messages
> are relayed correctly.
> What can be the solution?
>
>
> The entire message log:
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 100 Trying.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
>
>
>
> U xx.yy.56.226:5060 -> xx.yy.17.20:5060
> SIP/2.0 407 Proxy Authentication Required.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 INVITE.
>
>
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> ACK sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426464b44616423ea16ed.
> From: "unknown" ;tag=152937654c2b.
> To: ;tag=c97b4d1cb1f3d0da549e06a8d482ef63.8548.
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 1 ACK.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
> Content-Length: 0.
>
>
>
> U xx.yy.17.20:5060 -> xx.yy.56.226:5060
> INVITE sip:987...@xx.yy.56.226 SIP/2.0.
> Via: SIP/2.0/UDP
> xx.yy.17.20;branch=z9hG4bK591c111426474b446164164716f0.
> From: "unknown" ;tag=152937654c2b.
> To: .
> Contact: .
> Call-ID: D17BF0696DC546A7B436401CD27774720x591c1114.
> CSeq: 2 INVITE.
> Max-Forwards: 70.
> User-Agent: SJphone/1.65.377a (SJ Labs).
> Content-Length: 362.
> Content-Type: application/sdp.
> Supported: replaces,norefersub,timer.
> Proxy-Authorization: Digest
> username="123456",realm="xx.yy.56.226",nonce="4b43ec22000883661dbea2617b91d28401983dd85b7d",uri="sip:987...@xx.yy.56.226
> ",response="9
[OpenSIPS-Users] "SIP introduction" is the next webinar
Next webinar is scheduled for 28th of January 2010. The topic is "SIP Introduction" - detailed explanation and examples of SIP fundamentals: Requests and Replies, Initial and sequential requests, SIP transactions, SIP dialogs, SIP and RTP; A good understanding of SIP protocol is essential for working with OpenSIPS. Free registration - http://www.opensips.org/Training/Webinars#toc5 The list with all the next scheduled webinars is available under http://www.opensips.org/Training/Webinars#toc4 Best regards, Bogdan -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opiniions about WE SIP+OpenSIPS
Hi Vladimir, OpenSIPS 1.6 has a built-in b2bua module that allows you (via xml based scripting) to create custom scenarios. Regards, Bogdan Vladimir Kolosov wrote: > Good day, all. > I have a question about WE SIP > (http://www.wesip.com/mediawiki/index.php/Main_Page) > Is there anyone who tried it? What you managed to achieve? Its worth to use > it? > Im thinking about using it for B2BUA implementation for OpenSER, and > maybe some other applications in future... > Any opinions and suggestions is very important for me. > > Thanks. > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opiniions about WE SIP+OpenSIPS
El Viernes, 22 de Enero de 2010, Vladimir Kolosov escribió: > Good day, all. > I have a question about WE SIP > (http://www.wesip.com/mediawiki/index.php/Main_Page) > Is there anyone who tried it? What you managed to achieve? Its worth to use > it? Im thinking about using it for B2BUA implementation for OpenSER, and > maybe some other applications in future... > Any opinions and suggestions is very important for me. Take into account that WeSIP cannot be used for commercial deployments according to its current license: http://www.wesip.com/mediawiki/index.php/License -- Iñaki Baz Castillo ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] sched_yield()
Thanks! I'll try it. Some update meanwhile, children=1 definitely behaves better for me than 8, on 4-way SMP. 8 - hang, 1 - doesn't hang. Interesting... -- Best Regards, Alex Massover VoIP R&D TL Jajah Inc. > -Original Message- > From: users-boun...@lists.opensips.org [mailto:users- > boun...@lists.opensips.org] On Behalf Of Andrei Dragus > Sent: Friday, January 22, 2010 2:22 PM > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] sched_yield() > > > To determine if running on vmware is a problem you could try to test it > on a real machine and see. > > And just to make sure that f_malloc is not the issue you could try > getting an older version of the mem folder ( either one from revision > r6274 or one from 1.5 branch) > > > Alex Massover wrote: > > Hi, > > > > Unfortunately 'fifo get_statistics' crashes opensips, I opened a bug. > > But no chance that 1G is not enough, only about 400M is used for all > linux processes: > > Mem: 3115120k total, 398360k used, 2716760k free, 536k > buffers > > > > Maybe sched_yield() just cause problems on 2.3.62 or on vmware or on > SMP? > > > > I'm trying now with fork=yes and children=1. > > If I have only one working child, does it suppose to lock and > shed_yeild() itself from any reason? > > > > Meanwhile with single child OpenSIPS easily handles 4K of concurrent > calls at 15cps, load average is 0.00 (!) and CPU is about 96% idle. > > > > I wonder if single working child also hangs. > > > > -- > > Best Regards, > > Alex Massover > > VoIP R&D TL > > Jajah Inc. > > > >> -Original Message- > >> From: users-boun...@lists.opensips.org [mailto:users- > >> boun...@lists.opensips.org] On Behalf Of Andrei Dragus > >> Sent: Friday, January 22, 2010 1:17 PM > >> To: OpenSIPS users mailling list > >> Subject: Re: [OpenSIPS-Users] sched_yield() > >> > >> Hi, > >> > >> The new f_malloc will not do anything extra when compared to the old > >> one > >> until memory usage goes way up. > >> I've added a warning in mem/f_malloc.c so you can see when defrag > >> starts. If you get this warning then it is clear that the problem is > >> from high memory usage. > >> > >> 1 GB for 4k calls seems a lot ( 250k per call). You can try to use > >> "opensipsctl fifo get_statistics shmem:" and see what the memory > usage > >> is for diferent number of concurrent calls ( 1k,2k,3k,4k), and if > >> indeed > >> the memory usage is that high we should investigate the cause. > >> > >> > >> Alex Massover wrote: > >> > >>> Hi, > >>> > >>> Now shared memory is 1G (-m 1024), and all memory is dedicated to > >>> > >> the virtual machine (it was shared till now). > >> > >>> But it still happens, just not so often. > >>> > >>> I originate the calls for this stress test in Asterisk with the > same > >>> > >> resources and looks like Asterisk performs much better than > OpenSIPS. > >> How can it be? > >> > >>> In my stress OpenSIPS does no blocking/slow requests. And it's just > >>> > >> 4K concurrent calls, each one is 2-3 min. > >> > >>> Maybe OpenSIPS does too much low level memory management and > virtual > >>> > >> machine is not suitable for it (despite that Asterisk runs well over > >> VMware)? > >> > >>> I'm not sure but I have a feeling that 1.4 performed better. What > can > >>> > >> cause performance degradation in 1.6? Storing vars on dialog, new > >> malloc()? > >> > >>> gdb) bt > >>> #0 0xb78ad424 in __kernel_vsyscall () > >>> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 > >>> #2 0x080bf23d in new_avp () > >>> #3 0x080bf53f in add_avp () > >>> #4 0x08080e6e in pv_set_avp () > >>> #5 0x0808229c in pv_set_value () > >>> #6 0x08053c9d in do_assign () > >>> #7 0x0805447a in do_action () > >>> #8 0x08053ebf in run_action_list () > >>> #9 0x08056e7a in do_action () > >>> #10 0x08053ebf in run_action_list () > >>> #11 0x08056e7a in do_action () > >>> #12 0x08053ebf in run_action_list () > >>> #13 0x080569d8 in do_action () > >>> #14 0x08053ebf in run_action_list () > >>> #15 0x08056e7a in do_action () > >>> #16 0x08053ebf in run_action_list () > >>> #17 0x08057d99 in run_top_route () > >>> #18 0x0808ad6c in receive_msg () > >>> #19 0x080bd2f2 in udp_rcv_loop () > >>> #20 0x08069339 in main () > >>> (gdb) quit > >>> > >>> > >>> (gdb) bt > >>> #0 0xb78ad424 in __kernel_vsyscall () > >>> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 > >>> #2 0xb76f52cd in build_cell () from > /usr/lib/opensips/modules/tm.so > >>> #3 0xb770ac4a in t_newtran () from /usr/lib/opensips/modules/tm.so > >>> #4 0xb76ff7b8 in t_relay_to () from > /usr/lib/opensips/modules/tm.so > >>> #5 0xb770c501 in ?? () from /usr/lib/opensips/modules/tm.so > >>> #6 0x08055030 in do_action () > >>> #7 0x08053ebf in run_action_list () > >>> #8 0x08095cf2 in eval_expr () > >>> #9 0x080958d9 in eval_expr () > >>> #10 0x08095919 in eval_expr () > >>> #11 0x080554e2 in do_action () > >>> #12 0x08053ebf in run_action_list () > >>> #13 0x080569d8 in do_ac
Re: [OpenSIPS-Users] Failed INVITE tcp_send to UDP UACs
Hello Bogdan, An mar., déc 22, 2009, Bogdan-Andrei Iancu schrieb: >opensipsl...@encambio.com wrote: But this is maybe a clue. It would seem that something in TLS writing has changed between these two versions, maybe fundementally? >>> 1.3 was doing infinite loop (for write and read), leading sometime to >>> blocking. >>> >> That was a painful part of 1.3, so good that the counter is there >> now. I guess you're saying that the same TLS problems existed in >> 1.3 as well, but they were masked by retries (maybe thousands.) >> >yes, that is correct. > Can it be that when the internal OpenSIPS TCP lifetime counter is set to the registration interval using the tcp_persistent_flag that this counter is used even when the registration forcefully expires? What I mean by forcefully is: Some IP phones don't wait for a registration period to time out. Instead they wait for 1/2 of the expiry period and then send a new REGISTER with a header 'Expires: 0' to force the registration to timeout. Then they immediately send a new REGISTER with a normal expiry value to obtain a new registration. ...so if an expiry time is 10 minutes, after only 5 minutes the UAC invalidates the registration and makes a new one. I'm wondering if OpenSIPS tries opening TCP connections using the value of 10 minutes with a UAC which is no longer in the location table because the AOR was removed (due to the principle described above.) Possible? Brian ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Opiniions about WE SIP+OpenSIPS
Good day, all. I have a question about WE SIP (http://www.wesip.com/mediawiki/index.php/Main_Page) Is there anyone who tried it? What you managed to achieve? Its worth to use it? Im thinking about using it for B2BUA implementation for OpenSER, and maybe some other applications in future... Any opinions and suggestions is very important for me. Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] sched_yield()
To determine if running on vmware is a problem you could try to test it on a real machine and see. And just to make sure that f_malloc is not the issue you could try getting an older version of the mem folder ( either one from revision r6274 or one from 1.5 branch) Alex Massover wrote: > Hi, > > Unfortunately 'fifo get_statistics' crashes opensips, I opened a bug. > But no chance that 1G is not enough, only about 400M is used for all linux > processes: > Mem: 3115120k total, 398360k used, 2716760k free, 536k buffers > > Maybe sched_yield() just cause problems on 2.3.62 or on vmware or on SMP? > > I'm trying now with fork=yes and children=1. > If I have only one working child, does it suppose to lock and shed_yeild() > itself from any reason? > > Meanwhile with single child OpenSIPS easily handles 4K of concurrent calls at > 15cps, load average is 0.00 (!) and CPU is about 96% idle. > > I wonder if single working child also hangs. > > -- > Best Regards, > Alex Massover > VoIP R&D TL > Jajah Inc. > >> -Original Message- >> From: users-boun...@lists.opensips.org [mailto:users- >> boun...@lists.opensips.org] On Behalf Of Andrei Dragus >> Sent: Friday, January 22, 2010 1:17 PM >> To: OpenSIPS users mailling list >> Subject: Re: [OpenSIPS-Users] sched_yield() >> >> Hi, >> >> The new f_malloc will not do anything extra when compared to the old >> one >> until memory usage goes way up. >> I've added a warning in mem/f_malloc.c so you can see when defrag >> starts. If you get this warning then it is clear that the problem is >> from high memory usage. >> >> 1 GB for 4k calls seems a lot ( 250k per call). You can try to use >> "opensipsctl fifo get_statistics shmem:" and see what the memory usage >> is for diferent number of concurrent calls ( 1k,2k,3k,4k), and if >> indeed >> the memory usage is that high we should investigate the cause. >> >> >> Alex Massover wrote: >> >>> Hi, >>> >>> Now shared memory is 1G (-m 1024), and all memory is dedicated to >>> >> the virtual machine (it was shared till now). >> >>> But it still happens, just not so often. >>> >>> I originate the calls for this stress test in Asterisk with the same >>> >> resources and looks like Asterisk performs much better than OpenSIPS. >> How can it be? >> >>> In my stress OpenSIPS does no blocking/slow requests. And it's just >>> >> 4K concurrent calls, each one is 2-3 min. >> >>> Maybe OpenSIPS does too much low level memory management and virtual >>> >> machine is not suitable for it (despite that Asterisk runs well over >> VMware)? >> >>> I'm not sure but I have a feeling that 1.4 performed better. What can >>> >> cause performance degradation in 1.6? Storing vars on dialog, new >> malloc()? >> >>> gdb) bt >>> #0 0xb78ad424 in __kernel_vsyscall () >>> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 >>> #2 0x080bf23d in new_avp () >>> #3 0x080bf53f in add_avp () >>> #4 0x08080e6e in pv_set_avp () >>> #5 0x0808229c in pv_set_value () >>> #6 0x08053c9d in do_assign () >>> #7 0x0805447a in do_action () >>> #8 0x08053ebf in run_action_list () >>> #9 0x08056e7a in do_action () >>> #10 0x08053ebf in run_action_list () >>> #11 0x08056e7a in do_action () >>> #12 0x08053ebf in run_action_list () >>> #13 0x080569d8 in do_action () >>> #14 0x08053ebf in run_action_list () >>> #15 0x08056e7a in do_action () >>> #16 0x08053ebf in run_action_list () >>> #17 0x08057d99 in run_top_route () >>> #18 0x0808ad6c in receive_msg () >>> #19 0x080bd2f2 in udp_rcv_loop () >>> #20 0x08069339 in main () >>> (gdb) quit >>> >>> >>> (gdb) bt >>> #0 0xb78ad424 in __kernel_vsyscall () >>> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 >>> #2 0xb76f52cd in build_cell () from /usr/lib/opensips/modules/tm.so >>> #3 0xb770ac4a in t_newtran () from /usr/lib/opensips/modules/tm.so >>> #4 0xb76ff7b8 in t_relay_to () from /usr/lib/opensips/modules/tm.so >>> #5 0xb770c501 in ?? () from /usr/lib/opensips/modules/tm.so >>> #6 0x08055030 in do_action () >>> #7 0x08053ebf in run_action_list () >>> #8 0x08095cf2 in eval_expr () >>> #9 0x080958d9 in eval_expr () >>> #10 0x08095919 in eval_expr () >>> #11 0x080554e2 in do_action () >>> #12 0x08053ebf in run_action_list () >>> #13 0x080569d8 in do_action () >>> #14 0x08053ebf in run_action_list () >>> #15 0x08056e7a in do_action () >>> #16 0x08053ebf in run_action_list () >>> #17 0x08057d99 in run_top_route () >>> #18 0x0808ad6c in receive_msg () >>> #19 0x080bd2f2 in udp_rcv_loop () >>> #20 0x08069339 in main () >>> >>> >>> -- >>> Best Regards, >>> Alex Massover >>> VoIP R&D TL >>> Jajah Inc. >>> >>> >>> -Original Message- From: users-boun...@lists.opensips.org [mailto:users- boun...@lists.opensips.org] On Behalf Of Andrei Dragus Sent: Thursday, January 21, 2010 3:43 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] sched_yield() M
Re: [OpenSIPS-Users] sched_yield()
Hi, Unfortunately 'fifo get_statistics' crashes opensips, I opened a bug. But no chance that 1G is not enough, only about 400M is used for all linux processes: Mem: 3115120k total, 398360k used, 2716760k free, 536k buffers Maybe sched_yield() just cause problems on 2.3.62 or on vmware or on SMP? I'm trying now with fork=yes and children=1. If I have only one working child, does it suppose to lock and shed_yeild() itself from any reason? Meanwhile with single child OpenSIPS easily handles 4K of concurrent calls at 15cps, load average is 0.00 (!) and CPU is about 96% idle. I wonder if single working child also hangs. -- Best Regards, Alex Massover VoIP R&D TL Jajah Inc. > -Original Message- > From: users-boun...@lists.opensips.org [mailto:users- > boun...@lists.opensips.org] On Behalf Of Andrei Dragus > Sent: Friday, January 22, 2010 1:17 PM > To: OpenSIPS users mailling list > Subject: Re: [OpenSIPS-Users] sched_yield() > > Hi, > > The new f_malloc will not do anything extra when compared to the old > one > until memory usage goes way up. > I've added a warning in mem/f_malloc.c so you can see when defrag > starts. If you get this warning then it is clear that the problem is > from high memory usage. > > 1 GB for 4k calls seems a lot ( 250k per call). You can try to use > "opensipsctl fifo get_statistics shmem:" and see what the memory usage > is for diferent number of concurrent calls ( 1k,2k,3k,4k), and if > indeed > the memory usage is that high we should investigate the cause. > > > Alex Massover wrote: > > Hi, > > > > Now shared memory is 1G (-m 1024), and all memory is dedicated to > the virtual machine (it was shared till now). > > But it still happens, just not so often. > > > > I originate the calls for this stress test in Asterisk with the same > resources and looks like Asterisk performs much better than OpenSIPS. > How can it be? > > In my stress OpenSIPS does no blocking/slow requests. And it's just > 4K concurrent calls, each one is 2-3 min. > > > > Maybe OpenSIPS does too much low level memory management and virtual > machine is not suitable for it (despite that Asterisk runs well over > VMware)? > > > > I'm not sure but I have a feeling that 1.4 performed better. What can > cause performance degradation in 1.6? Storing vars on dialog, new > malloc()? > > > > gdb) bt > > #0 0xb78ad424 in __kernel_vsyscall () > > #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 > > #2 0x080bf23d in new_avp () > > #3 0x080bf53f in add_avp () > > #4 0x08080e6e in pv_set_avp () > > #5 0x0808229c in pv_set_value () > > #6 0x08053c9d in do_assign () > > #7 0x0805447a in do_action () > > #8 0x08053ebf in run_action_list () > > #9 0x08056e7a in do_action () > > #10 0x08053ebf in run_action_list () > > #11 0x08056e7a in do_action () > > #12 0x08053ebf in run_action_list () > > #13 0x080569d8 in do_action () > > #14 0x08053ebf in run_action_list () > > #15 0x08056e7a in do_action () > > #16 0x08053ebf in run_action_list () > > #17 0x08057d99 in run_top_route () > > #18 0x0808ad6c in receive_msg () > > #19 0x080bd2f2 in udp_rcv_loop () > > #20 0x08069339 in main () > > (gdb) quit > > > > > > (gdb) bt > > #0 0xb78ad424 in __kernel_vsyscall () > > #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6 > > #2 0xb76f52cd in build_cell () from /usr/lib/opensips/modules/tm.so > > #3 0xb770ac4a in t_newtran () from /usr/lib/opensips/modules/tm.so > > #4 0xb76ff7b8 in t_relay_to () from /usr/lib/opensips/modules/tm.so > > #5 0xb770c501 in ?? () from /usr/lib/opensips/modules/tm.so > > #6 0x08055030 in do_action () > > #7 0x08053ebf in run_action_list () > > #8 0x08095cf2 in eval_expr () > > #9 0x080958d9 in eval_expr () > > #10 0x08095919 in eval_expr () > > #11 0x080554e2 in do_action () > > #12 0x08053ebf in run_action_list () > > #13 0x080569d8 in do_action () > > #14 0x08053ebf in run_action_list () > > #15 0x08056e7a in do_action () > > #16 0x08053ebf in run_action_list () > > #17 0x08057d99 in run_top_route () > > #18 0x0808ad6c in receive_msg () > > #19 0x080bd2f2 in udp_rcv_loop () > > #20 0x08069339 in main () > > > > > > -- > > Best Regards, > > Alex Massover > > VoIP R&D TL > > Jajah Inc. > > > > > >> -Original Message- > >> From: users-boun...@lists.opensips.org [mailto:users- > >> boun...@lists.opensips.org] On Behalf Of Andrei Dragus > >> Sent: Thursday, January 21, 2010 3:43 PM > >> To: OpenSIPS users mailling list > >> Subject: Re: [OpenSIPS-Users] sched_yield() > >> > >> My guess is that there is not enough shared memory. When an > allocation > >> failes OpenSIPS tries to defragment memory to make room which takes > a > >> lot of time and must be done under lock. > >> > >> Please try to increase the shared memory size and tell me if it > >> persists. > >> > >> > >> Alex Massover wrote: > >> > >>> Hi! > >>> > >>> Yes, with -DF_MALLOC. > >>> > >>> 1.6.1 from sources, I build deb package. > >>> I use 128M of shared and 10*1024*1024 private
Re: [OpenSIPS-Users] sched_yield()
Hi,
The new f_malloc will not do anything extra when compared to the old one
until memory usage goes way up.
I've added a warning in mem/f_malloc.c so you can see when defrag
starts. If you get this warning then it is clear that the problem is
from high memory usage.
1 GB for 4k calls seems a lot ( 250k per call). You can try to use
"opensipsctl fifo get_statistics shmem:" and see what the memory usage
is for diferent number of concurrent calls ( 1k,2k,3k,4k), and if indeed
the memory usage is that high we should investigate the cause.
Alex Massover wrote:
> Hi,
>
> Now shared memory is 1G (-m 1024), and all memory is dedicated to the
> virtual machine (it was shared till now).
> But it still happens, just not so often.
>
> I originate the calls for this stress test in Asterisk with the same
> resources and looks like Asterisk performs much better than OpenSIPS. How can
> it be?
> In my stress OpenSIPS does no blocking/slow requests. And it's just 4K
> concurrent calls, each one is 2-3 min.
>
> Maybe OpenSIPS does too much low level memory management and virtual machine
> is not suitable for it (despite that Asterisk runs well over VMware)?
>
> I'm not sure but I have a feeling that 1.4 performed better. What can cause
> performance degradation in 1.6? Storing vars on dialog, new malloc()?
>
> gdb) bt
> #0 0xb78ad424 in __kernel_vsyscall ()
> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6
> #2 0x080bf23d in new_avp ()
> #3 0x080bf53f in add_avp ()
> #4 0x08080e6e in pv_set_avp ()
> #5 0x0808229c in pv_set_value ()
> #6 0x08053c9d in do_assign ()
> #7 0x0805447a in do_action ()
> #8 0x08053ebf in run_action_list ()
> #9 0x08056e7a in do_action ()
> #10 0x08053ebf in run_action_list ()
> #11 0x08056e7a in do_action ()
> #12 0x08053ebf in run_action_list ()
> #13 0x080569d8 in do_action ()
> #14 0x08053ebf in run_action_list ()
> #15 0x08056e7a in do_action ()
> #16 0x08053ebf in run_action_list ()
> #17 0x08057d99 in run_top_route ()
> #18 0x0808ad6c in receive_msg ()
> #19 0x080bd2f2 in udp_rcv_loop ()
> #20 0x08069339 in main ()
> (gdb) quit
>
>
> (gdb) bt
> #0 0xb78ad424 in __kernel_vsyscall ()
> #1 0xb77e841c in sched_yield () from /lib/i686/cmov/libc.so.6
> #2 0xb76f52cd in build_cell () from /usr/lib/opensips/modules/tm.so
> #3 0xb770ac4a in t_newtran () from /usr/lib/opensips/modules/tm.so
> #4 0xb76ff7b8 in t_relay_to () from /usr/lib/opensips/modules/tm.so
> #5 0xb770c501 in ?? () from /usr/lib/opensips/modules/tm.so
> #6 0x08055030 in do_action ()
> #7 0x08053ebf in run_action_list ()
> #8 0x08095cf2 in eval_expr ()
> #9 0x080958d9 in eval_expr ()
> #10 0x08095919 in eval_expr ()
> #11 0x080554e2 in do_action ()
> #12 0x08053ebf in run_action_list ()
> #13 0x080569d8 in do_action ()
> #14 0x08053ebf in run_action_list ()
> #15 0x08056e7a in do_action ()
> #16 0x08053ebf in run_action_list ()
> #17 0x08057d99 in run_top_route ()
> #18 0x0808ad6c in receive_msg ()
> #19 0x080bd2f2 in udp_rcv_loop ()
> #20 0x08069339 in main ()
>
>
> --
> Best Regards,
> Alex Massover
> VoIP R&D TL
> Jajah Inc.
>
>
>> -Original Message-
>> From: users-boun...@lists.opensips.org [mailto:users-
>> boun...@lists.opensips.org] On Behalf Of Andrei Dragus
>> Sent: Thursday, January 21, 2010 3:43 PM
>> To: OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] sched_yield()
>>
>> My guess is that there is not enough shared memory. When an allocation
>> failes OpenSIPS tries to defragment memory to make room which takes a
>> lot of time and must be done under lock.
>>
>> Please try to increase the shared memory size and tell me if it
>> persists.
>>
>>
>> Alex Massover wrote:
>>
>>> Hi!
>>>
>>> Yes, with -DF_MALLOC.
>>>
>>> 1.6.1 from sources, I build deb package.
>>> I use 128M of shared and 10*1024*1024 private memory (can increase -
>>>
>> no problem).
>>
>>> H, "opensipsctl fifo get_statistics all" crashes/stops the
>>>
>> opensips.
>>
>>> 'fifo uptime' or 'fifo debug' are OK.
>>>
>>> strace while 'fifo get_statistics all':
>>> Process 9509 attached - interrupt to quit
>>> pause() = ? ERESTARTNOHAND (To be
>>>
>> restarted)
>>
>>> --- SIGUSR2 (User defined signal 2) @ 0 (0) ---
>>> sigreturn() = ? (mask now [])
>>> pause() = ? ERESTARTNOHAND (To be
>>>
>> restarted)
>>
>>> --- SIGCHLD (Child exited) @ 0 (0) ---
>>> sigreturn() = ? (mask now [])
>>> waitpid(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGUSR2}], WNOHANG) =
>>>
>> 9520
>>
>>> waitpid(-1, 0xbf84b4c8, WNOHANG)= 0
>>> kill(0, SIGTERM)= 0
>>> --- SIGTERM (Terminated) @ 0 (0) ---
>>> --- SIGCHLD (Child exited) @ 0 (0) ---
>>> sigreturn() = ? (mask now [TERM])
>>> sigreturn() = ? (mask now [])
>>> rt_sigaction(SIGALRM, {0x806592
[OpenSIPS-Users] need help on dialplan module
Hi all could you please need me to understand the translation on dialplan module; mysql> select * from dialplan; ++--++--+---+---++--+---+ | id | dpid | pr | match_op | match_exp | match_len | subst_exp | repl_exp | attrs | ++--++--+---+---++--+---+ | 73 | 15 | 0 | 1 | ^000 | 0 | ^(0)(.+) | \2 | | | 78 | 16 | 0 | 1 | 000 | 0 | (000)(.+) | 8\2 | | | 76 | 14 | 0 | 1 | ^000 | 0 | ^(000)(.+) | 8\2 | | | 75 | 15 | 0 | 1 | ^55 | 0 | ^(55)(.+) | \2 | | ++--++--+---+---++--+---+ [r...@localhost ~]# opensipsctl fifo dp_translate 14 00055980007 Output:: 855980007 [r...@localhost ~]# opensipsctl fifo dp_translate 15 0007 Output:: 007 [r...@localhost ~]# opensipsctl fifo dp_translate 15 55980007 Output:: 980007 [r...@localhost ~]# opensipsctl fifo dp_translate 16 55980007 Output:: 87 repl_exp : sometimes has value \2 or \1 - what does it mean?? does it have other value? what does the ^ mean?? is there more special character?? where do i find more docs for translation rule Thank you Ha` ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] NAT helper : ping not sent
Hello,
I added the NAT helper module and added in my script the following line:
modparam("nathelper", "natping_interval", 30)
But I do not see 4 bytes (zero filled) UDP packets.
What could be wrong?
Thanks,
Yannick
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
users@lists.opensips.org
I found the solution and now i can hear my recorded files. -- View this message in context: http://n2.nabble.com/Query-regarding-Rtp-Proxy-opensips-tp4438620p4438875.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
