[SR-Users] RTPPROXY timeout patch.
Carsten Bock
lists at bock.info
Wed Mar 23 09:18:51 CET 2011
Hi all,
by the way, the RTPProxy-Repository already contains a fix for this:
author sobomax <sobomax at 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 <razvancrainea at 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.abreu at redt.com.br>:
> Hi Carsten,
>
> Patch applied. It works now.
>
> Thanks,
> Alexandre.
>
> -----Mensagem original-----
> De: kaiserbock2 at googlemail.com [mailto:kaiserbock2 at 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 at 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 <lists at 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.abreu at 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.abreu at redt.com.br]
>>> Enviada em: quarta-feira, 16 de março de 2011 14:41
>>> Para: 'Carsten Bock'
>>> Cc: 'sr-users at lists.sip-router.org'
>>> Assunto: RES: RTPPROXY timeout patch.
>>>
>>> Carsten,
>>>
>>> Here it goes:
>>>
>>> [root at 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: kaiserbock2 at googlemail.com [mailto:kaiserbock2 at 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 at lists.sip-router.org
>>> Assunto: Re: RTPPROXY timeout patch.
>>>
>>> Hi Alexandre,
>>>
>>> My version of RTP-Proxy is following:
>>>
>>> bock at 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.abreu at 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 at 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 at 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 at devel ~]# md5sum rtpproxy-carsten.tar.gz
>>>> c02b1e2ac57d39562e86bcfc4ee592b8 rtpproxy-carsten.tar.gz
>>>>
>>>> Thanks,
>>>> Alexandre.
>>>>
>>>> -----Mensagem original-----
>>>> De: kaiserbock2 at googlemail.com [mailto:kaiserbock2 at 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 at 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 at 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 at 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 at localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c.
>>>> From: sip:1 at 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 at 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 at localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094.
>>>> From: sip:2 at 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.abreu at 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:carsten at ng-voice.com
>>
>
>
>
> --
> Carsten Bock
> http://www.ng-voice.com
> mailto:carsten at ng-voice.com
>
>
--
Carsten Bock
http://www.ng-voice.com
mailto:carsten at ng-voice.com
More information about the sr-users
mailing list