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

[Bogdan-Andrei Iancu]

Hi Daniel,

Please see inline.

Regards

Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   http://www.opensips-solutions.com

On 10/27/2017 10:24 PM, Daniel Lakeland wrote:
> 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?)
[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.
>
> 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?
[bogdan]
YEs, it will try to open a new TCP conn, but if the end-device is behind 
a NAT, it will most probably fail.
> If it can't what does it do?
[bogdan]
The request OpenSIPS was trying to relay will be automatically be 
answered with 477 negative reply (as a result of the failure at the 
network layer)
> Does it drop the call even though I don't have the dialog "B" flag?
[bogdan]
by itself OpenSIPS will not - it will be the decision of the end-point 
to keep (or not) the call if a sequential request failed.
> 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").
[bogdan]
The dialog will still be removed from OpenSIPS memory, but no BYE 
request sent.
> 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.
>
>
> 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?
[bogdan]
Any TCP based protocol will try to open, if tcp_no_new_conn_bflag is 
off. So, if the SIP URI correctly points to the end device (as IP+port), 
OpenSIPS should be able to reach back the end-device.
>
> 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.
[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.
>
> Thanks for any help!
>
> Dan
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users