7 May
2020
7 May
'20
5:25 p.m.
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
11 May
11 May
12:23 p.m.
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1:39 p.m.
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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
On 7 May 2020, at 17:25, Michal Popovic
<michal.popovic(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12 May
12 May
11:39 a.m.
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(a)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
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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
On 7 May 2020, at 17:25, Michal Popovic
<michal.popovic(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
11:47 a.m.
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(a)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(a)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:
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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
--
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>
On 7 May 2020, at 17:25, Michal Popovic
<michal.popovic(a)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(a)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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1456
days inactive
1461
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Michal Popovic -
Olle E. Johansson