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