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

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

resending since this hasn't been acked by the mailing list or appeared
after over 30 minutes.  (I'm sure it will now immediately appear)

On 3/21/06, Bruce Lowekamp <lowekamp at cs.wm.edu> wrote:
> 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
> >
> >
>