Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hi Yuriy

Thanks for Your suggestions. I looked at them, and it seems to me that 
they all are supposed to be on the receiving side.
My side is the client side behind NAT, and only does INVITE, I never 
receives INVITES.


The alias concept looks interesting but I doubt that I can convince the 
provider to use is, as the documentation states it to be dangerous.


When looking up the force_tcp_alias I noticed that fix_natted_contact 
was recomended for NAT traversal. I do not know if the provider uses, 
this function. Could that be the cause?



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/12/21 8:59 AM, Yuriy Gorlichenko wrote:
It doesn't matter whet port used by provider when it sent initial 
INVITE to you.


Record-route and Route headers are Proxy headers. They are announce 
addresses of the proxy for the listening. That means when UA sends the 
request it has to use port mentioned in the first of the Route headers 
or in the Request URI header.
That means that your kamailio has to create new connection to this 
host port pair or reuse it if it already exists to reach provider's 
server. So there is nothing bad if you will create new connection for 
BYE to port 7071.


However, If provider initiated INVITE to you and sent it from the 
different port ( which is true because for that transaction provider 
has to behave atleast as TCP client ) and connection still alive ( 
socket still exists ) - you can try to use $du variable and put here 
existing address used for the connection to provider.

But remember it is a hack.

This is also can be achieved via as mentioned above global param

tcp_accept_aliases =yes

And functions wich has to be called on initial invite:
tcp_keepalive_enable
force_tcp_alias

On Tue, 12 Jan 2021, 07:15 Kjeld Flarup, > wrote:


Hi Daniel

The Record route in the INVITE from 194.247.61.26 sets this pair

Record-Route:


Record-Route:


The Bye requests this route

Route:


Route:


But the real port on 194.255.22.44 is 36059

It is my invite to 194.247.61.26 that sets the 7071 port, which
automatically comes from the listen statement.
I suspect that it might work if the invite was using 36059, but
how can I know this port, if the NAT router decides to map it to
another port.


What is the correct behaviour. Should my Kamailio somehow set the
correct port?

Should the providers Kamailio rewrite the route information?

Or something else?



 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk  


On 1/11/21 10:18 AM, Daniel-Constantin Mierla wrote:


The From/To/Call-ID are not used to match the connection. The
connection is matched based on target IP and port. For BYE, these
are taken from Route header, if there is one for next hop,
otherwise it is the request URI. Check these two to see if
something is not as expected. Otherwise, you have to discuss with
the provider and see the reason it returns back the 477 response.

Cheers,
Daniel

On 08.01.21 20:36, Kjeld Flarup wrote:


Happy New Year everyone.


I haven't solved this problem yet. Although is it not critical,
it is a bit annoying.

I have tried to simplify things, and have a reference setup that
works.
My linphone sends a TCP call and my Asterisk answers, plays a
speak and hangs up.


If I instead sends the call to my PBX, which handles the
authentication via UAC, it fails with this error, which the
customer site also generated.

Status-Line: SIP/2.0 477 Unfortunately error on sending to
next hop occurred (477/SL)

Unfortunately the error is not generated by my Kamailio, but by
a Kamailio at the provider, when it gets a Bye forwarded via
their SBC.


I have attached a capture which the provider send me. This is
the setup

linphone -> My Kamailio PBX (194.255.22.44:36089
) -> provider
Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075
)

A note on the providers Kamailio. It listens on both port 5060
and 5070, and both UDP/TCP.
It is also used as access point for both my PBX and my Asterisk,
thus the trace may be a little confusing to read.

As far as I can see, the provider Kamailio gets the correct
To/From and CallID in the bye. 

Re: [SR-Users] BYE and TCP

[Yuriy Gorlichenko]

It doesn't matter whet port used by provider when it sent initial INVITE to
you.

Record-route and Route headers are Proxy headers. They are announce
addresses of the proxy for the listening. That means when UA sends the
request it has to use port mentioned in the first of the Route headers or
in the Request URI header.
That means that your kamailio has to create new connection to this host
port pair or reuse it if it already exists to reach provider's server. So
there is nothing bad if you will create new connection for BYE to port 7071.

However, If provider initiated INVITE to you and sent it from the different
port ( which is true because for that transaction provider has to behave
atleast as TCP client ) and connection still alive ( socket still exists )
- you can try to use $du variable and put here existing address used for
the connection to provider.
But remember it is a hack.

This is also can be achieved via as mentioned above global param

tcp_accept_aliases =yes

And functions wich has to be called on initial invite:
tcp_keepalive_enable
force_tcp_alias

On Tue, 12 Jan 2021, 07:15 Kjeld Flarup, 
wrote:

> Hi Daniel
>
> The Record route in the INVITE from 194.247.61.26 sets this pair
>
> Record-Route:
> 
> Record-Route:
> 
>
> The Bye requests this route
>
> Route:
> 
> Route: 
>
> But the real port on 194.255.22.44 is 36059
>
> It is my invite to 194.247.61.26 that sets the 7071 port, which
> automatically comes from the listen statement.
> I suspect that it might work if the invite was using 36059, but how can I
> know this port, if the NAT router decides to map it to another port.
>
>
> What is the correct behaviour. Should my Kamailio somehow set the correct
> port?
>
> Should the providers Kamailio rewrite the route information?
>
> Or something else?
>
>
>
>  Med Liberalistiske Hilsner --
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
> On 1/11/21 10:18 AM, Daniel-Constantin Mierla wrote:
>
> The From/To/Call-ID are not used to match the connection. The connection
> is matched based on target IP and port. For BYE, these are taken from Route
> header, if there is one for next hop, otherwise it is the request URI.
> Check these two to see if something is not as expected. Otherwise, you have
> to discuss with the provider and see the reason it returns back the 477
> response.
>
> Cheers,
> Daniel
> On 08.01.21 20:36, Kjeld Flarup wrote:
>
> Happy New Year everyone.
>
>
> I haven't solved this problem yet. Although is it not critical, it is a
> bit annoying.
>
> I have tried to simplify things, and have a reference setup that works.
> My linphone sends a TCP call and my Asterisk answers, plays a speak and
> hangs up.
>
>
> If I instead sends the call to my PBX, which handles the authentication
> via UAC, it fails with this error, which the customer site also generated.
>
> Status-Line: SIP/2.0 477 Unfortunately error on sending to next hop
> occurred (477/SL)
>
> Unfortunately the error is not generated by my Kamailio, but by a Kamailio
> at the provider, when it gets a Bye forwarded via their SBC.
>
>
> I have attached a capture which the provider send me. This is the setup
>
> linphone -> My Kamailio PBX (194.255.22.44:36089) -> provider
> Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
> Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075)
>
> A note on the providers Kamailio. It listens on both port 5060 and 5070,
> and both UDP/TCP.
> It is also used as access point for both my PBX and my Asterisk, thus the
> trace may be a little confusing to read.
>
> As far as I can see, the provider Kamailio gets the correct To/From and
> CallID in the bye. Thus it should be able to match the TCP connection.
> The flow is also clean, there is no change of ports etc.
>
>
>
> I have this reference setup which works
>
> linphone -> provider Kamailio -> SBC -> provider Kamailio -> my Asterisk
>
> The only differences towards the reference I can see these. I do not have
> a capture from the provider on this.
>
>- There is an extra Via step.
>- Contact points to the Linphone IP, not the Kamailio IP
>
> Any hint will be appreciated.
>
>
>
>  Med Liberalistiske Hilsner --
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
> On 11/9/20 12:06 PM, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> there is no association between a SIP call and a TCP connection. SIP is
> not designed on TCP streams, the forwarding is based on the headers. It
> doesn't matter if there are messages belonging to same call or not, they
> can share same connection, or can open a new one...
>
> The BYE from caller gets to 

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hi Daniel

