[SR-Users] BYE and TCP
Daniel-Constantin Mierla
miconda at gmail.com
Mon Nov 9 12:06:28 CET 2020
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
> <miconda at gmail.com <mailto:miconda at 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
>> <miconda at gmail.com <mailto:miconda at 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"
>> <sip:32221660 at 194.255.22.44:5071>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
>> To: <sip:004540294149 at 127.0.0.1:5071>;tag=12003375157297.
>> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>>
>> And the BYE:
>>
>> From: "Front Door"
>> <sip:u0 at 192.168.2.9>;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
>>> <jh at tutpro.com <mailto:jh at 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
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> <mailto:sr-users at lists.kamailio.org>
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> <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 <http://www.liberalismen.dk>
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org <mailto:sr-users at 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.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>
>>
>>
>>
>> --
>>
>> --------------------- 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 <http://www.liberalismen.dk>
>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org <mailto:sr-users at 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.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>
>
>
>
> --
>
> --------------------- 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 <http://www.liberalismen.dk>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201109/3cd9827d/attachment.htm>
More information about the sr-users
mailing list