Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat

From: "Pete Cordell" <[email-masked]>
Date: Mon, 1 Jul 2002 18:24:28 +0100

Simply because it is the agreed strategy of the pre-midcom design group to
define something called SPAN.

It may not look like SPAN-A, and it may look more like TURN, but there is a
way to go before that happens.

Much of the mentioned the lack of consensus has been down to a lack of
reading rather than any identified technical issues, so I suggest we go with
the agreed name rather than starting a bun fight before we've identified and
discussed any technical problems.  To do otherwise is just creating ill will
at a time we don't need it (at least I'm assuming that people don't want it
at this stage).

Pete.

----- Original Message -----
From: "Cullen Jennings" <[email-masked]>
To: "Pete Cordell" <[email-masked]>; <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>
Sent: 28 June 2002 19:35
Subject: RE: [Sip] Proposed change in draft-ietf-sip-nat

>
> My read of the SPAN document was it did not even represent consensus of
the
> design team much less the midcom WG.
>
> Why should references to TURN or SPAM be changed to just SPAN?
>
> Thanks, Cullen
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Pete
> > Cordell
> > Sent: Friday, June 28, 2002 2:16 AM
> > To: Jonathan Rosenberg; [email-masked]
> > Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat
> >
> >
> > Sounds reasonable except that to be in line with the pre-midcom / midcom
> > work all references to TURN should be to SPAN (Simple Protocol for
> > Augmenting NATs), at least for the time being.
> >
> > For those that are interested, a candidate for SPAN is at:
> >
> > http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt
> >
> > But be advised that this is iteration 1 and so subject to change.
> >
> > Pete.
> >
> > ----- Original Message -----
> > From: "Jonathan Rosenberg" <[email-masked]>
> > To: <[email-masked]>
> > Sent: 28 June 2002 06:06
> > Subject: [Sip] Proposed change in draft-ietf-sip-nat
> >
> >
> > > Folks,
> > >
> > > I would like to propose a change in draft-ietf-sip-nat.
> > >
> > > Right now, this document specifies two very independent and orthogonal
> > > things. One of them is the rport parameter. This is a Via param that
> > > makes sure that the SIP response gets routed back to the source IP and
> > > port where the request came from. Without it, SIP over UDP doesn't
work
> > > through any NATs. It allows SIP to work like most other protocols in
> > > terms of its port usage. I think its uncontroversial and should move
> > > forward as is.
> > >
> > > THe other aspect is the Translate header. Its aimed at making
> > > registrations work through NAT. However, there are several problems
with
> > > the Translate header right now:
> > >
> > > 1. It "competes" with other solutions, such as STUN and TURN/SPAN,
which
> > > would allow for incoming INVITEs through NAT without any SIP specific
> > > extensions.
> > >
> > > 2. It tries to optimize for the full-cone case, by including a
parameter
> > > that indicates whether the client is behind a full-cone or symmetric
> > > NAT. I would rather not pollute SIP with this kind of NAT-specific
> > > stuff; rather, relegate it to STUN/TURN.
> > >
> > > 3. UDP registrations through NAT are really troublesome. They require
> > > very frequent re-registrations to maintain the binding (under a
minute).
> > > This poses a serious load. If you have to use UDP, a STUN or TURN
> > > solution is much better, since refreshes of the NAT bindings would
occur
> > > through those protocols, rather than SIP, and they scale much better.
> > > So, if you consider TCP (which works even better still, since you
don't
> > > need to refresh the registration in order to keep the binding active),
> > > the problem is not really translating the contact header as it is TCP
> > > connection reuse for incoming requests. Indeed, the same problem
occurs
> > > in record-routing - you want to be able to specify to your peer to
reuse
> > > the connection for incoming requests. Thats not even a nat-specific
> > > thing; its just a capability that, if we had a better story on, would
be
> > > useful for NAT.
> > >
> > >
> > > As a result, I would propose that draft-ietf-sip-nat move forward with
> > > just the rport stuff, and we look at the registration problem
> > > separately. I would like a solution for SIP that didn't depend on
> > > STUN/TURN, but I have convinced myself that this solution needs to be
> > > TCP-based, and that it is best viewed as a problem of connection
reuse.
> > > ROhan has posted a requirement draft on that topic.
> > >
> > > Flame away....
> > >
> > > -Jonathan R.
> > >
> > >
> > >
> > >
> > > --
> > > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> > > Chief Scientist                         First Floor
> > > dynamicsoft                             East Hanover, NJ 07936
> > > [email-masked]                 FAX: (973) 952-5050
> > > http://www.jdrosen.net                  PH:  (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments on the application of sip
> >
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> >

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 1 Jul 2002 18:32:58 +0100

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>

> Cullen Jennings wrote:
> Correct.

Indeed and that's what the document says, so why the need to comment here?

To go further, I am waiting VERY patiently for comments to come in for
discussion.  Much effort has been put in on my part to reach consensus using
many small steps to try and bring the team along as a whole and I will
continue to work with that goal in mind.  Rest assured that this does not
mean imposing my will on others, but where I believe I have valid technical
issues, I will present them and look forward to them being discussed in an
open (and technical) way.

> More importantly, this issue is totally irrelevant to this thread.
> Draft-ietf-sip-nat will have references to neither TURN, nor SPAN, nor
> STUN. Connection reuse has nothing to do with it either. THe only place
> TURN/SPAN/STUN should show up is the nat-scenarios document. That one is
> on the backburner until these issues are sorted out, and is not what
> this thread is about in any case.

More than likely.  So why not acknowledge the editorial error (which
requires no action) and move on.