The Record route in the INVITE from 194.247.61.26 sets this pair

Record-Route: 

Record-Route: 



The Bye requests this route

Route: 


Route: 

But the real port on 194.255.22.44 is 36059

It is my invite to 194.247.61.26 that sets the 7071 port, which 
automatically comes from the listen statement.
I suspect that it might work if the invite was using 36059, but how can 
I know this port, if the NAT router decides to map it to another port.



What is the correct behaviour. Should my Kamailio somehow set the 
correct port?


Should the providers Kamailio rewrite the route information?

Or something else?



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 1/11/21 10:18 AM, Daniel-Constantin Mierla wrote:


The From/To/Call-ID are not used to match the connection. The 
connection is matched based on target IP and port. For BYE, these are 
taken from Route header, if there is one for next hop, otherwise it is 
the request URI. Check these two to see if something is not as 
expected. Otherwise, you have to discuss with the provider and see the 
reason it returns back the 477 response.


Cheers,
Daniel

On 08.01.21 20:36, Kjeld Flarup wrote:


Happy New Year everyone.


I haven't solved this problem yet. Although is it not critical, it is 
a bit annoying.


I have tried to simplify things, and have a reference setup that works.
My linphone sends a TCP call and my Asterisk answers, plays a speak 
and hangs up.



If I instead sends the call to my PBX, which handles the 
authentication via UAC, it fails with this error, which the customer 
site also generated.


Status-Line: SIP/2.0 477 Unfortunately error on sending to next
hop occurred (477/SL)

Unfortunately the error is not generated by my Kamailio, but by a 
Kamailio at the provider, when it gets a Bye forwarded via their SBC.



I have attached a capture which the provider send me. This is the setup

linphone -> My Kamailio PBX (194.255.22.44:36089) -> provider
Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075)

A note on the providers Kamailio. It listens on both port 5060 and 
5070, and both UDP/TCP.
It is also used as access point for both my PBX and my Asterisk, thus 
the trace may be a little confusing to read.


As far as I can see, the provider Kamailio gets the correct To/From 
and CallID in the bye. Thus it should be able to match the TCP 
connection.

The flow is also clean, there is no change of ports etc.



I have this reference setup which works

linphone -> provider Kamailio -> SBC -> provider Kamailio -> my
Asterisk

The only differences towards the reference I can see these. I do not 
have a capture from the provider on this.


  * There is an extra Via step.
  * Contact points to the Linphone IP, not the Kamailio IP

Any hint will be appreciated.



 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk
On 11/9/20 12:06 PM, Daniel-Constantin Mierla wrote:


Hello,

there is no association between a SIP call and a TCP connection. SIP 
is not designed on TCP streams, the forwarding is based on the 
headers. It doesn't matter if there are messages belonging to same 
call or not, they can share same connection, or can open a new one...


The BYE from caller gets to 194.247.61.32:5040, which cannot deliver 
it further based on Route header. The system at 194.247.61.26:5070 
must be able to accept connections on advertised port of the Route 
address. Again, connection interruption can happen from various 
cases, it cannot rely on ephemeral ports, but on what the SIP system 
advertises as "listen" address.


One can play with tcp port aliases, look at Kamailio core cookbook, 
in case 194.247.61.32:5040 can do that. But that is not the proper 
way for server to server communication, there will be cases when the 
connection will be cut for various reasons (can be also the IP 
routes in the path that get congested).


Otherwise, you can follow the code of tcp_send() function in the 
tcp_main.c from core to see how tcp connection is matched, there are 
various cases there, also a matter of the config parameters.


Cheers,
Daniel

On 09.11.20 10:13, Kjeld Flarup wrote:

Hello

I have attached a pcap received from the provider.

It is quite informative as it shows bits of how they forward the call.

We send to 194.247.61.26 which is a Kamailio proxy, that forwards 
the call to a SBC  194.247.61.32


My guess is that the  194.247.61.26 kamailio gets confused, and 
does not match the BYE with the ongoing TCP 

Re: [SR-Users] BYE and TCP

[Daniel-Constantin Mierla]

The From/To/Call-ID are not used to match the connection. The connection
is matched based on target IP and port. For BYE, these are taken from
Route header, if there is one for next hop, otherwise it is the request
URI. Check these two to see if something is not as expected. Otherwise,
you have to discuss with the provider and see the reason it returns back
the 477 response.

Cheers,
Daniel

