Subject: RE: [Sipping] New NAT scenarios draft

From: "Chris Boulton" <[email-masked]>
Date: Tue, 22 Feb 2005 15:17:20 -0000

Chris:

Thanks for the work on this draft. A question regarding the following
blurb on

profiles...

> A client falling into the 'Minimal' profile will send/receive RTP
> form the same IP/port combination.  This client requires proprietary
> network based solutions to function in any NAT traversal scenario.

It's hard to see how a purely network based solution would function
using

just this "minimal" profile on the part of the client. In contrast, a
solution seems 

straightforward if the client also supports symmetrical signaling. This
definition of 

the "minimal" profile seems to imply that you can visualize a purely
network based 

solution without requiring symetric signaling. If so, can you fill in
the blanks for me? 

If not, should the minimal profile include symmetric signaling as well?

[Chris Boulton] Shaun - the profiles are only in association with
'media' and in no way relate to signaling.  This statement is just
saying at the very least a client should send/receive RTP on the same IP
/port combination.  

Thanks and cheers,

Shaun

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]]On Behalf Of Chris Boulton
	Sent: Monday, February 21, 2005 5:14 AM
	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

	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 

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: "Bharrat, Shaun" <[email-masked]>
Date: Tue, 22 Feb 2005 10:39:04 -0500

>It's hard to see how a purely network based solution would function using
>just this "minimal" profile on the part of the client. In contrast, a solution seems 
>straightforward if the client also supports symmetrical signaling. This definition of 
>the "minimal" profile seems to imply that you can visualize a purely network based 
>solution without requiring symetric signaling. If so, can you fill in the blanks for me? 

[Chris Boulton] Shaun - the profiles are only in association with 'media' and in no way relate to signaling.  This statement is just saying at the very least a client should send/receive RTP on the same IP /port combination.  

Fair enough. However, my underlying question still stands -- the minimal profile
as currently defined does not seem to allow a network based SIP solution. If so,
what is the point of the minimal profile? Shouldn't the minimal profile be something
that at least allows some solution with sufficient smarts in the network?

Thanks and cheers,
Shaun
 
 -----Original Message-----
From: Chris Boulton [mailto:[email-masked]]
Sent: Tuesday, February 22, 2005 10:17 AM
To: Bharrat, Shaun; sipping
Cc: Gonzalo Camarillo
Subject: RE: [Sipping] New NAT scenarios draft

Chris:

Thanks for the work on this draft. A question regarding the following blurb on
profiles...

> network based solutions to function in any NAT traversal scenario.

It's hard to see how a purely network based solution would function using
just this "minimal" profile on the part of the client. In contrast, a solution seems 
straightforward if the client also supports symmetrical signaling. This definition of 
the "minimal" profile seems to imply that you can visualize a purely network based 
solution without requiring symetric signaling. If so, can you fill in the blanks for me? 
If not, should the minimal profile include symmetric signaling as well?

[Chris Boulton] Shaun - the profiles are only in association with 'media' and in no way relate to signaling.  This statement is just saying at the very least a client should send/receive RTP on the same IP /port combination.  

Thanks and cheers,
Shaun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Chris Boulton
Sent: Monday, February 21, 2005 5:14 AM
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

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 22 Feb 2005 14:04:23 -0500

I understand what you are saying, but it is a very service-provider oriented
point of view.

If I am responsible for managing my Enteprise NAT/Firewall, I certainly
have the right to decide what may or may not cross my Enterprise NAT/FW,
and decide what I will make visible from the world outside.

I certainly believe that most Enterprise will want to be able to look
and modify if required the signalling crossing its borders, i.e., they
will do "Session Border Controllers". You may think it is a bad idea,
but from the point of view of the administrator, it would be a very 
bad idea to let "generic" traffic into the Enterprise without looking
at it. Why would SIP be any different than the other protocols?

In any case, I am certainly not proposing that we put examples
explaining how to do SBCs or SDP rewritting in the document. I
agree with you there.

What I would like to see is some explanation that media
relays based on SIP B2BUAs (e.g., SBCs) instead of a 
new protocol (TURN) are possible. If it then says that 
we consider this to be SBC functionality, and that it is
outside of the scope of the draft, that is also OK with me.

I don't think we should even mention "SDP rewritting" at all.
(not even to say it is a bad idea, which is highly subjective
in the context of SBCs).

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Tuesday, February 22, 2005 03:27
> To: Chris Boulton
> Cc: Audet, Francois [SC100:9T51:EXCH]; sipping
> Subject: Re: [Sipping] New NAT scenarios draft
> 
> 
> Hi,
> 
> > Gonzalo - do you think 4.4 should not be present? - Even if it was 
> > just 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
> 
> 
> 
>

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Tue, 22 Feb 2005 09:44:09 -0500

Chris:

 
 
Thanks and cheers,
Shaun

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Chris Boulton
Sent: Monday, February 21, 2005 5:14 AM
To: sipping
Cc: Gonzalo Camarillo
Subject: [Sipping] New NAT scenarios draft

All,

Best Regards,

Chris Boulton.

---

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

Thanks Kaiduan - I've put in the TODO box.  A bit of submission madness
;-).

Chris.

-----Original Message-----
From: kaiduan xie [mailto:[email-masked]] 
Sent: 21 February 2005 18:27
To: Chris Boulton; sipping
Cc: Gonzalo Camarillo
Subject: Re: [Sipping] New NAT scenarios draft

Chris,

Found some typo in this draft:

1) In Figure 22: Restricted NAT with ICE - Initiating,
message 15 TURN Resp:map=1.2.3.4:5618,
dest=1.2.3.4:5618

Here, the map should be the address and port on TURN
server, not the address and port on the NAT. Same typo
in Figure 24. Also Figure 24 should be Figure 23.

2) "Figure 26: Symmetric NAT with STUN - Failure", the
title is same as 
"Figure 25: Symmetric NAT with STUN - Failure", should
be "Figure 26: Symmetric NAT with TURN" or something
like that.

Thanks,

kaiduan

 --- Chris Boulton <[email-masked]> wrote: 
> 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:-
> 
>  
> 
>
> .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.
> 
> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 22 Feb 2005 11:46:37 -0000

Hi,

> Gonzalo - do you think 4.4 should not be present? - Even if it was
just
> 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.

[Chris Boulton] OK.

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

[Chris Boulton] That was the intention.

Gonzalo

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 24 Feb 2005 15:58:31 -0000

I'm going to second that.  The last thing we want to do is overload this
draft.  Its purpose is to convey usage of existing IETF solutions.  If
you have a problem with a solution, then this draft is not the place to
address it.

Chris.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: 24 February 2005 15:36
To: Medhavi Bhatia
Cc: 'Francois Audet'; 'sipping'; Chris Boulton
Subject: Re: [Sipping] New NAT scenarios draft

Hi,

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

Yes.

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

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