Subject: [p2p-sip] Re: SIP does NAT and P2P NAT

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Sun Oct 30 09:10:02 2005

Thanks, Henry, for the info. The discussion sounds interesting. I will not be
attending the IETF meeting this time. However, I would love to parttake in the
e-mail discussions. After reading the e-mail, I just joined the p2p-sip mailing
list.

Just as an FYI, we are working on submitting revised "Application design
guidelines for NAT traversal" draft (draft-ford-behave-app-01.txt) and "State
of P2P communication across NATs" draft
(draft-srisuresh-behave-p2p-state-01.txt) this weekend. Both these P2P NAT
drafts refer the ICE draft. It would be good to include links to these P2P NAT
drafts in the P2PSIP web site. 

regards,
suresh

--- Henry Sinnreich <[email-masked]> wrote:

> Most here probably already know: NAT traversal for SIP has much in common
> with P2P NAT traversal on which there is an excellent recent paper at
> http://www.brynosaurus.com/pub/net/p2pnat 
> 
> The NAT Check tool http://midcom-p2p.sourceforge.net/  and the results for
> many NATs are also very close to the interests of the SIP folks here.
> 
> This paper has a very similar approach to ICE, but may be of special
> interest to the P2P SIP folks and should be linked I believe on the
> www.p2psip.org web site. ICE and P2PNAT ought to be well cross-referenced.
> 
> Two meetings of common interest at the 64 IETF:
> 
> - "SIP does NAT" on Friday at 8:00; informal in the breakfast area,
> - "P2P SIP" Friday 1:00-5:00,
> Location: Junior Ballroom, located in the North Tower, 3rd Floor Sheraton
> Vancouver Wall Centre 1088 Burrard Street.
> 
> Thanks, Henry
>  
> 
> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: Friday, October 21, 2005 8:51 AM
> To: Chris Boulton; [email-masked]; Jonathan Rosenberg; Francois Audet
> Cc: Alan Duric; Jon Peterson; Daniel G. Petrie; Alan Johnston; Henning
> Schulzrinne; Adrian Georgescu; Jiri Kuthan; Dean Willis
> Subject: Re: SIP does NAT
> 
> 
> Please add Francois Audet to this thread - thanks.
> 
> 
> On 10/20/05 1:29 AM, "Chris Boulton" <[email-masked]> wrote:
> 
> > 
> > Many thanks to Jonathan for the new ICE draft!
> > 
> > [Chris Boulton] yes - thanks Jonathan.
> > 
> > While this goes a long way in solving the problem, the IETF has NAT/FW
> > traversal dispersed in far too many WGs and thus there is no (I hate
> > this
> > word) "program management", sorry to say so... Besides, we still need
> > agreement on
> > 
> > - A framework document and reading map, author?
> > 
> > [Chris Boulton] Is this necessary above and beyond what the NAT
> > scenarios provide?  The document already touches on topics such as
> > varying profiles for UA's.  If it is truly felt necessary I am more than
> > happy to organize and provide a general NAT Framework (such topics as
> > the UA profiles would be moved there).  This would result in the NAT
> > scenarios draft purely being deployment examples.  I'd be interested in
> > 'folks' opinion on this.
> > 
> > - Examples: The I-D by Chris Boulton and Jonathan Rosenberg,
> > 
> > [Chris Boulton] I will be working to produce a revision by Monday - to
> > be followed up after the meeting by another.
> > - Cullen Jenning's I-D,
> > - Any other?
> > 
> > If you are interested to discuss what I believe to be a crisis, let's
> > meet
> > Friday 11/11 morning at 8:00 at breakfast.
> > 
> > [Chris Boulton] Unfortunately I am leaving Thursday evening - but would
> > be free to chat at any other time.
> > 
> > What do you think; are exceptional actions justified to have SIP do NAT,
> > finally? Make a time slot in SIP or SIPPING to discuss before any other
> > topics on the agenda?
> > 
> > Thanks again to Jonathan and all authors that are contributing to a
> > solution,
> > 
> > Henry
> > 
> >  
> > 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Wednesday, October 19, 2005 8:27 PM
> > To: [email-masked]
> > Cc: 'Cullen Jennings'; 'Alan Duric'; 'Peterson, Jon'; 'Daniel G.
> > Petrie';
> > 'Alan Johnston'; 'Henning Schulzrinne'; 'Adrian Georgescu'; 'Jiri
> > Kuthan';
> > 'Dean Willis'; 'Chris Boulton'
> > Subject: Re: SIP does NAT
> > 
> > Sorry for not commenting on this sooner. As you know this is a topic
> > near and dear to my heart. I didn't want to post a note without being
> > able to report some news, and the news is that I have revised and
> > submitted the ICE spec, and spent a huge amount of time on it over the
> > last few weeks. I now believe its done and would be happy to ask Colin
> > and Joerg to wglc if folks think it would help accelerate.
> > 
> > ALong with the ICE draft was ICE-tcp, which describes a way to basically
> > 
> > have RTP run over tcp. Each endpoint in the call need only be able to
> > make an outbound tcp connection to some port on the turn relay. Once you
> > 
> > have something like that, I think it covers a LOT of cases. If you run
> > into firewalls that still block outbound tcp, you can try running your
> > turn tcp servers on port 80. Now I won't write that in an ietf spec but
> > it can be configured with ice-tcp. If that doesn't work, the next step
> > would be to get TLS support too. That would reqiure a turn extension.
> > Beyond that gets into nasties like HTTP tunneling. I suspect TURN/TLS
> > would be good enough. As such, I would support such a work item. I'm not
> > 
> > so sure about tunenls beyond that. As Cullen has pointed out, none of
> > that will work terribly well when there is packet loss. I don't know if
> > Skype plays games with tcp like parallel connections and fake ACKs. That
> > 
> > would be another possible "work item" but somehow I think would have to
> > be done as an individual effort and sent right to rfc-ed, since its
> > clearly horrible stuff.
> > 
> > The other thing that needs to be done is complete TURN; its languished
> > somewhat as an individual I-D and needs to be finished. I have a plan
> > for wrapping it up, and should have a revision out before the deadline
> > that puts some sanity around it and its relationship to STUN, and the
> > various things we're doing with stun these days.
> > 
> > Per the bits in the thread on anycast; I'd support some work on turn
> > server discovery. However, I don't want to send the wrong message to the
> > 
> > industry. TURN/STUN/ICE is, imho enough, and please don't wait for ietf
> > to figure out some kind of optimization to shave 25ms off the voice
> > latency. So we'd need to be careful about how this is positioned.
> > 
> > 
> > 
> > 
> > 
> > More below:
> > 
> > Henry Sinnreich wrote:
> > 
> >> Cullen,
> >> 
> >> Thanks for the interest! Here are some topics to discuss:
> >> 
> >> 1. Support for 'legacy' SIP UA: At present most service providers us
> > SBC
> >> (horrible), when we could recommend such as
> >>  http://ag-projects.com/MediaProxy.html
> > 
> > Actually, there is something that can be done for legacy PC softphones
> > at least. One idea is to have a single-user ICE-agent; it basically runs
> > 
> > on the same PC as the softphone. You point your softphone to it
> > (different port on the same host) as the outbound proxy. That little
> > ICE-agent acts as a b2bua and implements ICE on behalf of the caller.
> > Doesnt work so good for hardphones and TAs. Please don't push this
> > outside of the endpoint though; as soon as you do that, you have the
> > chance of a nat between the endpoint and this mini-SBC, and that would
> > really be bad...
> > 
> >> 
> >> 2. Many SIP UA and service providers support STUN, but it is a hard
> > sell
> >> since it is not always effective, and sorry to say, Skype and Google
> > Talk
> >> will always work.
> > 
> > Right. Thats why there is ICE.
> > 
> >> 
> >> 3. ICE will always work and there are already pre-standard
> > implementations
> >> like at http://www.counterpath.com/index.php and Chris Boulton and
> > Jonathan
> >> Rosenberg have an excellent I-D with detailed examples
> >> 
> > http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-nat-scenarios-02.t
> > xt
> > 
> >> 
> >> 4. Is there a way to get ICE and the NAT Scenarios faster to Last
> > Call?
> > 
> > Per above, ICE is done AFAIK and I believe ready to go to WGLC.
> > 
> > Henning had written:
> >> I'm sorry to say that a media relay of whatever kind isn't all that
> > different from an SBC.
> > 
> > well, that depends on what it is about sbc's that you view as bad. If
> > you think the badness is around the fact that there is relay of media,
> > then media relays (ala turn) are bad too. But I think its the b2bua and
> > transparency issues, security issues, that are bad. ICE/STUN/TURN will
> > use media relays when needed but has none of the transparency or
> > security issues. Indeed, if you look at the securite considerations
> > section in ICE, the voice hammer attack in particular - an SBC helps
> > this not one bit.
> > 
> > -Jonathan R.
> 
> 
> 
>