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

[sathya at research.panasonic.com (Sathya Narayanan)]

Hi Bruce -

Let me re-iterate what I said earlier - I am not against the idea of using SIP for the overlay layer YET. But ...

> A proposal to use something else needs to:
> - explain what the shortcomings of SIP are for this purpose
> - explain how a new or different solution will provide equivalent 
> functionality- explain how/why the new protocol will be better after resolving the
> complexities that SIP has become so complex to address
> - make a convincing enough case to justify deploying devices (and we're frequently talking about very small devices) to implement two
> separate protocol stacks.

I don't agree with the above statement. It is  not clear to me why it is the burden of somebody proposing the design non-SIP protocol to justify it. In my mind, its as much the responsibility of somebody proposing the use of SIP to justify such an use. Even more so, because there is no disagreement on the need for a overlay protocol,  the disagreement is whether SIP fits the bill SO well that it can be used with minimal changes. Ofcourse, draft-bryan is a starting point for such an idea, but obviously it leaves many open issues which worries me that we may regret the choice later. With a new protocol we have better freedom to make any necessary design choices without having worry about affecting SIP.

thanks,
Sathya



> 
> On 3/21/06, Philip Matthews <philip_matthews at magma.ca> wrote:
> > 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  ;-)
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
> >
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>