On 08.01.21 20:36, Kjeld Flarup wrote:
>
> Happy New Year everyone.
>
>
> I haven't solved this problem yet. Although is it not critical, it is
> a bit annoying.
>
> I have tried to simplify things, and have a reference setup that works.
> My linphone sends a TCP call and my Asterisk answers, plays a speak
> and hangs up.
>
>
> If I instead sends the call to my PBX, which handles the
> authentication via UAC, it fails with this error, which the customer
> site also generated.
>
> Status-Line: SIP/2.0 477 Unfortunately error on sending to next
> hop occurred (477/SL)
>
> Unfortunately the error is not generated by my Kamailio, but by a
> Kamailio at the provider, when it gets a Bye forwarded via their SBC.
>
>
> I have attached a capture which the provider send me. This is the setup
>
> linphone -> My Kamailio PBX (194.255.22.44:36089) -> provider
> Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
> Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075)
>
> A note on the providers Kamailio. It listens on both port 5060 and
> 5070, and both UDP/TCP.
> It is also used as access point for both my PBX and my Asterisk, thus
> the trace may be a little confusing to read.
>
> As far as I can see, the provider Kamailio gets the correct To/From
> and CallID in the bye. Thus it should be able to match the TCP
> connection.
> The flow is also clean, there is no change of ports etc.
>
>
>
> I have this reference setup which works
>
> linphone -> provider Kamailio -> SBC -> provider Kamailio -> my
> Asterisk
>
> The only differences towards the reference I can see these. I do not
> have a capture from the provider on this.
>
>   * There is an extra Via step.
>   * Contact points to the Linphone IP, not the Kamailio IP
>
> Any hint will be appreciated.
>
>
>
>  Med Liberalistiske Hilsner --
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
> On 11/9/20 12:06 PM, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> there is no association between a SIP call and a TCP connection. SIP
>> is not designed on TCP streams, the forwarding is based on the
>> headers. It doesn't matter if there are messages belonging to same
>> call or not, they can share same connection, or can open a new one...
>>
>> The BYE from caller gets to 194.247.61.32:5040, which cannot deliver
>> it further based on Route header. The system at 194.247.61.26:5070
>> must be able to accept connections on advertised port of the Route
>> address. Again, connection interruption can happen from various
>> cases, it cannot rely on ephemeral ports, but on what the SIP system
>> advertises as "listen" address.
>>
>> One can play with tcp port aliases, look at Kamailio core cookbook,
>> in case 194.247.61.32:5040 can do that. But that is not the proper
>> way for server to server communication, there will be cases when the
>> connection will be cut for various reasons (can be also the IP routes
>> in the path that get congested).
>>
>> Otherwise, you can follow the code of tcp_send() function in the
>> tcp_main.c from core to see how tcp connection is matched, there are
>> various cases there, also a matter of the config parameters.
>>
>> Cheers,
>> Daniel
>>
>> On 09.11.20 10:13, Kjeld Flarup wrote:
>>> Hello
>>>
>>> I have attached a pcap received from the provider.
>>>
>>> It is quite informative as it shows bits of how they forward the call.
>>>
>>> We send to 194.247.61.26 which is a Kamailio proxy, that forwards
>>> the call to a SBC  194.247.61.32
>>>
>>> My guess is that the  194.247.61.26 kamailio gets confused, and does
>>> not match the BYE with the ongoing TCP session.
>>> Instead it sees it as a new session, and forwards it according to
>>> the route information.
>>>
>>> Can anybody help explaining what fields Kamailio uses to match an
>>> ongoing TCP session.
>>>
>>>   Regards Kjeld
>>>
>>> Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla
>>> mailto:mico...@gmail.com>>:
>>>
>>> Hello,
>>>
>>> from SIP specs point of view, can be any port -- ACK and BYE do
>>> not have to follow same path as INVITE, so they can even come
>>> from a different IP.
>>>
>>> Then, the call can be closed after 30secs because also the ACK
>>> has the same problems with the header as the BYE. Your pcap
>>> didn't include all the traffic, you have to capture both
>>> directions on your kamailio server to see what 

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Happy New Year everyone.


I haven't solved this problem yet. Although is it not critical, it is a 
bit annoying.


I have tried to simplify things, and have a reference setup that works.
My linphone sends a TCP call and my Asterisk answers, plays a speak and 
hangs up.



If I instead sends the call to my PBX, which handles the authentication 
via UAC, it fails with this error, which the customer site also generated.


   Status-Line: SIP/2.0 477 Unfortunately error on sending to next hop
   occurred (477/SL)

Unfortunately the error is not generated by my Kamailio, but by a 
Kamailio at the provider, when it gets a Bye forwarded via their SBC.



I have attached a capture which the provider send me. This is the setup

   linphone -> My Kamailio PBX (194.255.22.44:36089) -> provider
   Kamailio(194.247.61.26) -> SBC(194.247.61.32) -> provider
   Kamailio(194.247.61.26) -> my Asterisk (194.255.22.44:45075)

A note on the providers Kamailio. It listens on both port 5060 and 5070, 
and both UDP/TCP.
It is also used as access point for both my PBX and my Asterisk, thus 
the trace may be a little confusing to read.


As far as I can see, the provider Kamailio gets the correct To/From and 
CallID in the bye. Thus it should be able to match the TCP connection.

The flow is also clean, there is no change of ports etc.



I have this reference setup which works

   linphone -> provider Kamailio -> SBC -> provider Kamailio -> my Asterisk

The only differences towards the reference I can see these. I do not 
have a capture from the provider on this.


 * There is an extra Via step.
 * Contact points to the Linphone IP, not the Kamailio IP

Any hint will be appreciated.



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk

On 11/9/20 12:06 PM, Daniel-Constantin Mierla wrote:


Hello,

there is no association between a SIP call and a TCP connection. SIP 
is not designed on TCP streams, the forwarding is based on the 
headers. It doesn't matter if there are messages belonging to same 
call or not, they can share same connection, or can open a new one...


The BYE from caller gets to 194.247.61.32:5040, which cannot deliver 
it further based on Route header. The system at 194.247.61.26:5070 
must be able to accept connections on advertised port of the Route 
address. Again, connection interruption can happen from various cases, 
it cannot rely on ephemeral ports, but on what the SIP system 
advertises as "listen" address.


One can play with tcp port aliases, look at Kamailio core cookbook, in 
case 194.247.61.32:5040 can do that. But that is not the proper way 
for server to server communication, there will be cases when the 
connection will be cut for various reasons (can be also the IP routes 
in the path that get congested).


Otherwise, you can follow the code of tcp_send() function in the 
tcp_main.c from core to see how tcp connection is matched, there are 
various cases there, also a matter of the config parameters.


