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@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@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@192.168.178.84:62516;tag=16d1c24.
To: sip:test@127.0.0.1.
Call-ID: 23927844@192.168.178.84.
CSeq: 1 OPTIONS.
Contact: sip:sipsak@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@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@192.168.178.84:62516;tag=16d1c24.
To: sip:test@127.0.0.1.
Call-ID: 23927844@192.168.178.84.
CSeq: 1 OPTIONS.
Contact: sip:sipsak@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:
Kamailio to UAS ($fs is set):
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 List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com