Subject: [p2p-sip] Problem statement for P2P SIP NAT traversal

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 13:09:36 -0500

inline.

David Barrett wrote:

>>-----Original Message-----
>>From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]
>>Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal
>>
>>I think the burden of proof would be to demonstrate that ICE cannot and
>>doesn't, for some reason, work for p2p SIP.
> 
> 
> That's fair.  Let's first define what 'works for P2P-SIP' is, then we can
> have a productive discussion on this point.  Specifically, I mean we should
> define the NAT-traversal requirements of P2P-SIP without regard to a
> solution (eg, without presupposing ICE), and then evaluate whether and to
> what degree ICE meets these requirements.

This would make sense if you were desiging a protocol from scratch. But 
we're not. SIP p2p can be thought of as yet another sip extension. We've 
had lots of those. To my knowledge, none of them has gone off and 
decided to write requirements around SIP problems that already have a 
SIP solution. I think the assumption needs to be that existing SIP 
mechanisms are used, and if they break in some way, bring some 
requirements to get them fixed. AFAIK, no one has said that ICE will not 
work with p2p SIP. I think it will work swimmingly well, in fact.

> 
> Clearly, if ICE is the best solution, let's take it.  But if ICE isn't the
> best solution, let's not take it, and instead find what is.  

Again, I disagree. If your beef is with ICE itself, as I suspect it is, 
from this note at least:

David Barrett wrote:
> I rather like the idea of just extending the base SIP protocol to include
> the DHT, rather than rolling an entirely new protocol (*cough* ICE *cough*)
> from scratch, using its own parsers, own state machines, own eccentricities,
> etc.

then I suggest you take these comments to mmusic list for discussion 
there. I will note that state machines are an essential part of nearly 
any protocol definition, whether it be an extension or a new protocol. 
Many sip extensions have them. The same is true for new syntax. I think 
it is naive to think you can do what ICE is doing and end up with 
something that defines no new syntax or state machinery.

> 
> I'm sorry, I didn't mean to present this as something new; I thought this
> was already the consensus.

I'm not sure what the consensus is, but I cannot agree with a plan of 
action that has us revisiting all sorts of sip design decisions that 
have been made already, in the name of a new, non-interoperable p2p-sip.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com