Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Mon, 23 Jan 2006 06:39:29 -0800 (PST)

Hi David,

Thank you for the comments. Please see my responses in line below. 

regards,
suresh

--- David Barrett <dbarrett at quinthar.com> wrote:

> I understand.  Thanks.
> 
> I totally, 100% support a unified STUN/TURN/ICE replacement.  And I
> completely endorse a single specification for the total functionality of a
> rendezvous service.
> 
[suresh] Great. Glad to hear this.

> However, I'd go one step further and suggest that we can accomplish this
> with minor alterations to SIP itself, and with minor additions to the SIP
> proxy.  Thus I think we can do this without creating a new protocol or
> server from scratch.
> 
> My reasoning (possibly not fully thought through) is that virtually all SIP
> deployments will occur over the internet, and thus will require a
> NAT-penetrating rendezvous service. 

[suresh] OK. However, several P2P applications that do not use SIP will also
need NAT-penetration service. 
 
>                                     The SIP proxy seems a natural place to
> do this (as it is virtually always publicly accessible), and it'd be great
> if P2P-SIP-compliant clients "just worked" across NATs without major changes
> to the overall syntax and state machines that have been refined with SIP.
> 

[suresh] Right, I see what you mean. 

> 
> Specifically, I think the existing SIP protocol and proxies already do 90%
> of what is necessary to pierce NATs.  The particular message flow I'd
> recommend is:
> 
> - All user agents use a STUN-like protocol on the SIP proxy to find both
> public and private (ip:port) tuples.
> 
> - All user agents REGISTER both (ip:port) tuples with the SIP proxy.
> 
> - All clients maintain a punched UDP hole (or persistent TCP connection) to
> one or more SIP proxies, thereby ensuring proxies can contact clients at
> will.
> 
> - User agent A sends INVITE to the SIP proxy, as always.
>  
> - The proxy gives A a provisional response to the INVITE with a "300
> Multiple Choices" (instead of "200 OK"), listing the (ip:port) tuples
> associated with user agent B.
> 
> - The proxy forwards A's INVITE to B, appending A's (ip:port) tuples.
> 
> - A, on receiving the "300 Multiple Choices" begins punching holes to both
> (ip:port) tuples of user agent B, thereby ensuring B can contact A.
> 
> - B, on receiving the forwarded "INVITE" request from the proxy, begins
> responding "200 OK" to A along both of A's (ip:port) tuples, implicitly
> punching holes to A and ensuring it can contact B.
> 
> - Eventually, A and B have each punched holes to each others' public and
> private (ip:port) tuples.  Whichever (A(ip:port),B(ip:port)) route along
> with A receives "200 OK" first is used for P2P communication.
> 
> 
> In summary, I suggest:
> - SIP be expanded with a STUN command that proxies MUST implement
> - User agents REGISTER multiple (ip:port) tuples with the proxy
> - Proxies respond "300 Multiple Choices" to INVITE, to which UA's holepunch
> - Proxies append all of A's (ip:port) tuples when forwarding to B
> - B replies "200 OK" direct to all of A's (ip:port) tuples
> 
> Obviously there are more minor issues (TURN integration, symmetric NAT
> piercing, etc), but this is the core algorithm.  And this *works today* in
> iGlance (www.iglance.com), so it's not an abstract proposal.  The relevant
> logic is implemented here (though obviously it won't make much sense without
> the context of the rest of the architecture):
> 

[suresh] Your proposal sounds good. I do like it. This extends the SIP protocol
and mandates the SIP proxy to be the rendezvous server. However, I am
uncomfortable with requiring that a SIP proxy (and only the SIP proxy) should
support rendezvous service. This is because Rendezvous service can be quite
bandwidth intensive, especially as it supports TURN service. Rendezvous service
may also be used by non-SIP applications. Why not use a SIP-like protocol, but
not tie the protocol to SIP and not tie the end nodes to SIP UA or SIP-Proxy. 