Cheers,
Daniel

On 09.11.20 10:13, Kjeld Flarup wrote:

Hello

I have attached a pcap received from the provider.

It is quite informative as it shows bits of how they forward the call.

We send to 194.247.61.26 which is a Kamailio proxy, that forwards the 
call to a SBC  194.247.61.32


My guess is that the  194.247.61.26 kamailio gets confused, and does 
not match the BYE with the ongoing TCP session.
Instead it sees it as a new session, and forwards it according to the 
route information.


Can anybody help explaining what fields Kamailio uses to match an 
ongoing TCP session.


  Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla 
mailto:mico...@gmail.com>>:


Hello,

from SIP specs point of view, can be any port -- ACK and BYE do
not have to follow same path as INVITE, so they can even come
from a different IP.

Then, the call can be closed after 30secs because also the ACK
has the same problems with the header as the BYE. Your pcap
didn't include all the traffic, you have to capture both
directions on your kamailio server to see what happens on each side.

Cheers,
Daniel


On 06.11.20 10:35, Kjeld Flarup wrote:

Hi Daniel

The Unknown Dialog comes because the server hang up the call 30
seconds earlier. We never gets these BYE messages, thus the door
phone hangs times out and hangs up.

My question is still, which port is the BYE from the server
supposed to be sent to?

The original 37148
The new 37150
or the advertised 5071

Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla
mailto:mico...@gmail.com>>:

Hello,

I think you hunt a mirage problem here by looking at the
ports of tcp connections, if you think that 

Re: [SR-Users] BYE and TCP

[Daniel-Constantin Mierla]

Hello,

there is no association between a SIP call and a TCP connection. SIP is
not designed on TCP streams, the forwarding is based on the headers. It
doesn't matter if there are messages belonging to same call or not, they
can share same connection, or can open a new one...

The BYE from caller gets to 194.247.61.32:5040, which cannot deliver it
further based on Route header. The system at 194.247.61.26:5070 must be
able to accept connections on advertised port of the Route address.
Again, connection interruption can happen from various cases, it cannot
rely on ephemeral ports, but on what the SIP system advertises as
"listen" address.

One can play with tcp port aliases, look at Kamailio core cookbook, in
case 194.247.61.32:5040 can do that. But that is not the proper way for
server to server communication, there will be cases when the connection
will be cut for various reasons (can be also the IP routes in the path
that get congested).

Otherwise, you can follow the code of tcp_send() function in the
tcp_main.c from core to see how tcp connection is matched, there are
various cases there, also a matter of the config parameters.

Cheers,
Daniel

On 09.11.20 10:13, Kjeld Flarup wrote:
> Hello
>
> I have attached a pcap received from the provider.
>
> It is quite informative as it shows bits of how they forward the call.
>
> We send to 194.247.61.26 which is a Kamailio proxy, that forwards the
> call to a SBC  194.247.61.32
>
> My guess is that the  194.247.61.26 kamailio gets confused, and does
> not match the BYE with the ongoing TCP session.
> Instead it sees it as a new session, and forwards it according to the
> route information.
>
> Can anybody help explaining what fields Kamailio uses to match an
> ongoing TCP session.
>
>   Regards Kjeld
>
> Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla
> mailto:mico...@gmail.com>>:
>
> Hello,
>
> from SIP specs point of view, can be any port -- ACK and BYE do
> not have to follow same path as INVITE, so they can even come from
> a different IP.
>
> Then, the call can be closed after 30secs because also the ACK has
> the same problems with the header as the BYE. Your pcap didn't
> include all the traffic, you have to capture both directions on
> your kamailio server to see what happens on each side.
>
> Cheers,
> Daniel
>
>
> On 06.11.20 10:35, Kjeld Flarup wrote:
>> Hi Daniel
>>
>> The Unknown Dialog comes because the server hang up the call 30
>> seconds earlier. We never gets these BYE messages, thus the door
>> phone hangs times out and hangs up.
>>
>> My question is still, which port is the BYE from the server
>> supposed to be sent to?
>>
>> The original 37148
>> The new 37150
>> or the advertised 5071
>>
>> Regards Kjeld
>>
>> Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla
>> mailto:mico...@gmail.com>>:
>>
>> Hello,
>>
>> I think you hunt a mirage problem here by looking at the
>> ports of tcp connections, if you think that being different
>> ports is the cause of BYE failure. The ACK fpr 200ok is
>> independent of the INVITE transaction and can have a
>> completely different path than INVITE, thus is completely
>> valid to use another connection. Of course, if follows the
>> same path as INVITE, if the connection is still open, it
>> should be reused. But is a matter of matching, it can be that
>> the INVITE uses different destination identifiers or the
>> connection gets cut from different reasons. But the point is
>> that even if there is a different connection, it should work.
>>
>> So, I actually looked at the pcap capture you sent in one of
>> your previous emails and the BYE is sent out, but gets back:
>>
>> SIP/2.0 481 Unknown Dialog.
>>
>> Therefore it gets to the end point, which doesn't match it
>> with any of its active calls. Looking at the headers, the
>> 200ok/INVITE has:
>>
>> From: "Front Door"
>> 
>> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To: ;tag=12003375157297.
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> And the BYE:
>>
>> From: "Front Door"
>> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To:
>> 
>> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297.
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> While the dialog should be matched on call-id, from/to-tags,
>> the From/To URI should be the same to be strict conformant
>> with RFC3261 (that mandates unchanged From/To for backward
>> compatibility with RFC2543). Likely you do some From/To
>> header changes that are not done correctly to update/restore
>> the values for traffic within 

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hello

I have attached a pcap received from the provider.

It is quite informative as it shows bits of how they forward the call.

We send to 194.247.61.26 which is a Kamailio proxy, that forwards the call
to a SBC  194.247.61.32

My guess is that the  194.247.61.26 kamailio gets confused, and does not
match the BYE with the ongoing TCP session.
Instead it sees it as a new session, and forwards it according to the route
information.

Can anybody help explaining what fields Kamailio uses to match an ongoing
TCP session.

  Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.50 skrev Daniel-Constantin Mierla <
mico...@gmail.com>:

