[OpenSIPS-Users] Opensips + RtpProxy: media stream timed out while starting
Semen Golubcov
thegolub4 at gmail.com
Sun Feb 15 00:36:59 CET 2015
Hello John. I fixed this part, but i still get same behaviour as in
previous try. Caller softphone is hanging on "Connecting" and the Calle is
disconnected on the time out, no media channel get's created
2015-02-14 8:12 GMT+02:00 John Mathew <john.mathew at divoxmedia.com>:
> Hi,
>
> Typo from my end.
>
> make it
>
> append_hf("Contact: <bob at xx.xx.xx.xx:5061;transport=tls>\r\n");
>
> On Sat, Feb 14, 2015 at 11:32 AM, Semen Golubcov <thegolub4 at gmail.com>
> wrote:
>
>> I just tried to modify my onreply route with remove/append hf, it didn't
>> help. The call is now hanging on 'connecting' state in alex softphone and
>> the media channel is not established . And bob get's the same timed out
>> eror.
>>
>> here is route:
>>
>> onreply_route[handle_nat] {
>> remove_hf("Contact:");
>> append_hf("Contact: <bob at xx.xx.xx.xx:5061>;transport=tls>\r\n");
>> if (nat_uac_test("1"))
>> fix_nated_contact();
>> if ( isflagset(NAT) )
>> rtpproxy_answer("ro");
>> xlog("incoming reply\n");
>> }
>>
>>
>> 2015-02-14 6:58 GMT+02:00 John Mathew <john.mathew at divoxmedia.com>:
>>
>>> Semen,
>>>
>>> After looking into the issue, i think you are not using TLS transport in
>>> your onreply_route function. On reply function still sending messages to
>>> alex on udp, which is been rejected by alex and waiting for reply on tls.
>>> Here alex is missing 200Ok.
>>>
>>> You have to make sure you are sending the right contact header to the
>>> A-Party with transport=tls.
>>>
>>> Try rewriting your contact header from bob by
>>> remove_hf("Contact:");
>>> append_hf("Contact: <bob at opensipsIP:port>;transport=tls>\r\n");
>>>
>>>
>>>
>>>
>>> On Sat, Feb 14, 2015 at 9:37 AM, Semen Golubcov <thegolub4 at gmail.com>
>>> wrote:
>>>
>>>> Hello. Here is the result of the ifconfig eth0 | grep 'inet':
>>>>
>>>> inet addr:190.32.5.8 Bcast:190.32.5.255 Mask:255.255.255.0
>>>> inet6 addr: (my_ipv6):5990/64 Scope:Link
>>>>
>>>> My server is basically a virtual dedicated server, i think you are
>>>> right about my network scenario.
>>>> I looked up the patch, and re-checked the rtpproxy source from git, it
>>>> loooks like it is ok with supporting -A option. I ran the proxy like so:
>>>>
>>>> sudo rtpproxy -d DBUG:LOG_LOCAL5 -f -s udp:localhost:12221 -u
>>>> rtpproxy:rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -A 185.48.5.9 -m 16384
>>>> -M 32768
>>>>
>>>> And the same problem still remains, here is the debug output:
>>>>
>>>> DBUG:get_command:GLOBAL: received command "3165_12 Lc113,101
>>>> b45b04f432f140b1bca5bf048d035871 10.10.10.108 50937
>>>> 6217f250d0f8490f9cbe4b37059cf82a;1 89c29c90c08940d8b7e155978a1d0fbb;1"
>>>> INFO:rtpp_command_ul_handle:b45b04f432f140b1bca5bf048d035871: lookup on
>>>> ports 26094/21578, session timer restarted
>>>> INFO:rtpp_command_ul_handle:b45b04f432f140b1bca5bf048d035871:
>>>> pre-filling callee's address with 10.10.10.108:50937
>>>> DBUG:rtpc_doreply:GLOBAL: sending reply "21578
>>>> "
>>>> INFO:rxmit_packets:b45b04f432f140b1bca5bf048d035871: callee's address
>>>> filled in: 152.xx.xx.xx:50937 (RTP)
>>>> INFO:rxmit_packets:b45b04f432f140b1bca5bf048d035871: guessing RTCP port
>>>> for callee to be 50938
>>>> INFO:rxmit_packets:b45b04f432f140b1bca5bf048d035871: callee's address
>>>> filled in: 152.xx.xx.xx:50941 (RTCP)
>>>> INFO:rxmit_packets:b45b04f432f140b1bca5bf048d035871: caller's address
>>>> filled in: 152.xx.xx.xx:50921 (RTP)
>>>> INFO:rxmit_packets:b45b04f432f140b1bca5bf048d035871: guessing RTCP port
>>>> for caller to be 50922
>>>> INFO:rxmit_packets:b45b04f432f140b1bca5bf048d035871: caller's address
>>>> filled in: 152.xx.xx.xx:50925 (RTCP)
>>>> INFO:process_rtp:4758975202dd42c194b3ece85af6feea: session timeout
>>>> INFO:remove_session:4758975202dd42c194b3ece85af6feea: RTP stats: 250 in
>>>> from callee, 241 in from caller, 491 relayed, 0 dropped
>>>> INFO:remove_session:4758975202dd42c194b3ece85af6feea: RTCP stats: 4 in
>>>> from callee, 5 in from caller, 9 relayed, 0 dropped
>>>> INFO:remove_session:4758975202dd42c194b3ece85af6feea: session on ports
>>>> 22646/17854 is cleaned up
>>>>
>>>> I guess now that it's some sort of ACK packet issue on opensips side (
>>>> only using tls , using the udp,tcp evrything works fine).
>>>>
>>>>
>>>> 2015-02-14 4:38 GMT+02:00 Babil <gsbabil at gmail.com>:
>>>>
>>>>> Hi Semen,
>>>>> what is your network configuration? If the RTP-Proxy machine is an
>>>>> Amazon EC-2 (or alike) instance where an "elastic" public IP is
>>>>> attached
>>>>> to the Ethernet interface which has a different internal DHCP provided
>>>>> address (or you have a port-forwarding scenario), you'd need to use a
>>>>> patched version of RTP-Proxy.
>>>>>
>>>>> The RTP-Proxy patch, as shown here [0], will allow you to have an
>>>>> additional '-A' option to modify the advertised IP address (external
>>>>> publicly visible IP address) by RTP-Proxy which should resolve the
>>>>> timeout issues you are experiencing. This version [1] on Github also
>>>>> seems to have the patch integrated. You'll find a longer discussion on
>>>>> the RTP-Proxy and NAT problem here [2].
>>>>>
>>>>> Hope this helps. Good luck.
>>>>>
>>>>> P.S.
>>>>> In order to check your network address dissimilarities, you may try the
>>>>> following commands. I'm considering your external interface is `eth0`:
>>>>>
>>>>> ```
>>>>> ifconfig eth0 | grep 'inet'
>>>>> ## or,
>>>>> #ip addr show dev eth0 | grep 'inet'
>>>>> ## followed by
>>>>> curl 'ipinfo.io/ip'
>>>>> ```
>>>>>
>>>>> You may run RTP-Proxy as:
>>>>>
>>>>> ```
>>>>> sudo rtpproxy -d DBUG:LOG_LOCAL5 -f -s udp:127.0.0.1:12221 -u
>>>>> rtpproxy:rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -A 54.111.222.123
>>>>> -l
>>>>> 10.0.0.2 -m 16384 -M 32768
>>>>> ```
>>>>>
>>>>> [0] http://bit.ly/1KUS9bx
>>>>> [1] https://github.com/sippy/rtpproxy
>>>>> [2] http://bit.ly/1CpQXe9
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Babil (Golam Sarwar)
>>>>>
>>>>> PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D
>>>>> PGP Key Download URL: http://bit.ly/gsbabil-pgp-key
>>>>>
>>>>> Regards,
>>>>> Babil (Golam Sarwar)
>>>>>
>>>>> PGP Key Fingerprint : D3A1 EED0 5BA0 72D3 A011 75CB 8EA6 7D99 F433 E92D
>>>>> PGP Key Download URL: http://bit.ly/gsbabil-pgp-key
>>>>>
>>>>> On Fri, Feb 13, 2015 at 10:27 AM, Semen Golubcov <thegolub4 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello! I'm using the latest opensips with latest rtpproxy :
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> i did setup the secure tls connection between clients in the
>>>>>> opensips, it uses the client certificate verification. But the interaction
>>>>>> with rtpproxy is getting messed up somehow. I'm using the blink softphone
>>>>>> to test on. So i have 2 accounts: bob and alex. When i do *call*
>>>>>> *bob* *from* *alex* i get this kind of behaviour in the *bob's
>>>>>> softphone*:
>>>>>>
>>>>>> So it hangs on "starting media", but in the same time the actual
>>>>>> connection is established, me and my partner can hear each other and we can
>>>>>> talk perfectly, so i assume the actual stream is allright. It hangs for
>>>>>> exactly 15 seconds then we get:
>>>>>>
>>>>>>
>>>>>>
>>>>>> *"media stream timed out while starting" in the bob's softphone*.
>>>>>>
>>>>>> *On the alex softphone side*:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "call ended by remote".
>>>>>>
>>>>>> The icon indicating that rtp stream is encrypted is not shown on
>>>>>> bob's side, but the stream is working. I tried to disable tls, and use
>>>>>> plain tcp, and it's working fine without tls, call is not getting stuck and
>>>>>> automatically terminate.
>>>>>>
>>>>>> My rtpproxy is running like so:
>>>>>>
>>>>>> rtpproxy -u rtpproxy -s udp:localhost:12221
>>>>>>
>>>>>> And my opensips config is generated by osipconfig utility (i didn't
>>>>>> modify the routes at all) see attached opensips.cfg
>>>>>>
>>>>>> I looked up the syslog for rtpproxy entries, apparently there is no
>>>>>> entries from rtpproxy or opensips with any error, other than
>>>>>>
>>>>>> Feb 13 04:00:24 user /usr/local/sbin/opensips[17535]:
>>>>>> ERROR:rtpproxy:force_rtp_proxy: Unable to parse body
>>>>>>
>>>>>> Feb 13 04:00:22 user /usr/local/sbin/opensips[17535]:
>>>>>> DBG:tm:matching_3261: RFC3261 transaction matching failed
>>>>>> I hope someone can help me to solve this problem, i'am hanging on
>>>>>> this for a week. If necessary i can post the syslog and blink softphone
>>>>>> sip traces, of our test conversation. Maybe the problem is with ACK?
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>> John Mathew
>>> CEO/Director
>>> Divox International Inc.
>>> Contact: +91-9037100001
>>> Email/MSN: John.Mathew at divoxmedia.com
>>> WEB: www.divoxmedia.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
>
> Regards,
> John Mathew
> CEO/Director
> Divox International Inc.
> Contact: +91-9037100001
> Email/MSN: John.Mathew at divoxmedia.com
> WEB: www.divoxmedia.com
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150215/f133b8c7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen_result_1.png
Type: image/png
Size: 2239 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20150215/f133b8c7/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen3.png
Type: image/png
Size: 3614 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20150215/f133b8c7/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screen_result_2.png
Type: image/png
Size: 3112 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20150215/f133b8c7/attachment-0005.png>
More information about the Users
mailing list