Subject: Re: [Rum] IPv6

From: Ed Sayers <[email-masked]>
Date: Wed, 1 Sep 2021 08:43:13 +0000

Hi Brian,

I am sure this is a bit rough and could do with a tidy up. I think it covers it though:

“
The RUM client MUST support RFC-6052 and RFC-7050 in order to synthesize routable IPv6 addresses. For example, when IPv4 addresses are seen in SIP signalling or SDP but IPv6 addresses are needed by the client.
“

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<https://purplevrs.com/>

[Purple is DEI certified!]
The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

From: Brian Rosen <[email-masked]>
Sent: 31 August 2021 11:23
To: Olle E. Johansson <[email-masked]>
Cc: Ed Sayers <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Rum] IPv6

While I would be willing to work on such a document and as sipvore chair I sure it would be a welcome draft, as author and co-chit here I don’t want a mis ref to it holding up our document.

So, I am happy to include those RFCs as requirements. If you want to suggest any text beyond just making them required, I’d be happy to include it, and we can then work on a more general draft.

Brian

On Tue, Aug 31, 2021 at 6:05 AM Olle E. Johansson <[email-masked]<mailto:[email-masked]>> wrote:

> On 31 Aug 2021, at 11:53, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> I have separated out IPv6 as a topic.
>
> We all know that IPv6 is the way to go, and also necessary as the IPv4 address range has all but dried up.
> However, the transition to IPv6 across the World has not been an easy one and is definitely not 'just SIP'.
>
> It is also very true to say that IPv6 needs to be embraced on endpoints; US mobile phone carriers were forced to start using IPv6 for handsets a long time ago.
> However, huge swathes of the Internet remain IPv4, because adding IPv6 to Infrastructure is not such as easy task to tackle, and because those IP addresses rarely change compared to endpoints.
>
> Again, we all agree - IPv6 is the way to go. But, IPv4, NAT64 and DNS64 are going to be needed for a long time to come.
> For many use-cases, DNS64 and NAT64 hide the transition back to the IPv4 Internet when not supported by Infrastructure.
> But, as we know, SDP include IP addresses that DNS64 and NAT64 cannot see and will not translate.
>
> Therefore, we'd like to propose for consideration that a RUM endpoint must also support the following RFCs as a possible fall back to aid the necessary transition to IPv6 over time:
> * RFC-6052 - IPv6 Addressing of IPv4/IPv6 Translators
> * RFC-7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis

What makes this special for RUM? Isn’t this support needed for all SIP implementations? If this is needed for transition, I would love to see these in a  generic document for SIP - how to implement it, considerations for SIP and offer/answer as well as security considerations.

