[p2p-sip] Some comments on Use-cases document

[philip_matthews at magma.ca (Philip Matthews)]

On 20-Mar-06, at 21:19 , David Barrett wrote:

> I'd add to that this key question:
>
> 	"Will we extend SIP, or create a new protocol?"
>
> I'm finding it hard to make any headway without understanding the  
> above.
> Basically, I see two major directions we could go:
>
> 1) Extend SIP with overlay-maintenance and resource-location messages.
>
> 2) Create a new overlay protocol and develop bindings for SIP and  
> ICE (eg,
> distributed proxy service and STUN/TURN resource-location service).
>
> It seems this high-level decision keeps coming up again and again in
> discussions of the smaller issues.
>

For what it is worth, I can say that my own views on this subject  
have changed.

For all of last year, I strongly believed that there should be two  
distinct layers:
a SIP layer and a P2P layer (i.e., option 2). See the arguments I  
wrote in
   http://www.p2psip.org/drafts/draft-matthews-sipping-p2p-industrial- 
strength-00.txt
as well as those on Alan Johnston in
   http://www.p2psip.org/drafts/draft-johnston-sipping-p2p-ipcom-01.txt

However, in the last few months, I have come to see that there are  
some good reasons
to put the two layers together into one (i.e., option 1):
	a) NAT Traversal becomes easier because there is just one port,  
rather than two
	   (this assumes that the P2P layer would run on a different port  
than SIP)
	b) Possible performance improvements. With two layers, you have to  
first ask
	  "where is user U?" and then send the Invite message. With one  
layer, there is
	  the possibility of sending the Invite and having it routed to the  
user.
	  (David et al removed this from their latest draft, but this was an  
option in the
	  earlier version, and also in the work done by Henning's group).

As others have pointed out, there are also drawbacks, so I haven't  
concluded anything
yet, but I am a lot more open to option 1 than I was a few months ago.


- Philip

PS. What this has to do with the use-cases document, however, I am  
not clear on  ;-)