8 Jan
2021
8 Jan
'21
2:36 p.m.
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(a)gmail.com <mailto:miconda@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:
--
Daniel-Constantin Mierla --www.asipto.com
www.twitter.com/miconda --www.linkedin.com/in/miconda
Funding:https://www.paypal.me/dcmierla 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(a)gmail.com <mailto:miconda@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@194.255.22.44:5071>;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To: <sip:004540294149@127.0.0.1:5071>;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
And the BYE:
From: "Front Door"
<sip:u0@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:
--
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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(a)tutpro.com <mailto:jh@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(a)lists.kamailio.org
<mailto: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
<http://www.liberalismen.dk>
_______________________________________________
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
--
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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users