/O
>
>
> Ed Sayers
> Endpoint SDK Team Lead
> Purple, a Division of ZP Better Together, LLC
> purplevrs.com<http://purplevrs.com>
>
> The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
>
>
>
>
> -----Original Message-----
> From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Rosen
> Sent: 30 August 2021 22:24
> To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
> Cc: Chad Leeper <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> Subject: Re: [Rum] IPv6 and encryption
>
> I don’t think there are ANY alternatives to SRTP.  There are alternatives to DTLS-SRTP.  There are moves within the IETF to deprecate SDES, specifically.  There is push back on that, but it’s an ongoing discussion because SDES isn’t secure enough.   Since all providers I know about anchor media, this only affects the initial hop.  Users really want to hear that their media is protected end to end (at least hop by hop) but our document doesn’t require that.  Again, we need a STANDARDS based solution, and we have to live within the constraints the IETF has for new standards with respect to security.  Like nearly every organization, the IETF is much more security conscious than it was, and won’t tolerate bad security although it often recognizes the necessity for backwards compatibility as long as it’s not to a known insecure mechanism.
>
> I really think this is a “step up to the bar” thing.  We’ve spent lots of time and cycles implementing things that turn out not to be secure enough, and we have to move forward on things that are.  DTLS-SRTP is one of those things, as is IPv6.
>
> Brian
>
>
>> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Chad,
>>
>> Welcome to the RUM WG!
>>
>> On 8/30/21 11:51 AM, Chad Leeper wrote:
>>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going forward, it can't be a "MUST" requirement.  I agree with Roger Slusser that mandating compliance using MUST requires providers to implement significant development to change over to what RUM is specifying.
>>
>> The requirements in this doc will apply only to devices that claim to conform to it. Presumably you could continue to support your existing devices using whatever mechanisms they currently use. So the implementation burden is only on the server side, not the legacy device side. (Of course the FCC will have a say in this.)
>>
>> One motivation for the webrtc requirement is so that a RUE can be built on top of WebRTC. E.g., it can be a server that supports deaf users using any device with a browser. Such a server is effectively just signaling gateway that can establish a p2p link between the browser and the VRS provider server. (It does have to transcode RTT, but that is less of a burden.)
>>
>> When defining a specification for an interface that is to be implemented by independent parties it is necessary for essential functions to have at least one mandatory to implement mechanism. Currently there are no standards for connecting a RUE to a provider, so we need to pick *something* to be mandatory to implement. If you have an alternative for the media you would prefer, then please make a specific proposal.
>>
>>> - We should keep any new privacy requirements very minimal at this time.  While companies in the EU have already created their systems in compliance with the GDPR, most of the world hasn't created an equivalent yet.  So what may look like an easy change to EU implementers may be a dramatic change for others.
>>
>> I don't think we have said much about privacy of retained data. But we are concerned that the media and signaling be private between the RUE and the provider. That is a low bar these days. It is unlikely that anything less could be approved. I expect the FCC will agree.
>>
>> If you have an alternate proposal that achieves that then make a proposal we can discuss.
>>
>>      Thanks,
>>      Paul
>>
>>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>   Providers,
>>>   My request below to Roger should have been broader. You all seem to
>>>   have
>>>   the same issue. I encourage any/all of you to make an alternative
>>>   proposal here. Just saying "we don't like what is there" isn't helpful
>>>   without an alternative.
>>>            Thanks,
>>>            Paul
>>>   On 8/26/21 5:40 PM, Paul Kyzivat wrote:
>>>> Roger,
>>>>
>>>> On 8/26/21 3:30 PM, Roger Slusser wrote:
>>>>
>>>>> Most providers already support encryption and IPV6 on a limited
>>>   scope,
>>>>> not necessarily the way it is defined in RUM spec. Mandating
>>>>> compliance using MUST requires providers to discard sometimes huge
>>>>> amounts of development to change over to what RUM is specifying.
>>>   The
>>>>> push back is not about doing these things it is about the loss of
>>>>> time, effort and money to do them in the way RUM mandates with
>>>   MUSTs.
>>>>
>>>> Do you think there is something else we could write in this spec
>>>   that
>>>> covers encryption and IPv6 in a way that is less burdensome for
>>>> providers while remaining interoperable with all providers?
>>>>
>>>> If so, can you please spell it out?
>>>   --     Rum mailing list
>>>   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>   https://www.ietf.org/mailman/listinfo/rum
>>>   <https://www.ietf.org/mailman/listinfo/rum>
>>
>> --
>> Rum mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum
> --
> Rum mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rum

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Sep 2021 08:15:33 -0400

Wouldn’t this apply to both sides?

Brian

> On Sep 1, 2021, at 4:43 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Brian,
>  
> purplevrs.com <https://purplevrs.com/>	
>  
> On Tue, Aug 31, 2021 at 6:05 AM Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On 31 Aug 2021, at 11:53, Ed Sayers <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > Hi,
> > 
> > purplevrs.com <http://purplevrs.com/>
> > 
> > From: Rum <[email-masked] <mailto:[email-masked]>> On Behalf Of Brian Rosen
> > To: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> > Cc: Chad Leeper <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> >> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> Chad,
> >> 
> >> Welcome to the RUM WG!
> >> 
> >>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>>   Providers,
> >>>   [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >>>   https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> >>>   <https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>>
> >> 
> >> -- 
> >> Rum mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> > 
> > -- 
> > Rum mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> > -- 
> > Rum mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Ed Sayers <[email-masked]>
Date: Wed, 1 Sep 2021 12:18:46 +0000

Hi Brian,

This only affects the client side, because it is the client may be behind a NAT64/DNS64. The server cannot determine those network-specific mappings.

Ed Sayers
Endpoint SDK Team Lead

From: Brian Rosen <[email-masked]>
Sent: 01 September 2021 13:16
To: Ed Sayers <[email-masked]>
Cc: Olle E. Johansson <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Rum] IPv6

