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

[lowekamp at cs.wm.edu (Bruce Lowekamp)]

I don't thnk it has anything to do with use-cases, either

but

Building DHT maintenance on top of SIP gives us all of the advantages
of the routing, addressing, naming, and security issues already built
into SIP.  Plus the NAT traversal capabilities of STUN, TURN, and ICE.
 While not perfect for our use, I think with very minimal
modifications (whatever the final protocol is) they will provide a
very good solution.

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.


The exact DHT algorithm we implement, the exact way the we use SIP,
the methods, etc I think are all going to need some careful thought. 
But for P2P SIP, I think SIP is the obvious choice for DHT operations,
and I would consider it the default unless a convincing argument is
made against it.

A number of comments have been made stating that NATs must be taken
into account from the beginning.  Again, one of the issues that using
SIP helps address already is NAT traversal.  It's not perfect for
signalling, but the framework is there.

Bruce

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
>
>