Subject: RE: [Sipping] New NAT scenarios draft

From: "Francois Audet" <[email-masked]>
Date: Mon, 21 Feb 2005 18:25:22 -0500

Hi Gonzalo,

B2BUAs can do whatever they want (and they do), as long as it is
SIP on both sides.

There is nothing "illegal" about that.

Proxies obviously can not touch SDPs (that would indeed be illegal).

The last time the IETF pretended that something didn't exist created
the NAT fiasco. Hopefully we will not do this again. I'd much rather
we acknowledge it, and put the usual warnings about it.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Monday, February 21, 2005 12:28
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Chris Boulton'; 'sipping'
> Subject: Re: [Sipping] New NAT scenarios draft
> 
> 
> Hi Francois,
> 
> SDP rewriting is not allowed by the SIP spec, and so, I would 
> not like to document it in this draft. SDP rewriting will be 
> documented in the SBC Functions draft as something that is 
> illegal from the SIP point of view.
> 
> Note that the NAT scenarios draft intends to show examples of 
> how to traverse NATs using standard mechanisms, as opposed to 
> document what current deployments use.
> 
> Thanks,
> 
> Gonzalo
> 
> Francois Audet wrote:
> > Hi Chris,
> > 
> > Good job.
> > 
> > My only comment is the following.
> > 
> > The description of "media relay" in 3.2.3 is incomplete. It talks
> > about TURN only, which is one way of doing a media relay.
> > 
> > For a media relay to function, there are essentially two
> > alternatives:
> > 
> > *	The media relay is effectively controlled by SIP/SDP, where IP 
> > addresses are modified to funnel the media through the media relay.
> > The SIP intelligence is some sort of B2BUA (because at a minimum it 
> > must be able to modify IP addresses and ports in the SDP to 
> redirect 
> > the media). The main characteristics of this approach is 
> that it does
> >  not require a new protocol between the media termination 
> (e.g., SIP 
> > UA) and the media relay, but that on the other hand, it requires a 
> > B2BUA (which places some restrictions on encryption, and overall 
> > transparency). *	A media relay explicitely controlled by a media 
> > relay protocol. TURN.
> > 
> > Here is what I propose.
> > 
> > Split 3.2.3 into 3.2.3.1 and 3.2.3.2. Explain in 3.2.3 (top level)
> > the role of media relays in general, including the fact 
> that they are
> >  a solution of last resort.
> > 
> > Describe the SIP-controlled Media relay in 3.2.3.1, and 
> describe TURN  
> > in 3.2.3.2.
> > 
> > In 3.2.3.1, you could put a pointer to your currently empty section
> > 4.4 on Intercepting Intermediaries. Or, alternatively, you could 
> > include all the material in 3.2.3.1 if you don't plan to 
> have a huge 
> > amount of text on the topic. Concepts to mention in there include: 
> > the fact that an "SBC" is an example of this architecture. 
> If the SIP
> >  intelligence is not co-located with the media relay, one 
> could use a
> >  protocol (e.g., MIDCOM) to control the media relay. It would
> > probably make sense to describe that this model only is applicable
> > when no end-to-end encryption of the SDP (e.g., S/MIME) is used.
> > 
> > I don't want to turn this into a debate between TURN and a
> > SIP-controlled media relay. There are valid scenarios for both, and 
> > that is basically what we should be stating in there.
> > 
> > Is this OK with you?
> > 
> > 
> > 
> > -----Original Message----- From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Chris Boulton Sent: 
> > Monday, February 21, 2005 02:14 To: sipping Cc: Gonzalo Camarillo 
> > Subject: [Sipping] New NAT scenarios draft
> > 
> > 
> > 
> > All,
> > 
> > We have submitted a new version of the NAT scenarios draft. Until it
> > is officially announced it can be found at the following link:-
> > 
> > 
> > 
> > 
> http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-scenarios-
> > 02
> >  .txt 
> > 
> <http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-s
> cenarios-0
> >  2.txt>
> > 
> > 
> > 
> > This version of the draft expands on some of the core examples and
> > also corrects some general mistakes.  I would really appreciate as 
> > much feedback as possible on this draft to gauge whether you folks 
> > like the direction + format.  I'm looking to get this draft in a 
> > stable state for presentation at the Paris IETF so your feedback at 
> > this stage is extremely important.
> > 
> > 
> > 
> > Best Regards,
> > 
> > 
> > 
> > Chris Boulton.
> > 
> > 
> > 
> > 
> > 
> > Information contained in this e-mail and any attachments 
> are intended  
> > for the use of the addressee only, and may contain confidential 
> > information of Ubiquity Software Corporation. All unauthorized use, 
> > disclosure or distribution is strictly prohibited.  If you 
> are not the 
> > addressee, please notify the sender immediately and destroy 
> all copies 
> > of this email.  Unless otherwise expressly agreed in a 
> writing  signed 
> > by an officer of Ubiquity Software Corporation, nothing in this 
> > communication shall be deemed to be legally binding. Thank-you
> > 
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
> 
> 
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Feb 2005 09:00:44 +0200

Hi,

we are not ignoring the problem. We are working on it, but using another 
document (the SBC Funtions draft).