Brian

On Sep 1, 2021, at 4:43 AM, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

“

Ed Sayers
Endpoint SDK Team Lead

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 31 August 2021 11:23
To: Olle E. Johansson <[email-masked]<mailto:[email-masked]>>
Cc: Ed Sayers <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] IPv6

Brian

/O
> purplevrs.com<http://purplevrs.com/>
>
>>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>   Providers,

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Sep 2021 08:37:21 -0400

But couldn’t the server be behind a NAT64?

> On Sep 1, 2021, at 8:18 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Brian,
>  
> On Sep 1, 2021, at 4:43 AM, Ed Sayers <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Brian,
>  
> From: Brian Rosen <[email-masked] <mailto:[email-masked]>> 
> To: Olle E. Johansson <[email-masked] <mailto:[email-masked]>>
> Cc: Ed Sayers <[email-masked] <mailto:[email-masked]>>; Paul Kyzivat <[email-masked] <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
> Subject: Re: [Rum] IPv6
>

---

From: Ed Sayers <[email-masked]>
Date: Wed, 1 Sep 2021 12:44:41 +0000

Hi Brian,

If the client is on an IPv4 network, they would tend to see the IPv4 interface for the server, so it tends to not be an issue that way around.

Ed Sayers
Endpoint SDK Team Lead

From: Brian Rosen <[email-masked]>
Sent: 01 September 2021 13:37
To: Ed Sayers <[email-masked]>
Cc: Olle E. Johansson <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Rum] IPv6

On Sep 1, 2021, at 8:18 AM, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Ed Sayers
Endpoint SDK Team Lead

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 01 September 2021 13:16
To: Ed Sayers <[email-masked]<mailto:[email-masked]>>
Cc: Olle E. Johansson <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] IPv6

Brian

Hi Brian,

“

Ed Sayers
Endpoint SDK Team Lead

From: Brian Rosen <[email-masked]<mailto:[email-masked]>>
Sent: 31 August 2021 11:23
To: Olle E. Johansson <[email-masked]<mailto:[email-masked]>>
Cc: Ed Sayers <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] IPv6

Brian

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Sep 2021 10:05:49 -0400

On 9/1/21 8:18 AM, Ed Sayers wrote:
> Hi Brian,
> 
> This only affects the client side, because it is the client may be 
> behind a NAT64/DNS64. The server cannot determine those network-specific 
> mappings.

Does it really make sense to ask the client to do extra work in order to 
save work on behalf of the server? If we ask the server to support both 
then the clients will be able to use whatever kind of addresses they are 
able to obtain.

	Thanks,
	Paul

