[OpenSIPS-Users] Further adventures in dual-stack ipv6/ipv4 questions

[Daniel Lakeland]

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