Subject: RE: [Sipping] New NAT scenarios draft

From: "Francois Audet" <[email-masked]>
Date: Mon, 21 Feb 2005 13:48:45 -0500

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-scenarios-02.tx
t> 

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 

_______________________________________________
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: Mon, 21 Feb 2005 22:28:09 +0200

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