> **
> *Ed Sayers*
> Purple is DEI certified!
> The information contained in this e-mail message is intended only for 
> the personal and confidential use of the recipient(s) named above. If 
> you have received this communication in error, please notify us 
> immediately by e-mail, and delete the original message.
> 
> *From:*Brian Rosen <[email-masked]>
> *Sent:* 01 September 2021 13:16
> *To:* Ed Sayers <[email-masked]>
> *Cc:* Olle E. Johansson <[email-masked]>; Paul Kyzivat 
> <[email-masked]>; [email-masked]
> *Subject:* Re: [Rum] IPv6
> 
>     The RUM client MUST supportRFC-6052 and RFC-7050 in order to
>     synthesize routable IPv6 addresses. For example, when IPv4 addresses
>     are seen in SIP signalling or SDP but IPv6 addresses are needed by
>     the client.
> 
>     “
> 
>     **
> 
>     *Ed Sayers*
>     Endpoint SDK Team Lead
>     The information contained in this e-mail message is intended only
>     for the personal and confidential use of the recipient(s) named
>     above. If you have received this communication in error, please
>     notify us immediately by e-mail, and delete the original message.
> 
>     *From:*Brian Rosen <[email-masked] <mailto:[email-masked]>>
>     *Sent:*31 August 2021 11:23
>     *To:*Olle E. Johansson <[email-masked] <mailto:[email-masked]>>
>     *Cc:*Ed Sayers <[email-masked] <mailto:[email-masked]>>;
>     Paul Kyzivat <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:*Re: [Rum] IPv6
> 
>     While I would be willing to work on such a document and as sipvore
>     chair I sure it would be a welcome draft, as author and co-chit here
>     I don’t want a mis ref to it holding up our document.
> 
>     So, I am happy to include those RFCs as requirements. If you want to
>     suggest any text beyond just making them required, I’d be happy to
>     include it, and we can then work on a more general draft.
> 
>     Brian
> 
>          > We all know that IPv6 is the way to go, and also necessary as
>         the IPv4 address range has all but dried up.
>          > However, the transition to IPv6 across the World has not been
>         an easy one and is definitely not 'just SIP'.
>          >
>          > It is also very true to say that IPv6 needs to be embraced on
>         endpoints; US mobile phone carriers were forced to start using
>         IPv6 for handsets a long time ago.
>          > However, huge swathes of the Internet remain IPv4, because
>         adding IPv6 to Infrastructure is not such as easy task to
>         tackle, and because those IP addresses rarely change compared to
>         endpoints.
>          >
>          > Again, we all agree - IPv6 is the way to go. But, IPv4, NAT64
>         and DNS64 are going to be needed for a long time to come.
>          > For many use-cases, DNS64 and NAT64 hide the transition back
>         to the IPv4 Internet when not supported by Infrastructure.
>          > Therefore, we'd like to propose for consideration that a RUM
>         endpoint must also support the following RFCs as a possible fall
>         back to aid the necessary transition to IPv6 over time:
>         What makes this special for RUM? Isn’t this support needed for
>         all SIP implementations? If this is needed for transition, I
>         would love to see these in a  generic document for SIP - how to
>         implement it, considerations for SIP and offer/answer as well as
>         security considerations.
> 
>         /O
>          >
>          >
>          > Ed Sayers
>          > Endpoint SDK Team Lead
>          > The information contained in this e-mail message is intended
>         only for the personal and confidential use of the recipient(s)
>         named above. If you have received this communication in error,
>         please notify us immediately by e-mail, and delete the original
>         message.
>          >
>          >
>          >
>          >
>          > From: Rum <[email-masked]
>         <mailto:[email-masked]>> On Behalf Of Brian Rosen
>          > Cc: Chad Leeper <[email-masked]
>         <mailto:[email-masked]>>;[email-masked]
>         <mailto:[email-masked]>
>          > I don’t think there are ANY alternatives to SRTP.  There are
>         alternatives to DTLS-SRTP.  There are moves within the IETF to
>         deprecate SDES, specifically.  There is push back on that, but
>         it’s an ongoing discussion because SDES isn’t secure enough. 
>           Since all providers I know about anchor media, this only
>         affects the initial hop.  Users really want to hear that their
>         media is protected end to end (at least hop by hop) but our
>         document doesn’t require that.  Again, we need a STANDARDS based
>         solution, and we have to live within the constraints the IETF
>         has for new standards with respect to security.  Like nearly
>         every organization, the IETF is much more security conscious
>         than it was, and won’t tolerate bad security although it often
>         recognizes the necessity for backwards compatibility as long as
>         it’s not to a known insecure mechanism.
>          >
>          > I really think this is a “step up to the bar” thing.  We’ve
>         spent lots of time and cycles implementing things that turn out
>         not to be secure enough, and we have to move forward on things
>         that are.  DTLS-SRTP is one of those things, as is IPv6.
>          >
>          > Brian
>          >
>          >
>          >> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>> wrote:
>          >>
>          >> Chad,
>          >>
>          >> Welcome to the RUM WG!
>          >>
>          >>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent
>         idea going forward, it can't be a "MUST" requirement.  I agree
>         with Roger Slusser that mandating compliance using MUST requires
>         providers to implement significant development to change over to
>         what RUM is specifying.
>          >>
>          >> The requirements in this doc will apply only to devices that
>         claim to conform to it. Presumably you could continue to support
>         your existing devices using whatever mechanisms they currently
>         use. So the implementation burden is only on the server side,
>         not the legacy device side. (Of course the FCC will have a say
>         in this.)
>          >>
>          >> One motivation for the webrtc requirement is so that a RUE
>         can be built on top of WebRTC. E.g., it can be a server that
>         supports deaf users using any device with a browser. Such a
>         server is effectively just signaling gateway that can establish
>         a p2p link between the browser and the VRS provider server. (It
>         does have to transcode RTT, but that is less of a burden.)
>          >>
>          >> When defining a specification for an interface that is to be
>         implemented by independent parties it is necessary for essential
>         functions to have at least one mandatory to implement mechanism.
>         Currently there are no standards for connecting a RUE to a
>         provider, so we need to pick *something* to be mandatory to
>         implement. If you have an alternative for the media you would
>         prefer, then please make a specific proposal.
>          >>
>          >>> - We should keep any new privacy requirements very minimal
>         at this time.  While companies in the EU have already created
>         their systems in compliance with the GDPR, most of the world
>         hasn't created an equivalent yet.  So what may look like an easy
>         change to EU implementers may be a dramatic change for others.
>          >>
>          >> I don't think we have said much about privacy of retained
>         data. But we are concerned that the media and signaling be
>         private between the RUE and the provider. That is a low bar
>         these days. It is unlikely that anything less could be approved.
>         I expect the FCC will agree.
>          >>
>          >>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat
>         <[email-masked]
>         <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>          >>>   Providers,
>          >>> [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>
>          >>>   <https://www.ietf.org/mailman/listinfo/rum
>         <https://www.ietf.org/mailman/listinfo/rum>>
>          >>
>          >> --
>          >> Rum mailing list

---

From: Ed Sayers <[email-masked]>
Date: Wed, 1 Sep 2021 14:09:01 +0000

Hi Paul,

This doesn't save work. It allows the client to do something that the server cannot do.
This provides the mechanism to cover a wider range of scenarios and a greater chance of ensuring success.

As I think Olle already indicated previously, it is assumed that clients are already capable of doing this. But, it is not called out anywhere..

Ed Sayers
Endpoint SDK Team Lead
purplevrs.com

-----Original Message-----
From: Paul Kyzivat <[email-masked]> 
Sent: 01 September 2021 15:06
To: Ed Sayers <[email-masked]>; Brian Rosen <[email-masked]>
Cc: Olle E. Johansson <[email-masked]>; [email-masked]
Subject: Re: [Rum] IPv6

On 9/1/21 8:18 AM, Ed Sayers wrote:
> behind a NAT64/DNS64. The server cannot determine those 
> network-specific mappings.

Does it really make sense to ask the client to do extra work in order to save work on behalf of the server? If we ask the server to support both then the clients will be able to use whatever kind of addresses they are able to obtain.

	Thanks,
	Paul

> **
> 
> *Ed Sayers*
> Endpoint SDK Team Lead
> Purple, a Division of ZP Better Together, LLC purplevrs.com 
> <https://purplevrs.com/>
> 
> 	
> 
> Purple is DEI certified!
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 1 Sep 2021 16:11:25 +0200

I keep wanting examples, which is why I wanted some document here before we make any decision.

If you are using UDP, there are a load of issues. But if we’re targeting TLS for SIP, the client will always be responsible for reaching the server and there won’t be any problem with the server knowing any ip addresses where the client can be reached.

So TLS/TCP makes life easier.

/O

> On 1 Sep 2021, at 16:09, Ed Sayers <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 1 Sep 2021 15:54:37 -0400

> As I think Olle already indicated previously, it is assumed that clients are already capable of doing this. But, it is not called out anywhere..

I'm not getting it. Can you explain further?

Everything begins with the RUE registering with the server. As long as 
the server offers both v4 and v6 in its DNS entry then the client will 
be able to complete that the registration using whichever it has. Then 
signaling for calls, in both directions. will reuse the TLS connection 
from registration.

For media both ends can offer whichever of v4 or v6 they are using for 
signaling.

So NAT64/DNS64 isn't required.

What am I missing?

	Thanks,
	Paul