As you know, SDP rewriting has a set of problems associated to it. The 
NAT scenarios draft describes how to perform NAT traversal without these 
problems. In my opinion, that's the scope this draft should have.

The whole point with the SBC work is to identify funtions that are 
needed by operators (e.g., NAT traversal) and to provide "friendly" 
mechanisms to provide those funtions. In this case, we already have the 
"friendly" mechanism (i.e., ICE), and that's what we are documenting here.

Of course, if there was a requirement related to NAT traversal that 
could be met by using a B2BUA but could not be by using the mechanisms 
described in this draft, we would need to analyze it and decide what to 
do...

Thanks,

Gonzalo

Francois Audet wrote:
>>From: Gonzalo Camarillo [mailto:[email-masked]
> 
> <mailto:[email-masked]> ] 
> 
>>>[mailto:[email-masked] <mailto:[email-masked]> ]
> 
> On Behalf Of Chris Boulton Sent: 
> 
> <http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-scenarios->
> 
>>>02 
>>> .txt 
>>>
>>
> <http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-s>  
> 
>>cenarios-0 
>>
>>> 2.txt> 
>>>
>>>
>>>
> <http://www.hut.fi/~gonzalo>  
> 
>>
>>
>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 23 Feb 2005 21:02:18 -0500

Gonzalo,

Just a comment on NAT Traversal. I think you are assuming that there is only
one NAT (adjacent to the user element). Can you explain how ICE solves the
general NAT Traversal problem (like UE-NAT-NAT-NAT-UE, UE's are aware of
juxtaposed NATs).

-Medhavi.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo
> Camarillo
> Sent: Tuesday, February 22, 2005 2:01 AM
> To: Francois Audet

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Feb 2005 09:30:00 +0200

Hi,

ICE explains how to gather addresses using different mechanisms (it
recommends to use TURN and STUN, but you could potentially use other
mechanisms such as session policies). You would gather IP addresses in
the appropriate address realms and then generate your offer. The ICE
spec also explains how to use end-to-end STUN checks to discover new
addresses.

Regards,

Gonzalo

