[SR-Users] Problem with "transport=tcp" and rtpproxy

Fri Feb 16 12:10:41 CET 2018

Sorry I don't have a deep knowledge in SIP protocol either how kamailio
works internally.

These are the invite messages:

T 88.15.197.56:34204 -> 146.185.142.19:9773 [AP]
INVITE sip:+34639446862 at 146.185.142.19:9773 SIP/2.0.
Via: SIP/2.0/TCP 88.15.197.56:34204
;rport;branch=z9hG4bKPj4778a63e-b3a1-4908-99b9-524161085409;alias.
Max-Forwards: 70.
From: sip:+3412345678910 at 146.185.142.19
;tag=9db4d38c-badb-41fe-8910-44857fb759c1.
To: sip:+34639446862 at 146.185.142.19.
Contact: <sip:+3412345678910 at 88.15.197.56:34204;transport=TCP;ob>.
Call-ID: 4c2fcd40-9b71-4dcf-b2dd-ee85318883f9.
CSeq: 32366 INVITE.
Route: <sip:146.185.142.19:9773;transport=tcp;lr>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Session-Expires: 1800.
Min-SE: 90.
Content-Type: application/sdp.
Content-Length:   473.
.
v=0.
o=- 3727764645 3727764645 IN IP4 192.168.1.35.
s=pjmedia.
b=AS:84.
t=0 0.
a=X-nat:0.
m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 96.
c=IN IP4 192.168.1.35.
b=TIAS:64000.
a=rtcp:4003 IN IP4 192.168.1.35.
a=sendrecv.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:99 speex/32000.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:9 G722/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-16.

#
T 146.185.142.19:9773 -> 88.15.197.56:34204 [AP]
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/TCP 88.15.197.56:34204
;rport=34204;branch=z9hG4bKPj4778a63e-b3a1-4908-99b9-524161085409;alias;received=88.15.197.56.
From: sip:+3412345678910 at 146.185.142.19
;tag=9db4d38c-badb-41fe-8910-44857fb759c1.
To: sip:+34639446862 at 146.185.142.19.
Call-ID: 4c2fcd40-9b71-4dcf-b2dd-ee85318883f9.
CSeq: 32366 INVITE.
Server: kamailio (4.3.4 (x86_64/linux)).
Content-Length: 0.
.

#
T 146.185.142.19:9773 -> 31.221.250.100:52775 [AP]
INVITE sip:+34639446862 at 31.221.250.100:52775;transport=TCP;ob SIP/2.0.
Record-Route: <sip:146.185.142.19:9773;transport=tcp;lr>.
Via: SIP/2.0/TCP 146.185.142.19:9773
;branch=z9hG4bK59dc.a677b7aceca06187ebd35e44c30f42a4.0;i=3.
Via: SIP/2.0/TCP 88.15.197.56:34204
;received=88.15.197.56;rport=34204;branch=z9hG4bKPj4778a63e-b3a1-4908-99b9-524161085409;alias.
Max-Forwards: 69.
From: sip:+3412345678910 at 146.185.142.19
;tag=9db4d38c-badb-41fe-8910-44857fb759c1.
To: sip:+34639446862 at 146.185.142.19.
Contact: <sip:+3412345678910 at 88.15.197.56:34204;transport=TCP;ob>.
Call-ID: 4c2fcd40-9b71-4dcf-b2dd-ee85318883f9.
CSeq: 32366 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Session-Expires: 1800.
Min-SE: 90.
Content-Type: application/sdp.
Content-Length:   473.
.
v=0.
o=- 3727764645 3727764645 IN IP4 192.168.1.35.
s=pjmedia.
b=AS:84.
t=0 0.
a=X-nat:0.
m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 96.
c=IN IP4 192.168.1.35.
b=TIAS:64000.
a=rtcp:4003 IN IP4 192.168.1.35.
a=sendrecv.
a=rtpmap:98 speex/16000.
a=rtpmap:97 speex/8000.
a=rtpmap:99 speex/32000.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:9 G722/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-16.

The Via and Contact both have the public ip, it's weird because I'm not
using STUN in clients.
The route and the record route are the sip domain with the transport tag.
 <sip:146.185.142.19:9773;transport=tcp;lr>.
So how it should be to be market as "natted" and be sent to rtpproxy?
Thanks for your patience.

2018-02-16 11:06 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:

> Wondering if you actually read properly my previous response. There is no
> "nat=yes" in Route params because the call (via initial INVITE) is not
> marked as natted -- look at what is sent to the network for the initial
> INVITE in the Record-Route header.
>
> Daniel
>
> On 16.02.18 10:45, Pau Giralt wrote:
>
> These are the complete logs for the previous call:
>
> [...]
>
>
> As you can see check_route_param(): params are <;transport=tcp;lr>
>
> 2018-02-15 18:16 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>
>> Based on the logs, there is no  check_route_param() executed. Actually,
>> it is an initial INVITE, doesn't have a to-tag, so there is no Route header
>> added previously by kamailio where check_route_param() can work on.
>>
>> Looking at the headers, this initial INVITE has Via and Contact with
>> public addresses (maybe UA is using stun), only the SDP seems to have
>> carrier grand nat address. You have to adjust the parameter for
>> nat_uac_test() in order to detect it is a natted call.
>>
>> Cheers,
>> Daniel
>>
>> On 15.02.18 15:35, Pau Giralt wrote:
>>
>> My kamailio version is:
>>
>> version: kamailio 4.4.6 (x86_64/linux) becbde
>> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE,
>> USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
>> TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
>> USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
>> HAVE_RESOLV_RES
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>> id: becbde
>> compiled on 08:18:45 Jul  3 2017 with gcc 5.4.0
>>
>>
>> I've pasted the logs below.
>>
>> ( ... )
>>
>> [...]
>>
>>
>> Thanks!
>>
>>
>> 2018-02-15 15:02 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com>:
>>
>>> Hello,
>>>
>>> first, what is the version of kamailio?
>>>
>>> Then, can you load debugger module and set cfgtrace=1, then send here
>>> all log messages for a case exposing this issue? It should show what
>>> actions are executed from config.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 15.02.18 12:08, Pau Giralt wrote:
>>>
>>> Hi!
>>>
>>> I'm working with kamailio and rtpproxy.
>>> When I configure the clients to send sip messages through TCP adding the
>>> ";transport=tcp" in the sip message the rtpproxy is not working anymore.
>>>
>>> The code is never passing the point pasted below, inside
>>> route[NATMANAGE] in kamailio.cfg
>>>
>>> if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return;
>>>
>>> Therefore, rtpproxy_manage("co"); is never reached.
>>>
>>> Could it be a parsing problem? ( check_route_param("nat=yes") )
>>>
>>> The config file is exactly the same as the one provided in the kamailio
>>> repository (the default one)
>>>
>>> Thanks!
>>>
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
>>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
>> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>>
>>
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180216/95493a1b/attachment.html>