I havent looked up iglance.com. I will take a look. Thanks.

> 	http://svn.iglance.com/svn/trunk/iglance/client/GBuddySession.cpp
> 
> The benefit is:
> - You don't need a separate syntax/grammar for STUN/TURN (in SIP)
> - You don't need a separate STUN/TURN server (in the proxy)

> - You don't need ICE at all (implicit in message flow)
> - Clients needn't implement STUN servers (as ICE requires)
> - Client state machines are vastly reduced in complexity over ICE
> 
[suresh] Agree with most of the assessment. I certainly can appreciate clients
not having to implement STUN server. See my comment above about the benefit (or
not) of requiring the SIP Proxy to be rendezvous server  :-)

As for eliminating ICE, I do believe, you will need additional connection setup
mechanisms, even if they differ from ICE. For instance, the proposal needs
extensions to support relay service and TCP transport.

> Furthermore, this is *entirely* compatible (indeed, orthogonal) to a
> decentralized SIP proxy.  By combining NAT rendezvous service with the SIP
> proxy service, the same supernode structure can be used for proxying as for
> NAT penetration (potentially even TURN relaying).
> 
> 
> Basically, NAT penetration isn't really that hard, and SIP *almost* already
> does it.  It'd be a shame to create a whole new layer of protocol complexity
> to solve such a minor, universal problem as this when very slight
> adjustments to SIP itself can make the problem go away.
> 
[suresh] Well, NAT penetration is not easy. There are many P2P applications
that seek NAT penetration. SIP based applications is one such group of apps.
When the NAT penetraton is addressed as an independent problem, SIP can be
extented to support that solution.

regards,
suresh

> -david
> 
> 
> > -----Original Message-----
> > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com]
> > Sent: Friday, January 20, 2006 4:55 PM
> > To: David Barrett; 'Philip Matthews'; 'Dean Willis'
> > Cc: 'P2P-SIP'
> > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG
> > 
> > I am in favor of option b). Create a new protocol that ultimately replaces
> > STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol.
> > The
> > "rendezvous server" or "super node"  that runs the protocol need not be a
> > SIP
> > proxy.
> > 
> > cheers,
> > suresh
> > 
> > --- David Barrett <dbarrett at quinthar.com> wrote:
> > 
> > > > -----Original Message-----
> > > > From: Philip Matthews
> > > >
> > > > What I see us (the P2P-SIP group) doing is specifying the protocol
> > > > used between the Rendezvous Server,
> > > > peer P, and node X.  Then some P2P-SIP networks may decide to use one
> > > > server, and other networks
> > > > may decide to use another server. Node X will then have to know (a)
> > > > which server to contact, (b) the name
> > > > of the P2P-SIP network it wishes to join, and (c) the password (if
> > > > any) to join.
> > >
> > > I think I agree with this, but I'm unclear what you are specifically
> > > proposing.  Are you suggesting the P2P-SIP group:
> > >
> > > a) Adjust SIP to implicitly solve the NAT penetration issues, thereby
> > making
> > > every SIP proxy naturally serve as a "rendezvous server", ultimately
> > doing
> > > away with STUN, TURN, and ICE entirely?
> > > 	- (Incidentally, I think this is the right course.)
> > >
> > > b) Create a new protocol that replaces STUN, TURN, and ICE, then
> > implement
> > > this new protocol in a new "rendezvous server" that is separate from the
> > SIP
> > > proxy, and then find a way to bridge SIP and this new server?
> > >
> > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new
> > > protocol that somehow simplifies the NAT penetration issue?
> > >
> > > Which of these is the closest?
> > >
> > > -david
> > >
> > > _______________________________________________
> > > p2p-sip mailing list
> > > p2p-sip at cs.columbia.edu
> > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> > >
> > 
> 
> 
>

---

