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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
