Subject: [p2p-sip] Single layer vs two layers

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Tue, 21 Mar 2006 14:42:47 -0500

After I wrote this email, I went back and read Bryan's draft and now I am not sure if it is proposing a single layer approach. It looks to me like it is proposing a two-layer approach, with the SIP layer exactly same as SIP and the overlay layer using a new SIP-like protocol. Is that a correct description?

thanks,
Sathya

----- Original Message -----
From: Sathya Narayanan <sathya at research.panasonic.com>
Date: Tuesday, March 21, 2006 2:10 pm
Subject: Re: [p2p-sip] Some comments on Use-cases document

> Dean -
> 
> > 
> > I propose that we first define an abstract model of an overlay  
> > network that includes the requisite primitives INSERT and QUERY  
> > (anything else needed?) and use this abstraction as our middle 
> layer.
> There is a section in draft-shim-sipping-p2p-arch-00.txt on P2P 
> Overlay API which proposes a set of such primitives.
> 
> > For the lower-layer, we do a binding from the abstraction to one 
> or  
> > more distributed database models, probably starting with CHORD. 
> This  
> > leaves our P2PSIP architecture independent of the database, but 
> gives a proof-of-concept adequate for implementation.
> 
> I am not sure if CHORD is the best option to start with. But, I 
> will wait to hear other opinions/reasons before taking a position 
> on this one.
> 
> > 
> > For the upper-layer, we have one model defined using SIP 
> REGISTER  
> > messages. We've also heard of work that uses REGISTER for the  
> > "INSERT" primitive and SUBSCRIBE/NOTIFY for the "query" primitive.
> > 
> > I'm also very interested in seeing if there's an obvious binding 
> for  
> > TURN here, as that might kill two birds with one stone.
> > 
> > I propose we start with the REGISTER/REGISTER model from the 
> bryan 
> > draft and talk that through a little further before we think 
> about changing it.
> 
> My understanding of Bryan's draft is that it tries to extend SIP 
> for overlay maintenance and resource location, i.e. a single layer 
> approach (Please correct me if I am wrong). So, proposing to start 
> with that model implicitely chooses that approach and ignores the 
> other possibility of having two separate layers as proposed in 
> draft-shim. I think we should have an explicit discussion on that 
> "key" question before proceeding any further. 
> 
> thanks,
> Sathya
> 
> > _______________________________________________
> > 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
>

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 21 Mar 2006 14:10:50 -0600

I would say it's SIP, not a SIP-like protocol, but that's a minor
terminology issue.

-01 used INVITE to search the DHT for the contact and to place the
call.  There was some concern that this might introduce issues when
connecting to non-P2P UAs with p2p headers (even if they are just
options or extension headers).

To address that issue, -02 uses REGISTER to query for the resource
registration (as specified by 3261, a REGISTER without a contact is a
query).   The UAC then places the call using purely conventional SIP
to the target UAS.

So it's two-layer in the sense that operations never traverse from the
DHT to non-DHT portions of the protocol.  But it's all implemented on
top of a standard SIP stack.

Bruce

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Tue, 21 Mar 2006 14:14:08 -0600

Sathya Narayanan wrote:
> After I wrote this email, I went back and read Bryan's draft and now I
> am not sure if it is proposing a single layer approach. It looks to me
> like it is proposing a two-layer approach, with the SIP layer exactly
> same as SIP and the overlay layer using a new SIP-like protocol. Is that
> a correct description?

It is.  Note that, pragmatically, the only detail that makes the
difference is that in version 1 user queries are accomplished with a
INVITE message and the result is conveyed in the last 302 response,
while in version 2 it is accomplished with a REGISTER and the result is
conveyed in the 200 response.

Enrico
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster at telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060321/c781cbd5/attachment.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 21 Mar 2006 17:02:51 -0600

> options or extension headers).

Despite our conversation on the topic last night, I fail to see how  
delivering a properly formatted SIP INVITE to a node (P2P or  
otherwise) is a problem. If it's a terminal node, it'll ring and  
maybe answer. If not, it'll try to proxy-route based on the request- 
URI, which had best be both syntactically valid and RFC 3263  
meaningful, and it might end up on a P2P UA eventually. Or a  
conventional UA. That's a feature, not a bug.

--
Dean