[SR-Users] Kamailio does not add port number to addresses in Via, Record-Route headers

[George Diamantopoulos]

Hello again,

Indeed this issue does not manifest at all. I'm awfully sorry for the false
alarm, and on release day no less!

The problem was there was a lingering DNAT rule in iptables, which would
translate port 5066 to port 5060. The deployment script injected this as it
was carried over from our legacy platform.

Of course, I kept banging my head against the wall here because sngrep
wouldn't show the DNAT's effect as it captures traffic from the NIC
directly: it would show a REGISTER arriving on 5066, but the dport was
masqueraded before being handed over to kamailio. Similarly for the
outgoing INVITE.

NAT is wrong in so many ways... :-)

BR,
George

On 11 December 2017 at 18:17, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> I did a quick test and all looks fine, ports are set in via and
> record-route, in my config I have:
>
>     record_route();
>
>     $fs="udp:127.0.0.1:5080";
>     $du = "sip:127.0.0.1:9";
>     t_relay();
>     exit;
>
> Then sending an OPTIONS resulted in the trace shown below.
>
> Cheers,
> Daniel
>
> U 2017/12/11 17:14:47.108430 127.0.0.1:56729 -> 127.0.0.1:5060
> OPTIONS sip:test at 127.0.0.1 SIP/2.0.
> Via: SIP/2.0/UDP 192.168.178.84:62516;branch=z9hG4bK.3aaddf68;rport;alias.
> From: sip:sipsak at 192.168.178.84:62516;tag=16d1c24.
> To: sip:test at 127.0.0.1.
> Call-ID: 23927844 at 192.168.178.84.
> CSeq: 1 OPTIONS.
> Contact: sip:sipsak at 192.168.178.84:62516.
> Content-Length: 0.
> Max-Forwards: 70.
> User-Agent: sipsak 0.9.7pre.
> Accept: text/plain.
> .
>
>
> U 2017/12/11 17:14:51.010251 127.0.0.1:5080 -> 127.0.0.1:9
> OPTIONS sip:test at 127.0.0.1 SIP/2.0.
> Record-Route: <sip:127.0.0.1:5080;r2=on;lr>.
> Record-Route: <sip:127.0.0.1;r2=on;lr>.
> Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK61bd.
> b2882fea15c488761489f8ef588efbe1.0.
> Via: SIP/2.0/UDP 192.168.178.84:62516;received=127.0.0.1;branch=z9hG4bK.
> 3aaddf68;rport=56729;alias.
> From: sip:sipsak at 192.168.178.84:62516;tag=16d1c24.
> To: sip:test at 127.0.0.1.
> Call-ID: 23927844 at 192.168.178.84.
> CSeq: 1 OPTIONS.
> Contact: sip:sipsak at 192.168.178.84:62516.
> Content-Length: 0.
> Max-Forwards: 69.
> User-Agent: sipsak 0.9.7pre.
> Accept: text/plain.
> .
>
> On 11.12.17 16:37, George Diamantopoulos wrote:
>
> Hello all,
>
> I have the following issue in my configuration, tested with 5.2.0-rc1 so
> far:
>
> At some point, I set the $fs pseudovariable to force a request to be
> relayed through a specific socket. Although this is honoured by kamailio
> (i.e. the request does indeed leave the kamailio host from the respective
> socket), the port number is not added to the Via and RR headers. As a
> result, all replies to the request, as well as all subsequent requests from
> the other SIP UA are relayed to the default port, 5060. Here's an example:
>
> SIP UAC to kamailio:
> INVITE 192.168.1.1:5060 ---> 192.168.1.254:5060
> Kamailio to UAS ($fs is set):
> INVITE 2.2.2.2:5066 ---> 3.3.3.3:5060
> Topmost Via in request relayed by kamailio is:
> SIP/2.0/UDP 2.2.2.2;branch=aaaaaaaaaaaaaa    <- port 5066 is not added
> Topmost RR in request relayed by kamailio is:
> <sip:2.2.2.2;r2=on;lr;did=bbbbbbb;nat=yes>    <- port 5066 is not added
> RESULT: Reply from UAS is sent to 2.2.2.2:5060
>
> Is this behaviour valid? Am I missing anything? Kamailio is configured to
> listen on both sockets on IP 2.2.2.2, namely: a) udp:2.2.2.2:5060 and b)
> 2.2.2.2:5066. Thanks.
>
> BR,
> George
>
>
> _______________________________________________
> 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 - 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/20171212/f0ecf8f6/attachment.html>