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(a)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(a)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(a)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:
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@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