From: henry at pulver.com (Henry Sinnreich)
Date: Mon, 23 Jan 2006 09:22:47 -0600

Pyda,

I have followed your discussion on this trail, have read your I-D and would
suggest we limit the scope here to:

1. SIP only, 
2. ICE/TURN/STUN since they solve 100% NAT traversal for SIP and RTP.

Other protocols (non-SIP) and NAT traversal solutions that do not solve 100%
of NAT scenarios should be out of scope.

> with minor alterations to SIP itself,

Out of scope, unless they accomplish 100% NAT traversal and ICE/TURN/STUN is
proven to be broken.

My two cents, Henry 

-----Original Message-----
From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] 
Sent: Monday, January 23, 2006 8:39 AM
To: David Barrett; 'Philip Matthews'; 'Dean Willis'
Cc: 'P2P-SIP'
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

Hi David,

regards,
suresh

 

> the context of the rest of the architecture):

[suresh] Your proposal sounds good. I do like it. This extends the SIP
protocol
and mandates the SIP proxy to be the rendezvous server. However, I am
uncomfortable with requiring that a SIP proxy (and only the SIP proxy)
should
support rendezvous service. This is because Rendezvous service can be quite
bandwidth intensive, especially as it supports TURN service. Rendezvous
service
may also be used by non-SIP applications. Why not use a SIP-like protocol,
but
not tie the protocol to SIP and not tie the end nodes to SIP UA or
SIP-Proxy. 

> - Client state machines are vastly reduced in complexity over ICE
[suresh] Agree with most of the assessment. I certainly can appreciate
clients
not having to implement STUN server. See my comment above about the benefit
(or
not) of requiring the SIP Proxy to be rendezvous server  :-)

As for eliminating ICE, I do believe, you will need additional connection
setup
mechanisms, even if they differ from ICE. For instance, the proposal needs
extensions to support relay service and TCP transport.

regards,
suresh

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 23 Jan 2006 09:16:39 -0800

> need NAT-penetration service.

No doubt.  But I'm afraid attempting to satisfy everyone by abstracting out
a new, general purpose NAT-traversal algorithm might end up satisfying
nobody.

(ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't help.)

Our primary audience is the SIP community, so we MUST satisfy them.  We CAN
satisfy others, but needn't.  As such, I recommend we make SIP "just work"
across NATs, and then encourage anyone who wants NAT traversal to use SIP
(even if not a VoIP application).

> support rendezvous service.
> This is because Rendezvous service can be
> quite
> bandwidth intensive, especially as it supports TURN service.

Thanks!  But I'm sorry, I didn't mean to imply that.  I think a rendezvous
service can be offered by anyone, user agents and proxies alike.  However, I
would say that proxies MUST implement it, while user agents only SHOULD.

> Rendezvous
> service
> may also be used by non-SIP applications.

Again, it's my view that by trying to solve the general case for all
applications, we risk not solving the specific case for any application.
SIP is hard enough by itself (and has a large enough userbase) that a
SIP-specific solution seems justified.

The flip side of focusing on what's important is *not* focusing on what's
*not* important.  In my view -- which is only one of many -- SIP
applications are important to the P2P-SIP group, and non-SIP applications
are not important.  Thus I think we should focus on SIP, and *not* focus on
*non-SIP*.

> extensions to support relay service and TCP transport.

Well, ICE, STUN, and TURN comprise hundreds of pages, while I've only given
one -- I certainly agree even more could be accomplished with more pages.
However, I do believe that the sum of all that functionality can be done in
a much simpler fashion (in far less than hundreds of pages) by just
leveraging the existing syntax and components of SIP rather than starting
over from scratch.

> that seek NAT penetration. SIP based applications is one such group of

True.  But SIP is all that matters to me.  We've had enough trouble trying
to standardize VoIP around SIP; trying to further standardize all
NAT-penetrating P2P apps around an entirely new protocol sounds like a hard
problem that doesn't need solving right now.

-david