RE: [Sipping] draft-ietf-sipping-nat-scenarios-05

It has been pointed out to me that the profiles I am referencing are _media_ profiles

and that the symmetric signaling and connection-reuse recommendations presumably

always apply.

Never mind...

Thanks and cheers,

Shaun Bharrat

-----Original Message-----
From: Bharrat, Shaun
Sent: Thursday, June 29, 2006 7:30 AM
To: sipping at ietf.org
Subject: RE: [Sipping] draft-ietf-sipping-nat-scenarios-05

Chris:

> 3.2.5.3. Minimal Profile

>   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.
>
>   All clients SHOULD support the 'Primary Profile', MUST support the
>   'Minimal Profile' and MAY support the 'Consumer Profile'.

>

> This suggests that there is such a solution for dealing with boxes
> which only support a minimal profile. I would greatly appreciate it
> if someone can enlighten me in this area. I can see how to do it without
> any endpoint involvement if the IAD supports both symmetric RTP _AND_
> symmetric signaling. Can anyone describe a solution without proprietary
> requirements on the IAD which functions without symmetric signaling
> from the IAD?

> Appreciate any thoughts in this area.

I haven't seen any feedback on this question. I suppose there could be workable proxy/registrar solutions

when the IAD only does "Minimal" but these solutions are supersecret and no-one will share. Equally likely

IMHO, though, is that there isn't a workable solution if the IAD doesn't support receiving requests on

the same address/port from which it sends REGISTERs.

If there really is a proxy/registrar solution, I really hope someone can chime in and enlighten me.

If there isn't a solution, then it seems pointless to define the Minimal Profile in this manner -- shouldn't

it include the minimal subset that facilitates a network-based solution.

Thanks and cheers,

Shaun Bharrat

-----Original Message-----
From: Bharrat, Shaun
Sent: Tuesday, June 27, 2006 7:54 AM
To: 'Chris Boulton'; sipping at ietf.org
Cc: Mary Barnes; Gonzalo Camarillo
Subject: RE: [Sipping] draft-ietf-sipping-nat-scenarios-05

3.2.5.3. Minimal Profile 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. All clients SHOULD support the 'Primary Profile', MUST support the 'Minimal Profile' and MAY support the 'Consumer Profile'.

This suggests that there is such a solution for dealing with boxes
which only support a minimal profile. I would greatly appreciate it
if someone can enlighten me in this area. I can see how to do it without
any endpoint involvement if the IAD supports both symmetric RTP _AND_
symmetric signaling. Can anyone describe a solution without proprietary
requirements on the IAD which functions without symmetric signaling
from the IAD?

Appreciate any thoughts in this area.

Thanks and cheers,
Shaun Bharrat

From: Chris Boulton [mailto:cboulton at ubiquity.net]
Sent: Tuesday, June 27, 2006 5:30 AM
To: sipping at ietf.org
Cc: Mary Barnes; Gonzalo Camarillo
Subject: [Sipping] draft-ietf-sipping-nat-scenarios-05

A new version of the NAT Scenarios has been submitted. Until it appears in the archives, you can get a copy from http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-scenarios-05.txt and http://www.ubiquitysoftware.com/ietf/draft-ietf-sipping-nat-scenarios-05.html.

This version is still a work-in-progress with the view to having an 'early' completed version post Montreal. All feedback is welcome, especially on the scenarios section as we try to compile a wide ranging and useful list of deployment scenarios. New suggestions welcome.

Best Regards,

Chris.

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 writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding. Thank-you