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: 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
OK -- good it was sorted out.
Cheers, Daniel
On 12.12.17 02:22, George Diamantopoulos wrote:
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 mailto: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 <http://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 <http://127.0.0.1:56729> -> 127.0.0.1:5060 <http://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 <mailto: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 <http://127.0.0.1:5080> -> 127.0.0.1:9 <http://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 <mailto: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: INVITE 192.168.1.1:5060 <http://192.168.1.1:5060> ---> 192.168.1.254:5060 <http://192.168.1.254:5060> Kamailio to UAS ($fs is set): INVITE 2.2.2.2:5066 <http://2.2.2.2:5066> ---> 3.3.3.3:5060 <http://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 <http://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 <http://2.2.2.2:5060> and b) 2.2.2.2:5066 <http://2.2.2.2:5066>. Thanks. BR, George _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
-- Daniel-Constantin Mierla www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Kamailio Advanced Training - www.asipto.com <http://www.asipto.com> Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com <http://www.kamailioworld.com>
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users