> Hello,
>
> from SIP specs point of view, can be any port -- ACK and BYE do not have
> to follow same path as INVITE, so they can even come from a different IP.
>
> Then, the call can be closed after 30secs because also the ACK has the
> same problems with the header as the BYE. Your pcap didn't include all the
> traffic, you have to capture both directions on your kamailio server to see
> what happens on each side.
>
> Cheers,
> Daniel
>
>
> On 06.11.20 10:35, Kjeld Flarup wrote:
>
> Hi Daniel
>
> The Unknown Dialog comes because the server hang up the call 30 seconds
> earlier. We never gets these BYE messages, thus the door phone hangs times
> out and hangs up.
>
> My question is still, which port is the BYE from the server supposed to be
> sent to?
>
> The original 37148
> The new 37150
> or the advertised 5071
>
> Regards Kjeld
>
> Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla <
> mico...@gmail.com>:
>
>> Hello,
>>
>> I think you hunt a mirage problem here by looking at the ports of tcp
>> connections, if you think that being different ports is the cause of BYE
>> failure. The ACK fpr 200ok is independent of the INVITE transaction and can
>> have a completely different path than INVITE, thus is completely valid to
>> use another connection. Of course, if follows the same path as INVITE, if
>> the connection is still open, it should be reused. But is a matter of
>> matching, it can be that the INVITE uses different destination identifiers
>> or the connection gets cut from different reasons. But the point is that
>> even if there is a different connection, it should work.
>>
>> So, I actually looked at the pcap capture you sent in one of your
>> previous emails and the BYE is sent out, but gets back:
>>
>> SIP/2.0 481 Unknown Dialog.
>>
>> Therefore it gets to the end point, which doesn't match it with any of
>> its active calls. Looking at the headers, the 200ok/INVITE has:
>>
>> From: "Front Door" 
>> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To: ;tag=12003375157297.
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> And the BYE:
>>
>> From: "Front Door" 
>> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To:
>> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297
>> .
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> While the dialog should be matched on call-id, from/to-tags, the From/To
>> URI should be the same to be strict conformant with RFC3261 (that mandates
>> unchanged From/To for backward compatibility with RFC2543). Likely you do
>> some From/To header changes that are not done correctly to update/restore
>> the values for traffic within dialog.
>>
>> Cheers,
>> Daniel
>> On 06.11.20 09:31, Kjeld Flarup wrote:
>>
>> Thanks Juha
>>
>> That makes it somehow easier to understand my capture. My Kamailio must
>> then have detected a broken TCP connection, though I cannot see why in the
>> capture, neither in the log, but I only run on debug level 2.
>> It receives a 200 OK on port 37148, and then establishes 37150 to reply
>> with an ACK.
>>
>> However two seconds before receiving the 200 OK, there are some spurious
>> retransmissions and out of order on 37148. Perhaps this has caused Kamailio
>> to deem the connection bad, but it still receives data on it.
>> Now I assume that the providers server (Which also is flying Kamailio)
>> should detect the new port, and continue using that. I got a trace from the
>> provider, where there is no disturbance. Thus the server thinks that the
>> connection is OK.
>>
>> Now my next question is, what makes a Kamailio detect this change?
>> Is it a problem that I only rewrite To and From in the INVITE, thus the
>> ACK contains some other values.
>>
>>
>> It is also a bit strange that I get this error exactly, the same place in
>> the conversation every time I make a call. Somehow I suspect some NAT
>> timeout in the router. (it is not carrier grade NAT).
>> Can I do anything to prevent a NAT timeout from the client side?
>>
>>
>> Another thing. I assume that sending my internal port in the From field,
>> or any kind of advertising, should be ignored by the server.
>>
>> Regards Kjeld
>>
>>
>>
>> Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen :
>>
>>> Kjeld Flarup writes:
>>>
>>> > How is TCP SIP actually supposed to handle a 

Re: [SR-Users] BYE and TCP

[Juha Heinanen]

Kjeld Flarup writes:

> My question is still, which port is the BYE from the server supposed to be
> sent to?

If client is behind NAT, the server must use the connection that the
client opened to it to send the request to client.  There is no way the
server opens the connection and uses it.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Juha Heinanen]

Kjeld Flarup writes:

> How is TCP SIP actually supposed to handle a BYE, when the client is 
> behind NAT.

Client behind NAT is supposed to keep its TCP connection to SIP Proxy
alive and use it for all requests of the call.  If the connection breaks
for some reason, the client sets up a new one for the remaining
requests.

-- Juha

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Daniel-Constantin Mierla]

Hello,

from SIP specs point of view, can be any port -- ACK and BYE do not have
to follow same path as INVITE, so they can even come from a different IP.

Then, the call can be closed after 30secs because also the ACK has the
same problems with the header as the BYE. Your pcap didn't include all
the traffic, you have to capture both directions on your kamailio server
to see what happens on each side.

Cheers,
Daniel


