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

[Daniel Lakeland]

So, at the moment, while topology hiding my network from ipv4 only 
devices, I seem to be getting decent call performance. In fact, after 
changing my create_dialog() call to not have "pPB" parameters, I'm now 
not experiencing some of the random drop-outs that I experienced before. 
This makes me suspect that the random drop-outs that I experienced 
before enabling ipv6 were NAT related and due to pings not reaching 
their intended destination. So now here's a question about how opensips 
works when using TLS/TCP and how this interacts with firewalls and NAT 
and ipv6.

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?)

Suppose that some NAT or firewall somewhere incorrectly ages out this 
TCP connection, or somewhere tcp_keepalive packets are being eaten, or 
the like and when opensips tries to ping or receives a reinvite from the 
far end that it tries to forward to my phone, it receives a connection 
reset on the socket to my phone. Suppose further that the 
tcp_no_new_conn_bflag is NOT set so Opensips is allowed to try to reopen 
the connection. Does Opensips try to reach the phone with a new 
connection? If it can't what does it do? Does it drop the call even 
though I don't have the dialog "B" flag? Or, does it just wait until 
maybe the phone notices and re-opens the connection itself? Suppose that 
I do not have the "bye" flag in my dialog but I do have "ping" ie 
create_dialog("Pp"). 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?

Now, suppose we enable ipv6 and our phone is capable of ipv6. Under this 
scenario provided firewalls are willing, a new TCP connection could be 
created. Will Opensips do this if the socket drops? How does TLS and TCP 
interact here? does TLS also try to open new connections or only TCP?

Clearly, the connectionless UDP protocol doesn't have this connection 
reset issue, and so once a phone is registered, opensips will send 
things to the registration location, and if they're not received it 
doesn't know except via timeout and resend. But with TCP or TLS if the 
connection is broken I'd like to know how Opensips handles this case 
because this could be a serious issue with reliability of phone calls 
and random drops when TLS security is used with ipv4 + NAT, and I'm 
wondering if ipv6 will solve this issue at least with respect to 
end-to-end connections.

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?

Thanks for any help!

Dan