[OpenSIPS-Users] Opensips + RtpProxy: media stream timed out while starting

Sat Feb 14 05:58:30 CET 2015

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150214/7bf4fb4f/attachment-0001.htm>
-------------- 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/20150214/7bf4fb4f/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/20150214/7bf4fb4f/attachment-0004.png>
-------------- 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/20150214/7bf4fb4f/attachment-0005.png>