On 06.11.20 10:35, Kjeld Flarup wrote:
> Hi Daniel
>
> The Unknown Dialog comes because the server hang up the call 30
> seconds earlier. We never gets these BYE messages, thus the door phone
> hangs times out and hangs up.
>
> My question is still, which port is the BYE from the server supposed
> to be sent to?
>
> The original 37148
> The new 37150
> or the advertised 5071
>
> Regards Kjeld
>
> Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla
> mailto:mico...@gmail.com>>:
>
> Hello,
>
> I think you hunt a mirage problem here by looking at the ports of
> tcp connections, if you think that being different ports is the
> cause of BYE failure. The ACK fpr 200ok is independent of the
> INVITE transaction and can have a completely different path than
> INVITE, thus is completely valid to use another connection. Of
> course, if follows the same path as INVITE, if the connection is
> still open, it should be reused. But is a matter of matching, it
> can be that the INVITE uses different destination identifiers or
> the connection gets cut from different reasons. But the point is
> that even if there is a different connection, it should work.
>
> So, I actually looked at the pcap capture you sent in one of your
> previous emails and the BYE is sent out, but gets back:
>
> SIP/2.0 481 Unknown Dialog.
>
> Therefore it gets to the end point, which doesn't match it with
> any of its active calls. Looking at the headers, the 200ok/INVITE has:
>
> From: "Front Door"
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To: ;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> And the BYE:
>
> From: "Front Door"
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To:
> 
> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> While the dialog should be matched on call-id, from/to-tags, the
> From/To URI should be the same to be strict conformant with
> RFC3261 (that mandates unchanged From/To for backward
> compatibility with RFC2543). Likely you do some From/To header
> changes that are not done correctly to update/restore the values
> for traffic within dialog.
>
> Cheers,
> Daniel
>
> On 06.11.20 09:31, Kjeld Flarup wrote:
>> Thanks Juha
>>
>> That makes it somehow easier to understand my capture. My
>> Kamailio must then have detected a broken TCP connection, though
>> I cannot see why in the capture, neither in the log, but I only
>> run on debug level 2.
>> It receives a 200 OK on port 37148, and then establishes 37150 to
>> reply with an ACK. 
>>
>> However two seconds before receiving the 200 OK, there are some
>> spurious retransmissions and out of order on 37148. Perhaps this
>> has caused Kamailio to deem the connection bad, but it still
>> receives data on it.
>> Now I assume that the providers server (Which also is flying
>> Kamailio) should detect the new port, and continue using that. I
>> got a trace from the provider, where there is no disturbance.
>> Thus the server thinks that the connection is OK. 
>>
>> Now my next question is, what makes a Kamailio detect this change?
>> Is it a problem that I only rewrite To and From in the INVITE,
>> thus the ACK contains some other values. 
>>
>>
>> It is also a bit strange that I get this error exactly, the same
>> place in the conversation every time I make a call. Somehow I
>> suspect some NAT timeout in the router. (it is not carrier grade
>> NAT).
>> Can I do anything to prevent a NAT timeout from the client side?
>>
>>
>> Another thing. I assume that sending my internal port in the From
>> field, or any kind of advertising, should be ignored by the server.
>>
>> Regards Kjeld
>>
>>
>>
>> Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen
>> mailto:j...@tutpro.com>>:
>>
>> Kjeld Flarup writes:
>>
>> > How is TCP SIP actually supposed to handle a BYE, when the
>> client is
>> > behind NAT.
>>
>> Client behind NAT is supposed to keep its TCP connection to
>> SIP Proxy
>> alive and use it for all requests of the call.  If the
>> connection breaks
>> for some reason, the client sets up a new one for the remaining
>> requests.
>>
>> -- Juha
>>
>> 

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hi Daniel

The Unknown Dialog comes because the server hang up the call 30 seconds
earlier. We never gets these BYE messages, thus the door phone hangs times
out and hangs up.

My question is still, which port is the BYE from the server supposed to be
sent to?

The original 37148
The new 37150
or the advertised 5071

Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla <
mico...@gmail.com>:

> Hello,
>
> I think you hunt a mirage problem here by looking at the ports of tcp
> connections, if you think that being different ports is the cause of BYE
> failure. The ACK fpr 200ok is independent of the INVITE transaction and can
> have a completely different path than INVITE, thus is completely valid to
> use another connection. Of course, if follows the same path as INVITE, if
> the connection is still open, it should be reused. But is a matter of
> matching, it can be that the INVITE uses different destination identifiers
> or the connection gets cut from different reasons. But the point is that
> even if there is a different connection, it should work.
>
> So, I actually looked at the pcap capture you sent in one of your previous
> emails and the BYE is sent out, but gets back:
>
> SIP/2.0 481 Unknown Dialog.
>
> Therefore it gets to the end point, which doesn't match it with any of its
> active calls. Looking at the headers, the 200ok/INVITE has:
>
> From: "Front Door" 
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To: ;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> And the BYE:
>
> From: "Front Door" 
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To:
> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297
> .
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> While the dialog should be matched on call-id, from/to-tags, the From/To
> URI should be the same to be strict conformant with RFC3261 (that mandates
> unchanged From/To for backward compatibility with RFC2543). Likely you do
> some From/To header changes that are not done correctly to update/restore
> the values for traffic within dialog.
>
> Cheers,
> Daniel
> On 06.11.20 09:31, Kjeld Flarup wrote:
>
> Thanks Juha
>
> That makes it somehow easier to understand my capture. My Kamailio must
> then have detected a broken TCP connection, though I cannot see why in the
> capture, neither in the log, but I only run on debug level 2.
> It receives a 200 OK on port 37148, and then establishes 37150 to reply
> with an ACK.
>
> However two seconds before receiving the 200 OK, there are some spurious
> retransmissions and out of order on 37148. Perhaps this has caused Kamailio
> to deem the connection bad, but it still receives data on it.
> Now I assume that the providers server (Which also is flying Kamailio)
> should detect the new port, and continue using that. I got a trace from the
> provider, where there is no disturbance. Thus the server thinks that the
> connection is OK.
>
> Now my next question is, what makes a Kamailio detect this change?
> Is it a problem that I only rewrite To and From in the INVITE, thus the
> ACK contains some other values.
>
>
> It is also a bit strange that I get this error exactly, the same place in
> the conversation every time I make a call. Somehow I suspect some NAT
> timeout in the router. (it is not carrier grade NAT).
> Can I do anything to prevent a NAT timeout from the client side?
>
>
> Another thing. I assume that sending my internal port in the From field,
> or any kind of advertising, should be ignored by the server.
>
> Regards Kjeld
>
>
>
> Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen :
>
>> Kjeld Flarup writes:
>>
>> > How is TCP SIP actually supposed to handle a BYE, when the client is
>> > behind NAT.
>>
>> Client behind NAT is supposed to keep its TCP connection to SIP Proxy
>> alive and use it for all requests of the call.  If the connection breaks
>> for some reason, the client sets up a new one for the remaining
>> requests.
>>
>> -- Juha
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
>
> - Med Liberalistiske Hilsner --
>
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>

-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er 

Re: [SR-Users] BYE and TCP

[Daniel-Constantin Mierla]

Hello,

I think you hunt a mirage problem here by looking at the ports of tcp
connections, if you think that being different ports is the cause of BYE
failure. The ACK fpr 200ok is independent of the INVITE transaction and
can have a completely different path than INVITE, thus is completely
valid to use another connection. Of course, if follows the same path as
INVITE, if the connection is still open, it should be reused. But is a
matter of matching, it can be that the INVITE uses different destination
identifiers or the connection gets cut from different reasons. But the
point is that even if there is a different connection, it should work.

