Did you try this?
Add this in route[relay].
remove_hf("Contact:");
append_hf("Contact: <[email protected]:5061;transport=tls>\r\n");
and in onreply_route[handle_nat].
remove_hf("Contact:");
append_hf("Contact: <[email protected]:5061;transport=tls>\r\n");
On Sun, Feb 15, 2015 at 5:08 AM, Semen Golubcov <[email protected]> wrote:
> Full route now is like this:
>
> onreply_route[handle_nat] {
> remove_hf("Contact:");
> append_hf("Contact: <[email protected]: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 8:12 GMT+02:00 John Mathew <[email protected]>:
>
>> Hi,
>>
>> Typo from my end.
>>
>> make it
>>
>> append_hf("Contact: <[email protected]:5061;transport=tls>\r\n");
>>
>> On Sat, Feb 14, 2015 at 11:32 AM, Semen Golubcov <[email protected]>
>> 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: <[email protected]: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 <[email protected]>:
>>>
>>>> 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@opensipsIP:port>;transport=tls>\r\n");
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Feb 14, 2015 at 9:37 AM, Semen Golubcov <[email protected]>
>>>> 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 <[email protected]>:
>>>>>
>>>>>> 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 <[email protected]
>>>>>> > 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
>>>>>>> [email protected]
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> [email protected]
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> [email protected]
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Regards,
>>>> John Mathew
>>>> CEO/Director
>>>> Divox International Inc.
>>>> Contact: +91-9037100001
>>>> Email/MSN: [email protected]
>>>> WEB: www.divoxmedia.com
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [email protected]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [email protected]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> --
>>
>> Regards,
>> John Mathew
>> CEO/Director
>> Divox International Inc.
>> Contact: +91-9037100001
>> Email/MSN: [email protected]
>> WEB: www.divoxmedia.com
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> [email protected]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
--
Regards,
John Mathew
CEO/Director
Divox International Inc.
Contact: +91-9037100001
Email/MSN: [email protected]
WEB: www.divoxmedia.com
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
