[OpenSIPS-Users] UDP to TCP issue with Re-INVITE

Wed Dec 18 10:00:20 EST 2019

Hi all,
I make a lot of others tests.
I have a new opensips with very simple conf.

Asterisk (tcp:192.168.10.204:8060) --> OpenSIPS (tcp:192.168.10.203:8060)
--> Public SBC

With the scenario, All calls work like a charm (Re-invite from public SBC
is forwarded to asterisk correctly).
OpenSIPS add Record-route headers and Via

INVITE from OpenSIPS to Public SBC:

INVITE sip:192.168.10.203:8060 SIP/2.0
Record-Route: <sip:192.168.10.203;transport=tcp;r2=on;lr;did=e0c.7aea7b33>
Record-Route: <sip:192.168.10.203:8060
;transport=tcp;r2=on;lr;did=e0c.7aea7b33>
Via: SIP/2.0/TCP 192.168.10.203:5060
;branch=z9hG4bK1fe7.4d994257.0;i=75d41696
Via: SIP/2.0/TCP 192.168.10.204:8060;branch=z9hG4bKmc2Kt5HeH7HrD
Max-Forwards: 69
From: <sip:192.168.10.204:8060>;tag=a2833Nt0cX4Xc
To: <sip:192.168.10.203:8060>
Call-ID: a9d81adc-9c40-1238-5cac-080027ea7403
CSeq: 946412450 INVITE
Contact: <sip:192.168.10.204:8060;transport=tcp>
User-Agent: UniMRCP SofiaSIP 1.6.0
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
Supported: eventlist
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 401

When I activate topology hiding on this OpenSIPS, It don't add record-route
header and via

Asterisk (tcp:192.168.10.204:8060) --> OpenSIPS (tcp:192.168.10.203:8060
with Topology Hinding) --> Public SBC

INVITE from OpenSIPS to Public SBC:

INVITE sip:192.168.10.203:8060 SIP/2.0
Via: SIP/2.0/TCP 192.168.10.203:5060
;branch=z9hG4bK3945.b919d255.0;i=6ed14877
Max-Forwards: 69
From: <sip:192.168.10.204:8060>;tag=gr0rerZNUjaej
To: <sip:192.168.10.203:8060>
Call-ID: 362650cb-9c47-1238-5cac-080027ea7403
CSeq: 946412456 INVITE
Contact: <sip:192.168.10.203;transport=tcp;did=6b1.179a1cb1>
User-Agent: UniMRCP SofiaSIP 1.6.0
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
Supported: eventlist
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 402

And with topology hiding activate, the Re-Invite from UAS (public SBC)
isn't forwarded to asterisk !
Idem, with topology hiding, a BYE from UAS (public SBC) isn't forwarded too.

Is there a bug or misconfiguration for topology hiding module ?

thanks in advance

Le mar. 17 déc. 2019 à 11:09, Mickael Hubert <mickael at winlux.fr> a écrit :