So, I actually looked at the pcap capture you sent in one of your
previous emails and the BYE is sent out, but gets back:

SIP/2.0 481 Unknown Dialog.

Therefore it gets to the end point, which doesn't match it with any of
its active calls. Looking at the headers, the 200ok/INVITE has:

From: "Front Door"
;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To: ;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.

And the BYE:

From: "Front Door"
;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To:
sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.

While the dialog should be matched on call-id, from/to-tags, the From/To
URI should be the same to be strict conformant with RFC3261 (that
mandates unchanged From/To for backward compatibility with RFC2543).
Likely you do some From/To header changes that are not done correctly to
update/restore the values for traffic within dialog.

Cheers,
Daniel

On 06.11.20 09:31, Kjeld Flarup wrote:
> Thanks Juha
>
> That makes it somehow easier to understand my capture. My Kamailio
> must then have detected a broken TCP connection, though I cannot see
> why in the capture, neither in the log, but I only run on debug level 2.
> It receives a 200 OK on port 37148, and then establishes 37150 to
> reply with an ACK. 
>
> However two seconds before receiving the 200 OK, there are some
> spurious retransmissions and out of order on 37148. Perhaps this has
> caused Kamailio to deem the connection bad, but it still receives data
> on it.
> Now I assume that the providers server (Which also is flying Kamailio)
> should detect the new port, and continue using that. I got a trace
> from the provider, where there is no disturbance. Thus the server
> thinks that the connection is OK. 
>
> Now my next question is, what makes a Kamailio detect this change?
> Is it a problem that I only rewrite To and From in the INVITE, thus
> the ACK contains some other values. 
>
>
> It is also a bit strange that I get this error exactly, the same place
> in the conversation every time I make a call. Somehow I suspect some
> NAT timeout in the router. (it is not carrier grade NAT).
> Can I do anything to prevent a NAT timeout from the client side?
>
>
> Another thing. I assume that sending my internal port in the From
> field, or any kind of advertising, should be ignored by the server.
>
> Regards Kjeld
>
>
>
> Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen  >:
>
> Kjeld Flarup writes:
>
> > How is TCP SIP actually supposed to handle a BYE, when the
> client is
> > behind NAT.
>
> Client behind NAT is supposed to keep its TCP connection to SIP Proxy
> alive and use it for all requests of the call.  If the connection
> breaks
> for some reason, the client sets up a new one for the remaining
> requests.
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
>
>
>
> -- 
>
> - Med Liberalistiske Hilsner --
>
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk 
> 
>
>
> ___
> 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

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Thanks Juha

That makes it somehow easier to understand my capture. My Kamailio must
then have detected a broken TCP connection, though I cannot see why in the
capture, neither in the log, but I only run on debug level 2.
It receives a 200 OK on port 37148, and then establishes 37150 to reply
with an ACK.

However two seconds before receiving the 200 OK, there are some spurious
retransmissions and out of order on 37148. Perhaps this has caused Kamailio
to deem the connection bad, but it still receives data on it.
Now I assume that the providers server (Which also is flying Kamailio)
should detect the new port, and continue using that. I got a trace from the
provider, where there is no disturbance. Thus the server thinks that the
connection is OK.

Now my next question is, what makes a Kamailio detect this change?
Is it a problem that I only rewrite To and From in the INVITE, thus the ACK
contains some other values.


It is also a bit strange that I get this error exactly, the same place in
the conversation every time I make a call. Somehow I suspect some NAT
timeout in the router. (it is not carrier grade NAT).
Can I do anything to prevent a NAT timeout from the client side?


Another thing. I assume that sending my internal port in the From field, or
any kind of advertising, should be ignored by the server.

Regards Kjeld



Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen :

> Kjeld Flarup writes:
>
> > How is TCP SIP actually supposed to handle a BYE, when the client is
> > behind NAT.
>
> Client behind NAT is supposed to keep its TCP connection to SIP Proxy
> alive and use it for all requests of the call.  If the connection breaks
> for some reason, the client sets up a new one for the remaining
> requests.
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hello

I got an answer from the VOIP provider.

They claim that we have an error in our port forwarding. Because we 
advertise 5071, but traffic comes from another port.


As I understand, it is however impossible for TCP to send all traffic 
from just one port.


How is TCP SIP actually supposed to handle a BYE, when the client is 
behind NAT.


 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 11/4/20 10:00 PM, Kjeld Flarup wrote:


Hello again

I have attached a Capture.

My public IP is 194.255.22.44, and I have a port forward of 5071 in my 
router


The Raspberry Pi running the Kamailio is on 192.168.2.9 with an alias 
192.168.2.40


My listening is setup like this

listen=127.0.0.1:5071
listen=eth0:5071  advertise 194.255.22.44:5071
alias=194.255.22.44:5071

Kamailio is forwarding an invite from a door phone thus I also rewrite 
FROM:


uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@194.255.22.44:5071");
And the failure route to
$fu = "sip:"+$dbr(ra=>[0,0])+"@194.255.22.44:5071";

In the route doing the INVITE I also set this:

set_advertised_address("194.255.22.44:5071");


Regarding tcp_reuse_port, if I set this I get this error, which I 
understand is due to the way TCP works.


Nov  4 18:38:41 scantronpbx /usr/sbin/kamailio[15864]: {1 ACK 16191 
ACK C2Az-Xm2b0CEPyV5eQuz7yEf9IJo4PyJ} WARNING:  
[core/tcp_main.c:1061]: tcp_do_connect(): binding to source address 
192.168.2.40:5071 failed: Address already in use [98]


I do have tcp_reuse_port=yes with this capture. But much to my 
surprise, the 200 OK from is send to 37148, but the ACK to it comes 
from 37150



 Med Liberalistiske Hilsner --
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen -www.liberalismen.dk
On 11/4/20 1:59 PM, Carsten Bock wrote:

Hi,

I think you are searching for this parameter:

http://www.kamailio.org/wiki/cookbooks/devel/core#tcp_reuse_port

It basically tells the kernel not to choose a new port at random for 
a new connection, but it will try to reuse the existing port (in your 
case 5071).


Thanks,
Carsten


--
Carsten Bock I CTO & Founder

ng-voice GmbH

Trostbrücke 1 I 20457 Hamburg I Germany
T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com 



Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock



