Subject: RE: [Sipping] New NAT scenarios draft

From: "Chris Boulton" <[email-masked]>
Date: Tue, 22 Feb 2005 09:26:14 -0000

I agree with Gonzalo.  The main focus of this draft has changed since
its conception.  Rather than conveying many mechanisms for traversing
NAT types the idea was to have one consistent story to try to minimize
the current confusion.

I actually left a placeholder '4.4   Intercepting Intermediary (B2BUA)'
in the draft where I intended to briefly mention such deployments.  This
advanced section is still open for discussion within the WG so this is
the type of dialog we need.

Gonzalo - do you think 4.4 should not be present? - Even if it was just
a brief outline + document limitations of approach.

Francois - would section 4.4 be enough for you?

Regards,

Chris.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: 22 February 2005 07:01
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.

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:
> 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]
> 
> <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] <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-
> 
>
<http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-scenarios->
> 
>>>02 
>>> .txt 
>>>
>>
>><http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-s
> 
> <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
> 
> <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

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.

_______________________________________________
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 13:27:08 +0200

Hi,

> a brief outline + document limitations of approach.

If you want to write a couple of brief paragraphs explaining why 
performing SDP rewriting is not such a good idea and stating that using 
an end-to-end mechanism such as ICE does not have the same problems 
associated to its use, it would be fine with me.

However, I would not like to have examples or explanations on how SDP 
rewriting works or how current systems place themselves in the media path...

Gonzalo