On 11/01/2017 07:16 AM, Bogdan-Andrei Iancu wrote:
Bogdan: thanks so much for your detailed info on what happens. I think
this will help me debug stuff. I have some further questions below if
you have time.
Suppose I have a phone that registers to opensips using TLS. This is
a TCP based socket. Suppose that the phone is ipv4, so it's behind a
NAT. Well, in truth, it's probably behind multiple layers of NAT,
potentially a carrier grade NAT somewhere deep in the bowels of an
ISP, then potentially a customer service ADSL modem or the like, and
then a router that I have control over. As I understand it after
setting TCP_PERSISTENT Opensips should leave this TLS connection open
and can then pass further reinvites, pings, and soforth down the same
socket. This is particularly true if the phone supports Sip Outbound
RFC 5626 (all ok so far?)
[bogdan]
The only thing required for the end point is not to close the
connection. On its side, OpenSIPS will keep the TCP Conn alive for the
whole duration of the registration, so the user is reachable.
My impression is that over WiFi if there are momentary lapses in
connectivity, Android may sometimes decide that it needs to reassociate
to a new network, scan, then reassociate to the same network (this is
different from a simple roaming between APs and very different from an
802.11r fast transition). Even though it's associated to the same
network, it still resets TCP connections. This means the TCP connection
to OpenSIPS drops. If this occurs in the middle of a call, it sounds
like I have to get lucky and hope that OpenSIPS reopens the connection
to my phone via its reachable IPv6 address. In the absence of that, my
call is probably going to drop. It also sounds like this might rarely
work due to ephemeral ports on my client.
Suppose further that after a while with Opensips in this reset state
with no open connection to my phone, my phone re-registers and a TLS
connection is available, will Opensips be able to pass reinvites and
pings for ongoing calls down this new socket? Does it understand that
this is the same phone and that this new registration+socket is
relevant to the ongoing dialog?
[bogdan]
jumping on new connection during a SIP session is not easy. As the TCP
connections uses ephemeral ports, there are some internal aliases kept
by OpenSIPS between SIP URIs and the actual TCP connections. A new
connection means a new TCP port -> the existing aliases will not work.
If the client sends some kind of unique ID, such as a standard
Sip_instance (for example used by OBI ATAs and in a UUID format) or an
rinstance attribute (used by Bria on Android and just in
;rinstance=.........; with a big hex number in there or whatever
(admittedly it seems like clients do a lot of different stuff here). Can
/ Does OpenSIPS try to reassociate its connection to the same instance?
[bogdan]
All the time you need to consider both layer - the transport and the
SIP layer. If the registration (at SIP layer) is not reachable anymore
(based on the transport layer), the registration must be invalidated.
You can do this based on registration SIP pinging in OpenSIPS.
With the end-to-end nature of Ipv6 it seems we have a definite
possibility to avoid a lot of hassle with opensips able to directly
open a new sip connection to the phone to continue ongoing dialogs.
Is this a possibility for why I'm experiencing fewer random dropped
calls?
[bogdan]
I wouldn't gamble on it.
This seems to be a major bottleneck for reliable calls over TLS via
WiFi. If the TLS connection can't be maintained because momentary WiFi
droppage causes reset packets to be sent by Android OS or other OS then
the registration is invalidated and the call will drop as soon as the
remote party tries to do anything (such as reINVITE or the like). This
will be true even though the RTP is traveling around just fine. Is that
more or less the sum of it?
Are there things I could do to improve this situation? Suppose far end
wants to reINVITE either as a kind of pinging, or for a hold or
something. It sends SIP message to OpenSIPS, now over the last few
minutes OpenSIPS lost the specific registration from my client, and then
regained it when my client re-opened the connection. Is there a way I
can make OpenSIPS know what happened and forward my phone the INVITE on
the new socket? What things need to be supported on the client? What
needs configuration in the server?
Thanks again.
Dan
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