Am Mi., 4. Nov. 2020 um 12:07 Uhr schrieb Kjeld Flarup 
mailto:kjeld.fla...@liberalismen.dk>>:


Hello

I have a Kamailio running behind NAT, which sends calls to a VOIP
service provider.

I have setup the Kamalio to listen on port 5071, and also setup a
port
forward in the router.

Now the problem is that with TCP, 5071 is not used for the
dialog, but a
new port is chosen everytime. This means that when the mobile phone
called hands up, I never sees the BYE, because BYE is a new dialog.


To which port is the server supposed to send the BYE, and what field
tells the server this.


-- 
 Med Liberalistiske Hilsner

--
    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk 


___
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
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Kjeld Flarup]

Hello again

I have attached a Capture.

My public IP is 194.255.22.44, and I have a port forward of 5071 in my 
router


The Raspberry Pi running the Kamailio is on 192.168.2.9 with an alias 
192.168.2.40


My listening is setup like this

listen=127.0.0.1:5071
listen=eth0:5071  advertise 194.255.22.44:5071
alias=194.255.22.44:5071

Kamailio is forwarding an invite from a door phone thus I also rewrite FROM:

uac_replace_from("sip:"+$dbr(ra=>[0,1])+"@194.255.22.44:5071");
And the failure route to
$fu = "sip:"+$dbr(ra=>[0,0])+"@194.255.22.44:5071";

In the route doing the INVITE I also set this:

set_advertised_address("194.255.22.44:5071");


Regarding tcp_reuse_port, if I set this I get this error, which I 
understand is due to the way TCP works.


Nov  4 18:38:41 scantronpbx /usr/sbin/kamailio[15864]: {1 ACK 16191 ACK 
C2Az-Xm2b0CEPyV5eQuz7yEf9IJo4PyJ} WARNING:  
[core/tcp_main.c:1061]: tcp_do_connect(): binding to source address 
192.168.2.40:5071 failed: Address already in use [98]


I do have tcp_reuse_port=yes with this capture. But much to my surprise, 
the 200 OK from is send to 37148, but the ACK to it comes from 37150



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 11/4/20 1:59 PM, Carsten Bock wrote:

Hi,

I think you are searching for this parameter:

http://www.kamailio.org/wiki/cookbooks/devel/core#tcp_reuse_port

It basically tells the kernel not to choose a new port at random for a 
new connection, but it will try to reuse the existing port (in your 
case 5071).


Thanks,
Carsten


--
Carsten Bock I CTO & Founder

ng-voice GmbH

Trostbrücke 1 I 20457 Hamburg I Germany
T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com 



Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock



Am Mi., 4. Nov. 2020 um 12:07 Uhr schrieb Kjeld Flarup 
mailto:kjeld.fla...@liberalismen.dk>>:


Hello

I have a Kamailio running behind NAT, which sends calls to a VOIP
service provider.

I have setup the Kamalio to listen on port 5071, and also setup a
port
forward in the router.

Now the problem is that with TCP, 5071 is not used for the dialog,
but a
new port is chosen everytime. This means that when the mobile phone
called hands up, I never sees the BYE, because BYE is a new dialog.


To which port is the server supposed to send the BYE, and what field
tells the server this.


-- 
 Med Liberalistiske Hilsner --

    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min
tegnebog
    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
    Den ikke akademiske hjemmeside for liberalismen -
www.liberalismen.dk 


___
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


tcpbye.cap
Description: application/vnd.tcpdump.pcap
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] BYE and TCP

[Carsten Bock]

Hi,

I think you are searching for this parameter:

http://www.kamailio.org/wiki/cookbooks/devel/core#tcp_reuse_port

It basically tells the kernel not to choose a new port at random for a new
connection, but it will try to reuse the existing port (in your case 5071).

Thanks,
Carsten


--
Carsten Bock I CTO & Founder

ng-voice GmbH

Trostbrücke 1 I 20457 Hamburg I Germany
T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com

Registry Office at Local Court Hamburg, HRB 120189
Managing Directors: Dr. David Bachmann, Carsten Bock


Am Mi., 4. Nov. 2020 um 12:07 Uhr schrieb Kjeld Flarup <
kjeld.fla...@liberalismen.dk>:

> Hello
>
> I have a Kamailio running behind NAT, which sends calls to a VOIP
> service provider.
>
> I have setup the Kamalio to listen on port 5071, and also setup a port
> forward in the router.
>
> Now the problem is that with TCP, 5071 is not used for the dialog, but a
> new port is chosen everytime. This means that when the mobile phone
> called hands up, I never sees the BYE, because BYE is a new dialog.
>
>
> To which port is the server supposed to send the BYE, and what field
> tells the server this.
>
>
> --
>  Med Liberalistiske Hilsner --
> Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
> Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
> Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
>
> ___
> 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

Re: [SR-Users] BYE and TCP

[Daniel-Constantin Mierla]

Hello,

your message is confusing somehow, what do you mean by "never sees the
BYE, because BYE is a new dialog"?

Maybe you can grab the pcap with sip packets for such call on kamailio
server and sent it over to see if the headers are as expected.

Cheers,
Daniel

On 04.11.20 12:04, Kjeld Flarup wrote:
> Hello
>
> I have a Kamailio running behind NAT, which sends calls to a VOIP
> service provider.
>
> I have setup the Kamalio to listen on port 5071, and also setup a port
> forward in the router.
>
> Now the problem is that with TCP, 5071 is not used for the dialog, but
> a new port is chosen everytime. This means that when the mobile phone
> called hands up, I never sees the BYE, because BYE is a new dialog.
>
>
> To which port is the server supposed to send the BYE, and what field
> tells the server this.
>
>
> -- 
>  Med Liberalistiske Hilsner --
>    Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>    Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>    Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
>
> ___
> 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


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] BYE and TCP

[Kjeld Flarup]

Hello

I have a Kamailio running behind NAT, which sends calls to a VOIP 
service provider.


I have setup the Kamalio to listen on port 5071, and also setup a port 
forward in the router.


Now the problem is that with TCP, 5071 is not used for the dialog, but a 
new port is chosen everytime. This means that when the mobile phone 
called hands up, I never sees the BYE, because BYE is a new dialog.



To which port is the server supposed to send the BYE, and what field 
tells the server this.



--
 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users