> Sure !
> You can find it here  (it's jinja2 template, but it readable ;) ) :
> https://github.com/Mickaelh51/opensips-tcp-issue/blob/master/micka_opensips_conf.txt
> There is only the routing process in this file. Feel free to ask me if you
> want other parts of my conf.
>
> ++
>
> Le lun. 16 déc. 2019 à 21:04, David Villasmil <
> david.villasmil.work at gmail.com> a écrit :
>
>> Can we see your cfg ?
>>
>> On Mon, 16 Dec 2019 at 16:44, Mickael Hubert <mickael at winlux.fr> wrote:
>>
>>> Thanks for your help David,
>>> I'm already in debug level:
>>> log_level=4
>>>
>>> UAC is not in location table, because it's IP2IP connection (without
>>> registration)
>>>
>>> I did another test:
>>> I try to activate "Pp" in dialog creation to send OPTIONS to both sides
>>> (leg A and B)
>>> SIP client (tcp:192.168.10.203) -- my NAT router --> (tcp:2.2.2.2:8060)
>>> opensips (udp:10.1.15.126:5060) --> rest of infra (udp:10.1.15.0/24:5060
>>> )
>>>
>>> OPTIONS from private interface is sent, but OPTIONS from public
>>> interface can't be sent to natted UAC:
>>>
>>> Dec 16 16:52:22 am-frontal1a-test /usr/local/sbin/opensips[2705]:
>>> ERROR:tm:msg_send: send() to 192.168.10.203:5060 for proto tcp/2 failed
>>> Dec 16 16:52:22 am-frontal1a-test /usr/local/sbin/opensips[2705]:
>>> ERROR:tm:t_uac: attempt to send to
>>> 'sip:192.168.10.203;transport=tcp;r2=on;lr;did=d9.ed83b676' failed
>>> Dec 16 16:52:43 am-frontal1a-test /usr/local/sbin/opensips[2693]:
>>> ERROR:tm:msg_send: send() to 192.168.10.203:5060 for proto tcp/2 failed
>>> Dec 16 16:52:43 am-frontal1a-test /usr/local/sbin/opensips[2693]:
>>> ERROR:tm:t_uac: attempt to send to
>>> 'sip:192.168.10.203;transport=tcp;r2=on;lr;did=d9.ed83b676' failed
>>>
>>> My other test (into VPN) works like a charm, but UAC is registered !
>>>
>>> Is there a way to keep natted source ip and port to reuse them with
>>> initial request from UAS ?
>>> I use topology_hiding function, and it's not compatible with
>>> record_route. But I tested to deactive TH and active RR, it's exactly the
>>> same issue, the Re-INVITE from UAS is not forwarded to UAC.
>>>
>>> thanks
>>>
>>> Le lun. 16 déc. 2019 à 15:52, David Villasmil <
>>> david.villasmil.work at gmail.com> a écrit :
>>>
>>>> please increase the debug level and paste the log. Also, check what is
>>>> saved as the location for the user.
>>>>
>>>> On Mon, 16 Dec 2019 at 14:48, Mickael Hubert <mickael at winlux.fr> wrote:
>>>>
>>>>> Maybe I founded:
>>>>> I tested a call through Internet connection and I can see (uac natted):
>>>>>
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:proto_tcp_send: *no open tcp connection found*, opening new
>>>>> one, async = 1
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:probe_max_sock_buff: getsockopt: snd is initially 16384
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 11
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:tcpconn_async_connect: Polling is overdue
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:tcpconn_async_connect: Create connection for async connect
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:print_ip: tcpconn_new: new tcp connection to: 192.168.10.203
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:tcpconn_new: on port 5060, proto 2
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:proto_tcp_send: Successfully connected from interface
>>>>> 192.168.10.203:5060 to 192.168.10.203:56899!
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:proto_tcp_send: Successfully started async connection
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:tm:insert_timer_unsafe: [0]: 0x7efe91196790 (99)
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:tm:t_relay_to: new transaction fwd'ed
>>>>> Dec 16 15:15:44 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> retcode = 1
>>>>>
>>>>> The re-invite is never forwarded (no trace with sngrep, or classic
>>>>> tcpdump)
>>>>> I don't know why opensips wants use private IP and not natted IP...
>>>>> So...
>>>>>
>>>>> I tested through VPN connection (uac natted):
>>>>>
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:tcp_conn_get: *tcp connection found* (0x7efe9118cf48),
>>>>> acquiring fd
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:tcp_conn_get: c= 0x7efe9118cf48, n=16, Usock=168
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31187]:
>>>>> DBG:core:handle_worker: read response= 7efe9118cf48, 1, fd -1 from 35
>>>>> (31165)
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:tcp_conn_get: after receive_fd: c= 0x7efe9118cf48 n=8 fd=11
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:proto_tcp_send: sending via fd 11...
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:async_tsend_stream: Async successful write from first try on
>>>>> 0x7efe9118cf48
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:core:proto_tcp_send: after write: c= 0x7efe9118cf48 n/len=1014/1014
>>>>> fd=11
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:tm:insert_timer_unsafe: [0]: 0x7efe91196790 (1403)
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> DBG:tm:t_relay_to: new transaction fwd'ed
>>>>> Dec 16 15:37:28 am-frontal1a-test /usr/local/sbin/opensips[31165]:
>>>>> retcode = 1
>>>>>
>>>>> The re-inivte is forwarded correctly !
>>>>>
>>>>> I pretty sure I use the keepalived mecasim ....
>>>>>
>>>>>
>>>>> Le lun. 16 déc. 2019 à 14:27, Mickael Hubert <mickael at winlux.fr> a
>>>>> écrit :
>>>>>
>>>>>> Hi David,
>>>>>> Yes I use it
>>>>>>
>>>>>> if (nat_uac_test("3") && ($Ri == $var(publicip) || $Ri == $var(vpnip)
>>>>>> ))
>>>>>> {
>>>>>> xlog("L_INFO","$avp(startlog) -- Nated EP Detected\n");
>>>>>> if (force_rport())
>>>>>> {
>>>>>> xlog("L_INFO","$avp(startlog) -- RPORT parameter forced\n");
>>>>>> }
>>>>>> if (fix_nated_contact())
>>>>>> {
>>>>>> xlog("L_INFO","$avp(startlog) -- Nated $rm's Contact Fixed !\n");
>>>>>> }
>>>>>> if (fix_nated_sdp("10"))
>>>>>> {
>>>>>> xlog("L_INFO","$avp(startlog) -- Nated SDP Fixed for $rm\n");
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Le lun. 16 déc. 2019 à 13:50, David Villasmil <
>>>>>> david.villasmil.work at gmail.com> a écrit :
>>>>>>
>>>>>>> Aré you using nathelper?
>>>>>>>
>>>>>>> On Mon, 16 Dec 2019 at 12:06, Mickael Hubert <mickael at winlux.fr>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> I advanced in my LAB
>>>>>>>> I have this configuration:
>>>>>>>> SIP client (tcp:192.168.10.203) -- my NAT router --> (tcp:
>>>>>>>> 2.2.2.2:8060) opensips (udp:10.1.15.126:5060) --> rest of infra
>>>>>>>> (udp:10.1.15.0/24:5060)
>>>>>>>>
>>>>>>>> When I received the reinvite from "rest of infra" on private
>>>>>>>> interface (10.1.15.126), I could see this log:
>>>>>>>>
>>>>>>>> Dec 16 12:55:27 am-frontal1a-test /usr/local/sbin/opensips[26160]:
>>>>>>>> ERROR:tm:msg_send: send() to 192.168.10.203:5060 for proto tcp/2
>>>>>>>> failed
>>>>>>>> Dec 16 12:55:27 am-frontal1a-test /usr/local/sbin/opensips[26160]:
>>>>>>>> ERROR:tm:t_forward_nonack: sending request failed
>>>>>>>> Dec 16 12:55:27 am-frontal1a-test /usr/local/sbin/opensips[26160]:
>>>>>>>> retcode = -6
>>>>>>>>
>>>>>>>> I don't know why OpenSIPS tries to send the Re-invite to client
>>>>>>>> private IP instead client public port and IP (natted).
>>>>>>>>
>>>>>>>> Do you have an idea please ?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> Le jeu. 12 déc. 2019 à 11:09, Mickael Hubert <mickael at winlux.fr> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>> I have an issue, opensips doesn't want forward Re-INVITE during
>>>>>>>>> UDP to TCP mapping session.
>>>>>>>>> Customer (NATTED) -- TCP --> (public interface listen tcp:8060)
>>>>>>>>> OpenSIPS (private interface listen udp:5060) --> rest of infrastructure
>>>>>>>>> (udp:5060)
>>>>>>>>>
>>>>>>>>> I can send a call from customer to OpenSIPS (initial INVITE,
>>>>>>>>> 200OK, etc ...).
>>>>>>>>> But when I received Re-INVITE from UAS (sip session timer),
>>>>>>>>> OpenSIPS doesn't forward it to customer.
>>>>>>>>>
>>>>>>>>> You can see the call flow here:
>>>>>>>>> https://photos.app.goo.gl/eUSb5MvBhUfueaoM7
>>>>>>>>> You can see SIP messages and opensips's logs in txt file in
>>>>>>>>> attachment
>>>>>>>>>
>>>>>>>>> OpenSIPS handles on it's public interface:
>>>>>>>>> - Topology hiding
>>>>>>>>> - Nat detection
>>>>>>>>>
>>>>>>>>> Thanks a lot for you help !
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at lists.opensips.org
>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>>
>>>>>>> David Villasmil
>>>>>>> email: david.villasmil.work at gmail.com
>>>>>>> phone: +34669448337
>>>>>>> _______________________________________________
>>>>>>> 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,
>>>>
>>>> David Villasmil
>>>> email: david.villasmil.work at gmail.com
>>>> phone: +34669448337
>>>> _______________________________________________
>>>> 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,
>>
>> David Villasmil
>> email: david.villasmil.work at gmail.com
>> phone: +34669448337
>> _______________________________________________
>> 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/20191218/9ca7018d/attachment-0001.html>