Further adventures in dual-stack ipv6/ipv4 questions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Further adventures in dual-stack ipv6/ipv4 questions

Bogdan-Andrei Iancu-2
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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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





_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Further adventures in dual-stack ipv6/ipv4 questions

Daniel Lakeland
On 11/07/2017 09:22 AM, Daniel Lakeland wrote:

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

It may help to know that I did the following test just now:

Bria 3.9.6.99409 on Android registered to OpenSIPS via ipv6 which then
talks to Asterisk on same server.

Connect to OpenSIPS via Wifi using TLS on ipv6 only network, call
asterisk to extension that reads the time for several minutes

While listening to the time, turn off Wifi entirely and wait about 4
seconds... phone now switches to T-Mobile ipv6 mobile data network,
magically audio returns after a few seconds.

Now, put phone into airplane mode, then turn on  just wifi.

Magically after several seconds, audio returns...

I didn't do packet captures etc, so I'm not sure what SIP messages were
sent. But my guess is that when connection dropped, Bria was
re-connecting, and then re-inviting the call to its new address. Bria is
probably sending the Call-ID so the momentary losses of
connections/registrations were OK for this call.

Now, if OpenSIPS had sent a ping, or the remote end had reINVITED during
the period after I turned off wifi and before Bria got itself connected
to OpenSIPS on the mobile network... or the like... I imagine I might
have had a different experience.



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users