Medhavi Bhatia wrote:
> Gonzalo,
> 
> Just a comment on NAT Traversal. I think you are assuming that there
> is only one NAT (adjacent to the user element). Can you explain how
> ICE solves the general NAT Traversal problem (like UE-NAT-NAT-NAT-UE,
> UE's are aware of juxtaposed NATs).
> 
> -Medhavi.
> 
> 
>> [mailto:[email-masked]] On Behalf
> 
> Of Gonzalo
> 
>> Camarillo Sent: Tuesday, February 22, 2005 2:01 AM To: Francois
>> Audet Cc: 'Chris Boulton'; 'sipping' Subject: Re: [Sipping] New NAT
>> scenarios draft
>> 
>> Hi,
>> 
>> we are not ignoring the problem. We are working on it, but using
>> another document (the SBC Funtions draft).
>> 
>> As you know, SDP rewriting has a set of problems associated to it.
>> The NAT scenarios draft describes how to perform NAT traversal
>> without these problems. In my opinion, that's the scope this draft
>> should have.
>> 
>>  mechanisms to provide those funtions. In this case, we already
>> have the "friendly" mechanism (i.e., ICE), and that's what we are
>> documenting here.
>> 
>>  could be met by using a B2BUA but could not be by using the
>> mechanisms described in this draft, we would need to analyze it and
>> decide what to do...
>> 
>> Thanks,
>> 
>> Gonzalo
>> 
>> 
>> Francois Audet wrote:
>> 
>>> Hi Gonzalo,
>>> 
>>> The last time the IETF pretended that something didn't exist
>>> created the NAT fiasco. Hopefully we will not do this again. I'd
>>> much rather we acknowledge it, and put the usual warnings about
>>> it.
>>> 
>>> 
>>> 
>>>> -----Original Message----- From: Gonzalo Camarillo
>>>> [mailto:[email-masked]
>>> 
>>>> Sent: Monday, February 21, 2005 12:28 To: Audet, Francois
>>>> [SC100:9T51:EXCH] Cc: 'Chris Boulton'; 'sipping' Subject: Re:
>>>> [Sipping] New NAT scenarios draft
>>>> 
>>>> 
>>>> Hi Francois,
>>>> 
>>>>> The description of "media relay" in 3.2.3 is incomplete. It
>>>>> talks about TURN only, which is one way of doing a media
>>>>> relay.
>>>>> 
>>>>> *   The media relay is effectively controlled by SIP/SDP,
>>>>> where IP addresses are modified to funnel the media through
>>>>> the media relay. The SIP intelligence is some sort of B2BUA
>>>>> (because at a minimum it must be able to modify IP addresses
>>>>> and ports in the SDP to
>>>> 
>>>> redirect
>>>> 
>>>> 
>>>>> UA) and the media relay, but that on the other hand, it
>>>>> requires a B2BUA (which places some restrictions on
>>>>> encryption, and overall transparency). *    A media relay
>>>>> explicitely controlled by a media relay protocol. TURN.
>>>>> 
>>>>> Here is what I propose.
>>>>> 
>>>>> Split 3.2.3 into 3.2.3.1 and 3.2.3.2. Explain in 3.2.3 (top
>>>>> level) the role of media relays in general, including the
>>>>> fact
>>>> 
>>>> that they are
>>>> 
>>>> 
>>>>> In 3.2.3.1, you could put a pointer to your currently empty
>>>>> section 4.4 on Intercepting Intermediaries. Or,
>>>>> alternatively, you could include all the material in 3.2.3.1
>>>>> if you don't plan to
>>>> 
>>>> have a huge
>>>> 
>>>> 
>>>>> amount of text on the topic. Concepts to mention in there
>>>>> include: the fact that an "SBC" is an example of this
>>>>> architecture.
>>>> 
>>>> If the SIP
>>>> 
>>>> 
>>>>> probably make sense to describe that this model only is
>>>>> applicable when no end-to-end encryption of the SDP (e.g.,
>>>>> S/MIME) is used.
>>>>> 
>>>>> SIP-controlled media relay. There are valid scenarios for
>>>>> both, and that is basically what we should be stating in
>>>>> there.
>>>>> 
>>>>> Is this OK with you?
>>>>> 
>>>>> 
>>>>> 
>>>>> Monday, February 21, 2005 02:14 To: sipping Cc: Gonzalo
>>>>> Camarillo Subject: [Sipping] New NAT scenarios draft
>>>>> 
>>>>> 
>>>>> 
>>>>> All,
>>>>> 
>>>>> 02 .txt
>>>>> This version of the draft expands on some of the core
>>>>> examples and also corrects some general mistakes.  I would
>>>>> really appreciate as much feedback as possible on this draft
>>>>> to gauge whether you folks like the direction + format.  I'm
>>>>> looking to get this draft in a stable state for presentation
>>>>> at the Paris IETF so your feedback at this stage is extremely
>>>>> important.
>>>>> 
>>>>> 
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> 
>>>>> 
>>>>> Chris Boulton.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> for the use of the addressee only, and may contain
>>>>> confidential information of Ubiquity Software Corporation.
>>>>> All unauthorized use, disclosure or distribution is strictly
>>>>> prohibited.  If you
>>>> 
>>>> are not the
>>>> 
>>>> 
>>>>> by an officer of Ubiquity Software Corporation, nothing in
>>>>> this communication shall be deemed to be legally binding.
>>>>> Thank-you
>>>>> 
>>>> 
>>>> -- Gonzalo Camarillo         Phone :  +358  9 299 33 71 Oy L M
>>>> Ericsson Ab        Mobile:  +358 40 702 35 35 Telecom R&D
>>>> Fax   :  +358  9 299 30 52 FIN-02420 Jorvas          Email :
>>>> [email-masked] Finland
>>>> http://www.hut.fi/~gonzalo
>>> 
>> -- Gonzalo Camarillo         Phone :  +358  9 299 33 71 Oy L M
>> Ericsson Ab        Mobile:  +358 40 702 35 35 Telecom R&D
>> Fax   :  +358  9 299 30 52 FIN-02420 Jorvas          Email :
>> [email-masked] Finland
>> http://www.hut.fi/~gonzalo
>> 
>> 
>> _______________________________________________ Sipping mailing
>> list  https://www1.ietf.org/mailman/listinfo/sipping This list is
>> for NEW development of the application of SIP Use
>> [email-masked] for questions on current sip Use
>> [email-masked] for new developments of core SIP
> 
> 
> 
> 
> 
> _______________________________________________ Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW
> development of the application of SIP Use
> [email-masked] for questions on current sip Use
> [email-masked] for new developments of core SIP

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 24 Feb 2005 10:27:31 -0500

Gonzalo,

I think all these mechanisms require cooperation from the client. In my
example below, (UE-NAT1-NAT2-NAT3-UE), the STUN/TURN servers will be placed
between NAT1/NAT2 and NAT3/NAT2. Traversing NAT1 and NAT3 is easy. I don't
think traversing NAT2 is covered using STUN/TURN.

-Medhavi.

Of Gonzalo
> Camarillo
> Sent: Thursday, February 24, 2005 2:30 AM
> To: Medhavi Bhatia
> Cc: 'Francois Audet'; 'sipping'; 'Chris Boulton'

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Feb 2005 17:36:10 +0200

Hi,

> I think all these mechanisms require cooperation from the client.

Yes.

> In my

If you think that your scenario is not covered by ICE, you should send 
your feedback to the MMUSIC mailing list and to the author of ICE 
(Jonathan). They are the ones developing the solution. The NAT Scenarios 
draft only provides examples on how to use that solution.

Thanks,

Gonzalo

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 24 Feb 2005 11:14:52 -0500

Gonzalo,

My intention was not to influence the NAT Scenarios draft in any way. I
should have probably started another thread on the comment you made earlier
as part of the existing thread. Sorry for confusion. I think I made my point
and that pretty much winds this up. If folks agree or disagree we can
discuss this in a separate thread.

-Medhavi.

Of Gonzalo
> Camarillo
> Sent: Thursday, February 24, 2005 10:36 AM
> To: Medhavi Bhatia