[SR-Users] BYE and TCP
Kjeld Flarup
kjeld.flarup at liberalismen.dk
Fri Jan 8 20:36:28 CET 2021
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
>> <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
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --------------------- 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
>>>
>>> --
>>> 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
>>>
>>>
>>>
>>> --
>>>
>>> --------------------- 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
>>
>>
>> --
>> 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
>>
>>
>>
>> --
>>
>> --------------------- 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/20210108/489fbc91/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: downloaded - 2021-01-08T092642.877.pcap
Type: application/vnd.tcpdump.pcap
Size: 47780 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210108/489fbc91/attachment.pcap>
More information about the sr-users
mailing list