[OpenSIPS-Users] Further adventures in dual-stack ipv6/ipv4 questions
dlakelan at street-artists.org
Tue Nov 7 12:22:02 EST 2017
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?)
> 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?
> 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?
> 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
> 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?
More information about the Users