Hi all, by the way, the RTPProxy-Repository already contains a fix for this:
author sobomax <sobo...@sippysoft.com> Sun, 27 Feb 2011 03:26:31 +0000 (19:26 -0800) Move initialization of the notification thread after the rtpp_daemon() call. Threads started before fork(2) may not remain running afterwards. Reported by: Razvan Crainea <razvancrai...@opensips.org> http://sippy.git.sourceforge.net/git/gitweb.cgi?p=sippy/rtpproxy;a=commit;h=4b967a5602d8678c413e3699dda78c282a0018e5 So my patch is obsolete. Kind regards, Carsten 2011/3/22 Alexandre Abreu <alexandre.ab...@redt.com.br>: > Hi Carsten, > > Patch applied. It works now. > > Thanks, > Alexandre. > > -----Mensagem original----- > De: kaiserbo...@googlemail.com [mailto:kaiserbo...@googlemail.com] Em nome > de Carsten Bock > Enviada em: terça-feira, 22 de março de 2011 08:00 > Para: Alexandre Abreu > Cc: sr-users@lists.sip-router.org; RTPproxy Development > Assunto: Re: RTPPROXY timeout patch. > > Hi Alexandre, > > it took quite a lot of searching, but now it's done. It was a general > RTPProxy/PThread issue. > The problem seems to be, that the PThread is created before the fork > of the main process. Then the Thread waits forever... > > Attached an changed main.c + rtpp_defines.h which modifies this > behaviour and starts the Thread after the fork. > I will create an according patch and send it to the > RTPProxy-Dev-Mailinglist as well. > > Have fun, > Carsten > > > 2011/3/22 Carsten Bock <li...@bock.info>: >> Hi Alexandre, >> >> it seem to be a general RTP-Proxy/PThread issue. It seems not to be >> related to the XML-RPC notification; the thread, which processes the >> timeouts, seems to waits forever... I will check... >> >> Carsten >> >> 2011/3/21 Alexandre Abreu <alexandre.ab...@redt.com.br>: >>> Hi Carsten, >>> >>> After more testing, I just realized that the notification works only if I >>> use "-f" parameter in RTPPROXY. If I omit this parameter (to run in >>> background mode), the session timeout but there's no notification sent >>> (BYE). Why's that? >>> >>> Thanks, >>> Alexandre. >>> >>> -----Mensagem original----- >>> De: Alexandre Abreu [mailto:alexandre.ab...@redt.com.br] >>> Enviada em: quarta-feira, 16 de março de 2011 14:41 >>> Para: 'Carsten Bock' >>> Cc: 'sr-users@lists.sip-router.org' >>> Assunto: RES: RTPPROXY timeout patch. >>> >>> Carsten, >>> >>> Here it goes: >>> >>> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l > 192.168.200.90 >>> -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723 >>> INFO:main: rtpproxy started, pid 22495 >>> rtpproxy: >>> Running Timeout-Process >>> >>> DBUG:handle_command: received command "22428_8 Uc0,8,101 080b5d23d1603667 >>> 192.168.200.114 6380 0073852a;1" >>> INFO:handle_command: new session 080b5d23d1603667, tag 0073852a;1 > requested, >>> type strong >>> INFO:handle_command: new session on a port 48662 created, tag 0073852a;1 >>> INFO:handle_command: pre-filling caller's address with > 192.168.200.114:6380 >>> DBUG:doreply: sending reply "22428_8 48662 192.168.200.90" >>> DBUG:handle_command: received command "22436_8 Lc0,8,101 080b5d23d1603667 >>> 192.168.200.149 7614 0073852a;1 c758967a;1 >>> xmlrpc:http://127.0.0.1:8000/RPC2"; >>> INFO:handle_command: lookup on ports 48662/58604, session timer restarted >>> INFO:handle_command: setting custom timeout handler >>> (xmlrpc:http://127.0.0.1:8000/RPC2) >>> INFO:handle_command: pre-filling callee's address with > 192.168.200.149:7614 >>> DBUG:doreply: sending reply "22436_8 58604 192.168.200.90" >>> INFO:process_rtp: session timeout >>> INFO:remove_session: RTP stats: 982 in from callee, 4 in from caller, 986 >>> relayed, 0 dropped >>> INFO:remove_session: RTCP stats: 5 in from callee, 1 in from caller, 6 >>> relayed, 0 dropped >>> INFO:remove_session: session on ports 48662/58604 is cleaned up >>> ERR:do_timeout_notification: Timeout socket is: èîÈÄÐÊ@ÍÈÄÈÄ`ê >>> DBUG:reconnect_timeout_handler: reconnecting timeout socket >>> ERR:reconnect_timeout_handler: can't create timeout socket: Address > family >>> not supported by protocol >>> ERR:do_timeout_notification: unable to send timeout notification >>> >>> Very weird chars in the debug of what Timeout socket is... >>> >>> But the custom timeout handler are being printed correctly from the > config >>> file. >>> INFO:handle_command: setting custom timeout handler >>> (xmlrpc:http://127.0.0.1:8000/RPC2) >>> Here I am running CentOS 5.2 32-bit. >>> >>> Thanks, >>> Alexandre >>> >>> -----Mensagem original----- >>> De: kaiserbo...@googlemail.com [mailto:kaiserbo...@googlemail.com] Em > nome >>> de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 14:18 >>> Para: Alexandre Abreu >>> Cc: sr-users@lists.sip-router.org >>> Assunto: Re: RTPPROXY timeout patch. >>> >>> Hi Alexandre, >>> >>> My version of RTP-Proxy is following: >>> >>> bock@bock-tde:~/ims/rtpproxy$ ./rtpproxy -v Basic version: 20040107 >>> Extension 20050322: Support for multiple RTP streams and MOH Extension >>> 20060704: Support for extra parameter in the V command Extension > 20071116: >>> Support for RTP re-packetization Extension 20071218: Support for forking >>> (copying) RTP stream Extension 20080403: Support for RTP statistics > querying >>> Extension 20081102: Support for setting codecs in the update/lookup > command >>> Extension 20081224: Support for session timeout notifications Extension >>> 20090810: Support for automatic bridging Extension 20100819: Support for >>> timeout notifications using XML-RPC towards Kamailio/sip-router.org >>> >>> Please find attached a modified rtpp_notify.c file. I have just added > some >>> tiny debug output in order to see some points. >>> Now you should see the following Debug-Outputs: >>> >>> rtpproxy: >>> Running Timeout-Process >>> >>> Then the notifier process is running. That would be good. If not, that's > the >>> reason why it is not working. When the request comes in, you should see > the >>> following: >>> >>> INFO:handle_command: setting custom timeout handler >>> (xmlrpc:http://localhost:8000/RPC2) >>> >>> Then the Timeout-Socket was properly set, that would be good as well. >>> Now the timeout: >>> >>> INFO:process_rtp: session timeout >>> [...] >>> ERR:do_timeout_notification: Timeout socket is: >>> xmlrpc:http://localhost:8000/RPC2 >>> >>> That would be great, because then the Timeout towards the Kamailio should > be >>> triggerd. >>> If these parts are ok, then there must be some issue either in the > XML-RPC >>> client library or in the communication between the RTP-Proxy and > Kamailio. I >>> hope you did a trace on the XML-RPC Port both on the RTPproxy and on the >>> Kamailio? What distro are you using? My tests were only on Ubuntu and >>> Debian, which are quite similar. >>> >>> Hope we find this issue, >>> >>> Kind regards, >>> Carsten >>> >>> P.S.: I think i removed that check for the port for testing, that's why > my >>> version accepted the socket without port... (now i'm using "-n >>> tcp:127.0.0.1:9999") >>> >>> 2011/3/16 Alexandre Abreu <alexandre.ab...@redt.com.br>: >>>> Carsten, >>>> >>>> Indeed. Very strange. >>>> >>>> Are we running the same RTPPROXY version? How can you start using '-n >>>> tcp:127.0.0.1' without specifying a port? >>>> >>>> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l >>>> 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1 >>>> rtpproxy: can't parse host:port in TCP address >>>> rtpproxy: can't start notification thread >>>> >>>> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l >>>> 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723 >>>> INFO:main: rtpproxy started, pid 21169 >>>> >>>> DBUG:handle_command: received command "17828_9 Uc0,8,101 >>>> 4b10ce04de4f8818 >>>> 192.168.200.114 6380 9c4b6265;1" >>>> INFO:handle_command: new session 4b10ce04de4f8818, tag 9c4b6265;1 >>>> requested, type strong >>>> INFO:handle_command: new session on a port 43750 created, tag >>>> 9c4b6265;1 >>>> INFO:handle_command: pre-filling caller's address with >>>> 192.168.200.114:6380 >>>> DBUG:doreply: sending reply "17828_9 43750 192.168.200.90 " >>>> DBUG:handle_command: received command "17847_9 Lc0,8,101 >>>> 4b10ce04de4f8818 >>>> 192.168.200.149 7386 9c4b6265;1 dd69ab1d;1 >>>> xmlrpc:http://localhost:8000/RPC2"; >>>> INFO:handle_command: lookup on ports 43750/55796, session timer >>>> restarted >>>> INFO:handle_command: setting custom timeout handler >>>> (xmlrpc:http://localhost:8000/RPC2) >>>> INFO:handle_command: pre-filling callee's address with >>>> 192.168.200.149:7386 >>>> DBUG:doreply: sending reply "17847_9 55796 192.168.200.90 " >>>> INFO:process_rtp: session timeout >>>> INFO:remove_session: RTP stats: 548 in from callee, 5 in from caller, >>>> 553 relayed, 0 dropped >>>> INFO:remove_session: RTCP stats: 3 in from callee, 1 in from caller, 4 >>>> relayed, 0 dropped >>>> INFO:remove_session: session on ports 43750/55796 is cleaned up >>>> DBUG:reconnect_timeout_handler: reconnecting timeout socket >>>> ERR:reconnect_timeout_handler: can't create timeout socket: Address >>>> family not supported by protocol >>>> ERR:do_timeout_notification: unable to send timeout notification >>>> >>>> Above the error message. >>>> >>>> [root@devel ~]# md5sum rtpproxy-carsten.tar.gz >>>> c02b1e2ac57d39562e86bcfc4ee592b8 rtpproxy-carsten.tar.gz >>>> >>>> Thanks, >>>> Alexandre. >>>> >>>> -----Mensagem original----- >>>> De: kaiserbo...@googlemail.com [mailto:kaiserbo...@googlemail.com] Em >>>> nome de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 >>>> 13:03 >>>> Para: Alexandre Abreu >>>> Cc: sr-users@lists.sip-router.org >>>> Assunto: Re: RTPPROXY timeout patch. >>>> >>>> Hi Alexandre, >>>> >>>> That is strange: >>>> >>>> I run the RTP-Proxy like this (directly from the TAR-File, i sent you) >>>> and Kamailio with attached config-file. >>>> >>>> bock@bock-tde:~/ims/rtpproxy$ sudo ./rtpproxy -T 10 -f -F -i -l >>>> 127.0.0.1 -s udp:*:22222 -d DBUG -n tcp:127.0.0.1 >>>> rtpproxy: Timer started. >>>> INFO:main: rtpproxy started, pid 4203 >>>> [... Kamailio connects to RTP-Proxy...] >>>> DBUG:handle_command: received command "4259_8 >>>> UAc98,97,99,104,3,0,8,9,96 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 >>>> 195.71.4.203 4008 5371f039-40d0-4944-aae7-6f75071a2f8c;1" >>>> INFO:handle_command: new session 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5, >>>> tag 5371f039-40d0-4944-aae7-6f75071a2f8c;1 requested, type strong >>>> INFO:handle_command: new session on a port 45508 created, tag >>>> 5371f039-40d0-4944-aae7-6f75071a2f8c;1 >>>> INFO:handle_command: pre-filling caller's address with >>>> 195.71.4.203:4008 >>>> DBUG:doreply: sending reply "4259_8 45508 127.0.0.1 " >>>> DBUG:handle_command: received command "4259_9 LAc98,96 >>>> 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 195.71.4.203 4000 >>>> 5371f039-40d0-4944-aae7-6f75071a2f8c;1 >>>> 9915df0c-30fc-49c5-aa8a-c86b4242c094;1 >>>> xmlrpc:http://localhost:8000/RPC2"; >>>> INFO:handle_command: lookup on ports 45508/45238, session timer >>>> restarted >>>> INFO:handle_command: setting custom timeout handler >>>> (xmlrpc:http://localhost:8000/RPC2) >>>> INFO:handle_command: pre-filling callee's address with >>>> 195.71.4.203:4000 >>>> DBUG:doreply: sending reply "4259_9 45238 127.0.0.1 " >>>> INFO:process_rtp: session timeout >>>> ERR:rtpp_notify_schedule: XMLRPC xmlrpc:http://localhost:8000/RPC2 >>>> INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0 >>>> relayed, 0 dropped >>>> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0 >>>> relayed, 0 dropped >>>> INFO:remove_session: session on ports 45508/45238 is cleaned up >>>> ERR:do_timeout_notification: Timeout socket: >>>> xmlrpc:http://localhost:8000/RPC2 >>>> >>>> And it works for me: >>>> >>>> U 2011/03/16 16:50:14.350721 127.0.0.1:5060 -> 127.0.0.1:15061 BYE >>>> sip:2@127.0.0.1:15061;ob SIP/2.0. >>>> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.245e2dd7.0. >>>> To: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c. >>>> From: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094. >>>> CSeq: 7905 BYE. >>>> Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5. >>>> Content-Length: 0. >>>> User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)). >>>> Max-Forwards: 70. >>>> . >>>> >>>> U 2011/03/16 16:50:14.350801 127.0.0.1:5060 -> 127.0.0.1:15060 BYE >>>> sip:1@127.0.0.1:15060;transport=UDP;ob SIP/2.0. >>>> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.345e2dd7.0. >>>> To: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094. >>>> From: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c. >>>> CSeq: 7905 BYE. >>>> Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5. >>>> Content-Length: 0. >>>> User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)). >>>> Max-Forwards: 70. >>>> . >>>> [...] >>>> >>>> Maybe, you can add some more debug-info from RTP-Proxy... >>>> And can you verify, that the RTP-Proxy is not trying to send the > request? >>>> >>>> Kind regards, >>>> Carsten >>>> >>>> 2011/3/16 Alexandre Abreu <alexandre.ab...@redt.com.br>: >>>>> Hi Carsten, >>>>> >>>>> Even with your RTPPROXY tarball I was unable to get this working. >>>>> Session remains after RTPPROXY timeout. >>>>> I am using KAMAILIO 3.1 branch from GIT and as I told you, I moved >>>>> the rtpproxy/ from GIT-MASTER to the Kamailio branch (waiting your >>> backport). >>>> Is >>>>> there anything else regarding this feature that should also should be >>>> moved >>>>> (beyond rtpproxy/)? >>>>> >>>>> Thanks, >>>>> Alexandre >>> >>> >> >> >> >> -- >> Carsten Bock >> http://www.ng-voice.com >> mailto:cars...@ng-voice.com >> > > > > -- > Carsten Bock > http://www.ng-voice.com > mailto:cars...@ng-voice.com > > -- Carsten Bock http://www.ng-voice.com mailto:cars...@ng-voice.com _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
