Hello,
our kamailio used for sip trunk interconnections is behind NAT and our cloud provider opens random outgoing ports for outbound connections. Our record-route is set to our external address and port 5060, that is probably incorrect, but we did not had any issues. One of our partners suddenly begin sending BYEs to the port advertised in record-route instead of port from where he received call.
What is a correct approach here if we are not able to determine open port behind NAT?
Bye, Michal
Hello,
so it looks like kamailio used random port for opening connections to our partners but did not updates record-route port properly. AWS has symmetric NAT and that works fine.
Is there any way how to identify port and rewrite record-route?
Thanks.
Bye, Michal
On 7 May 2020, at 17:25, Michal Popovic michal.popovic@cloudtalk.io wrote:
Hello,
our kamailio used for sip trunk interconnections is behind NAT and our cloud provider opens random outgoing ports for outbound connections. Our record-route is set to our external address and port 5060, that is probably incorrect, but we did not had any issues. One of our partners suddenly begin sending BYEs to the port advertised in record-route instead of port from where he received call.
What is a correct approach here if we are not able to determine open port behind NAT?
Bye, Michal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
the nature of tcp protocol makes local ports on connect (as well accepted connection ports) ephemeral. Kamailio has for that reason "connection aliases", so the matching is also done based on advertised attributes, not only on connection source ip/port. The interconnect provider should do it also for tcp/tls. I am not sure now, but I think there is also in the RFC specs something about.
Then, the alternative, with the latest kernels and kamailio, you can try to reuse the tcp port:
* https://www.kamailio.org/wiki/cookbooks/5.3.x/core#tcp_reuse_port
On the other hand, the firewall may associate a different extern port for connections originated from the same source ip/port, you will have to test and see what happens.
Cheers, Daniel
On 11.05.20 12:23, Michal Popovic wrote:
Hello,
so it looks like kamailio used random port for opening connections to our partners but did not updates record-route port properly. AWS has symmetric NAT and that works fine.
Is there any way how to identify port and rewrite record-route?
Thanks.
Bye, Michal
On 7 May 2020, at 17:25, Michal Popovic michal.popovic@cloudtalk.io wrote:
Hello,
our kamailio used for sip trunk interconnections is behind NAT and our cloud provider opens random outgoing ports for outbound connections. Our record-route is set to our external address and port 5060, that is probably incorrect, but we did not had any issues. One of our partners suddenly begin sending BYEs to the port advertised in record-route instead of port from where he received call.
What is a correct approach here if we are not able to determine open port behind NAT?
Bye, Michal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
thank you for your help.
I have found out that reason for this behaviour was that kamailio relay UDP connection to TCP connection and tm module adds two record-routes. This is correct behaviour, but I am not sure if it is correct that first record-route advertised port 5060 if kamailio opens random port for the connection. Shouldn't there be a port that was used for outgoing connection?
Record-Route: sip:xx.xx.xx.xx:5060;transport=tcp;r2=on;lr=on;ftag=as1f9ba470 Record-Route: <sipxx.xx.xx.xx;r2=on;lr=on;ftag=as1f9ba470>
Bye, Michal
On 11 May 2020, at 13:39, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
the nature of tcp protocol makes local ports on connect (as well accepted connection ports) ephemeral. Kamailio has for that reason "connection aliases", so the matching is also done based on advertised attributes, not only on connection source ip/port. The interconnect provider should do it also for tcp/tls. I am not sure now, but I think there is also in the RFC specs something about.
Then, the alternative, with the latest kernels and kamailio, you can try to reuse the tcp port:
On the other hand, the firewall may associate a different extern port for connections originated from the same source ip/port, you will have to test and see what happens.
Cheers, Daniel
On 11.05.20 12:23, Michal Popovic wrote:
Hello,
so it looks like kamailio used random port for opening connections to our partners but did not updates record-route port properly. AWS has symmetric NAT and that works fine.
Is there any way how to identify port and rewrite record-route?
Thanks.
Bye, Michal
On 7 May 2020, at 17:25, Michal Popovic michal.popovic@cloudtalk.io wrote:
Hello,
our kamailio used for sip trunk interconnections is behind NAT and our cloud provider opens random outgoing ports for outbound connections. Our record-route is set to our external address and port 5060, that is probably incorrect, but we did not had any issues. One of our partners suddenly begin sending BYEs to the port advertised in record-route instead of port from where he received call.
What is a correct approach here if we are not able to determine open port behind NAT?
Bye, Michal _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
Record route is used for coming transactions on the same dialog and needs to be something the server is listening to.
The server (on the other side) for a TCP connection may reuse the TCP connection (if outbound is used) or setup a new connection to the port advertised in Record-route/Route-headers.
As 5060 is the port Kamailio listens to, that is the one to be advertised. The other one is just a source port used for outbound connections and nothing Kamailio listens on for inbound connections.
/O
On 12 May 2020, at 11:39, Michal Popovic michal.popovic@cloudtalk.io wrote:
Hi Daniel,
thank you for your help.
I have found out that reason for this behaviour was that kamailio relay UDP connection to TCP connection and tm module adds two record-routes. This is correct behaviour, but I am not sure if it is correct that first record-route advertised port 5060 if kamailio opens random port for the connection. Shouldn't there be a port that was used for outgoing connection?
Record-Route: <sip:xx.xx.xx.xx: sip:xx.xx.xx.xx:5060;transport=tcp;r2=on;lr=on;ftag=as1f9ba470> Record-Route: <sipxx.xx.xx.xx;r2=on;lr=on;ftag=as1f9ba470>
Bye, Michal
On 11 May 2020, at 13:39, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
Hello,
the nature of tcp protocol makes local ports on connect (as well accepted connection ports) ephemeral. Kamailio has for that reason "connection aliases", so the matching is also done based on advertised attributes, not only on connection source ip/port. The interconnect provider should do it also for tcp/tls. I am not sure now, but I think there is also in the RFC specs something about.
Then, the alternative, with the latest kernels and kamailio, you can try to reuse the tcp port:
- https://www.kamailio.org/wiki/cookbooks/5.3.x/core#tcp_reuse_port https://www.kamailio.org/wiki/cookbooks/5.3.x/core#tcp_reuse_port
On the other hand, the firewall may associate a different extern port for connections originated from the same source ip/port, you will have to test and see what happens.
Cheers, Daniel
On 11.05.20 12:23, Michal Popovic wrote:
Hello,
so it looks like kamailio used random port for opening connections to our partners but did not updates record-route port properly. AWS has symmetric NAT and that works fine.
Is there any way how to identify port and rewrite record-route?
Thanks.
Bye, Michal
On 7 May 2020, at 17:25, Michal Popovic <michal.popovic@cloudtalk.io mailto:michal.popovic@cloudtalk.io> wrote:
Hello,
our kamailio used for sip trunk interconnections is behind NAT and our cloud provider opens random outgoing ports for outbound connections. Our record-route is set to our external address and port 5060, that is probably incorrect, but we did not had any issues. One of our partners suddenly begin sending BYEs to the port advertised in record-route instead of port from where he received call.
What is a correct approach here if we are not able to determine open port behind NAT?
Bye, Michal _______________________________________________ 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
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
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Michal Popovic -
Olle E. Johansson