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, <kjeld.fla...@liberalismen.dk
<mailto:kjeld.fla...@liberalismen.dk>> wrote:
Hi Daniel
The Record route in the INVITE from 194.247.61.26 sets this pair
Record-Route:
<sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1>
Record-Route:
<sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1>
The Bye requests this route
Route:
<sip:194.255.22.44:7071;transport=tcp;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1>
Route:
<sip:194.255.22.44:7071;r2=on;lr=on;ftag=6acjlRdN~;did=836.f1b1>
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
<http://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
<http://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
<http://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
<http://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
<http://194.247.61.32:5040>, which cannot deliver it further
based on Route header. The system at 194.247.61.26:5070
<http://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
<http://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
<mico...@gmail.com <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 <mico...@gmail.com <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"
<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:
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
<j...@tutpro.com <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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@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@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@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@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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@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
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@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
