From eunsoo at research.panasonic.com Thu Jun 1 00:15:36 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 01 Jun 2006 00:15:36 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <024101c68510$355f3240$6400a8c0@comcast.net> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <024101c68510$355f3240$6400a8c0@comcast.net> Message-ID: <447E69E8.8010603@research.panasonic.com> First of all, please let me clarify one thing - I never meant interoperation between different DHTs. I think it is/should out of scope. What I assume is a DHT per a P2PSIP network. It seems all your questions are based on the assumption that I was talking about interoperation of different DHTs. Interoperation between different P2PSIP networks? Please review my slides of the ad-hoc meeting in Dallas. The interoperation is via RFC3261. And I think we need to be specific about what interface (or protocol) we are talking about when we talk about GET/PUT. Thanks. Eunsoo Peter Pan wrote: >The abstraction of GET/PUT seems ideal to wrap complex node interactions of >different DHTs into a simple interface. > >Few questions: > >* Will there be some DHT "type tag" in the protocol so that a node in >Kademlia DHT receiving a GET req from another node in Chord DHT will not >dump irrelevant k closest nodes to the Chord node? >* How will GET/PUT encapsulate difference of or convert distance "metric" >information of different DHTs? (eg. Chord uses subtraction while Kademlia >uses XOR to calculate node distance) >* How will a node in DHT A locate the next-hop node in DHT B to send >GET/PUT, which seems a precondition to interoperate DHTs on peer-to-peer >basis? > >PP >----- Original Message ----- >From: "Eunsoo Shim" >To: "Cullen Jennings" >Cc: "P2P-SIP" >Sent: Wednesday, May 31, 2006 9:07 AM >Subject: Re: [p2p-sip] What are we doing - question 1 > > > > >>Cullen Jennings wrote: >> >> >> >>>On May 30, 2006, at 10:39 AM, Alan Johnston wrote: >>> >>> >>> >>>>Cullen Jennings wrote: >>>> >>>> >>>> >>>>>Ok, I'm glad to hear that at least some people think we have some >>>>>consensus on this. It's been hard to tell following the list so I >>>>>appreciate people speaking up about it. >>>>> >>>>>I'll be very blunt about doing both proposal. It is not clear to >>>>>me if people think we should do both because >>>>>1) this is the technical long term solution we want, or >>>>>2) this would make it so at some level everyone agreed. >>>>> >>>>>Doing both will no doubt slow down finishing either. It is not >>>>>clear to the that the GET/PUT only protocol would be used if the >>>>>other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >>>>>want the later of the two. So if we look at our end goal, is there >>>>>a need for GET/ PUT only. >>>>> >>>>> >>>>> >>>>Yes. Real DHT nodes typically interact with 100s if not 1000s of >>>>peer nodes at any given instant. Will every SIP UA be capable of >>>>doing this? >>>> >>>> >>>I'll use chord as an example here not because I think chord is the >>>right DHT but only as a concrete example. A node that knew a few >>>other chord nodes but was not storing any data could easily interact >>>with the DHT and only have very few connections. >>> >>> >>> >>Please let me try to clarify the issure a little bit more. >> >>A node in Chord must maintain a finger table and data with keys of a >>certain range or locations of such data. >>Chord requires each node (in the Chord network) to have around log N >>fingers (where N is the total number of nodes in the Chord network and >>the base is 2). So if the network size is around 64,000, the number of >>fingers for each node is around 16. For a network of around a million >>nodes, the number becomes around 20. >> >>There is a cost for maintaining the finger table when the network is >>dynamic (nodes join and leave). Furthermore, each node should provide >>routing for various Chord messages such as GET/PUT/JOIN/LEAVE. >> >>When a node has limited bandwidth or battery power, the above >>requirements may be too much. If the node is behind NAT, it is not >>simple maintaining connections with fingers and other nodes for which >>the node is a finger. >> >>What I said kind of justifies the distinction between devices (SIP UAs) >>that participate in the DHT (Chord) and devices (SIP UAs) that do not. >>The devices that do not participate in the DHT don't need to support >>JOIN and LEAVE but need to do just GET/PUT. >> >>So now we have two interfaces. >> >>Node in DHT Node in >>DHT Node not in DHT >> >> >> >> >> >|<---------------------------------------->|<------------------------------- >----------------------->| > > >> (a) GET/PUT (b) GET/PUT >> JOIN/LEAVE >> >>Now the question has a few angles. >>- Will (a) GET/PUT be dependent of the underling DHT algorithm? >>- Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax and >>semantics? >>- Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? >> >>If an answer for any of the above question is 'yes', I think we'd be >>better off by defining (b) GET/PUT as a separate protocol. And I think >>it is a safe assumption. >>If we find out none of the answers is 'yes', then we would not need a >>separate protocol for (b) GET/PUT. >>Nodes not in DHT can safely just implement and support GET/PUT but not >>JOIN/LEAVE. >> >>Hope I added some clarity, not confusion. >> >> >> >>>>Think wireless, low bandwidth, and embedded UAs. >>>>There is a very clear layering and architectural choices here that >>>>if we only somehow choose one single DHT and standardize it that we >>>>will loose. >>>> >>>> >>>So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE >>>protocol. This is the part that I am failing to understand. I think >>>it would be great if we could have no central servers and not >>>standardized a P2P protocol but I don't see how we can have our cake >>>and eat it too. >>> >>> >>> >>>>Also, I think we need to first decide what information should be >>>>pushed and pulled from the DHT, what format it is, and how it will >>>>be retrieved. Then, and only then do we have the requirements for >>>>our DHT layer. >>>> >>>> >>>I agree here but I don't see how this has to do with making a >>>protocol for the GET/PUT. >>> >>> >>> >>> >>>>To do both of these efforts them at the same time makes no sense to >>>> >>>> >me. > > >>>Agree here too. >>> >>> >>> >>Thanks. >> >>Eunsoo >> >> >> >> > > > > From eunsoo at research.panasonic.com Thu Jun 1 00:42:20 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 01 Jun 2006 00:42:20 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> Message-ID: <447E702C.7060305@research.panasonic.com> My comments are inline. >> >> One trivial comment and one important comment inline... >> >> On May 31, 2006, at 9:07 AM, Eunsoo Shim wrote: >> > > >>>> Cullen Jennings wrote: >>>> >> >> >>>>>> >>>>>> On May 30, 2006, at 10:39 AM, Alan Johnston wrote: >>>>>> >>> >>> >>>>>>>> Cullen Jennings wrote: >>>>>>>> >>>> >>>> >>>>>>>>>> Ok, I'm glad to hear that at least some people think we have some >>>>>>>>>> consensus on this. It's been hard to tell following the list so I >>>>>>>>>> appreciate people speaking up about it. >>>>>>>>>> >>>>>>>>>> I'll be very blunt about doing both proposal. It is not clear to >>>>>>>>>> me if people think we should do both because >>>>>>>>>> 1) this is the technical long term solution we want, or >>>>>>>>>> 2) this would make it so at some level everyone agreed. >>>>>>>>>> >>>>>>>>>> Doing both will no doubt slow down finishing either. It is not >>>>>>>>>> clear to the that the GET/PUT only protocol would be used if the >>>>>>>>>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >>>>>>>>>> want the later of the two. So if we look at our end goal, is there >>>>>>>>>> a need for GET/ PUT only. >>>>>>>>>> >>>>> >>>>> >>>>>>>> Yes. Real DHT nodes typically interact with 100s if not 1000s of >>>>>>>> peer nodes at any given instant. Will every SIP UA be capable of >>>>>>>> doing this? >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>>> I'll use chord as an example here not because I think chord is the >>>>>> right DHT but only as a concrete example. A node that knew a few >>>>>> other chord nodes but was not storing any data could easily interact >>>>>> with the DHT and only have very few connections. >>>>>> >>> >>> >>>> Please let me try to clarify the issure a little bit more. >>>> >>>> A node in Chord must maintain a finger table and data with keys of a >>>> certain range or locations of such data. >>>> Chord requires each node (in the Chord network) to have around log N >>>> fingers (where N is the total number of nodes in the Chord network and >>>> the base is 2). So if the network size is around 64,000, the number of >>>> fingers for each node is around 16. For a network of around a million >>>> nodes, the number becomes around 20. >> >> >> >> >> the trivial comment - A trivial modification to the Chord algo would >> say that if a node wanted less finger tables, it dropped half the >> current ones and kept every other finger entry - things would still work. > > Yes. Just at an expense of slower lookup. >> I'm not arguing this is a good idea but I am pointing out there are >> many ways to modify a DHT to meet this somewhat requirement of low >> connection count. > > OK. >> The problem with most low power devices is not keeping up 20 >> connection but instead how often they have to wake up for traffic. > > Yes. >> It may be that P2P is a real bad idea for mobile devices because you >> need to keep updating data. All this really does is worry me that >> selecting a DHT for use in mobile environments is a research problem. > > It is possible to keep mobile devices as just ordinary nodes (or clients) that do not participate in DHT routing if a P2PSIP network includes fixed devices and mobile devices. A P2PSIP network with only mobile devices? Well, if Mobile IP is supported for the devices, there is nothing to worry. DHT won't be affected by their mobility. No Mobile IP? Well, then it is a very dynamic DHT. I am not sure whether we should worry about such a case at the moment. >> > > >>>> >>>> There is a cost for maintaining the finger table when the network is >>>> dynamic (nodes join and leave). Furthermore, each node should provide >>>> routing for various Chord messages such as GET/PUT/JOIN/LEAVE. >>>> >>>> When a node has limited bandwidth or battery power, the above >>>> requirements may be too much. If the node is behind NAT, it is not >>>> simple maintaining connections with fingers and other nodes for which >>>> the node is a finger. >> >> >> >> >> True that it is not easy but it's not clear that it is any harder >> than setting up RTP between two devices behind NAT which I believe to >> be a requirement of this work. > > For a given pair of nodes, I guess it is the same task as setting up a RTP channel. The difference is that, if a node behind NAT participates in DHT, it should maintain multiple or many of such channels with nodes which may change over time. For Chord, a JOIN operation involves of O(log2 N) messages when no NAT is involved. If NATs are involved, I am sure more traffic will be required for a JOIN operation. >> > > >>>> >>>> What I said kind of justifies the distinction between devices (SIP UAs) >>>> that participate in the DHT (Chord) and devices (SIP UAs) that do not. >>>> The devices that do not participate in the DHT don't need to support >>>> JOIN and LEAVE but need to do just GET/PUT. >>>> >>>> So now we have two interfaces. >>>> >>>> Node in DHT Node in >>>> DHT Node not in DHT >>>> >>>> >>>> |<---------------------------------------->| >>>> <------------------------------------------------------>| >>>> (a) GET/PUT (b) >>>> GET/PUT >>>> JOIN/LEAVE >>>> >>>> Now the question has a few angles. >>>> - Will (a) GET/PUT be dependent of the underling DHT algorithm? >>>> - Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax >>>> and >>>> semantics? >>>> - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? >>>> >>>> If an answer for any of the above question is 'yes', I think we'd be >>>> better off by defining (b) GET/PUT as a separate protocol. And I think >>>> it is a safe assumption. >>>> If we find out none of the answers is 'yes', then we would not need a >>>> separate protocol for (b) GET/PUT. >>>> Nodes not in DHT can safely just implement and support GET/PUT but not >>>> JOIN/LEAVE. >>>> >>>> Hope I added some clarity, not confusion. >> >> >> >> >> Yes sort of. I think what you are saying is that if any of the >> answers are yes, then we will not be able to build an interoperable >> protocol to do the (a) side so we will need the (b) protocol. Do I >> have this right? >> > > I am afraid that my message was not clear enough. No matter what the answers of the three questions are, we can build an interoperable protocol to do the (a) side. And I believe we should build one. The question I tried to answer was when/why we would need to build a separate protocol to do the (b) side in addition to the protocol for the (a) side. My answer to the question is that it is a safe assumption that we would be better off if we plan to design a separate protocol to do the (b) side. So I am proposing that we put the two protocols in the charter as deliverables. Thanks. Eunsoo From enrico.marocco at telecomitalia.it Thu Jun 1 04:29:18 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 01 Jun 2006 10:29:18 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447E702C.7060305@research.panasonic.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <447E702C.7060305@research.panasonic.com> Message-ID: <447EA55E.9020204@telecomitalia.it> Eunsoo Shim wrote: > So I am proposing that we put the two protocols in the charter as > deliverables. The IETF has a liason with 3GPP which has specified a GET/PUT protocol as an extension for the DIAMETER protocol. Moreover, the DIME WG in the OPS Area has a charter which starts: The Diameter Maintanence and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. I don't know the liason in details and perhaps we could argue that retrieving and storing is not AAA, but I'm pretty sure that If we put the GET/PUT only protocol in the charter, we will get a "go with DIME" from IAB and IESG members. Cullen, please correct me if I'm wrong ;-) Sorry for being repetitive. Enrico From bk9001 at gmail.com Thu Jun 1 10:28:32 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Thu, 1 Jun 2006 10:28:32 -0400 Subject: [p2p-sip] What are we doing - question 1 References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com><447DBF51.8030803@research.panasonic.com> <024101c68510$355f3240$6400a8c0@comcast.net> Message-ID: <006e01c68587$aa383f90$110aa8c0@Shikky> Peter: You raised very pertinent questions. The people that are proposing the interworking between DHTs seem to be ignoring the fact how difficult interworking of two different DHT name spaces is. Since each implementation of DHT is so different, and manages name spaces very differently, it will require major research to map DHT name spaces and I haven't so far seen any research work in this direction. Just to believe that creating API level semantics of get and put can mask such major technical difficulties, imho, is trivializing the problem. In any case, IETF has always left definition of any APIs to implementers whether terms are Get or Put, or Deposit and Retrieve, hence assigning meaning to such terms is a bad practice. cheers, --bk ----- Original Message ----- From: "Peter Pan" To: "Eunsoo Shim" ; "Cullen Jennings" Cc: "P2P-SIP" Sent: Wednesday, May 31, 2006 8:13 PM Subject: Re: [p2p-sip] What are we doing - question 1 > The abstraction of GET/PUT seems ideal to wrap complex node interactions > of > different DHTs into a simple interface. > > Few questions: > > * Will there be some DHT "type tag" in the protocol so that a node in > Kademlia DHT receiving a GET req from another node in Chord DHT will not > dump irrelevant k closest nodes to the Chord node? > * How will GET/PUT encapsulate difference of or convert distance "metric" > information of different DHTs? (eg. Chord uses subtraction while Kademlia > uses XOR to calculate node distance) > * How will a node in DHT A locate the next-hop node in DHT B to send > GET/PUT, which seems a precondition to interoperate DHTs on peer-to-peer > basis? > > PP > ----- Original Message ----- > From: "Eunsoo Shim" > To: "Cullen Jennings" > Cc: "P2P-SIP" > Sent: Wednesday, May 31, 2006 9:07 AM > Subject: Re: [p2p-sip] What are we doing - question 1 > > >> Cullen Jennings wrote: >> >> > >> > On May 30, 2006, at 10:39 AM, Alan Johnston wrote: >> > >> >> Cullen Jennings wrote: >> >> >> >>> Ok, I'm glad to hear that at least some people think we have some >> >>> consensus on this. It's been hard to tell following the list so I >> >>> appreciate people speaking up about it. >> >>> >> >>> I'll be very blunt about doing both proposal. It is not clear to >> >>> me if people think we should do both because >> >>> 1) this is the technical long term solution we want, or >> >>> 2) this would make it so at some level everyone agreed. >> >>> >> >>> Doing both will no doubt slow down finishing either. It is not >> >>> clear to the that the GET/PUT only protocol would be used if the >> >>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >> >>> want the later of the two. So if we look at our end goal, is there >> >>> a need for GET/ PUT only. >> >>> >> >> Yes. Real DHT nodes typically interact with 100s if not 1000s of >> >> peer nodes at any given instant. Will every SIP UA be capable of >> >> doing this? >> > >> > >> > I'll use chord as an example here not because I think chord is the >> > right DHT but only as a concrete example. A node that knew a few >> > other chord nodes but was not storing any data could easily interact >> > with the DHT and only have very few connections. >> > >> Please let me try to clarify the issure a little bit more. >> >> A node in Chord must maintain a finger table and data with keys of a >> certain range or locations of such data. >> Chord requires each node (in the Chord network) to have around log N >> fingers (where N is the total number of nodes in the Chord network and >> the base is 2). So if the network size is around 64,000, the number of >> fingers for each node is around 16. For a network of around a million >> nodes, the number becomes around 20. >> >> There is a cost for maintaining the finger table when the network is >> dynamic (nodes join and leave). Furthermore, each node should provide >> routing for various Chord messages such as GET/PUT/JOIN/LEAVE. >> >> When a node has limited bandwidth or battery power, the above >> requirements may be too much. If the node is behind NAT, it is not >> simple maintaining connections with fingers and other nodes for which >> the node is a finger. >> >> What I said kind of justifies the distinction between devices (SIP UAs) >> that participate in the DHT (Chord) and devices (SIP UAs) that do not. >> The devices that do not participate in the DHT don't need to support >> JOIN and LEAVE but need to do just GET/PUT. >> >> So now we have two interfaces. >> >> Node in DHT Node in >> DHT Node not in DHT >> >> >> > |<---------------------------------------->|<------------------------------- > ----------------------->| >> (a) GET/PUT (b) GET/PUT >> JOIN/LEAVE >> >> Now the question has a few angles. >> - Will (a) GET/PUT be dependent of the underling DHT algorithm? >> - Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax and >> semantics? >> - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? >> >> If an answer for any of the above question is 'yes', I think we'd be >> better off by defining (b) GET/PUT as a separate protocol. And I think >> it is a safe assumption. >> If we find out none of the answers is 'yes', then we would not need a >> separate protocol for (b) GET/PUT. >> Nodes not in DHT can safely just implement and support GET/PUT but not >> JOIN/LEAVE. >> >> Hope I added some clarity, not confusion. >> >> >> Think wireless, low bandwidth, and embedded UAs. >> >> There is a very clear layering and architectural choices here that >> >> if we only somehow choose one single DHT and standardize it that we >> >> will loose. >> > >> > >> > So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE >> > protocol. This is the part that I am failing to understand. I think >> > it would be great if we could have no central servers and not >> > standardized a P2P protocol but I don't see how we can have our cake >> > and eat it too. >> > >> >> >> >> Also, I think we need to first decide what information should be >> >> pushed and pulled from the DHT, what format it is, and how it will >> >> be retrieved. Then, and only then do we have the requirements for >> >> our DHT layer. >> > >> > I agree here but I don't see how this has to do with making a >> > protocol for the GET/PUT. >> > >> > >> >> To do both of these efforts them at the same time makes no sense to > me. >> > >> > Agree here too. >> > >> Thanks. >> >> Eunsoo >> >> > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From bk9001 at gmail.com Thu Jun 1 10:48:36 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Thu, 1 Jun 2006 10:48:36 -0400 Subject: [p2p-sip] What are we doing - question 1 References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com><447DBF51.8030803@research.panasonic.com> Message-ID: <007901c6858a$7831d2b0$110aa8c0@Shikky> Cullen wrote: >The problem with most low power devices is not > keeping up 20 connection but instead how often they have to wake up > for traffic. It may be that P2P is a real bad idea for mobile devices > because you need to keep updating data. All this really does is worry > me that selecting a DHT for use in mobile environments is a research > problem. Very good observation that seemed to be missing from the perspective so far. Without sleep mode in OTA protocols, battery life will go down to hours (just about equal to talk time on a typical mobile handset). But, a mobile node can be a greedy node - join, use service and get out from the network - a lot of churn might cause some DHT instability and more traffic to other nodes (if they are mobile some loss of battery again). But, it might still work.... (well, same issues that have deterred widespread uses of mobile video broadcast in handsets so far!!). cheers, --bk ----- Original Message ----- From: "Cullen Jennings" To: "Eunsoo Shim" Cc: "P2P-SIP" Sent: Wednesday, May 31, 2006 10:33 PM Subject: Re: [p2p-sip] What are we doing - question 1 > > One trivial comment and one important comment inline... > > On May 31, 2006, at 9:07 AM, Eunsoo Shim wrote: > >> Cullen Jennings wrote: >> >>> >>> On May 30, 2006, at 10:39 AM, Alan Johnston wrote: >>> >>>> Cullen Jennings wrote: >>>> >>>>> Ok, I'm glad to hear that at least some people think we have some >>>>> consensus on this. It's been hard to tell following the list so I >>>>> appreciate people speaking up about it. >>>>> >>>>> I'll be very blunt about doing both proposal. It is not clear to >>>>> me if people think we should do both because >>>>> 1) this is the technical long term solution we want, or >>>>> 2) this would make it so at some level everyone agreed. >>>>> >>>>> Doing both will no doubt slow down finishing either. It is not >>>>> clear to the that the GET/PUT only protocol would be used if the >>>>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >>>>> want the later of the two. So if we look at our end goal, is >>>>> there >>>>> a need for GET/ PUT only. >>>>> >>>> Yes. Real DHT nodes typically interact with 100s if not 1000s of >>>> peer nodes at any given instant. Will every SIP UA be capable of >>>> doing this? >>> >>> >>> I'll use chord as an example here not because I think chord is the >>> right DHT but only as a concrete example. A node that knew a few >>> other chord nodes but was not storing any data could easily interact >>> with the DHT and only have very few connections. >>> >> Please let me try to clarify the issure a little bit more. >> >> A node in Chord must maintain a finger table and data with keys of a >> certain range or locations of such data. >> Chord requires each node (in the Chord network) to have around log N >> fingers (where N is the total number of nodes in the Chord network and >> the base is 2). So if the network size is around 64,000, the >> number of >> fingers for each node is around 16. For a network of around a million >> nodes, the number becomes around 20. > > the trivial comment - A trivial modification to the Chord algo would > say that if a node wanted less finger tables, it dropped half the > current ones and kept every other finger entry - things would still > work. I'm not arguing this is a good idea but I am pointing out there > are many ways to modify a DHT to meet this somewhat requirement of > low connection count. The problem with most low power devices is not > keeping up 20 connection but instead how often they have to wake up > for traffic. It may be that P2P is a real bad idea for mobile devices > because you need to keep updating data. All this really does is worry > me that selecting a DHT for use in mobile environments is a research > problem. > >> >> There is a cost for maintaining the finger table when the network is >> dynamic (nodes join and leave). Furthermore, each node should provide >> routing for various Chord messages such as GET/PUT/JOIN/LEAVE. >> >> When a node has limited bandwidth or battery power, the above >> requirements may be too much. If the node is behind NAT, it is not >> simple maintaining connections with fingers and other nodes for which >> the node is a finger. > > True that it is not easy but it's not clear that it is any harder > than setting up RTP between two devices behind NAT which I believe to > be a requirement of this work. > >> >> What I said kind of justifies the distinction between devices (SIP >> UAs) >> that participate in the DHT (Chord) and devices (SIP UAs) that do not. >> The devices that do not participate in the DHT don't need to support >> JOIN and LEAVE but need to do just GET/PUT. >> >> So now we have two interfaces. >> >> Node in DHT Node in >> DHT Node not in DHT >> >> >> |<---------------------------------------->| >> <------------------------------------------------------>| >> (a) GET/PUT (b) >> GET/PUT >> JOIN/LEAVE >> >> Now the question has a few angles. >> - Will (a) GET/PUT be dependent of the underling DHT algorithm? >> - Will (a) GET/PUT and (b) GET/PUT have any difference in the >> syntax and >> semantics? >> - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? >> >> If an answer for any of the above question is 'yes', I think we'd be >> better off by defining (b) GET/PUT as a separate protocol. And I think >> it is a safe assumption. >> If we find out none of the answers is 'yes', then we would not need a >> separate protocol for (b) GET/PUT. >> Nodes not in DHT can safely just implement and support GET/PUT but not >> JOIN/LEAVE. >> >> Hope I added some clarity, not confusion. > > Yes sort of. I think what you are saying is that if any of the > answers are yes, then we will not be able to build an interoperable > protocol to do the (a) side so we will need the (b) protocol. Do I > have this right? > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Thu Jun 1 11:19:22 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Thu, 1 Jun 2006 08:19:22 -0700 Subject: [p2p-sip] What are we doing - question 1 References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com><447DBF51.8030803@research.panasonic.com> <024101c68510$355f3240$6400a8c0@comcast.net> <006e01c68587$aa383f90$110aa8c0@Shikky> Message-ID: <001001c6858e$c375b800$6400a8c0@comcast.net> It reads like that anyone who will or have been working on building p2p sip networks can no longer wait for any P2P SIP protocol possibly standardized here, and can now go ahead start building theirs by any "internal" p2p protocol over any DHT. As long as they can interoperate with others (P2P SIP standard followers or not) via RFC 3261 gateways (or their UA is SIP based), none will lose. Not bad. PP ----- Original Message ----- From: "Brijesh Kumar" To: "Peter Pan" ; "Cullen Jennings" Cc: "P2P-SIP" Sent: Thursday, June 01, 2006 7:28 AM Subject: Re: [p2p-sip] What are we doing - question 1 > Peter: > > You raised very pertinent questions. > > The people that are proposing the interworking between DHTs seem to be > ignoring the > fact how difficult interworking of two different DHT name spaces is. > > Since each implementation of DHT is so different, and manages name spaces > very differently, > it will require major research to map DHT name spaces and I haven't so far > seen any research > work in this direction. Just to believe that creating API level semantics of > get and put can mask > such major technical difficulties, imho, is trivializing the problem. > > In any case, IETF has always left definition of any APIs to implementers > whether terms are > Get or Put, or Deposit and Retrieve, hence assigning meaning to such terms > is a bad practice. > > cheers, > > --bk > > > ----- Original Message ----- > From: "Peter Pan" > To: "Eunsoo Shim" ; "Cullen Jennings" > > Cc: "P2P-SIP" > Sent: Wednesday, May 31, 2006 8:13 PM > Subject: Re: [p2p-sip] What are we doing - question 1 > > > > The abstraction of GET/PUT seems ideal to wrap complex node interactions > > of > > different DHTs into a simple interface. > > > > Few questions: > > > > * Will there be some DHT "type tag" in the protocol so that a node in > > Kademlia DHT receiving a GET req from another node in Chord DHT will not > > dump irrelevant k closest nodes to the Chord node? > > * How will GET/PUT encapsulate difference of or convert distance "metric" > > information of different DHTs? (eg. Chord uses subtraction while Kademlia > > uses XOR to calculate node distance) > > * How will a node in DHT A locate the next-hop node in DHT B to send > > GET/PUT, which seems a precondition to interoperate DHTs on peer-to-peer > > basis? > > > > PP > > ----- Original Message ----- > > From: "Eunsoo Shim" > > To: "Cullen Jennings" > > Cc: "P2P-SIP" > > Sent: Wednesday, May 31, 2006 9:07 AM > > Subject: Re: [p2p-sip] What are we doing - question 1 > > > > > >> Cullen Jennings wrote: > >> > >> > > >> > On May 30, 2006, at 10:39 AM, Alan Johnston wrote: > >> > > >> >> Cullen Jennings wrote: > >> >> > >> >>> Ok, I'm glad to hear that at least some people think we have some > >> >>> consensus on this. It's been hard to tell following the list so I > >> >>> appreciate people speaking up about it. > >> >>> > >> >>> I'll be very blunt about doing both proposal. It is not clear to > >> >>> me if people think we should do both because > >> >>> 1) this is the technical long term solution we want, or > >> >>> 2) this would make it so at some level everyone agreed. > >> >>> > >> >>> Doing both will no doubt slow down finishing either. It is not > >> >>> clear to the that the GET/PUT only protocol would be used if the > >> >>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just > >> >>> want the later of the two. So if we look at our end goal, is there > >> >>> a need for GET/ PUT only. > >> >>> > >> >> Yes. Real DHT nodes typically interact with 100s if not 1000s of > >> >> peer nodes at any given instant. Will every SIP UA be capable of > >> >> doing this? > >> > > >> > > >> > I'll use chord as an example here not because I think chord is the > >> > right DHT but only as a concrete example. A node that knew a few > >> > other chord nodes but was not storing any data could easily interact > >> > with the DHT and only have very few connections. > >> > > >> Please let me try to clarify the issure a little bit more. > >> > >> A node in Chord must maintain a finger table and data with keys of a > >> certain range or locations of such data. > >> Chord requires each node (in the Chord network) to have around log N > >> fingers (where N is the total number of nodes in the Chord network and > >> the base is 2). So if the network size is around 64,000, the number of > >> fingers for each node is around 16. For a network of around a million > >> nodes, the number becomes around 20. > >> > >> There is a cost for maintaining the finger table when the network is > >> dynamic (nodes join and leave). Furthermore, each node should provide > >> routing for various Chord messages such as GET/PUT/JOIN/LEAVE. > >> > >> When a node has limited bandwidth or battery power, the above > >> requirements may be too much. If the node is behind NAT, it is not > >> simple maintaining connections with fingers and other nodes for which > >> the node is a finger. > >> > >> What I said kind of justifies the distinction between devices (SIP UAs) > >> that participate in the DHT (Chord) and devices (SIP UAs) that do not. > >> The devices that do not participate in the DHT don't need to support > >> JOIN and LEAVE but need to do just GET/PUT. > >> > >> So now we have two interfaces. > >> > >> Node in DHT Node in > >> DHT Node not in DHT > >> > >> > >> > > |<---------------------------------------->|<------------------------------- > > ----------------------->| > >> (a) GET/PUT (b) GET/PUT > >> JOIN/LEAVE > >> > >> Now the question has a few angles. > >> - Will (a) GET/PUT be dependent of the underling DHT algorithm? > >> - Will (a) GET/PUT and (b) GET/PUT have any difference in the syntax and > >> semantics? > >> - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? > >> > >> If an answer for any of the above question is 'yes', I think we'd be > >> better off by defining (b) GET/PUT as a separate protocol. And I think > >> it is a safe assumption. > >> If we find out none of the answers is 'yes', then we would not need a > >> separate protocol for (b) GET/PUT. > >> Nodes not in DHT can safely just implement and support GET/PUT but not > >> JOIN/LEAVE. > >> > >> Hope I added some clarity, not confusion. > >> > >> >> Think wireless, low bandwidth, and embedded UAs. > >> >> There is a very clear layering and architectural choices here that > >> >> if we only somehow choose one single DHT and standardize it that we > >> >> will loose. > >> > > >> > > >> > So I take it you are saying we should NOT do the GET/PUT/JOIN/LEAVE > >> > protocol. This is the part that I am failing to understand. I think > >> > it would be great if we could have no central servers and not > >> > standardized a P2P protocol but I don't see how we can have our cake > >> > and eat it too. > >> > > >> >> > >> >> Also, I think we need to first decide what information should be > >> >> pushed and pulled from the DHT, what format it is, and how it will > >> >> be retrieved. Then, and only then do we have the requirements for > >> >> our DHT layer. > >> > > >> > I agree here but I don't see how this has to do with making a > >> > protocol for the GET/PUT. > >> > > >> > > >> >> To do both of these efforts them at the same time makes no sense to > > me. > >> > > >> > Agree here too. > >> > > >> Thanks. > >> > >> Eunsoo > >> > >> > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From fluffy at cisco.com Sat Jun 3 18:21:00 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sat, 3 Jun 2006 15:21:00 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447EA55E.9020204@telecomitalia.it> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <447E702C.7060305@research.panasonic.com> <447EA55E.9020204@telecomitalia.it> Message-ID: <25262164-A6FE-40D3-9AD4-0DBE5D4D5AC3@cisco.com> On Jun 1, 2006, at 1:29 AM, Enrico Marocco wrote: > Eunsoo Shim wrote: >> So I am proposing that we put the two protocols in the charter as >> deliverables. > > The IETF has a liason with 3GPP which has specified a GET/PUT protocol > as an extension for the DIAMETER protocol. Moreover, the DIME WG > in the > OPS Area has a charter which starts: > > The Diameter Maintanence and Extensions WG will focus on maintenance > and extensions to the Diameter protocol required to enable its use > in applications such as IP telephony and Local Area Network > authentication, authorization and accounting. > > I don't know the liason in details and perhaps we could argue that > retrieving and storing is not AAA, but I'm pretty sure that If we put > the GET/PUT only protocol in the charter, we will get a "go with DIME" > from IAB and IESG members. Cullen, please correct me if I'm wrong ;-) Oh, I have no idea what you would get from IAB or IESG. I doubt the conversation is well enough formed or enough information is on the table for the IESG or IAB to really form an opinion on the topic. However, from me as individual contributor, you do have the outstanding question of why a SIP REGISTER is not sufficient to do the GET and PUT. The advantage of this is that existing UA devices could already be talking protocol (b). There has been suggestion that this might not be clear for finding a services such as a TURN server but I did make a proposal for that based on some sort of service URI like convention. From enrico.marocco at telecomitalia.it Sun Jun 4 12:04:58 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Sun, 04 Jun 2006 18:04:58 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <25262164-A6FE-40D3-9AD4-0DBE5D4D5AC3@cisco.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <447E702C.7060305@research.panasonic.com> <447EA55E.9020204@telecomitalia.it> <25262164-A6FE-40D3-9AD4-0DBE5D4D5AC3@cisco.com> Message-ID: <448304AA.5040307@telecomitalia.it> Cullen Jennings wrote: > However, from me as individual contributor, you do have the outstanding > question of why a SIP REGISTER is not sufficient to do the GET and PUT. > The advantage of this is that existing UA devices could already be > talking protocol (b). There has been suggestion that this might not be > clear for finding a services such as a TURN server but I did make a > proposal for that based on some sort of service URI like convention. That's exactly the solution David and me have proposed for connecting P2P SIP overlays and traditional SIP domains in draft-marocco-sipping-p2p-scenarios. We would really appreciate comments about it; so far we haven't received any. Enrico From dbarrett at quinthar.com Sun Jun 4 20:17:19 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sun, 4 Jun 2006 17:17:19 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <200606050019.k550HmX5011803@cs.columbia.edu> I'd like to reitereate Cullen's question: what, fundamentally, are we trying to do here? Everything feels very slippery. Is there any consensus on any of the following issues? 1) Does P2PSIP require DNS? 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? 3) Does P2PSIP work for 2 devices? 4) Does P2PSIP work for 2B devices? 5) Does P2PSIP require any central servers (other than, potentially, DNS)? 6) Does P2PSIP use a DHT? 7) Does P2PSIP work with non-P2PSIP UAs? 8) Does P2PSIP use modified SIP messages or some new syntax? 9) Does P2PSIP support secure authentication? I don't mean this as a critique, but I don't feel like we're gathering toward consensus on any of these points. Thus perhaps we should choose a new tactic? I like Enrico's quick enumeration of his vision for P2PSIP. I expect were we all to give it a shot, we'd find 2-4 basic variations. Maybe once we have those we can name them in a totally vague way and grapple with the subject from a new perspective. Thus here's my quick-bullet summary of the P2PSIP I'd like to see standardized; I'm eager to hear yours: - P2PSIP 1.0 is an extension to the SIP protocol that enables UAs to connect to and participate in a DHT that performs the basic functionality of a SIP proxy. - Nodes can choose whether to participate in or only query the DHT. - A new SIP address type is created to differentiate between client/server and P2P proxies: p2psip:[@@[]] - is any string; if unspecified it is assumed to be "global". - is the IP:port or domain name of any P2PSIP UA; if left unspecified it is assumed to be any of a well-known collection of public bootstrapping nodes maintained by volunteers. - Resolving a P2PSIP address consists of contacting the bootstrapping node, joining the named DHT, and looking up the IP:port of the username. - Any number of DHTs can exist in parallel on the same network. - P2PSIP 1.0 does not provide any built-in authentication framework. - P2PSIP 1.0 is not intended for production use; it is a prototype protocol - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is finalized, not before. I have no idea if this is similar to anyone else's vision, but I'll name this stake in the ground the "decentralized proxy" proposal given that it aims to do no more than decentralize the most basic client/server SIP proxy functions. How would you summarize and name your vision? How does it differ from mine and everyone else's? -david From hu.xinyu at huawei.com Sun Jun 4 22:17:56 2006 From: hu.xinyu at huawei.com (Seaward Hu) Date: Mon, 05 Jun 2006 10:17:56 +0800 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606050019.k550HmX5011803@cs.columbia.edu> Message-ID: <000001c68846$427f8720$1a05a40a@china.huawei.com> Hello David, I'm sorry that I don't agree to set the [bootstrap] as a part of P2P SIP address, below is my options: 1.Bootstrap server is used to provide some information about existing SN to a new ON, so it will be useless for a ON after it has logged in a P2P SIP overlay network, why should the ON always tell others this information? 2.There may be several bootstraps which maintained by volunteers can be acquired in a DHT , how to select one to fill the address? > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Monday, June 05, 2006 8:17 AM > To: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] What are we doing, question 2 > > > I'd like to reitereate Cullen's question: what, > fundamentally, are we trying to do here? Everything feels > very slippery. Is there any consensus on any of the following issues? > > 1) Does P2PSIP require DNS? > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > 3) Does P2PSIP work for 2 devices? > 4) Does P2PSIP work for 2B devices? > 5) Does P2PSIP require any central servers (other than, > potentially, DNS)? > 6) Does P2PSIP use a DHT? > 7) Does P2PSIP work with non-P2PSIP UAs? > 8) Does P2PSIP use modified SIP messages or some new syntax? > 9) Does P2PSIP support secure authentication? > > I don't mean this as a critique, but I don't feel like we're > gathering toward consensus on any of these points. Thus > perhaps we should choose a new tactic? > > I like Enrico's quick enumeration of his vision for P2PSIP. > I expect were we all to give it a shot, we'd find 2-4 basic > variations. Maybe once we have those we can name them in a > totally vague way and grapple with the subject from a new perspective. > > Thus here's my quick-bullet summary of the P2PSIP I'd like to > see standardized; I'm eager to hear yours: > > - P2PSIP 1.0 is an extension to the SIP protocol that enables > UAs to connect > to and participate in a DHT that performs the basic > functionality of a SIP > proxy. > - Nodes can choose whether to participate in or only query the DHT. > - A new SIP address type is created to differentiate between > client/server > and P2P proxies: p2psip:[@@[]] > - is any string; if unspecified it is assumed to be > "global". > - is the IP:port or domain name of any P2PSIP UA; if left > unspecified it is assumed to be any of a well-known > collection of public > bootstrapping nodes maintained by volunteers. > - Resolving a P2PSIP address consists of contacting the > bootstrapping node, > joining the named DHT, and looking up the IP:port of the username. > - Any number of DHTs can exist in parallel on the same network. > - P2PSIP 1.0 does not provide any built-in authentication framework. > - P2PSIP 1.0 is not intended for production use; it is a > prototype protocol > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > finalized, not before. > > I have no idea if this is similar to anyone else's vision, > but I'll name this stake in the ground the "decentralized > proxy" proposal given that it aims to do no more than > decentralize the most basic client/server SIP proxy functions. > > How would you summarize and name your vision? How does it > differ from mine and everyone else's? > > -david > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From dbarrett at quinthar.com Sun Jun 4 23:16:47 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sun, 4 Jun 2006 20:16:47 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <000001c68846$427f8720$1a05a40a@china.huawei.com> Message-ID: <200606050317.k553GqX5013938@cs.columbia.edu> Hi Seaward. I'd prefer not to debate the specifics at this point -- if we can agree that there's some kind of "p2psip:" address type, I think that's as deep as we need to get agreement on the big picture. Basically, I'm thinking there's some kind of P2PSIP address that can be printed on a business card, posted on a webpage, sent in an email, and so on. Somehow you can plug this into your P2PSIP UA, and it magically figures out which DHT my UA is registered, then uses it to send me an INVITE. I'm less concerned with how this happens than with getting your agreement on whether or not you share this goal. This I'll ask: 1) Do you agree there should be some address that you can read off my business card and type into your UA that somehow causes it to locate my UA and establish a call? 2) Do you agree (1) should be accomplished by using a special 'p2psip:' address type to differentiate it from a normal 'sip:' address? -david > -----Original Message----- > From: Seaward Hu [mailto:hu.xinyu at huawei.com] > Sent: Sunday, June 04, 2006 7:18 PM > To: 'David Barrett'; p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > Hello David, > I'm sorry that I don't agree to set the [bootstrap] as a part of > P2P SIP address, below is my options: > 1.Bootstrap server is used to provide some information about > existing SN to a new ON, so it will be useless for a ON after it has > logged > in a P2P SIP overlay network, why should the ON always tell others this > information? > 2.There may be several bootstraps which maintained by volunteers > can be acquired in a DHT , how to select one to fill the address? > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > > Sent: Monday, June 05, 2006 8:17 AM > > To: p2p-sip at cs.columbia.edu > > Subject: [p2p-sip] What are we doing, question 2 > > > > > > I'd like to reitereate Cullen's question: what, > > fundamentally, are we trying to do here? Everything feels > > very slippery. Is there any consensus on any of the following issues? > > > > 1) Does P2PSIP require DNS? > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > 3) Does P2PSIP work for 2 devices? > > 4) Does P2PSIP work for 2B devices? > > 5) Does P2PSIP require any central servers (other than, > > potentially, DNS)? > > 6) Does P2PSIP use a DHT? > > 7) Does P2PSIP work with non-P2PSIP UAs? > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > 9) Does P2PSIP support secure authentication? > > > > I don't mean this as a critique, but I don't feel like we're > > gathering toward consensus on any of these points. Thus > > perhaps we should choose a new tactic? > > > > I like Enrico's quick enumeration of his vision for P2PSIP. > > I expect were we all to give it a shot, we'd find 2-4 basic > > variations. Maybe once we have those we can name them in a > > totally vague way and grapple with the subject from a new perspective. > > > > Thus here's my quick-bullet summary of the P2PSIP I'd like to > > see standardized; I'm eager to hear yours: > > > > - P2PSIP 1.0 is an extension to the SIP protocol that enables > > UAs to connect > > to and participate in a DHT that performs the basic > > functionality of a SIP > > proxy. > > - Nodes can choose whether to participate in or only query the DHT. > > - A new SIP address type is created to differentiate between > > client/server > > and P2P proxies: p2psip:[@@[]] > > - is any string; if unspecified it is assumed to be > > "global". > > - is the IP:port or domain name of any P2PSIP UA; if left > > unspecified it is assumed to be any of a well-known > > collection of public > > bootstrapping nodes maintained by volunteers. > > - Resolving a P2PSIP address consists of contacting the > > bootstrapping node, > > joining the named DHT, and looking up the IP:port of the username. > > - Any number of DHTs can exist in parallel on the same network. > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > - P2PSIP 1.0 is not intended for production use; it is a > > prototype protocol > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > finalized, not before. > > > > I have no idea if this is similar to anyone else's vision, > > but I'll name this stake in the ground the "decentralized > > proxy" proposal given that it aims to do no more than > > decentralize the most basic client/server SIP proxy functions. > > > > How would you summarize and name your vision? How does it > > differ from mine and everyone else's? > > > > -david > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From huang-ming.pan at comcast.net Mon Jun 5 00:17:34 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sun, 4 Jun 2006 21:17:34 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606050317.k553GqX5013938@cs.columbia.edu> Message-ID: <003b01c68856$f91ead20$6400a8c0@comcast.net> My amen for "p2psip:" address scheme!! It indicates address lookup via DHT instead of via DNS SRV. Peter ----- Original Message ----- From: "David Barrett" To: "'Seaward Hu'" ; Sent: Sunday, June 04, 2006 8:16 PM Subject: Re: [p2p-sip] What are we doing, question 2 > Hi Seaward. > > I'd prefer not to debate the specifics at this point -- if we can agree that > there's some kind of "p2psip:" address type, I think that's as > deep as we need to get agreement on the big picture. > > Basically, I'm thinking there's some kind of P2PSIP address that can be > printed on a business card, posted on a webpage, sent in an email, and so > on. Somehow you can plug this into your P2PSIP UA, and it magically figures > out which DHT my UA is registered, then uses it to send me an INVITE. > > I'm less concerned with how this happens than with getting your agreement on > whether or not you share this goal. This I'll ask: > > 1) Do you agree there should be some address that you can read off my > business card and type into your UA that somehow causes it to locate my UA > and establish a call? > > 2) Do you agree (1) should be accomplished by using a special > 'p2psip:' address type to differentiate it from a normal > 'sip:' address? > > -david > > > -----Original Message----- > > From: Seaward Hu [mailto:hu.xinyu at huawei.com] > > Sent: Sunday, June 04, 2006 7:18 PM > > To: 'David Barrett'; p2p-sip at cs.columbia.edu > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > Hello David, > > I'm sorry that I don't agree to set the [bootstrap] as a part of > > P2P SIP address, below is my options: > > 1.Bootstrap server is used to provide some information about > > existing SN to a new ON, so it will be useless for a ON after it has > > logged > > in a P2P SIP overlay network, why should the ON always tell others this > > information? > > 2.There may be several bootstraps which maintained by volunteers > > can be acquired in a DHT , how to select one to fill the address? > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > > > Sent: Monday, June 05, 2006 8:17 AM > > > To: p2p-sip at cs.columbia.edu > > > Subject: [p2p-sip] What are we doing, question 2 > > > > > > > > > I'd like to reitereate Cullen's question: what, > > > fundamentally, are we trying to do here? Everything feels > > > very slippery. Is there any consensus on any of the following issues? > > > > > > 1) Does P2PSIP require DNS? > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > > 3) Does P2PSIP work for 2 devices? > > > 4) Does P2PSIP work for 2B devices? > > > 5) Does P2PSIP require any central servers (other than, > > > potentially, DNS)? > > > 6) Does P2PSIP use a DHT? > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > > 9) Does P2PSIP support secure authentication? > > > > > > I don't mean this as a critique, but I don't feel like we're > > > gathering toward consensus on any of these points. Thus > > > perhaps we should choose a new tactic? > > > > > > I like Enrico's quick enumeration of his vision for P2PSIP. > > > I expect were we all to give it a shot, we'd find 2-4 basic > > > variations. Maybe once we have those we can name them in a > > > totally vague way and grapple with the subject from a new perspective. > > > > > > Thus here's my quick-bullet summary of the P2PSIP I'd like to > > > see standardized; I'm eager to hear yours: > > > > > > - P2PSIP 1.0 is an extension to the SIP protocol that enables > > > UAs to connect > > > to and participate in a DHT that performs the basic > > > functionality of a SIP > > > proxy. > > > - Nodes can choose whether to participate in or only query the DHT. > > > - A new SIP address type is created to differentiate between > > > client/server > > > and P2P proxies: p2psip:[@@[]] > > > - is any string; if unspecified it is assumed to be > > > "global". > > > - is the IP:port or domain name of any P2PSIP UA; if left > > > unspecified it is assumed to be any of a well-known > > > collection of public > > > bootstrapping nodes maintained by volunteers. > > > - Resolving a P2PSIP address consists of contacting the > > > bootstrapping node, > > > joining the named DHT, and looking up the IP:port of the username. > > > - Any number of DHTs can exist in parallel on the same network. > > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > > - P2PSIP 1.0 is not intended for production use; it is a > > > prototype protocol > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > > finalized, not before. > > > > > > I have no idea if this is similar to anyone else's vision, > > > but I'll name this stake in the ground the "decentralized > > > proxy" proposal given that it aims to do no more than > > > decentralize the most basic client/server SIP proxy functions. > > > > > > How would you summarize and name your vision? How does it > > > differ from mine and everyone else's? > > > > > > -david > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > From hu.xinyu at huawei.com Mon Jun 5 02:01:26 2006 From: hu.xinyu at huawei.com (Seaward Hu) Date: Mon, 05 Jun 2006 14:01:26 +0800 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003b01c68856$f91ead20$6400a8c0@comcast.net> Message-ID: <000001c68865$7e7bb9f0$1a05a40a@china.huawei.com> I also agree with the address format of "p2psip:", and there have many things as such Mr.Eunsoo pointed out in his slide need to be specified, may we pay some attention on that? by the way, is the iGlance base on DHT topology? > -----Original Message----- > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > Sent: Monday, June 05, 2006 12:18 PM > To: David Barrett; 'Seaward Hu'; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > > My amen for "p2psip:" address scheme!! > > It indicates address lookup via DHT instead of via DNS SRV. > > Peter > ----- Original Message ----- > From: "David Barrett" > To: "'Seaward Hu'" ; > Sent: Sunday, June 04, 2006 8:16 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > Hi Seaward. > > > > I'd prefer not to debate the specifics at this point -- if we can > > agree > that > > there's some kind of "p2psip:" address type, I > think that's > > as deep as we need to get agreement on the big picture. > > > > Basically, I'm thinking there's some kind of P2PSIP address > that can > > be printed on a business card, posted on a webpage, sent in > an email, > > and so on. Somehow you can plug this into your P2PSIP UA, and it > > magically > figures > > out which DHT my UA is registered, then uses it to send me > an INVITE. > > > > I'm less concerned with how this happens than with getting your > > agreement > on > > whether or not you share this goal. This I'll ask: > > > > 1) Do you agree there should be some address that you can > read off my > > business card and type into your UA that somehow causes it > to locate > > my UA and establish a call? > > > > 2) Do you agree (1) should be accomplished by using a special > > 'p2psip:' address type to differentiate it from a normal > > 'sip:' address? > > > > -david > > > > > -----Original Message----- > > > From: Seaward Hu [mailto:hu.xinyu at huawei.com] > > > Sent: Sunday, June 04, 2006 7:18 PM > > > To: 'David Barrett'; p2p-sip at cs.columbia.edu > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > Hello David, > > > I'm sorry that I don't agree to set the > [bootstrap] as a > > > part > of > > > P2P SIP address, below is my options: > > > 1.Bootstrap server is used to provide some information > > > about existing SN to a new ON, so it will be useless for > a ON after > > > it has logged in a P2P SIP overlay network, why should > the ON always > > > tell others this information? > > > 2.There may be several bootstraps which maintained by > volunteers > > > can be acquired in a DHT , how to select one to fill the address? > > > > > > > -----Original Message----- > > > > From: p2p-sip-bounces at cs.columbia.edu > > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David > > > > Barrett > > > > Sent: Monday, June 05, 2006 8:17 AM > > > > To: p2p-sip at cs.columbia.edu > > > > Subject: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > I'd like to reitereate Cullen's question: what, > fundamentally, are > > > > we trying to do here? Everything feels very slippery. > Is there > > > > any consensus on any of the following issues? > > > > > > > > 1) Does P2PSIP require DNS? > > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP > > > > addresses? > > > > 3) Does P2PSIP work for 2 devices? > > > > 4) Does P2PSIP work for 2B devices? > > > > 5) Does P2PSIP require any central servers (other than, > > > > potentially, DNS)? > > > > 6) Does P2PSIP use a DHT? > > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > > > 9) Does P2PSIP support secure authentication? > > > > > > > > I don't mean this as a critique, but I don't feel like we're > > > > gathering toward consensus on any of these points. > Thus perhaps > > > > we should choose a new tactic? > > > > > > > > I like Enrico's quick enumeration of his vision for P2PSIP. I > > > > expect were we all to give it a shot, we'd find 2-4 basic > > > > variations. Maybe once we have those we can name them in a > > > > totally vague way and grapple with the subject from a new > > > > perspective. > > > > > > > > Thus here's my quick-bullet summary of the P2PSIP I'd > like to see > > > > standardized; I'm eager to hear yours: > > > > > > > > - P2PSIP 1.0 is an extension to the SIP protocol that > enables UAs > > > > to connect > > > > to and participate in a DHT that performs the basic > > > > functionality of a SIP > > > > proxy. > > > > - Nodes can choose whether to participate in or only query the > > > > DHT. > > > > - A new SIP address type is created to differentiate between > > > > client/server > > > > and P2P proxies: p2psip:[@@[]] > > > > - is any string; if unspecified it is assumed to be > > > > "global". > > > > - is the IP:port or domain name of any > P2PSIP UA; if left > > > > unspecified it is assumed to be any of a well-known > > > > collection of public > > > > bootstrapping nodes maintained by volunteers. > > > > - Resolving a P2PSIP address consists of contacting the > > > > bootstrapping node, > > > > joining the named DHT, and looking up the IP:port of > the username. > > > > - Any number of DHTs can exist in parallel on the same network. > > > > - P2PSIP 1.0 does not provide any built-in > authentication framework. > > > > - P2PSIP 1.0 is not intended for production use; it is a > > > > prototype protocol > > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > > > finalized, not before. > > > > > > > > I have no idea if this is similar to anyone else's vision, but > > > > I'll name this stake in the ground the "decentralized proxy" > > > > proposal given that it aims to do no more than decentralize the > > > > most basic client/server SIP proxy functions. > > > > > > > > How would you summarize and name your vision? How does > it differ > > > > from mine and everyone else's? > > > > > > > > -david > > > > > > > > _______________________________________________ > > > > p2p-sip mailing list > > > > p2p-sip at cs.columbia.edu > > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > > > > > > From jh at tutpro.com Mon Jun 5 03:01:53 2006 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 5 Jun 2006 10:01:53 +0300 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606050317.k553GqX5013938@cs.columbia.edu> References: <000001c68846$427f8720$1a05a40a@china.huawei.com> <200606050317.k553GqX5013938@cs.columbia.edu> Message-ID: <17539.55009.28037.809557@rautu.tutpro.com> David Barrett writes: > 2) Do you agree (1) should be accomplished by using a special > 'p2psip:' address type to differentiate it from a normal > 'sip:' address? i once proposed that there would be nothing special, just sip:user at domain, where user at domain is the same as person's email address. when someone sends a request to that user, his user agent or proxy would first try sip:user.domain.p2p.arpa. this way even if user's domain does not provide any p2p sip service, user in any domain could still have it. -- juha From hgs at cs.columbia.edu Mon Jun 5 09:27:17 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Mon, 5 Jun 2006 09:27:17 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606050317.k553GqX5013938@cs.columbia.edu> References: <200606050317.k553GqX5013938@cs.columbia.edu> Message-ID: > I'd prefer not to debate the specifics at this point -- if we can > agree that > there's some kind of "p2psip:" address type, I think > that's as > deep as we need to get agreement on the big picture. I think this is a fundamentally bad idea. I shouldn't have to change my address (and business card) just because I'm changing some low- level technical detail of how signaling requests are routed. In any event, just like many web pages are simply listed as www.something.com (instead of http://www.something.com), I expect that many business cards and directories will simply contain alice at something.com. It's the role of protocols to make these resolution details transparent to the user. This isn't terribly difficult in this particular case. Henning From spencer at mcsr-labs.org Mon Jun 5 09:48:34 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 5 Jun 2006 08:48:34 -0500 Subject: [p2p-sip] What are we doing, question 2 References: <200606050317.k553GqX5013938@cs.columbia.edu> Message-ID: <04f301c688a6$bd6c0700$0700a8c0@china.huawei.com> I agree with Henning at this point, especially since I would expect many people would have both anyway, but my comment is based on architectural purity, not on technical discussions. We DO use two different schemes (sip and sips) when it seems to make sense to do so. Based on discussion to date, I don't understand why using the same scheme for SIP-CS and SIP-P2P is a problem, and why using two different schemes is a solution. Please keep talking, of course. Spencer >> I'd prefer not to debate the specifics at this point -- if we can >> agree that >> there's some kind of "p2psip:" address type, I think >> that's as >> deep as we need to get agreement on the big picture. > > I think this is a fundamentally bad idea. I shouldn't have to change > my address (and business card) just because I'm changing some low- > level technical detail of how signaling requests are routed. In any > event, just like many web pages are simply listed as > www.something.com (instead of http://www.something.com), I expect > that many business cards and directories will simply contain > alice at something.com. > > It's the role of protocols to make these resolution details > transparent to the user. This isn't terribly difficult in this > particular case. > > Henning From jh at tutpro.com Mon Jun 5 09:56:52 2006 From: jh at tutpro.com (Juha Heinanen) Date: Mon, 5 Jun 2006 16:56:52 +0300 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <04f301c688a6$bd6c0700$0700a8c0@china.huawei.com> References: <200606050317.k553GqX5013938@cs.columbia.edu> <04f301c688a6$bd6c0700$0700a8c0@china.huawei.com> Message-ID: <17540.14372.587136.845291@rautu.tutpro.com> Spencer Dawkins writes: > We DO use two different schemes (sip and sips) when it seems to make sense > to do so. the discussion on sip list seems to indicate the opposite, i.e., it does not make sense to have both sip and sips. -- juha From enrico.marocco at telecomitalia.it Mon Jun 5 10:05:10 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Mon, 05 Jun 2006 16:05:10 +0200 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606050019.k550HmX5011803@cs.columbia.edu> References: <200606050019.k550HmX5011803@cs.columbia.edu> Message-ID: <44843A16.6010709@telecomitalia.it> David, > I'd like to reitereate Cullen's question: what, fundamentally, are we trying > to do here? We are trying to "leverage the distributed nature of P2P to allow for distributed resource discovery in a SIP network". We _have consensus_ on this because it is the definition of P2PSIP (p2psip.org) and this is the P2PSIP mailing list. > [..] > Thus here's my quick-bullet summary of the P2PSIP I'd like to see > standardized; I'm eager to hear yours: > > - P2PSIP 1.0 is an extension to the SIP protocol that enables UAs to connect > to and participate in a DHT that performs the basic functionality of a SIP > proxy. Ok. > - Nodes can choose whether to participate in or only query the DHT. In my very personal opinion, nodes should not be able to choose whether or not to participate in the DHT. Instead, the DHT should be smart enough to not require resources from nodes more than they could share, i.e. it should apply policies based on performance metrics (e.g. uptime, bandwidth, load...) for promoting ordinary nodes to super nodes. > - A new SIP address type is created to differentiate between client/server > and P2P proxies: p2psip:[@@[]] > - is any string; if unspecified it is assumed to be "global". > - is the IP:port or domain name of any P2PSIP UA; if left > unspecified it is assumed to be any of a well-known collection of public > bootstrapping nodes maintained by volunteers. > - Resolving a P2PSIP address consists of contacting the bootstrapping node, > joining the named DHT, and looking up the IP:port of the username. Your solution is not doable in P2PSIP. P2PSIP _is SIP_ in that: + both P2P and conventional UAs use SIP for communcating (INVITE, MESSAGE, BYE...). This implies that they should be identifiable by means of sip: URIs; + when they are not isolated, P2PSIP domains _must_ be located by conventional SIP elements using procedures defined in RFC 3263. > - Any number of DHTs can exist in parallel on the same network. Sure. > - P2PSIP 1.0 does not provide any built-in authentication framework. Not a framework, but possibly some mechanisms for achieving some level of authentication. > - P2PSIP 1.0 is not intended for production use; it is a prototype protocol No. It should be a "standard track" protcol, addressed to consumer electronics devices as well as open source softphones. > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is finalized, not before. Ok, let's start from version 0.0 ;-) Enrico From kns10 at cs.columbia.edu Mon Jun 5 10:19:19 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Mon, 5 Jun 2006 10:19:19 -0400 (EDT) Subject: [p2p-sip] I-D ACTION:draft-singh-p2p-sip-00.txt (fwd) Message-ID: Hi, This is our attempt to formalize the external DHT mode for P2P-SIP. Comments appreciated. -- Kundan Singh http://www.cs.columbia.edu/~kns10 ---------- Forwarded message ---------- Date: Thu, 01 Jun 2006 15:50:01 -0400 From: Internet-Drafts at ietf.org To: i-d-announce at ietf.org Subject: I-D ACTION:draft-singh-p2p-sip-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Data format and interface to an external peer-to-peer network for SIP location service Author(s) : K. Singh, H. Schulzrinne Filename : draft-singh-p2p-sip-00.txt Pages : 30 Date : 2006-6-1 This document describes the data format and interface to an external peer-to-peer (P2P) protocol for use as a location service in the Session Initiation Protocol (SIP)-based Internet telephony. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-singh-p2p-sip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-singh-p2p-sip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From bryan at ethernot.org Mon Jun 5 10:29:03 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 5 Jun 2006 10:29:03 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: References: <200606050317.k553GqX5013938@cs.columbia.edu> Message-ID: <8b2769930606050729v1383c3d4v32ffc2b2e7df9691@mail.gmail.com> I would agree, and would add a subtly different objection that a traditional SIP UA will be better able to interact with a P2PSIP endpoint if we have a simple "sip:" or "sips:" (however that debate hashes out). David On 6/5/06, Henning Schulzrinne wrote: > > I'd prefer not to debate the specifics at this point -- if we can > > agree that > > there's some kind of "p2psip:" address type, I think > > that's as > > deep as we need to get agreement on the big picture. > > I think this is a fundamentally bad idea. I shouldn't have to change > my address (and business card) just because I'm changing some low- > level technical detail of how signaling requests are routed. In any > event, just like many web pages are simply listed as > www.something.com (instead of http://www.something.com), I expect > that many business cards and directories will simply contain > alice at something.com. > > It's the role of protocols to make these resolution details > transparent to the user. This isn't terribly difficult in this > particular case. > > Henning > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From spencer at mcsr-labs.org Mon Jun 5 10:30:25 2006 From: spencer at mcsr-labs.org (Spencer Dawkins) Date: Mon, 5 Jun 2006 09:30:25 -0500 Subject: [p2p-sip] What are we doing, question 2 References: <200606050317.k553GqX5013938@cs.columbia.edu><04f301c688a6$bd6c0700$0700a8c0@china.huawei.com> <17540.14372.587136.845291@rautu.tutpro.com> Message-ID: <051f01c688ac$96288c30$0700a8c0@china.huawei.com> > the discussion on sip list seems to indicate the opposite, i.e., it does > not make sense to have both sip and sips. (way off topic for this list, but I believe that what doesn't seem to make sense on the SIP list is having a "secure SIP" that provides no SIPS guarantees beyond what SIP guarantees - but the point I was trying to make was that we have chosen two different schemes when we THOUGHT there was a good reason, ignoring whether we were correct or not. Juha's summary of the current viewpoint on sip/sips matches my understanding. Thankks, Spencer From bk9001 at gmail.com Mon Jun 5 11:19:41 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Mon, 5 Jun 2006 11:19:41 -0400 Subject: [p2p-sip] What are we doing, question 2 References: <200606050317.k553GqX5013938@cs.columbia.edu> Message-ID: <006b01c688b3$7bbc9d80$0200a8c0@Shikky> David: You made many good points, but the idea of "p2psip:" address type is the anti-thesis of the very idea of p2psip. If it uses address other than sip, it is not sip - it can be pip, spip or whatever;-) If it uses a server in the network, then it is not a p2p but something else. If it uses a server to boot, it is not meant for ad-hoc networks. If it is not meant for ad-hoc networks, then someone will ask for asip (a sip of adhoc networks and a new address asip: ;-)) and the list goes on.. Address mapping from one domain to another can easily be incorporated in any protocol design (example, email to sms and vice versa. It is done all the time) . But that is not where most of the problemsof p2p sip are, the problems are in other areas that you have excellently listed in your mail. The another big problem is that, the proposed charter is badly defined with people proposing multiple versions of sip based on different architectures, different type of DHTs, and this and that. There is neither a clarity nor any consensus here. cheers, --bk ----- Original Message ----- From: "David Barrett" To: "'Seaward Hu'" ; Sent: Sunday, June 04, 2006 11:16 PM Subject: Re: [p2p-sip] What are we doing, question 2 > Hi Seaward. > > I'd prefer not to debate the specifics at this point -- if we can agree > that > there's some kind of "p2psip:" address type, I think that's as > deep as we need to get agreement on the big picture. > > Basically, I'm thinking there's some kind of P2PSIP address that can be > printed on a business card, posted on a webpage, sent in an email, and so > on. Somehow you can plug this into your P2PSIP UA, and it magically > figures > out which DHT my UA is registered, then uses it to send me an INVITE. > > I'm less concerned with how this happens than with getting your agreement > on > whether or not you share this goal. This I'll ask: > > 1) Do you agree there should be some address that you can read off my > business card and type into your UA that somehow causes it to locate my UA > and establish a call? > > 2) Do you agree (1) should be accomplished by using a special > 'p2psip:' address type to differentiate it from a normal > 'sip:' address? > > -david > >> -----Original Message----- >> From: Seaward Hu [mailto:hu.xinyu at huawei.com] >> Sent: Sunday, June 04, 2006 7:18 PM >> To: 'David Barrett'; p2p-sip at cs.columbia.edu >> Subject: RE: [p2p-sip] What are we doing, question 2 >> >> Hello David, >> I'm sorry that I don't agree to set the [bootstrap] as a part >> of >> P2P SIP address, below is my options: >> 1.Bootstrap server is used to provide some information about >> existing SN to a new ON, so it will be useless for a ON after it has >> logged >> in a P2P SIP overlay network, why should the ON always tell others this >> information? >> 2.There may be several bootstraps which maintained by >> volunteers >> can be acquired in a DHT , how to select one to fill the address? >> >> > -----Original Message----- >> > From: p2p-sip-bounces at cs.columbia.edu >> > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett >> > Sent: Monday, June 05, 2006 8:17 AM >> > To: p2p-sip at cs.columbia.edu >> > Subject: [p2p-sip] What are we doing, question 2 >> > >> > >> > I'd like to reitereate Cullen's question: what, >> > fundamentally, are we trying to do here? Everything feels >> > very slippery. Is there any consensus on any of the following issues? >> > >> > 1) Does P2PSIP require DNS? >> > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? >> > 3) Does P2PSIP work for 2 devices? >> > 4) Does P2PSIP work for 2B devices? >> > 5) Does P2PSIP require any central servers (other than, >> > potentially, DNS)? >> > 6) Does P2PSIP use a DHT? >> > 7) Does P2PSIP work with non-P2PSIP UAs? >> > 8) Does P2PSIP use modified SIP messages or some new syntax? >> > 9) Does P2PSIP support secure authentication? >> > >> > I don't mean this as a critique, but I don't feel like we're >> > gathering toward consensus on any of these points. Thus >> > perhaps we should choose a new tactic? >> > >> > I like Enrico's quick enumeration of his vision for P2PSIP. >> > I expect were we all to give it a shot, we'd find 2-4 basic >> > variations. Maybe once we have those we can name them in a >> > totally vague way and grapple with the subject from a new perspective. >> > >> > Thus here's my quick-bullet summary of the P2PSIP I'd like to >> > see standardized; I'm eager to hear yours: >> > >> > - P2PSIP 1.0 is an extension to the SIP protocol that enables >> > UAs to connect >> > to and participate in a DHT that performs the basic >> > functionality of a SIP >> > proxy. >> > - Nodes can choose whether to participate in or only query the DHT. >> > - A new SIP address type is created to differentiate between >> > client/server >> > and P2P proxies: p2psip:[@@[]] >> > - is any string; if unspecified it is assumed to be >> > "global". >> > - is the IP:port or domain name of any P2PSIP UA; if left >> > unspecified it is assumed to be any of a well-known >> > collection of public >> > bootstrapping nodes maintained by volunteers. >> > - Resolving a P2PSIP address consists of contacting the >> > bootstrapping node, >> > joining the named DHT, and looking up the IP:port of the username. >> > - Any number of DHTs can exist in parallel on the same network. >> > - P2PSIP 1.0 does not provide any built-in authentication framework. >> > - P2PSIP 1.0 is not intended for production use; it is a >> > prototype protocol >> > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is >> > finalized, not before. >> > >> > I have no idea if this is similar to anyone else's vision, >> > but I'll name this stake in the ground the "decentralized >> > proxy" proposal given that it aims to do no more than >> > decentralize the most basic client/server SIP proxy functions. >> > >> > How would you summarize and name your vision? How does it >> > differ from mine and everyone else's? >> > >> > -david >> > >> > _______________________________________________ >> > 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 ksankar at cisco.com Mon Jun 5 11:43:18 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 08:43:18 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A45859C@xmb-sjc-219.amer.cisco.com> My view of the P2P-SIP world ... > - P2PSIP 1.0 is an extension to the SIP protocol that enables UAs to connect to and participate > in a DHT that performs the basic functionality of a SIP proxy. DHT is not important, but the P2P nature is. "participate in a Peer-to-peer network" is more accurate. DHT is one such mechanism. There could be (and will be) others ... > 1) Does P2PSIP require DNS? May be. As a well known anchor point, DNS is a good choice than any other bootstrap mechanism. One good use is the Bonjour/zeroConf. > - P2PSIP 1.0 does not provide any built-in authentication framework. We should. > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? Yep, definitely. Might not be that easy > 5) Does P2PSIP require any central servers (other than, potentially, DNS)? Nope > 6) Does P2PSIP use a DHT? Yes, but not essential. We are looking for a scalable P2P substrate. > 7) Does P2PSIP work with non-P2PSIP UAs? yep. > 8) Does P2PSIP use modified SIP messages or some new syntax? Nope > 9) Does P2PSIP support secure authentication? Yep > - Nodes can choose whether to participate in or only query the DHT. Too much into DHT. Not needed. > - A new SIP address type is created to differentiate between client/server > and P2P proxies: p2psip:[@@[]] Absolutely not. Why do we need this ? Whether it is a P2P SIP or "normal" SIP should be transparent. > - is the IP:port or domain name of any P2PSIP UA; if left > unspecified it is assumed to be any of a well-known > collection of public bootstrapping nodes maintained by volunteers. Sounds OK. Possibly a DNS based substrate > - Resolving a P2PSIP address consists of contacting the bootstrapping node, > joining the named DHT, and looking up the IP:port of the username. Essentially Yes > - Any number of DHTs can exist in parallel on the same network. Yes > - P2PSIP 1.0 is not intended for production use; it is a prototype protocol Nope > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > finalized, not before. But we can discuss P2PSIP 3.0 while 1.0 is in progress ;o) Cheers > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Sunday, June 04, 2006 5:17 PM > To: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] What are we doing, question 2 > > I'd like to reitereate Cullen's question: what, > fundamentally, are we trying to do here? Everything feels > very slippery. Is there any consensus on any of the following issues? > > 1) Does P2PSIP require DNS? > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > 3) Does P2PSIP work for 2 devices? > 4) Does P2PSIP work for 2B devices? > 5) Does P2PSIP require any central servers (other than, > potentially, DNS)? > 6) Does P2PSIP use a DHT? > 7) Does P2PSIP work with non-P2PSIP UAs? > 8) Does P2PSIP use modified SIP messages or some new syntax? > 9) Does P2PSIP support secure authentication? > > I don't mean this as a critique, but I don't feel like we're > gathering toward consensus on any of these points. Thus > perhaps we should choose a new tactic? > > I like Enrico's quick enumeration of his vision for P2PSIP. > I expect were we all to give it a shot, we'd find 2-4 basic > variations. Maybe once we have those we can name them in a > totally vague way and grapple with the subject from a new perspective. > > Thus here's my quick-bullet summary of the P2PSIP I'd like to > see standardized; I'm eager to hear yours: > > - P2PSIP 1.0 is an extension to the SIP protocol that enables > UAs to connect > to and participate in a DHT that performs the basic > functionality of a SIP > proxy. > - Nodes can choose whether to participate in or only query the DHT. > - A new SIP address type is created to differentiate between > client/server > and P2P proxies: p2psip:[@@[]] > - is any string; if unspecified it is assumed to be > "global". > - is the IP:port or domain name of any P2PSIP UA; if left > unspecified it is assumed to be any of a well-known > collection of public > bootstrapping nodes maintained by volunteers. > - Resolving a P2PSIP address consists of contacting the > bootstrapping node, > joining the named DHT, and looking up the IP:port of the username. > - Any number of DHTs can exist in parallel on the same network. > - P2PSIP 1.0 does not provide any built-in authentication framework. > - P2PSIP 1.0 is not intended for production use; it is a > prototype protocol > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > finalized, not before. > > I have no idea if this is similar to anyone else's vision, > but I'll name this stake in the ground the "decentralized > proxy" proposal given that it aims to do no more than > decentralize the most basic client/server SIP proxy functions. > > How would you summarize and name your vision? How does it > differ from mine and everyone else's? > > -david > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From henry at pulver.com Mon Jun 5 11:46:39 2006 From: henry at pulver.com (Henry Sinnreich) Date: Mon, 5 Jun 2006 10:46:39 -0500 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003b01c68856$f91ead20$6400a8c0@comcast.net> Message-ID: <000601c688b7$3d3e65d0$2800a8c0@DSX400> > My amen for "p2psip:" address scheme!! Banish this thought for the reasons explained by Henning Schulzrinne. Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Peter Pan Sent: Sunday, June 04, 2006 11:18 PM To: David Barrett; 'Seaward Hu'; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 My amen for "p2psip:" address scheme!! It indicates address lookup via DHT instead of via DNS SRV. Peter ----- Original Message ----- From: "David Barrett" To: "'Seaward Hu'" ; Sent: Sunday, June 04, 2006 8:16 PM Subject: Re: [p2p-sip] What are we doing, question 2 > Hi Seaward. > > I'd prefer not to debate the specifics at this point -- if we can agree that > there's some kind of "p2psip:" address type, I think that's as > deep as we need to get agreement on the big picture. > > Basically, I'm thinking there's some kind of P2PSIP address that can be > printed on a business card, posted on a webpage, sent in an email, and so > on. Somehow you can plug this into your P2PSIP UA, and it magically figures > out which DHT my UA is registered, then uses it to send me an INVITE. > > I'm less concerned with how this happens than with getting your agreement on > whether or not you share this goal. This I'll ask: > > 1) Do you agree there should be some address that you can read off my > business card and type into your UA that somehow causes it to locate my UA > and establish a call? > > 2) Do you agree (1) should be accomplished by using a special > 'p2psip:' address type to differentiate it from a normal > 'sip:' address? > > -david > > > -----Original Message----- > > From: Seaward Hu [mailto:hu.xinyu at huawei.com] > > Sent: Sunday, June 04, 2006 7:18 PM > > To: 'David Barrett'; p2p-sip at cs.columbia.edu > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > Hello David, > > I'm sorry that I don't agree to set the [bootstrap] as a part of > > P2P SIP address, below is my options: > > 1.Bootstrap server is used to provide some information about > > existing SN to a new ON, so it will be useless for a ON after it has > > logged > > in a P2P SIP overlay network, why should the ON always tell others this > > information? > > 2.There may be several bootstraps which maintained by volunteers > > can be acquired in a DHT , how to select one to fill the address? > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > > > Sent: Monday, June 05, 2006 8:17 AM > > > To: p2p-sip at cs.columbia.edu > > > Subject: [p2p-sip] What are we doing, question 2 > > > > > > > > > I'd like to reitereate Cullen's question: what, > > > fundamentally, are we trying to do here? Everything feels > > > very slippery. Is there any consensus on any of the following issues? > > > > > > 1) Does P2PSIP require DNS? > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > > 3) Does P2PSIP work for 2 devices? > > > 4) Does P2PSIP work for 2B devices? > > > 5) Does P2PSIP require any central servers (other than, > > > potentially, DNS)? > > > 6) Does P2PSIP use a DHT? > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > > 9) Does P2PSIP support secure authentication? > > > > > > I don't mean this as a critique, but I don't feel like we're > > > gathering toward consensus on any of these points. Thus > > > perhaps we should choose a new tactic? > > > > > > I like Enrico's quick enumeration of his vision for P2PSIP. > > > I expect were we all to give it a shot, we'd find 2-4 basic > > > variations. Maybe once we have those we can name them in a > > > totally vague way and grapple with the subject from a new perspective. > > > > > > Thus here's my quick-bullet summary of the P2PSIP I'd like to > > > see standardized; I'm eager to hear yours: > > > > > > - P2PSIP 1.0 is an extension to the SIP protocol that enables > > > UAs to connect > > > to and participate in a DHT that performs the basic > > > functionality of a SIP > > > proxy. > > > - Nodes can choose whether to participate in or only query the DHT. > > > - A new SIP address type is created to differentiate between > > > client/server > > > and P2P proxies: p2psip:[@@[]] > > > - is any string; if unspecified it is assumed to be > > > "global". > > > - is the IP:port or domain name of any P2PSIP UA; if left > > > unspecified it is assumed to be any of a well-known > > > collection of public > > > bootstrapping nodes maintained by volunteers. > > > - Resolving a P2PSIP address consists of contacting the > > > bootstrapping node, > > > joining the named DHT, and looking up the IP:port of the username. > > > - Any number of DHTs can exist in parallel on the same network. > > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > > - P2PSIP 1.0 is not intended for production use; it is a > > > prototype protocol > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > > finalized, not before. > > > > > > I have no idea if this is similar to anyone else's vision, > > > but I'll name this stake in the ground the "decentralized > > > proxy" proposal given that it aims to do no more than > > > decentralize the most basic client/server SIP proxy functions. > > > > > > How would you summarize and name your vision? How does it > > > differ from mine and everyone else's? > > > > > > -david > > > > > > _______________________________________________ > > > 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 dbarrett at quinthar.com Mon Jun 5 11:57:59 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 08:57:59 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <8b2769930606050729v1383c3d4v32ffc2b2e7df9691@mail.gmail.com> Message-ID: <200606051558.k55Fw8X5009286@cs.columbia.edu> Ok, I'll totally agree that it'd be nice to hide the details of P2PSIP behind a standard "sip:" address (expressed or implied). I just haven't envisioned how to accomplish this in conjunction with the other requirements, and I'm trying to avoid proposing what I can't figure out how to build. The problem I see isn't one of technology, but usability issues caused in the adoption period. Clearly, P2PSIP isn't going to happen overnight. There will be period of years where it is slowly rolled out to SIP UAs. And during this period, I think it's important for a UA to differentiate between invalid SIP addresses, and P2PSIP addresses that it doesn't know how to handle. For example, let's assume I put my P2PSIP address on a business card as "sip:dbarrett at quinthar.com" (or just "dbarrett at quinthar.com" with the "sip:" implied). A P2PSIP-aware UA might first look for a traditional SIP proxy at "quinthar.com" and then, not finding one, use some DHT-based mechanism. I love that idea. But a P2PSIP-unaware UA will just break. It'll say the address is valid and supported, but broken. I don't love this idea. Thus I'm proposing, at least at the start while P2PSIP is getting its legs, we use "p2psip:". A P2PSIP-aware UA will work, and a P2PSIP-unaware UA can clearly say "I don't support this address type". The blame is placed on the UA (where it should be), rather than the address. Maybe in the future, once P2PSIP is more established, UAs would automatically retry all failed "sip:" addresses on some P2PSIP framework, and then the two addresses would converge down the road. But I'm not sure how we can start out converged without just confusing the user and, ultimately, hurting the SIP community as a whole -- P2P and otherwise. Have I missed something? Can you see a way to roll out P2PSIP atop a standard "sip:" address without appearing totally broken throughout the deployment period? -david > -----Original Message----- > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On Behalf Of > David A. Bryan > Sent: Monday, June 05, 2006 7:29 AM > To: Henning Schulzrinne > Cc: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > I would agree, and would add a subtly different objection that a > traditional SIP UA will be better able to interact with a P2PSIP > endpoint if we have a simple "sip:" or "sips:" (however that debate > hashes out). > > David > > On 6/5/06, Henning Schulzrinne wrote: > > > I'd prefer not to debate the specifics at this point -- if we can > > > agree that > > > there's some kind of "p2psip:" address type, I think > > > that's as > > > deep as we need to get agreement on the big picture. > > > > I think this is a fundamentally bad idea. I shouldn't have to change > > my address (and business card) just because I'm changing some low- > > level technical detail of how signaling requests are routed. In any > > event, just like many web pages are simply listed as > > www.something.com (instead of http://www.something.com), I expect > > that many business cards and directories will simply contain > > alice at something.com. > > > > It's the role of protocols to make these resolution details > > transparent to the user. This isn't terribly difficult in this > > particular case. > > > > Henning > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From huang-ming.pan at comcast.net Mon Jun 5 12:01:31 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 5 Jun 2006 09:01:31 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606050019.k550HmX5011803@cs.columbia.edu> <44843A16.6010709@telecomitalia.it> Message-ID: <002601c688b9$50995070$6400a8c0@comcast.net> > > - A new SIP address type is created to differentiate between client/server > > and P2P proxies: p2psip:[@@[]] > > - is any string; if unspecified it is assumed to be "global". > > - is the IP:port or domain name of any P2PSIP UA; if left > > unspecified it is assumed to be any of a well-known collection of public > > bootstrapping nodes maintained by volunteers. > > - Resolving a P2PSIP address consists of contacting the bootstrapping node, > > joining the named DHT, and looking up the IP:port of the username. > > Your solution is not doable in P2PSIP. P2PSIP _is SIP_ in that: > + both P2P and conventional UAs use SIP for communcating (INVITE, > MESSAGE, BYE...). This implies that they should be identifiable by > means of sip: URIs; > + when they are not isolated, P2PSIP domains _must_ be located by > conventional SIP elements using procedures defined in RFC 3263. > Why is P2PSIP restricted to sip/sips? Unless failover (from DHT to DNS, or vice versa) time can be "optimized" to both care user experience (not timeout too slow, eg. 64*T1) and false positive (not timeout too soon), leaving ambiguity in uri scheme seems unnecessary. Or, forked lookup is anticipated? Why should I wear two pants if I live in Taiwan only?? > > - Any number of DHTs can exist in parallel on the same network. > > Sure. Impractical. Wishing for miracle, still. > > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > Not a framework, but possibly some mechanisms for achieving some level > of authentication. Not a problem likely, if link-layer (p2p, not L2) security is included from day one. > > > - P2PSIP 1.0 is not intended for production use; it is a prototype protocol > > No. It should be a "standard track" protcol, addressed to consumer > electronics devices as well as open source softphones. > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is finalized, not before. > > Ok, let's start from version 0.0 ;-) 0.0=A.A (Amateur.Academic)? From huang-ming.pan at comcast.net Mon Jun 5 12:13:05 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 5 Jun 2006 09:13:05 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606050317.k553GqX5013938@cs.columbia.edu><04f301c688a6$bd6c0700$0700a8c0@china.huawei.com><17540.14372.587136.845291@rautu.tutpro.com> <051f01c688ac$96288c30$0700a8c0@china.huawei.com> Message-ID: <004b01c688ba$ed64f930$6400a8c0@comcast.net> ----- Original Message ----- From: "Spencer Dawkins" Sent: Monday, June 05, 2006 7:30 AM Subject: Re: [p2p-sip] What are we doing, question 2 > > the discussion on sip list seems to indicate the opposite, i.e., it does > > not make sense to have both sip and sips. > > (way off topic for this list, but I believe that what doesn't seem to make > sense on the SIP list is having a "secure SIP" that provides no SIPS > guarantees beyond what SIP guarantees - but the point I was trying to make > was that we have chosen two different schemes when we THOUGHT there was a > good reason, ignoring whether we were correct or not. Juha's summary of the > current viewpoint on sip/sips matches my understanding. > > Thankks, > > Spencer > SIPS seems less feasible in P2P SIP than in CS SIP, because TLS can copy the scalability problem seen in real world (almost none uses TLS or even TCP in commercial practices), unless SIPS will be use SSL/TLS over UDP and nodes can learn themselves outside NAT in advance, SIPS uri scheme seems theoretically useful in P2P SIP. From dbarrett at quinthar.com Mon Jun 5 12:15:02 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 09:15:02 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A45859C@xmb-sjc-219.amer.cisco.com> Message-ID: <200606051615.k55GFTX5016638@cs.columbia.edu> Hi Krishna, I agree with most of your points should eventually be covered by P2PSIP, but I disagree they should be part of P2PSIP *1.0*. In other words, are you proposing we can't do *anything* until we accomplish *all* of your requirements? I like the idea of using Bonjour/zeroConf. Same for generalizing for multiple P2P networks, DHT algorithms, mobile IPs, address transparency, etc, etc. But I do not like the idea of holding up the boat until *all* are on board. So what I'm really asking is for more aggressive prioritization. What is the smallest set of requirements that you believe should be in the 1.0 release? What is the absolute smallest set of functionality that can be built and standardized in order to help us learn how to make P2PSIP 2.0? -david > -----Original Message----- > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > Sent: Monday, June 05, 2006 8:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > > > - P2PSIP 1.0 is an extension to the SIP protocol that enables UAs to > connect to and participate > > in a DHT that performs the basic functionality of a SIP proxy. > > DHT is not important, but the P2P nature is. "participate in a > Peer-to-peer network" is more accurate. DHT is one such mechanism. There > could be (and will be) others ... > > > 1) Does P2PSIP require DNS? > > May be. As a well known anchor point, DNS is a good choice than > any other bootstrap mechanism. One good use is the Bonjour/zeroConf. > > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > We should. > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > Yep, definitely. Might not be that easy > > > 5) Does P2PSIP require any central servers (other than, potentially, > DNS)? > > Nope > > > 6) Does P2PSIP use a DHT? > > Yes, but not essential. We are looking for a scalable P2P > substrate. > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > yep. > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > Nope > > > 9) Does P2PSIP support secure authentication? > > Yep > > > - Nodes can choose whether to participate in or only query the DHT. > > Too much into DHT. Not needed. > > > - A new SIP address type is created to differentiate between > client/server > > and P2P proxies: p2psip:[@@[]] > > Absolutely not. Why do we need this ? Whether it is a P2P SIP or > "normal" SIP should be transparent. > > > - is the IP:port or domain name of any P2PSIP UA; if left > > unspecified it is assumed to be any of a well-known > > collection of public bootstrapping nodes maintained by volunteers. > > Sounds OK. Possibly a DNS based substrate > > > - Resolving a P2PSIP address consists of contacting the bootstrapping > node, > > joining the named DHT, and looking up the IP:port of the username. > > Essentially Yes > > > - Any number of DHTs can exist in parallel on the same network. > > Yes > > > - P2PSIP 1.0 is not intended for production use; it is a prototype > protocol > > Nope > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > finalized, not before. > > But we can discuss P2PSIP 3.0 while 1.0 is in progress ;o) > > > Cheers > > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > > Sent: Sunday, June 04, 2006 5:17 PM > > To: p2p-sip at cs.columbia.edu > > Subject: [p2p-sip] What are we doing, question 2 > > > > I'd like to reitereate Cullen's question: what, > > fundamentally, are we trying to do here? Everything feels > > very slippery. Is there any consensus on any of the following issues? > > > > 1) Does P2PSIP require DNS? > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > 3) Does P2PSIP work for 2 devices? > > 4) Does P2PSIP work for 2B devices? > > 5) Does P2PSIP require any central servers (other than, > > potentially, DNS)? > > 6) Does P2PSIP use a DHT? > > 7) Does P2PSIP work with non-P2PSIP UAs? > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > 9) Does P2PSIP support secure authentication? > > > > I don't mean this as a critique, but I don't feel like we're > > gathering toward consensus on any of these points. Thus > > perhaps we should choose a new tactic? > > > > I like Enrico's quick enumeration of his vision for P2PSIP. > > I expect were we all to give it a shot, we'd find 2-4 basic > > variations. Maybe once we have those we can name them in a > > totally vague way and grapple with the subject from a new perspective. > > > > Thus here's my quick-bullet summary of the P2PSIP I'd like to > > see standardized; I'm eager to hear yours: > > > > - P2PSIP 1.0 is an extension to the SIP protocol that enables > > UAs to connect > > to and participate in a DHT that performs the basic > > functionality of a SIP > > proxy. > > - Nodes can choose whether to participate in or only query the DHT. > > - A new SIP address type is created to differentiate between > > client/server > > and P2P proxies: p2psip:[@@[]] > > - is any string; if unspecified it is assumed to be > > "global". > > - is the IP:port or domain name of any P2PSIP UA; if left > > unspecified it is assumed to be any of a well-known > > collection of public > > bootstrapping nodes maintained by volunteers. > > - Resolving a P2PSIP address consists of contacting the > > bootstrapping node, > > joining the named DHT, and looking up the IP:port of the username. > > - Any number of DHTs can exist in parallel on the same network. > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > - P2PSIP 1.0 is not intended for production use; it is a > > prototype protocol > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > finalized, not before. > > > > I have no idea if this is similar to anyone else's vision, > > but I'll name this stake in the ground the "decentralized > > proxy" proposal given that it aims to do no more than > > decentralize the most basic client/server SIP proxy functions. > > > > How would you summarize and name your vision? How does it > > differ from mine and everyone else's? > > > > -david > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From dbarrett at quinthar.com Mon Jun 5 12:15:02 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 09:15:02 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <000001c68865$7e7bb9f0$1a05a40a@china.huawei.com> Message-ID: <200606051616.k55GFpX5016720@cs.columbia.edu> (iGlance uses a central server, btw. Some details at http://www.iglance.com/code.html) > -----Original Message----- > From: Seaward Hu [mailto:hu.xinyu at huawei.com] > Sent: Sunday, June 04, 2006 11:01 PM > To: 'Peter Pan'; 'David Barrett'; p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > I also agree with the address format of "p2psip:", and there > have many things as such Mr.Eunsoo pointed out in his slide need to be > specified, may we pay some attention on that? > > by the way, is the iGlance base on DHT topology? > > > > -----Original Message----- > > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > > Sent: Monday, June 05, 2006 12:18 PM > > To: David Barrett; 'Seaward Hu'; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > My amen for "p2psip:" address scheme!! > > > > It indicates address lookup via DHT instead of via DNS SRV. > > > > Peter > > ----- Original Message ----- > > From: "David Barrett" > > To: "'Seaward Hu'" ; > > Sent: Sunday, June 04, 2006 8:16 PM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > Hi Seaward. > > > > > > I'd prefer not to debate the specifics at this point -- if we can > > > agree > > that > > > there's some kind of "p2psip:" address type, I > > think that's > > > as deep as we need to get agreement on the big picture. > > > > > > Basically, I'm thinking there's some kind of P2PSIP address > > that can > > > be printed on a business card, posted on a webpage, sent in > > an email, > > > and so on. Somehow you can plug this into your P2PSIP UA, and it > > > magically > > figures > > > out which DHT my UA is registered, then uses it to send me > > an INVITE. > > > > > > I'm less concerned with how this happens than with getting your > > > agreement > > on > > > whether or not you share this goal. This I'll ask: > > > > > > 1) Do you agree there should be some address that you can > > read off my > > > business card and type into your UA that somehow causes it > > to locate > > > my UA and establish a call? > > > > > > 2) Do you agree (1) should be accomplished by using a special > > > 'p2psip:' address type to differentiate it from a normal > > > 'sip:' address? > > > > > > -david > > > > > > > -----Original Message----- > > > > From: Seaward Hu [mailto:hu.xinyu at huawei.com] > > > > Sent: Sunday, June 04, 2006 7:18 PM > > > > To: 'David Barrett'; p2p-sip at cs.columbia.edu > > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > > > Hello David, > > > > I'm sorry that I don't agree to set the > > [bootstrap] as a > > > > part > > of > > > > P2P SIP address, below is my options: > > > > 1.Bootstrap server is used to provide some information > > > > about existing SN to a new ON, so it will be useless for > > a ON after > > > > it has logged in a P2P SIP overlay network, why should > > the ON always > > > > tell others this information? > > > > 2.There may be several bootstraps which maintained by > > volunteers > > > > can be acquired in a DHT , how to select one to fill the address? > > > > > > > > > -----Original Message----- > > > > > From: p2p-sip-bounces at cs.columbia.edu > > > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David > > > > > Barrett > > > > > Sent: Monday, June 05, 2006 8:17 AM > > > > > To: p2p-sip at cs.columbia.edu > > > > > Subject: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > > > > I'd like to reitereate Cullen's question: what, > > fundamentally, are > > > > > we trying to do here? Everything feels very slippery. > > Is there > > > > > any consensus on any of the following issues? > > > > > > > > > > 1) Does P2PSIP require DNS? > > > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP > > > > > addresses? > > > > > 3) Does P2PSIP work for 2 devices? > > > > > 4) Does P2PSIP work for 2B devices? > > > > > 5) Does P2PSIP require any central servers (other than, > > > > > potentially, DNS)? > > > > > 6) Does P2PSIP use a DHT? > > > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > > > > 9) Does P2PSIP support secure authentication? > > > > > > > > > > I don't mean this as a critique, but I don't feel like we're > > > > > gathering toward consensus on any of these points. > > Thus perhaps > > > > > we should choose a new tactic? > > > > > > > > > > I like Enrico's quick enumeration of his vision for P2PSIP. I > > > > > expect were we all to give it a shot, we'd find 2-4 basic > > > > > variations. Maybe once we have those we can name them in a > > > > > totally vague way and grapple with the subject from a new > > > > > perspective. > > > > > > > > > > Thus here's my quick-bullet summary of the P2PSIP I'd > > like to see > > > > > standardized; I'm eager to hear yours: > > > > > > > > > > - P2PSIP 1.0 is an extension to the SIP protocol that > > enables UAs > > > > > to connect > > > > > to and participate in a DHT that performs the basic > > > > > functionality of a SIP > > > > > proxy. > > > > > - Nodes can choose whether to participate in or only query the > > > > > DHT. > > > > > - A new SIP address type is created to differentiate between > > > > > client/server > > > > > and P2P proxies: p2psip:[@@[]] > > > > > - is any string; if unspecified it is assumed to be > > > > > "global". > > > > > - is the IP:port or domain name of any > > P2PSIP UA; if left > > > > > unspecified it is assumed to be any of a well-known > > > > > collection of public > > > > > bootstrapping nodes maintained by volunteers. > > > > > - Resolving a P2PSIP address consists of contacting the > > > > > bootstrapping node, > > > > > joining the named DHT, and looking up the IP:port of > > the username. > > > > > - Any number of DHTs can exist in parallel on the same network. > > > > > - P2PSIP 1.0 does not provide any built-in > > authentication framework. > > > > > - P2PSIP 1.0 is not intended for production use; it is a > > > > > prototype protocol > > > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > > > > > finalized, not before. > > > > > > > > > > I have no idea if this is similar to anyone else's vision, but > > > > > I'll name this stake in the ground the "decentralized proxy" > > > > > proposal given that it aims to do no more than decentralize the > > > > > most basic client/server SIP proxy functions. > > > > > > > > > > How would you summarize and name your vision? How does > > it differ > > > > > from mine and everyone else's? > > > > > > > > > > -david > > > > > > > > > > _______________________________________________ > > > > > p2p-sip mailing list > > > > > p2p-sip at cs.columbia.edu > > > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > > > > > > > > > > > > > From dbarrett at quinthar.com Mon Jun 5 12:27:45 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 09:27:45 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <002601c688b9$50995070$6400a8c0@comcast.net> Message-ID: <200606051627.k55GRmX5021212@cs.columbia.edu> > -----Original Message----- > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > > Why is P2PSIP restricted to sip/sips? > > Unless failover (from DHT to DNS, or vice versa) time can be "optimized" > to > both care user experience (not timeout too slow, eg. 64*T1) and false > positive (not timeout too soon), leaving ambiguity in uri scheme seems > unnecessary. > > Or, forked lookup is anticipated? Why should I wear two pants if I live in > Taiwan only?? Forked lookup sounds like a good long term strategy, but a confusing short term strategy. > > > - Any number of DHTs can exist in parallel on the same network. > > > > Sure. > > Impractical. Wishing for miracle, still. I'm not sure it's impractical, though I agree it might not be necessary for 1.0. > > > - P2PSIP 1.0 does not provide any built-in authentication framework. > > > > Not a framework, but possibly some mechanisms for achieving some level > > of authentication. > > Not a problem likely, if link-layer (p2p, not L2) security is included > from > day one. Despite arguments that it's impossible, virtually all of the most widely used protocols successfully added security after 1.0. TCP, HTTP, FTP, RSH, SMTP, POP, IMAP. I'm skeptical that our problem set is so much more challenging that we need to tackle it up front (or that we're so much smarter that we can, or so much dumber that we cannot add it later). > > > - P2PSIP 1.0 is not intended for production use; it is a prototype > protocol > > > > No. It should be a "standard track" protcol, addressed to consumer > > electronics devices as well as open source softphones. > > > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is finalized, not > before. > > > > Ok, let's start from version 0.0 ;-) > > 0.0=A.A (Amateur.Academic)? Whatever the nomenclature, we should have prioritization and protocol versioning at the top of our mind. Otherwise we continue trying to be all things to all people right off the bat. -david From ksankar at cisco.com Mon Jun 5 13:03:20 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 10:03:20 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A4585FA@xmb-sjc-219.amer.cisco.com> David, You have a valid point making p2p-sip explicit for all than implicit in the UAs who understand it. a) I mulled it over and do not see any other way, as a 1.0 requirement. i.e. we do need a p2p-sip protocol designator somewhere to make it explicit. But not necessarily in one's vcard. b) We could make the client responsible for trying the generic and then p2p:. c) Going back to putting p2psip in one's vcard, what does "p2psip" in one's SIP address signify anyway ? Signifies that one will be part of a p2psip as and when available ? d) Isn't p2psip situational ? i.e. when one is at home, may be, one will be part of the p2psip provided by the service provider or even the home network; but when one is at work, one becomes part of a server based larger sip substrate. What about an emergency worker who moves between different p2psip and sip networks ? What about a mobile worker who wanders from Starbucks network to airport network to .. All might have different p2psip mechanisms or even a combination of p2psip and server based sip. May be I got it all wrong (mice crunching cats are the norm of the day than galloping stallions) - very possible ... Cheers > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Monday, June 05, 2006 8:58 AM > To: 'David A. Bryan'; 'Henning Schulzrinne' > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > Ok, I'll totally agree that it'd be nice to hide the details > of P2PSIP behind a standard "sip:" address (expressed or > implied). I just haven't envisioned how to accomplish this > in conjunction with the other requirements, and I'm trying to > avoid proposing what I can't figure out how to build. > > The problem I see isn't one of technology, but usability > issues caused in the adoption period. Clearly, P2PSIP isn't > going to happen overnight. > There will be period of years where it is slowly rolled out > to SIP UAs. And during this period, I think it's important > for a UA to differentiate between invalid SIP addresses, and > P2PSIP addresses that it doesn't know how to handle. > > For example, let's assume I put my P2PSIP address on a > business card as "sip:dbarrett at quinthar.com" (or just > "dbarrett at quinthar.com" with the "sip:" > implied). A P2PSIP-aware UA might first look for a > traditional SIP proxy at "quinthar.com" and then, not finding > one, use some DHT-based mechanism. I love that idea. > > But a P2PSIP-unaware UA will just break. It'll say the > address is valid and supported, but broken. I don't love this idea. > > Thus I'm proposing, at least at the start while P2PSIP is > getting its legs, we use "p2psip:". A > P2PSIP-aware UA will work, and a P2PSIP-unaware UA can > clearly say "I don't support this address type". The blame > is placed on the UA (where it should be), rather than the address. > > Maybe in the future, once P2PSIP is more established, UAs > would automatically retry all failed "sip:" > addresses on some P2PSIP framework, and then the two > addresses would converge down the road. > > But I'm not sure how we can start out converged without just > confusing the user and, ultimately, hurting the SIP community > as a whole -- P2P and otherwise. > > Have I missed something? Can you see a way to roll out > P2PSIP atop a standard "sip:" address without > appearing totally broken throughout the deployment period? > > -david > > > -----Original Message----- > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > Behalf Of > > David A. Bryan > > Sent: Monday, June 05, 2006 7:29 AM > > To: Henning Schulzrinne > > Cc: David Barrett; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > I would agree, and would add a subtly different objection that a > > traditional SIP UA will be better able to interact with a P2PSIP > > endpoint if we have a simple "sip:" or "sips:" (however that debate > > hashes out). > > > > David > > > > On 6/5/06, Henning Schulzrinne wrote: > > > > I'd prefer not to debate the specifics at this point -- > if we can > > > > agree that there's some kind of "p2psip:" > address type, > > > > I think that's as deep as we need to get agreement on the big > > > > picture. > > > > > > I think this is a fundamentally bad idea. I shouldn't > have to change > > > my address (and business card) just because I'm changing > some low- > > > level technical detail of how signaling requests are > routed. In any > > > event, just like many web pages are simply listed as > > > www.something.com (instead of http://www.something.com), I expect > > > that many business cards and directories will simply contain > > > alice at something.com. > > > > > > It's the role of protocols to make these resolution details > > > transparent to the user. This isn't terribly difficult in this > > > particular case. > > > > > > Henning > > > _______________________________________________ > > > 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 bryan at ethernot.org Mon Jun 5 13:08:47 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 5 Jun 2006 13:08:47 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A4585FA@xmb-sjc-219.amer.cisco.com> References: <9FA16888AD1BF64ABCE6C2532CCEB98A4585FA@xmb-sjc-219.amer.cisco.com> Message-ID: <8b2769930606051008qb04e1fbk6a5a4350f1600679@mail.gmail.com> If we have a p2psip: address, what does a non-P2P SIP endpoint do with it? On the otherhand, a regular sip: address can go from a UA to a proxy that is more likely to be able to do something useful (forward it to a p2p domain)? See the draft Enrico and I did (draft-marocco-sipping-p2p-scenarios-00.html) for details. We can use maybe use something else in the messages -- a URI param or a header perhaps -- to distinguish P2P from regular SIP where needed, but I think we should ensure that a URI is as backward compliant as possible. --David Bryan On 6/5/06, Krishna Sankar (ksankar) wrote: > David, > > You have a valid point making p2p-sip explicit for all than > implicit in the UAs who understand it. > a) I mulled it over and do not see any other way, as a 1.0 > requirement. i.e. we do need a p2p-sip protocol designator somewhere to > make it explicit. But not necessarily in one's vcard. > b) We could make the client responsible for trying the > generic and then p2p:. > c) Going back to putting p2psip in one's vcard, what does > "p2psip" in one's SIP address signify anyway ? Signifies that one will > be part of a p2psip as and when available ? > d) Isn't p2psip situational ? i.e. when one is at home, may > be, one will be part of the p2psip provided by the service provider or > even the home network; but when one is at work, one becomes part of a > server based larger sip substrate. > What about an emergency worker who moves between > different p2psip and sip networks ? > > What about a mobile worker who wanders from Starbucks > network to airport network to .. All might have different p2psip > mechanisms or even a combination of p2psip and server based sip. > > May be I got it all wrong (mice crunching cats are the norm of > the day than galloping stallions) - very possible ... > Cheers > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > > Sent: Monday, June 05, 2006 8:58 AM > > To: 'David A. Bryan'; 'Henning Schulzrinne' > > Cc: p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > Ok, I'll totally agree that it'd be nice to hide the details > > of P2PSIP behind a standard "sip:" address (expressed or > > implied). I just haven't envisioned how to accomplish this > > in conjunction with the other requirements, and I'm trying to > > avoid proposing what I can't figure out how to build. > > > > The problem I see isn't one of technology, but usability > > issues caused in the adoption period. Clearly, P2PSIP isn't > > going to happen overnight. > > There will be period of years where it is slowly rolled out > > to SIP UAs. And during this period, I think it's important > > for a UA to differentiate between invalid SIP addresses, and > > P2PSIP addresses that it doesn't know how to handle. > > > > For example, let's assume I put my P2PSIP address on a > > business card as "sip:dbarrett at quinthar.com" (or just > > "dbarrett at quinthar.com" with the "sip:" > > implied). A P2PSIP-aware UA might first look for a > > traditional SIP proxy at "quinthar.com" and then, not finding > > one, use some DHT-based mechanism. I love that idea. > > > > But a P2PSIP-unaware UA will just break. It'll say the > > address is valid and supported, but broken. I don't love this idea. > > > > Thus I'm proposing, at least at the start while P2PSIP is > > getting its legs, we use "p2psip:". A > > P2PSIP-aware UA will work, and a P2PSIP-unaware UA can > > clearly say "I don't support this address type". The blame > > is placed on the UA (where it should be), rather than the address. > > > > Maybe in the future, once P2PSIP is more established, UAs > > would automatically retry all failed "sip:" > > addresses on some P2PSIP framework, and then the two > > addresses would converge down the road. > > > > But I'm not sure how we can start out converged without just > > confusing the user and, ultimately, hurting the SIP community > > as a whole -- P2P and otherwise. > > > > Have I missed something? Can you see a way to roll out > > P2PSIP atop a standard "sip:" address without > > appearing totally broken throughout the deployment period? > > > > -david > > > > > -----Original Message----- > > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > Behalf Of > > > David A. Bryan > > > Sent: Monday, June 05, 2006 7:29 AM > > > To: Henning Schulzrinne > > > Cc: David Barrett; p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > I would agree, and would add a subtly different objection that a > > > traditional SIP UA will be better able to interact with a P2PSIP > > > endpoint if we have a simple "sip:" or "sips:" (however that debate > > > hashes out). > > > > > > David > > > > > > On 6/5/06, Henning Schulzrinne wrote: > > > > > I'd prefer not to debate the specifics at this point -- > > if we can > > > > > agree that there's some kind of "p2psip:" > > address type, > > > > > I think that's as deep as we need to get agreement on the big > > > > > picture. > > > > > > > > I think this is a fundamentally bad idea. I shouldn't > > have to change > > > > my address (and business card) just because I'm changing > > some low- > > > > level technical detail of how signaling requests are > > routed. In any > > > > event, just like many web pages are simply listed as > > > > www.something.com (instead of http://www.something.com), I expect > > > > that many business cards and directories will simply contain > > > > alice at something.com. > > > > > > > > It's the role of protocols to make these resolution details > > > > transparent to the user. This isn't terribly difficult in this > > > > particular case. > > > > > > > > Henning > > > > _______________________________________________ > > > > 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 ksankar at cisco.com Mon Jun 5 13:15:22 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 10:15:22 -0700 Subject: [p2p-sip] What are we doing, question 2 - take 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A45860B@xmb-sjc-219.amer.cisco.com> David, Good points. I totally missed the significance of "1.0" in your message - lack of sleep and not enough caffeine (or green tea as the case may be ;o)) Take 2 - short form priority list for 1.0 which I am passionate about: 1. We need some form of bootstrap - may be two common ones like DNS and zConf to start with. 2. No central server, should operate with non-P2PSIP UAs 3. Yes, let us fix DHT (kicking and screaming ;o() But no DHT-specific primitives 4. While we do not need any authentication framework, we do need authentication (What about privacy or do we assume the p2p substrate is appropriately trusted to do this job ?) 5. We will have the p2psip:[@@[]] semantics either implicit (i.e. by protocols - multicast for bootstrap or configuration) or explicit in the address. After re-reading your e-mails, I do think an addressing scheme like this is a good idea, but could be a technology artifact that is buried in a finger table or somewhere like that and might not be visible outside. The @dhtname will change as one moves around. 6. 1.0 production use 7. Any number can co-exist and one can be part of many (?) 8. And yes, p2psip provides the control path function of connectivity in a server-less ad-hoc world Thanks for the discussion and the prod to focus ... Cheers > -----Original Message----- > From: David Barrett [mailto:dbarrett at quinthar.com] > Sent: Monday, June 05, 2006 9:15 AM > To: Krishna Sankar (ksankar); p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > Hi Krishna, I agree with most of your points should > eventually be covered by P2PSIP, but I disagree they should > be part of P2PSIP *1.0*. > > In other words, are you proposing we can't do *anything* > until we accomplish > *all* of your requirements? > > I like the idea of using Bonjour/zeroConf. Same for > generalizing for multiple P2P networks, DHT algorithms, > mobile IPs, address transparency, etc, etc. But I do not > like the idea of holding up the boat until *all* are on board. > > So what I'm really asking is for more aggressive > prioritization. What is the smallest set of requirements > that you believe should be in the 1.0 release? What is the > absolute smallest set of functionality that can be built and > standardized in order to help us learn how to make P2PSIP 2.0? > > -david > > > -----Original Message----- > > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > Sent: Monday, June 05, 2006 8:43 AM > > To: David Barrett; p2p-sip at cs.columbia.edu > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > My view of the P2P-SIP world ... > > > > > - P2PSIP 1.0 is an extension to the SIP protocol that > enables UAs to > > connect to and participate > > > in a DHT that performs the basic functionality of a SIP proxy. > > > > DHT is not important, but the P2P nature is. "participate in a > > Peer-to-peer network" is more accurate. DHT is one such mechanism. > > There could be (and will be) others ... > > > > > 1) Does P2PSIP require DNS? > > > > May be. As a well known anchor point, DNS is a good > choice than any > > other bootstrap mechanism. One good use is the Bonjour/zeroConf. > > > > > - P2PSIP 1.0 does not provide any built-in authentication > framework. > > > > We should. > > > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP > addresses? > > > > Yep, definitely. Might not be that easy > > > 5) Does P2PSIP require any central servers (other than, > potentially, > > DNS)? > > > > Nope > > > > > 6) Does P2PSIP use a DHT? > > > > Yes, but not essential. We are looking for a scalable > P2P substrate. > > > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > > > yep. > > > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > > > Nope > > > > > 9) Does P2PSIP support secure authentication? > > > > Yep > > > > > - Nodes can choose whether to participate in or only > query the DHT. > > > > Too much into DHT. Not needed. > > > > > - A new SIP address type is created to differentiate between > > client/server > > > and P2P proxies: p2psip:[@@[]] > > > > Absolutely not. Why do we need this ? Whether it is a > P2P SIP or > > "normal" SIP should be transparent. > > > > > - is the IP:port or domain name of any P2PSIP UA; if > > > left unspecified it is assumed to be any of a well-known > collection > > > of public bootstrapping nodes maintained by volunteers. > > > > Sounds OK. Possibly a DNS based substrate > > > - Resolving a P2PSIP address consists of contacting the > > > bootstrapping > > node, > > > joining the named DHT, and looking up the IP:port of > the username. > > > > Essentially Yes > > > > > - Any number of DHTs can exist in parallel on the same network. > > > > Yes > > > > > - P2PSIP 1.0 is not intended for production use; it is a prototype > > protocol > > > > Nope > > > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > finalized, not > > > before. > > > > But we can discuss P2PSIP 3.0 while 1.0 is in progress ;o) > > > > Cheers > > > > > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > David Barrett > > > Sent: Sunday, June 04, 2006 5:17 PM > > > To: p2p-sip at cs.columbia.edu > > > Subject: [p2p-sip] What are we doing, question 2 > > > > > > I'd like to reitereate Cullen's question: what, > fundamentally, are > > > we trying to do here? Everything feels very slippery. > Is there any > > > consensus on any of the following issues? > > > > > > 1) Does P2PSIP require DNS? > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP > addresses? > > > 3) Does P2PSIP work for 2 devices? > > > 4) Does P2PSIP work for 2B devices? > > > 5) Does P2PSIP require any central servers (other than, > potentially, > > > DNS)? > > > 6) Does P2PSIP use a DHT? > > > 7) Does P2PSIP work with non-P2PSIP UAs? > > > 8) Does P2PSIP use modified SIP messages or some new syntax? > > > 9) Does P2PSIP support secure authentication? > > > > > > I don't mean this as a critique, but I don't feel like we're > > > gathering toward consensus on any of these points. Thus > perhaps we > > > should choose a new tactic? > > > > > > I like Enrico's quick enumeration of his vision for P2PSIP. > > > I expect were we all to give it a shot, we'd find 2-4 basic > > > variations. Maybe once we have those we can name them in > a totally > > > vague way and grapple with the subject from a new perspective. > > > > > > Thus here's my quick-bullet summary of the P2PSIP I'd like to see > > > standardized; I'm eager to hear yours: > > > > > > - P2PSIP 1.0 is an extension to the SIP protocol that > enables UAs to > > > connect > > > to and participate in a DHT that performs the basic > functionality > > > of a SIP > > > proxy. > > > - Nodes can choose whether to participate in or only > query the DHT. > > > - A new SIP address type is created to differentiate between > > > client/server > > > and P2P proxies: p2psip:[@@[]] > > > - is any string; if unspecified it is assumed to be > > > "global". > > > - is the IP:port or domain name of any P2PSIP > UA; if left > > > unspecified it is assumed to be any of a well-known > collection of > > > public > > > bootstrapping nodes maintained by volunteers. > > > - Resolving a P2PSIP address consists of contacting the > > > bootstrapping node, > > > joining the named DHT, and looking up the IP:port of > the username. > > > - Any number of DHTs can exist in parallel on the same network. > > > - P2PSIP 1.0 does not provide any built-in authentication > framework. > > > - P2PSIP 1.0 is not intended for production use; it is a > prototype > > > protocol > > > - P2PSIP 2.0 will begin discussion once P2PSIP 1.0 is > finalized, not > > > before. > > > > > > I have no idea if this is similar to anyone else's > vision, but I'll > > > name this stake in the ground the "decentralized proxy" proposal > > > given that it aims to do no more than decentralize the most basic > > > client/server SIP proxy functions. > > > > > > How would you summarize and name your vision? How does it differ > > > from mine and everyone else's? > > > > > > -david > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > From ksankar at cisco.com Mon Jun 5 13:21:40 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 10:21:40 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A458614@xmb-sjc-219.amer.cisco.com> Agreed. If we, in-principle, see the need for the p2psip:[@@[]], we can make it as harmless as possible - a set of header elements or a set of URI parameter is an excellent choice. I like header element better - something like : Additional-Format:P2P P2P-DHTName:,,... P2P-BootStrap:,... Cheers > -----Original Message----- > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > Behalf Of David A. Bryan > Sent: Monday, June 05, 2006 10:09 AM > To: Krishna Sankar (ksankar) > Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > If we have a p2psip: address, what does a non-P2P SIP > endpoint do with it? On the otherhand, a regular sip: address > can go from a UA to a proxy that is more likely to be able to > do something useful (forward it to a p2p domain)? See the > draft Enrico and I did > (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > We can use maybe use something else in the messages -- a URI > param or a header perhaps -- to distinguish P2P from regular > SIP where needed, but I think we should ensure that a URI is > as backward compliant as possible. > > --David Bryan > > On 6/5/06, Krishna Sankar (ksankar) wrote: > > David, > > > > You have a valid point making p2p-sip explicit for all than > > implicit in the UAs who understand it. > > a) I mulled it over and do not see any other > way, as a 1.0 > > requirement. i.e. we do need a p2p-sip protocol designator > somewhere > > to make it explicit. But not necessarily in one's vcard. > > b) We could make the client responsible for trying the > > generic and then p2p:. > > c) Going back to putting p2psip in one's > vcard, what does > > "p2psip" in one's SIP address signify anyway ? Signifies > that one will > > be part of a p2psip as and when available ? > > d) Isn't p2psip situational ? i.e. when one is > at home, may > > be, one will be part of the p2psip provided by the service > provider or > > even the home network; but when one is at work, one becomes > part of a > > server based larger sip substrate. > > What about an emergency worker who moves between > > different p2psip and sip networks ? > > > > What about a mobile worker who wanders from > Starbucks > > network to airport network to .. All might have different p2psip > > mechanisms or even a combination of p2psip and server based sip. > > > > May be I got it all wrong (mice crunching cats are > the norm of > > the day than galloping stallions) - very possible ... > > Cheers > > > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > David Barrett > > > Sent: Monday, June 05, 2006 8:58 AM > > > To: 'David A. Bryan'; 'Henning Schulzrinne' > > > Cc: p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > Ok, I'll totally agree that it'd be nice to hide the details of > > > P2PSIP behind a standard "sip:" address (expressed or > implied). I > > > just haven't envisioned how to accomplish this in > conjunction with > > > the other requirements, and I'm trying to avoid proposing what I > > > can't figure out how to build. > > > > > > The problem I see isn't one of technology, but usability issues > > > caused in the adoption period. Clearly, P2PSIP isn't going to > > > happen overnight. > > > There will be period of years where it is slowly rolled > out to SIP > > > UAs. And during this period, I think it's important for a UA to > > > differentiate between invalid SIP addresses, and P2PSIP addresses > > > that it doesn't know how to handle. > > > > > > For example, let's assume I put my P2PSIP address on a > business card > > > as "sip:dbarrett at quinthar.com" (or just > "dbarrett at quinthar.com" with > > > the "sip:" > > > implied). A P2PSIP-aware UA might first look for a > traditional SIP > > > proxy at "quinthar.com" and then, not finding one, use some > > > DHT-based mechanism. I love that idea. > > > > > > But a P2PSIP-unaware UA will just break. It'll say the > address is > > > valid and supported, but broken. I don't love this idea. > > > > > > Thus I'm proposing, at least at the start while P2PSIP is getting > > > its legs, we use "p2psip:". A P2PSIP-aware UA > will work, > > > and a P2PSIP-unaware UA can clearly say "I don't support this > > > address type". The blame is placed on the UA (where it > should be), > > > rather than the address. > > > > > > Maybe in the future, once P2PSIP is more established, UAs would > > > automatically retry all failed "sip:" > > > addresses on some P2PSIP framework, and then the two > addresses would > > > converge down the road. > > > > > > But I'm not sure how we can start out converged without just > > > confusing the user and, ultimately, hurting the SIP > community as a > > > whole -- P2P and otherwise. > > > > > > Have I missed something? Can you see a way to roll out > P2PSIP atop > > > a standard "sip:" address without appearing totally > > > broken throughout the deployment period? > > > > > > -david > > > > > > > -----Original Message----- > > > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > > Behalf Of > > > > David A. Bryan > > > > Sent: Monday, June 05, 2006 7:29 AM > > > > To: Henning Schulzrinne > > > > Cc: David Barrett; p2p-sip at cs.columbia.edu > > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > I would agree, and would add a subtly different > objection that a > > > > traditional SIP UA will be better able to interact with > a P2PSIP > > > > endpoint if we have a simple "sip:" or "sips:" (however that > > > > debate hashes out). > > > > > > > > David > > > > > > > > On 6/5/06, Henning Schulzrinne wrote: > > > > > > I'd prefer not to debate the specifics at this point -- > > > if we can > > > > > > agree that there's some kind of "p2psip:" > > > address type, > > > > > > I think that's as deep as we need to get agreement > on the big > > > > > > picture. > > > > > > > > > > I think this is a fundamentally bad idea. I shouldn't > > > have to change > > > > > my address (and business card) just because I'm changing > > > some low- > > > > > level technical detail of how signaling requests are > > > routed. In any > > > > > event, just like many web pages are simply listed as > > > > > www.something.com (instead of http://www.something.com), I > > > > > expect that many business cards and directories will simply > > > > > contain alice at something.com. > > > > > > > > > > It's the role of protocols to make these resolution details > > > > > transparent to the user. This isn't terribly > difficult in this > > > > > particular case. > > > > > > > > > > Henning > > > > > _______________________________________________ > > > > > 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 fwmiller at cornfed.com Mon Jun 5 14:20:21 2006 From: fwmiller at cornfed.com (fwmiller@cornfed.com) Date: Mon, 5 Jun 2006 13:20:21 -0500 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <200606051820.k55IKLx05639@smapp01.siteprotect.com> While the arguments for some explicitness may be enticing, I for one would argue for as complete transparency as possbile. For example, we should strive have no modifications to session establishment messaging if possible. I would propose the model be that we just rely on the ability of a UAC to talk directly to a UAS and have the registrations and presence information associated with a UA "trick" the UAC into talking directly to the UAS. What I mean is, you register your UA as normally as possible (i.e. minimal changes to the REGISTER messages and then as new headers only so they are transparent). To find another UA, you query using existing presence mechanisms (i.e. SUB/NOT with PIDF and/or XCAP again with minimal changes to these messages as possible). The actual session establishment is then no different than existing SIP, right down to the UAS challenging the UAC for authentication if the UAS thinks that is necessary. In this approach, the P2P infrastructure just looks like a SIP registrar and presence servers to the UAs which maximizes both backward compatibility and flexibility in the implementation of the P2P infrastructure. FM ------------------------------------------------ On Mon, 5 Jun 2006 10:03:20 -0700, "Krishna Sankar \(ksankar\)" wrote: > David, > > You have a valid point making p2p-sip explicit for all than > implicit in the UAs who understand it. > a) I mulled it over and do not see any other way, as a 1.0 > requirement. i.e. we do need a p2p-sip protocol designator somewhere to > make it explicit. But not necessarily in one's vcard. > b) We could make the client responsible for trying the > generic and then p2p:. > c) Going back to putting p2psip in one's vcard, what does > "p2psip" in one's SIP address signify anyway ? Signifies that one will > be part of a p2psip as and when available ? > d) Isn't p2psip situational ? i.e. when one is at home, may > be, one will be part of the p2psip provided by the service provider or > even the home network; but when one is at work, one becomes part of a > server based larger sip substrate. > What about an emergency worker who moves between > different p2psip and sip networks ? > > What about a mobile worker who wanders from Starbucks > network to airport network to .. All might have different p2psip > mechanisms or even a combination of p2psip and server based sip. > > May be I got it all wrong (mice crunching cats are the norm of > the day than galloping stallions) - very possible ... > Cheers > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > > Sent: Monday, June 05, 2006 8:58 AM > > To: 'David A. Bryan'; 'Henning Schulzrinne' > > Cc: p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > Ok, I'll totally agree that it'd be nice to hide the details > > of P2PSIP behind a standard "sip:" address (expressed or > > implied). I just haven't envisioned how to accomplish this > > in conjunction with the other requirements, and I'm trying to > > avoid proposing what I can't figure out how to build. > > > > The problem I see isn't one of technology, but usability > > issues caused in the adoption period. Clearly, P2PSIP isn't > > going to happen overnight. > > There will be period of years where it is slowly rolled out > > to SIP UAs. And during this period, I think it's important > > for a UA to differentiate between invalid SIP addresses, and > > P2PSIP addresses that it doesn't know how to handle. > > > > For example, let's assume I put my P2PSIP address on a > > business card as "sip:dbarrett at quinthar.com" (or just > > "dbarrett at quinthar.com" with the "sip:" > > implied). A P2PSIP-aware UA might first look for a > > traditional SIP proxy at "quinthar.com" and then, not finding > > one, use some DHT-based mechanism. I love that idea. > > > > But a P2PSIP-unaware UA will just break. It'll say the > > address is valid and supported, but broken. I don't love this idea. > > > > Thus I'm proposing, at least at the start while P2PSIP is > > getting its legs, we use "p2psip:". A > > P2PSIP-aware UA will work, and a P2PSIP-unaware UA can > > clearly say "I don't support this address type". The blame > > is placed on the UA (where it should be), rather than the address. > > > > Maybe in the future, once P2PSIP is more established, UAs > > would automatically retry all failed "sip:" > > addresses on some P2PSIP framework, and then the two > > addresses would converge down the road. > > > > But I'm not sure how we can start out converged without just > > confusing the user and, ultimately, hurting the SIP community > > as a whole -- P2P and otherwise. > > > > Have I missed something? Can you see a way to roll out > > P2PSIP atop a standard "sip:" address without > > appearing totally broken throughout the deployment period? > > > > -david > > > > > -----Original Message----- > > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > Behalf Of > > > David A. Bryan > > > Sent: Monday, June 05, 2006 7:29 AM > > > To: Henning Schulzrinne > > > Cc: David Barrett; p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > I would agree, and would add a subtly different objection that a > > > traditional SIP UA will be better able to interact with a P2PSIP > > > endpoint if we have a simple "sip:" or "sips:" (however that debate > > > hashes out). > > > > > > David > > > > > > On 6/5/06, Henning Schulzrinne wrote: > > > > > I'd prefer not to debate the specifics at this point -- > > if we can > > > > > agree that there's some kind of "p2psip:" > > address type, > > > > > I think that's as deep as we need to get agreement on the big > > > > > picture. > > > > > > > > I think this is a fundamentally bad idea. I shouldn't > > have to change > > > > my address (and business card) just because I'm changing > > some low- > > > > level technical detail of how signaling requests are > > routed. In any > > > > event, just like many web pages are simply listed as > > > > www.something.com (instead of http://www.something.com), I expect > > > > that many business cards and directories will simply contain > > > > alice at something.com. > > > > > > > > It's the role of protocols to make these resolution details > > > > transparent to the user. This isn't terribly difficult in this > > > > particular case. > > > > > > > > Henning > > > > _______________________________________________ > > > > 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 > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From RADHIKA.R.ROY at saic.com Mon Jun 5 14:39:13 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Mon, 5 Jun 2006 14:39:13 -0400 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <62D92A9A02BCC845B202323D49A48426230E05@0591-ITS-EXMP02.us.saic.com> KS: To support p2pSIP for mobile nodes (if not mobile devices per se) should not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done the most difficult works in this p2p networking environment: Network Routing and QoS support. So, it will be rather easy to support the p2pSIP application protocol that will ride over the network layer MANET protocol. In fact, we will be working cooperating with them to complete our work: p2pSIP Application Layer to the MANET Network Layer. Best regards, Radhika R. Roy -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar (ksankar) Sent: Monday, June 05, 2006 11:43 AM To: David Barrett; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 My view of the P2P-SIP world ... > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? Yep, definitely. Might not be that easy From ksankar at cisco.com Mon Jun 5 14:46:17 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 11:46:17 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFCE7@xmb-sjc-219.amer.cisco.com> Agreed and is a good idea. I am a fan of MANET and was thinking of the same thing. Count me in, to work on this. But, we should specify this crisply (i.e. we will use MANET mechanisms as developed by IETF WG - DYMO et al) so that there is no ambiguity and divergence later. Cheers > -----Original Message----- > From: RADHIKA.R.ROY at saic.com [mailto:RADHIKA.R.ROY at saic.com] > Sent: Monday, June 05, 2006 11:39 AM > To: Krishna Sankar (ksankar) > Cc: p2p-sip at cs.columbia.edu; David Barrett > Subject: RE: [p2p-sip] What are we doing, question 2 > > KS: > > To support p2pSIP for mobile nodes (if not mobile devices per > se) should not be difficult. IETF Mobile Ad Hoc Network > (MANET) WG has already done the most difficult works in this > p2p networking environment: Network Routing and QoS support. > > So, it will be rather easy to support the p2pSIP application > protocol that will ride over the network layer MANET protocol. > > In fact, we will be working cooperating with them to complete > our work: > p2pSIP Application Layer to the MANET Network Layer. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > (ksankar) > Sent: Monday, June 05, 2006 11:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP > addresses? > > Yep, definitely. Might not be that easy > From mike_robnson at yahoo.com Mon Jun 5 17:39:40 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Mon, 5 Jun 2006 14:39:40 -0700 (PDT) Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <62D92A9A02BCC845B202323D49A48426230E05@0591-ITS-EXMP02.us.saic.com> Message-ID: <20060605213940.74124.qmail@web38510.mail.mud.yahoo.com> Radhika Roy wrote: >>In fact, we will be working cooperating with them to complete our work: >> p2pSIP Application Layer to the MANET Network Layer. What is that you refer to "our work"? Whose work are you talking? Did IETF assign you a spokesman for MANET? Could you please update us who authorized to speak on behalf of MANET group? By the way, ad-hoc networks have nothing to do with p2p since p2p can run on fixed infrastructure and ad-hoc networks need not use p2p for applications. Did it occur to you that one can run client server applications even when network may be based on ad-hoc network routing protocol. Supporting mobility in p2p nodes is quite difficult contrary to what you say in your typical hand waving style (since you would need to do reinsert your mobile nodes in a DHT, reconfigure DHT, and update resource information at all DHT nodes) I hope you would try to understand the issues with DHT and mobility before you resume your periodic vacuous comments in support of p2p sip (which almost always are devoid of any technical input whatsoever). o mike "Roy, Radhika R." wrote: KS: To support p2pSIP for mobile nodes (if not mobile devices per se) should not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done the most difficult works in this p2p networking environment: Network Routing and QoS support. So, it will be rather easy to support the p2pSIP application protocol that will ride over the network layer MANET protocol. In fact, we will be working cooperating with them to complete our work: p2pSIP Application Layer to the MANET Network Layer. Best regards, Radhika R. Roy -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar (ksankar) Sent: Monday, June 05, 2006 11:43 AM To: David Barrett; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 My view of the P2P-SIP world ... > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? Yep, definitely. Might not be that easy _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060605/341b0bd2/attachment-0001.html From bk9001 at gmail.com Mon Jun 5 17:50:34 2006 From: bk9001 at gmail.com (Brijesh Kumar) Date: Mon, 5 Jun 2006 17:50:34 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <62D92A9A02BCC845B202323D49A48426230E05@0591-ITS-EXMP02.us.saic.com> References: <62D92A9A02BCC845B202323D49A48426230E05@0591-ITS-EXMP02.us.saic.com> Message-ID: <95cb5bd20606051450h4f7dd1ak26a1d9eccb77e11e@mail.gmail.com> On 6/5/06, Roy, Radhika R. wrote: > > KS: > > To support p2pSIP for mobile nodes (if not mobile devices per se) should > not be difficult. > I beg to differ with above assessment. Actually, a change in the IP address would result in the change in a node's identity. Also, a number of DHT configuraion algorithms (specially hierarchical organization) try to optimize overlay organization on the basis of a node's geographical location with respect to certain reference points. That has major implications on a DHT's operation since it may require DHT reconfiguration as well as affect where a node will be placed in the overlay. I haven't seen many papers that have analyzed large scale networks for the effect of node identity change due to node mobility in P2P networks so it is not clear to me why would you say that it is not "difficult". --bk IETF Mobile Ad Hoc Network (MANET) WG has already done > the most difficult works in this p2p networking environment: Network > Routing and QoS support. > > So, it will be rather easy to support the p2pSIP application protocol > that will ride over the network layer MANET protocol. > > In fact, we will be working cooperating with them to complete our work: > p2pSIP Application Layer to the MANET Network Layer. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > (ksankar) > Sent: Monday, June 05, 2006 11:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > Yep, definitely. Might not be that easy > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060605/7041d1f5/attachment.html From dbarrett at quinthar.com Mon Jun 5 18:32:10 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 15:32:10 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A458614@xmb-sjc-219.amer.cisco.com> Message-ID: <200606052236.k55MWfX5018358@cs.columbia.edu> Again, I love the idea of having a single "sip:" address that "just works" for both CS and P2P SIP. Please help me understand your proposal better. Will I be able to print my combined CS/P2P SIP address on a business card, hand it to you, and have you type it into your SIP UA and get an expected result (a valid connection, if it's P2PSIP aware, or a message saying "unsupported address type" if not)? If so, what might that address look like? I've proposed your business card might say: sip:@ Or p2psip:[@] [1] If instead we only use the first format, how does a UA figure out which DHT the address is registered with, and how does it connect to that DHT? I can imagine URI attributes: sip:@[?dht=] And I think this is a great solution. But I don't understand how a human would input "header elements" to a UA. Am I misunderstanding the proposal? -david [1] I've proposed is [@], and that it's optional (defaulting to some global DHT if unspecified). But the precise syntax is unimportant. What is important is that the address contain whatever information is necessary to connect to a given DHT. > -----Original Message----- > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > Sent: Monday, June 05, 2006 10:22 AM > To: David A. Bryan > Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > Agreed. If we, in-principle, see the need for the > p2psip:[@@[]], we can make it as harmless > as possible - a set of header elements or a set of URI parameter is an > excellent choice. > > I like header element better - something like : > Additional-Format:P2P > P2P-DHTName:,,... > P2P-BootStrap:,... > > Cheers > > > > -----Original Message----- > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > Behalf Of David A. Bryan > > Sent: Monday, June 05, 2006 10:09 AM > > To: Krishna Sankar (ksankar) > > Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > If we have a p2psip: address, what does a non-P2P SIP > > endpoint do with it? On the otherhand, a regular sip: address > > can go from a UA to a proxy that is more likely to be able to > > do something useful (forward it to a p2p domain)? See the > > draft Enrico and I did > > (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > > > We can use maybe use something else in the messages -- a URI > > param or a header perhaps -- to distinguish P2P from regular > > SIP where needed, but I think we should ensure that a URI is > > as backward compliant as possible. > > > > --David Bryan > > > > On 6/5/06, Krishna Sankar (ksankar) wrote: > > > David, > > > > > > You have a valid point making p2p-sip explicit for all than > > > implicit in the UAs who understand it. > > > a) I mulled it over and do not see any other > > way, as a 1.0 > > > requirement. i.e. we do need a p2p-sip protocol designator > > somewhere > > > to make it explicit. But not necessarily in one's vcard. > > > b) We could make the client responsible for trying the > > > generic and then p2p:. > > > c) Going back to putting p2psip in one's > > vcard, what does > > > "p2psip" in one's SIP address signify anyway ? Signifies > > that one will > > > be part of a p2psip as and when available ? > > > d) Isn't p2psip situational ? i.e. when one is > > at home, may > > > be, one will be part of the p2psip provided by the service > > provider or > > > even the home network; but when one is at work, one becomes > > part of a > > > server based larger sip substrate. > > > What about an emergency worker who moves between > > > different p2psip and sip networks ? > > > > > > What about a mobile worker who wanders from > > Starbucks > > > network to airport network to .. All might have different p2psip > > > mechanisms or even a combination of p2psip and server based sip. > > > > > > May be I got it all wrong (mice crunching cats are > > the norm of > > > the day than galloping stallions) - very possible ... > > > Cheers > > > > > > > > > > -----Original Message----- > > > > From: p2p-sip-bounces at cs.columbia.edu > > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > > David Barrett > > > > Sent: Monday, June 05, 2006 8:58 AM > > > > To: 'David A. Bryan'; 'Henning Schulzrinne' > > > > Cc: p2p-sip at cs.columbia.edu > > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > Ok, I'll totally agree that it'd be nice to hide the details of > > > > P2PSIP behind a standard "sip:" address (expressed or > > implied). I > > > > just haven't envisioned how to accomplish this in > > conjunction with > > > > the other requirements, and I'm trying to avoid proposing what I > > > > can't figure out how to build. > > > > > > > > The problem I see isn't one of technology, but usability issues > > > > caused in the adoption period. Clearly, P2PSIP isn't going to > > > > happen overnight. > > > > There will be period of years where it is slowly rolled > > out to SIP > > > > UAs. And during this period, I think it's important for a UA to > > > > differentiate between invalid SIP addresses, and P2PSIP addresses > > > > that it doesn't know how to handle. > > > > > > > > For example, let's assume I put my P2PSIP address on a > > business card > > > > as "sip:dbarrett at quinthar.com" (or just > > "dbarrett at quinthar.com" with > > > > the "sip:" > > > > implied). A P2PSIP-aware UA might first look for a > > traditional SIP > > > > proxy at "quinthar.com" and then, not finding one, use some > > > > DHT-based mechanism. I love that idea. > > > > > > > > But a P2PSIP-unaware UA will just break. It'll say the > > address is > > > > valid and supported, but broken. I don't love this idea. > > > > > > > > Thus I'm proposing, at least at the start while P2PSIP is getting > > > > its legs, we use "p2psip:". A P2PSIP-aware UA > > will work, > > > > and a P2PSIP-unaware UA can clearly say "I don't support this > > > > address type". The blame is placed on the UA (where it > > should be), > > > > rather than the address. > > > > > > > > Maybe in the future, once P2PSIP is more established, UAs would > > > > automatically retry all failed "sip:" > > > > addresses on some P2PSIP framework, and then the two > > addresses would > > > > converge down the road. > > > > > > > > But I'm not sure how we can start out converged without just > > > > confusing the user and, ultimately, hurting the SIP > > community as a > > > > whole -- P2P and otherwise. > > > > > > > > Have I missed something? Can you see a way to roll out > > P2PSIP atop > > > > a standard "sip:" address without appearing totally > > > > broken throughout the deployment period? > > > > > > > > -david > > > > > > > > > -----Original Message----- > > > > > From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > > > Behalf Of > > > > > David A. Bryan > > > > > Sent: Monday, June 05, 2006 7:29 AM > > > > > To: Henning Schulzrinne > > > > > Cc: David Barrett; p2p-sip at cs.columbia.edu > > > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > I would agree, and would add a subtly different > > objection that a > > > > > traditional SIP UA will be better able to interact with > > a P2PSIP > > > > > endpoint if we have a simple "sip:" or "sips:" (however that > > > > > debate hashes out). > > > > > > > > > > David > > > > > > > > > > On 6/5/06, Henning Schulzrinne wrote: > > > > > > > I'd prefer not to debate the specifics at this point -- > > > > if we can > > > > > > > agree that there's some kind of "p2psip:" > > > > address type, > > > > > > > I think that's as deep as we need to get agreement > > on the big > > > > > > > picture. > > > > > > > > > > > > I think this is a fundamentally bad idea. I shouldn't > > > > have to change > > > > > > my address (and business card) just because I'm changing > > > > some low- > > > > > > level technical detail of how signaling requests are > > > > routed. In any > > > > > > event, just like many web pages are simply listed as > > > > > > www.something.com (instead of http://www.something.com), I > > > > > > expect that many business cards and directories will simply > > > > > > contain alice at something.com. > > > > > > > > > > > > It's the role of protocols to make these resolution details > > > > > > transparent to the user. This isn't terribly > > difficult in this > > > > > > particular case. > > > > > > > > > > > > Henning > > > > > > _______________________________________________ > > > > > > 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 eunsoo at research.panasonic.com Mon Jun 5 19:01:08 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 05 Jun 2006 19:01:08 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606052236.k55MWfX5018358@cs.columbia.edu> References: <200606052236.k55MWfX5018358@cs.columbia.edu> Message-ID: <4484B7B4.8000809@research.panasonic.com> The domainname should be able to lead to the proper DHT. If the domain is your local domain, it is done. If the domain is a remote domain, DNS is used to find the remote domain's proxy that is participating in the DHT of the domain and the INVITE message is sent to the proxy. This approach makes it transparent to the user whether the underling location lookup is based on a central server (C/S SIP) or a DHT within each domain (P2PSIP). Thanks. Eunsoo David Barrett wrote: > Again, I love the idea of having a single "sip:" address that "just works" > for both CS and P2P SIP. Please help me understand your proposal better. > > Will I be able to print my combined CS/P2P SIP address on a business card, > hand it to you, and have you type it into your SIP UA and get an expected > result (a valid connection, if it's P2PSIP aware, or a message saying > "unsupported address type" if not)? If so, what might that address look > like? > > I've proposed your business card might say: > > sip:@ > > Or > > p2psip:[@] [1] > > If instead we only use the first format, how does a UA figure out which DHT > the address is registered with, and how does it connect to that DHT? I can > imagine URI attributes: > > sip:@[?dht=] > > And I think this is a great solution. But I don't understand how a human > would input "header elements" to a UA. Am I misunderstanding the proposal? > > -david > > [1] I've proposed is [@], and that it's > optional (defaulting to some global DHT if unspecified). But the precise > syntax is unimportant. What is important is that the address contain > whatever information is necessary to connect to a given DHT. > >> -----Original Message----- >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] >> Sent: Monday, June 05, 2006 10:22 AM >> To: David A. Bryan >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >> Subject: RE: [p2p-sip] What are we doing, question 2 >> >> Agreed. If we, in-principle, see the need for the >> p2psip:[@@[]], we can make it as harmless >> as possible - a set of header elements or a set of URI parameter is an >> excellent choice. >> >> I like header element better - something like : >> Additional-Format:P2P >> P2P-DHTName:,,... >> P2P-BootStrap:,... >> >> Cheers >> >> >>> -----Original Message----- >>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>> Behalf Of David A. Bryan >>> Sent: Monday, June 05, 2006 10:09 AM >>> To: Krishna Sankar (ksankar) >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >>> Subject: Re: [p2p-sip] What are we doing, question 2 >>> >>> If we have a p2psip: address, what does a non-P2P SIP >>> endpoint do with it? On the otherhand, a regular sip: address >>> can go from a UA to a proxy that is more likely to be able to >>> do something useful (forward it to a p2p domain)? See the >>> draft Enrico and I did >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. >>> >>> We can use maybe use something else in the messages -- a URI >>> param or a header perhaps -- to distinguish P2P from regular >>> SIP where needed, but I think we should ensure that a URI is >>> as backward compliant as possible. >>> >>> --David Bryan >>> >>> On 6/5/06, Krishna Sankar (ksankar) wrote: >>>> David, >>>> >>>> You have a valid point making p2p-sip explicit for all than >>>> implicit in the UAs who understand it. >>>> a) I mulled it over and do not see any other >>> way, as a 1.0 >>>> requirement. i.e. we do need a p2p-sip protocol designator >>> somewhere >>>> to make it explicit. But not necessarily in one's vcard. >>>> b) We could make the client responsible for trying the >>>> generic and then p2p:. >>>> c) Going back to putting p2psip in one's >>> vcard, what does >>>> "p2psip" in one's SIP address signify anyway ? Signifies >>> that one will >>>> be part of a p2psip as and when available ? >>>> d) Isn't p2psip situational ? i.e. when one is >>> at home, may >>>> be, one will be part of the p2psip provided by the service >>> provider or >>>> even the home network; but when one is at work, one becomes >>> part of a >>>> server based larger sip substrate. >>>> What about an emergency worker who moves between >>>> different p2psip and sip networks ? >>>> >>>> What about a mobile worker who wanders from >>> Starbucks >>>> network to airport network to .. All might have different p2psip >>>> mechanisms or even a combination of p2psip and server based sip. >>>> >>>> May be I got it all wrong (mice crunching cats are >>> the norm of >>>> the day than galloping stallions) - very possible ... >>>> Cheers >>>> >>>> >>>>> -----Original Message----- >>>>> From: p2p-sip-bounces at cs.columbia.edu >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of >>> David Barrett >>>>> Sent: Monday, June 05, 2006 8:58 AM >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' >>>>> Cc: p2p-sip at cs.columbia.edu >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>> >>>>> Ok, I'll totally agree that it'd be nice to hide the details of >>>>> P2PSIP behind a standard "sip:" address (expressed or >>> implied). I >>>>> just haven't envisioned how to accomplish this in >>> conjunction with >>>>> the other requirements, and I'm trying to avoid proposing what I >>>>> can't figure out how to build. >>>>> >>>>> The problem I see isn't one of technology, but usability issues >>>>> caused in the adoption period. Clearly, P2PSIP isn't going to >>>>> happen overnight. >>>>> There will be period of years where it is slowly rolled >>> out to SIP >>>>> UAs. And during this period, I think it's important for a UA to >>>>> differentiate between invalid SIP addresses, and P2PSIP addresses >>>>> that it doesn't know how to handle. >>>>> >>>>> For example, let's assume I put my P2PSIP address on a >>> business card >>>>> as "sip:dbarrett at quinthar.com" (or just >>> "dbarrett at quinthar.com" with >>>>> the "sip:" >>>>> implied). A P2PSIP-aware UA might first look for a >>> traditional SIP >>>>> proxy at "quinthar.com" and then, not finding one, use some >>>>> DHT-based mechanism. I love that idea. >>>>> >>>>> But a P2PSIP-unaware UA will just break. It'll say the >>> address is >>>>> valid and supported, but broken. I don't love this idea. >>>>> >>>>> Thus I'm proposing, at least at the start while P2PSIP is getting >>>>> its legs, we use "p2psip:". A P2PSIP-aware UA >>> will work, >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this >>>>> address type". The blame is placed on the UA (where it >>> should be), >>>>> rather than the address. >>>>> >>>>> Maybe in the future, once P2PSIP is more established, UAs would >>>>> automatically retry all failed "sip:" >>>>> addresses on some P2PSIP framework, and then the two >>> addresses would >>>>> converge down the road. >>>>> >>>>> But I'm not sure how we can start out converged without just >>>>> confusing the user and, ultimately, hurting the SIP >>> community as a >>>>> whole -- P2P and otherwise. >>>>> >>>>> Have I missed something? Can you see a way to roll out >>> P2PSIP atop >>>>> a standard "sip:" address without appearing totally >>>>> broken throughout the deployment period? >>>>> >>>>> -david >>>>> >>>>>> -----Original Message----- >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>>>> Behalf Of >>>>>> David A. Bryan >>>>>> Sent: Monday, June 05, 2006 7:29 AM >>>>>> To: Henning Schulzrinne >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>> >>>>>> I would agree, and would add a subtly different >>> objection that a >>>>>> traditional SIP UA will be better able to interact with >>> a P2PSIP >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that >>>>>> debate hashes out). >>>>>> >>>>>> David >>>>>> >>>>>> On 6/5/06, Henning Schulzrinne wrote: >>>>>>>> I'd prefer not to debate the specifics at this point -- >>>>> if we can >>>>>>>> agree that there's some kind of "p2psip:" >>>>> address type, >>>>>>>> I think that's as deep as we need to get agreement >>> on the big >>>>>>>> picture. >>>>>>> I think this is a fundamentally bad idea. I shouldn't >>>>> have to change >>>>>>> my address (and business card) just because I'm changing >>>>> some low- >>>>>>> level technical detail of how signaling requests are >>>>> routed. In any >>>>>>> event, just like many web pages are simply listed as >>>>>>> www.something.com (instead of http://www.something.com), I >>>>>>> expect that many business cards and directories will simply >>>>>>> contain alice at something.com. >>>>>>> >>>>>>> It's the role of protocols to make these resolution details >>>>>>> transparent to the user. This isn't terribly >>> difficult in this >>>>>>> particular case. >>>>>>> >>>>>>> Henning >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From eunsoo at research.panasonic.com Mon Jun 5 19:14:40 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 05 Jun 2006 19:14:40 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <20060605213940.74124.qmail@web38510.mail.mud.yahoo.com> References: <20060605213940.74124.qmail@web38510.mail.mud.yahoo.com> Message-ID: <4484BAE0.7010603@research.panasonic.com> As long as the IP address of a node does not change, nothing special needs to be done for DHT. In the MANET framework, the IP address of a mobile node does not change. If a mobile deivce is connected to the global Internet and Mobile IP is supported, nothing special needs to be done for the mobile node participating in the DHT, either. If the IP address of a mobile node changes, that's a different story. We can put such mobile devices as ordinary nodes (not participating in DHT) if the P2P network contain both fixed and mobile devices. In my understanding, no one represents any IETF working group or any other organization in the mailing list unless she/he claims to do so explicitly. I don't see anyone claiming to represent MANET or any other WG during the discussion. Thanks. Eunsoo Mike Robinson wrote: > Radhika Roy wrote: > >>> In fact, we will be working cooperating with them to complete our work: >>> p2pSIP Application Layer to the MANET Network Layer. > > What is that you refer to "our work"? Whose work are you talking? Did IETF assign you a spokesman for MANET? > > Could you please update us who authorized to speak on behalf of MANET group? > > By the way, ad-hoc networks have nothing to do with p2p since p2p can run on fixed infrastructure and ad-hoc networks need not use p2p for applications. Did it occur to you that one can run client server applications even when network may be based on ad-hoc network routing protocol. Supporting mobility in p2p nodes is quite difficult contrary to what you say in your typical hand waving style (since you would need to do reinsert your mobile nodes in a DHT, reconfigure DHT, and update resource information at all DHT nodes) > > I hope you would try to understand the issues with DHT and mobility before you resume your periodic vacuous comments in support of p2p sip (which almost always are devoid of any technical input whatsoever). > > > o mike > > > "Roy, Radhika R." wrote: KS: > > To support p2pSIP for mobile nodes (if not mobile devices per se) should > not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done > the most difficult works in this p2p networking environment: Network > Routing and QoS support. > > So, it will be rather easy to support the p2pSIP application protocol > that will ride over the network layer MANET protocol. > > In fact, we will be working cooperating with them to complete our work: > p2pSIP Application Layer to the MANET Network Layer. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > (ksankar) > Sent: Monday, June 05, 2006 11:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > >> 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > Yep, definitely. Might not be that easy > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Mon Jun 5 19:20:07 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 5 Jun 2006 16:20:07 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <20060605213940.74124.qmail@web38510.mail.mud.yahoo.com> Message-ID: <00c901c688f6$966ff5d0$7f0010ac@pi2000> Won't mobility be taken care transparently (w/o ip change) by routers supporting 802.11f, rfc 3344 and related standards? IP change sounds chaotic (if not catastrophic) to DHT. Are MANET and IP mobility mutual exclusive? Peter ----- Original Message ----- From: Mike Robinson To: Roy, Radhika R. ; Krishna Sankar (ksankar) Cc: p2p-sip at cs.columbia.edu Sent: Monday, June 05, 2006 2:39 PM Subject: Re: [p2p-sip] What are we doing, question 2 Radhika Roy wrote: >>In fact, we will be working cooperating with them to complete our work: >> p2pSIP Application Layer to the MANET Network Layer. What is that you refer to "our work"? Whose work are you talking? Did IETF assign you a spokesman for MANET? Could you please update us who authorized to speak on behalf of MANET group? By the way, ad-hoc networks have nothing to do with p2p since p2p can run on fixed infrastructure and ad-hoc networks need not use p2p for applications. Did it occur to you that one can run client server applications even when network may be based on ad-hoc network routing protocol. Supporting mobility in p2p nodes is quite difficult contrary to what you say in your typical hand waving style (since you would need to do reinsert your mobile nodes in a DHT, reconfigure DHT, and update resource information at all DHT nodes) I hope you would try to understand the issues with DHT and mobility before you resume your periodic vacuous comments in support of p2p sip (which almost always are devoid of any technical input whatsoever). o mike "Roy, Radhika R." wrote: KS: To support p2pSIP for mobile nodes (if not mobile devices per se) should not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done the most difficult works in this p2p networking environment: Network Routing and QoS support. So, it will be rather easy to support the p2pSIP application protocol that will ride over the network layer MANET protocol. In fact, we will be working cooperating with them to complete our work: p2pSIP Application Layer to the MANET Network Layer. Best regards, Radhika R. Roy -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar (ksankar) Sent: Monday, June 05, 2006 11:43 AM To: David Barrett; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 My view of the P2P-SIP world ... > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? Yep, definitely. Might not be that easy _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. From huang-ming.pan at comcast.net Mon Jun 5 19:31:20 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 5 Jun 2006 16:31:20 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606052236.k55MWfX5018358@cs.columbia.edu> <4484B7B4.8000809@research.panasonic.com> Message-ID: <00ce01c688f8$27361300$7f0010ac@pi2000> ----- Original Message ----- From: "Eunsoo Shim" To: "David Barrett" Cc: ; "'David A. Bryan'" Sent: Monday, June 05, 2006 4:01 PM Subject: Re: [p2p-sip] What are we doing, question 2 > The domainname should be able to lead to the proper DHT. > If the domain is your local domain, it is done. > If the domain is a remote domain, DNS is used to find the remote > domain's proxy that is participating in the DHT of the domain and the > INVITE message is sent to the proxy. what if the remote domain is also p2p, ie. proxyless?? > > This approach makes it transparent to the user whether the underling > location lookup is based on a central server (C/S SIP) or a DHT within > each domain (P2PSIP). > > Thanks. From dbarrett at quinthar.com Mon Jun 5 20:10:00 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 17:10:00 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <4484B7B4.8000809@research.panasonic.com> Message-ID: <200606060010.k560ARX5023100@cs.columbia.edu> Ah, thanks, I think that makes sense. Correct me if I misunderstand, but are you're proposing that every DHT have at least one persistent node that does two tasks: 1) Helps P2PSIP-aware UAs join the DHT (ie, bootstrap) 2) Handles INVITE requests from P2PSIP-unaware UAs Once you're a member of the DHT, then you needn't talk with DHT proxy node ever again. And if you can't or don't want to use the DHT, just send a normal INVITE to the DHT proxy and it'll return as if it's a standard CS proxy. Is this right? If so, I think I like it. One problem is it means we're not totally decentralized, because every DHT needs a persistent bootstrapping server. (Though this neatly allows for any number of DHTs to exist in parallel, and assuming "sip:dbarrett at 192.168.0.1" is a valid address, then we can operate in environments without DNS.) Pure decentralization could be hacked into this with some kind of "pseudodomain" like "sip:dbarrett at quinthar.dht", and the UA might do (for example) an IP multicast to find other nodes participating in the "quinthar" DHT. Clearly that would fail miserably for a P2PSIP-unaware UA, but that strikes me as acceptable. Anyway, am I understanding your proposal correctly? -david > -----Original Message----- > From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > Sent: Monday, June 05, 2006 4:01 PM > To: David Barrett > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > The domainname should be able to lead to the proper DHT. > If the domain is your local domain, it is done. > If the domain is a remote domain, DNS is used to find the remote > domain's proxy that is participating in the DHT of the domain and the > INVITE message is sent to the proxy. > > This approach makes it transparent to the user whether the underling > location lookup is based on a central server (C/S SIP) or a DHT within > each domain (P2PSIP). > > Thanks. > > Eunsoo > > > David Barrett wrote: > > Again, I love the idea of having a single "sip:" address that "just > works" > > for both CS and P2P SIP. Please help me understand your proposal > better. > > > > Will I be able to print my combined CS/P2P SIP address on a business > card, > > hand it to you, and have you type it into your SIP UA and get an > expected > > result (a valid connection, if it's P2PSIP aware, or a message saying > > "unsupported address type" if not)? If so, what might that address look > > like? > > > > I've proposed your business card might say: > > > > sip:@ > > > > Or > > > > p2psip:[@] [1] > > > > If instead we only use the first format, how does a UA figure out which > DHT > > the address is registered with, and how does it connect to that DHT? I > can > > imagine URI attributes: > > > > sip:@[?dht=] > > > > And I think this is a great solution. But I don't understand how a > human > > would input "header elements" to a UA. Am I misunderstanding the > proposal? > > > > -david > > > > [1] I've proposed is [@], and that it's > > optional (defaulting to some global DHT if unspecified). But the > precise > > syntax is unimportant. What is important is that the address contain > > whatever information is necessary to connect to a given DHT. > > > >> -----Original Message----- > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > >> Sent: Monday, June 05, 2006 10:22 AM > >> To: David A. Bryan > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > >> Subject: RE: [p2p-sip] What are we doing, question 2 > >> > >> Agreed. If we, in-principle, see the need for the > >> p2psip:[@@[]], we can make it as harmless > >> as possible - a set of header elements or a set of URI parameter is an > >> excellent choice. > >> > >> I like header element better - something like : > >> Additional-Format:P2P > >> P2P-DHTName:,,... > >> P2P-BootStrap:,... > >> > >> Cheers > >> > >> > >>> -----Original Message----- > >>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > >>> Behalf Of David A. Bryan > >>> Sent: Monday, June 05, 2006 10:09 AM > >>> To: Krishna Sankar (ksankar) > >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>> > >>> If we have a p2psip: address, what does a non-P2P SIP > >>> endpoint do with it? On the otherhand, a regular sip: address > >>> can go from a UA to a proxy that is more likely to be able to > >>> do something useful (forward it to a p2p domain)? See the > >>> draft Enrico and I did > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > >>> > >>> We can use maybe use something else in the messages -- a URI > >>> param or a header perhaps -- to distinguish P2P from regular > >>> SIP where needed, but I think we should ensure that a URI is > >>> as backward compliant as possible. > >>> > >>> --David Bryan > >>> > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > >>>> David, > >>>> > >>>> You have a valid point making p2p-sip explicit for all than > >>>> implicit in the UAs who understand it. > >>>> a) I mulled it over and do not see any other > >>> way, as a 1.0 > >>>> requirement. i.e. we do need a p2p-sip protocol designator > >>> somewhere > >>>> to make it explicit. But not necessarily in one's vcard. > >>>> b) We could make the client responsible for trying the > >>>> generic and then p2p:. > >>>> c) Going back to putting p2psip in one's > >>> vcard, what does > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > >>> that one will > >>>> be part of a p2psip as and when available ? > >>>> d) Isn't p2psip situational ? i.e. when one is > >>> at home, may > >>>> be, one will be part of the p2psip provided by the service > >>> provider or > >>>> even the home network; but when one is at work, one becomes > >>> part of a > >>>> server based larger sip substrate. > >>>> What about an emergency worker who moves between > >>>> different p2psip and sip networks ? > >>>> > >>>> What about a mobile worker who wanders from > >>> Starbucks > >>>> network to airport network to .. All might have different p2psip > >>>> mechanisms or even a combination of p2psip and server based sip. > >>>> > >>>> May be I got it all wrong (mice crunching cats are > >>> the norm of > >>>> the day than galloping stallions) - very possible ... > >>>> Cheers > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: p2p-sip-bounces at cs.columbia.edu > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > >>> David Barrett > >>>>> Sent: Monday, June 05, 2006 8:58 AM > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > >>>>> Cc: p2p-sip at cs.columbia.edu > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>>>> > >>>>> Ok, I'll totally agree that it'd be nice to hide the details of > >>>>> P2PSIP behind a standard "sip:" address (expressed or > >>> implied). I > >>>>> just haven't envisioned how to accomplish this in > >>> conjunction with > >>>>> the other requirements, and I'm trying to avoid proposing what I > >>>>> can't figure out how to build. > >>>>> > >>>>> The problem I see isn't one of technology, but usability issues > >>>>> caused in the adoption period. Clearly, P2PSIP isn't going to > >>>>> happen overnight. > >>>>> There will be period of years where it is slowly rolled > >>> out to SIP > >>>>> UAs. And during this period, I think it's important for a UA to > >>>>> differentiate between invalid SIP addresses, and P2PSIP addresses > >>>>> that it doesn't know how to handle. > >>>>> > >>>>> For example, let's assume I put my P2PSIP address on a > >>> business card > >>>>> as "sip:dbarrett at quinthar.com" (or just > >>> "dbarrett at quinthar.com" with > >>>>> the "sip:" > >>>>> implied). A P2PSIP-aware UA might first look for a > >>> traditional SIP > >>>>> proxy at "quinthar.com" and then, not finding one, use some > >>>>> DHT-based mechanism. I love that idea. > >>>>> > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > >>> address is > >>>>> valid and supported, but broken. I don't love this idea. > >>>>> > >>>>> Thus I'm proposing, at least at the start while P2PSIP is getting > >>>>> its legs, we use "p2psip:". A P2PSIP-aware UA > >>> will work, > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this > >>>>> address type". The blame is placed on the UA (where it > >>> should be), > >>>>> rather than the address. > >>>>> > >>>>> Maybe in the future, once P2PSIP is more established, UAs would > >>>>> automatically retry all failed "sip:" > >>>>> addresses on some P2PSIP framework, and then the two > >>> addresses would > >>>>> converge down the road. > >>>>> > >>>>> But I'm not sure how we can start out converged without just > >>>>> confusing the user and, ultimately, hurting the SIP > >>> community as a > >>>>> whole -- P2P and otherwise. > >>>>> > >>>>> Have I missed something? Can you see a way to roll out > >>> P2PSIP atop > >>>>> a standard "sip:" address without appearing totally > >>>>> broken throughout the deployment period? > >>>>> > >>>>> -david > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > >>>>> Behalf Of > >>>>>> David A. Bryan > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > >>>>>> To: Henning Schulzrinne > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>>>>> > >>>>>> I would agree, and would add a subtly different > >>> objection that a > >>>>>> traditional SIP UA will be better able to interact with > >>> a P2PSIP > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that > >>>>>> debate hashes out). > >>>>>> > >>>>>> David > >>>>>> > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > >>>>>>>> I'd prefer not to debate the specifics at this point -- > >>>>> if we can > >>>>>>>> agree that there's some kind of "p2psip:" > >>>>> address type, > >>>>>>>> I think that's as deep as we need to get agreement > >>> on the big > >>>>>>>> picture. > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > >>>>> have to change > >>>>>>> my address (and business card) just because I'm changing > >>>>> some low- > >>>>>>> level technical detail of how signaling requests are > >>>>> routed. In any > >>>>>>> event, just like many web pages are simply listed as > >>>>>>> www.something.com (instead of http://www.something.com), I > >>>>>>> expect that many business cards and directories will simply > >>>>>>> contain alice at something.com. > >>>>>>> > >>>>>>> It's the role of protocols to make these resolution details > >>>>>>> transparent to the user. This isn't terribly > >>> difficult in this > >>>>>>> particular case. > >>>>>>> > >>>>>>> Henning > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From fluffy at cisco.com Mon Jun 5 20:36:09 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 5 Jun 2006 17:36:09 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606052236.k55MWfX5018358@cs.columbia.edu> References: <200606052236.k55MWfX5018358@cs.columbia.edu> Message-ID: <7B8DCFEC-A86A-45A3-9FEB-DCCE4944D3D4@cisco.com> Some of the proposal so for have come up with ways to make sip: addresses work and make things interoperable with more traditional sip. Clearly having interoperate would be a nice property if possible. However, I am still lost on what we are trying to accomplish, much less what the solutions is or if it needs a different URL. On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > Again, I love the idea of having a single "sip:" address that "just > works" > for both CS and P2P SIP. Please help me understand your proposal > better. > > Will I be able to print my combined CS/P2P SIP address on a > business card, > hand it to you, and have you type it into your SIP UA and get an > expected > result (a valid connection, if it's P2PSIP aware, or a message saying > "unsupported address type" if not)? If so, what might that address > look > like? > > I've proposed your business card might say: > > sip:@ > > Or > > p2psip:[@] [1] > > If instead we only use the first format, how does a UA figure out > which DHT > the address is registered with, and how does it connect to that > DHT? I can > imagine URI attributes: > > sip:@[?dht=] > > And I think this is a great solution. But I don't understand how a > human > would input "header elements" to a UA. Am I misunderstanding the > proposal? > > -david > > [1] I've proposed is [@], and that it's > optional (defaulting to some global DHT if unspecified). But the > precise > syntax is unimportant. What is important is that the address contain > whatever information is necessary to connect to a given DHT. > >> -----Original Message----- >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] >> Sent: Monday, June 05, 2006 10:22 AM >> To: David A. Bryan >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >> Subject: RE: [p2p-sip] What are we doing, question 2 >> >> Agreed. If we, in-principle, see the need for the >> p2psip:[@@[]], we can make it as >> harmless >> as possible - a set of header elements or a set of URI parameter >> is an >> excellent choice. >> >> I like header element better - something like : >> Additional-Format:P2P >> P2P-DHTName:,,... >> P2P-BootStrap:,... >> >> Cheers >> >> >>> -----Original Message----- >>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>> Behalf Of David A. Bryan >>> Sent: Monday, June 05, 2006 10:09 AM >>> To: Krishna Sankar (ksankar) >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >>> Subject: Re: [p2p-sip] What are we doing, question 2 >>> >>> If we have a p2psip: address, what does a non-P2P SIP >>> endpoint do with it? On the otherhand, a regular sip: address >>> can go from a UA to a proxy that is more likely to be able to >>> do something useful (forward it to a p2p domain)? See the >>> draft Enrico and I did >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. >>> >>> We can use maybe use something else in the messages -- a URI >>> param or a header perhaps -- to distinguish P2P from regular >>> SIP where needed, but I think we should ensure that a URI is >>> as backward compliant as possible. >>> >>> --David Bryan >>> >>> On 6/5/06, Krishna Sankar (ksankar) wrote: >>>> David, >>>> >>>> You have a valid point making p2p-sip explicit for all than >>>> implicit in the UAs who understand it. >>>> a) I mulled it over and do not see any other >>> way, as a 1.0 >>>> requirement. i.e. we do need a p2p-sip protocol designator >>> somewhere >>>> to make it explicit. But not necessarily in one's vcard. >>>> b) We could make the client responsible for trying the >>>> generic and then p2p:. >>>> c) Going back to putting p2psip in one's >>> vcard, what does >>>> "p2psip" in one's SIP address signify anyway ? Signifies >>> that one will >>>> be part of a p2psip as and when available ? >>>> d) Isn't p2psip situational ? i.e. when one is >>> at home, may >>>> be, one will be part of the p2psip provided by the service >>> provider or >>>> even the home network; but when one is at work, one becomes >>> part of a >>>> server based larger sip substrate. >>>> What about an emergency worker who moves between >>>> different p2psip and sip networks ? >>>> >>>> What about a mobile worker who wanders from >>> Starbucks >>>> network to airport network to .. All might have different p2psip >>>> mechanisms or even a combination of p2psip and server based sip. >>>> >>>> May be I got it all wrong (mice crunching cats are >>> the norm of >>>> the day than galloping stallions) - very possible ... >>>> Cheers >>>> >>>> >>>>> -----Original Message----- >>>>> From: p2p-sip-bounces at cs.columbia.edu >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of >>> David Barrett >>>>> Sent: Monday, June 05, 2006 8:58 AM >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' >>>>> Cc: p2p-sip at cs.columbia.edu >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>> >>>>> Ok, I'll totally agree that it'd be nice to hide the details of >>>>> P2PSIP behind a standard "sip:" address (expressed or >>> implied). I >>>>> just haven't envisioned how to accomplish this in >>> conjunction with >>>>> the other requirements, and I'm trying to avoid proposing what I >>>>> can't figure out how to build. >>>>> >>>>> The problem I see isn't one of technology, but usability issues >>>>> caused in the adoption period. Clearly, P2PSIP isn't going to >>>>> happen overnight. >>>>> There will be period of years where it is slowly rolled >>> out to SIP >>>>> UAs. And during this period, I think it's important for a UA to >>>>> differentiate between invalid SIP addresses, and P2PSIP addresses >>>>> that it doesn't know how to handle. >>>>> >>>>> For example, let's assume I put my P2PSIP address on a >>> business card >>>>> as "sip:dbarrett at quinthar.com" (or just >>> "dbarrett at quinthar.com" with >>>>> the "sip:" >>>>> implied). A P2PSIP-aware UA might first look for a >>> traditional SIP >>>>> proxy at "quinthar.com" and then, not finding one, use some >>>>> DHT-based mechanism. I love that idea. >>>>> >>>>> But a P2PSIP-unaware UA will just break. It'll say the >>> address is >>>>> valid and supported, but broken. I don't love this idea. >>>>> >>>>> Thus I'm proposing, at least at the start while P2PSIP is getting >>>>> its legs, we use "p2psip:". A P2PSIP-aware UA >>> will work, >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this >>>>> address type". The blame is placed on the UA (where it >>> should be), >>>>> rather than the address. >>>>> >>>>> Maybe in the future, once P2PSIP is more established, UAs would >>>>> automatically retry all failed "sip:" >>>>> addresses on some P2PSIP framework, and then the two >>> addresses would >>>>> converge down the road. >>>>> >>>>> But I'm not sure how we can start out converged without just >>>>> confusing the user and, ultimately, hurting the SIP >>> community as a >>>>> whole -- P2P and otherwise. >>>>> >>>>> Have I missed something? Can you see a way to roll out >>> P2PSIP atop >>>>> a standard "sip:" address without appearing totally >>>>> broken throughout the deployment period? >>>>> >>>>> -david >>>>> >>>>>> -----Original Message----- >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>>>> Behalf Of >>>>>> David A. Bryan >>>>>> Sent: Monday, June 05, 2006 7:29 AM >>>>>> To: Henning Schulzrinne >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>> >>>>>> I would agree, and would add a subtly different >>> objection that a >>>>>> traditional SIP UA will be better able to interact with >>> a P2PSIP >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that >>>>>> debate hashes out). >>>>>> >>>>>> David >>>>>> >>>>>> On 6/5/06, Henning Schulzrinne wrote: >>>>>>>> I'd prefer not to debate the specifics at this point -- >>>>> if we can >>>>>>>> agree that there's some kind of "p2psip:" >>>>> address type, >>>>>>>> I think that's as deep as we need to get agreement >>> on the big >>>>>>>> picture. >>>>>>> >>>>>>> I think this is a fundamentally bad idea. I shouldn't >>>>> have to change >>>>>>> my address (and business card) just because I'm changing >>>>> some low- >>>>>>> level technical detail of how signaling requests are >>>>> routed. In any >>>>>>> event, just like many web pages are simply listed as >>>>>>> www.something.com (instead of http://www.something.com), I >>>>>>> expect that many business cards and directories will simply >>>>>>> contain alice at something.com. >>>>>>> >>>>>>> It's the role of protocols to make these resolution details >>>>>>> transparent to the user. This isn't terribly >>> difficult in this >>>>>>> particular case. >>>>>>> >>>>>>> Henning >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From fluffy at cisco.com Mon Jun 5 20:37:40 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 5 Jun 2006 17:37:40 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606051615.k55GFTX5016638@cs.columbia.edu> References: <200606051615.k55GFTX5016638@cs.columbia.edu> Message-ID: <6D60FBD1-FDD6-44E9-871C-B3E3721128B2@cisco.com> On Jun 5, 2006, at 9:15 AM, David Barrett wrote: > What is > the smallest set of requirements that you believe should be in the 1.0 > release? My personal opinion ... Interoperable communications between devices from different vendors while minimizing the expense of any "central" server equipment that is not operated/owned by the end user. I believe we could achieve a system where after initial enrollment, no "central servers" were needed for operational calls between P2P enabled clients. From ksankar at cisco.com Mon Jun 5 20:48:34 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 17:48:34 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFE77@xmb-sjc-219.amer.cisco.com> Yep, MANET and IP mobility are different paradigms. And yes, most probably the underlying connectivity substrate *can* be irrelevant to us. BTW, what is so catastrophic about an IP change ? When IP changes, delete the old record and add a new one. I know that we need to work thru the various cases and map out the various protocol activities. Cheers > -----Original Message----- > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > Sent: Monday, June 05, 2006 4:20 PM > To: Mike Robinson; Roy, Radhika R.; Krishna Sankar (ksankar) > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > Won't mobility be taken care transparently (w/o ip change) by > routers supporting 802.11f, rfc 3344 and related standards? > IP change sounds chaotic (if not catastrophic) to DHT. > > Are MANET and IP mobility mutual exclusive? > > Peter > > ----- Original Message ----- > From: Mike Robinson > To: Roy, Radhika R. ; Krishna Sankar (ksankar) > Cc: p2p-sip at cs.columbia.edu > Sent: Monday, June 05, 2006 2:39 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > Radhika Roy wrote: > > >>In fact, we will be working cooperating with them to > complete our work: > >> p2pSIP Application Layer to the MANET Network Layer. > > What is that you refer to "our work"? Whose work are you > talking? Did IETF assign you a spokesman for MANET? > > Could you please update us who authorized to speak on behalf > of MANET group? > > By the way, ad-hoc networks have nothing to do with p2p since > p2p can run on fixed infrastructure and ad-hoc networks need > not use p2p for applications. > Did it occur to you that one can run client server > applications even when network may be based on ad-hoc network > routing protocol. Supporting mobility in p2p nodes is quite > difficult contrary to what you say in your typical hand > waving style (since you would need to do reinsert your mobile > nodes in a DHT, reconfigure DHT, and update resource > information at all DHT nodes) > > I hope you would try to understand the issues with DHT and > mobility before you resume your periodic vacuous comments in > support of p2p sip (which almost always are devoid of any > technical input whatsoever). > > > o mike > > > "Roy, Radhika R." wrote: > KS: > > To support p2pSIP for mobile nodes (if not mobile devices per > se) should not be difficult. IETF Mobile Ad Hoc Network > (MANET) WG has already done the most difficult works in this > p2p networking environment: Network Routing and QoS support. > > So, it will be rather easy to support the p2pSIP application > protocol that will ride over the network layer MANET protocol. > > In fact, we will be working cooperating with them to complete > our work: > p2pSIP Application Layer to the MANET Network Layer. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > (ksankar) > Sent: Monday, June 05, 2006 11:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > Yep, definitely. Might not be that easy > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > New Yahoo! Messenger with Voice. Call regular phones from > your PC and save big. > From mike_robnson at yahoo.com Mon Jun 5 21:01:51 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Mon, 5 Jun 2006 18:01:51 -0700 (PDT) Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <4484BAE0.7010603@research.panasonic.com> Message-ID: <20060606010151.59450.qmail@web38512.mail.mud.yahoo.com> Eunsoo Sim wrote: >> In the MANET framework, the IP address of a mobile node does not change. This is definitely incorrect to the MANET framework that I am familiar with. A node may momentarily leave the network and re-join the network. This will result in address re-assignement (or self configuration with DAD in IPv6). Also, two or more networks may merge/split and address reconfiguration may take place. >> If the IP address of a mobile node changes, that's a different story. We >>can put such mobile devices as ordinary nodes (not participating in DHT) >> if the P2P network contain both fixed and mobile devices. How would a node know apriori whether and when it supports mobility or not since IP mobility support is function of node and network infrastructure? Besides, the idea of making p2p sip functionality of a node dependent on mobile-ip presence or absence sounds quite wrong to me. Unfortunartely, I don't have time to go in lengthy debates, but hopefully I have conveyed that support for mobile nodes is not that simple either as is/was being made. o mike Eunsoo Shim wrote: As long as the IP address of a node does not change, nothing special needs to be done for DHT. In the MANET framework, the IP address of a mobile node does not change. If a mobile deivce is connected to the global Internet and Mobile IP is supported, nothing special needs to be done for the mobile node participating in the DHT, either. If the IP address of a mobile node changes, that's a different story. We can put such mobile devices as ordinary nodes (not participating in DHT) if the P2P network contain both fixed and mobile devices. In my understanding, no one represents any IETF working group or any other organization in the mailing list unless she/he claims to do so explicitly. I don't see anyone claiming to represent MANET or any other WG during the discussion. Thanks. Eunsoo Mike Robinson wrote: > Radhika Roy wrote: > >>> In fact, we will be working cooperating with them to complete our work: >>> p2pSIP Application Layer to the MANET Network Layer. > > What is that you refer to "our work"? Whose work are you talking? Did IETF assign you a spokesman for MANET? > > Could you please update us who authorized to speak on behalf of MANET group? > > By the way, ad-hoc networks have nothing to do with p2p since p2p can run on fixed infrastructure and ad-hoc networks need not use p2p for applications. Did it occur to you that one can run client server applications even when network may be based on ad-hoc network routing protocol. Supporting mobility in p2p nodes is quite difficult contrary to what you say in your typical hand waving style (since you would need to do reinsert your mobile nodes in a DHT, reconfigure DHT, and update resource information at all DHT nodes) > > I hope you would try to understand the issues with DHT and mobility before you resume your periodic vacuous comments in support of p2p sip (which almost always are devoid of any technical input whatsoever). > > > o mike > > > "Roy, Radhika R." wrote: KS: > > To support p2pSIP for mobile nodes (if not mobile devices per se) should > not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done > the most difficult works in this p2p networking environment: Network > Routing and QoS support. > > So, it will be rather easy to support the p2pSIP application protocol > that will ride over the network layer MANET protocol. > > In fact, we will be working cooperating with them to complete our work: > p2pSIP Application Layer to the MANET Network Layer. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > (ksankar) > Sent: Monday, June 05, 2006 11:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > >> 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > Yep, definitely. Might not be that easy > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060605/97a3aab2/attachment.html From mike_robnson at yahoo.com Mon Jun 5 21:05:03 2006 From: mike_robnson at yahoo.com (Mike Robinson) Date: Mon, 5 Jun 2006 18:05:03 -0700 (PDT) Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <4484BAE0.7010603@research.panasonic.com> Message-ID: <20060606010503.87457.qmail@web38510.mail.mud.yahoo.com> Eunsoo Sim wrote: >> In the MANET framework, the IP address of a mobile node does not change. This is definitely incorrect to the MANET framework that I am familiar with. A node may momentarily leave the network and re-join the network. This will result in address re-assignement (or self configuration with DAD in IPv6). Also, two or more networks may merge/split and address reconfiguration may take place. >> If the IP address of a mobile node changes, that's a different story. We >>can put such mobile devices as ordinary nodes (not participating in DHT) >> if the P2P network contain both fixed and mobile devices. How would a node know apriori whether and when it supports mobility or not since IP mobility support is function of node and network infrastructure? Besides, the idea of making p2p sip functionality of a node dependent on mobile-ip presence or absence sounds quite wrong to me. Unfortunartely, I don't have time to go in lengthy debates, but hopefully I have conveyed that support for mobile nodes is not that simple either as is/was being made. o mike Eunsoo Shim wrote: As long as the IP address of a node does not change, nothing special needs to be done for DHT. In the MANET framework, the IP address of a mobile node does not change. If a mobile deivce is connected to the global Internet and Mobile IP is supported, nothing special needs to be done for the mobile node participating in the DHT, either. If the IP address of a mobile node changes, that's a different story. We can put such mobile devices as ordinary nodes (not participating in DHT) if the P2P network contain both fixed and mobile devices. In my understanding, no one represents any IETF working group or any other organization in the mailing list unless she/he claims to do so explicitly. I don't see anyone claiming to represent MANET or any other WG during the discussion. Thanks. Eunsoo Mike Robinson wrote: > Radhika Roy wrote: > >>> In fact, we will be working cooperating with them to complete our work: >>> p2pSIP Application Layer to the MANET Network Layer. > > What is that you refer to "our work"? Whose work are you talking? Did IETF assign you a spokesman for MANET? > > Could you please update us who authorized to speak on behalf of MANET group? > > By the way, ad-hoc networks have nothing to do with p2p since p2p can run on fixed infrastructure and ad-hoc networks need not use p2p for applications. Did it occur to you that one can run client server applications even when network may be based on ad-hoc network routing protocol. Supporting mobility in p2p nodes is quite difficult contrary to what you say in your typical hand waving style (since you would need to do reinsert your mobile nodes in a DHT, reconfigure DHT, and update resource information at all DHT nodes) > > I hope you would try to understand the issues with DHT and mobility before you resume your periodic vacuous comments in support of p2p sip (which almost always are devoid of any technical input whatsoever). > > > o mike > > > "Roy, Radhika R." wrote: KS: > > To support p2pSIP for mobile nodes (if not mobile devices per se) should > not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done > the most difficult works in this p2p networking environment: Network > Routing and QoS support. > > So, it will be rather easy to support the p2pSIP application protocol > that will ride over the network layer MANET protocol. > > In fact, we will be working cooperating with them to complete our work: > p2pSIP Application Layer to the MANET Network Layer. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > (ksankar) > Sent: Monday, June 05, 2006 11:43 AM > To: David Barrett; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > My view of the P2P-SIP world ... > >> 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > Yep, definitely. Might not be that easy > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > --------------------------------- > New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060605/c8e4ad09/attachment-0001.html From huang-ming.pan at comcast.net Mon Jun 5 22:06:35 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 5 Jun 2006 19:06:35 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFE77@xmb-sjc-219.amer.cisco.com> Message-ID: <00f001c6890d$d75ffc90$7f0010ac@pi2000> The basic troubles to application, operating system and network caused by a IP change are described in rfc 3344. The troubles to P2P SIP at least includes: * stale DHT fingers or k-buckets (besides those resulted from nodes leaving network) * stale SIP registration (nodes need to register) * stale TURN relay (needs re-discovery) and sessions (needs SDP re-negotiation) * no more transparent singaling/media handover (if "L7 handover" had worked perfectly there would be no rfc 3344) Please omit unnecessary work when good solution (ip mobility) is there. Peter ----- Original Message ----- From: "Krishna Sankar (ksankar)" To: "Peter Pan" ; "Mike Robinson" ; "Roy, Radhika R." Cc: Sent: Monday, June 05, 2006 5:48 PM Subject: Re: [p2p-sip] What are we doing, question 2 > Yep, MANET and IP mobility are different paradigms. And yes, most > probably the underlying connectivity substrate *can* be irrelevant to > us. > > BTW, what is so catastrophic about an IP change ? When IP changes, > delete the old record and add a new one. I know that we need to work > thru the various cases and map out the various protocol activities. > > Cheers > > > > -----Original Message----- > > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > > Sent: Monday, June 05, 2006 4:20 PM > > To: Mike Robinson; Roy, Radhika R.; Krishna Sankar (ksankar) > > Cc: p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > Won't mobility be taken care transparently (w/o ip change) by > > routers supporting 802.11f, rfc 3344 and related standards? > > IP change sounds chaotic (if not catastrophic) to DHT. > > > > Are MANET and IP mobility mutual exclusive? > > > > Peter > > > > ----- Original Message ----- > > From: Mike Robinson > > To: Roy, Radhika R. ; Krishna Sankar (ksankar) > > Cc: p2p-sip at cs.columbia.edu > > Sent: Monday, June 05, 2006 2:39 PM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > Radhika Roy wrote: > > > > >>In fact, we will be working cooperating with them to > > complete our work: > > >> p2pSIP Application Layer to the MANET Network Layer. > > > > What is that you refer to "our work"? Whose work are you > > talking? Did IETF assign you a spokesman for MANET? > > > > Could you please update us who authorized to speak on behalf > > of MANET group? > > > > By the way, ad-hoc networks have nothing to do with p2p since > > p2p can run on fixed infrastructure and ad-hoc networks need > > not use p2p for applications. > > Did it occur to you that one can run client server > > applications even when network may be based on ad-hoc network > > routing protocol. Supporting mobility in p2p nodes is quite > > difficult contrary to what you say in your typical hand > > waving style (since you would need to do reinsert your mobile > > nodes in a DHT, reconfigure DHT, and update resource > > information at all DHT nodes) > > > > I hope you would try to understand the issues with DHT and > > mobility before you resume your periodic vacuous comments in > > support of p2p sip (which almost always are devoid of any > > technical input whatsoever). > > > > > > o mike > > > > > > "Roy, Radhika R." wrote: > > KS: > > > > To support p2pSIP for mobile nodes (if not mobile devices per > > se) should not be difficult. IETF Mobile Ad Hoc Network > > (MANET) WG has already done the most difficult works in this > > p2p networking environment: Network Routing and QoS support. > > > > So, it will be rather easy to support the p2pSIP application > > protocol that will ride over the network layer MANET protocol. > > > > In fact, we will be working cooperating with them to complete > > our work: > > p2pSIP Application Layer to the MANET Network Layer. > > > > Best regards, > > Radhika R. Roy > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > > (ksankar) > > Sent: Monday, June 05, 2006 11:43 AM > > To: David Barrett; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > My view of the P2P-SIP world ... > > > > > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? > > > > Yep, definitely. Might not be that easy > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > > > > New Yahoo! Messenger with Voice. Call regular phones from > > your PC and save big. > > > > > From ksankar at cisco.com Tue Jun 6 00:23:30 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Mon, 5 Jun 2006 21:23:30 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFEA0@xmb-sjc-219.amer.cisco.com> Peter, Agreed, we should not create more work for us and we should make assumptions and requirements that simplify our work. OTOH, we cannot make assumptions that will curtail our adoption. Without getting into any sort of a religious debate, mobile IP and MANET are solving different problems. Me thinks (am open to be corrected) that we will find MANET more than mobile IP. Depending on that assumption, we can decide the mobility substrate requirements one way or the other. May be, as David says, we should de-prioritize (for 1.0) the whole MANET issue and assume no mobility substrate or one that is transparent/irrelevant to us. Like I said earlier, we should specify the assumptions behind this crisply so that there is no ambiguity and divergence later. Cheers > -----Original Message----- > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > Sent: Monday, June 05, 2006 7:07 PM > To: Krishna Sankar (ksankar); Mike Robinson; Roy, Radhika R. > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > The basic troubles to application, operating system and > network caused by a IP change are described in rfc 3344. > > The troubles to P2P SIP at least includes: > > * stale DHT fingers or k-buckets (besides those resulted from > nodes leaving > network) > * stale SIP registration (nodes need to register) > * stale TURN relay (needs re-discovery) and sessions (needs SDP > re-negotiation) > * no more transparent singaling/media handover (if "L7 > handover" had worked perfectly there would be no rfc 3344) > > Please omit unnecessary work when good solution (ip mobility) > is there. > > Peter > > ----- Original Message ----- > From: "Krishna Sankar (ksankar)" > To: "Peter Pan" ; "Mike Robinson" > ; "Roy, Radhika R." > Cc: > Sent: Monday, June 05, 2006 5:48 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > Yep, MANET and IP mobility are different paradigms. And yes, most > > probably the underlying connectivity substrate *can* be > irrelevant to > > us. > > > > BTW, what is so catastrophic about an IP change ? When IP changes, > > delete the old record and add a new one. I know that we > need to work > > thru the various cases and map out the various protocol activities. > > > > Cheers > > > > > > > -----Original Message----- > > > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > > > Sent: Monday, June 05, 2006 4:20 PM > > > To: Mike Robinson; Roy, Radhika R.; Krishna Sankar (ksankar) > > > Cc: p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > Won't mobility be taken care transparently (w/o ip change) by > > > routers supporting 802.11f, rfc 3344 and related standards? > > > IP change sounds chaotic (if not catastrophic) to DHT. > > > > > > Are MANET and IP mobility mutual exclusive? > > > > > > Peter > > > > > > ----- Original Message ----- > > > From: Mike Robinson > > > To: Roy, Radhika R. ; Krishna Sankar (ksankar) > > > Cc: p2p-sip at cs.columbia.edu > > > Sent: Monday, June 05, 2006 2:39 PM > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > Radhika Roy wrote: > > > > > > >>In fact, we will be working cooperating with them to > > > complete our work: > > > >> p2pSIP Application Layer to the MANET Network Layer. > > > > > > What is that you refer to "our work"? Whose work are you talking? > > > Did IETF assign you a spokesman for MANET? > > > > > > Could you please update us who authorized to speak on behalf of > > > MANET group? > > > > > > By the way, ad-hoc networks have nothing to do with p2p since p2p > > > can run on fixed infrastructure and ad-hoc networks need > not use p2p > > > for applications. > > > Did it occur to you that one can run client server > applications even > > > when network may be based on ad-hoc network routing protocol. > > > Supporting mobility in p2p nodes is quite difficult > contrary to what > > > you say in your typical hand waving style (since you > would need to > > > do reinsert your mobile nodes in a DHT, reconfigure DHT, > and update > > > resource information at all DHT nodes) > > > > > > I hope you would try to understand the issues with DHT > and mobility > > > before you resume your periodic vacuous comments in > support of p2p > > > sip (which almost always are devoid of any technical input > > > whatsoever). > > > > > > > > > o mike > > > > > > > > > "Roy, Radhika R." wrote: > > > KS: > > > > > > To support p2pSIP for mobile nodes (if not mobile devices per > > > se) should not be difficult. IETF Mobile Ad Hoc Network > > > (MANET) WG has already done the most difficult works in this p2p > > > networking environment: Network Routing and QoS support. > > > > > > So, it will be rather easy to support the p2pSIP application > > > protocol that will ride over the network layer MANET protocol. > > > > > > In fact, we will be working cooperating with them to complete our > > > work: > > > p2pSIP Application Layer to the MANET Network Layer. > > > > > > Best regards, > > > Radhika R. Roy > > > > > > -----Original Message----- > > > From: p2p-sip-bounces at cs.columbia.edu > > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > Krishna Sankar > > > (ksankar) > > > Sent: Monday, June 05, 2006 11:43 AM > > > To: David Barrett; p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > My view of the P2P-SIP world ... > > > > > > > 2) Does P2PSIP work on mobile devices assigned dynamic > IP addresses? > > > > > > Yep, definitely. Might not be that easy > > > > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > > > > > > > > > > New Yahoo! Messenger with Voice. Call regular phones from your PC > > > and save big. > > > > > > > > > > From karstbj at yahoo.com Tue Jun 6 00:45:45 2006 From: karstbj at yahoo.com (Karst Bjorgson) Date: Mon, 5 Jun 2006 21:45:45 -0700 (PDT) Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <7B8DCFEC-A86A-45A3-9FEB-DCCE4944D3D4@cisco.com> Message-ID: <20060606044545.98296.qmail@web53010.mail.yahoo.com> --- Cullen Jennings wrote: > > Some of the proposal so for have come up with ways > to make sip: > addresses work and make things interoperable with > more traditional > sip. Clearly having interoperate would be a nice > property if > possible. However, I am still lost on what we are > trying to > accomplish, much less what the solutions is or if it > needs a > different URL. We seem to be oscillating between two different ideas, that I would name "distributed proxy" and "cruise ship". In the "distributed proxy" scenario, the UA in a SIP domain conspire to resolve names through a distributed process, e.g. a DHT. The names are probably of the form: sip:@. The "domain" is common to all UA participating in the scheme. "User" and "subdomain" are used to identify specific UA within that domain. The domain selects a distribution method, e.g. a specific DHT technology. The domain somehow provides a set of proxies for communicating with CS-SIP. In the "cruise ship" scenario, UA that happens to be on an isolated network use a local discovery mechanism to establish sessions, even though their respective gateways are unreachable. They use the same URL they would use in CS-SIP, e.g. "sip:user at example.com" or "sip:karstbj at yahoo.com". P2P is a fallback mechanism. The UA just happen to be at the same place, and are not configured to use a specific technology. We need to standardize a common discovery mechanism, either a DHT or possibly something very simple like SDP. In both cases, we want to use plain "sip:" URL. In the "distributed proxy" scenario, use of plain "sip:" URL allows for easy interconnect with CS-SIP. In the "cruise ship" scenario, use of plain "sip:" URL allow for reuse of existing names. Of course, we could choose to only address one of these two scenarios... -- Karst __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dean.willis at softarmor.com Tue Jun 6 00:54:45 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 5 Jun 2006 23:54:45 -0500 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606051558.k55Fw8X5009286@cs.columbia.edu> References: <200606051558.k55Fw8X5009286@cs.columbia.edu> Message-ID: On Jun 5, 2006, at 10:57 AM, David Barrett wrote: > > For example, let's assume I put my P2PSIP address on a business > card as > "sip:dbarrett at quinthar.com" (or just "dbarrett at quinthar.com" with > the "sip:" > implied). A P2PSIP-aware UA might first look for a traditional SIP > proxy at > "quinthar.com" and then, not finding one, use some DHT-based > mechanism. I > love that idea. > > But a P2PSIP-unaware UA will just break. It'll say the address is > valid and > supported, but broken. I don't love this idea. > If you intend your P2PSIP overlay to be useful, you'd better have a resolver/introducer/rendezvous/whatever server at quinthar.com to make this route resolve for a stadnard SIP client. Otherwise, we're not defining P2P uses of SIP, we're defining some new protocol that, well, isn't SIP. -- Dean From dbarrett at quinthar.com Tue Jun 6 01:43:25 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 22:43:25 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <20060606044545.98296.qmail@web53010.mail.yahoo.com> Message-ID: <200606060547.k565hTX5020008@cs.columbia.edu> Ah, interesting -- thanks for capturing this distinction: - "distributed proxy" UAs construct and use a P2P SIP proxy, without any CS. - "cruise ship" UAs use CS SIP proxies when on the internet, or P2P if not. What other core ideas are floating around? Can we define then and give them names? -david > -----Original Message----- > From: Karst Bjorgson [mailto:karstbj at yahoo.com] > Sent: Monday, June 05, 2006 9:46 PM > To: Cullen Jennings; David Barrett > Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan' > Subject: Re: [p2p-sip] What are we doing, question 2 > > We seem to be oscillating between two different ideas, > that I would name "distributed proxy" and "cruise > ship". > > In the "distributed proxy" scenario, the UA in a SIP > domain conspire to resolve names through a distributed > process, e.g. a DHT. The names are probably of the > form: > sip:@. > The "domain" is common to all UA participating in the > scheme. "User" and "subdomain" are used to identify > specific UA within that domain. The domain selects a > distribution method, e.g. a specific DHT technology. > The domain somehow provides a set of proxies for > communicating with CS-SIP. > > In the "cruise ship" scenario, UA that happens to be > on an isolated network use a local discovery mechanism > to establish sessions, even though their respective > gateways are unreachable. They use the same URL they > would use in CS-SIP, e.g. "sip:user at example.com" or > "sip:karstbj at yahoo.com". P2P is a fallback mechanism. > The UA just happen to be at the same place, and are > not configured to use a specific technology. We need > to standardize a common discovery mechanism, either a > DHT or possibly something very simple like SDP. > > In both cases, we want to use plain "sip:" URL. In the > "distributed proxy" scenario, use of plain "sip:" URL > allows for easy interconnect with CS-SIP. In the > "cruise ship" scenario, use of plain "sip:" URL allow > for reuse of existing names. > > Of course, we could choose to only address one of > these two scenarios... > > -- Karst > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com From dbarrett at quinthar.com Tue Jun 6 02:00:48 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 5 Jun 2006 23:00:48 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <7B8DCFEC-A86A-45A3-9FEB-DCCE4944D3D4@cisco.com> Message-ID: <200606060603.k5660mX5026061@cs.columbia.edu> Well, what I'm trying to accomplish is enunciate a vision for how the product works for a user. Once we agree upon what P2PSIP is supposed to do for the user, then I think we can more easily discuss how to make that happen. With this in mind, here's an updated story for my vision of what a P2PSIP 1.0 UA does: You and I each install a P2PSIP-enabled UA while sitting on the same LAN. I click the "Create a new network" button on my UA, and give it the name "quinthar". [1] It asks me what my name is on this network, and I say "dbarrett". [2] Your UA detects this and lists "quinthar" as one of the known networks, and "dbarrett at quinthar" as a known user. [3] You choose the "quinthar" network and click "Join network", then specify that your name is "fluffy". [4] On my UA, I see "fluffy at quinthar" is listed in as a known user. I double click on "fluffy at quinthar", and initiate a VoIP call. [5] [1] For 1.0, anyone can create a network; later it might be tied to public key encryption. [2] For 1.0, anyone can choose any name when joining a network; later each network might have an administrator. [3] For 1.0, UAs broadcast their network affiliation using IP multicast. Later there might be global network registries, special bootstrapping servers, or even a global DHT set aside to publish networks. [4] For 1.0, anyone can join any network they've discovered, or by entering the IP:port of a node on the network. [5] We've created identities, discovered each other, and initiated a SIP call -- all without ever touching a single server. Does this story basically capture the same product that you want to enable with P2PSIP? If not, can you follow the pattern above and lay out your own story? -david > -----Original Message----- > From: Cullen Jennings [mailto:fluffy at cisco.com] > Sent: Monday, June 05, 2006 5:36 PM > To: David Barrett > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > > Some of the proposal so for have come up with ways to make sip: > addresses work and make things interoperable with more traditional > sip. Clearly having interoperate would be a nice property if > possible. However, I am still lost on what we are trying to > accomplish, much less what the solutions is or if it needs a > different URL. > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > Again, I love the idea of having a single "sip:" address that "just > > works" > > for both CS and P2P SIP. Please help me understand your proposal > > better. > > > > Will I be able to print my combined CS/P2P SIP address on a > > business card, > > hand it to you, and have you type it into your SIP UA and get an > > expected > > result (a valid connection, if it's P2PSIP aware, or a message saying > > "unsupported address type" if not)? If so, what might that address > > look > > like? > > > > I've proposed your business card might say: > > > > sip:@ > > > > Or > > > > p2psip:[@] [1] > > > > If instead we only use the first format, how does a UA figure out > > which DHT > > the address is registered with, and how does it connect to that > > DHT? I can > > imagine URI attributes: > > > > sip:@[?dht=] > > > > And I think this is a great solution. But I don't understand how a > > human > > would input "header elements" to a UA. Am I misunderstanding the > > proposal? > > > > -david > > > > [1] I've proposed is [@], and that it's > > optional (defaulting to some global DHT if unspecified). But the > > precise > > syntax is unimportant. What is important is that the address contain > > whatever information is necessary to connect to a given DHT. > > > >> -----Original Message----- > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > >> Sent: Monday, June 05, 2006 10:22 AM > >> To: David A. Bryan > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > >> Subject: RE: [p2p-sip] What are we doing, question 2 > >> > >> Agreed. If we, in-principle, see the need for the > >> p2psip:[@@[]], we can make it as > >> harmless > >> as possible - a set of header elements or a set of URI parameter > >> is an > >> excellent choice. > >> > >> I like header element better - something like : > >> Additional-Format:P2P > >> P2P-DHTName:,,... > >> P2P-BootStrap:,... > >> > >> Cheers > >> > >> > >>> -----Original Message----- > >>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > >>> Behalf Of David A. Bryan > >>> Sent: Monday, June 05, 2006 10:09 AM > >>> To: Krishna Sankar (ksankar) > >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>> > >>> If we have a p2psip: address, what does a non-P2P SIP > >>> endpoint do with it? On the otherhand, a regular sip: address > >>> can go from a UA to a proxy that is more likely to be able to > >>> do something useful (forward it to a p2p domain)? See the > >>> draft Enrico and I did > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > >>> > >>> We can use maybe use something else in the messages -- a URI > >>> param or a header perhaps -- to distinguish P2P from regular > >>> SIP where needed, but I think we should ensure that a URI is > >>> as backward compliant as possible. > >>> > >>> --David Bryan > >>> > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > >>>> David, > >>>> > >>>> You have a valid point making p2p-sip explicit for all than > >>>> implicit in the UAs who understand it. > >>>> a) I mulled it over and do not see any other > >>> way, as a 1.0 > >>>> requirement. i.e. we do need a p2p-sip protocol designator > >>> somewhere > >>>> to make it explicit. But not necessarily in one's vcard. > >>>> b) We could make the client responsible for trying the > >>>> generic and then p2p:. > >>>> c) Going back to putting p2psip in one's > >>> vcard, what does > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > >>> that one will > >>>> be part of a p2psip as and when available ? > >>>> d) Isn't p2psip situational ? i.e. when one is > >>> at home, may > >>>> be, one will be part of the p2psip provided by the service > >>> provider or > >>>> even the home network; but when one is at work, one becomes > >>> part of a > >>>> server based larger sip substrate. > >>>> What about an emergency worker who moves between > >>>> different p2psip and sip networks ? > >>>> > >>>> What about a mobile worker who wanders from > >>> Starbucks > >>>> network to airport network to .. All might have different p2psip > >>>> mechanisms or even a combination of p2psip and server based sip. > >>>> > >>>> May be I got it all wrong (mice crunching cats are > >>> the norm of > >>>> the day than galloping stallions) - very possible ... > >>>> Cheers > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: p2p-sip-bounces at cs.columbia.edu > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > >>> David Barrett > >>>>> Sent: Monday, June 05, 2006 8:58 AM > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > >>>>> Cc: p2p-sip at cs.columbia.edu > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>>>> > >>>>> Ok, I'll totally agree that it'd be nice to hide the details of > >>>>> P2PSIP behind a standard "sip:" address (expressed or > >>> implied). I > >>>>> just haven't envisioned how to accomplish this in > >>> conjunction with > >>>>> the other requirements, and I'm trying to avoid proposing what I > >>>>> can't figure out how to build. > >>>>> > >>>>> The problem I see isn't one of technology, but usability issues > >>>>> caused in the adoption period. Clearly, P2PSIP isn't going to > >>>>> happen overnight. > >>>>> There will be period of years where it is slowly rolled > >>> out to SIP > >>>>> UAs. And during this period, I think it's important for a UA to > >>>>> differentiate between invalid SIP addresses, and P2PSIP addresses > >>>>> that it doesn't know how to handle. > >>>>> > >>>>> For example, let's assume I put my P2PSIP address on a > >>> business card > >>>>> as "sip:dbarrett at quinthar.com" (or just > >>> "dbarrett at quinthar.com" with > >>>>> the "sip:" > >>>>> implied). A P2PSIP-aware UA might first look for a > >>> traditional SIP > >>>>> proxy at "quinthar.com" and then, not finding one, use some > >>>>> DHT-based mechanism. I love that idea. > >>>>> > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > >>> address is > >>>>> valid and supported, but broken. I don't love this idea. > >>>>> > >>>>> Thus I'm proposing, at least at the start while P2PSIP is getting > >>>>> its legs, we use "p2psip:". A P2PSIP-aware UA > >>> will work, > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this > >>>>> address type". The blame is placed on the UA (where it > >>> should be), > >>>>> rather than the address. > >>>>> > >>>>> Maybe in the future, once P2PSIP is more established, UAs would > >>>>> automatically retry all failed "sip:" > >>>>> addresses on some P2PSIP framework, and then the two > >>> addresses would > >>>>> converge down the road. > >>>>> > >>>>> But I'm not sure how we can start out converged without just > >>>>> confusing the user and, ultimately, hurting the SIP > >>> community as a > >>>>> whole -- P2P and otherwise. > >>>>> > >>>>> Have I missed something? Can you see a way to roll out > >>> P2PSIP atop > >>>>> a standard "sip:" address without appearing totally > >>>>> broken throughout the deployment period? > >>>>> > >>>>> -david > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > >>>>> Behalf Of > >>>>>> David A. Bryan > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > >>>>>> To: Henning Schulzrinne > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>>>>> > >>>>>> I would agree, and would add a subtly different > >>> objection that a > >>>>>> traditional SIP UA will be better able to interact with > >>> a P2PSIP > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that > >>>>>> debate hashes out). > >>>>>> > >>>>>> David > >>>>>> > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > >>>>>>>> I'd prefer not to debate the specifics at this point -- > >>>>> if we can > >>>>>>>> agree that there's some kind of "p2psip:" > >>>>> address type, > >>>>>>>> I think that's as deep as we need to get agreement > >>> on the big > >>>>>>>> picture. > >>>>>>> > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > >>>>> have to change > >>>>>>> my address (and business card) just because I'm changing > >>>>> some low- > >>>>>>> level technical detail of how signaling requests are > >>>>> routed. In any > >>>>>>> event, just like many web pages are simply listed as > >>>>>>> www.something.com (instead of http://www.something.com), I > >>>>>>> expect that many business cards and directories will simply > >>>>>>> contain alice at something.com. > >>>>>>> > >>>>>>> It's the role of protocols to make these resolution details > >>>>>>> transparent to the user. This isn't terribly > >>> difficult in this > >>>>>>> particular case. > >>>>>>> > >>>>>>> Henning > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>> > >>> > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From dbarrett at quinthar.com Tue Jun 6 03:10:17 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 6 Jun 2006 00:10:17 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: Message-ID: <200606060710.k567AZX5021391@cs.columbia.edu> > -----Original Message----- > From: Dean Willis [mailto:dean.willis at softarmor.com] > > If you intend your P2PSIP overlay to be useful, you'd better have a > resolver/introducer/rendezvous/whatever server at quinthar.com to > make this route resolve for a stadnard SIP client. > > Otherwise, we're not defining P2P uses of SIP, we're defining some > new protocol that, well, isn't SIP. I totally agree that in the long term, the gulf between P2P and client/server SIP needs bridging. But I'm not sure it *needs* to be done in v1.0 of P2PSIP. I think useful work can be done on a v1.0 P2PSIP standard that doesn't address this problem. For example, in my previous email, I sketched out a vision for how P2PSIP could be used in an environment totally devoid of client/server SIP. If that's the best we can do for v1.0 P2PSIP, I count that as a success even though it means your CS-only UA couldn't call my P2P-only UA because I haven't registered an address on a traditional SIP proxy. However, it's easy to imagine that my P2P UA could call your CS UA: I click "Add a buddy" and enter "sip:dean.willis at softarmor.com", and my P2P UA recognizes it as a client/server address and treats it accordingly. Likewise, the reverse is also easy to imagine: I click an "Add an address" button and type "sip:dbarrett at softarmor.com", and register my UA on your traditional SIP server. And finally, it's easy to imagine that I (the founder of the 'quinthar' DHT) enable non-P2P UAs to contact P2P users on my DHT by putting up a P2P gateway at "quinthar.com". Thus when you type "sip:dbarrett at quinthar.com" into your non-P2P UA, your UA treats my gateway as if it's a standard SIP proxy. But when someone types "sip:dbarrett at quinthar.com" into a P2P-enabled UA, it uses my gateway as a bootstrapping server to join the "quinthar" DHT, and then never talks to it again. Basically, for v1.0, it seems useful and easiest to not worry too much about interoperation between traditional and P2P SIP UAs. There exist a variety of options to bridge the gap down the road. -david From enrico.marocco at telecomitalia.it Tue Jun 6 04:08:52 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Tue, 06 Jun 2006 10:08:52 +0200 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <20060606010503.87457.qmail@web38510.mail.mud.yahoo.com> References: <20060606010503.87457.qmail@web38510.mail.mud.yahoo.com> Message-ID: <44853814.2040102@telecomitalia.it> Mike Robinson wrote: > Unfortunartely, I don't have time to go in lengthy debates Sending mails twice won't help much anyway. Enrico From eunsoo at research.panasonic.com Tue Jun 6 07:10:50 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 06 Jun 2006 07:10:50 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606060008.AFY53379@redwood.research.panasonic.com> References: <200606060008.AFY53379@redwood.research.panasonic.com> Message-ID: <448562BA.1040401@research.panasonic.com> David Barrett wrote: >Ah, thanks, I think that makes sense. Correct me if I misunderstand, but >are you're proposing that every DHT have at least one persistent node that >does two tasks: > >1) Helps P2PSIP-aware UAs join the DHT (ie, bootstrap) >2) Handles INVITE requests from P2PSIP-unaware UAs > > > Yes. The two tasks can be done by different nodes, though. Logically each can be called 'Bootstrap Server' and 'P2P SIP Proxy (or P2P CS SIP Gateway)' respectively. >Once you're a member of the DHT, then you needn't talk with DHT proxy node >ever again. And if you can't or don't want to use the DHT, just send a >normal INVITE to the DHT proxy and it'll return as if it's a standard CS >proxy. > >Is this right? If so, I think I like it. > > > That is right. >One problem is it means we're not totally decentralized, because every DHT >needs a persistent bootstrapping server. (Though this neatly allows for any >number of DHTs to exist in parallel, and assuming "sip:dbarrett at 192.168.0.1" >is a valid address, then we can operate in environments without DNS.) > > > Bootstrapping can be done in many ways. As you said below, multicast based search is one way even though it works only in limited environments. Therefore, it is up to the deployment scenario whether a persistent bootstrap server will be installed. The P2P SIP Proxy (or P2P CS SIP Gateway) is necessary if there is need to support session establishment with non-P2P SIP UAs or UAs in the remote domains. If you want to run an isolated P2PSIP network, you don't need it. >Pure decentralization could be hacked into this with some kind of >"pseudodomain" like "sip:dbarrett at quinthar.dht", and the UA might do (for >example) an IP multicast to find other nodes participating in the "quinthar" >DHT. Clearly that would fail miserably for a P2PSIP-unaware UA, but that >strikes me as acceptable. > >Anyway, am I understanding your proposal correctly? > > > I think so. Thanks. Eunsoo > > >>-----Original Message----- >>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] >>Sent: Monday, June 05, 2006 4:01 PM >>To: David Barrett >>Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; p2p-sip at cs.columbia.edu >>Subject: Re: [p2p-sip] What are we doing, question 2 >> >>The domainname should be able to lead to the proper DHT. >>If the domain is your local domain, it is done. >>If the domain is a remote domain, DNS is used to find the remote >>domain's proxy that is participating in the DHT of the domain and the >>INVITE message is sent to the proxy. >> >>This approach makes it transparent to the user whether the underling >>location lookup is based on a central server (C/S SIP) or a DHT within >>each domain (P2PSIP). >> >>Thanks. >> >>Eunsoo >> >> >>David Barrett wrote: >> >> >>>Again, I love the idea of having a single "sip:" address that "just >>> >>> >>works" >> >> >>>for both CS and P2P SIP. Please help me understand your proposal >>> >>> >>better. >> >> >>>Will I be able to print my combined CS/P2P SIP address on a business >>> >>> >>card, >> >> >>>hand it to you, and have you type it into your SIP UA and get an >>> >>> >>expected >> >> >>>result (a valid connection, if it's P2PSIP aware, or a message saying >>>"unsupported address type" if not)? If so, what might that address look >>>like? >>> >>>I've proposed your business card might say: >>> >>> sip:@ >>> >>>Or >>> >>> p2psip:[@] [1] >>> >>>If instead we only use the first format, how does a UA figure out which >>> >>> >>DHT >> >> >>>the address is registered with, and how does it connect to that DHT? I >>> >>> >>can >> >> >>>imagine URI attributes: >>> >>> sip:@[?dht=] >>> >>>And I think this is a great solution. But I don't understand how a >>> >>> >>human >> >> >>>would input "header elements" to a UA. Am I misunderstanding the >>> >>> >>proposal? >> >> >>>-david >>> >>>[1] I've proposed is [@], and that it's >>>optional (defaulting to some global DHT if unspecified). But the >>> >>> >>precise >> >> >>>syntax is unimportant. What is important is that the address contain >>>whatever information is necessary to connect to a given DHT. >>> >>> >>> >>>>-----Original Message----- >>>>From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] >>>>Sent: Monday, June 05, 2006 10:22 AM >>>>To: David A. Bryan >>>>Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >>>>Subject: RE: [p2p-sip] What are we doing, question 2 >>>> >>>>Agreed. If we, in-principle, see the need for the >>>>p2psip:[@@[]], we can make it as harmless >>>>as possible - a set of header elements or a set of URI parameter is an >>>>excellent choice. >>>> >>>>I like header element better - something like : >>>>Additional-Format:P2P >>>>P2P-DHTName:,,... >>>>P2P-BootStrap:,... >>>> >>>>Cheers >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>>>>Behalf Of David A. Bryan >>>>>Sent: Monday, June 05, 2006 10:09 AM >>>>>To: Krishna Sankar (ksankar) >>>>>Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >>>>>Subject: Re: [p2p-sip] What are we doing, question 2 >>>>> >>>>>If we have a p2psip: address, what does a non-P2P SIP >>>>>endpoint do with it? On the otherhand, a regular sip: address >>>>>can go from a UA to a proxy that is more likely to be able to >>>>>do something useful (forward it to a p2p domain)? See the >>>>>draft Enrico and I did >>>>>(draft-marocco-sipping-p2p-scenarios-00.html) for details. >>>>> >>>>>We can use maybe use something else in the messages -- a URI >>>>>param or a header perhaps -- to distinguish P2P from regular >>>>>SIP where needed, but I think we should ensure that a URI is >>>>>as backward compliant as possible. >>>>> >>>>>--David Bryan >>>>> >>>>>On 6/5/06, Krishna Sankar (ksankar) wrote: >>>>> >>>>> >>>>>>David, >>>>>> >>>>>> You have a valid point making p2p-sip explicit for all than >>>>>>implicit in the UAs who understand it. >>>>>> a) I mulled it over and do not see any other >>>>>> >>>>>> >>>>>way, as a 1.0 >>>>> >>>>> >>>>>>requirement. i.e. we do need a p2p-sip protocol designator >>>>>> >>>>>> >>>>>somewhere >>>>> >>>>> >>>>>>to make it explicit. But not necessarily in one's vcard. >>>>>> b) We could make the client responsible for trying the >>>>>>generic and then p2p:. >>>>>> c) Going back to putting p2psip in one's >>>>>> >>>>>> >>>>>vcard, what does >>>>> >>>>> >>>>>>"p2psip" in one's SIP address signify anyway ? Signifies >>>>>> >>>>>> >>>>>that one will >>>>> >>>>> >>>>>>be part of a p2psip as and when available ? >>>>>> d) Isn't p2psip situational ? i.e. when one is >>>>>> >>>>>> >>>>>at home, may >>>>> >>>>> >>>>>>be, one will be part of the p2psip provided by the service >>>>>> >>>>>> >>>>>provider or >>>>> >>>>> >>>>>>even the home network; but when one is at work, one becomes >>>>>> >>>>>> >>>>>part of a >>>>> >>>>> >>>>>>server based larger sip substrate. >>>>>> What about an emergency worker who moves between >>>>>>different p2psip and sip networks ? >>>>>> >>>>>> What about a mobile worker who wanders from >>>>>> >>>>>> >>>>>Starbucks >>>>> >>>>> >>>>>>network to airport network to .. All might have different p2psip >>>>>>mechanisms or even a combination of p2psip and server based sip. >>>>>> >>>>>> May be I got it all wrong (mice crunching cats are >>>>>> >>>>>> >>>>>the norm of >>>>> >>>>> >>>>>>the day than galloping stallions) - very possible ... >>>>>>Cheers >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: p2p-sip-bounces at cs.columbia.edu >>>>>>>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of >>>>>>> >>>>>>> >>>>>David Barrett >>>>> >>>>> >>>>>>>Sent: Monday, June 05, 2006 8:58 AM >>>>>>>To: 'David A. Bryan'; 'Henning Schulzrinne' >>>>>>>Cc: p2p-sip at cs.columbia.edu >>>>>>>Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>>> >>>>>>>Ok, I'll totally agree that it'd be nice to hide the details of >>>>>>>P2PSIP behind a standard "sip:" address (expressed or >>>>>>> >>>>>>> >>>>>implied). I >>>>> >>>>> >>>>>>>just haven't envisioned how to accomplish this in >>>>>>> >>>>>>> >>>>>conjunction with >>>>> >>>>> >>>>>>>the other requirements, and I'm trying to avoid proposing what I >>>>>>>can't figure out how to build. >>>>>>> >>>>>>>The problem I see isn't one of technology, but usability issues >>>>>>>caused in the adoption period. Clearly, P2PSIP isn't going to >>>>>>>happen overnight. >>>>>>>There will be period of years where it is slowly rolled >>>>>>> >>>>>>> >>>>>out to SIP >>>>> >>>>> >>>>>>>UAs. And during this period, I think it's important for a UA to >>>>>>>differentiate between invalid SIP addresses, and P2PSIP addresses >>>>>>>that it doesn't know how to handle. >>>>>>> >>>>>>>For example, let's assume I put my P2PSIP address on a >>>>>>> >>>>>>> >>>>>business card >>>>> >>>>> >>>>>>>as "sip:dbarrett at quinthar.com" (or just >>>>>>> >>>>>>> >>>>>"dbarrett at quinthar.com" with >>>>> >>>>> >>>>>>>the "sip:" >>>>>>>implied). A P2PSIP-aware UA might first look for a >>>>>>> >>>>>>> >>>>>traditional SIP >>>>> >>>>> >>>>>>>proxy at "quinthar.com" and then, not finding one, use some >>>>>>>DHT-based mechanism. I love that idea. >>>>>>> >>>>>>>But a P2PSIP-unaware UA will just break. It'll say the >>>>>>> >>>>>>> >>>>>address is >>>>> >>>>> >>>>>>>valid and supported, but broken. I don't love this idea. >>>>>>> >>>>>>>Thus I'm proposing, at least at the start while P2PSIP is getting >>>>>>>its legs, we use "p2psip:". A P2PSIP-aware UA >>>>>>> >>>>>>> >>>>>will work, >>>>> >>>>> >>>>>>>and a P2PSIP-unaware UA can clearly say "I don't support this >>>>>>>address type". The blame is placed on the UA (where it >>>>>>> >>>>>>> >>>>>should be), >>>>> >>>>> >>>>>>>rather than the address. >>>>>>> >>>>>>>Maybe in the future, once P2PSIP is more established, UAs would >>>>>>>automatically retry all failed "sip:" >>>>>>>addresses on some P2PSIP framework, and then the two >>>>>>> >>>>>>> >>>>>addresses would >>>>> >>>>> >>>>>>>converge down the road. >>>>>>> >>>>>>>But I'm not sure how we can start out converged without just >>>>>>>confusing the user and, ultimately, hurting the SIP >>>>>>> >>>>>>> >>>>>community as a >>>>> >>>>> >>>>>>>whole -- P2P and otherwise. >>>>>>> >>>>>>>Have I missed something? Can you see a way to roll out >>>>>>> >>>>>>> >>>>>P2PSIP atop >>>>> >>>>> >>>>>>>a standard "sip:" address without appearing totally >>>>>>>broken throughout the deployment period? >>>>>>> >>>>>>>-david >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>>>>>>> >>>>>>>> >>>>>>>Behalf Of >>>>>>> >>>>>>> >>>>>>>>David A. Bryan >>>>>>>>Sent: Monday, June 05, 2006 7:29 AM >>>>>>>>To: Henning Schulzrinne >>>>>>>>Cc: David Barrett; p2p-sip at cs.columbia.edu >>>>>>>>Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>>>> >>>>>>>>I would agree, and would add a subtly different >>>>>>>> >>>>>>>> >>>>>objection that a >>>>> >>>>> >>>>>>>>traditional SIP UA will be better able to interact with >>>>>>>> >>>>>>>> >>>>>a P2PSIP >>>>> >>>>> >>>>>>>>endpoint if we have a simple "sip:" or "sips:" (however that >>>>>>>>debate hashes out). >>>>>>>> >>>>>>>>David >>>>>>>> >>>>>>>>On 6/5/06, Henning Schulzrinne wrote: >>>>>>>> >>>>>>>> >>>>>>>>>>I'd prefer not to debate the specifics at this point -- >>>>>>>>>> >>>>>>>>>> >>>>>>>if we can >>>>>>> >>>>>>> >>>>>>>>>>agree that there's some kind of "p2psip:" >>>>>>>>>> >>>>>>>>>> >>>>>>>address type, >>>>>>> >>>>>>> >>>>>>>>>>I think that's as deep as we need to get agreement >>>>>>>>>> >>>>>>>>>> >>>>>on the big >>>>> >>>>> >>>>>>>>>>picture. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>I think this is a fundamentally bad idea. I shouldn't >>>>>>>>> >>>>>>>>> >>>>>>>have to change >>>>>>> >>>>>>> >>>>>>>>>my address (and business card) just because I'm changing >>>>>>>>> >>>>>>>>> >>>>>>>some low- >>>>>>> >>>>>>> >>>>>>>>>level technical detail of how signaling requests are >>>>>>>>> >>>>>>>>> >>>>>>>routed. In any >>>>>>> >>>>>>> >>>>>>>>>event, just like many web pages are simply listed as >>>>>>>>>www.something.com (instead of http://www.something.com), I >>>>>>>>>expect that many business cards and directories will simply >>>>>>>>>contain alice at something.com. >>>>>>>>> >>>>>>>>>It's the role of protocols to make these resolution details >>>>>>>>>transparent to the user. This isn't terribly >>>>>>>>> >>>>>>>>> >>>>>difficult in this >>>>> >>>>> >>>>>>>>>particular case. >>>>>>>>> >>>>>>>>>Henning >>>>>>>>>_______________________________________________ >>>>>>>>>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 >>>>>>> >>>>>>> >>>>>>> >>>_______________________________________________ >>>p2p-sip mailing list >>>p2p-sip at cs.columbia.edu >>>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> >>> > > > From eunsoo at research.panasonic.com Tue Jun 6 07:25:16 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 06 Jun 2006 07:25:16 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <20060606010151.59450.qmail@web38512.mail.mud.yahoo.com> References: <20060606010151.59450.qmail@web38512.mail.mud.yahoo.com> Message-ID: <4485661C.5050902@research.panasonic.com> Mike Robinson wrote: > Eunsoo Sim wrote: > > >> In the MANET framework, the IP address of a mobile node does not > change. > > This is definitely incorrect to the MANET framework that I am familiar > with. > > A node may momentarily leave the network and re-join the network. > This will result in address re-assignement (or self configuration with > DAD in IPv6). OK. This is the same for a fixed node that gets offline and comes back. > > Also, two or more networks may merge/split and address reconfiguration > may take place. > OK. I guess this won't happen very often. DHT should be able to hanlde JOIN/LEAVE of nodes. In a simple scheme, IP address change is equivalent to a LEAVE and a JOIN. As long as it does not happen too often, many DHTs we know of will be able to handle it. > >> If the IP address of a mobile node changes, that's a different > story. We > >>can put such mobile devices as ordinary nodes (not participating in DHT) > >> if the P2P network contain both fixed and mobile devices. > > How would a node know apriori whether and when it supports mobility or > not since IP mobility support is function of node and network > infrastructure? > Initially the software in each device may gather information about the system like the type of the network interface or the type of device. If the network interface is wireless, the software can take a conservative decision to operate only as an ordinary node. I don't mean there is an easy and precise algorithm for this. The detailed algorithm is out of scope of our discussion or the standardization in the IETF. > Besides, the idea of making p2p sip functionality of a node dependent > on mobile-ip presence or absence sounds quite wrong to me. > I am not saying P2P SIP requires Mobile IP all the time. > Unfortunartely, I don't have time to go in lengthy debates, but > hopefully I have conveyed that support for mobile nodes is not that > simple either as is/was being made. > I don't mean supporting mobile nodes is easy always. There are different cases and we may avoid difficult problems. So we should not be scared too much about mobile nodes w.r.t. P2P SIP. But I agree with you that we should not consider the problem in general as a simple one. Thanks. Eunsoo > > > > > */Eunsoo Shim /* wrote: > > As long as the IP address of a node does not change, nothing special > needs to be done for DHT. > > In the MANET framework, the IP address of a mobile node does not > change. > > > If a mobile deivce is connected to the global Internet and Mobile > IP is > supported, nothing special needs to be done for the mobile node > participating in the DHT, either. > > If the IP address of a mobile node changes, that's a different > story. We > can put such mobile devices as ordinary nodes (not participating > in DHT) > if the P2P network contain both fixed and mobile devices. > > In my understanding, no one represents any IETF working group or any > other organization in the mailing list unless she/he claims to do so > explicitly. I don't see anyone claiming to represent MANET or any > other > WG during the discussion. > > Thanks. > > Eunsoo > > > > Mike Robinson wrote: > > Radhika Roy wrote: > > > >>> In fact, we will be working cooperating with them to complete > our work: > >>> p2pSIP Application Layer to the MANET Network Layer. > > > > What is that you refer to "our work"? Whose work are you > talking? Did IETF assign you a spokesman for MANET? > > > > Could you please update us who authorized to speak on behalf of > MANET group? > > > > By the way, ad-hoc networks have nothing to do with p2p since > p2p can run on fixed infrastructure and ad-hoc networks need not > use p2p for applications. Did it occur to you that one can run > client server applications even when network may be based on > ad-hoc network routing protocol. Supporting mobility in p2p nodes > is quite difficult contrary to what you say in your typical hand > waving style (since you would need to do reinsert your mobile > nodes in a DHT, reconfigure DHT, and update resource information > at all DHT nodes) > > > > I hope you would try to understand the issues with DHT and > mobility before you resume your periodic vacuous comments in > support of p2p sip (which almost always are devoid of any > technical input whatsoever). > > > > > > o mike > > > > > > "Roy, Radhika R." wrote: KS: > > > > To support p2pSIP for mobile nodes (if not mobile devices per > se) should > > not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has > already done > > the most difficult works in this p2p networking environment: Network > > Routing and QoS support. > > > > So, it will be rather easy to support the p2pSIP application > protocol > > that will ride over the network layer MANET protocol. > > > > In fact, we will be working cooperating with them to complete > our work: > > p2pSIP Application Layer to the MANET Network Layer. > > > > Best regards, > > Radhika R. Roy > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar > > (ksankar) > > Sent: Monday, June 05, 2006 11:43 AM > > To: David Barrett; p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > My view of the P2P-SIP world ... > > > >> 2) Does P2PSIP work on mobile devices assigned dynamic IP > addresses? > > > > Yep, definitely. Might not be that easy > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > --------------------------------- > > New Yahoo! Messenger with Voice. Call regular phones from your > PC and save big. > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > From henry at pulver.com Tue Jun 6 09:02:00 2006 From: henry at pulver.com (Henry Sinnreich) Date: Tue, 6 Jun 2006 08:02:00 -0500 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606060603.k5660mX5026061@cs.columbia.edu> Message-ID: <002901c68969$67447970$2800a8c0@DSX400> >With this in mind, here's an updated story for my vision of what a P2PSIP >1.0 UA does: Excellent scenario, except it need to be on the same LAN, just on the Internet. Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett Sent: Tuesday, June 06, 2006 1:01 AM To: 'Cullen Jennings' Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan' Subject: Re: [p2p-sip] What are we doing, question 2 Well, what I'm trying to accomplish is enunciate a vision for how the product works for a user. Once we agree upon what P2PSIP is supposed to do for the user, then I think we can more easily discuss how to make that happen. With this in mind, here's an updated story for my vision of what a P2PSIP 1.0 UA does: You and I each install a P2PSIP-enabled UA while sitting on the same LAN. I click the "Create a new network" button on my UA, and give it the name "quinthar". [1] It asks me what my name is on this network, and I say "dbarrett". [2] Your UA detects this and lists "quinthar" as one of the known networks, and "dbarrett at quinthar" as a known user. [3] You choose the "quinthar" network and click "Join network", then specify that your name is "fluffy". [4] On my UA, I see "fluffy at quinthar" is listed in as a known user. I double click on "fluffy at quinthar", and initiate a VoIP call. [5] [1] For 1.0, anyone can create a network; later it might be tied to public key encryption. [2] For 1.0, anyone can choose any name when joining a network; later each network might have an administrator. [3] For 1.0, UAs broadcast their network affiliation using IP multicast. Later there might be global network registries, special bootstrapping servers, or even a global DHT set aside to publish networks. [4] For 1.0, anyone can join any network they've discovered, or by entering the IP:port of a node on the network. [5] We've created identities, discovered each other, and initiated a SIP call -- all without ever touching a single server. Does this story basically capture the same product that you want to enable with P2PSIP? If not, can you follow the pattern above and lay out your own story? -david > -----Original Message----- > From: Cullen Jennings [mailto:fluffy at cisco.com] > Sent: Monday, June 05, 2006 5:36 PM > To: David Barrett > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] What are we doing, question 2 > > > Some of the proposal so for have come up with ways to make sip: > addresses work and make things interoperable with more traditional > sip. Clearly having interoperate would be a nice property if > possible. However, I am still lost on what we are trying to > accomplish, much less what the solutions is or if it needs a > different URL. > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > Again, I love the idea of having a single "sip:" address that "just > > works" > > for both CS and P2P SIP. Please help me understand your proposal > > better. > > > > Will I be able to print my combined CS/P2P SIP address on a > > business card, > > hand it to you, and have you type it into your SIP UA and get an > > expected > > result (a valid connection, if it's P2PSIP aware, or a message saying > > "unsupported address type" if not)? If so, what might that address > > look > > like? > > > > I've proposed your business card might say: > > > > sip:@ > > > > Or > > > > p2psip:[@] [1] > > > > If instead we only use the first format, how does a UA figure out > > which DHT > > the address is registered with, and how does it connect to that > > DHT? I can > > imagine URI attributes: > > > > sip:@[?dht=] > > > > And I think this is a great solution. But I don't understand how a > > human > > would input "header elements" to a UA. Am I misunderstanding the > > proposal? > > > > -david > > > > [1] I've proposed is [@], and that it's > > optional (defaulting to some global DHT if unspecified). But the > > precise > > syntax is unimportant. What is important is that the address contain > > whatever information is necessary to connect to a given DHT. > > > >> -----Original Message----- > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > >> Sent: Monday, June 05, 2006 10:22 AM > >> To: David A. Bryan > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > >> Subject: RE: [p2p-sip] What are we doing, question 2 > >> > >> Agreed. If we, in-principle, see the need for the > >> p2psip:[@@[]], we can make it as > >> harmless > >> as possible - a set of header elements or a set of URI parameter > >> is an > >> excellent choice. > >> > >> I like header element better - something like : > >> Additional-Format:P2P > >> P2P-DHTName:,,... > >> P2P-BootStrap:,... > >> > >> Cheers > >> > >> > >>> -----Original Message----- > >>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > >>> Behalf Of David A. Bryan > >>> Sent: Monday, June 05, 2006 10:09 AM > >>> To: Krishna Sankar (ksankar) > >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>> > >>> If we have a p2psip: address, what does a non-P2P SIP > >>> endpoint do with it? On the otherhand, a regular sip: address > >>> can go from a UA to a proxy that is more likely to be able to > >>> do something useful (forward it to a p2p domain)? See the > >>> draft Enrico and I did > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > >>> > >>> We can use maybe use something else in the messages -- a URI > >>> param or a header perhaps -- to distinguish P2P from regular > >>> SIP where needed, but I think we should ensure that a URI is > >>> as backward compliant as possible. > >>> > >>> --David Bryan > >>> > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > >>>> David, > >>>> > >>>> You have a valid point making p2p-sip explicit for all than > >>>> implicit in the UAs who understand it. > >>>> a) I mulled it over and do not see any other > >>> way, as a 1.0 > >>>> requirement. i.e. we do need a p2p-sip protocol designator > >>> somewhere > >>>> to make it explicit. But not necessarily in one's vcard. > >>>> b) We could make the client responsible for trying the > >>>> generic and then p2p:. > >>>> c) Going back to putting p2psip in one's > >>> vcard, what does > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > >>> that one will > >>>> be part of a p2psip as and when available ? > >>>> d) Isn't p2psip situational ? i.e. when one is > >>> at home, may > >>>> be, one will be part of the p2psip provided by the service > >>> provider or > >>>> even the home network; but when one is at work, one becomes > >>> part of a > >>>> server based larger sip substrate. > >>>> What about an emergency worker who moves between > >>>> different p2psip and sip networks ? > >>>> > >>>> What about a mobile worker who wanders from > >>> Starbucks > >>>> network to airport network to .. All might have different p2psip > >>>> mechanisms or even a combination of p2psip and server based sip. > >>>> > >>>> May be I got it all wrong (mice crunching cats are > >>> the norm of > >>>> the day than galloping stallions) - very possible ... > >>>> Cheers > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: p2p-sip-bounces at cs.columbia.edu > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > >>> David Barrett > >>>>> Sent: Monday, June 05, 2006 8:58 AM > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > >>>>> Cc: p2p-sip at cs.columbia.edu > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>>>> > >>>>> Ok, I'll totally agree that it'd be nice to hide the details of > >>>>> P2PSIP behind a standard "sip:" address (expressed or > >>> implied). I > >>>>> just haven't envisioned how to accomplish this in > >>> conjunction with > >>>>> the other requirements, and I'm trying to avoid proposing what I > >>>>> can't figure out how to build. > >>>>> > >>>>> The problem I see isn't one of technology, but usability issues > >>>>> caused in the adoption period. Clearly, P2PSIP isn't going to > >>>>> happen overnight. > >>>>> There will be period of years where it is slowly rolled > >>> out to SIP > >>>>> UAs. And during this period, I think it's important for a UA to > >>>>> differentiate between invalid SIP addresses, and P2PSIP addresses > >>>>> that it doesn't know how to handle. > >>>>> > >>>>> For example, let's assume I put my P2PSIP address on a > >>> business card > >>>>> as "sip:dbarrett at quinthar.com" (or just > >>> "dbarrett at quinthar.com" with > >>>>> the "sip:" > >>>>> implied). A P2PSIP-aware UA might first look for a > >>> traditional SIP > >>>>> proxy at "quinthar.com" and then, not finding one, use some > >>>>> DHT-based mechanism. I love that idea. > >>>>> > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > >>> address is > >>>>> valid and supported, but broken. I don't love this idea. > >>>>> > >>>>> Thus I'm proposing, at least at the start while P2PSIP is getting > >>>>> its legs, we use "p2psip:". A P2PSIP-aware UA > >>> will work, > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this > >>>>> address type". The blame is placed on the UA (where it > >>> should be), > >>>>> rather than the address. > >>>>> > >>>>> Maybe in the future, once P2PSIP is more established, UAs would > >>>>> automatically retry all failed "sip:" > >>>>> addresses on some P2PSIP framework, and then the two > >>> addresses would > >>>>> converge down the road. > >>>>> > >>>>> But I'm not sure how we can start out converged without just > >>>>> confusing the user and, ultimately, hurting the SIP > >>> community as a > >>>>> whole -- P2P and otherwise. > >>>>> > >>>>> Have I missed something? Can you see a way to roll out > >>> P2PSIP atop > >>>>> a standard "sip:" address without appearing totally > >>>>> broken throughout the deployment period? > >>>>> > >>>>> -david > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > >>>>> Behalf Of > >>>>>> David A. Bryan > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > >>>>>> To: Henning Schulzrinne > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > >>>>>> > >>>>>> I would agree, and would add a subtly different > >>> objection that a > >>>>>> traditional SIP UA will be better able to interact with > >>> a P2PSIP > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that > >>>>>> debate hashes out). > >>>>>> > >>>>>> David > >>>>>> > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > >>>>>>>> I'd prefer not to debate the specifics at this point -- > >>>>> if we can > >>>>>>>> agree that there's some kind of "p2psip:" > >>>>> address type, > >>>>>>>> I think that's as deep as we need to get agreement > >>> on the big > >>>>>>>> picture. > >>>>>>> > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > >>>>> have to change > >>>>>>> my address (and business card) just because I'm changing > >>>>> some low- > >>>>>>> level technical detail of how signaling requests are > >>>>> routed. In any > >>>>>>> event, just like many web pages are simply listed as > >>>>>>> www.something.com (instead of http://www.something.com), I > >>>>>>> expect that many business cards and directories will simply > >>>>>>> contain alice at something.com. > >>>>>>> > >>>>>>> It's the role of protocols to make these resolution details > >>>>>>> transparent to the user. This isn't terribly > >>> difficult in this > >>>>>>> particular case. > >>>>>>> > >>>>>>> Henning > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>>> > >>> > > > > _______________________________________________ > > 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 RADHIKA.R.ROY at saic.com Tue Jun 6 10:48:29 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Tue, 6 Jun 2006 10:48:29 -0400 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <62D92A9A02BCC845B202323D49A48426230E09@0591-ITS-EXMP02.us.saic.com> Inline [RRR] -----Original Message----- From: Peter Pan [mailto:huang-ming.pan at comcast.net] Sent: Monday, June 05, 2006 7:20 PM To: Mike Robinson; Roy, Radhika R.; Krishna Sankar (ksankar) Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 Won't mobility be taken care transparently (w/o ip change) by routers supporting 802.11f, rfc 3344 and related standards? IP change sounds chaotic (if not catastrophic) to DHT. [RRR] Yes because so far 3G has used SIP as it is. I also think that this can eventually be addressed in DHT. Are MANET and IP mobility mutual exclusive? [RRR] I would think so. Peter From RADHIKA.R.ROY at saic.com Tue Jun 6 10:28:49 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Tue, 6 Jun 2006 10:28:49 -0400 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <62D92A9A02BCC845B202323D49A48426230E08@0591-ITS-EXMP02.us.saic.com> Inline [RRR] _____ From: Brijesh Kumar [mailto:bk9001 at gmail.com] Sent: Monday, June 05, 2006 5:51 PM To: Roy, Radhika R. Cc: Krishna Sankar (ksankar); p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 On 6/5/06, Roy, Radhika R. > wrote: KS: To support p2pSIP for mobile nodes (if not mobile devices per se) should not be difficult. I beg to differ with above assessment. [RRR] The mobile ad hoc network (MANET) WG has solved (or is solving) the most complex problems that p2pSIP ever can imagine. That is, a MANET network is mobile and its topology is ad hoc. It is forced to use p2p schemes. So, they have addressed two serious problems at the same time: 1. Ad hoc mobile network whose topology changes as each mobile node moves with different speeds (e.g., vehicles move at the speed of 10 to 100 miles hours, unmanned airborne vehicles may move at the speed of 200 to 500 miles per hour) in different directions and 2. MANET is forced to address p2p networking schemes because all nodes are mobile. [RRR] P2pSIP is not considering the mobility assuming that the lower network will be able to take care of the mobility, and the p2pSIP is hoping that, like normal SIP, it will also be transparent to mobility, and no special works are needed. For example, normal SIP is being used in 3G cellular wireless networks. However, MANET is inherently very complexly and is different from those 3G networks because it, unlike 3G, force to use p2p schemes. [RRR] The idea is this: To use normal SIP over MANET is far from ideal as normal SIP is not suitable for p2p schemes. However, p2pSIP will be ideal for MANET as both of them are used in p2p environment. Actually, a change in the IP address would result in the change in a node's identity. Also, a number of DHT configuraion algorithms (specially hierarchical organization) try to optimize overlay organization on the basis of a node's geographical location with respect to certain reference points. That has major implications on a DHT's operation since it may require DHT reconfiguration as well as affect where a node will be placed in the overlay. [RRR] The address changes in p2p environments in the IP network due to mobility and the complexity of routing where the network topology are being changed very frequently are being solved successfully in MANET in p2p environment. As I indicated above, MANET has a wealth knowledge how to address those, and we, being in the p2pSIP WG, do not need to spend energy on this. [RRR] That is why I am extremely hopeful that it will not be difficult to solve mobility problem for the p2pSIP once we develop the p2pSIP standard at the application layer. I haven't seen many papers that have analyzed large scale networks for the effect of node identity change due to node mobility in P2P networks so it is not clear to me why would you say that it is not "difficult". [RRR] See above. The most complex problems of mobility in p2p schemes are in the lower network layer that MANET is addressing as you have explained above (e.g., IP network address changes). I also add another one: Topology of the network itself changes. [RRR] Once p2pSIP using all its features including DHT is standardized, there are is not much serious complex problems to solve like what MANET WG has been doing. I usually call these problems as some minor "patch" works (sorry for lack of proper words) for standardization. --bk IETF Mobile Ad Hoc Network (MANET) WG has already done the most difficult works in this p2p networking environment: Network Routing and QoS support. So, it will be rather easy to support the p2pSIP application protocol that will ride over the network layer MANET protocol. In fact, we will be working cooperating with them to complete our work: p2pSIP Application Layer to the MANET Network Layer. Best regards, Radhika R. Roy -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu ] On Behalf Of Krishna Sankar (ksankar) Sent: Monday, June 05, 2006 11:43 AM To: David Barrett; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 My view of the P2P-SIP world ... > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? Yep, definitely. Might not be that easy _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060606/d666a0a5/attachment-0001.html From RADHIKA.R.ROY at saic.com Tue Jun 6 11:10:38 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Tue, 6 Jun 2006 11:10:38 -0400 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <62D92A9A02BCC845B202323D49A48426230E0A@0591-ITS-EXMP02.us.saic.com> Inline [RRR] _____ From: Mike Robinson [mailto:mike_robnson at yahoo.com] Sent: Monday, June 05, 2006 9:02 PM To: Eunsoo Shim Cc: Roy, Radhika R.; Krishna Sankar (ksankar); p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 How would a node know apriori whether and when it supports mobility or not since IP mobility support is function of node and network infrastructure? [RRR] Let us wait for this as soon as we complete our p2pSIP work first. [RRR] The second question is this: 1. Do you want to solve the mobility in the context of the public Internet where it not apriori known? and 2. Or, do you want to address this problem as an enterprise network where it is apriori known? Besides, the idea of making p2p sip functionality of a node dependent on mobile-ip presence or absence sounds quite wrong to me. [RRR] Probably not. I think p2pSIP is following the same what is being used in normal SIP. That is, p2pSIP is transparent to mobility. Unfortunartely, I don't have time to go in lengthy debates, but hopefully I have conveyed that support for mobile nodes is not that simple either as is/was being made. [RRR] It depends. The complexity of the problems is not what MANET is solving now for mobility with different speeds and in different directions as well as for ad hoc networking where the network topology is always changing. [RRR] In some cases, the simple non-p2p-SIP, like 3G network, is being tried to be used over the p2p MNAET network. It is far from the ideal as there are so many limitations to get all problems solved. [RRR] In the same token, p2pSIP can also be used over the p2p MANET. Of course, there will be some works need to be done for standardization, but these are not overly complex problems that we have start to inventing some fundamental new wheels. Let us not address this in p2pSIP WG. o mike -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060606/69b1fe6f/attachment.html From huang-ming.pan at comcast.net Tue Jun 6 11:32:31 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Tue, 6 Jun 2006 08:32:31 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606060710.k567AZX5021391@cs.columbia.edu> Message-ID: <003701c6897e$6e424800$6400a8c0@comcast.net> I wonder why interoperation between traditional and P2P SIP UAs is a worry when P2P SIP UAs have SIP stack inside. The interoperation seems tiny compared with most other P2P issues. I wonder too why security cannot be in 1.0 when security seems the paramount in modern p2p networks (even unencrypted file sharing networks use some way or other to assure file integrity), SPKI technology is growing rapidly (you can say Skype uses it) and voip in 21th century without security seems like a homework (or a joke). Peter ----- Original Message ----- From: "David Barrett" To: "'Dean Willis'" Cc: ; "'David A. Bryan'" Sent: Tuesday, June 06, 2006 12:10 AM Subject: Re: [p2p-sip] What are we doing, question 2 > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis at softarmor.com] > > > > If you intend your P2PSIP overlay to be useful, you'd better have a > > resolver/introducer/rendezvous/whatever server at quinthar.com to > > make this route resolve for a stadnard SIP client. > > > > Otherwise, we're not defining P2P uses of SIP, we're defining some > > new protocol that, well, isn't SIP. > > I totally agree that in the long term, the gulf between P2P and > client/server SIP needs bridging. But I'm not sure it *needs* to be done in > v1.0 of P2PSIP. I think useful work can be done on a v1.0 P2PSIP standard > that doesn't address this problem. > > For example, in my previous email, I sketched out a vision for how P2PSIP > could be used in an environment totally devoid of client/server SIP. If > that's the best we can do for v1.0 P2PSIP, I count that as a success even > though it means your CS-only UA couldn't call my P2P-only UA because I > haven't registered an address on a traditional SIP proxy. > > However, it's easy to imagine that my P2P UA could call your CS UA: I click > "Add a buddy" and enter "sip:dean.willis at softarmor.com", and my P2P UA > recognizes it as a client/server address and treats it accordingly. > > Likewise, the reverse is also easy to imagine: I click an "Add an address" > button and type "sip:dbarrett at softarmor.com", and register my UA on your > traditional SIP server. > > And finally, it's easy to imagine that I (the founder of the 'quinthar' DHT) > enable non-P2P UAs to contact P2P users on my DHT by putting up a P2P > gateway at "quinthar.com". Thus when you type "sip:dbarrett at quinthar.com" > into your non-P2P UA, your UA treats my gateway as if it's a standard SIP > proxy. But when someone types "sip:dbarrett at quinthar.com" into a > P2P-enabled UA, it uses my gateway as a bootstrapping server to join the > "quinthar" DHT, and then never talks to it again. > > Basically, for v1.0, it seems useful and easiest to not worry too much about > interoperation between traditional and P2P SIP UAs. There exist a variety > of options to bridge the gap down the road. > > -david > > > From ksankar at cisco.com Tue Jun 6 11:38:44 2006 From: ksankar at cisco.com (Krishna Sankar (ksankar)) Date: Tue, 6 Jun 2006 08:38:44 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFF38@xmb-sjc-219.amer.cisco.com> Yep, works for me at higher level. Comments ... > [3] For 1.0, UAs broadcast their network affiliation using IP multicast. We also need to add that discovery would be done thru IP multicast. Can we say we will leverage existing DNS mechanism - specifically use the mDNS primitives for this ? That way we do not have to work on another multicast format, port number and associated mechanisms. We also need to specify couple of DNS record types and appropriate formats. May be we can leverage the currently available record types and formats. Still prefer the URI sip:@[?dht=]. May be we will say, the FQN for fluffy at quinthar is actually sip:fluffy at quinthar[[@]] Should add some form of security mechanism - at least a key substrate as a trust bootstrap and encryption as needed. May be TLS is enough. > -----Original Message----- > From: David Barrett [mailto:dbarrett at quinthar.com] > Sent: Monday, June 05, 2006 11:01 PM > To: Cullen Jennings (fluffy) > Cc: Krishna Sankar (ksankar); 'David A. Bryan'; > p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > Well, what I'm trying to accomplish is enunciate a vision for > how the product works for a user. Once we agree upon what > P2PSIP is supposed to do for the user, then I think we can > more easily discuss how to make that happen. > > With this in mind, here's an updated story for my vision of > what a P2PSIP 1.0 UA does: > > You and I each install a P2PSIP-enabled UA while sitting on > the same LAN. I click the "Create a new network" button on > my UA, and give it the name "quinthar". [1] It asks me what > my name is on this network, and I say "dbarrett". [2] Your UA > detects this and lists "quinthar" as one of the known > networks, and "dbarrett at quinthar" as a known user. [3] You > choose the "quinthar" network and click "Join network", then > specify that your name is "fluffy". [4] On my UA, I see > "fluffy at quinthar" is listed in as a known user. I double > click on "fluffy at quinthar", and initiate a VoIP call. [5] > > [1] For 1.0, anyone can create a network; later it might be > tied to public key encryption. > [2] For 1.0, anyone can choose any name when joining a > network; later each network might have an administrator. > [3] For 1.0, UAs broadcast their network affiliation using IP > multicast. > Later there might be global network registries, special > bootstrapping servers, or even a global DHT set aside to > publish networks. > [4] For 1.0, anyone can join any network they've discovered, > or by entering the IP:port of a node on the network. > [5] We've created identities, discovered each other, and > initiated a SIP call -- all without ever touching a single server. > > > Does this story basically capture the same product that you > want to enable with P2PSIP? If not, can you follow the > pattern above and lay out your own story? > > -david > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy at cisco.com] > > Sent: Monday, June 05, 2006 5:36 PM > > To: David Barrett > > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; > > p2p-sip at cs.columbia.edu > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > Some of the proposal so for have come up with ways to make sip: > > addresses work and make things interoperable with more traditional > > sip. Clearly having interoperate would be a nice property > if possible. > > However, I am still lost on what we are trying to accomplish, much > > less what the solutions is or if it needs a different URL. > > > > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > > > Again, I love the idea of having a single "sip:" address > that "just > > > works" > > > for both CS and P2P SIP. Please help me understand your proposal > > > better. > > > > > > Will I be able to print my combined CS/P2P SIP address on > a business > > > card, hand it to you, and have you type it into your SIP > UA and get > > > an expected result (a valid connection, if it's P2PSIP > aware, or a > > > message saying "unsupported address type" if not)? If so, what > > > might that address look like? > > > > > > I've proposed your business card might say: > > > > > > sip:@ > > > > > > Or > > > > > > p2psip:[@] [1] > > > > > > If instead we only use the first format, how does a UA figure out > > > which DHT the address is registered with, and how does it > connect to > > > that DHT? I can imagine URI attributes: > > > > > > sip:@[?dht=] > > > > > > And I think this is a great solution. But I don't > understand how a > > > human would input "header elements" to a UA. Am I > misunderstanding > > > the proposal? > > > > > > -david > > > > > > [1] I've proposed is [@], and that > > > it's optional (defaulting to some global DHT if > unspecified). But > > > the precise syntax is unimportant. What is important is that the > > > address contain whatever information is necessary to connect to a > > > given DHT. > > > > > >> -----Original Message----- > > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > >> Sent: Monday, June 05, 2006 10:22 AM > > >> To: David A. Bryan > > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > >> Subject: RE: [p2p-sip] What are we doing, question 2 > > >> > > >> Agreed. If we, in-principle, see the need for the > > >> p2psip:[@@[]], we can make it as > > >> harmless as possible - a set of header elements or a set of URI > > >> parameter is an excellent choice. > > >> > > >> I like header element better - something like : > > >> Additional-Format:P2P > > >> P2P-DHTName:,,... > > >> P2P-BootStrap:,... > > >> > > >> Cheers > > >> > > >> > > >>> -----Original Message----- > > >>> From: davidbryan at gmail.com > [mailto:davidbryan at gmail.com] On Behalf > > >>> Of David A. Bryan > > >>> Sent: Monday, June 05, 2006 10:09 AM > > >>> To: Krishna Sankar (ksankar) > > >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > > >>> > > >>> If we have a p2psip: address, what does a non-P2P SIP > endpoint do > > >>> with it? On the otherhand, a regular sip: address can > go from a UA > > >>> to a proxy that is more likely to be able to do > something useful > > >>> (forward it to a p2p domain)? See the draft Enrico and I did > > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > >>> > > >>> We can use maybe use something else in the messages -- > a URI param > > >>> or a header perhaps -- to distinguish P2P from regular > SIP where > > >>> needed, but I think we should ensure that a URI is as backward > > >>> compliant as possible. > > >>> > > >>> --David Bryan > > >>> > > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > > >>>> David, > > >>>> > > >>>> You have a valid point making p2p-sip explicit for all > > >>>> than implicit in the UAs who understand it. > > >>>> a) I mulled it over and do not see any other > > >>> way, as a 1.0 > > >>>> requirement. i.e. we do need a p2p-sip protocol designator > > >>> somewhere > > >>>> to make it explicit. But not necessarily in one's vcard. > > >>>> b) We could make the client responsible > for trying the > > >>>> generic and then p2p:. > > >>>> c) Going back to putting p2psip in one's > > >>> vcard, what does > > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > > >>> that one will > > >>>> be part of a p2psip as and when available ? > > >>>> d) Isn't p2psip situational ? i.e. when one is > > >>> at home, may > > >>>> be, one will be part of the p2psip provided by the service > > >>> provider or > > >>>> even the home network; but when one is at work, one becomes > > >>> part of a > > >>>> server based larger sip substrate. > > >>>> What about an emergency worker who > moves between > > >>>> different p2psip and sip networks ? > > >>>> > > >>>> What about a mobile worker who wanders from > > >>> Starbucks > > >>>> network to airport network to .. All might have > different p2psip > > >>>> mechanisms or even a combination of p2psip and server > based sip. > > >>>> > > >>>> May be I got it all wrong (mice crunching cats are > > >>> the norm of > > >>>> the day than galloping stallions) - very possible ... > > >>>> Cheers > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: p2p-sip-bounces at cs.columbia.edu > > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > > >>> David Barrett > > >>>>> Sent: Monday, June 05, 2006 8:58 AM > > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > > >>>>> Cc: p2p-sip at cs.columbia.edu > > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > >>>>> > > >>>>> Ok, I'll totally agree that it'd be nice to hide the > details of > > >>>>> P2PSIP behind a standard "sip:" address (expressed or > > >>> implied). I > > >>>>> just haven't envisioned how to accomplish this in > > >>> conjunction with > > >>>>> the other requirements, and I'm trying to avoid > proposing what I > > >>>>> can't figure out how to build. > > >>>>> > > >>>>> The problem I see isn't one of technology, but > usability issues > > >>>>> caused in the adoption period. Clearly, P2PSIP isn't > going to > > >>>>> happen overnight. > > >>>>> There will be period of years where it is slowly rolled > > >>> out to SIP > > >>>>> UAs. And during this period, I think it's important > for a UA to > > >>>>> differentiate between invalid SIP addresses, and P2PSIP > > >>>>> addresses that it doesn't know how to handle. > > >>>>> > > >>>>> For example, let's assume I put my P2PSIP address on a > > >>> business card > > >>>>> as "sip:dbarrett at quinthar.com" (or just > > >>> "dbarrett at quinthar.com" with > > >>>>> the "sip:" > > >>>>> implied). A P2PSIP-aware UA might first look for a > > >>> traditional SIP > > >>>>> proxy at "quinthar.com" and then, not finding one, use some > > >>>>> DHT-based mechanism. I love that idea. > > >>>>> > > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > > >>> address is > > >>>>> valid and supported, but broken. I don't love this idea. > > >>>>> > > >>>>> Thus I'm proposing, at least at the start while P2PSIP is > > >>>>> getting its legs, we use "p2psip:". A > P2PSIP-aware > > >>>>> UA > > >>> will work, > > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this > > >>>>> address type". The blame is placed on the UA (where it > > >>> should be), > > >>>>> rather than the address. > > >>>>> > > >>>>> Maybe in the future, once P2PSIP is more established, > UAs would > > >>>>> automatically retry all failed "sip:" > > >>>>> addresses on some P2PSIP framework, and then the two > > >>> addresses would > > >>>>> converge down the road. > > >>>>> > > >>>>> But I'm not sure how we can start out converged without just > > >>>>> confusing the user and, ultimately, hurting the SIP > > >>> community as a > > >>>>> whole -- P2P and otherwise. > > >>>>> > > >>>>> Have I missed something? Can you see a way to roll out > > >>> P2PSIP atop > > >>>>> a standard "sip:" address without > appearing totally > > >>>>> broken throughout the deployment period? > > >>>>> > > >>>>> -david > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > >>>>> Behalf Of > > >>>>>> David A. Bryan > > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > > >>>>>> To: Henning Schulzrinne > > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > >>>>>> > > >>>>>> I would agree, and would add a subtly different > > >>> objection that a > > >>>>>> traditional SIP UA will be better able to interact with > > >>> a P2PSIP > > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that > > >>>>>> debate hashes out). > > >>>>>> > > >>>>>> David > > >>>>>> > > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > > >>>>>>>> I'd prefer not to debate the specifics at this point -- > > >>>>> if we can > > >>>>>>>> agree that there's some kind of "p2psip:" > > >>>>> address type, > > >>>>>>>> I think that's as deep as we need to get agreement > > >>> on the big > > >>>>>>>> picture. > > >>>>>>> > > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > > >>>>> have to change > > >>>>>>> my address (and business card) just because I'm changing > > >>>>> some low- > > >>>>>>> level technical detail of how signaling requests are > > >>>>> routed. In any > > >>>>>>> event, just like many web pages are simply listed as > > >>>>>>> www.something.com (instead of http://www.something.com), I > > >>>>>>> expect that many business cards and directories will simply > > >>>>>>> contain alice at something.com. > > >>>>>>> > > >>>>>>> It's the role of protocols to make these resolution details > > >>>>>>> transparent to the user. This isn't terribly > > >>> difficult in this > > >>>>>>> particular case. > > >>>>>>> > > >>>>>>> Henning > > >>>>>>> _______________________________________________ > > >>>>>>> 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 > > >>>>> > > >>>> > > >>> > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From huang-ming.pan at comcast.net Tue Jun 6 11:39:24 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Tue, 6 Jun 2006 08:39:24 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606060008.AFY53379@redwood.research.panasonic.com> <448562BA.1040401@research.panasonic.com> Message-ID: <004201c6897f$63d1e5f0$6400a8c0@comcast.net> > >Once you're a member of the DHT, then you needn't talk with DHT proxy node > >ever again. And if you can't or don't want to use the DHT, just send a > >normal INVITE to the DHT proxy and it'll return as if it's a standard CS > >proxy. > > > >Is this right? If so, I think I like it. > > > That is right. Me am afraid NOT RIGHT, unless validity of at least one SN (or DHT proxy) in cached SN list can be guaranteed (which usually cannot be, unless networks install persist fault-tolerant SNs). From eunsoo at research.panasonic.com Tue Jun 6 11:46:37 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 06 Jun 2006 11:46:37 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <004201c6897f$63d1e5f0$6400a8c0@comcast.net> References: <200606060008.AFY53379@redwood.research.panasonic.com> <448562BA.1040401@research.panasonic.com> <004201c6897f$63d1e5f0$6400a8c0@comcast.net> Message-ID: <4485A35D.5060702@research.panasonic.com> Peter Pan wrote: >>> Once you're a member of the DHT, then you needn't talk with DHT proxy > node >>> ever again. And if you can't or don't want to use the DHT, just send a >>> normal INVITE to the DHT proxy and it'll return as if it's a standard CS >>> proxy. >>> >>> Is this right? If so, I think I like it. >>> >> That is right. > > Me am afraid NOT RIGHT, unless validity of at least one SN (or DHT proxy) in > cached SN list can be guaranteed (which usually cannot be, unless networks > install persist fault-tolerant SNs). > I think the above was based on assumption that some of the neighbors are online. If the neighbors in the DHT routing table and the peers in the cache are all offline, now the peer is back to the point where it needs to do bootstrapping from scratch. If the peer needs to talk to the Bootstrap Server for bootstrapping, it got to do so. Thanks. Eunsoo From huang-ming.pan at comcast.net Tue Jun 6 11:50:37 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Tue, 6 Jun 2006 08:50:37 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606060008.AFY53379@redwood.research.panasonic.com> <448562BA.1040401@research.panasonic.com> <004201c6897f$63d1e5f0$6400a8c0@comcast.net> <4485A35D.5060702@research.panasonic.com> Message-ID: <005901c68980$f4a28a70$6400a8c0@comcast.net> > >>> Once you're a member of the DHT, then you needn't talk with DHT proxy > > node > >>> ever again. And if you can't or don't want to use the DHT, just send a > >>> normal INVITE to the DHT proxy and it'll return as if it's a standard CS > >>> proxy. > >>> > >>> Is this right? If so, I think I like it. > >>> > >> That is right. > > > > Me am afraid NOT RIGHT, unless validity of at least one SN (or DHT proxy) in > > cached SN list can be guaranteed (which usually cannot be, unless networks > > install persist fault-tolerant SNs). > > > > I think the above was based on assumption that some of the neighbors are > online. > If the neighbors in the DHT routing table and the peers in the cache are > all offline, now the peer is back to the point where it needs to do > bootstrapping from scratch. If the peer needs to talk to the Bootstrap > Server for bootstrapping, it got to do so. > Thanks. > In quality service networks for commercial purpose, the assumption seems risky :) From RADHIKA.R.ROY at saic.com Tue Jun 6 09:47:44 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Tue, 6 Jun 2006 09:47:44 -0400 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <62D92A9A02BCC845B202323D49A48426230E07@0591-ITS-EXMP02.us.saic.com> Mike: MANET WG is there in the IETF, and you are advised to contact them. Every group has its own charter and you are welcome to provide technical comments as you did here. However, I am not sure what your point is in saying this: What is that you refer to "our work"? Whose work are you talking? Did IETF assign you a spokesman for MANET? In this context our work is this: p2pSIP works. Is this clear to you? More are inline [RRR]. Best regards, Radhika R. Roy _____ From: mike_robnson at yahoo.com [mailto:mike_robnson at yahoo.com] Sent: Monday, June 05, 2006 5:40 PM To: Roy, Radhika R.; Krishna Sankar (ksankar) Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 Radhika Roy wrote: >>In fact, we will be working cooperating with them to complete our work: >> p2pSIP Application Layer to the MANET Network Layer. What is that you refer to "our work"? Whose work are you talking? [RRR] p2pSIP work. Is this clear to you? Did IETF assign you a spokesman for MANET? [RRR] Do I need to take your permission to refer to MANET work? Do I need to take MANET WG's permission to refer their work? Could you please update us who authorized to speak on behalf of MANET group? [RRR] See above. It speaks for itself. You can got to MANET WG, and tell them that I did not take their permission to refer MANET's works. By the way, ad-hoc networks have nothing to do with p2p since p2p can run on fixed infrastructure and ad-hoc networks need not use p2p for applications. [RRR] Who told you so for mobile nodes? A fixed network can use both p2p and non-p2p applications. A mobile ad hoc network does not have any choice, but it is forced to use p2p schemes. Is this clear to you? Did it occur to you that one can run client server applications even when network may be based on ad-hoc network routing protocol. Supporting mobility in p2p nodes is quite difficult contrary to what you say in your typical hand waving style (since you would need to do reinsert your mobile nodes in a DHT, reconfigure DHT, and update resource information at all DHT nodes) [RRR] Are you being technically authorized to speak for the MANET WG? Did you take the permission from the MANET WG before providing your tutorial on MANET? Did you read all the routing protocols and resources reservation that MANET WG is standardizing? [RRR] Did you ever understand what DHT is trying to solve and what MANET WG's routing protocols and resources reservation are trying to address, and how they will eventually need to be correlated in the mobile network's p2p environment when people need to solve problems from the application layer to the lower network layer without using the so called proprietary solutions? [RRR} Do you understand the differences between the p2p applications vs. p2p routing protocols in mobile ad hoc network and how much works are needed to forge them when both p2pSIP will be used over the p2p MANET network? Or, do you like that p2pSIP WG will also address lower network routing protocols for the p2p mobile network? I hope you would try to understand the issues with DHT and mobility before you resume your periodic vacuous comments in support of p2p sip (which almost always are devoid of any technical input whatsoever). [RRR} Hope that you can read more on MANET routing protocols and then try to relate the DHT and other things. Is this clear to you? o mike "Roy, Radhika R." wrote: KS: To support p2pSIP for mobile nodes (if not mobile devices per se) should not be difficult. IETF Mobile Ad Hoc Network (MANET) WG has already done the most difficult works in this p2p networking environment: Network Routing and QoS support. So, it will be rather easy to support the p2pSIP application protocol that will ride over the network layer MANET protocol. In fact, we will be working cooperating with them to complete our work: p2pSIP Application Layer to the MANET Network Layer. Best regards, Radhika R. Roy -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Krishna Sankar (ksankar) Sent: Monday, June 05, 2006 11:43 AM To: David Barrett; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] What are we doing, question 2 My view of the P2P-SIP world ... > 2) Does P2PSIP work on mobile devices assigned dynamic IP addresses? Yep, definitely. Might not be that easy _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip _____ New Yahoo! Messenger with Voice. Call regular phones from your PC and save big. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060606/c6025330/attachment.html From dbarrett at quinthar.com Tue Jun 6 13:03:25 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 6 Jun 2006 10:03:25 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003701c6897e$6e424800$6400a8c0@comcast.net> Message-ID: <200606061703.k56H3UX5027106@cs.columbia.edu> I totally agree they're important and not difficult. But they're nonzero effort (discussion, documentation, review, standardization, implementation, testing, verification, etc, etc.) and we need to focus on the smallest possible set of features in order to make headway. Once P2PSIP v1.0 is established, then these are critical priorities for v2.0. -david > -----Original Message----- > From: Peter Pan [mailto:huang-ming.pan at comcast.net] > Sent: Tuesday, June 06, 2006 8:33 AM > To: David Barrett; 'Dean Willis' > Cc: p2p-sip at cs.columbia.edu; 'David A. Bryan' > Subject: Re: [p2p-sip] What are we doing, question 2 > > I wonder why interoperation between traditional and P2P SIP UAs is a worry > when P2P SIP UAs have SIP stack inside. The interoperation seems tiny > compared with most other P2P issues. > > I wonder too why security cannot be in 1.0 when security seems the > paramount > in modern p2p networks (even unencrypted file sharing networks use some > way > or other to assure file integrity), SPKI technology is growing rapidly > (you > can say Skype uses it) and voip in 21th century without security seems > like > a homework (or a joke). > > Peter > ----- Original Message ----- > From: "David Barrett" > To: "'Dean Willis'" > Cc: ; "'David A. Bryan'" > Sent: Tuesday, June 06, 2006 12:10 AM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis at softarmor.com] > > > > > > If you intend your P2PSIP overlay to be useful, you'd better have a > > > resolver/introducer/rendezvous/whatever server at quinthar.com to > > > make this route resolve for a stadnard SIP client. > > > > > > Otherwise, we're not defining P2P uses of SIP, we're defining some > > > new protocol that, well, isn't SIP. > > > > I totally agree that in the long term, the gulf between P2P and > > client/server SIP needs bridging. But I'm not sure it *needs* to be > done > in > > v1.0 of P2PSIP. I think useful work can be done on a v1.0 P2PSIP > standard > > that doesn't address this problem. > > > > For example, in my previous email, I sketched out a vision for how > P2PSIP > > could be used in an environment totally devoid of client/server SIP. If > > that's the best we can do for v1.0 P2PSIP, I count that as a success > even > > though it means your CS-only UA couldn't call my P2P-only UA because I > > haven't registered an address on a traditional SIP proxy. > > > > However, it's easy to imagine that my P2P UA could call your CS UA: I > click > > "Add a buddy" and enter "sip:dean.willis at softarmor.com", and my P2P UA > > recognizes it as a client/server address and treats it accordingly. > > > > Likewise, the reverse is also easy to imagine: I click an "Add an > address" > > button and type "sip:dbarrett at softarmor.com", and register my UA on your > > traditional SIP server. > > > > And finally, it's easy to imagine that I (the founder of the 'quinthar' > DHT) > > enable non-P2P UAs to contact P2P users on my DHT by putting up a P2P > > gateway at "quinthar.com". Thus when you type > "sip:dbarrett at quinthar.com" > > into your non-P2P UA, your UA treats my gateway as if it's a standard > SIP > > proxy. But when someone types "sip:dbarrett at quinthar.com" into a > > P2P-enabled UA, it uses my gateway as a bootstrapping server to join the > > "quinthar" DHT, and then never talks to it again. > > > > Basically, for v1.0, it seems useful and easiest to not worry too much > about > > interoperation between traditional and P2P SIP UAs. There exist a > variety > > of options to bridge the gap down the road. > > > > -david > > > > > > From dbarrett at quinthar.com Tue Jun 6 13:26:46 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 6 Jun 2006 10:26:46 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFF38@xmb-sjc-219.amer.cisco.com> Message-ID: <200606061726.k56HQtX5004712@cs.columbia.edu> Cool. So if this story is used as the scope for P2PSIP v1.0, it means we're targeting the following definitions and use cases: P2PSIP v1.0 Scope - A "P2PSIP proxy" is constructed by UAs using P2P techniques . P2PSIP v1.0 supports one type of P2PSIP proxy, based on a DHT . Future versions of P2PSIP will support non-DHT proxies - A "P2PSIP UA" is capable of: . Creating a new P2PSIP proxy and assigning it a name . Registering itself with a named P2PSIP proxy . Advertising its named P2PSIP proxies to neighboring peers o P2PSIP v1.0 supports IP multicast broadcasts o Future versions will support other broadcast techniques . Discovering named P2PSIP proxy advertisements from neighboring peers . Joining named P2PSIP proxies . Resolving "sip:" addresses to P2PSIP UAs using P2PSIP proxies And really, that's about it. I'd say that future versions include: P2PSIP v2.0+ Scope - A "P2PSIP Gateway" interfaces between P2PSIP proxies and CS SIP UAs . This is what lets CS UAs contact P2PSIP UAs - A "P2PSIP Bootstrapping Server" joins and advertises P2PSIP proxies . This is what prevents P2PSIP proxies going "dark" . This also helps rendezvous P2PSIP UAs outside advertisement range - P2PSIP UAs look for both P2P and CS proxies for each "sip:" address . This is what lets P2PSIP UAs contact CS UAs - All P2PSIP components incorporate secure authentication, TLS, and so on - Variants of P2PSIP proxies using other DHTs (or other P2P algorithms) - Variants of P2PSIP proxy advertisement using zeroConf, mDNS, etc. Basically, I propose we circle the wagons *very* tightly around a very small set of functionality (the smallest possible set that satisfies our use cases), and focus on that exclusively for P2PSIP v1.0. Once that has been nailed down, then we open up the floor to discuss bigger topics. Does this sound like a reasonable plan? Do you endorse us following it? -david > -----Original Message----- > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > Sent: Tuesday, June 06, 2006 8:39 AM > To: David Barrett; Cullen Jennings (fluffy) > Cc: David A. Bryan; p2p-sip at cs.columbia.edu > Subject: RE: [p2p-sip] What are we doing, question 2 > > Yep, works for me at higher level. Comments ... > > > [3] For 1.0, UAs broadcast their network affiliation using IP > multicast. > > We also need to add that discovery would be done thru IP > multicast. > Can we say we will leverage existing DNS mechanism - > specifically use the mDNS primitives for this ? That way we do not have > to work on another multicast format, port number and associated > mechanisms. > We also need to specify couple of DNS record types and > appropriate formats. May be we can leverage the currently available > record types and formats. > > Still prefer the URI > sip:@[?dht=]. May be we will say, the FQN > for fluffy at quinthar is actually > sip:fluffy at quinthar[[@]] > > Should add some form of security mechanism - at least a key > substrate as a trust bootstrap and encryption as needed. May be TLS is > enough. > > > -----Original Message----- > > From: David Barrett [mailto:dbarrett at quinthar.com] > > Sent: Monday, June 05, 2006 11:01 PM > > To: Cullen Jennings (fluffy) > > Cc: Krishna Sankar (ksankar); 'David A. Bryan'; > > p2p-sip at cs.columbia.edu > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > Well, what I'm trying to accomplish is enunciate a vision for > > how the product works for a user. Once we agree upon what > > P2PSIP is supposed to do for the user, then I think we can > > more easily discuss how to make that happen. > > > > With this in mind, here's an updated story for my vision of > > what a P2PSIP 1.0 UA does: > > > > You and I each install a P2PSIP-enabled UA while sitting on > > the same LAN. I click the "Create a new network" button on > > my UA, and give it the name "quinthar". [1] It asks me what > > my name is on this network, and I say "dbarrett". [2] Your UA > > detects this and lists "quinthar" as one of the known > > networks, and "dbarrett at quinthar" as a known user. [3] You > > choose the "quinthar" network and click "Join network", then > > specify that your name is "fluffy". [4] On my UA, I see > > "fluffy at quinthar" is listed in as a known user. I double > > click on "fluffy at quinthar", and initiate a VoIP call. [5] > > > > [1] For 1.0, anyone can create a network; later it might be > > tied to public key encryption. > > [2] For 1.0, anyone can choose any name when joining a > > network; later each network might have an administrator. > > [3] For 1.0, UAs broadcast their network affiliation using IP > > multicast. > > Later there might be global network registries, special > > bootstrapping servers, or even a global DHT set aside to > > publish networks. > > [4] For 1.0, anyone can join any network they've discovered, > > or by entering the IP:port of a node on the network. > > [5] We've created identities, discovered each other, and > > initiated a SIP call -- all without ever touching a single server. > > > > > > Does this story basically capture the same product that you > > want to enable with P2PSIP? If not, can you follow the > > pattern above and lay out your own story? > > > > -david > > > > > -----Original Message----- > > > From: Cullen Jennings [mailto:fluffy at cisco.com] > > > Sent: Monday, June 05, 2006 5:36 PM > > > To: David Barrett > > > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; > > > p2p-sip at cs.columbia.edu > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > Some of the proposal so for have come up with ways to make sip: > > > addresses work and make things interoperable with more traditional > > > sip. Clearly having interoperate would be a nice property > > if possible. > > > However, I am still lost on what we are trying to accomplish, much > > > less what the solutions is or if it needs a different URL. > > > > > > > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > > > > > Again, I love the idea of having a single "sip:" address > > that "just > > > > works" > > > > for both CS and P2P SIP. Please help me understand your proposal > > > > better. > > > > > > > > Will I be able to print my combined CS/P2P SIP address on > > a business > > > > card, hand it to you, and have you type it into your SIP > > UA and get > > > > an expected result (a valid connection, if it's P2PSIP > > aware, or a > > > > message saying "unsupported address type" if not)? If so, what > > > > might that address look like? > > > > > > > > I've proposed your business card might say: > > > > > > > > sip:@ > > > > > > > > Or > > > > > > > > p2psip:[@] [1] > > > > > > > > If instead we only use the first format, how does a UA figure out > > > > which DHT the address is registered with, and how does it > > connect to > > > > that DHT? I can imagine URI attributes: > > > > > > > > sip:@[?dht=] > > > > > > > > And I think this is a great solution. But I don't > > understand how a > > > > human would input "header elements" to a UA. Am I > > misunderstanding > > > > the proposal? > > > > > > > > -david > > > > > > > > [1] I've proposed is [@], and that > > > > it's optional (defaulting to some global DHT if > > unspecified). But > > > > the precise syntax is unimportant. What is important is that the > > > > address contain whatever information is necessary to connect to a > > > > given DHT. > > > > > > > >> -----Original Message----- > > > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > > >> Sent: Monday, June 05, 2006 10:22 AM > > > >> To: David A. Bryan > > > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > > >> Subject: RE: [p2p-sip] What are we doing, question 2 > > > >> > > > >> Agreed. If we, in-principle, see the need for the > > > >> p2psip:[@@[]], we can make it as > > > >> harmless as possible - a set of header elements or a set of URI > > > >> parameter is an excellent choice. > > > >> > > > >> I like header element better - something like : > > > >> Additional-Format:P2P > > > >> P2P-DHTName:,,... > > > >> P2P-BootStrap:,... > > > >> > > > >> Cheers > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: davidbryan at gmail.com > > [mailto:davidbryan at gmail.com] On Behalf > > > >>> Of David A. Bryan > > > >>> Sent: Monday, June 05, 2006 10:09 AM > > > >>> To: Krishna Sankar (ksankar) > > > >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > >>> > > > >>> If we have a p2psip: address, what does a non-P2P SIP > > endpoint do > > > >>> with it? On the otherhand, a regular sip: address can > > go from a UA > > > >>> to a proxy that is more likely to be able to do > > something useful > > > >>> (forward it to a p2p domain)? See the draft Enrico and I did > > > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > > >>> > > > >>> We can use maybe use something else in the messages -- > > a URI param > > > >>> or a header perhaps -- to distinguish P2P from regular > > SIP where > > > >>> needed, but I think we should ensure that a URI is as backward > > > >>> compliant as possible. > > > >>> > > > >>> --David Bryan > > > >>> > > > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > > > >>>> David, > > > >>>> > > > >>>> You have a valid point making p2p-sip explicit for all > > > >>>> than implicit in the UAs who understand it. > > > >>>> a) I mulled it over and do not see any other > > > >>> way, as a 1.0 > > > >>>> requirement. i.e. we do need a p2p-sip protocol designator > > > >>> somewhere > > > >>>> to make it explicit. But not necessarily in one's vcard. > > > >>>> b) We could make the client responsible > > for trying the > > > >>>> generic and then p2p:. > > > >>>> c) Going back to putting p2psip in one's > > > >>> vcard, what does > > > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > > > >>> that one will > > > >>>> be part of a p2psip as and when available ? > > > >>>> d) Isn't p2psip situational ? i.e. when one is > > > >>> at home, may > > > >>>> be, one will be part of the p2psip provided by the service > > > >>> provider or > > > >>>> even the home network; but when one is at work, one becomes > > > >>> part of a > > > >>>> server based larger sip substrate. > > > >>>> What about an emergency worker who > > moves between > > > >>>> different p2psip and sip networks ? > > > >>>> > > > >>>> What about a mobile worker who wanders from > > > >>> Starbucks > > > >>>> network to airport network to .. All might have > > different p2psip > > > >>>> mechanisms or even a combination of p2psip and server > > based sip. > > > >>>> > > > >>>> May be I got it all wrong (mice crunching cats are > > > >>> the norm of > > > >>>> the day than galloping stallions) - very possible ... > > > >>>> Cheers > > > >>>> > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: p2p-sip-bounces at cs.columbia.edu > > > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > > > >>> David Barrett > > > >>>>> Sent: Monday, June 05, 2006 8:58 AM > > > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > > > >>>>> Cc: p2p-sip at cs.columbia.edu > > > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > >>>>> > > > >>>>> Ok, I'll totally agree that it'd be nice to hide the > > details of > > > >>>>> P2PSIP behind a standard "sip:" address (expressed or > > > >>> implied). I > > > >>>>> just haven't envisioned how to accomplish this in > > > >>> conjunction with > > > >>>>> the other requirements, and I'm trying to avoid > > proposing what I > > > >>>>> can't figure out how to build. > > > >>>>> > > > >>>>> The problem I see isn't one of technology, but > > usability issues > > > >>>>> caused in the adoption period. Clearly, P2PSIP isn't > > going to > > > >>>>> happen overnight. > > > >>>>> There will be period of years where it is slowly rolled > > > >>> out to SIP > > > >>>>> UAs. And during this period, I think it's important > > for a UA to > > > >>>>> differentiate between invalid SIP addresses, and P2PSIP > > > >>>>> addresses that it doesn't know how to handle. > > > >>>>> > > > >>>>> For example, let's assume I put my P2PSIP address on a > > > >>> business card > > > >>>>> as "sip:dbarrett at quinthar.com" (or just > > > >>> "dbarrett at quinthar.com" with > > > >>>>> the "sip:" > > > >>>>> implied). A P2PSIP-aware UA might first look for a > > > >>> traditional SIP > > > >>>>> proxy at "quinthar.com" and then, not finding one, use some > > > >>>>> DHT-based mechanism. I love that idea. > > > >>>>> > > > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > > > >>> address is > > > >>>>> valid and supported, but broken. I don't love this idea. > > > >>>>> > > > >>>>> Thus I'm proposing, at least at the start while P2PSIP is > > > >>>>> getting its legs, we use "p2psip:". A > > P2PSIP-aware > > > >>>>> UA > > > >>> will work, > > > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this > > > >>>>> address type". The blame is placed on the UA (where it > > > >>> should be), > > > >>>>> rather than the address. > > > >>>>> > > > >>>>> Maybe in the future, once P2PSIP is more established, > > UAs would > > > >>>>> automatically retry all failed "sip:" > > > >>>>> addresses on some P2PSIP framework, and then the two > > > >>> addresses would > > > >>>>> converge down the road. > > > >>>>> > > > >>>>> But I'm not sure how we can start out converged without just > > > >>>>> confusing the user and, ultimately, hurting the SIP > > > >>> community as a > > > >>>>> whole -- P2P and otherwise. > > > >>>>> > > > >>>>> Have I missed something? Can you see a way to roll out > > > >>> P2PSIP atop > > > >>>>> a standard "sip:" address without > > appearing totally > > > >>>>> broken throughout the deployment period? > > > >>>>> > > > >>>>> -david > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > > >>>>> Behalf Of > > > >>>>>> David A. Bryan > > > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > > > >>>>>> To: Henning Schulzrinne > > > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > > > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > >>>>>> > > > >>>>>> I would agree, and would add a subtly different > > > >>> objection that a > > > >>>>>> traditional SIP UA will be better able to interact with > > > >>> a P2PSIP > > > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that > > > >>>>>> debate hashes out). > > > >>>>>> > > > >>>>>> David > > > >>>>>> > > > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > > > >>>>>>>> I'd prefer not to debate the specifics at this point -- > > > >>>>> if we can > > > >>>>>>>> agree that there's some kind of "p2psip:" > > > >>>>> address type, > > > >>>>>>>> I think that's as deep as we need to get agreement > > > >>> on the big > > > >>>>>>>> picture. > > > >>>>>>> > > > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > > > >>>>> have to change > > > >>>>>>> my address (and business card) just because I'm changing > > > >>>>> some low- > > > >>>>>>> level technical detail of how signaling requests are > > > >>>>> routed. In any > > > >>>>>>> event, just like many web pages are simply listed as > > > >>>>>>> www.something.com (instead of http://www.something.com), I > > > >>>>>>> expect that many business cards and directories will simply > > > >>>>>>> contain alice at something.com. > > > >>>>>>> > > > >>>>>>> It's the role of protocols to make these resolution details > > > >>>>>>> transparent to the user. This isn't terribly > > > >>> difficult in this > > > >>>>>>> particular case. > > > >>>>>>> > > > >>>>>>> Henning > > > >>>>>>> _______________________________________________ > > > >>>>>>> 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 > > > >>>>> > > > >>>> > > > >>> > > > > > > > > _______________________________________________ > > > > p2p-sip mailing list > > > > p2p-sip at cs.columbia.edu > > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From mbhatia at 3clogic.com Tue Jun 6 19:15:16 2006 From: mbhatia at 3clogic.com (Medhavi Bhatia) Date: Tue, 6 Jun 2006 19:15:16 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606061726.k56HQtX5004712@cs.columbia.edu> References: <9FA16888AD1BF64ABCE6C2532CCEB98A4DFF38@xmb-sjc-219.amer.cisco.com> <200606061726.k56HQtX5004712@cs.columbia.edu> Message-ID: <894e079b0606061615jf6d6e9chc405fba2fc08926a@mail.gmail.com> Hi Dave, Maybe I am chiming in a bit late, but your wording sounds a little confusing. I think at the last IETF meeting we discussed the need for standardizing the protocol between SIP UAs and any DHT for the lookup and registration etc. Does that fit into one of your scope items below? -Medhavi. On 6/6/06, David Barrett wrote: > Cool. So if this story is used as the scope for P2PSIP v1.0, it means we're > targeting the following definitions and use cases: > > P2PSIP v1.0 Scope > - A "P2PSIP proxy" is constructed by UAs using P2P techniques > . P2PSIP v1.0 supports one type of P2PSIP proxy, based on a DHT > . Future versions of P2PSIP will support non-DHT proxies > > - A "P2PSIP UA" is capable of: > . Creating a new P2PSIP proxy and assigning it a name > . Registering itself with a named P2PSIP proxy > . Advertising its named P2PSIP proxies to neighboring peers > o P2PSIP v1.0 supports IP multicast broadcasts > o Future versions will support other broadcast techniques > . Discovering named P2PSIP proxy advertisements from neighboring > peers > . Joining named P2PSIP proxies > . Resolving "sip:" addresses to P2PSIP UAs using P2PSIP proxies > > And really, that's about it. I'd say that future versions include: > > P2PSIP v2.0+ Scope > - A "P2PSIP Gateway" interfaces between P2PSIP proxies and CS SIP UAs > . This is what lets CS UAs contact P2PSIP UAs > > - A "P2PSIP Bootstrapping Server" joins and advertises P2PSIP proxies > . This is what prevents P2PSIP proxies going "dark" > . This also helps rendezvous P2PSIP UAs outside advertisement range > > - P2PSIP UAs look for both P2P and CS proxies for each "sip:" address > . This is what lets P2PSIP UAs contact CS UAs > > - All P2PSIP components incorporate secure authentication, TLS, and so on > > - Variants of P2PSIP proxies using other DHTs (or other P2P algorithms) > > - Variants of P2PSIP proxy advertisement using zeroConf, mDNS, etc. > > > Basically, I propose we circle the wagons *very* tightly around a very small > set of functionality (the smallest possible set that satisfies our use > cases), and focus on that exclusively for P2PSIP v1.0. Once that has been > nailed down, then we open up the floor to discuss bigger topics. > > Does this sound like a reasonable plan? Do you endorse us following it? > > -david > > > -----Original Message----- > > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > Sent: Tuesday, June 06, 2006 8:39 AM > > To: David Barrett; Cullen Jennings (fluffy) > > Cc: David A. Bryan; p2p-sip at cs.columbia.edu > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > Yep, works for me at higher level. Comments ... > > > > > [3] For 1.0, UAs broadcast their network affiliation using IP > > multicast. > > > > We also need to add that discovery would be done thru IP > > multicast. > > Can we say we will leverage existing DNS mechanism - > > specifically use the mDNS primitives for this ? That way we do not have > > to work on another multicast format, port number and associated > > mechanisms. > > We also need to specify couple of DNS record types and > > appropriate formats. May be we can leverage the currently available > > record types and formats. > > > > Still prefer the URI > > sip:@[?dht=]. May be we will say, the FQN > > for fluffy at quinthar is actually > > sip:fluffy at quinthar[[@]] > > > > Should add some form of security mechanism - at least a key > > substrate as a trust bootstrap and encryption as needed. May be TLS is > > enough. > > > > > -----Original Message----- > > > From: David Barrett [mailto:dbarrett at quinthar.com] > > > Sent: Monday, June 05, 2006 11:01 PM > > > To: Cullen Jennings (fluffy) > > > Cc: Krishna Sankar (ksankar); 'David A. Bryan'; > > > p2p-sip at cs.columbia.edu > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > Well, what I'm trying to accomplish is enunciate a vision for > > > how the product works for a user. Once we agree upon what > > > P2PSIP is supposed to do for the user, then I think we can > > > more easily discuss how to make that happen. > > > > > > With this in mind, here's an updated story for my vision of > > > what a P2PSIP 1.0 UA does: > > > > > > You and I each install a P2PSIP-enabled UA while sitting on > > > the same LAN. I click the "Create a new network" button on > > > my UA, and give it the name "quinthar". [1] It asks me what > > > my name is on this network, and I say "dbarrett". [2] Your UA > > > detects this and lists "quinthar" as one of the known > > > networks, and "dbarrett at quinthar" as a known user. [3] You > > > choose the "quinthar" network and click "Join network", then > > > specify that your name is "fluffy". [4] On my UA, I see > > > "fluffy at quinthar" is listed in as a known user. I double > > > click on "fluffy at quinthar", and initiate a VoIP call. [5] > > > > > > [1] For 1.0, anyone can create a network; later it might be > > > tied to public key encryption. > > > [2] For 1.0, anyone can choose any name when joining a > > > network; later each network might have an administrator. > > > [3] For 1.0, UAs broadcast their network affiliation using IP > > > multicast. > > > Later there might be global network registries, special > > > bootstrapping servers, or even a global DHT set aside to > > > publish networks. > > > [4] For 1.0, anyone can join any network they've discovered, > > > or by entering the IP:port of a node on the network. > > > [5] We've created identities, discovered each other, and > > > initiated a SIP call -- all without ever touching a single server. > > > > > > > > > Does this story basically capture the same product that you > > > want to enable with P2PSIP? If not, can you follow the > > > pattern above and lay out your own story? > > > > > > -david > > > > > > > -----Original Message----- > > > > From: Cullen Jennings [mailto:fluffy at cisco.com] > > > > Sent: Monday, June 05, 2006 5:36 PM > > > > To: David Barrett > > > > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; > > > > p2p-sip at cs.columbia.edu > > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > Some of the proposal so for have come up with ways to make sip: > > > > addresses work and make things interoperable with more traditional > > > > sip. Clearly having interoperate would be a nice property > > > if possible. > > > > However, I am still lost on what we are trying to accomplish, much > > > > less what the solutions is or if it needs a different URL. > > > > > > > > > > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > > > > > > > Again, I love the idea of having a single "sip:" address > > > that "just > > > > > works" > > > > > for both CS and P2P SIP. Please help me understand your proposal > > > > > better. > > > > > > > > > > Will I be able to print my combined CS/P2P SIP address on > > > a business > > > > > card, hand it to you, and have you type it into your SIP > > > UA and get > > > > > an expected result (a valid connection, if it's P2PSIP > > > aware, or a > > > > > message saying "unsupported address type" if not)? If so, what > > > > > might that address look like? > > > > > > > > > > I've proposed your business card might say: > > > > > > > > > > sip:@ > > > > > > > > > > Or > > > > > > > > > > p2psip:[@] [1] > > > > > > > > > > If instead we only use the first format, how does a UA figure out > > > > > which DHT the address is registered with, and how does it > > > connect to > > > > > that DHT? I can imagine URI attributes: > > > > > > > > > > sip:@[?dht=] > > > > > > > > > > And I think this is a great solution. But I don't > > > understand how a > > > > > human would input "header elements" to a UA. Am I > > > misunderstanding > > > > > the proposal? > > > > > > > > > > -david > > > > > > > > > > [1] I've proposed is [@], and that > > > > > it's optional (defaulting to some global DHT if > > > unspecified). But > > > > > the precise syntax is unimportant. What is important is that the > > > > > address contain whatever information is necessary to connect to a > > > > > given DHT. > > > > > > > > > >> -----Original Message----- > > > > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > > > >> Sent: Monday, June 05, 2006 10:22 AM > > > > >> To: David A. Bryan > > > > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > > > >> Subject: RE: [p2p-sip] What are we doing, question 2 > > > > >> > > > > >> Agreed. If we, in-principle, see the need for the > > > > >> p2psip:[@@[]], we can make it as > > > > >> harmless as possible - a set of header elements or a set of URI > > > > >> parameter is an excellent choice. > > > > >> > > > > >> I like header element better - something like : > > > > >> Additional-Format:P2P > > > > >> P2P-DHTName:,,... > > > > >> P2P-BootStrap:,... > > > > >> > > > > >> Cheers > > > > >> > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: davidbryan at gmail.com > > > [mailto:davidbryan at gmail.com] On Behalf > > > > >>> Of David A. Bryan > > > > >>> Sent: Monday, June 05, 2006 10:09 AM > > > > >>> To: Krishna Sankar (ksankar) > > > > >>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > > > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > >>> > > > > >>> If we have a p2psip: address, what does a non-P2P SIP > > > endpoint do > > > > >>> with it? On the otherhand, a regular sip: address can > > > go from a UA > > > > >>> to a proxy that is more likely to be able to do > > > something useful > > > > >>> (forward it to a p2p domain)? See the draft Enrico and I did > > > > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > > > >>> > > > > >>> We can use maybe use something else in the messages -- > > > a URI param > > > > >>> or a header perhaps -- to distinguish P2P from regular > > > SIP where > > > > >>> needed, but I think we should ensure that a URI is as backward > > > > >>> compliant as possible. > > > > >>> > > > > >>> --David Bryan > > > > >>> > > > > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > > > > >>>> David, > > > > >>>> > > > > >>>> You have a valid point making p2p-sip explicit for all > > > > >>>> than implicit in the UAs who understand it. > > > > >>>> a) I mulled it over and do not see any other > > > > >>> way, as a 1.0 > > > > >>>> requirement. i.e. we do need a p2p-sip protocol designator > > > > >>> somewhere > > > > >>>> to make it explicit. But not necessarily in one's vcard. > > > > >>>> b) We could make the client responsible > > > for trying the > > > > >>>> generic and then p2p:. > > > > >>>> c) Going back to putting p2psip in one's > > > > >>> vcard, what does > > > > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > > > > >>> that one will > > > > >>>> be part of a p2psip as and when available ? > > > > >>>> d) Isn't p2psip situational ? i.e. when one is > > > > >>> at home, may > > > > >>>> be, one will be part of the p2psip provided by the service > > > > >>> provider or > > > > >>>> even the home network; but when one is at work, one becomes > > > > >>> part of a > > > > >>>> server based larger sip substrate. > > > > >>>> What about an emergency worker who > > > moves between > > > > >>>> different p2psip and sip networks ? > > > > >>>> > > > > >>>> What about a mobile worker who wanders from > > > > >>> Starbucks > > > > >>>> network to airport network to .. All might have > > > different p2psip > > > > >>>> mechanisms or even a combination of p2psip and server > > > based sip. > > > > >>>> > > > > >>>> May be I got it all wrong (mice crunching cats are > > > > >>> the norm of > > > > >>>> the day than galloping stallions) - very possible ... > > > > >>>> Cheers > > > > >>>> > > > > >>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: p2p-sip-bounces at cs.columbia.edu > > > > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > > > > >>> David Barrett > > > > >>>>> Sent: Monday, June 05, 2006 8:58 AM > > > > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > > > > >>>>> Cc: p2p-sip at cs.columbia.edu > > > > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > >>>>> > > > > >>>>> Ok, I'll totally agree that it'd be nice to hide the > > > details of > > > > >>>>> P2PSIP behind a standard "sip:" address (expressed or > > > > >>> implied). I > > > > >>>>> just haven't envisioned how to accomplish this in > > > > >>> conjunction with > > > > >>>>> the other requirements, and I'm trying to avoid > > > proposing what I > > > > >>>>> can't figure out how to build. > > > > >>>>> > > > > >>>>> The problem I see isn't one of technology, but > > > usability issues > > > > >>>>> caused in the adoption period. Clearly, P2PSIP isn't > > > going to > > > > >>>>> happen overnight. > > > > >>>>> There will be period of years where it is slowly rolled > > > > >>> out to SIP > > > > >>>>> UAs. And during this period, I think it's important > > > for a UA to > > > > >>>>> differentiate between invalid SIP addresses, and P2PSIP > > > > >>>>> addresses that it doesn't know how to handle. > > > > >>>>> > > > > >>>>> For example, let's assume I put my P2PSIP address on a > > > > >>> business card > > > > >>>>> as "sip:dbarrett at quinthar.com" (or just > > > > >>> "dbarrett at quinthar.com" with > > > > >>>>> the "sip:" > > > > >>>>> implied). A P2PSIP-aware UA might first look for a > > > > >>> traditional SIP > > > > >>>>> proxy at "quinthar.com" and then, not finding one, use some > > > > >>>>> DHT-based mechanism. I love that idea. > > > > >>>>> > > > > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > > > > >>> address is > > > > >>>>> valid and supported, but broken. I don't love this idea. > > > > >>>>> > > > > >>>>> Thus I'm proposing, at least at the start while P2PSIP is > > > > >>>>> getting its legs, we use "p2psip:". A > > > P2PSIP-aware > > > > >>>>> UA > > > > >>> will work, > > > > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support this > > > > >>>>> address type". The blame is placed on the UA (where it > > > > >>> should be), > > > > >>>>> rather than the address. > > > > >>>>> > > > > >>>>> Maybe in the future, once P2PSIP is more established, > > > UAs would > > > > >>>>> automatically retry all failed "sip:" > > > > >>>>> addresses on some P2PSIP framework, and then the two > > > > >>> addresses would > > > > >>>>> converge down the road. > > > > >>>>> > > > > >>>>> But I'm not sure how we can start out converged without just > > > > >>>>> confusing the user and, ultimately, hurting the SIP > > > > >>> community as a > > > > >>>>> whole -- P2P and otherwise. > > > > >>>>> > > > > >>>>> Have I missed something? Can you see a way to roll out > > > > >>> P2PSIP atop > > > > >>>>> a standard "sip:" address without > > > appearing totally > > > > >>>>> broken throughout the deployment period? > > > > >>>>> > > > > >>>>> -david > > > > >>>>> > > > > >>>>>> -----Original Message----- > > > > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > > > >>>>> Behalf Of > > > > >>>>>> David A. Bryan > > > > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > > > > >>>>>> To: Henning Schulzrinne > > > > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > > > > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > >>>>>> > > > > >>>>>> I would agree, and would add a subtly different > > > > >>> objection that a > > > > >>>>>> traditional SIP UA will be better able to interact with > > > > >>> a P2PSIP > > > > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however that > > > > >>>>>> debate hashes out). > > > > >>>>>> > > > > >>>>>> David > > > > >>>>>> > > > > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > > > > >>>>>>>> I'd prefer not to debate the specifics at this point -- > > > > >>>>> if we can > > > > >>>>>>>> agree that there's some kind of "p2psip:" > > > > >>>>> address type, > > > > >>>>>>>> I think that's as deep as we need to get agreement > > > > >>> on the big > > > > >>>>>>>> picture. > > > > >>>>>>> > > > > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > > > > >>>>> have to change > > > > >>>>>>> my address (and business card) just because I'm changing > > > > >>>>> some low- > > > > >>>>>>> level technical detail of how signaling requests are > > > > >>>>> routed. In any > > > > >>>>>>> event, just like many web pages are simply listed as > > > > >>>>>>> www.something.com (instead of http://www.something.com), I > > > > >>>>>>> expect that many business cards and directories will simply > > > > >>>>>>> contain alice at something.com. > > > > >>>>>>> > > > > >>>>>>> It's the role of protocols to make these resolution details > > > > >>>>>>> transparent to the user. This isn't terribly > > > > >>> difficult in this > > > > >>>>>>> particular case. > > > > >>>>>>> > > > > >>>>>>> Henning > > > > >>>>>>> _______________________________________________ > > > > >>>>>>> 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 > > > > >>>>> > > > > >>>> > > > > >>> > > > > > > > > > > _______________________________________________ > > > > > 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 dean.willis at softarmor.com Wed Jun 7 01:32:52 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 7 Jun 2006 00:32:52 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted Message-ID: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> David Bryan, Eunsoo Shim, Philip Matthews and I have spent about 100 hours of conference bridge time trying to come to a rough consensus on what we're talking about, with Henning and Cullen popping in for a few dozen hours each. I finally wrote it all down in a draft format, leaving lots of questions listed but unanswered, and got them to agree that it was at least sort of close to what they were thinking. It was somewhat like pulling the hind teeth out of an angry moose using nothing but Swiss Army Knife tweezers (or at least like I imagine that might be, not having been so daring myself), but now we have a document for the rest of you to shred, which I'm sure you will. It'll be on the IETF draft site soon. In the meantime, check out: http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- concepts-00.html http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- concepts-00.txt http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- concepts-00.xml -- Dean From dbarrett at quinthar.com Wed Jun 7 01:49:15 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 6 Jun 2006 22:49:15 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <894e079b0606061615jf6d6e9chc405fba2fc08926a@mail.gmail.com> Message-ID: <200606070552.k575nQX5012745@cs.columbia.edu> Yes, my vision statement isn't intended to conflict with that, but rather illustrate the v1.0 scope from another perspective (through high-level end-user use cases). In other words, "standardizing the protocol between SIP UAs and any DHT for the lookup and registration" is one of many things that will need doing in order to satisfy my listed use cases. Does this answer your question? -david > -----Original Message----- > From: medhavib at gmail.com [mailto:medhavib at gmail.com] On Behalf Of Medhavi > Bhatia > Sent: Tuesday, June 06, 2006 4:15 PM > To: David Barrett > Cc: Krishna Sankar (ksankar); Cullen Jennings (fluffy); p2p- > sip at cs.columbia.edu; David A. Bryan > Subject: Re: [p2p-sip] What are we doing, question 2 > > Hi Dave, > > Maybe I am chiming in a bit late, but your wording sounds a little > confusing. I think at the last IETF meeting we discussed the need for > standardizing the protocol between SIP UAs and any DHT for the lookup > and registration etc. Does that fit into one of your scope items > below? > > -Medhavi. > > On 6/6/06, David Barrett wrote: > > Cool. So if this story is used as the scope for P2PSIP v1.0, it means > we're > > targeting the following definitions and use cases: > > > > P2PSIP v1.0 Scope > > - A "P2PSIP proxy" is constructed by UAs using P2P techniques > > . P2PSIP v1.0 supports one type of P2PSIP proxy, based on a DHT > > . Future versions of P2PSIP will support non-DHT proxies > > > > - A "P2PSIP UA" is capable of: > > . Creating a new P2PSIP proxy and assigning it a name > > . Registering itself with a named P2PSIP proxy > > . Advertising its named P2PSIP proxies to neighboring peers > > o P2PSIP v1.0 supports IP multicast broadcasts > > o Future versions will support other broadcast > techniques > > . Discovering named P2PSIP proxy advertisements from neighboring > > peers > > . Joining named P2PSIP proxies > > . Resolving "sip:" addresses to P2PSIP UAs using P2PSIP proxies > > > > And really, that's about it. I'd say that future versions include: > > > > P2PSIP v2.0+ Scope > > - A "P2PSIP Gateway" interfaces between P2PSIP proxies and CS SIP UAs > > . This is what lets CS UAs contact P2PSIP UAs > > > > - A "P2PSIP Bootstrapping Server" joins and advertises P2PSIP proxies > > . This is what prevents P2PSIP proxies going "dark" > > . This also helps rendezvous P2PSIP UAs outside advertisement > range > > > > - P2PSIP UAs look for both P2P and CS proxies for each "sip:" address > > . This is what lets P2PSIP UAs contact CS UAs > > > > - All P2PSIP components incorporate secure authentication, TLS, and so > on > > > > - Variants of P2PSIP proxies using other DHTs (or other P2P algorithms) > > > > - Variants of P2PSIP proxy advertisement using zeroConf, mDNS, etc. > > > > > > Basically, I propose we circle the wagons *very* tightly around a very > small > > set of functionality (the smallest possible set that satisfies our use > > cases), and focus on that exclusively for P2PSIP v1.0. Once that has > been > > nailed down, then we open up the floor to discuss bigger topics. > > > > Does this sound like a reasonable plan? Do you endorse us following it? > > > > -david > > > > > -----Original Message----- > > > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > > Sent: Tuesday, June 06, 2006 8:39 AM > > > To: David Barrett; Cullen Jennings (fluffy) > > > Cc: David A. Bryan; p2p-sip at cs.columbia.edu > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > Yep, works for me at higher level. Comments ... > > > > > > > [3] For 1.0, UAs broadcast their network affiliation using IP > > > multicast. > > > > > > We also need to add that discovery would be done thru IP > > > multicast. > > > Can we say we will leverage existing DNS mechanism - > > > specifically use the mDNS primitives for this ? That way we do not > have > > > to work on another multicast format, port number and associated > > > mechanisms. > > > We also need to specify couple of DNS record types and > > > appropriate formats. May be we can leverage the currently available > > > record types and formats. > > > > > > Still prefer the URI > > > sip:@[?dht=]. May be we will say, the > FQN > > > for fluffy at quinthar is actually > > > sip:fluffy at quinthar[[@]] > > > > > > Should add some form of security mechanism - at least a key > > > substrate as a trust bootstrap and encryption as needed. May be TLS is > > > enough. > > > > > > > -----Original Message----- > > > > From: David Barrett [mailto:dbarrett at quinthar.com] > > > > Sent: Monday, June 05, 2006 11:01 PM > > > > To: Cullen Jennings (fluffy) > > > > Cc: Krishna Sankar (ksankar); 'David A. Bryan'; > > > > p2p-sip at cs.columbia.edu > > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > > > Well, what I'm trying to accomplish is enunciate a vision for > > > > how the product works for a user. Once we agree upon what > > > > P2PSIP is supposed to do for the user, then I think we can > > > > more easily discuss how to make that happen. > > > > > > > > With this in mind, here's an updated story for my vision of > > > > what a P2PSIP 1.0 UA does: > > > > > > > > You and I each install a P2PSIP-enabled UA while sitting on > > > > the same LAN. I click the "Create a new network" button on > > > > my UA, and give it the name "quinthar". [1] It asks me what > > > > my name is on this network, and I say "dbarrett". [2] Your UA > > > > detects this and lists "quinthar" as one of the known > > > > networks, and "dbarrett at quinthar" as a known user. [3] You > > > > choose the "quinthar" network and click "Join network", then > > > > specify that your name is "fluffy". [4] On my UA, I see > > > > "fluffy at quinthar" is listed in as a known user. I double > > > > click on "fluffy at quinthar", and initiate a VoIP call. [5] > > > > > > > > [1] For 1.0, anyone can create a network; later it might be > > > > tied to public key encryption. > > > > [2] For 1.0, anyone can choose any name when joining a > > > > network; later each network might have an administrator. > > > > [3] For 1.0, UAs broadcast their network affiliation using IP > > > > multicast. > > > > Later there might be global network registries, special > > > > bootstrapping servers, or even a global DHT set aside to > > > > publish networks. > > > > [4] For 1.0, anyone can join any network they've discovered, > > > > or by entering the IP:port of a node on the network. > > > > [5] We've created identities, discovered each other, and > > > > initiated a SIP call -- all without ever touching a single server. > > > > > > > > > > > > Does this story basically capture the same product that you > > > > want to enable with P2PSIP? If not, can you follow the > > > > pattern above and lay out your own story? > > > > > > > > -david > > > > > > > > > -----Original Message----- > > > > > From: Cullen Jennings [mailto:fluffy at cisco.com] > > > > > Sent: Monday, June 05, 2006 5:36 PM > > > > > To: David Barrett > > > > > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; > > > > > p2p-sip at cs.columbia.edu > > > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > > > > Some of the proposal so for have come up with ways to make sip: > > > > > addresses work and make things interoperable with more traditional > > > > > sip. Clearly having interoperate would be a nice property > > > > if possible. > > > > > However, I am still lost on what we are trying to accomplish, much > > > > > less what the solutions is or if it needs a different URL. > > > > > > > > > > > > > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > > > > > > > > > Again, I love the idea of having a single "sip:" address > > > > that "just > > > > > > works" > > > > > > for both CS and P2P SIP. Please help me understand your > proposal > > > > > > better. > > > > > > > > > > > > Will I be able to print my combined CS/P2P SIP address on > > > > a business > > > > > > card, hand it to you, and have you type it into your SIP > > > > UA and get > > > > > > an expected result (a valid connection, if it's P2PSIP > > > > aware, or a > > > > > > message saying "unsupported address type" if not)? If so, what > > > > > > might that address look like? > > > > > > > > > > > > I've proposed your business card might say: > > > > > > > > > > > > sip:@ > > > > > > > > > > > > Or > > > > > > > > > > > > p2psip:[@] [1] > > > > > > > > > > > > If instead we only use the first format, how does a UA figure > out > > > > > > which DHT the address is registered with, and how does it > > > > connect to > > > > > > that DHT? I can imagine URI attributes: > > > > > > > > > > > > sip:@[?dht=] > > > > > > > > > > > > And I think this is a great solution. But I don't > > > > understand how a > > > > > > human would input "header elements" to a UA. Am I > > > > misunderstanding > > > > > > the proposal? > > > > > > > > > > > > -david > > > > > > > > > > > > [1] I've proposed is [@], and that > > > > > > it's optional (defaulting to some global DHT if > > > > unspecified). But > > > > > > the precise syntax is unimportant. What is important is that > the > > > > > > address contain whatever information is necessary to connect to > a > > > > > > given DHT. > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > > > > >> Sent: Monday, June 05, 2006 10:22 AM > > > > > >> To: David A. Bryan > > > > > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > > > > >> Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > >> > > > > > >> Agreed. If we, in-principle, see the need for the > > > > > >> p2psip:[@@[]], we can make it as > > > > > >> harmless as possible - a set of header elements or a set of URI > > > > > >> parameter is an excellent choice. > > > > > >> > > > > > >> I like header element better - something like : > > > > > >> Additional-Format:P2P > > > > > >> P2P-DHTName:,,... > > > > > >> P2P-BootStrap:,... > > > > > >> > > > > > >> Cheers > > > > > >> > > > > > >> > > > > > >>> -----Original Message----- > > > > > >>> From: davidbryan at gmail.com > > > > [mailto:davidbryan at gmail.com] On Behalf > > > > > >>> Of David A. Bryan > > > > > >>> Sent: Monday, June 05, 2006 10:09 AM > > > > > >>> To: Krishna Sankar (ksankar) > > > > > >>> Cc: David Barrett; Henning Schulzrinne; p2p- > sip at cs.columbia.edu > > > > > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >>> > > > > > >>> If we have a p2psip: address, what does a non-P2P SIP > > > > endpoint do > > > > > >>> with it? On the otherhand, a regular sip: address can > > > > go from a UA > > > > > >>> to a proxy that is more likely to be able to do > > > > something useful > > > > > >>> (forward it to a p2p domain)? See the draft Enrico and I did > > > > > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > > > > >>> > > > > > >>> We can use maybe use something else in the messages -- > > > > a URI param > > > > > >>> or a header perhaps -- to distinguish P2P from regular > > > > SIP where > > > > > >>> needed, but I think we should ensure that a URI is as backward > > > > > >>> compliant as possible. > > > > > >>> > > > > > >>> --David Bryan > > > > > >>> > > > > > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > > > > > >>>> David, > > > > > >>>> > > > > > >>>> You have a valid point making p2p-sip explicit for > all > > > > > >>>> than implicit in the UAs who understand it. > > > > > >>>> a) I mulled it over and do not see any other > > > > > >>> way, as a 1.0 > > > > > >>>> requirement. i.e. we do need a p2p-sip protocol designator > > > > > >>> somewhere > > > > > >>>> to make it explicit. But not necessarily in one's vcard. > > > > > >>>> b) We could make the client responsible > > > > for trying the > > > > > >>>> generic and then p2p:. > > > > > >>>> c) Going back to putting p2psip in one's > > > > > >>> vcard, what does > > > > > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > > > > > >>> that one will > > > > > >>>> be part of a p2psip as and when available ? > > > > > >>>> d) Isn't p2psip situational ? i.e. when one is > > > > > >>> at home, may > > > > > >>>> be, one will be part of the p2psip provided by the service > > > > > >>> provider or > > > > > >>>> even the home network; but when one is at work, one becomes > > > > > >>> part of a > > > > > >>>> server based larger sip substrate. > > > > > >>>> What about an emergency worker who > > > > moves between > > > > > >>>> different p2psip and sip networks ? > > > > > >>>> > > > > > >>>> What about a mobile worker who wanders from > > > > > >>> Starbucks > > > > > >>>> network to airport network to .. All might have > > > > different p2psip > > > > > >>>> mechanisms or even a combination of p2psip and server > > > > based sip. > > > > > >>>> > > > > > >>>> May be I got it all wrong (mice crunching cats are > > > > > >>> the norm of > > > > > >>>> the day than galloping stallions) - very possible ... > > > > > >>>> Cheers > > > > > >>>> > > > > > >>>> > > > > > >>>>> -----Original Message----- > > > > > >>>>> From: p2p-sip-bounces at cs.columbia.edu > > > > > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > > > > > >>> David Barrett > > > > > >>>>> Sent: Monday, June 05, 2006 8:58 AM > > > > > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > > > > > >>>>> Cc: p2p-sip at cs.columbia.edu > > > > > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >>>>> > > > > > >>>>> Ok, I'll totally agree that it'd be nice to hide the > > > > details of > > > > > >>>>> P2PSIP behind a standard "sip:" address (expressed or > > > > > >>> implied). I > > > > > >>>>> just haven't envisioned how to accomplish this in > > > > > >>> conjunction with > > > > > >>>>> the other requirements, and I'm trying to avoid > > > > proposing what I > > > > > >>>>> can't figure out how to build. > > > > > >>>>> > > > > > >>>>> The problem I see isn't one of technology, but > > > > usability issues > > > > > >>>>> caused in the adoption period. Clearly, P2PSIP isn't > > > > going to > > > > > >>>>> happen overnight. > > > > > >>>>> There will be period of years where it is slowly rolled > > > > > >>> out to SIP > > > > > >>>>> UAs. And during this period, I think it's important > > > > for a UA to > > > > > >>>>> differentiate between invalid SIP addresses, and P2PSIP > > > > > >>>>> addresses that it doesn't know how to handle. > > > > > >>>>> > > > > > >>>>> For example, let's assume I put my P2PSIP address on a > > > > > >>> business card > > > > > >>>>> as "sip:dbarrett at quinthar.com" (or just > > > > > >>> "dbarrett at quinthar.com" with > > > > > >>>>> the "sip:" > > > > > >>>>> implied). A P2PSIP-aware UA might first look for a > > > > > >>> traditional SIP > > > > > >>>>> proxy at "quinthar.com" and then, not finding one, use some > > > > > >>>>> DHT-based mechanism. I love that idea. > > > > > >>>>> > > > > > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > > > > > >>> address is > > > > > >>>>> valid and supported, but broken. I don't love this idea. > > > > > >>>>> > > > > > >>>>> Thus I'm proposing, at least at the start while P2PSIP is > > > > > >>>>> getting its legs, we use "p2psip:". A > > > > P2PSIP-aware > > > > > >>>>> UA > > > > > >>> will work, > > > > > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support > this > > > > > >>>>> address type". The blame is placed on the UA (where it > > > > > >>> should be), > > > > > >>>>> rather than the address. > > > > > >>>>> > > > > > >>>>> Maybe in the future, once P2PSIP is more established, > > > > UAs would > > > > > >>>>> automatically retry all failed "sip:" > > > > > >>>>> addresses on some P2PSIP framework, and then the two > > > > > >>> addresses would > > > > > >>>>> converge down the road. > > > > > >>>>> > > > > > >>>>> But I'm not sure how we can start out converged without just > > > > > >>>>> confusing the user and, ultimately, hurting the SIP > > > > > >>> community as a > > > > > >>>>> whole -- P2P and otherwise. > > > > > >>>>> > > > > > >>>>> Have I missed something? Can you see a way to roll out > > > > > >>> P2PSIP atop > > > > > >>>>> a standard "sip:" address without > > > > appearing totally > > > > > >>>>> broken throughout the deployment period? > > > > > >>>>> > > > > > >>>>> -david > > > > > >>>>> > > > > > >>>>>> -----Original Message----- > > > > > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > > > > >>>>> Behalf Of > > > > > >>>>>> David A. Bryan > > > > > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > > > > > >>>>>> To: Henning Schulzrinne > > > > > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > > > > > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >>>>>> > > > > > >>>>>> I would agree, and would add a subtly different > > > > > >>> objection that a > > > > > >>>>>> traditional SIP UA will be better able to interact with > > > > > >>> a P2PSIP > > > > > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however > that > > > > > >>>>>> debate hashes out). > > > > > >>>>>> > > > > > >>>>>> David > > > > > >>>>>> > > > > > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > > > > > >>>>>>>> I'd prefer not to debate the specifics at this point -- > > > > > >>>>> if we can > > > > > >>>>>>>> agree that there's some kind of "p2psip:" > > > > > >>>>> address type, > > > > > >>>>>>>> I think that's as deep as we need to get agreement > > > > > >>> on the big > > > > > >>>>>>>> picture. > > > > > >>>>>>> > > > > > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > > > > > >>>>> have to change > > > > > >>>>>>> my address (and business card) just because I'm changing > > > > > >>>>> some low- > > > > > >>>>>>> level technical detail of how signaling requests are > > > > > >>>>> routed. In any > > > > > >>>>>>> event, just like many web pages are simply listed as > > > > > >>>>>>> www.something.com (instead of http://www.something.com), I > > > > > >>>>>>> expect that many business cards and directories will > simply > > > > > >>>>>>> contain alice at something.com. > > > > > >>>>>>> > > > > > >>>>>>> It's the role of protocols to make these resolution > details > > > > > >>>>>>> transparent to the user. This isn't terribly > > > > > >>> difficult in this > > > > > >>>>>>> particular case. > > > > > >>>>>>> > > > > > >>>>>>> Henning > > > > > >>>>>>> _______________________________________________ > > > > > >>>>>>> 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 > > > > > >>>>> > > > > > >>>> > > > > > >>> > > > > > > > > > > > > _______________________________________________ > > > > > > 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 mbhatia at 3clogic.com Wed Jun 7 09:45:45 2006 From: mbhatia at 3clogic.com (Medhavi Bhatia) Date: Wed, 7 Jun 2006 09:45:45 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <20060607054926.49028.qmail@mta103.biz.mail.re2.yahoo.com> References: <894e079b0606061615jf6d6e9chc405fba2fc08926a@mail.gmail.com> <20060607054926.49028.qmail@mta103.biz.mail.re2.yahoo.com> Message-ID: <894e079b0606070645x14bea3ccu498a4ec206ea79d7@mail.gmail.com> Hi Dave, Another set of clarifications: Why do we need the notion of a P2P SIP Proxy if we all agree the SIP UA to DHT protocol exists? The SIP Proxies can exist and continue to be used as it is in the SIP protocol specs. Another one: Why do we need a P2PSIP UA? Do you propose to change the SIP state machines at the UA or any of the ways SIP will be used between UAs in the P2P world? The only thing I forsee is the tinkering of RFC 3263. -Medhavi. On 6/7/06, David Barrett wrote: > Yes, my vision statement isn't intended to conflict with that, but rather > illustrate the v1.0 scope from another perspective (through high-level > end-user use cases). > > In other words, "standardizing the protocol between SIP UAs and any DHT for > the lookup and registration" is one of many things that will need doing in > order to satisfy my listed use cases. > > Does this answer your question? > > -david > > > -----Original Message----- > > From: medhavib at gmail.com [mailto:medhavib at gmail.com] On Behalf Of Medhavi > > Bhatia > > Sent: Tuesday, June 06, 2006 4:15 PM > > To: David Barrett > > Cc: Krishna Sankar (ksankar); Cullen Jennings (fluffy); p2p- > > sip at cs.columbia.edu; David A. Bryan > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > Hi Dave, > > > > Maybe I am chiming in a bit late, but your wording sounds a little > > confusing. I think at the last IETF meeting we discussed the need for > > standardizing the protocol between SIP UAs and any DHT for the lookup > > and registration etc. Does that fit into one of your scope items > > below? > > > > -Medhavi. > > > > On 6/6/06, David Barrett wrote: > > > Cool. So if this story is used as the scope for P2PSIP v1.0, it means > > we're > > > targeting the following definitions and use cases: > > > > > > P2PSIP v1.0 Scope > > > - A "P2PSIP proxy" is constructed by UAs using P2P techniques > > > . P2PSIP v1.0 supports one type of P2PSIP proxy, based on a DHT > > > . Future versions of P2PSIP will support non-DHT proxies > > > > > > - A "P2PSIP UA" is capable of: > > > . Creating a new P2PSIP proxy and assigning it a name > > > . Registering itself with a named P2PSIP proxy > > > . Advertising its named P2PSIP proxies to neighboring peers > > > o P2PSIP v1.0 supports IP multicast broadcasts > > > o Future versions will support other broadcast > > techniques > > > . Discovering named P2PSIP proxy advertisements from neighboring > > > peers > > > . Joining named P2PSIP proxies > > > . Resolving "sip:" addresses to P2PSIP UAs using P2PSIP proxies > > > > > > And really, that's about it. I'd say that future versions include: > > > > > > P2PSIP v2.0+ Scope > > > - A "P2PSIP Gateway" interfaces between P2PSIP proxies and CS SIP UAs > > > . This is what lets CS UAs contact P2PSIP UAs > > > > > > - A "P2PSIP Bootstrapping Server" joins and advertises P2PSIP proxies > > > . This is what prevents P2PSIP proxies going "dark" > > > . This also helps rendezvous P2PSIP UAs outside advertisement > > range > > > > > > - P2PSIP UAs look for both P2P and CS proxies for each "sip:" address > > > . This is what lets P2PSIP UAs contact CS UAs > > > > > > - All P2PSIP components incorporate secure authentication, TLS, and so > > on > > > > > > - Variants of P2PSIP proxies using other DHTs (or other P2P algorithms) > > > > > > - Variants of P2PSIP proxy advertisement using zeroConf, mDNS, etc. > > > > > > > > > Basically, I propose we circle the wagons *very* tightly around a very > > small > > > set of functionality (the smallest possible set that satisfies our use > > > cases), and focus on that exclusively for P2PSIP v1.0. Once that has > > been > > > nailed down, then we open up the floor to discuss bigger topics. > > > > > > Does this sound like a reasonable plan? Do you endorse us following it? > > > > > > -david > > > > > > > -----Original Message----- > > > > From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > > > Sent: Tuesday, June 06, 2006 8:39 AM > > > > To: David Barrett; Cullen Jennings (fluffy) > > > > Cc: David A. Bryan; p2p-sip at cs.columbia.edu > > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > > > Yep, works for me at higher level. Comments ... > > > > > > > > > [3] For 1.0, UAs broadcast their network affiliation using IP > > > > multicast. > > > > > > > > We also need to add that discovery would be done thru IP > > > > multicast. > > > > Can we say we will leverage existing DNS mechanism - > > > > specifically use the mDNS primitives for this ? That way we do not > > have > > > > to work on another multicast format, port number and associated > > > > mechanisms. > > > > We also need to specify couple of DNS record types and > > > > appropriate formats. May be we can leverage the currently available > > > > record types and formats. > > > > > > > > Still prefer the URI > > > > sip:@[?dht=]. May be we will say, the > > FQN > > > > for fluffy at quinthar is actually > > > > sip:fluffy at quinthar[[@]] > > > > > > > > Should add some form of security mechanism - at least a key > > > > substrate as a trust bootstrap and encryption as needed. May be TLS is > > > > enough. > > > > > > > > > -----Original Message----- > > > > > From: David Barrett [mailto:dbarrett at quinthar.com] > > > > > Sent: Monday, June 05, 2006 11:01 PM > > > > > To: Cullen Jennings (fluffy) > > > > > Cc: Krishna Sankar (ksankar); 'David A. Bryan'; > > > > > p2p-sip at cs.columbia.edu > > > > > Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > > > > > Well, what I'm trying to accomplish is enunciate a vision for > > > > > how the product works for a user. Once we agree upon what > > > > > P2PSIP is supposed to do for the user, then I think we can > > > > > more easily discuss how to make that happen. > > > > > > > > > > With this in mind, here's an updated story for my vision of > > > > > what a P2PSIP 1.0 UA does: > > > > > > > > > > You and I each install a P2PSIP-enabled UA while sitting on > > > > > the same LAN. I click the "Create a new network" button on > > > > > my UA, and give it the name "quinthar". [1] It asks me what > > > > > my name is on this network, and I say "dbarrett". [2] Your UA > > > > > detects this and lists "quinthar" as one of the known > > > > > networks, and "dbarrett at quinthar" as a known user. [3] You > > > > > choose the "quinthar" network and click "Join network", then > > > > > specify that your name is "fluffy". [4] On my UA, I see > > > > > "fluffy at quinthar" is listed in as a known user. I double > > > > > click on "fluffy at quinthar", and initiate a VoIP call. [5] > > > > > > > > > > [1] For 1.0, anyone can create a network; later it might be > > > > > tied to public key encryption. > > > > > [2] For 1.0, anyone can choose any name when joining a > > > > > network; later each network might have an administrator. > > > > > [3] For 1.0, UAs broadcast their network affiliation using IP > > > > > multicast. > > > > > Later there might be global network registries, special > > > > > bootstrapping servers, or even a global DHT set aside to > > > > > publish networks. > > > > > [4] For 1.0, anyone can join any network they've discovered, > > > > > or by entering the IP:port of a node on the network. > > > > > [5] We've created identities, discovered each other, and > > > > > initiated a SIP call -- all without ever touching a single server. > > > > > > > > > > > > > > > Does this story basically capture the same product that you > > > > > want to enable with P2PSIP? If not, can you follow the > > > > > pattern above and lay out your own story? > > > > > > > > > > -david > > > > > > > > > > > -----Original Message----- > > > > > > From: Cullen Jennings [mailto:fluffy at cisco.com] > > > > > > Sent: Monday, June 05, 2006 5:36 PM > > > > > > To: David Barrett > > > > > > Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; > > > > > > p2p-sip at cs.columbia.edu > > > > > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > > > > > > > Some of the proposal so for have come up with ways to make sip: > > > > > > addresses work and make things interoperable with more traditional > > > > > > sip. Clearly having interoperate would be a nice property > > > > > if possible. > > > > > > However, I am still lost on what we are trying to accomplish, much > > > > > > less what the solutions is or if it needs a different URL. > > > > > > > > > > > > > > > > > > On Jun 5, 2006, at 3:32 PM, David Barrett wrote: > > > > > > > > > > > > > Again, I love the idea of having a single "sip:" address > > > > > that "just > > > > > > > works" > > > > > > > for both CS and P2P SIP. Please help me understand your > > proposal > > > > > > > better. > > > > > > > > > > > > > > Will I be able to print my combined CS/P2P SIP address on > > > > > a business > > > > > > > card, hand it to you, and have you type it into your SIP > > > > > UA and get > > > > > > > an expected result (a valid connection, if it's P2PSIP > > > > > aware, or a > > > > > > > message saying "unsupported address type" if not)? If so, what > > > > > > > might that address look like? > > > > > > > > > > > > > > I've proposed your business card might say: > > > > > > > > > > > > > > sip:@ > > > > > > > > > > > > > > Or > > > > > > > > > > > > > > p2psip:[@] [1] > > > > > > > > > > > > > > If instead we only use the first format, how does a UA figure > > out > > > > > > > which DHT the address is registered with, and how does it > > > > > connect to > > > > > > > that DHT? I can imagine URI attributes: > > > > > > > > > > > > > > sip:@[?dht=] > > > > > > > > > > > > > > And I think this is a great solution. But I don't > > > > > understand how a > > > > > > > human would input "header elements" to a UA. Am I > > > > > misunderstanding > > > > > > > the proposal? > > > > > > > > > > > > > > -david > > > > > > > > > > > > > > [1] I've proposed is [@], and that > > > > > > > it's optional (defaulting to some global DHT if > > > > > unspecified). But > > > > > > > the precise syntax is unimportant. What is important is that > > the > > > > > > > address contain whatever information is necessary to connect to > > a > > > > > > > given DHT. > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] > > > > > > >> Sent: Monday, June 05, 2006 10:22 AM > > > > > > >> To: David A. Bryan > > > > > > >> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu > > > > > > >> Subject: RE: [p2p-sip] What are we doing, question 2 > > > > > > >> > > > > > > >> Agreed. If we, in-principle, see the need for the > > > > > > >> p2psip:[@@[]], we can make it as > > > > > > >> harmless as possible - a set of header elements or a set of URI > > > > > > >> parameter is an excellent choice. > > > > > > >> > > > > > > >> I like header element better - something like : > > > > > > >> Additional-Format:P2P > > > > > > >> P2P-DHTName:,,... > > > > > > >> P2P-BootStrap:,... > > > > > > >> > > > > > > >> Cheers > > > > > > >> > > > > > > >> > > > > > > >>> -----Original Message----- > > > > > > >>> From: davidbryan at gmail.com > > > > > [mailto:davidbryan at gmail.com] On Behalf > > > > > > >>> Of David A. Bryan > > > > > > >>> Sent: Monday, June 05, 2006 10:09 AM > > > > > > >>> To: Krishna Sankar (ksankar) > > > > > > >>> Cc: David Barrett; Henning Schulzrinne; p2p- > > sip at cs.columbia.edu > > > > > > >>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > >>> > > > > > > >>> If we have a p2psip: address, what does a non-P2P SIP > > > > > endpoint do > > > > > > >>> with it? On the otherhand, a regular sip: address can > > > > > go from a UA > > > > > > >>> to a proxy that is more likely to be able to do > > > > > something useful > > > > > > >>> (forward it to a p2p domain)? See the draft Enrico and I did > > > > > > >>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. > > > > > > >>> > > > > > > >>> We can use maybe use something else in the messages -- > > > > > a URI param > > > > > > >>> or a header perhaps -- to distinguish P2P from regular > > > > > SIP where > > > > > > >>> needed, but I think we should ensure that a URI is as backward > > > > > > >>> compliant as possible. > > > > > > >>> > > > > > > >>> --David Bryan > > > > > > >>> > > > > > > >>> On 6/5/06, Krishna Sankar (ksankar) wrote: > > > > > > >>>> David, > > > > > > >>>> > > > > > > >>>> You have a valid point making p2p-sip explicit for > > all > > > > > > >>>> than implicit in the UAs who understand it. > > > > > > >>>> a) I mulled it over and do not see any other > > > > > > >>> way, as a 1.0 > > > > > > >>>> requirement. i.e. we do need a p2p-sip protocol designator > > > > > > >>> somewhere > > > > > > >>>> to make it explicit. But not necessarily in one's vcard. > > > > > > >>>> b) We could make the client responsible > > > > > for trying the > > > > > > >>>> generic and then p2p:. > > > > > > >>>> c) Going back to putting p2psip in one's > > > > > > >>> vcard, what does > > > > > > >>>> "p2psip" in one's SIP address signify anyway ? Signifies > > > > > > >>> that one will > > > > > > >>>> be part of a p2psip as and when available ? > > > > > > >>>> d) Isn't p2psip situational ? i.e. when one is > > > > > > >>> at home, may > > > > > > >>>> be, one will be part of the p2psip provided by the service > > > > > > >>> provider or > > > > > > >>>> even the home network; but when one is at work, one becomes > > > > > > >>> part of a > > > > > > >>>> server based larger sip substrate. > > > > > > >>>> What about an emergency worker who > > > > > moves between > > > > > > >>>> different p2psip and sip networks ? > > > > > > >>>> > > > > > > >>>> What about a mobile worker who wanders from > > > > > > >>> Starbucks > > > > > > >>>> network to airport network to .. All might have > > > > > different p2psip > > > > > > >>>> mechanisms or even a combination of p2psip and server > > > > > based sip. > > > > > > >>>> > > > > > > >>>> May be I got it all wrong (mice crunching cats are > > > > > > >>> the norm of > > > > > > >>>> the day than galloping stallions) - very possible ... > > > > > > >>>> Cheers > > > > > > >>>> > > > > > > >>>> > > > > > > >>>>> -----Original Message----- > > > > > > >>>>> From: p2p-sip-bounces at cs.columbia.edu > > > > > > >>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > > > > > > >>> David Barrett > > > > > > >>>>> Sent: Monday, June 05, 2006 8:58 AM > > > > > > >>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' > > > > > > >>>>> Cc: p2p-sip at cs.columbia.edu > > > > > > >>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > >>>>> > > > > > > >>>>> Ok, I'll totally agree that it'd be nice to hide the > > > > > details of > > > > > > >>>>> P2PSIP behind a standard "sip:" address (expressed or > > > > > > >>> implied). I > > > > > > >>>>> just haven't envisioned how to accomplish this in > > > > > > >>> conjunction with > > > > > > >>>>> the other requirements, and I'm trying to avoid > > > > > proposing what I > > > > > > >>>>> can't figure out how to build. > > > > > > >>>>> > > > > > > >>>>> The problem I see isn't one of technology, but > > > > > usability issues > > > > > > >>>>> caused in the adoption period. Clearly, P2PSIP isn't > > > > > going to > > > > > > >>>>> happen overnight. > > > > > > >>>>> There will be period of years where it is slowly rolled > > > > > > >>> out to SIP > > > > > > >>>>> UAs. And during this period, I think it's important > > > > > for a UA to > > > > > > >>>>> differentiate between invalid SIP addresses, and P2PSIP > > > > > > >>>>> addresses that it doesn't know how to handle. > > > > > > >>>>> > > > > > > >>>>> For example, let's assume I put my P2PSIP address on a > > > > > > >>> business card > > > > > > >>>>> as "sip:dbarrett at quinthar.com" (or just > > > > > > >>> "dbarrett at quinthar.com" with > > > > > > >>>>> the "sip:" > > > > > > >>>>> implied). A P2PSIP-aware UA might first look for a > > > > > > >>> traditional SIP > > > > > > >>>>> proxy at "quinthar.com" and then, not finding one, use some > > > > > > >>>>> DHT-based mechanism. I love that idea. > > > > > > >>>>> > > > > > > >>>>> But a P2PSIP-unaware UA will just break. It'll say the > > > > > > >>> address is > > > > > > >>>>> valid and supported, but broken. I don't love this idea. > > > > > > >>>>> > > > > > > >>>>> Thus I'm proposing, at least at the start while P2PSIP is > > > > > > >>>>> getting its legs, we use "p2psip:". A > > > > > P2PSIP-aware > > > > > > >>>>> UA > > > > > > >>> will work, > > > > > > >>>>> and a P2PSIP-unaware UA can clearly say "I don't support > > this > > > > > > >>>>> address type". The blame is placed on the UA (where it > > > > > > >>> should be), > > > > > > >>>>> rather than the address. > > > > > > >>>>> > > > > > > >>>>> Maybe in the future, once P2PSIP is more established, > > > > > UAs would > > > > > > >>>>> automatically retry all failed "sip:" > > > > > > >>>>> addresses on some P2PSIP framework, and then the two > > > > > > >>> addresses would > > > > > > >>>>> converge down the road. > > > > > > >>>>> > > > > > > >>>>> But I'm not sure how we can start out converged without just > > > > > > >>>>> confusing the user and, ultimately, hurting the SIP > > > > > > >>> community as a > > > > > > >>>>> whole -- P2P and otherwise. > > > > > > >>>>> > > > > > > >>>>> Have I missed something? Can you see a way to roll out > > > > > > >>> P2PSIP atop > > > > > > >>>>> a standard "sip:" address without > > > > > appearing totally > > > > > > >>>>> broken throughout the deployment period? > > > > > > >>>>> > > > > > > >>>>> -david > > > > > > >>>>> > > > > > > >>>>>> -----Original Message----- > > > > > > >>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On > > > > > > >>>>> Behalf Of > > > > > > >>>>>> David A. Bryan > > > > > > >>>>>> Sent: Monday, June 05, 2006 7:29 AM > > > > > > >>>>>> To: Henning Schulzrinne > > > > > > >>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu > > > > > > >>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > >>>>>> > > > > > > >>>>>> I would agree, and would add a subtly different > > > > > > >>> objection that a > > > > > > >>>>>> traditional SIP UA will be better able to interact with > > > > > > >>> a P2PSIP > > > > > > >>>>>> endpoint if we have a simple "sip:" or "sips:" (however > > that > > > > > > >>>>>> debate hashes out). > > > > > > >>>>>> > > > > > > >>>>>> David > > > > > > >>>>>> > > > > > > >>>>>> On 6/5/06, Henning Schulzrinne wrote: > > > > > > >>>>>>>> I'd prefer not to debate the specifics at this point -- > > > > > > >>>>> if we can > > > > > > >>>>>>>> agree that there's some kind of "p2psip:" > > > > > > >>>>> address type, > > > > > > >>>>>>>> I think that's as deep as we need to get agreement > > > > > > >>> on the big > > > > > > >>>>>>>> picture. > > > > > > >>>>>>> > > > > > > >>>>>>> I think this is a fundamentally bad idea. I shouldn't > > > > > > >>>>> have to change > > > > > > >>>>>>> my address (and business card) just because I'm changing > > > > > > >>>>> some low- > > > > > > >>>>>>> level technical detail of how signaling requests are > > > > > > >>>>> routed. In any > > > > > > >>>>>>> event, just like many web pages are simply listed as > > > > > > >>>>>>> www.something.com (instead of http://www.something.com), I > > > > > > >>>>>>> expect that many business cards and directories will > > simply > > > > > > >>>>>>> contain alice at something.com. > > > > > > >>>>>>> > > > > > > >>>>>>> It's the role of protocols to make these resolution > > details > > > > > > >>>>>>> transparent to the user. This isn't terribly > > > > > > >>> difficult in this > > > > > > >>>>>>> particular case. > > > > > > >>>>>>> > > > > > > >>>>>>> Henning > > > > > > >>>>>>> _______________________________________________ > > > > > > >>>>>>> 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 > > > > > > >>>>> > > > > > > >>>> > > > > > > >>> > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 eunsoo at research.panasonic.com Wed Jun 7 11:03:51 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 07 Jun 2006 11:03:51 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606061726.k56HQtX5004712@cs.columbia.edu> References: <200606061726.k56HQtX5004712@cs.columbia.edu> Message-ID: <4486EAD7.4010106@research.panasonic.com> My comments are inline. David Barrett wrote: > Cool. So if this story is used as the scope for P2PSIP v1.0, it means we're > targeting the following definitions and use cases: > > P2PSIP v1.0 Scope > - A "P2PSIP proxy" is constructed by UAs using P2P techniques > . P2PSIP v1.0 supports one type of P2PSIP proxy, based on a DHT > . Future versions of P2PSIP will support non-DHT proxies > Is a P2PSIP proxy a (logical) node or just a service realized using the DHT? > - A "P2PSIP UA" is capable of: > . Creating a new P2PSIP proxy and assigning it a name > . Registering itself with a named P2PSIP proxy > . Advertising its named P2PSIP proxies to neighboring peers Why should P2PSIP UAs advertise its P2PSIP proxies? > o P2PSIP v1.0 supports IP multicast broadcasts If we assume IP multicast or broadcast is available among all the peers, we don't need DHT or any P2P network. > o Future versions will support other broadcast techniques > . Discovering named P2PSIP proxy advertisements from neighboring > peers > . Joining named P2PSIP proxies > . Resolving "sip:" addresses to P2PSIP UAs using P2PSIP proxies > > And really, that's about it. I'd say that future versions include: > Here is what I think. - Nodes with P2PSIP UA and possibly other nodes form a P2P network. . Some of them form a DHT and the rest establish associations with those participating in the DHT. . The DHT does not require IP multicast or broadcast. - There is at least one SIP Proxy in the P2P network (that is called P2PSIP Proxy), which is registered in the DNS for the domain. . The P2PSIP proxy may be one of user devices or a dedicated device setup by some authority of the domain. Registration of the proxy with the DNS requires authorization. - A P2PSIP UA constructs a location record and places it in the P2P network. (This is equivalent to registration and/or advertisement.) - The P2PSIP UAC (the calling UA) resolves "sip:" address into the IP address (and port number) by retrieving the location record of the P2PSIP UAS (the called UA) in the P2P network. . If the UAC is a node participating in the DHT, the node initiates the DHT GET procedure. . If the UAC is not in the DHT, the node sends the lookup request to its associated node in the DHT that initiates the DHT GET procedure. - Once the address resolution is done, the rest of the call setup procedure follows RFC3261. - If the caller is in the remote domain or a C/S SIP UA, it follows RFC3261 and 3263 to locate the SIP Proxy of the domain the UAS belongs. - A P2PSIP Proxy receives an INVITE message destined to a UA in the local domain, it resolves the destination "sip:" address from the P2P network. After that, it follows RFC3261. Is this close to your story? Thanks. Eunsoo > P2PSIP v2.0+ Scope > - A "P2PSIP Gateway" interfaces between P2PSIP proxies and CS SIP UAs > . This is what lets CS UAs contact P2PSIP UAs > > - A "P2PSIP Bootstrapping Server" joins and advertises P2PSIP proxies > . This is what prevents P2PSIP proxies going "dark" > . This also helps rendezvous P2PSIP UAs outside advertisement range > > - P2PSIP UAs look for both P2P and CS proxies for each "sip:" address > . This is what lets P2PSIP UAs contact CS UAs > > - All P2PSIP components incorporate secure authentication, TLS, and so on > > - Variants of P2PSIP proxies using other DHTs (or other P2P algorithms) > > - Variants of P2PSIP proxy advertisement using zeroConf, mDNS, etc. > > > Basically, I propose we circle the wagons *very* tightly around a very small > set of functionality (the smallest possible set that satisfies our use > cases), and focus on that exclusively for P2PSIP v1.0. Once that has been > nailed down, then we open up the floor to discuss bigger topics. > > Does this sound like a reasonable plan? Do you endorse us following it? > > -david > >> -----Original Message----- >> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] >> Sent: Tuesday, June 06, 2006 8:39 AM >> To: David Barrett; Cullen Jennings (fluffy) >> Cc: David A. Bryan; p2p-sip at cs.columbia.edu >> Subject: RE: [p2p-sip] What are we doing, question 2 >> >> Yep, works for me at higher level. Comments ... >> >>> [3] For 1.0, UAs broadcast their network affiliation using IP >> multicast. >> >> We also need to add that discovery would be done thru IP >> multicast. >> Can we say we will leverage existing DNS mechanism - >> specifically use the mDNS primitives for this ? That way we do not have >> to work on another multicast format, port number and associated >> mechanisms. >> We also need to specify couple of DNS record types and >> appropriate formats. May be we can leverage the currently available >> record types and formats. >> >> Still prefer the URI >> sip:@[?dht=]. May be we will say, the FQN >> for fluffy at quinthar is actually >> sip:fluffy at quinthar[[@]] >> >> Should add some form of security mechanism - at least a key >> substrate as a trust bootstrap and encryption as needed. May be TLS is >> enough. >> >>> -----Original Message----- >>> From: David Barrett [mailto:dbarrett at quinthar.com] >>> Sent: Monday, June 05, 2006 11:01 PM >>> To: Cullen Jennings (fluffy) >>> Cc: Krishna Sankar (ksankar); 'David A. Bryan'; >>> p2p-sip at cs.columbia.edu >>> Subject: RE: [p2p-sip] What are we doing, question 2 >>> >>> Well, what I'm trying to accomplish is enunciate a vision for >>> how the product works for a user. Once we agree upon what >>> P2PSIP is supposed to do for the user, then I think we can >>> more easily discuss how to make that happen. >>> >>> With this in mind, here's an updated story for my vision of >>> what a P2PSIP 1.0 UA does: >>> >>> You and I each install a P2PSIP-enabled UA while sitting on >>> the same LAN. I click the "Create a new network" button on >>> my UA, and give it the name "quinthar". [1] It asks me what >>> my name is on this network, and I say "dbarrett". [2] Your UA >>> detects this and lists "quinthar" as one of the known >>> networks, and "dbarrett at quinthar" as a known user. [3] You >>> choose the "quinthar" network and click "Join network", then >>> specify that your name is "fluffy". [4] On my UA, I see >>> "fluffy at quinthar" is listed in as a known user. I double >>> click on "fluffy at quinthar", and initiate a VoIP call. [5] >>> >>> [1] For 1.0, anyone can create a network; later it might be >>> tied to public key encryption. >>> [2] For 1.0, anyone can choose any name when joining a >>> network; later each network might have an administrator. >>> [3] For 1.0, UAs broadcast their network affiliation using IP >>> multicast. >>> Later there might be global network registries, special >>> bootstrapping servers, or even a global DHT set aside to >>> publish networks. >>> [4] For 1.0, anyone can join any network they've discovered, >>> or by entering the IP:port of a node on the network. >>> [5] We've created identities, discovered each other, and >>> initiated a SIP call -- all without ever touching a single server. >>> >>> >>> Does this story basically capture the same product that you >>> want to enable with P2PSIP? If not, can you follow the >>> pattern above and lay out your own story? >>> >>> -david >>> >>>> -----Original Message----- >>>> From: Cullen Jennings [mailto:fluffy at cisco.com] >>>> Sent: Monday, June 05, 2006 5:36 PM >>>> To: David Barrett >>>> Cc: 'Krishna Sankar (ksankar)'; 'David A. Bryan'; >>>> p2p-sip at cs.columbia.edu >>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>> >>>> >>>> Some of the proposal so for have come up with ways to make sip: >>>> addresses work and make things interoperable with more traditional >>>> sip. Clearly having interoperate would be a nice property >>> if possible. >>>> However, I am still lost on what we are trying to accomplish, much >>>> less what the solutions is or if it needs a different URL. >>>> >>>> >>>> On Jun 5, 2006, at 3:32 PM, David Barrett wrote: >>>> >>>>> Again, I love the idea of having a single "sip:" address >>> that "just >>>>> works" >>>>> for both CS and P2P SIP. Please help me understand your proposal >>>>> better. >>>>> >>>>> Will I be able to print my combined CS/P2P SIP address on >>> a business >>>>> card, hand it to you, and have you type it into your SIP >>> UA and get >>>>> an expected result (a valid connection, if it's P2PSIP >>> aware, or a >>>>> message saying "unsupported address type" if not)? If so, what >>>>> might that address look like? >>>>> >>>>> I've proposed your business card might say: >>>>> >>>>> sip:@ >>>>> >>>>> Or >>>>> >>>>> p2psip:[@] [1] >>>>> >>>>> If instead we only use the first format, how does a UA figure out >>>>> which DHT the address is registered with, and how does it >>> connect to >>>>> that DHT? I can imagine URI attributes: >>>>> >>>>> sip:@[?dht=] >>>>> >>>>> And I think this is a great solution. But I don't >>> understand how a >>>>> human would input "header elements" to a UA. Am I >>> misunderstanding >>>>> the proposal? >>>>> >>>>> -david >>>>> >>>>> [1] I've proposed is [@], and that >>>>> it's optional (defaulting to some global DHT if >>> unspecified). But >>>>> the precise syntax is unimportant. What is important is that the >>>>> address contain whatever information is necessary to connect to a >>>>> given DHT. >>>>> >>>>>> -----Original Message----- >>>>>> From: Krishna Sankar (ksankar) [mailto:ksankar at cisco.com] >>>>>> Sent: Monday, June 05, 2006 10:22 AM >>>>>> To: David A. Bryan >>>>>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >>>>>> Subject: RE: [p2p-sip] What are we doing, question 2 >>>>>> >>>>>> Agreed. If we, in-principle, see the need for the >>>>>> p2psip:[@@[]], we can make it as >>>>>> harmless as possible - a set of header elements or a set of URI >>>>>> parameter is an excellent choice. >>>>>> >>>>>> I like header element better - something like : >>>>>> Additional-Format:P2P >>>>>> P2P-DHTName:,,... >>>>>> P2P-BootStrap:,... >>>>>> >>>>>> Cheers >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: davidbryan at gmail.com >>> [mailto:davidbryan at gmail.com] On Behalf >>>>>>> Of David A. Bryan >>>>>>> Sent: Monday, June 05, 2006 10:09 AM >>>>>>> To: Krishna Sankar (ksankar) >>>>>>> Cc: David Barrett; Henning Schulzrinne; p2p-sip at cs.columbia.edu >>>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>>> >>>>>>> If we have a p2psip: address, what does a non-P2P SIP >>> endpoint do >>>>>>> with it? On the otherhand, a regular sip: address can >>> go from a UA >>>>>>> to a proxy that is more likely to be able to do >>> something useful >>>>>>> (forward it to a p2p domain)? See the draft Enrico and I did >>>>>>> (draft-marocco-sipping-p2p-scenarios-00.html) for details. >>>>>>> >>>>>>> We can use maybe use something else in the messages -- >>> a URI param >>>>>>> or a header perhaps -- to distinguish P2P from regular >>> SIP where >>>>>>> needed, but I think we should ensure that a URI is as backward >>>>>>> compliant as possible. >>>>>>> >>>>>>> --David Bryan >>>>>>> >>>>>>> On 6/5/06, Krishna Sankar (ksankar) wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> You have a valid point making p2p-sip explicit for all >>>>>>>> than implicit in the UAs who understand it. >>>>>>>> a) I mulled it over and do not see any other >>>>>>> way, as a 1.0 >>>>>>>> requirement. i.e. we do need a p2p-sip protocol designator >>>>>>> somewhere >>>>>>>> to make it explicit. But not necessarily in one's vcard. >>>>>>>> b) We could make the client responsible >>> for trying the >>>>>>>> generic and then p2p:. >>>>>>>> c) Going back to putting p2psip in one's >>>>>>> vcard, what does >>>>>>>> "p2psip" in one's SIP address signify anyway ? Signifies >>>>>>> that one will >>>>>>>> be part of a p2psip as and when available ? >>>>>>>> d) Isn't p2psip situational ? i.e. when one is >>>>>>> at home, may >>>>>>>> be, one will be part of the p2psip provided by the service >>>>>>> provider or >>>>>>>> even the home network; but when one is at work, one becomes >>>>>>> part of a >>>>>>>> server based larger sip substrate. >>>>>>>> What about an emergency worker who >>> moves between >>>>>>>> different p2psip and sip networks ? >>>>>>>> >>>>>>>> What about a mobile worker who wanders from >>>>>>> Starbucks >>>>>>>> network to airport network to .. All might have >>> different p2psip >>>>>>>> mechanisms or even a combination of p2psip and server >>> based sip. >>>>>>>> May be I got it all wrong (mice crunching cats are >>>>>>> the norm of >>>>>>>> the day than galloping stallions) - very possible ... >>>>>>>> Cheers >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: p2p-sip-bounces at cs.columbia.edu >>>>>>>>> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of >>>>>>> David Barrett >>>>>>>>> Sent: Monday, June 05, 2006 8:58 AM >>>>>>>>> To: 'David A. Bryan'; 'Henning Schulzrinne' >>>>>>>>> Cc: p2p-sip at cs.columbia.edu >>>>>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>>>>> >>>>>>>>> Ok, I'll totally agree that it'd be nice to hide the >>> details of >>>>>>>>> P2PSIP behind a standard "sip:" address (expressed or >>>>>>> implied). I >>>>>>>>> just haven't envisioned how to accomplish this in >>>>>>> conjunction with >>>>>>>>> the other requirements, and I'm trying to avoid >>> proposing what I >>>>>>>>> can't figure out how to build. >>>>>>>>> >>>>>>>>> The problem I see isn't one of technology, but >>> usability issues >>>>>>>>> caused in the adoption period. Clearly, P2PSIP isn't >>> going to >>>>>>>>> happen overnight. >>>>>>>>> There will be period of years where it is slowly rolled >>>>>>> out to SIP >>>>>>>>> UAs. And during this period, I think it's important >>> for a UA to >>>>>>>>> differentiate between invalid SIP addresses, and P2PSIP >>>>>>>>> addresses that it doesn't know how to handle. >>>>>>>>> >>>>>>>>> For example, let's assume I put my P2PSIP address on a >>>>>>> business card >>>>>>>>> as "sip:dbarrett at quinthar.com" (or just >>>>>>> "dbarrett at quinthar.com" with >>>>>>>>> the "sip:" >>>>>>>>> implied). A P2PSIP-aware UA might first look for a >>>>>>> traditional SIP >>>>>>>>> proxy at "quinthar.com" and then, not finding one, use some >>>>>>>>> DHT-based mechanism. I love that idea. >>>>>>>>> >>>>>>>>> But a P2PSIP-unaware UA will just break. It'll say the >>>>>>> address is >>>>>>>>> valid and supported, but broken. I don't love this idea. >>>>>>>>> >>>>>>>>> Thus I'm proposing, at least at the start while P2PSIP is >>>>>>>>> getting its legs, we use "p2psip:". A >>> P2PSIP-aware >>>>>>>>> UA >>>>>>> will work, >>>>>>>>> and a P2PSIP-unaware UA can clearly say "I don't support this >>>>>>>>> address type". The blame is placed on the UA (where it >>>>>>> should be), >>>>>>>>> rather than the address. >>>>>>>>> >>>>>>>>> Maybe in the future, once P2PSIP is more established, >>> UAs would >>>>>>>>> automatically retry all failed "sip:" >>>>>>>>> addresses on some P2PSIP framework, and then the two >>>>>>> addresses would >>>>>>>>> converge down the road. >>>>>>>>> >>>>>>>>> But I'm not sure how we can start out converged without just >>>>>>>>> confusing the user and, ultimately, hurting the SIP >>>>>>> community as a >>>>>>>>> whole -- P2P and otherwise. >>>>>>>>> >>>>>>>>> Have I missed something? Can you see a way to roll out >>>>>>> P2PSIP atop >>>>>>>>> a standard "sip:" address without >>> appearing totally >>>>>>>>> broken throughout the deployment period? >>>>>>>>> >>>>>>>>> -david >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On >>>>>>>>> Behalf Of >>>>>>>>>> David A. Bryan >>>>>>>>>> Sent: Monday, June 05, 2006 7:29 AM >>>>>>>>>> To: Henning Schulzrinne >>>>>>>>>> Cc: David Barrett; p2p-sip at cs.columbia.edu >>>>>>>>>> Subject: Re: [p2p-sip] What are we doing, question 2 >>>>>>>>>> >>>>>>>>>> I would agree, and would add a subtly different >>>>>>> objection that a >>>>>>>>>> traditional SIP UA will be better able to interact with >>>>>>> a P2PSIP >>>>>>>>>> endpoint if we have a simple "sip:" or "sips:" (however that >>>>>>>>>> debate hashes out). >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 6/5/06, Henning Schulzrinne wrote: >>>>>>>>>>>> I'd prefer not to debate the specifics at this point -- >>>>>>>>> if we can >>>>>>>>>>>> agree that there's some kind of "p2psip:" >>>>>>>>> address type, >>>>>>>>>>>> I think that's as deep as we need to get agreement >>>>>>> on the big >>>>>>>>>>>> picture. >>>>>>>>>>> I think this is a fundamentally bad idea. I shouldn't >>>>>>>>> have to change >>>>>>>>>>> my address (and business card) just because I'm changing >>>>>>>>> some low- >>>>>>>>>>> level technical detail of how signaling requests are >>>>>>>>> routed. In any >>>>>>>>>>> event, just like many web pages are simply listed as >>>>>>>>>>> www.something.com (instead of http://www.something.com), I >>>>>>>>>>> expect that many business cards and directories will simply >>>>>>>>>>> contain alice at something.com. >>>>>>>>>>> >>>>>>>>>>> It's the role of protocols to make these resolution details >>>>>>>>>>> transparent to the user. This isn't terribly >>>>>>> difficult in this >>>>>>>>>>> particular case. >>>>>>>>>>> >>>>>>>>>>> Henning >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>> _______________________________________________ >>>>> 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 fluffy at cisco.com Wed Jun 7 09:03:50 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 7 Jun 2006 06:03:50 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <4ucqkp$8ob2ib@sj-inbound-d.cisco.com> References: <4ucqkp$8ob2ib@sj-inbound-d.cisco.com> Message-ID: David - I think that is a great scenario for describing what we might be trying to do - and we need it at about this level of detail. If we had good agreement on something like this, we would be much closer. I suspect from what I have heard so far, many folks on the list would be interested in this working when the two users are not within multicast reach of each-other and others would like it to work when the root DNS was not reachable. On Jun 5, 2006, at 11:00 PM, David Barrett wrote: > Well, what I'm trying to accomplish is enunciate a vision for how the > product works for a user. Once we agree upon what P2PSIP is > supposed to do > for the user, then I think we can more easily discuss how to make that > happen. > > With this in mind, here's an updated story for my vision of what a > P2PSIP > 1.0 UA does: > > You and I each install a P2PSIP-enabled UA while sitting on the > same LAN. I > click the "Create a new network" button on my UA, and give it the name > "quinthar". [1] It asks me what my name is on this network, and I say > "dbarrett". [2] Your UA detects this and lists "quinthar" as one of > the > known networks, and "dbarrett at quinthar" as a known user. [3] You > choose the > "quinthar" network and click "Join network", then specify that your > name is > "fluffy". [4] On my UA, I see "fluffy at quinthar" is listed in as a > known > user. I double click on "fluffy at quinthar", and initiate a VoIP > call. [5] > > [1] For 1.0, anyone can create a network; later it might be tied to > public > key encryption. > [2] For 1.0, anyone can choose any name when joining a network; > later each > network might have an administrator. > [3] For 1.0, UAs broadcast their network affiliation using IP > multicast. > Later there might be global network registries, special bootstrapping > servers, or even a global DHT set aside to publish networks. > [4] For 1.0, anyone can join any network they've discovered, or by > entering > the IP:port of a node on the network. > [5] We've created identities, discovered each other, and initiated > a SIP > call -- all without ever touching a single server. > > > Does this story basically capture the same product that you want to > enable > with P2PSIP? If not, can you follow the pattern above and lay out > your own > story? > > -david From fluffy at cisco.com Wed Jun 7 08:13:20 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 7 Jun 2006 05:13:20 -0700 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> Message-ID: <6441E006-B0C0-4DF2-AAFF-2354CED79239@cisco.com> Dean - thanks for getting this done. On Jun 6, 2006, at 10:32 PM, Dean Willis wrote: > > David Bryan, Eunsoo Shim, Philip Matthews and I have spent about > 100 hours of conference bridge time trying to come to a rough > consensus on what we're talking about, with Henning and Cullen > popping in for a few dozen hours each. I finally wrote it all down > in a draft format, leaving lots of questions listed but unanswered, > and got them to agree that it was at least sort of close to what > they were thinking. It was somewhat like pulling the hind teeth out > of an angry moose using nothing but Swiss Army Knife tweezers (or > at least like I imagine that might be, not having been so daring > myself), but now we have a document for the rest of you to shred, > which I'm sure you will. > > It'll be on the IETF draft site soon. In the meantime, check out: > > http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- > concepts-00.html > http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- > concepts-00.txt > http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- > concepts-00.xml > > > -- > Dean From huang-ming.pan at comcast.net Wed Jun 7 12:34:02 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 7 Jun 2006 09:34:02 -0700 Subject: [p2p-sip] p2p-sip Digest, Vol 11, Issue 18 References: Message-ID: <002f01c68a50$2fb1dc40$6400a8c0@comcast.net> The diagram in "3.2. Reference Model" looks beautiful (but also intimidating like the one seen in IMS). Very sure that systems designed following this architecture and these concepts will be wonderful per aesthetics of computer science, as long as all questions listed therein can be solved (with no doubt). Me just needing to think about the reason why somewhere else now there is a system, single and uniform, running also beautifully without ample node types and resplendent architecture. Peter ----- Original Message ----- From: To: Sent: Wednesday, June 07, 2006 6:49 AM Subject: p2p-sip Digest, Vol 11, Issue 18 > Send p2p-sip mailing list submissions to > p2p-sip at cs.columbia.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > or, via email, send a message with subject or body 'help' to > p2p-sip-request at cs.columbia.edu > > You can reach the person managing the list at > p2p-sip-owner at cs.columbia.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of p2p-sip digest..." > ---------------------------------------------------------------------------- ---- > Today's Topics: > > 1. P2PSIP Concepts and terminology draft posted (Dean Willis) > 2. Re: What are we doing, question 2 (David Barrett) > 3. Re: What are we doing, question 2 (Medhavi Bhatia) > ---------------------------------------------------------------------------- ---- > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From enrico.marocco at telecomitalia.it Wed Jun 7 12:47:30 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 07 Jun 2006 18:47:30 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> Message-ID: <44870322.5080105@telecomitalia.it> Dean Willis wrote: > David Bryan, Eunsoo Shim, Philip Matthews and I have spent about 100 > hours of conference bridge time trying to come to a rough consensus > on what we're talking about, with Henning and Cullen popping in for a > few dozen hours each. I finally wrote it all down in a draft format, > leaving lots of questions listed but unanswered, and got them to > agree that it was at least sort of close to what they were thinking. > It was somewhat like pulling the hind teeth out of an angry moose > using nothing but Swiss Army Knife tweezers (or at least like I > imagine that might be, not having been so daring myself), but now we > have a document for the rest of you to shred, which I'm sure you will. The document is very good and I think it will be very useful. But... there's one thing I fail to understand. Given the distinction between clients and peers -- which I don't like but accept -- why do you define the client protocol as a subset of the peer protocol? I can only figure a clear division with doGet, doPut, doSend on the client side and serveGet, servePut, serveSend plus whatever is needed for their implementation (e.g. doJoin, serveJoin...) on the peer side. Keeping them functionally complementary rather than alternative helps in distinguishing the roles of peers and clients. Just some more minor typos from a quick read: + In P2PSIP Overlay Bootstrap Server definition (sec. 2), in the Example you write "...uses a P2PSIP Overlay Bootstrap Server other peers..."; something like "to discover" is missing. + Item 4 of the list in sec. 3.1 restricts the redirection to INVITE messages; I'd substitute "INVITE" with "request message". + In the last sentence of the first paragraph in sec. 3.3.2 "(get)" and "(put)" are inverted. Enrico From bryan at ethernot.org Wed Jun 7 13:03:46 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 7 Jun 2006 13:03:46 -0400 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44870322.5080105@telecomitalia.it> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> Message-ID: <8b2769930606071003v4acd9626m29a1b422317fe292@mail.gmail.com> > But... there's one thing I fail to understand. Given the distinction > between clients and peers -- which I don't like but accept -- why do you > define the client protocol as a subset of the peer protocol? I can only > figure a clear division with doGet, doPut, doSend on the client side and > serveGet, servePut, serveSend plus whatever is needed for their > implementation (e.g. doJoin, serveJoin...) on the peer side. Keeping > them functionally complementary rather than alternative helps in > distinguishing the roles of peers and clients. I think the reason folks stressed that was that in such a design, the get/put functions of the clients would also be needed between the peers, if nothing else for those peers that had associated UAs. They likely also need the same sort of primitive to move information between themselves as peers join and leave. Personally, if we did do clients and peers, I would hope that the client protocol was either SIP or else a proper subset of the peer protocol, such that peers did everything that clients did, and then some more. David Bryan > > Just some more minor typos from a quick read: > + In P2PSIP Overlay Bootstrap Server definition (sec. 2), in the Example > you write "...uses a P2PSIP Overlay Bootstrap Server other peers..."; > something like "to discover" is missing. > + Item 4 of the list in sec. 3.1 restricts the redirection to INVITE > messages; I'd substitute "INVITE" with "request message". > + In the last sentence of the first paragraph in sec. 3.3.2 "(get)" and > "(put)" are inverted. > > Enrico > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From huang-ming.pan at comcast.net Wed Jun 7 13:17:00 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 7 Jun 2006 10:17:00 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606061726.k56HQtX5004712@cs.columbia.edu> <4486EAD7.4010106@research.panasonic.com> Message-ID: <004a01c68a56$30c2a140$6400a8c0@comcast.net> some q's inline. 3q! > Here is what I think. > . The DHT does not require IP multicast or broadcast. > - There is at least one SIP Proxy in the P2P network (that is called > P2PSIP Proxy), which is registered in the DNS for the domain. [pp]: shouldn't hardcoded ip should be more recommended than dns to minimize p2psip's dependency on server? > - A P2PSIP UA constructs a location record and places it in the P2P > network. (This is equivalent to registration and/or advertisement.) [pp]: the registration/advertisement between on-sn and sn-sn seems likely different. could you elaborate the details of p2psip in this aspect? > - Once the address resolution is done, the rest of the call setup > procedure follows RFC3261. [pp]: are you sure that the thing is then as so simple as the session initiation in c/s environment where there is usually sbc or special proxy/b2bua to manipulate firewall penetration, not to mention most desired supplementary call features? peter From bryan at ethernot.org Wed Jun 7 13:28:12 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 7 Jun 2006 13:28:12 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <004a01c68a56$30c2a140$6400a8c0@comcast.net> References: <200606061726.k56HQtX5004712@cs.columbia.edu> <4486EAD7.4010106@research.panasonic.com> <004a01c68a56$30c2a140$6400a8c0@comcast.net> Message-ID: <8b2769930606071028w3d63b4b5y1fe78cc090ee36cd@mail.gmail.com> At risk of having one David answer on behalf of another ;) My opinion is that we will need to avail ourselves of the ICE-family tools to do NAT traversal since as you point out, we are not likely to have SBCs in the picture. The odds are that using the ICE stuff will be far more critical for P2P systems than CS where things like SBCs can be used as band aids for the problem. As far as features, a few comments. Some I think will work quite transparently with P2PSIP -- transfers of various types, redirects on busy/unavailable, call forward. Some others are likely to be far more challenging -- obviously VM being one -- but features like this aren't always specified in the protocols anyway -- look at SIP where many are not specified directly in the protocol. Forking (so multiple appearance) is another that will be interesting and I can imagine may need to be treated differently in a P2P than CS scenario. In my vision for this, if a feature works as is or can be made to work with essentially no changes, P2P should not reinvent the wheel. Only do that for features that are truly dependent on servers in traditional CS SIP. David Bryan On 6/7/06, Peter Pan wrote: > some q's inline. 3q! > > > Here is what I think. > > . The DHT does not require IP multicast or broadcast. > > - There is at least one SIP Proxy in the P2P network (that is called > > P2PSIP Proxy), which is registered in the DNS for the domain. > > [pp]: shouldn't hardcoded ip should be more recommended than dns to minimize > p2psip's dependency on server? > > > - A P2PSIP UA constructs a location record and places it in the P2P > > network. (This is equivalent to registration and/or advertisement.) > > [pp]: the registration/advertisement between on-sn and sn-sn seems likely > different. could you elaborate the details of p2psip in this aspect? > > > - Once the address resolution is done, the rest of the call setup > > procedure follows RFC3261. > > [pp]: are you sure that the thing is then as so simple as the session > initiation in c/s environment where there is usually sbc or special > proxy/b2bua to manipulate firewall penetration, not to mention most desired > supplementary call features? > > peter > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From eunsoo at research.panasonic.com Wed Jun 7 14:10:24 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 07 Jun 2006 14:10:24 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <8b2769930606071028w3d63b4b5y1fe78cc090ee36cd@mail.gmail.com> References: <200606061726.k56HQtX5004712@cs.columbia.edu> <4486EAD7.4010106@research.panasonic.com> <004a01c68a56$30c2a140$6400a8c0@comcast.net> <8b2769930606071028w3d63b4b5y1fe78cc090ee36cd@mail.gmail.com> Message-ID: <44871690.3070207@research.panasonic.com> My comments are inline. David A. Bryan wrote: > At risk of having one David answer on behalf of another ;) > > My opinion is that we will need to avail ourselves of the ICE-family > tools to do NAT traversal since as you point out, we are not likely to > have SBCs in the picture. The odds are that using the ICE stuff will > be far more critical for P2P systems than CS where things like SBCs > can be used as band aids for the problem. > > As far as features, a few comments. Some I think will work quite > transparently with P2PSIP -- transfers of various types, redirects on > busy/unavailable, call forward. Some others are likely to be far more > challenging -- obviously VM being one -- but features like this aren't > always specified in the protocols anyway -- look at SIP where many are > not specified directly in the protocol. Forking (so multiple > appearance) is another that will be interesting and I can imagine may > need to be treated differently in a P2P than CS scenario. > > In my vision for this, if a feature works as is or can be made to work > with essentially no changes, P2P should not reinvent the wheel. Only > do that for features that are truly dependent on servers in > traditional CS SIP. > > David Bryan > I agree to the above answer. When I said "follows RFC3261", I meant basic call features that can be implemented with RFC3261. > On 6/7/06, Peter Pan wrote: >> some q's inline. 3q! >> >> > Here is what I think. >> > . The DHT does not require IP multicast or broadcast. >> > - There is at least one SIP Proxy in the P2P network (that is called >> > P2PSIP Proxy), which is registered in the DNS for the domain. >> >> [pp]: shouldn't hardcoded ip should be more recommended than dns to >> minimize >> p2psip's dependency on server? Hardcoding or manual configuration is always possible and I guess it should be used or supported as the base method. But I think it is really recommended to register the SIP Proxy in the DNS so that UAs in the remote domain can find the SIP Proxy as well. If you want to run an isolated P2PSIP network, you don't need the SIP Proxy to be registered in the DNS. >> >> > - A P2PSIP UA constructs a location record and places it in the P2P >> > network. (This is equivalent to registration and/or advertisement.) >> >> [pp]: the registration/advertisement between on-sn and sn-sn seems likely >> different. could you elaborate the details of p2psip in this aspect? >> ON-SN interaction is basically exchange of requests replies for GET/PUT. SN-SN interaction deals with GET/PUT requests and replies, JOIN/LEAVE requests and replies, and routing of all those messages. I think GET and PUT just deal with keys (or target (resource)record names as just byte strings) and values no matter whether the message exchange occur and they are independent of the semantics of the values. Registration/advertisement is nothing but the PUT operation for the user location record. Therefore, except the possible syntax difference between GET/PUT messages on ON-SN and SN-SN, the PUT messages or the registration/advertisement are almost the same on both ON-SN and SN-SN. Did I answer your question? >> > - Once the address resolution is done, the rest of the call setup >> > procedure follows RFC3261. >> >> [pp]: are you sure that the thing is then as so simple as the session >> initiation in c/s environment where there is usually sbc or special >> proxy/b2bua to manipulate firewall penetration, not to mention most >> desired >> supplementary call features? >> Thanks. Eunsoo From huang-ming.pan at comcast.net Wed Jun 7 14:14:27 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 7 Jun 2006 11:14:27 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <200606061726.k56HQtX5004712@cs.columbia.edu> <4486EAD7.4010106@research.panasonic.com> <004a01c68a56$30c2a140$6400a8c0@comcast.net> <8b2769930606071028w3d63b4b5y1fe78cc090ee36cd@mail.gmail.com> Message-ID: <006601c68a5e$370214c0$6400a8c0@comcast.net> 3q for the comfort. ----- Original Message ----- From: "David A. Bryan" To: "Peter Pan" Cc: "Eunsoo Shim" ; "David Barrett" ; Sent: Wednesday, June 07, 2006 10:28 AM Subject: Re: [p2p-sip] What are we doing, question 2 > At risk of having one David answer on behalf of another ;) > > My opinion is that we will need to avail ourselves of the ICE-family > tools to do NAT traversal since as you point out, we are not likely to > have SBCs in the picture. The odds are that using the ICE stuff will > be far more critical for P2P systems than CS where things like SBCs > can be used as band aids for the problem. > > As far as features, a few comments. Some I think will work quite > transparently with P2PSIP -- transfers of various types, redirects on > busy/unavailable, call forward. Some others are likely to be far more > challenging -- obviously VM being one -- but features like this aren't > always specified in the protocols anyway -- look at SIP where many are [pp]: Yes or no, imo. The reasons why sip seemingly cover all scenarios so far without twisting itself are, among others: * There are trucks of "informative" drafts and RFCs to supplement RFC3261; these informative specs are helpful but also bring "informative" incompatibilities among existing SIP systems or service networks. * Usually it is the "feature" servers (like those b2bua based call managers by broadsoft/sylantro/avaya/nortel/...) in c/s softswitch systems that bridge the incompleteness of rfc3261 by means of the primitives defined in rfc3261 and other RFCs. In p2psip territory, there seems no more such "manipulators". The manipulation will likely be done by p2psip nodes alone. > not specified directly in the protocol. Forking (so multiple > appearance) is another that will be interesting and I can imagine may > need to be treated differently in a P2P than CS scenario. > > In my vision for this, if a feature works as is or can be made to work > with essentially no changes, P2P should not reinvent the wheel. Only > do that for features that are truly dependent on servers in > traditional CS SIP. [pp]: Do you have kindly something persuasive other than vision and promise which can ease this long-term concern (backward compitibility of incremental p2psip protocol) of mine, for example, technical paper or open-source reference implementation (that has been able to add most well-known call features without changing architecture/protocol/implementation too much)? I will really appreciate it since i've been always believing that p2psip is not initiated for basic session initiation only. peter From eunsoo at research.panasonic.com Wed Jun 7 14:18:19 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 07 Jun 2006 14:18:19 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: References: <4ucqkp$8ob2ib@sj-inbound-d.cisco.com> Message-ID: <4487186B.8070802@research.panasonic.com> I am one of those who like to see P2PSIP working beyond the reach of IP multcast or the access to the root DNS. Thanks. Eunsoo Cullen Jennings wrote: > David - I think that is a great scenario for describing what we might > be trying to do - and we need it at about this level of detail. If we > had good agreement on something like this, we would be much closer. > > I suspect from what I have heard so far, many folks on the list would > be interested in this working when the two users are not within > multicast reach of each-other and others would like it to work when > the root DNS was not reachable. > > > > On Jun 5, 2006, at 11:00 PM, David Barrett wrote: > >> Well, what I'm trying to accomplish is enunciate a vision for how the >> product works for a user. Once we agree upon what P2PSIP is >> supposed to do >> for the user, then I think we can more easily discuss how to make that >> happen. >> >> With this in mind, here's an updated story for my vision of what a >> P2PSIP >> 1.0 UA does: >> >> You and I each install a P2PSIP-enabled UA while sitting on the >> same LAN. I >> click the "Create a new network" button on my UA, and give it the name >> "quinthar". [1] It asks me what my name is on this network, and I say >> "dbarrett". [2] Your UA detects this and lists "quinthar" as one of >> the >> known networks, and "dbarrett at quinthar" as a known user. [3] You >> choose the >> "quinthar" network and click "Join network", then specify that your >> name is >> "fluffy". [4] On my UA, I see "fluffy at quinthar" is listed in as a >> known >> user. I double click on "fluffy at quinthar", and initiate a VoIP >> call. [5] >> >> [1] For 1.0, anyone can create a network; later it might be tied to >> public >> key encryption. >> [2] For 1.0, anyone can choose any name when joining a network; >> later each >> network might have an administrator. >> [3] For 1.0, UAs broadcast their network affiliation using IP >> multicast. >> Later there might be global network registries, special bootstrapping >> servers, or even a global DHT set aside to publish networks. >> [4] For 1.0, anyone can join any network they've discovered, or by >> entering >> the IP:port of a node on the network. >> [5] We've created identities, discovered each other, and initiated >> a SIP >> call -- all without ever touching a single server. >> >> >> Does this story basically capture the same product that you want to >> enable >> with P2PSIP? If not, can you follow the pattern above and lay out >> your own >> story? >> >> -david > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From dean.willis at softarmor.com Wed Jun 7 14:23:16 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 7 Jun 2006 13:23:16 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44870322.5080105@telecomitalia.it> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> Message-ID: <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> On Jun 7, 2006, at 11:47 AM, Enrico Marocco wrote: > Dean Willis wrote: >> David Bryan, Eunsoo Shim, Philip Matthews and I have spent about 100 >> hours of conference bridge time trying to come to a rough consensus >> on what we're talking about, with Henning and Cullen popping in for a >> few dozen hours each. I finally wrote it all down in a draft format, >> leaving lots of questions listed but unanswered, and got them to >> agree that it was at least sort of close to what they were thinking. >> It was somewhat like pulling the hind teeth out of an angry moose >> using nothing but Swiss Army Knife tweezers (or at least like I >> imagine that might be, not having been so daring myself), but now we >> have a document for the rest of you to shred, which I'm sure you >> will. > > The document is very good and I think it will be very useful. > > But... there's one thing I fail to understand. Given the distinction > between clients and peers -- which I don't like but accept -- why > do you > define the client protocol as a subset of the peer protocol? I can > only > figure a clear division with doGet, doPut, doSend on the client > side and > serveGet, servePut, serveSend plus whatever is needed for their > implementation (e.g. doJoin, serveJoin...) on the peer side. Keeping > them functionally complementary rather than alternative helps in > distinguishing the roles of peers and clients. It's a "functional subset", not necessarily a syntactic subset. All of the functions that the client protocol would perform would also be needed in the peer protocol. But the peer protocol would need some additional functions. > > Just some more minor typos from a quick read: > + In P2PSIP Overlay Bootstrap Server definition (sec. 2), in the > Example > you write "...uses a P2PSIP Overlay Bootstrap Server other > peers..."; > something like "to discover" is missing. yes indeed. > + Item 4 of the list in sec. 3.1 restricts the redirection to INVITE > messages; I'd substitute "INVITE" with "request message". > Reasonable. > + In the last sentence of the first paragraph in sec. 3.3.2 "(get)" > and > "(put)" are inverted. > Far out. Thanks, -- Dean From dbarrett at quinthar.com Wed Jun 7 14:44:27 2006 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 7 Jun 2006 11:44:27 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <4486EAD7.4010106@research.panasonic.com> Message-ID: <200606071845.k57IitX5014164@cs.columbia.edu> > -----Original Message----- > From: Eunsoo Shim > > Is a P2PSIP proxy a (logical) node or just a service realized using the > DHT? Service realized using the DHT. I believe Dean's document called it an "overlay"; that's a better name. > If we assume IP multicast or broadcast is available among all the peers, > we don't need DHT or any P2P network. Clearly. I've proposed multicast as an overlay advertisement scheme just for v1.0. Bootstrapping servers and DNS would be other ways to learn of and connect to overlays, but to minimize scope I've left them out of v1.0. Basically, I feel the goal of P2PSIP is to work without *any* servers (including DNS), thus v1.0 scope reflects this. Naturally if servers are available (DNS, bootstrapping, etc) it'll use those too, but those are essentially optimizations (and thus v2.0 and beyond). > Here is what I think. > ... > > Is this close to your story? I largely agree with you, but I disagree in the timing. I'm proposing we first build a solution that works on the worst-case network (two laptops in the middle of the desert connected by a crossover cable), and then improve upon that. This is reflected in my proposal for v1.0 scope. I believe you present great options for "eventually", but it seems like a big bite to swallow all at once. -david From dbarrett at quinthar.com Wed Jun 7 14:49:10 2006 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 7 Jun 2006 11:49:10 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: Message-ID: <200606071849.k57InbX5020695@cs.columbia.edu> > -----Original Message----- > From: Cullen Jennings [mailto:fluffy at cisco.com] > > David - I think that is a great scenario for describing what we might > be trying to do - and we need it at about this level of detail. If we > had good agreement on something like this, we would be much closer. > > I suspect from what I have heard so far, many folks on the list would > be interested in this working when the two users are not within > multicast reach of each-other and others would like it to work when > the root DNS was not reachable. Totally agree. I'm proposing this is part of v2.0+ scope. After all, client server SIP works great across the internet; we know how to solve that problem. Where client server doesn't work is in environments with no DNS, no persistent servers, etc. Indeed, I believe this is the whole goal behind P2PSIP. Thus I propose rather than starting with a best-case network (that has access to central servers in the form of DNS, proxies, bootstrapping services, etc) and work out, we instead start with a worst-case network (two laptops in the desert) and work back. -david From dbarrett at quinthar.com Wed Jun 7 14:55:05 2006 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 7 Jun 2006 11:55:05 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <894e079b0606070645x14bea3ccu498a4ec206ea79d7@mail.gmail.com> Message-ID: <200606071855.k57ItUX5023224@cs.columbia.edu> > -----Original Message----- > From: medhavib at gmail.com > > Hi Dave, > > Another set of clarifications: > > Why do we need the notion of a P2P SIP Proxy if we all agree the SIP > UA to DHT protocol exists? The SIP Proxies can exist and continue to > be used as it is in the SIP protocol specs. I think this comes back to the question of whether the P2PSIP proxy (or, I prefer Dean's terminology, the P2PSIP overlay network) is built using extensions to SIP or using a new protocol. I'm proposing the former (we build the overlay using extensions to SIP messages between UAs). > Another one: Why do we need a P2PSIP UA? Do you propose to change the > SIP state machines at the UA or any of the ways SIP will be used > between UAs in the P2P world? The only thing I forsee is the tinkering > of RFC 3263. In short, yes, I propose the state machine and messages of a P2PSIP UA will be different than those of a normal SIP UA. Clearly, the goal is to keep them as similar as possible, but they do different things and thus will need to differ: - A P2PSIP UA will have logic and messages to resolve "sip:" addresses using a DHT. - A traditional SIP UA will have messages and logic to resolve "sip:" addresses using a client-server SIP proxy. The long-term goal will to have UAs capable of speaking both languages (using both a P2PSIP overlay network as well as traditional client-server SIP proxies), but I'm proposing this is not tackled in v1.0. -david From RADHIKA.R.ROY at saic.com Wed Jun 7 15:02:43 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Wed, 7 Jun 2006 15:02:43 -0400 Subject: [p2p-sip] draft-willis-p2psip-concepts-00: Issues and Resolution s Message-ID: <62D92A9A02BCC845B202323D49A48426230E12@0591-ITS-EXMP02.us.saic.com> Hi, David: The above draft is providing a reference based on which, I believe, we are proceeding. Some important discussions are already on in this mailing list to work the next step for the p2pSIP protocol development. We hope that you will keep a list of issues being discussed and their possible resolutions where possible. After a while, please publish those in a document, as a WG does, which can be accessed by all of us. In this way, the progress that will be made will be recoded very clearly, and the subsequent steps can be taken clearly (without repeating the same issues again and again). Best regards, Radhika R. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060607/1aec8729/attachment.html From enrico.marocco at telecomitalia.it Wed Jun 7 15:30:01 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Wed, 07 Jun 2006 21:30:01 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> Message-ID: <44872939.3080407@telecomitalia.it> Dean Willis wrote: >> But... there's one thing I fail to understand. Given the distinction >> between clients and peers -- which I don't like but accept -- why do you >> define the client protocol as a subset of the peer protocol? I can only >> figure a clear division with doGet, doPut, doSend on the client side and >> serveGet, servePut, serveSend plus whatever is needed for their >> implementation (e.g. doJoin, serveJoin...) on the peer side. Keeping >> them functionally complementary rather than alternative helps in >> distinguishing the roles of peers and clients. > > > It's a "functional subset", not necessarily a syntactic subset. All of > the functions that the client protocol would perform would also be > needed in the peer protocol. But the peer protocol would need some > additional functions. In some cases (e.g. iterative chord) the peer protocol wouldn't need a get function. Ok, I know there's not much difference, but the picture would be fairly clearer, at least to me, with a straight separation between the P2P layer, place of peers, and the SIP layer, place of clients. Needless to say, I'd love to see both a peer and a client on the same device where the UA is. Anyway, I think that such a document was defenitly needed. Please ignore my distinction, if it exists only in my mind ;-) Enrico From matthew at matthew.at Wed Jun 7 15:37:23 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 7 Jun 2006 12:37:23 -0700 (PDT) Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606071845.k57IitX5014164@cs.columbia.edu> Message-ID: <200606071937.k57JbNK26464@where.matthew.at> David Barrett: > I'm proposing we first build a solution that works on the worst-case network > (two laptops in the middle of the desert connected by a crossover cable), > and then improve upon that. This is reflected in my proposal for v1.0 > scope. That isn't "worst case" at all, since they can easily find one another via link-level broadcast or multicast. There are clearly two orthogonal problems that need solving, but which are solved in different ways: (and I know this has been brought up on the list before, but calling the above the "worst case" seems to demonstrate that the orthogonality isn't fully clear) 1) Everyone who wants to call each other is on a network that is not attached to the larger Internet (so, for instance, DNS roots are unavailable and PKI must be local) This has subproblems: 1a) Those people are all on a network that has link-level connectivity sufficient that multicast or broadcast can be used to find neighbors (easy) 1b) Those people are on a routed WAN that has inter-node connectivity incapable of supporting multicast (hard, may only be solvable with manual entry of rendezvous node(s) or neighbor(s)) 2) Everyone who wants to call each other is on a network that *is* attached to the larger Internet, but for {political, economic, other} reasons do not want to use SIP proxies run by other parties or run their own individual SIP proxies associated with their own DNS name(s). An obvious driver for this is the case where you want to run a network with tens of millions of registered users and millions of simultaneous online users, but you don't want to deploy the SIP proxy infrastructure that would be required. The "worst case" for part 1 is probably the "1b" scenario. The "worst case" for part 2 is probably when an attacker decides to see if they can corrupt your (published protocol) distributed lookup system, unless scaling or churn limits get you first. Matthew Kaufman matthew at matthew.at http://www.amicima.com From dean.willis at softarmor.com Wed Jun 7 16:17:56 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 7 Jun 2006 15:17:56 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44872939.3080407@telecomitalia.it> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> <44872939.3080407@telecomitalia.it> Message-ID: On Jun 7, 2006, at 2:30 PM, Enrico Marocco wrote: > Dean Willis wrote: >>> But... there's one thing I fail to understand. Given the >>> distinction >>> between clients and peers -- which I don't like but accept -- why >>> do you >>> define the client protocol as a subset of the peer protocol? I >>> can only >>> figure a clear division with doGet, doPut, doSend on the client >>> side and >>> serveGet, servePut, serveSend plus whatever is needed for their >>> implementation (e.g. doJoin, serveJoin...) on the peer side. >>> Keeping >>> them functionally complementary rather than alternative helps in >>> distinguishing the roles of peers and clients. >> >> >> It's a "functional subset", not necessarily a syntactic subset. >> All of >> the functions that the client protocol would perform would also be >> needed in the peer protocol. But the peer protocol would need some >> additional functions. > > In some cases (e.g. iterative chord) the peer protocol wouldn't need a > get function. > > Ok, I know there's not much difference, but the picture would be > fairly > clearer, at least to me, with a straight separation between the P2P > layer, place of peers, and the SIP layer, place of clients. > Needless to > say, I'd love to see both a peer and a client on the same device where > the UA is. This is a good question, and one the David/Eunsoo/Philip/Dean calls went around and around on. I ended up with three different abstract beasties: A "peer" that fully participates in the P2PSIP overlay, including storing stuff and routing stuff for other nodes (if recursive routing is used). A "client" that knows about the P2PSIP overlay , but just uses it instead of contributing to it. a "user agent" that knows how to do SIP stuff, and might be coupled to a peer or a client so it can use the P2PSIP Overlay in addition to conventional client-server SIP. I originally had a single-layer model, then two (peer and client, where the client contained a UA), then moved to the three layer model to encompass the range of concepts in the discussion. Do we need "client" nodes? They're certainly not required in all deployment scenarios, but they might be useful in other scenarios. For example, in an environment where some nodes are crippled due to low bandwidth, low power reserves, and minimal CPU and storage capacity, those nodes might be able to interact as clients but would mess the whole thing up if they tried to serve as peers. This is probably the case with GPRS mobile phones. Do we need to have a peer, a client, and a UA on the same device? This depends on whether the client behavior is a proper subset of the peer behavior. If it is a proper subset (not just a functional subset), then a node finding itself marginally connected/empowered could fall back to a "client" mode of operation without having to actually change protocols. If we can do this, then all we need is a "peer" and a "ua", since the "client" mode is just "peer" with some things turned off. -- Dean From fwmiller at cornfed.com Wed Jun 7 16:36:52 2006 From: fwmiller at cornfed.com (fwmiller@cornfed.com) Date: Wed, 7 Jun 2006 15:36:52 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted Message-ID: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> > > I ended up with three different abstract beasties: > > A "peer" that fully participates in the P2PSIP overlay, including > storing stuff and routing stuff for other nodes (if recursive routing > is used). > > A "client" that knows about the P2PSIP overlay , but just uses it > instead of contributing to it. > I'm not sure this distinction is necessary. If the protocol associated with "full participation" is different than "knowing about it", then it is useful. If the "knowing about it" will end up just being a subset of "full participation" then I'm not sure it is. To your later question about whether we need client nodes, I think the need should be defined by whether there is a separate protocol. I'm really hoping that the "knowing about it" can be hidden behind existing SIP mechanisms, e.g. SUB/NOT or 302s or something. If this is the case then the client becomes just a UA even though the "knowing about it" and "full participation" are using different protocols. Seems like peer and UA is general enough if protocols are the measure by which model entities are defined. FM From henry at pulver.com Wed Jun 7 16:45:50 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 7 Jun 2006 15:45:50 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> Message-ID: <00af01c68a73$5cbb2ac0$2800a8c0@DSX400> > A "client" that knows about the P2PSIP overlay , but just uses it > instead of contributing to it. This is a good idea, since it allows using openDHT and similar networks as they may appear in a commercial version. The advantage is that no bootstrap nodes need to be operated for small P2P SIP networks, just using openDHT may work. The cost of a bootstrap server can be very small, but the people to operate it may not come very cheap. Thanks, Henry -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of fwmiller at cornfed.com Sent: Wednesday, June 07, 2006 3:37 PM To: Dean Willis; Enrico Marocco Cc: P2P-SIP; David Goeckeler Subject: Re: [p2p-sip] P2PSIP Concepts and terminology draft posted > > I ended up with three different abstract beasties: > > A "peer" that fully participates in the P2PSIP overlay, including > storing stuff and routing stuff for other nodes (if recursive routing > is used). > > A "client" that knows about the P2PSIP overlay , but just uses it > instead of contributing to it. > I'm not sure this distinction is necessary. If the protocol associated with "full participation" is different than "knowing about it", then it is useful. If the "knowing about it" will end up just being a subset of "full participation" then I'm not sure it is. To your later question about whether we need client nodes, I think the need should be defined by whether there is a separate protocol. I'm really hoping that the "knowing about it" can be hidden behind existing SIP mechanisms, e.g. SUB/NOT or 302s or something. If this is the case then the client becomes just a UA even though the "knowing about it" and "full participation" are using different protocols. Seems like peer and UA is general enough if protocols are the measure by which model entities are defined. FM _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From salman at cs.columbia.edu Wed Jun 7 18:22:23 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Wed, 7 Jun 2006 18:22:23 -0400 (EDT) Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> <44872939.3080407@telecomitalia.it> Message-ID: Nice draft. Notational issue ---------------- -'P2PSIP' should perhaps be removed from the terminology heading such as 'P2PSIP Overlay Peer' as its inclusion seems implicit and redundant. Currently, all terminology headings except for the first two include it. Likewise for 'Overlay'. Other issues ------------ -Overlay Peer Enrollment Maybe required again if the user logs in the p2p network from a different machine which does not have his credentials. This is not necessarily a loss of credentials. -Section 3.2. The UA client should hang from a overlay peer because otherwise it has no way of accessing the DHT. -I am confused by the addition of the term 'peer' to the SIP redirection and proxy servers. A redirection server is generally per domain and responsible for all users in that domain. If the sys admin of that domain wants its conventional SIP redir server to participate in the p2p network, the redir server will have to register/insert all the user identifiers of all its users in the p2p network making the role of redir server redundant. Ofcourse, it is possible to store the registrar IP address against the user identifier so that a lookup query lands at the registrar. But this just adds another hop to the lookup. It also seems that a peer needs to decide whether to lookup for a user identifier in a p2p network or directly contact the SIP proxy server based on the host name (cs.columbia.edu for salman at cs.columbia.edu). For a network in which both conventional and p2p SIP nodes are participating, p2p or SIP proxy lookup can respectively increase or decrease the lookup time for an identifier. Regards, Salman From huang-ming.pan at comcast.net Wed Jun 7 18:42:21 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 7 Jun 2006 15:42:21 -0700 Subject: [p2p-sip] What are we doing, question 2 Message-ID: <00b401c68a83$a3bab930$6400a8c0@comcast.net> I encounter a question of SIP on address resolution. It is not about p2psip. I just need advice and vision into the question because people here are masters on SIP and firewall penetration. An UAS receives a request via UDP. Source address in the udp header is ipx:portx, and sent-by in topmost Via is "ipy:porty", where ipx<>ipy. There is no empty "rport" parameter in topmost Via of the request. To which address (ip and port) should the UAS send responses? Why? What for (ie. practical real-world use)? Please ignore the message if you won't shed the light. 3q. Peter ----- Original Message ----- From: "Peter Pan" To: "David A. Bryan" Cc: "Eunsoo Shim" ; "David Barrett" ; Sent: Wednesday, June 07, 2006 11:14 AM Subject: Re: [p2p-sip] What are we doing, question 2 > 3q for the comfort. > > ----- Original Message ----- > From: "David A. Bryan" > To: "Peter Pan" > Cc: "Eunsoo Shim" ; "David Barrett" > ; > Sent: Wednesday, June 07, 2006 10:28 AM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > At risk of having one David answer on behalf of another ;) > > > > My opinion is that we will need to avail ourselves of the ICE-family > > tools to do NAT traversal since as you point out, we are not likely to > > have SBCs in the picture. The odds are that using the ICE stuff will > > be far more critical for P2P systems than CS where things like SBCs > > can be used as band aids for the problem. > > > > As far as features, a few comments. Some I think will work quite > > transparently with P2PSIP -- transfers of various types, redirects on > > busy/unavailable, call forward. Some others are likely to be far more > > challenging -- obviously VM being one -- but features like this aren't > > always specified in the protocols anyway -- look at SIP where many are > > [pp]: Yes or no, imo. > > The reasons why sip seemingly cover all scenarios so far without twisting > itself are, among others: > > * There are trucks of "informative" drafts and RFCs to supplement RFC3261; > these informative specs are helpful but also bring "informative" > incompatibilities among existing SIP systems or service networks. > * Usually it is the "feature" servers (like those b2bua based call managers > by broadsoft/sylantro/avaya/nortel/...) in c/s softswitch systems that > bridge the incompleteness of rfc3261 by means of the primitives defined in > rfc3261 and other RFCs. In p2psip territory, there seems no more such > "manipulators". The manipulation will likely be done by p2psip nodes alone. > > > not specified directly in the protocol. Forking (so multiple > > appearance) is another that will be interesting and I can imagine may > > need to be treated differently in a P2P than CS scenario. > > > > In my vision for this, if a feature works as is or can be made to work > > with essentially no changes, P2P should not reinvent the wheel. Only > > do that for features that are truly dependent on servers in > > traditional CS SIP. > [pp]: Do you have kindly something persuasive other than vision and promise > which can ease this long-term concern (backward compitibility of incremental > p2psip protocol) of mine, for example, technical paper or open-source > reference implementation (that has been able to add most well-known call > features without changing architecture/protocol/implementation too much)? I > will really appreciate it since i've been always believing that p2psip is > not initiated for basic session initiation only. > > peter > > From dean.willis at softarmor.com Wed Jun 7 23:08:01 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 07 Jun 2006 22:08:01 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> <44872939.3080407@telecomitalia.it> Message-ID: <44879491.9010200@softarmor.com> Salman Abdul Baset wrote: > Nice draft. Thanks. > Notational issue > ---------------- > -'P2PSIP' should perhaps be removed from the terminology heading such as > 'P2PSIP Overlay Peer' as its inclusion seems implicit and redundant. > Currently, all terminology headings except for the first two include it. > Likewise for 'Overlay'. We argued that, but it sees all words have multiple meanings, so the fully-qualified format may be useful. There are, for example, overlays that are not P2PSIP overlays. > Other issues > ------------ > -Overlay Peer Enrollment > Maybe required again if the user logs in the p2p network from a different > machine which does not have his credentials. This is not necessarily a > loss of credentials. I view "enrollment" as being akin to "signing up for an account". If you use a different PC to access your email server, do you have to sign up for a new account on the email server? But you raise a good question -- is enrollment the same thing as credential recovery? Do we need a credential recovery operation that is not the same as enrollment? My guess is that this depends on the credential system used. > -Section 3.2. The UA client should hang from a overlay peer because > otherwise it has no way of accessing the DHT. Huh? No, the client can access the routing data of the DHT without having a fixed relationship with a peer. It might interact with any peer, chosen possibly by configuration, DNS, bootstrap server, multicast, or broadcast, just as any peer might start up. A client that has been running for some time could conceivably (if allowed in the design) cache knowledge of a large number of peers, and pick one for a given request due to some sort of distribution algorithm. > -I am confused by the addition of the term 'peer' to the SIP redirection and > proxy servers. A redirection server is generally per domain and responsible > for all users in that domain. If the sys admin of that domain wants its > conventional SIP redir server to participate in the p2p network, the redir > server will have to register/insert all the user identifiers of all its users > in the p2p network making the role of redir server redundant. A proxy or redirect server would implement proxy or redirect functions in plain SIP, using the routing knowledge of the overlay instead of a local database. For that proxy or redirect server to access the routing knowledge of the overlay, that proxy or redirect server must be coupled to an overlay peer or an overlay client. The diagram describes a proxy coupled to an overlay peer. It could just as easily be coupled to an overlay client, but would arguably be less useful done that way. > Ofcourse, it is possible to store the registrar IP address against the > user identifier so that a lookup query lands at the registrar. But this > just adds another hop to the lookup. Yes, and this is an example of iterative lookup, as an alternative to direct or recursive lookups. We probably ought to add all these to the definitions section. > It also seems that a peer needs to decide whether to lookup for a user > identifier in a p2p network or directly contact the SIP proxy server based > on the host name (cs.columbia.edu for salman at cs.columbia.edu). For a > network in which both conventional and p2p SIP nodes are participating, > p2p or SIP proxy lookup can respectively increase or decrease the lookup > time for an identifier. One would presume a single domain either has all of its primary routing knowledge in an overlay, or has it all in a conventional structure. So if you're in an overlay, and you want to look up something in your domain, you look in the overlay. If you want to look up something in another domain, you use standard SIP resolution procedures, which could involve asking your proxy or using DNS ala RFC 3263. So if cs.columbia.edu is an overlay, any node (conventional or p2p) trying to contact slaman at cs.columbia.edu would, either directly or indirectly, access that overlay. A peer or client in the same overlay would access the overlay directly. A UA outside the overlay would use RFC 3263 or equivalent procdures to find an outward-facing proxy or redirect server that's participating in the cs.columbia.edu overlay, then send the request to that proxy or redirect server. If its a proxy, it looks up the target in the overlay and routes the request to it. If it is a redirect server, it looks up the target in the overlay and returns an appropriate 300-class response. -- Dean From hu.xinyu at huawei.com Thu Jun 8 09:30:47 2006 From: hu.xinyu at huawei.com (Seaward Hu) Date: Thu, 08 Jun 2006 21:30:47 +0800 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44879491.9010200@softarmor.com> Message-ID: <000001c68aff$c08ff030$1a05a40a@china.huawei.com> Hello Dean, I have several question about your draft: 1.In the definition of P2PSIP Overlay user, you said the media relay is a kind of user, but in the reference model diagram , the gateway peer act as a P2PSIP Overlay Peer, so may I consider the media relay a peer also? 2.In the definition of bootstrap server, it was used by peer and client to locate an entry into the overlay network, but how a UA find a client or peer without any cached information while UA is not coupled to a peer or client? Must the UA be coupled to peer of client? Thanks. Seaward hu From eunsoo at research.panasonic.com Thu Jun 8 09:58:18 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 08 Jun 2006 09:58:18 -0400 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> Message-ID: <44882CFA.5070600@research.panasonic.com> Clients and Peers are logical nodes from the P2P perspective, indicating whether the node provide routing and storage or not. Peers can do always what Clients can do, which are initiating GET and PUT. UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes from SIP perspective (or session control). I personally see the two sets belong to different substrates (or sublayers). Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer. Thanks. Eunsoo fwmiller at cornfed.com wrote: > > >>I ended up with three different abstract beasties: >> >>A "peer" that fully participates in the P2PSIP overlay, including >>storing stuff and routing stuff for other nodes (if recursive routing >>is used). >> >>A "client" that knows about the P2PSIP overlay , but just uses it >>instead of contributing to it. >> >> >> > >I'm not sure this distinction is necessary. If the protocol associated with "full participation" is different than "knowing about it", then it is useful. If the "knowing about it" will end up just being a subset of "full participation" then I'm not sure it is. To your later question about whether we need client nodes, I think the need should be defined by whether there is a separate protocol. > >I'm really hoping that the "knowing about it" can be hidden behind existing SIP mechanisms, e.g. SUB/NOT or 302s or something. If this is the case then the client becomes just a UA even though the "knowing about it" and "full participation" are using different protocols. > >Seems like peer and UA is general enough if protocols are the measure by which model entities are defined. > >FM > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From eunsoo at research.panasonic.com Thu Jun 8 10:12:08 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 08 Jun 2006 10:12:08 -0400 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44882CFA.5070600@research.panasonic.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> Message-ID: <44883038.1040905@research.panasonic.com> Media relay is also a logical node from the SIP perspective. So media relay can be either a Client or Peer, in principle. Please note that media relay is used also in the context of NAT traversal. The latest ICE draft uses the term 'STUN relay'. So I think we should use 'STUN relay' for a node relaying SIP messages or RTP traffic in the context of NAT traversal. We can still use media relay in a general sense for a node that relays RTP traffic. If capable (i.e., located outside NATs or having public IP addresses not behind firewalls), any node can become a STUN relay. So a physical node can be a Peer, SIP UA, and STUN relay. Or one can be a Client, SIP UA, SIP Proxy, and Gateway. Thanks. Eunsoo Eunsoo Shim wrote: >Clients and Peers are logical nodes from the P2P perspective, indicating >whether the node provide routing and storage or not. Peers can do always >what Clients can do, which are initiating GET and PUT. >UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes >from SIP perspective (or session control). >I personally see the two sets belong to different substrates (or sublayers). >Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer. >Thanks. > >Eunsoo > >fwmiller at cornfed.com wrote: > > > >> >> >> >> >>>I ended up with three different abstract beasties: >>> >>>A "peer" that fully participates in the P2PSIP overlay, including >>>storing stuff and routing stuff for other nodes (if recursive routing >>>is used). >>> >>>A "client" that knows about the P2PSIP overlay , but just uses it >>>instead of contributing to it. >>> >>> >>> >>> >>> >>I'm not sure this distinction is necessary. If the protocol associated with "full participation" is different than "knowing about it", then it is useful. If the "knowing about it" will end up just being a subset of "full participation" then I'm not sure it is. To your later question about whether we need client nodes, I think the need should be defined by whether there is a separate protocol. >> >>I'm really hoping that the "knowing about it" can be hidden behind existing SIP mechanisms, e.g. SUB/NOT or 302s or something. If this is the case then the client becomes just a UA even though the "knowing about it" and "full participation" are using different protocols. >> >>Seems like peer and UA is general enough if protocols are the measure by which model entities are defined. >> >>FM >> >>_______________________________________________ >>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 enrico.marocco at telecomitalia.it Thu Jun 8 11:38:44 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 08 Jun 2006 17:38:44 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44882CFA.5070600@research.panasonic.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> Message-ID: <44884484.3050802@telecomitalia.it> Eunsoo Shim wrote: > Clients and Peers are logical nodes from the P2P perspective, indicating > whether the node provide routing and storage or not. Peers can do always > what Clients can do, which are initiating GET and PUT. This is what I like least. If a Pear is also a Client by definition, how do you call a Peer -- say a node participating in an iterative Chord DHT -- which is not a Client? Again, think about the P2PSIP scenario where the overlay is OpenDHT. Do you feel comfortable calling PlanetLab nodes "P2PSIP Overlay Clients"? I think this would be confusing even if you know that actually Bamboo nodes are able to perform GET and PUT operations. I'd prefer to have the "Peer" defiend as a node which participetes in the overlay contributing to storage and routing functionalities and the "Client" as something able to query an overlay for storing and retrieving data. > UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes > from SIP perspective (or session control). > I personally see the two sets belong to different substrates (or sublayers). > Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer. According with the definitions above, any P2PSIP Overlay User _must_ be coupled with a Client and _should_ be coupled with a Peer. Enrico From eunsoo at research.panasonic.com Thu Jun 8 11:47:21 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 08 Jun 2006 11:47:21 -0400 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44884484.3050802@telecomitalia.it> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> Message-ID: <44884689.1030709@research.panasonic.com> Enrico Marocco wrote: > Eunsoo Shim wrote: >> Clients and Peers are logical nodes from the P2P perspective, indicating >> whether the node provide routing and storage or not. Peers can do always >> what Clients can do, which are initiating GET and PUT. > > This is what I like least. If a Pear is also a Client by definition, > how do you call a Peer -- say a node participating in an iterative Chord > DHT -- which is not a Client? > > Again, think about the P2PSIP scenario where the overlay is OpenDHT. Do > you feel comfortable calling PlanetLab nodes "P2PSIP Overlay Clients"? > I think this would be confusing even if you know that actually Bamboo > nodes are able to perform GET and PUT operations. > > I'd prefer to have the "Peer" defiend as a node which participetes in > the overlay contributing to storage and routing functionalities and the > "Client" as something able to query an overlay for storing and > retrieving data. > Then, every node in the P2P network is a Client of your definition. Then what is left is what is Peer and Non-Peer. So the draft suggests Peer for Peer and Client for Non-Peer. If this is helpful, you can think that Peer is equivalent to Super Node and Client to Ordinary Node. Would you prefer classification of 'Peer and Non-Peer' to 'Peer and Client'? >> UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes >> from SIP perspective (or session control). >> I personally see the two sets belong to different substrates (or sublayers). >> Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer. > > According with the definitions above, any P2PSIP Overlay User _must_ be > coupled with a Client and _should_ be coupled with a Peer. > Thanks. Eunsoo From enrico.marocco at telecomitalia.it Thu Jun 8 13:15:07 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 08 Jun 2006 19:15:07 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44884689.1030709@research.panasonic.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> <44884689.1030709@research.panasonic.com> Message-ID: <44885B1B.9080105@telecomitalia.it> Eunsoo Shim wrote: >> I'd prefer to have the "Peer" defiend as a node which participetes in >> the overlay contributing to storage and routing functionalities and the >> "Client" as something able to query an overlay for storing and >> retrieving data. >> > > Then, every node in the P2P network is a Client of your definition. Then > what is left is what is Peer and Non-Peer. Sorry, I cannot identify what the "P2P network" is in the Reference Model. If by "P2P network" you mean "P2PSIP Overlay": No, they are all Peers. If by "P2P network" you mean the whole system made of nodes which just work for providing storage stuff (say "Horses"), nodes which just use storage service (say "Parasites") and nodes which both work and use it (say "Workers"): No again. According with my definitions, an "Horse" is a Peer, a "Parasite" is a Clients and a "Worker" is both a Peer and a Client. > So the draft suggests Peer for Peer and Client for Non-Peer. > If this is helpful, you can think that Peer is equivalent to Super Node > and Client to Ordinary Node. The draft suggests "Peer" for "Worker" and "Client" for "Parasite", but it doesn't suggest anything for "Horse"; since a Super Node may be an "Horse" too, it is lacking a definition. > Would you prefer classification of 'Peer and Non-Peer' to 'Peer and Client'? I'd prefer classification of "Horse, Worker and Parasite" ;-) Anyway, I like the classification of "Peer and Client", but when a Peer is acting as a client - i.e. is storing or retrieving data for establishing SIP sessions he's involved in - I would call it a Client. Enrico From eunsoo at research.panasonic.com Thu Jun 8 13:53:33 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 08 Jun 2006 13:53:33 -0400 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44885B1B.9080105@telecomitalia.it> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> <44884689.1030709@research.panasonic.com> <44885B1B.9080105@telecomitalia.it> Message-ID: <4488641D.1040004@research.panasonic.com> Enrico Marocco wrote: > Eunsoo Shim wrote: >>> I'd prefer to have the "Peer" defiend as a node which participetes in >>> the overlay contributing to storage and routing functionalities and the >>> "Client" as something able to query an overlay for storing and >>> retrieving data. >>> >> Then, every node in the P2P network is a Client of your definition. Then >> what is left is what is Peer and Non-Peer. > > Sorry, I cannot identify what the "P2P network" is in the Reference Model. > I meant "P2PSIP Overlay Network" by "P2P Network". > If by "P2P network" you mean "P2PSIP Overlay": No, they are all Peers. > A P2PSIP Overlay Network can consist of Peers and Clients. Not necessarily all the nodes of a P2PSIP Overlay Network are Peers. If this is not clear in the concept draft, that point should be described better in the draft. > If by "P2P network" you mean the whole system made of nodes which just > work for providing storage stuff (say "Horses"), nodes which just use > storage service (say "Parasites") and nodes which both work and use it > (say "Workers"): No again. According with my definitions, an "Horse" is > a Peer, a "Parasite" is a Clients and a "Worker" is both a Peer and a > Client. > At least in the concept draft, there is no node in the P2PSIP Overlay Network that cannot initiate GET and PUT. I don't think we need to define Horses. In a sense, a Peer is a Server and Client. If we define something like Horse, it will be a Server. >> So the draft suggests Peer for Peer and Client for Non-Peer. >> If this is helpful, you can think that Peer is equivalent to Super Node >> and Client to Ordinary Node. > > The draft suggests "Peer" for "Worker" and "Client" for "Parasite", but > it doesn't suggest anything for "Horse"; since a Super Node may be an > "Horse" too, it is lacking a definition. > >> Would you prefer classification of 'Peer and Non-Peer' to 'Peer and Client'? > > I'd prefer classification of "Horse, Worker and Parasite" ;-) > > Anyway, I like the classification of "Peer and Client", but when a Peer > is acting as a client - i.e. is storing or retrieving data for > establishing SIP sessions he's involved in - I would call it a Client. > Well, I hope we use the term Peer and Client in the same meaning. Thanks. Eunsoo From salman at cs.columbia.edu Thu Jun 8 14:57:52 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Thu, 8 Jun 2006 14:57:52 -0400 (EDT) Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44879491.9010200@softarmor.com> References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> <44872939.3080407@telecomitalia.it> <44879491.9010200@softarmor.com> Message-ID: Inline. > > Notational issue > > ---------------- > > -'P2PSIP' should perhaps be removed from the terminology heading such as > > 'P2PSIP Overlay Peer' as its inclusion seems implicit and redundant. > > Currently, all terminology headings except for the first two include it. > > Likewise for 'Overlay'. > > We argued that, but it sees all words have multiple meanings, so the > fully-qualified format may be useful. There are, for example, overlays > that are not P2PSIP overlays. Since the term names are quite long, people will tend to use their abbreviations when writing a draft. For example, I will prefer writing POUA instead of 'P2PSIP Overlay User Agent'. Perhaps, it will help to come up with unambiguous abbreviations for corresponding key terms. > > It also seems that a peer needs to decide whether to lookup for a user > > identifier in a p2p network or directly contact the SIP proxy server based > > on the host name (cs.columbia.edu for salman at cs.columbia.edu). For a > > network in which both conventional and p2p SIP nodes are participating, > > p2p or SIP proxy lookup can respectively increase or decrease the lookup > > time for an identifier. > > One would presume a single domain either has all of its primary routing > knowledge in an overlay, or has it all in a conventional structure. > > So if you're in an overlay, and you want to look up something in your > domain, you look in the overlay. If you want to look up something in > another domain, you use standard SIP resolution procedures, which could > involve asking your proxy or using DNS ala RFC 3263. The definition for P2PSIP Overlay Identifier states: "Information that identifies a specific P2PSIP Overlay. This is presumed in the general case to be scoped to a name within the DNS, but other scopes may apply, particularly in ad-hoc environments. Short forms: overlay identifier, overlay ID." Since overlay ID is not always a DNS name, it implies that two nodes in different domains can potentially participate in the same overlay. This may not be a recommended practice and a BCP draft might help clarify this. Some questions not necessarily for this draft are: -What should happen if we want to run a P2PSIP overlay in an existing SIP domain? Do the existing redir/proxy servers need to be coupled with a peer layer? When would an overlay peer want to discover them as opposed to looking in the overlay? -Is better not to run conventional SIP with overlay SIP? -When conventional and P2PSIP are run together, shall the existing redir servers keep their local databases or switch to the overlay storage. -salman From enrico.marocco at telecomitalia.it Thu Jun 8 15:33:33 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 08 Jun 2006 21:33:33 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <4488641D.1040004@research.panasonic.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> <44884689.1030709@research.panasonic.com> <44885B1B.9080105@telecomitalia.it> <4488641D.1040004@research.panasonic.com> Message-ID: <44887B8D.7020300@telecomitalia.it> Eunsoo Shim wrote: > At least in the concept draft, there is no node in the P2PSIP Overlay > Network that cannot initiate GET and PUT. In real life scenarios there are some: an example is OpenDHT nodes. Using concepts currently present in the draft, you'd define an OpenDHT node not only a Peer, but also a Client (because a Peer *is* a Client). I'm sorry, but I think it's misleading. Enrico From dean.willis at softarmor.com Thu Jun 8 16:45:46 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Thu, 8 Jun 2006 15:45:46 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <000001c68aff$c08ff030$1a05a40a@china.huawei.com> References: <000001c68aff$c08ff030$1a05a40a@china.huawei.com> Message-ID: On Jun 8, 2006, at 8:30 AM, Seaward Hu wrote: > Hello Dean, > I have several question about your draft: > > 1.In the definition of P2PSIP Overlay user, you said the media > relay is a > kind of user, but in the reference model diagram , the gateway peer > act as a > P2PSIP Overlay Peer, so may I consider the media relay a peer also? A media relay might be a peer or a client or neither. Whether or not it is a "user" is probably debatable. The entire peoblem of finding media relays is wide-open. > > 2.In the definition of bootstrap server, it was used by peer and > client to > locate an entry into the overlay network, but how a UA find a > client or peer > without any cached information while UA is not coupled to a peer or > client? > Must the UA be coupled to peer of client? A P2PSIP UA must be coupled to a peer or a client. A SIP UA might use a proxy server that is coupled to a peer or a client, or it might use a redirect server that is coupled to a peer or a client, or it might not interact with the overlay at all. -- Dean From dean.willis at softarmor.com Thu Jun 8 16:49:32 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Thu, 8 Jun 2006 15:49:32 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44884484.3050802@telecomitalia.it> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> Message-ID: <4360B39D-FC2D-4B0B-8934-E3C4C6366285@softarmor.com> On Jun 8, 2006, at 10:38 AM, Enrico Marocco wrote: > Eunsoo Shim wrote: >> Clients and Peers are logical nodes from the P2P perspective, >> indicating >> whether the node provide routing and storage or not. Peers can do >> always >> what Clients can do, which are initiating GET and PUT. > > This is what I like least. If a Pear is also a Client by definition, > how do you call a Peer -- say a node participating in an iterative > Chord > DHT -- which is not a Client? If (and this is an open question) the client is a syntactic or protocol subset of the peer, then there is no peer that is not also a client. If the client is merely a functional subset, then a client is a client and a peer is a peer, and they;re different things. > > Again, think about the P2PSIP scenario where the overlay is > OpenDHT. Do > you feel comfortable calling PlanetLab nodes "P2PSIP Overlay Clients"? > I think this would be confusing even if you know that actually Bamboo > nodes are able to perform GET and PUT operations. yes. > > I'd prefer to have the "Peer" defiend as a node which participetes in > the overlay contributing to storage and routing functionalities and > the > "Client" as something able to query an overlay for storing and > retrieving data. > Ok, I'm confused, as I thought that's what the existing definition said. Could you pelase write the full definitions up in the style used in the draft for comparison purposes, and start a new thread on peer and client definitions? >> UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes >> from SIP perspective (or session control). >> I personally see the two sets belong to different substrates (or >> sublayers). >> Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer. > > According with the definitions above, any P2PSIP Overlay User > _must_ be > coupled with a Client and _should_ be coupled with a Peer. > Again, depending on the subset relationship (currently unresolved) between client and peer. -- Dean From dean.willis at softarmor.com Thu Jun 8 16:56:48 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Thu, 8 Jun 2006 15:56:48 -0500 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: References: <57FA1A19-CACD-487C-8FBB-1DC4F9FDA13D@softarmor.com> <44870322.5080105@telecomitalia.it> <4E5CE537-D06C-4F2C-9C0D-C24DF87DFEBF@softarmor.com> <44872939.3080407@telecomitalia.it> <44879491.9010200@softarmor.com> Message-ID: On Jun 8, 2006, at 1:57 PM, Salman Abdul Baset wrote: > Inline. > >>> Notational issue >>> ---------------- >>> -'P2PSIP' should perhaps be removed from the terminology heading >>> such as >>> 'P2PSIP Overlay Peer' as its inclusion seems implicit and redundant. >>> Currently, all terminology headings except for the first two >>> include it. >>> Likewise for 'Overlay'. >> >> We argued that, but it sees all words have multiple meanings, so the >> fully-qualified format may be useful. There are, for example, >> overlays >> that are not P2PSIP overlays. > > Since the term names are quite long, people will tend to use their > abbreviations when writing a draft. For example, I will prefer writing > POUA instead of 'P2PSIP Overlay User Agent'. Perhaps, it will help > to come up with unambiguous abbreviations for corresponding key terms. feel free to propose some on-list and we'll discuss them. I have no objection to adding thme to the draft if we have consensus. > >>> It also seems that a peer needs to decide whether to lookup for a >>> user >>> identifier in a p2p network or directly contact the SIP proxy >>> server based >>> on the host name (cs.columbia.edu for salman at cs.columbia.edu). For a >>> network in which both conventional and p2p SIP nodes are >>> participating, >>> p2p or SIP proxy lookup can respectively increase or decrease the >>> lookup >>> time for an identifier. >> >> One would presume a single domain either has all of its primary >> routing >> knowledge in an overlay, or has it all in a conventional structure. >> >> So if you're in an overlay, and you want to look up something in your >> domain, you look in the overlay. If you want to look up something in >> another domain, you use standard SIP resolution procedures, which >> could >> involve asking your proxy or using DNS ala RFC 3263. > > The definition for P2PSIP Overlay Identifier states: > "Information that identifies a specific P2PSIP Overlay. This is > presumed > in the general case to be scoped to a name within the DNS, but other > scopes may apply, particularly in ad-hoc environments. Short forms: > overlay identifier, overlay ID." > > Since overlay ID is not always a DNS name, it implies that two > nodes in > different domains can potentially participate in the same overlay. > This > may not be a recommended practice and a BCP draft might help > clarify this. That's not precluded by anything in this draft, but should probably be clarified. > > Some questions not necessarily for this draft are: > > -What should happen if we want to run a P2PSIP overlay in an > existing SIP > domain? Do the existing redir/proxy servers need to be coupled with > a peer > layer? When would an overlay peer want to discover them as opposed > to looking > in the overlay? If we ran a P2PSIP overlay inside a existing client/server (CS) SIP domain, we'd have to have some way to establish routing. One possibility would be for a registrar-assist agent to 3rd-party register each P2P user into the CS SIP domain. Another approach would be to have the CS domain route all unknown users to the overlay. > -Is better not to run conventional SIP with overlay SIP? Good religious question. Define your parameters for "better"? > -When conventional and P2PSIP are run together, shall the existing > redir > servers keep their local databases or switch to the overlay storage. > The answer is an unambiguous "yes", but that probably doesn't answer the question you meant to ask. Write it up as an open question and send to list with a title like "Another question for concepts draft: combining database" or some such, and I'll add it to the working draft if nobody screams. -- Dean From eunsoo at research.panasonic.com Thu Jun 8 17:42:47 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 08 Jun 2006 17:42:47 -0400 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <44887B8D.7020300@telecomitalia.it> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> <44884689.1030709@research.panasonic.com> <44885B1B.9080105@telecomitalia.it> <4488641D.1040004@research.panasonic.com> <44887B8D.7020300@telecomitalia.it> Message-ID: <448899D7.4090000@research.panasonic.com> Enrico Marocco wrote: > Eunsoo Shim wrote: >> At least in the concept draft, there is no node in the P2PSIP Overlay >> Network that cannot initiate GET and PUT. > > In real life scenarios there are some: an example is OpenDHT nodes. > I am not sure an OpenDHT node cannot initiate GET and PUT. Logically it does not make a sense if a DHT node cannot initiate GET and PUT. Even for JOIN, a node should be able to initiate GET. > Using concepts currently present in the draft, you'd define an OpenDHT > node not only a Peer, but also a Client (because a Peer *is* a Client). > I'm sorry, but I think it's misleading. > > Enrico > Probably the definition in the draft needs to be improved. Here is my understanding. A Peer is a node that can do the four things. - JOIN and LEAVE (the DHT). - Route messages (based on the DHT routing table it maintains). - Store data for other nodes. - Initiate GET and PUT. A Client is a node that can do one thing. - Initiate GET and PUT. (Whether a Client should store data for other nodes is an open question. For now, we can ignore the possibility.) Please note that a P2PSIP Overlay Network can consist of only Peers. Thanks. Eunsoo From enrico.marocco at telecomitalia.it Thu Jun 8 18:32:14 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 09 Jun 2006 00:32:14 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <448899D7.4090000@research.panasonic.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> <44884689.1030709@research.panasonic.com> <44885B1B.9080105@telecomitalia.it> <4488641D.1040004@research.panasonic.com> <44887B8D.7020300@telecomitalia.it> <448899D7.4090000@research.panasonic.com> Message-ID: <4488A56E.40104@telecomitalia.it> Eunsoo Shim wrote: >>> At least in the concept draft, there is no node in the P2PSIP Overlay >>> Network that cannot initiate GET and PUT. >> In real life scenarios there are some: an example is OpenDHT nodes. >> > I am not sure an OpenDHT node cannot initiate GET and PUT. > Logically it does not make a sense if a DHT node cannot initiate GET and > PUT. I'm not sure that client GET/PUT operations - which cope with user credentials other than data - could be considered functionally equivalent to maintainance operations. > Even for JOIN, a node should be able to initiate GET. Arguable. In Chord JOIN and GET are similar, but this does not imply that they are generally related. > Probably the definition in the draft needs to be improved. > Here is my understanding. > > A Peer is a node that can do the four things. > - JOIN and LEAVE (the DHT). > - Route messages (based on the DHT routing table it maintains). > - Store data for other nodes. > - Initiate GET and PUT. I would let only clients initiate GET and PUT, but, hey... maybe it's just me. > A Client is a node that can do one thing. > - Initiate GET and PUT. > (Whether a Client should store data for other nodes is an open question. > For now, we can ignore the possibility.) > > Please note that a P2PSIP Overlay Network can consist of only Peers. Sure. But then you need clients for storing and retrieving user records needed for SIP communications. Ok, it sounds like we are disagreeing again :-) Enrico From enrico.marocco at telecomitalia.it Thu Jun 8 18:36:50 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 09 Jun 2006 00:36:50 +0200 Subject: [p2p-sip] P2PSIP Concepts and terminology draft posted In-Reply-To: <4360B39D-FC2D-4B0B-8934-E3C4C6366285@softarmor.com> References: <200606072036.k57Kaqx05759@smapp01.siteprotect.com> <44882CFA.5070600@research.panasonic.com> <44884484.3050802@telecomitalia.it> <4360B39D-FC2D-4B0B-8934-E3C4C6366285@softarmor.com> Message-ID: <4488A682.4090400@telecomitalia.it> Dean Willis wrote: >> Again, think about the P2PSIP scenario where the overlay is OpenDHT. Do >> you feel comfortable calling PlanetLab nodes "P2PSIP Overlay Clients"? >> I think this would be confusing even if you know that actually Bamboo >> nodes are able to perform GET and PUT operations. > > yes. > >> >> I'd prefer to have the "Peer" defiend as a node which participetes in >> the overlay contributing to storage and routing functionalities and the >> "Client" as something able to query an overlay for storing and >> retrieving data. >> > > Ok, I'm confused, as I thought that's what the existing definition said. > Could you pelase write the full definitions up in the style used in the > draft for comparison purposes, and start a new thread on peer and client > definitions? Client and peer definitions are not bad per se. What's confusing, IMHO, is the inheritance relationship between them or, better, between their protocols. >>> UAs, SIP Proxy, SIP Redirector Server, and Gateway are logical nodes >>> from SIP perspective (or session control). >>> I personally see the two sets belong to different substrates (or >>> sublayers). >>> Any SIP node (UA, SIP Proxy, etc.) can be either a Client or Peer. >> >> According with the definitions above, any P2PSIP Overlay User _must_ be >> coupled with a Client and _should_ be coupled with a Peer. > > Again, depending on the subset relationship (currently unresolved) > between client and peer. Indeed. Enrico From francis at cs.cornell.edu Fri Jun 9 08:13:32 2006 From: francis at cs.cornell.edu (Paul Francis) Date: Fri, 9 Jun 2006 08:13:32 -0400 Subject: [p2p-sip] Offpath BoF at Montreal IETF Message-ID: Gang, The offpath BoF, titled "Path-decoupled Signaling for Data", as been approved for the next IETF. The proposed topic for the BoF is copied below, and is also available at http://www.cs.cornell.edu/people/francis/offpath/. This message is being sent (separately) to the nsis, behave, p2psip, e2e-interest, and ietf mailing lists. The purpose of this message is to solicite feedback about the topics and agenda for the BoF. Note that the immediate goal of the BoF is to create an IRTF research group. A BoF mailing list has been created (see below). Thanks, PF --------------------------------------------------------------------- Path-decoupled Signaling for Data (offpath) To be held at the 66th (Montreal) IETF, under the auspices of the Transport Area (Lars Eggert), and coordinated with the IRTF (Aaron Falk). BoF Chair: TBD BoF Initiators: Paul Francis and Saikat Guha (both of Cornell University) @cs.cornell.edu General Discussion: off-path-bof at ietf.org To Subscribe: off-path-bof-request at ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html This page at: http://www.cs.cornell.edu/people/francis/offpath Purpose of BoF: Gauge interest in creating an IRTF research group on this topic. Synopsis: Path-decoupled (or off-path) signaling, in the form of SIP, has proven to be a very powerful mechanism for facilitating media connection establishment between hosts. It provides friendly naming, discovery, user mobility, authentication, transport and application negotiation, and even NAT/FW traversal for UDP and, more recently, TCP. Furthermore, it is network independent, working equally well for IPv4 and IPv6. This set of features, however, would be attractive to all types of data sessions, not just media. The purpose of this BoF is to gauge interest in the design of off-path signaling (probably but not necessarily using SIP) for establishing all kinds of non-public-server data sessions. A positive outcome of this BoF would be the formation of an IRTF group, though other outcomes will of course be considered. We are particularly interested in models of off-path signaling that improve security beyond today's address/port/deep-inspection model. The use of path-decoupled signaling gives both the middle and the ends the opportunity to assert policy and negotiate an acceptable session. We would like to explore cases where the off-path signaling operates alone (i.e. NAT/FW traversal with legacy NAT/FW's), as well as where it operates in conjunction with subsequent path-coupled signaling (either in-band or out-of-band). Considering that an application can always lie about what it is, we would also like to explore how to couple the signaling primitives with emerging OS security features (i.e. trusted computing platforms). Beyond security, we would like to explore the use of off-path signaling for such features as user and host mobility, transport negotiation (i.e. TCP versus SCTP), anycast and multicast, billing, and time-delayed communications messaging). The ultimate goal here is that some or all of these features become part of the standard sockets API of typical OS's, and that infrastructure support for the signaling becomes ubiquitous (in the same sense that DNS is ubiquitous). This would allow application developers, security vendors (middlebox and endhost), users, and network administrators to converge on a unified method of naming and connection establishment over the Internet. (By contrast, naming and connection establishment through NATs and firewalls today is ad hoc and usually application specific, variously involving email, IM services, dynamic DNS services, manual configuration of ports, and so on.) Of the IETF working groups, this BoF is most closely aligned with the nsis WG in the Transport Area, especially the NAT/FW NSLP. The following gives an example of how an off-path signaling protocol would work in conjunction with the NAT/FW NSLP. This is only an example...there are other approaches and variants on this example. Say an application wishes to establish a TCP connection with a "peer", where both peers are behind NAT/FW's. The initiating peer off-path signals a connection request. The request contains the application name, user names, authentication information (Certs or Diameter), and information about the preferred transport (TCP, SSL, IPSec, etc.). The off-path request is checked by the initiating endhost's policy, and then flows through policy boxes representing the initiator's and the recipient's networks. This gives both sides an opportunity to reject the request, or to request different transport or security characteristics, or to accept and pass on the request as-is. Note that the policy boxes could both be far from either ends' physical network, thus not revealing the IP addresses of either end until the connection is approved. The policy boxes could also be widely replicated. Assuming the connection request is approved, the endhosts use the NAT/FW NSLP to obtain address and port mappings from their respective NAT boxes. These are conveyed through the off-path signaling channel. In addition, the policy boxes create secure tokens that firewalls can use to allow the approved connection. These tokens are passed to the endhosts through off-path signaling, which then convey them on-path, either in-band or out-of-band (i.e. the NAT/FW NSLP), to traverse the firewall. Supporting material: http://nutss.gforge.cis.cornell.edu/ From kyara543 at yahoo.com Fri Jun 9 14:15:51 2006 From: kyara543 at yahoo.com (K.Yamamoto) Date: Fri, 9 Jun 2006 11:15:51 -0700 (PDT) Subject: [p2p-sip] Offpath BoF at Montreal IETF In-Reply-To: Message-ID: <20060609181551.91842.qmail@web38611.mail.mud.yahoo.com> WOW! ONE MORE NOSH-UP FOR ALUMNUS BANQUET!! BUT ISN'T IT THE GOAL OF TECHNOLOGIES TO ACCOMMODATE LIVINGS OF HUMAN BEINGS (WITHOUT SACRIFICING LIVES OF POOR ENGINEERS)? WHAT A NIGHTMARE TO THOSE AT BOTTOM WHO WRITE SIP CODE TO EARN A BITE OF SUSHI RICE OR BOWL OF MISO SOUP!! SINCERE MERCIES. K.Y. Paul Francis wrote: Gang, The offpath BoF, titled "Path-decoupled Signaling for Data", as been approved for the next IETF. The proposed topic for the BoF is copied below, and is also available at http://www.cs.cornell.edu/people/francis/offpath/. This message is being sent (separately) to the nsis, behave, p2psip, e2e-interest, and ietf mailing lists. The purpose of this message is to solicite feedback about the topics and agenda for the BoF. Note that the immediate goal of the BoF is to create an IRTF research group. A BoF mailing list has been created (see below). Thanks, PF --------------------------------------------------------------------- Path-decoupled Signaling for Data (offpath) To be held at the 66th (Montreal) IETF, under the auspices of the Transport Area (Lars Eggert), and coordinated with the IRTF (Aaron Falk). BoF Chair: TBD BoF Initiators: Paul Francis and Saikat Guha (both of Cornell University) saikat>@cs.cornell.edu General Discussion: off-path-bof at ietf.org To Subscribe: off-path-bof-request at ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/off-path-bof/index.html This page at: http://www.cs.cornell.edu/people/francis/offpath Purpose of BoF: Gauge interest in creating an IRTF research group on this topic. Synopsis: Path-decoupled (or off-path) signaling, in the form of SIP, has proven to be a very powerful mechanism for facilitating media connection establishment between hosts. It provides friendly naming, discovery, user mobility, authentication, transport and application negotiation, and even NAT/FW traversal for UDP and, more recently, TCP. Furthermore, it is network independent, working equally well for IPv4 and IPv6. This set of features, however, would be attractive to all types of data sessions, not just media. The purpose of this BoF is to gauge interest in the design of off-path signaling (probably but not necessarily using SIP) for establishing all kinds of non-public-server data sessions. A positive outcome of this BoF would be the formation of an IRTF group, though other outcomes will of course be considered. We are particularly interested in models of off-path signaling that improve security beyond today's address/port/deep-inspection model. The use of path-decoupled signaling gives both the middle and the ends the opportunity to assert policy and negotiate an acceptable session. We would like to explore cases where the off-path signaling operates alone (i.e. NAT/FW traversal with legacy NAT/FW's), as well as where it operates in conjunction with subsequent path-coupled signaling (either in-band or out-of-band). Considering that an application can always lie about what it is, we would also like to explore how to couple the signaling primitives with emerging OS security features (i.e. trusted computing platforms). Beyond security, we would like to explore the use of off-path signaling for such features as user and host mobility, transport negotiation (i.e. TCP versus SCTP), anycast and multicast, billing, and time-delayed communications messaging). The ultimate goal here is that some or all of these features become part of the standard sockets API of typical OS's, and that infrastructure support for the signaling becomes ubiquitous (in the same sense that DNS is ubiquitous). This would allow application developers, security vendors (middlebox and endhost), users, and network administrators to converge on a unified method of naming and connection establishment over the Internet. (By contrast, naming and connection establishment through NATs and firewalls today is ad hoc and usually application specific, variously involving email, IM services, dynamic DNS services, manual configuration of ports, and so on.) Of the IETF working groups, this BoF is most closely aligned with the nsis WG in the Transport Area, especially the NAT/FW NSLP. The following gives an example of how an off-path signaling protocol would work in conjunction with the NAT/FW NSLP. This is only an example...there are other approaches and variants on this example. Say an application wishes to establish a TCP connection with a "peer", where both peers are behind NAT/FW's. The initiating peer off-path signals a connection request. The request contains the application name, user names, authentication information (Certs or Diameter), and information about the preferred transport (TCP, SSL, IPSec, etc.). The off-path request is checked by the initiating endhost's policy, and then flows through policy boxes representing the initiator's and the recipient's networks. This gives both sides an opportunity to reject the request, or to request different transport or security characteristics, or to accept and pass on the request as-is. Note that the policy boxes could both be far from either ends' physical network, thus not revealing the IP addresses of either end until the connection is approved. The policy boxes could also be widely replicated. Assuming the connection request is approved, the endhosts use the NAT/FW NSLP to obtain address and port mappings from their respective NAT boxes. These are conveyed through the off-path signaling channel. In addition, the policy boxes create secure tokens that firewalls can use to allow the approved connection. These tokens are passed to the endhosts through off-path signaling, which then convey them on-path, either in-band or out-of-band (i.e. the NAT/FW NSLP), to traverse the firewall. Supporting material: http://nutss.gforge.cis.cornell.edu/ _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060609/c1428ad8/attachment-0001.html From fluffy at cisco.com Sat Jun 10 00:24:24 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Fri, 9 Jun 2006 21:24:24 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <00b401c68a83$a3bab930$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> Message-ID: If the Via says port 1000 and you received it from port 2000 and there is no rport, the spec says you send back to 1000. (If there was an rport, you would send to 2000). The reason why is some devices send from a different port than they receive on - typically they receive on 5060 but send from some ephemeral port allocated by OS. If they device sends and receives from same port, it needs to indicate this by inserting the rport flag in the via. On Jun 7, 2006, at 3:42 PM, Peter Pan wrote: > I encounter a question of SIP on address resolution. It is not > about p2psip. > I just need advice and vision into the question because people here > are > masters on SIP and firewall penetration. > > An UAS receives a request via UDP. Source address in the udp header is > ipx:portx, and sent-by in topmost Via is "ipy:porty", where > ipx<>ipy. There > is no empty "rport" parameter in topmost Via of the request. > > To which address (ip and port) should the UAS send responses? Why? > What for > (ie. practical real-world use)? > > Please ignore the message if you won't shed the light. > > 3q. > > Peter > ----- Original Message ----- > From: "Peter Pan" > To: "David A. Bryan" > Cc: "Eunsoo Shim" ; "David Barrett" > ; > Sent: Wednesday, June 07, 2006 11:14 AM > Subject: Re: [p2p-sip] What are we doing, question 2 > > >> 3q for the comfort. >> >> ----- Original Message ----- >> From: "David A. Bryan" >> To: "Peter Pan" >> Cc: "Eunsoo Shim" ; "David Barrett" >> ; >> Sent: Wednesday, June 07, 2006 10:28 AM >> Subject: Re: [p2p-sip] What are we doing, question 2 >> >> >>> At risk of having one David answer on behalf of another ;) >>> >>> My opinion is that we will need to avail ourselves of the ICE-family >>> tools to do NAT traversal since as you point out, we are not >>> likely to >>> have SBCs in the picture. The odds are that using the ICE stuff will >>> be far more critical for P2P systems than CS where things like SBCs >>> can be used as band aids for the problem. >>> >>> As far as features, a few comments. Some I think will work quite >>> transparently with P2PSIP -- transfers of various types, >>> redirects on >>> busy/unavailable, call forward. Some others are likely to be far >>> more >>> challenging -- obviously VM being one -- but features like this >>> aren't >>> always specified in the protocols anyway -- look at SIP where >>> many are >> >> [pp]: Yes or no, imo. >> >> The reasons why sip seemingly cover all scenarios so far without >> twisting >> itself are, among others: >> >> * There are trucks of "informative" drafts and RFCs to supplement >> RFC3261; >> these informative specs are helpful but also bring "informative" >> incompatibilities among existing SIP systems or service networks. >> * Usually it is the "feature" servers (like those b2bua based call > managers >> by broadsoft/sylantro/avaya/nortel/...) in c/s softswitch systems >> that >> bridge the incompleteness of rfc3261 by means of the primitives >> defined in >> rfc3261 and other RFCs. In p2psip territory, there seems no more such >> "manipulators". The manipulation will likely be done by p2psip nodes > alone. >> >>> not specified directly in the protocol. Forking (so multiple >>> appearance) is another that will be interesting and I can imagine >>> may >>> need to be treated differently in a P2P than CS scenario. >>> >>> In my vision for this, if a feature works as is or can be made to >>> work >>> with essentially no changes, P2P should not reinvent the wheel. Only >>> do that for features that are truly dependent on servers in >>> traditional CS SIP. >> [pp]: Do you have kindly something persuasive other than vision and > promise >> which can ease this long-term concern (backward compitibility of > incremental >> p2psip protocol) of mine, for example, technical paper or open-source >> reference implementation (that has been able to add most well- >> known call >> features without changing architecture/protocol/implementation too >> much)? > I >> will really appreciate it since i've been always believing that >> p2psip is >> not initiated for basic session initiation only. >> >> peter >> >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Sat Jun 10 02:03:56 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 9 Jun 2006 23:03:56 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> Message-ID: <049101c68c53$a8ca6b10$6400a8c0@comcast.net> Thanks a lot for the comments. I did some survey of RFC 3261 and 3581 in this regard, and got my preliminary conclusion that the response MUST be sent to address "ipx:porty", which seems unreasonable. For example, a UAS receives a request via UDP with the address in sent-by of Via = 172.2.2.2:6666, with no rport in Via the address in udp header = 172.1.1.1:5555 According to Sec 18.2.1 of RFC 3261, UAS MUST add ";received=172.1.1.1:5555" to the Via. It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my interop partner insists). Finally, per Sec 18.2.2 of RFC 3261 (instead of Sec 4 of RFC 3581), UAS MUST send the response to address "172.1.1.1:6666". But 172.1.1.1:6666 reads like "my ip and his port" or "my body and his head", which to me apparently makes no sense, unless I miss any possible intrigue. Please correct me if I misunderstand the RFCs; or, please reveal the intrigue should you know it. 3q and have a nice weekend!! Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Friday, June 09, 2006 9:24 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > If the Via says port 1000 and you received it from port 2000 and > there is no rport, the spec says you send back to 1000. (If there was > an rport, you would send to 2000). > > The reason why is some devices send from a different port than they > receive on - typically they receive on 5060 but send from some > ephemeral port allocated by OS. If they device sends and receives > from same port, it needs to indicate this by inserting the rport flag > in the via. > > > > On Jun 7, 2006, at 3:42 PM, Peter Pan wrote: > > > I encounter a question of SIP on address resolution. It is not > > about p2psip. > > I just need advice and vision into the question because people here > > are > > masters on SIP and firewall penetration. > > > > An UAS receives a request via UDP. Source address in the udp header is > > ipx:portx, and sent-by in topmost Via is "ipy:porty", where > > ipx<>ipy. There > > is no empty "rport" parameter in topmost Via of the request. > > > > To which address (ip and port) should the UAS send responses? Why? > > What for > > (ie. practical real-world use)? > > > > Please ignore the message if you won't shed the light. > > > > 3q. > > > > Peter > > ----- Original Message ----- > > From: "Peter Pan" > > To: "David A. Bryan" > > Cc: "Eunsoo Shim" ; "David Barrett" > > ; > > Sent: Wednesday, June 07, 2006 11:14 AM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >> 3q for the comfort. > >> > >> ----- Original Message ----- > >> From: "David A. Bryan" > >> To: "Peter Pan" > >> Cc: "Eunsoo Shim" ; "David Barrett" > >> ; > >> Sent: Wednesday, June 07, 2006 10:28 AM > >> Subject: Re: [p2p-sip] What are we doing, question 2 > >> > >> > >>> At risk of having one David answer on behalf of another ;) > >>> > >>> My opinion is that we will need to avail ourselves of the ICE-family > >>> tools to do NAT traversal since as you point out, we are not > >>> likely to > >>> have SBCs in the picture. The odds are that using the ICE stuff will > >>> be far more critical for P2P systems than CS where things like SBCs > >>> can be used as band aids for the problem. > >>> > >>> As far as features, a few comments. Some I think will work quite > >>> transparently with P2PSIP -- transfers of various types, > >>> redirects on > >>> busy/unavailable, call forward. Some others are likely to be far > >>> more > >>> challenging -- obviously VM being one -- but features like this > >>> aren't > >>> always specified in the protocols anyway -- look at SIP where > >>> many are > >> > >> [pp]: Yes or no, imo. > >> > >> The reasons why sip seemingly cover all scenarios so far without > >> twisting > >> itself are, among others: > >> > >> * There are trucks of "informative" drafts and RFCs to supplement > >> RFC3261; > >> these informative specs are helpful but also bring "informative" > >> incompatibilities among existing SIP systems or service networks. > >> * Usually it is the "feature" servers (like those b2bua based call > > managers > >> by broadsoft/sylantro/avaya/nortel/...) in c/s softswitch systems > >> that > >> bridge the incompleteness of rfc3261 by means of the primitives > >> defined in > >> rfc3261 and other RFCs. In p2psip territory, there seems no more such > >> "manipulators". The manipulation will likely be done by p2psip nodes > > alone. > >> > >>> not specified directly in the protocol. Forking (so multiple > >>> appearance) is another that will be interesting and I can imagine > >>> may > >>> need to be treated differently in a P2P than CS scenario. > >>> > >>> In my vision for this, if a feature works as is or can be made to > >>> work > >>> with essentially no changes, P2P should not reinvent the wheel. Only > >>> do that for features that are truly dependent on servers in > >>> traditional CS SIP. > >> [pp]: Do you have kindly something persuasive other than vision and > > promise > >> which can ease this long-term concern (backward compitibility of > > incremental > >> p2psip protocol) of mine, for example, technical paper or open-source > >> reference implementation (that has been able to add most well- > >> known call > >> features without changing architecture/protocol/implementation too > >> much)? > > I > >> will really appreciate it since i've been always believing that > >> p2psip is > >> not initiated for basic session initiation only. > >> > >> peter > >> > >> > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060610/69af5828/attachment.html From matteo.peraldo at gmail.com Sat Jun 10 08:24:35 2006 From: matteo.peraldo at gmail.com (Matteo Peraldo) Date: Sat, 10 Jun 2006 14:24:35 +0200 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Concepts and terminology draft posted) Message-ID: It seems there is some confusion about peer and client. Someone is viewing at them as roles, someone as real distinguished nodes. Obviously, considering them roles, a node can play the role of peer and client both. But peer and client are not the some role and they are not overlapped. When a node works in the mainteinance of DHT it acts as peer, when initiates GET or PUT it acts as client. > A Peer is a node that can do the four things. > - JOIN and LEAVE (the DHT). > - Route messages (based on the DHT routing table it maintains). > - Store data for other nodes. > - Initiate GET and PUT. This Peer is a node that acts as client and as peer. You can imagine that there are no nodes in the overlay that act only as peers, but maybe it is useful keeping the two roles separeted. -- Matteo From fluffy at cisco.com Sat Jun 10 13:52:10 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sat, 10 Jun 2006 10:52:10 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <049101c68c53$a8ca6b10$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> Message-ID: <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > interop partner insists). I think you interop partner is correct. From huang-ming.pan at comcast.net Sat Jun 10 13:59:18 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sat, 10 Jun 2006 10:59:18 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> Message-ID: <003301c68cb7$99239e70$6400a8c0@comcast.net> > > On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > > It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > interop partner insists). > > I think you interop partner is correct. Is my conclusion that the UAS must send response to ipX:portY also correct? If yes, what could the address ipX:portY possibly mean? Thanks. Peter From dean.willis at softarmor.com Sun Jun 11 03:30:31 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Sun, 11 Jun 2006 02:30:31 -0500 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Concepts and terminology draft posted) In-Reply-To: References: Message-ID: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> On Jun 10, 2006, at 7:24 AM, Matteo Peraldo wrote: > It seems there is some confusion about peer and client. Someone is > viewing at them as roles, someone as real distinguished nodes. > > Obviously, considering them roles, a node can play the role of peer > and client both. But peer and client are not the some role and they > are not overlapped. > > When a node works in the mainteinance of DHT it acts as peer, when > initiates GET or PUT it acts as client. > >> A Peer is a node that can do the four things. >> - JOIN and LEAVE (the DHT). >> - Route messages (based on the DHT routing table it maintains). >> - Store data for other nodes. >> - Initiate GET and PUT. > > This Peer is a node that acts as client and as peer. You can imagine > that there are no nodes in the overlay that act only as peers, but > maybe it is useful keeping the two roles separeted. > I think I like this taxonomy. But here's a question: If a node that acts as both a "peer" and a "client" is executing a GET operation, does it do so using the same protocol that a node that only acts as a "client" would use? This gets to the heart of whether the client protocol (from the concepts draft) is a syntactic subset of the peer protocol from that draft. Some people have proposed that the client protocol might be SIP (perhaps REGISTER transactions) and that the peer protocol might be something entirely different that also provides a mechanism for GET and PUT. If we have this kind of relationship between the two protocols, then I don't think the above taxonomy accurately describes the model. -- Dean From enrico.marocco at telecomitalia.it Sun Jun 11 06:36:06 2006 From: enrico.marocco at telecomitalia.it (Marocco Enrico) Date: Sun, 11 Jun 2006 12:36:06 +0200 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Conceptsand terminology draft posted) References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> Message-ID: <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> Dean Willis wrote: >> This Peer is a node that acts as client and as peer. You can imagine >> that there are no nodes in the overlay that act only as peers, but >> maybe it is useful keeping the two roles separeted. >> > > I think I like this taxonomy. > > But here's a question: If a node that acts as both a "peer" and a > "client" is executing a GET operation, does it do so using the same > protocol that a node that only acts as a "client" would use? I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed by a client has to locally retrieve credentials for signing or encripting the record being inserted, while the PUT served and then performed by a peer has to check them for authorizing the operation. I look at them as two distinct operations, both syntactically and functionally. > This gets to the heart of whether the client protocol (from the > concepts draft) is a syntactic subset of the peer protocol from that > draft. > > Some people have proposed that the client protocol might be SIP > (perhaps REGISTER transactions) and that the peer protocol might be > something entirely different that also provides a mechanism for GET > and PUT. If we have this kind of relationship between the two > protocols, then I don't think the above taxonomy accurately describes > the model. With this kind of relationship the PUT operation performed by a node which was both a client and a peer would result in a REGISTER sent locally. Actually it doesn't look different from the case where the peer performs directly the PUT in place of the user agent. 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/20060611/039575c6/attachment.html From huang-ming.pan at comcast.net Sun Jun 11 12:40:47 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sun, 11 Jun 2006 09:40:47 -0700 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand terminology draft posted) References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> Message-ID: <001601c68d75$cb68f060$6400a8c0@comcast.net> client : peer = coke : pepsi ??? imo, on = ua (once find itself restricted) sn = on + registrar + proxy + dht for "simple session" initiation (!= "simple" session initiation:), p2psip(on,sn) = sip(ua,proxy) p2psip(sn,sn) = sip(all) + dht minimally, on = aa + sip_ua + stunx_client + turn_client sn = aa + sip_full + stunx + turn + dht where, stunx=distributed stun (!= rfc3489) on - aa = toy sn - aa = joke simpler? Peter ----- Original Message ----- From: Marocco Enrico To: Dean Willis ; Matteo Peraldo Cc: p2p-sip at cs.columbia.edu Sent: Sunday, June 11, 2006 3:36 AM Subject: Re: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand terminology draft posted) Dean Willis wrote: >> This Peer is a node that acts as client and as peer. You can imagine >> that there are no nodes in the overlay that act only as peers, but >> maybe it is useful keeping the two roles separeted. >> > > I think I like this taxonomy. > > But here's a question: If a node that acts as both a "peer" and a > "client" is executing a GET operation, does it do so using the same > protocol that a node that only acts as a "client" would use? I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed by a client has to locally retrieve credentials for signing or encripting the record being inserted, while the PUT served and then performed by a peer has to check them for authorizing the operation. I look at them as two distinct operations, both syntactically and functionally. > This gets to the heart of whether the client protocol (from the > concepts draft) is a syntactic subset of the peer protocol from that > draft. > > Some people have proposed that the client protocol might be SIP > (perhaps REGISTER transactions) and that the peer protocol might be > something entirely different that also provides a mechanism for GET > and PUT. If we have this kind of relationship between the two > protocols, then I don't think the above taxonomy accurately describes > the model. With this kind of relationship the PUT operation performed by a node which was both a client and a peer would result in a REGISTER sent locally. Actually it doesn't look different from the case where the peer performs directly the PUT in place of the user agent. 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 -------------------------------------------------------------------- _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Sun Jun 11 13:07:32 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sun, 11 Jun 2006 10:07:32 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> Message-ID: <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> > > On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > > It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > interop partner insists). > > I think you interop partner is correct. Actually the partner raised the issue via some sort of stress test possibly for curiosity. Her UAC (likely a robot) cannot resend the request on no response. There seems nothing practically correct or incorrect. Unless pointers to convincing explanations about what the responded address "ipX:portY" may be could kindly show up, personally I will close the case as an incompleteness of current SIP related RFCs. (Never mind it, for SIP alone seems never designed to cover all NAT scenarios:) From fluffy at cisco.com Sun Jun 11 16:02:33 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 11 Jun 2006 13:02:33 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003301c68cb7$99239e70$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003301c68cb7$99239e70$6400a8c0@comcast.net> Message-ID: <28B90DC3-E08E-4FEC-9BEB-50030743D5BE@cisco.com> On Jun 10, 2006, at 10:59 AM, Peter Pan wrote: >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: >> >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my >>> interop partner insists). >> >> I think you interop partner is correct. > > Is my conclusion that the UAS must send response to ipX:portY also > correct? > If yes, what could the address ipX:portY possibly mean? I don't understand what you mean by this. From fluffy at cisco.com Sun Jun 11 20:11:42 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 11 Jun 2006 17:11:42 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> Message-ID: I don't think there is anything "incomplete" about this part of the spec. I think it is pretty clear how it works and I explained why it worked that way in previous email. The way you are proposing (if I understand correctly, and I certainly may not) does not work with substantial amounts of equipment that sends and receives from different ports. On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > >> >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: >> >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my >>> interop partner insists). >> >> I think you interop partner is correct. > > Actually the partner raised the issue via some sort of stress test > possibly > for curiosity. Her UAC (likely a robot) cannot resend the request > on no > response. There seems nothing practically correct or incorrect. > > Unless pointers to convincing explanations about what the responded > address > "ipX:portY" may be could kindly show up, personally I will close > the case as > an incompleteness of current SIP related RFCs. (Never mind it, for > SIP alone > seems never designed to cover all NAT scenarios:) From huang-ming.pan at comcast.net Sun Jun 11 23:28:24 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sun, 11 Jun 2006 20:28:24 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> Message-ID: <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> OK, with tx and rx on different ports, let's take the following UAC as a specific example: It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public addr 209.133.55.1:20006. It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to public addr 209.133.55.1:20007. (Remind you that, in the issue of debate, the ip in Via sent-by is NOT equal to that in UDP header) Now UAC sends a req via UDP, with Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) UDP src addr= 209.133.55.1:20006 According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. Does the address 209.133.55.1:5070 make any sense? No, apparently!! (Neither, if send-by = 192.168.1.1:5060) You could say that UAC should probe STUN beforehand and set Via sent-by to the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that will NOT be the same problem as the debated one because of precondition in the reminder above, not to mention that RFC 3581 (or rport) would have been completely unnecessary if UA could always consult STUN beforehand to set sent-by to a public address. Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Sunday, June 11, 2006 5:11 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't think there is anything "incomplete" about this part of the > spec. I think it is pretty clear how it works and I explained why it > worked that way in previous email. The way you are proposing (if I > understand correctly, and I certainly may not) does not work with > substantial amounts of equipment that sends and receives from > different ports. > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > >> > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > >> > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > >>> interop partner insists). > >> > >> I think you interop partner is correct. > > > > Actually the partner raised the issue via some sort of stress test > > possibly > > for curiosity. Her UAC (likely a robot) cannot resend the request > > on no > > response. There seems nothing practically correct or incorrect. > > > > Unless pointers to convincing explanations about what the responded > > address > > "ipX:portY" may be could kindly show up, personally I will close > > the case as > > an incompleteness of current SIP related RFCs. (Never mind it, for > > SIP alone > > seems never designed to cover all NAT scenarios:) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060611/fc3e19e0/attachment.html From fluffy at cisco.com Sun Jun 11 23:48:39 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 11 Jun 2006 20:48:39 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> Message-ID: If the device receives SIP on the same ports it sends from, it adds an rport and all of this is irrelevant. If it does not send from the same port it receives from - nothing you are proposing will work and it will break existing devices. The advice is very simple, make you device send and receive SIP from same UDP port and add an rport flag in the Via - then everything works fine. This does not need STUN to work, it works fine with NATs, and it is backwards compatible with devices that don't send on same port they receive on. On Jun 11, 2006, at 8:28 PM, Peter Pan wrote: > OK, with tx and rx on different ports, let's take the following UAC > as a specific example: > > It sends msg at private address 192.168.1.1:5060 which is NAT-ed to > public addr 209.133.55.1:20006. > It recvs msg at private address 192.168.1.1:5070 which is NAT-ed > to public addr 209.133.55.1:20007. > > (Remind you that, in the issue of debate, the ip in Via sent-by is > NOT equal to that in UDP header) > > Now UAC sends a req via UDP, with > > Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) > UDP src addr= 209.133.55.1:20006 > > According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. > > Does the address 209.133.55.1:5070 make any sense? No, apparently!! > > (Neither, if send-by = 192.168.1.1:5060) > > You could say that UAC should probe STUN beforehand and set Via > sent-by to the public (rx) address 209.133.55.1:20007 and it will > work. Yes, but that will NOT be the same problem as the debated one > because of precondition in the reminder above, not to mention that > RFC 3581 (or rport) would have been completely unnecessary if UA > could always consult STUN beforehand to set sent-by to a public > address. > > Peter > ----- Original Message ----- > From: "Cullen Jennings" > To: "Peter Pan" > Cc: > Sent: Sunday, June 11, 2006 5:11 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > I don't think there is anything "incomplete" about this part of the > > spec. I think it is pretty clear how it works and I explained why it > > worked that way in previous email. The way you are proposing (if I > > understand correctly, and I certainly may not) does not work with > > substantial amounts of equipment that sends and receives from > > different ports. > > > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > > > > >> > > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > >> > > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > >>> interop partner insists). > > >> > > >> I think you interop partner is correct. > > > > > > Actually the partner raised the issue via some sort of stress test > > > possibly > > > for curiosity. Her UAC (likely a robot) cannot resend the request > > > on no > > > response. There seems nothing practically correct or incorrect. > > > > > > Unless pointers to convincing explanations about what the > responded > > > address > > > "ipX:portY" may be could kindly show up, personally I will close > > > the case as > > > an incompleteness of current SIP related RFCs. (Never mind it, for > > > SIP alone > > > seems never designed to cover all NAT scenarios:) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060611/eb7bd7f9/attachment.html From huang-ming.pan at comcast.net Mon Jun 12 00:10:51 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sun, 11 Jun 2006 21:10:51 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> Message-ID: <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> I'm sorry that you never read carefully the problem raised by my interop partner and my messages so far, especially on the "unequal ip" precondition. If you did, we can save all these back and forth :) BTW, please see [pp]s inline. Peter ----- Original Message ----- From: Cullen Jennings To: Peter Pan Cc: p2p-sip at cs.columbia.edu Sent: Sunday, June 11, 2006 8:48 PM Subject: Re: [p2p-sip] What are we doing, question 2 If the device receives SIP on the same ports it sends from, it adds an rport and all of this is irrelevant. If it does not send from the same port it receives from - nothing you are proposing will work and it will break existing devices. [pp]: No, when rx and tx on different ports and UAC sets sent-by = public rx address (w/o rport), it will work. Just need STUN. The advice is very simple, make you device send and receive SIP from same UDP port and add an rport flag in the Via - then everything works fine. [pp]: Didn't you say "substantial amounts of equipment that sends and receives from different ports" below??? I'm worry about those equipments, not mine. My device tx/rx on the same port from day one. I always hate trouble, but my interop partner seems love trouble :-) This does not need STUN to work, it works fine with NATs, and it is backwards compatible with devices that don't send on same port they receive on. [pp]: How can RFC 3261/3581 be "backwards compatible" with these substantial amounts of equipments when they are behind NAT without STUN ??? I really doubt it without your further elaborations. Thanks!! On Jun 11, 2006, at 8:28 PM, Peter Pan wrote: OK, with tx and rx on different ports, let's take the following UAC as a specific example: It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public addr 209.133.55.1:20006. It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to public addr 209.133.55.1:20007. (Remind you that, in the issue of debate, the ip in Via sent-by is NOT equal to that in UDP header) Now UAC sends a req via UDP, with Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) UDP src addr= 209.133.55.1:20006 According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. Does the address 209.133.55.1:5070 make any sense? No, apparently!! (Neither, if send-by = 192.168.1.1:5060) You could say that UAC should probe STUN beforehand and set Via sent-by to the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that will NOT be the same problem as the debated one because of precondition in the reminder above, not to mention that RFC 3581 (or rport) would have been completely unnecessary if UA could always consult STUN beforehand to set sent-by to a public address. Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Sunday, June 11, 2006 5:11 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't think there is anything "incomplete" about this part of the > spec. I think it is pretty clear how it works and I explained why it > worked that way in previous email. The way you are proposing (if I > understand correctly, and I certainly may not) does not work with > substantial amounts of equipment that sends and receives from > different ports. > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > >> > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > >> > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > >>> interop partner insists). > >> > >> I think you interop partner is correct. > > > > Actually the partner raised the issue via some sort of stress test > > possibly > > for curiosity. Her UAC (likely a robot) cannot resend the request > > on no > > response. There seems nothing practically correct or incorrect. > > > > Unless pointers to convincing explanations about what the responded > > address > > "ipX:portY" may be could kindly show up, personally I will close > > the case as > > an incompleteness of current SIP related RFCs. (Never mind it, for > > SIP alone > > seems never designed to cover all NAT scenarios:) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/38ea6fe5/attachment-0001.html From huang-ming.pan at comcast.net Mon Jun 12 00:22:45 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Sun, 11 Jun 2006 21:22:45 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net><049101c68c53$a8ca6b10$6400a8c0@comcast.net><0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com><003d01c68d79$87e3f2a0$6400a8c0@comcast.net><001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> Message-ID: <005601c68dd7$dada6a30$6400a8c0@comcast.net> Also, I proposed nothing, did I? I only asked a question raised by my interop partner and requested for comment or answer to the question as well as for clarification of possible incompleteness of current RFC regarding the raised question. Peter ----- Original Message ----- From: Peter Pan To: Cullen Jennings Cc: p2p-sip at cs.columbia.edu Sent: Sunday, June 11, 2006 9:10 PM Subject: Re: [p2p-sip] What are we doing, question 2 I'm sorry that you never read carefully the problem raised by my interop partner and my messages so far, especially on the "unequal ip" precondition. If you did, we can save all these back and forth :) BTW, please see [pp]s inline. Peter ----- Original Message ----- From: Cullen Jennings To: Peter Pan Cc: p2p-sip at cs.columbia.edu Sent: Sunday, June 11, 2006 8:48 PM Subject: Re: [p2p-sip] What are we doing, question 2 If the device receives SIP on the same ports it sends from, it adds an rport and all of this is irrelevant. If it does not send from the same port it receives from - nothing you are proposing will work and it will break existing devices. [pp]: No, when rx and tx on different ports and UAC sets sent-by = public rx address (w/o rport), it will work. Just need STUN. The advice is very simple, make you device send and receive SIP from same UDP port and add an rport flag in the Via - then everything works fine. [pp]: Didn't you say "substantial amounts of equipment that sends and receives from different ports" below??? I'm worry about those equipments, not mine. My device tx/rx on the same port from day one. I always hate trouble, but my interop partner seems love trouble :-) This does not need STUN to work, it works fine with NATs, and it is backwards compatible with devices that don't send on same port they receive on. [pp]: How can RFC 3261/3581 be "backwards compatible" with these substantial amounts of equipments when they are behind NAT without STUN ??? I really doubt it without your further elaborations. Thanks!! On Jun 11, 2006, at 8:28 PM, Peter Pan wrote: OK, with tx and rx on different ports, let's take the following UAC as a specific example: It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public addr 209.133.55.1:20006. It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to public addr 209.133.55.1:20007. (Remind you that, in the issue of debate, the ip in Via sent-by is NOT equal to that in UDP header) Now UAC sends a req via UDP, with Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) UDP src addr= 209.133.55.1:20006 According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. Does the address 209.133.55.1:5070 make any sense? No, apparently!! (Neither, if send-by = 192.168.1.1:5060) You could say that UAC should probe STUN beforehand and set Via sent-by to the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that will NOT be the same problem as the debated one because of precondition in the reminder above, not to mention that RFC 3581 (or rport) would have been completely unnecessary if UA could always consult STUN beforehand to set sent-by to a public address. Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Sunday, June 11, 2006 5:11 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't think there is anything "incomplete" about this part of the > spec. I think it is pretty clear how it works and I explained why it > worked that way in previous email. The way you are proposing (if I > understand correctly, and I certainly may not) does not work with > substantial amounts of equipment that sends and receives from > different ports. > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > >> > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > >> > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > >>> interop partner insists). > >> > >> I think you interop partner is correct. > > > > Actually the partner raised the issue via some sort of stress test > > possibly > > for curiosity. Her UAC (likely a robot) cannot resend the request > > on no > > response. There seems nothing practically correct or incorrect. > > > > Unless pointers to convincing explanations about what the responded > > address > > "ipX:portY" may be could kindly show up, personally I will close > > the case as > > an incompleteness of current SIP related RFCs. (Never mind it, for > > SIP alone > > seems never designed to cover all NAT scenarios:) _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From stefan_nitschke at hotmail.com Mon Jun 12 04:24:23 2006 From: stefan_nitschke at hotmail.com (Stefan Nitschke) Date: Mon, 12 Jun 2006 08:24:23 +0000 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> Message-ID: Hi Peter, from my understanding the client has to use: Via sent-by = 192.168.1.1:5070;rport This way it signals to the reciever that it does support symmetric signaling and the receiver can use the rport and received parameters to send it response to. A missing "rport" has the meaning of non symmetric signaling. regards, Stefan >From: "Peter Pan" >To: "Cullen Jennings" >CC: p2p-sip at cs.columbia.edu >Subject: Re: [p2p-sip] What are we doing, question 2 >Date: Sun, 11 Jun 2006 20:28:24 -0700 > >OK, with tx and rx on different ports, let's take the following UAC as a >specific example: > >It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public >addr 209.133.55.1:20006. >It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to public >addr 209.133.55.1:20007. > >(Remind you that, in the issue of debate, the ip in Via sent-by is NOT >equal to that in UDP header) > >Now UAC sends a req via UDP, with > > Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) > UDP src addr= 209.133.55.1:20006 > >According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. > >Does the address 209.133.55.1:5070 make any sense? No, apparently!! > >(Neither, if send-by = 192.168.1.1:5060) > >You could say that UAC should probe STUN beforehand and set Via sent-by to >the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that >will NOT be the same problem as the debated one because of precondition in >the reminder above, not to mention that RFC 3581 (or rport) would have been >completely unnecessary if UA could always consult STUN beforehand to set >sent-by to a public address. > >Peter >----- Original Message ----- >From: "Cullen Jennings" >To: "Peter Pan" >Cc: >Sent: Sunday, June 11, 2006 5:11 PM >Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > I don't think there is anything "incomplete" about this part of the > > spec. I think it is pretty clear how it works and I explained why it > > worked that way in previous email. The way you are proposing (if I > > understand correctly, and I certainly may not) does not work with > > substantial amounts of equipment that sends and receives from > > different ports. > > > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > > > > >> > > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > >> > > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > >>> interop partner insists). > > >> > > >> I think you interop partner is correct. > > > > > > Actually the partner raised the issue via some sort of stress test > > > possibly > > > for curiosity. Her UAC (likely a robot) cannot resend the request > > > on no > > > response. There seems nothing practically correct or incorrect. > > > > > > Unless pointers to convincing explanations about what the responded > > > address > > > "ipX:portY" may be could kindly show up, personally I will close > > > the case as > > > an incompleteness of current SIP related RFCs. (Never mind it, for > > > SIP alone > > > seems never designed to cover all NAT scenarios:) >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From eunsoo at research.panasonic.com Mon Jun 12 11:01:12 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 12 Jun 2006 11:01:12 -0400 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Conceptsand terminology draft posted) In-Reply-To: <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> Message-ID: <448D81B8.8060309@research.panasonic.com> Marocco Enrico wrote: > > Dean Willis wrote: > >> This Peer is a node that acts as client and as peer. You can imagine > >> that there are no nodes in the overlay that act only as peers, but > >> maybe it is useful keeping the two roles separeted. > >> > > > > I think I like this taxonomy. > > > > But here's a question: If a node that acts as both a "peer" and a > > "client" is executing a GET operation, does it do so using the same > > protocol that a node that only acts as a "client" would use? > > I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed > by a client has to locally retrieve credentials for signing or > encripting the record being inserted, while the PUT served and then > performed by a peer has to check them for authorizing the > operation. I look at them as two distinct operations, both > syntactically and functionally. I'd say no. When a Client initiatiates GET/PUT, the message from Client is sent to a Peer (GET/PUT Request message of the Client Protocol). Then the Peer forwards the request (not the message) to other Peers (GET/PUT Request message of the Peer Protocol) according to their routing algorithm. If a Peer initiates GET/PUT, why should the Peer send a GET/PUT Request message of the Client Protocol to another Peer? That will cause just an unnecessary message check and/or conversion from a Client Protocol's GET/PUT Request message to a Peer Protocol's GET/PUT Request message. So when a Peer initiates GET/PUT, it can and should send just a Peer Protocol's GET/PUT Request message from the beginning. That is all necessary. > > > This gets to the heart of whether the client protocol (from the > > concepts draft) is a syntactic subset of the peer protocol from that > > draft. > > > > Some people have proposed that the client protocol might be SIP > > (perhaps REGISTER transactions) and that the peer protocol might be > > something entirely different that also provides a mechanism for GET > > and PUT. If we have this kind of relationship between the two > > protocols, then I don't think the above taxonomy accurately describes > > the model. > > With this kind of relationship the PUT operation performed by a node > which was both a client and a peer would result in a REGISTER sent > locally. Actually it doesn't look different from the case where the > peer performs directly the PUT in place of the user agent. Your assumption about the protocol is beyond the scope of the discussion. We should stick to the logically distinguished two protocols - the Client Protocol and the Peer Protocol - in this architectural discussion. Another note about Client and Peer. I think the reason Client is introduced is to accomodate devices with limited physical resources (eg. limited cpu power or battery) or in a limited environment (eg. private address). To put it differently, a participant becomes a Client because it is not capable or qualified to participate in the routing and storage service for other participants. So there was a suggestion that a Peer be called a Full Peer and a Client a Limited Peer. A participatnt that can be a Peer is certainly capable of what a Client does. Why would we define another type of a limited peer that cannot initiate GET/PUT? Thanks. Eunsoo From huang-ming.pan at comcast.net Mon Jun 12 11:13:51 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 08:13:51 -0700 Subject: [p2p-sip] What are we doing, question 2 References: Message-ID: <000d01c68e32$d0f0f880$6400a8c0@comcast.net> Hi, Stefan. Thanks for the comment. Unfortunately, as you could see below, the client below is NOT supporting symmetric signaling; it uses asymmetric signaling. Cullen mentioned below that there are substantial amounts of such equipments that sends and receives from different ports. Do you or anyone know how RFC 3261/3581 and other SIP RFCs together can be "backwards compatible" with those Cullen-mentioned "substantial amounts of equipments that sends and receives from different ports" when they are behind (any kind of) NAT and without STUN? I will appreciate any kindly elaboration. Thanks. Peter ----- Original Message ----- From: "Stefan Nitschke" To: Sent: Monday, June 12, 2006 1:24 AM Subject: Re: [p2p-sip] What are we doing, question 2 > Hi Peter, > > from my understanding the client has to use: > > Via sent-by = 192.168.1.1:5070;rport > > This way it signals to the reciever that it does support symmetric signaling > and the receiver can use the rport and received parameters to send it > response to. > A missing "rport" has the meaning of non symmetric signaling. > > regards, > Stefan > > > >From: "Peter Pan" > >To: "Cullen Jennings" > >CC: p2p-sip at cs.columbia.edu > >Subject: Re: [p2p-sip] What are we doing, question 2 > >Date: Sun, 11 Jun 2006 20:28:24 -0700 > > > >OK, with tx and rx on different ports, let's take the following UAC as a > >specific example: > > > >It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public > >addr 209.133.55.1:20006. > >It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to public > >addr 209.133.55.1:20007. > > > >(Remind you that, in the issue of debate, the ip in Via sent-by is NOT > >equal to that in UDP header) > > > >Now UAC sends a req via UDP, with > > > > Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) > > UDP src addr= 209.133.55.1:20006 > > > >According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. > > > >Does the address 209.133.55.1:5070 make any sense? No, apparently!! > > > >(Neither, if send-by = 192.168.1.1:5060) > > > >You could say that UAC should probe STUN beforehand and set Via sent-by to > >the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that > >will NOT be the same problem as the debated one because of precondition in > >the reminder above, not to mention that RFC 3581 (or rport) would have been > >completely unnecessary if UA could always consult STUN beforehand to set > >sent-by to a public address. > > > >Peter > >----- Original Message ----- > >From: "Cullen Jennings" > >To: "Peter Pan" > >Cc: > >Sent: Sunday, June 11, 2006 5:11 PM > >Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > I don't think there is anything "incomplete" about this part of the > > > spec. I think it is pretty clear how it works and I explained why it > > > worked that way in previous email. The way you are proposing (if I > > > understand correctly, and I certainly may not) does not work with > > > substantial amounts of equipment that sends and receives from > > > different ports. > > > > > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > > > > > > > >> > > > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > > >> > > > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > > >>> interop partner insists). > > > >> > > > >> I think you interop partner is correct. > > > > > > > > Actually the partner raised the issue via some sort of stress test > > > > possibly > > > > for curiosity. Her UAC (likely a robot) cannot resend the request > > > > on no > > > > response. There seems nothing practically correct or incorrect. > > > > > > > > Unless pointers to convincing explanations about what the responded > > > > address > > > > "ipX:portY" may be could kindly show up, personally I will close > > > > the case as > > > > an incompleteness of current SIP related RFCs. (Never mind it, for > > > > SIP alone > > > > seems never designed to cover all NAT scenarios:) > > > >_______________________________________________ > >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/7391f494/attachment-0001.html From bryan at ethernot.org Mon Jun 12 11:16:20 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 12 Jun 2006 11:16:20 -0400 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Conceptsand terminology draft posted) In-Reply-To: <448D81B8.8060309@research.panasonic.com> References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> <448D81B8.8060309@research.panasonic.com> Message-ID: <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> We do have lots of put/get type things as peers enter and leave and need to move resources. I agree with the arguments you make if the two protocols are different, but of course, that isn't decided yet. The two *could* be different, or could be one and the same. If they are one and the same, then of course the get/put are logically identical between the two, if the protocols are different, then a peer should probably use peer type operations rather than client type. Personally, I still think we can do this with one protocol, but at some level, this debate is a bit orthogonal to the discussion of what we want to do at the most fundamental level. I think we can agree that we want to: Allow endpoints and other "edge" devices (clients, in the document) to get/put Allow peers to get/put in some way, as well as other operations The purpose of the get/put is the same between them, to place and retrieve information. In some designs, it is also the same protocol wise, and in others it isn't. That will likely be decided as the protocol design moves forward, I would think. David On 6/12/06, Eunsoo Shim wrote: > Marocco Enrico wrote: > > > > > Dean Willis wrote: > > >> This Peer is a node that acts as client and as peer. You can imagine > > >> that there are no nodes in the overlay that act only as peers, but > > >> maybe it is useful keeping the two roles separeted. > > >> > > > > > > I think I like this taxonomy. > > > > > > But here's a question: If a node that acts as both a "peer" and a > > > "client" is executing a GET operation, does it do so using the same > > > protocol that a node that only acts as a "client" would use? > > > > I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed > > by a client has to locally retrieve credentials for signing or > > encripting the record being inserted, while the PUT served and then > > performed by a peer has to check them for authorizing the > > operation. I look at them as two distinct operations, both > > syntactically and functionally. > > I'd say no. > When a Client initiatiates GET/PUT, the message from Client is sent to a > Peer (GET/PUT Request message of the Client Protocol). > Then the Peer forwards the request (not the message) to other Peers > (GET/PUT Request message of the Peer Protocol) according to their > routing algorithm. > > If a Peer initiates GET/PUT, why should the Peer send a GET/PUT Request > message of the Client Protocol to another Peer? That will cause just an > unnecessary message check and/or conversion from a Client Protocol's > GET/PUT Request message to a Peer Protocol's GET/PUT Request message. > > So when a Peer initiates GET/PUT, it can and should send just a Peer > Protocol's GET/PUT Request message from the beginning. That is all > necessary. > > > > > > This gets to the heart of whether the client protocol (from the > > > concepts draft) is a syntactic subset of the peer protocol from that > > > draft. > > > > > > Some people have proposed that the client protocol might be SIP > > > (perhaps REGISTER transactions) and that the peer protocol might be > > > something entirely different that also provides a mechanism for GET > > > and PUT. If we have this kind of relationship between the two > > > protocols, then I don't think the above taxonomy accurately describes > > > the model. > > > > With this kind of relationship the PUT operation performed by a node > > which was both a client and a peer would result in a REGISTER sent > > locally. Actually it doesn't look different from the case where the > > peer performs directly the PUT in place of the user agent. > > Your assumption about the protocol is beyond the scope of the discussion. > We should stick to the logically distinguished two protocols - the > Client Protocol and the Peer Protocol - in this architectural discussion. > > Another note about Client and Peer. > I think the reason Client is introduced is to accomodate devices with > limited physical resources (eg. limited cpu power or battery) or in a > limited environment (eg. private address). > To put it differently, a participant becomes a Client because it is not > capable or qualified to participate in the routing and storage service > for other participants. So there was a suggestion that a Peer be called > a Full Peer and a Client a Limited Peer. > A participatnt that can be a Peer is certainly capable of what a Client > does. Why would we define another type of a limited peer that cannot > initiate GET/PUT? > > Thanks. > > Eunsoo > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From bryan at ethernot.org Mon Jun 12 11:19:04 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 12 Jun 2006 11:19:04 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <000d01c68e32$d0f0f880$6400a8c0@comcast.net> References: <000d01c68e32$d0f0f880$6400a8c0@comcast.net> Message-ID: <8b2769930606120819x60075564va2c19e99f3b43f56@mail.gmail.com> This might be a good thread to move to the Columbia SIP implementors mailing list. That is generally the place with the most experience on interop/implemenation type questions. David On 6/12/06, Peter Pan wrote: > > > Hi, Stefan. > > Thanks for the comment. > > Unfortunately, as you could see below, the client below is NOT supporting > symmetric signaling; it uses asymmetric signaling. Cullen mentioned below > that there are substantial amounts of such equipments that sends and > receives from different ports. > > Do you or anyone know how RFC 3261/3581 and other SIP RFCs together can be > "backwards compatible" with those Cullen-mentioned "substantial amounts of > equipments that sends and receives from different ports" when they are > behind (any kind of) NAT and without STUN? > > I will appreciate any kindly elaboration. > > Thanks. > > > Peter > > ----- Original Message ----- > From: "Stefan Nitschke" > To: > Sent: Monday, June 12, 2006 1:24 AM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > Hi Peter, > > > > from my understanding the client has to use: > > > > Via sent-by = 192.168.1.1:5070;rport > > > > This way it signals to the reciever that it does support symmetric > signaling > > and the receiver can use the rport and received parameters to send it > > response to. > > A missing "rport" has the meaning of non symmetric signaling. > > > > regards, > > Stefan > > > > > > >From: "Peter Pan" > > >To: "Cullen Jennings" > > >CC: p2p-sip at cs.columbia.edu > > >Subject: Re: [p2p-sip] What are we doing, question 2 > > >Date: Sun, 11 Jun 2006 20:28:24 -0700 > > > > > >OK, with tx and rx on different ports, let's take the following UAC as a > > >specific example: > > > > > >It sends msg at private address 192.168.1.1:5060 which is NAT-ed to > public > > >addr 209.133.55.1:20006. > > >It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to > public > > >addr 209.133.55.1:20007. > > > > > >(Remind you that, in the issue of debate, the ip in Via sent-by is NOT > > >equal to that in UDP header) > > > > > >Now UAC sends a req via UDP, with > > > > > > Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) > > > UDP src addr= 209.133.55.1:20006 > > > > > >According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. > > > > > >Does the address 209.133.55.1:5070 make any sense? No, apparently!! > > > > > >(Neither, if send-by = 192.168.1.1:5060) > > > > > >You could say that UAC should probe STUN beforehand and set Via sent-by > to > > >the public (rx) address 209.133.55.1:20007 and it will work. Yes, but > that > > >will NOT be the same problem as the debated one because of precondition > in > > >the reminder above, not to mention that RFC 3581 (or rport) would have > been > > >completely unnecessary if UA could always consult STUN beforehand to set > > >sent-by to a public address. > > > > > >Peter > > >----- Original Message ----- > > >From: "Cullen Jennings" > > >To: "Peter Pan" > > >Cc: > > >Sent: Sunday, June 11, 2006 5:11 PM > > >Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > > > I don't think there is anything "incomplete" about this part of the > > > > spec. I think it is pretty clear how it works and I explained why it > > > > worked that way in previous email. The way you are proposing (if I > > > > understand correctly, and I certainly may not) does not work with > > > > substantial amounts of equipment that sends and receives from > > > > different ports. > > > > > > > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > > > > > > > > > > >> > > > > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > > > >> > > > > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > > > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > > > >>> interop partner insists). > > > > >> > > > > >> I think you interop partner is correct. > > > > > > > > > > Actually the partner raised the issue via some sort of stress test > > > > > possibly > > > > > for curiosity. Her UAC (likely a robot) cannot resend the request > > > > > on no > > > > > response. There seems nothing practically correct or incorrect. > > > > > > > > > > Unless pointers to convincing explanations about what the responded > > > > > address > > > > > "ipX:portY" may be could kindly show up, personally I will close > > > > > the case as > > > > > an incompleteness of current SIP related RFCs. (Never mind it, for > > > > > SIP alone > > > > > seems never designed to cover all NAT scenarios:) > > > > > > >_______________________________________________ > > >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 > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From eunsoo at research.panasonic.com Mon Jun 12 11:21:01 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 12 Jun 2006 11:21:01 -0400 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Conceptsand terminology draft posted) In-Reply-To: <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> <448D81B8.8060309@research.panasonic.com> <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> Message-ID: <448D865D.3070004@research.panasonic.com> Sounds reasonable to me. Thanks. Eunsoo David A. Bryan wrote: > We do have lots of put/get type things as peers enter and leave and > need to move resources. I agree with the arguments you make if the two > protocols are different, but of course, that isn't decided yet. The > two *could* be different, or could be one and the same. If they are > one and the same, then of course the get/put are logically identical > between the two, if the protocols are different, then a peer should > probably use peer type operations rather than client type. > > Personally, I still think we can do this with one protocol, but at > some level, this debate is a bit orthogonal to the discussion of what > we want to do at the most fundamental level. I think we can agree that > we want to: > > Allow endpoints and other "edge" devices (clients, in the document) to > get/put > Allow peers to get/put in some way, as well as other operations > > The purpose of the get/put is the same between them, to place and > retrieve information. In some designs, it is also the same protocol > wise, and in others it isn't. That will likely be decided as the > protocol design moves forward, I would think. > > David > > On 6/12/06, Eunsoo Shim wrote: > >> Marocco Enrico wrote: >> >> > >> > Dean Willis wrote: >> > >> This Peer is a node that acts as client and as peer. You can >> imagine >> > >> that there are no nodes in the overlay that act only as peers, but >> > >> maybe it is useful keeping the two roles separeted. >> > >> >> > > >> > > I think I like this taxonomy. >> > > >> > > But here's a question: If a node that acts as both a "peer" and a >> > > "client" is executing a GET operation, does it do so using the same >> > > protocol that a node that only acts as a "client" would use? >> > >> > I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed >> > by a client has to locally retrieve credentials for signing or >> > encripting the record being inserted, while the PUT served and then >> > performed by a peer has to check them for authorizing the >> > operation. I look at them as two distinct operations, both >> > syntactically and functionally. >> >> I'd say no. >> When a Client initiatiates GET/PUT, the message from Client is sent to a >> Peer (GET/PUT Request message of the Client Protocol). >> Then the Peer forwards the request (not the message) to other Peers >> (GET/PUT Request message of the Peer Protocol) according to their >> routing algorithm. >> >> If a Peer initiates GET/PUT, why should the Peer send a GET/PUT Request >> message of the Client Protocol to another Peer? That will cause just an >> unnecessary message check and/or conversion from a Client Protocol's >> GET/PUT Request message to a Peer Protocol's GET/PUT Request message. >> >> So when a Peer initiates GET/PUT, it can and should send just a Peer >> Protocol's GET/PUT Request message from the beginning. That is all >> necessary. >> >> > >> > > This gets to the heart of whether the client protocol (from the >> > > concepts draft) is a syntactic subset of the peer protocol from that >> > > draft. >> > > >> > > Some people have proposed that the client protocol might be SIP >> > > (perhaps REGISTER transactions) and that the peer protocol might be >> > > something entirely different that also provides a mechanism for GET >> > > and PUT. If we have this kind of relationship between the two >> > > protocols, then I don't think the above taxonomy accurately >> describes >> > > the model. >> > >> > With this kind of relationship the PUT operation performed by a node >> > which was both a client and a peer would result in a REGISTER sent >> > locally. Actually it doesn't look different from the case where the >> > peer performs directly the PUT in place of the user agent. >> >> Your assumption about the protocol is beyond the scope of the >> discussion. >> We should stick to the logically distinguished two protocols - the >> Client Protocol and the Peer Protocol - in this architectural >> discussion. >> >> Another note about Client and Peer. >> I think the reason Client is introduced is to accomodate devices with >> limited physical resources (eg. limited cpu power or battery) or in a >> limited environment (eg. private address). >> To put it differently, a participant becomes a Client because it is not >> capable or qualified to participate in the routing and storage service >> for other participants. So there was a suggestion that a Peer be called >> a Full Peer and a Client a Limited Peer. >> A participatnt that can be a Peer is certainly capable of what a Client >> does. Why would we define another type of a limited peer that cannot >> initiate GET/PUT? >> >> Thanks. >> >> Eunsoo >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> From fluffy at cisco.com Mon Jun 12 11:36:36 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 08:36:36 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> Message-ID: <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> It seems your primary goal is to claim that something does not work. The truth is that it works fine if you follow the RFCs, many vendors have implemented it, there are many end points deployed that use rport. I don't know what else to say. You are right that if you violate the RFCs then it does not work. On Jun 11, 2006, at 9:10 PM, Peter Pan wrote: > I'm sorry that you never read carefully the problem raised by my > interop partner and my messages so far, especially on the "unequal > ip" precondition. If you did, we can save all these back and forth :) > > BTW, please see [pp]s inline. > > Peter > ----- Original Message ----- > From: Cullen Jennings > To: Peter Pan > Cc: p2p-sip at cs.columbia.edu > Sent: Sunday, June 11, 2006 8:48 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > > If the device receives SIP on the same ports it sends from, it adds > an rport and all of this is irrelevant. If it does not send from > the same port it receives from - nothing you are proposing will > work and it will break existing devices. > [pp]: No, when rx and tx on different ports and UAC sets sent-by = > public rx address (w/o rport), it will work. Just need STUN. > > The advice is very simple, make you device send and receive SIP > from same UDP port and add an rport flag in the Via - then > everything works fine. > [pp]: Didn't you say "substantial amounts of equipment that sends > and receives from different ports" below??? I'm worry about > thoseequipments, not mine. > > My device tx/rx on the same port from day one. I always hate > trouble, but my interop partner seems love trouble :-) > This does not need STUN to work, it works fine with NATs, and it is > backwards compatible with devices that don't send on same port they > receive on. > > [pp]: How can RFC 3261/3581 be "backwards compatible" with these > substantial amounts of equipments when they are behind NAT without > STUN ??? I really doubt it without your further elaborations. Thanks!! > > > On Jun 11, 2006, at 8:28 PM, Peter Pan wrote: > >> OK, with tx and rx on different ports, let's take the following >> UAC as a specific example: >> >> It sends msg at private address 192.168.1.1:5060 which is NAT-ed >> to public addr 209.133.55.1:20006. >> It recvs msg at private address 192.168.1.1:5070 which is NAT-ed >> to public addr 209.133.55.1:20007. >> >> (Remind you that, in the issue of debate, the ip in Via sent-by is >> NOT equal to that in UDP header) >> >> Now UAC sends a req via UDP, with >> >> Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) >> UDP src addr= 209.133.55.1:20006 >> >> According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. >> >> Does the address 209.133.55.1:5070 make any sense? No, apparently!! >> >> (Neither, if send-by = 192.168.1.1:5060) >> >> You could say that UAC should probe STUN beforehand and set Via >> sent-by to the public (rx) address 209.133.55.1:20007 and it will >> work. Yes, but that will NOT be the same problem as the debated >> one because of precondition in the reminder above, not to mention >> that RFC 3581 (or rport) would have been completely unnecessary if >> UA could always consult STUN beforehand to set sent-by to a public >> address. >> >> Peter >> ----- Original Message ----- >> From: "Cullen Jennings" >> To: "Peter Pan" >> Cc: >> Sent: Sunday, June 11, 2006 5:11 PM >> Subject: Re: [p2p-sip] What are we doing, question 2 >> >> > >> > I don't think there is anything "incomplete" about this part of the >> > spec. I think it is pretty clear how it works and I explained >> why it >> > worked that way in previous email. The way you are proposing (if I >> > understand correctly, and I certainly may not) does not work with >> > substantial amounts of equipment that sends and receives from >> > different ports. >> > >> > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: >> > >> > > >> > >> >> > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: >> > >> >> > >>> It is not clear in RFC 3581 whether or not UAS MAY >> "voluntarily" >> > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which >> is my >> > >>> interop partner insists). >> > >> >> > >> I think you interop partner is correct. >> > > >> > > Actually the partner raised the issue via some sort of stress >> test >> > > possibly >> > > for curiosity. Her UAC (likely a robot) cannot resend the request >> > > on no >> > > response. There seems nothing practically correct or incorrect. >> > > >> > > Unless pointers to convincing explanations about what the >> responded >> > > address >> > > "ipX:portY" may be could kindly show up, personally I will close >> > > the case as >> > > an incompleteness of current SIP related RFCs. (Never mind it, >> for >> > > SIP alone >> > > seems never designed to cover all NAT scenarios:) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/0ab92a77/attachment-0001.html From enrico.marocco at telecomitalia.it Mon Jun 12 11:44:28 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Mon, 12 Jun 2006 17:44:28 +0200 Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIP Conceptsand terminology draft posted) In-Reply-To: <448D865D.3070004@research.panasonic.com> References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com> <9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it> <448D81B8.8060309@research.panasonic.com> <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> <448D865D.3070004@research.panasonic.com> Message-ID: <448D8BDC.4020608@telecomitalia.it> It sounds reasonable to me too. Enrico Eunsoo Shim wrote: > Sounds reasonable to me. > Thanks. > > Eunsoo > > David A. Bryan wrote: > >> We do have lots of put/get type things as peers enter and leave and >> need to move resources. I agree with the arguments you make if the two >> protocols are different, but of course, that isn't decided yet. The >> two *could* be different, or could be one and the same. If they are >> one and the same, then of course the get/put are logically identical >> between the two, if the protocols are different, then a peer should >> probably use peer type operations rather than client type. >> >> Personally, I still think we can do this with one protocol, but at >> some level, this debate is a bit orthogonal to the discussion of what >> we want to do at the most fundamental level. I think we can agree that >> we want to: >> >> Allow endpoints and other "edge" devices (clients, in the document) to >> get/put >> Allow peers to get/put in some way, as well as other operations >> >> The purpose of the get/put is the same between them, to place and >> retrieve information. In some designs, it is also the same protocol >> wise, and in others it isn't. That will likely be decided as the >> protocol design moves forward, I would think. >> >> David >> >> On 6/12/06, Eunsoo Shim wrote: >> >>> Marocco Enrico wrote: >>> >>>> Dean Willis wrote: >>>>>> This Peer is a node that acts as client and as peer. You can >>> imagine >>>>>> that there are no nodes in the overlay that act only as peers, but >>>>>> maybe it is useful keeping the two roles separeted. >>>>>> >>>>> I think I like this taxonomy. >>>>> >>>>> But here's a question: If a node that acts as both a "peer" and a >>>>> "client" is executing a GET operation, does it do so using the same >>>>> protocol that a node that only acts as a "client" would use? >>>> I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed >>>> by a client has to locally retrieve credentials for signing or >>>> encripting the record being inserted, while the PUT served and then >>>> performed by a peer has to check them for authorizing the >>>> operation. I look at them as two distinct operations, both >>>> syntactically and functionally. >>> I'd say no. >>> When a Client initiatiates GET/PUT, the message from Client is sent to a >>> Peer (GET/PUT Request message of the Client Protocol). >>> Then the Peer forwards the request (not the message) to other Peers >>> (GET/PUT Request message of the Peer Protocol) according to their >>> routing algorithm. >>> >>> If a Peer initiates GET/PUT, why should the Peer send a GET/PUT Request >>> message of the Client Protocol to another Peer? That will cause just an >>> unnecessary message check and/or conversion from a Client Protocol's >>> GET/PUT Request message to a Peer Protocol's GET/PUT Request message. >>> >>> So when a Peer initiates GET/PUT, it can and should send just a Peer >>> Protocol's GET/PUT Request message from the beginning. That is all >>> necessary. >>> >>>>> This gets to the heart of whether the client protocol (from the >>>>> concepts draft) is a syntactic subset of the peer protocol from that >>>>> draft. >>>>> >>>>> Some people have proposed that the client protocol might be SIP >>>>> (perhaps REGISTER transactions) and that the peer protocol might be >>>>> something entirely different that also provides a mechanism for GET >>>>> and PUT. If we have this kind of relationship between the two >>>>> protocols, then I don't think the above taxonomy accurately >>> describes >>>>> the model. >>>> With this kind of relationship the PUT operation performed by a node >>>> which was both a client and a peer would result in a REGISTER sent >>>> locally. Actually it doesn't look different from the case where the >>>> peer performs directly the PUT in place of the user agent. >>> Your assumption about the protocol is beyond the scope of the >>> discussion. >>> We should stick to the logically distinguished two protocols - the >>> Client Protocol and the Peer Protocol - in this architectural >>> discussion. >>> >>> Another note about Client and Peer. >>> I think the reason Client is introduced is to accomodate devices with >>> limited physical resources (eg. limited cpu power or battery) or in a >>> limited environment (eg. private address). >>> To put it differently, a participant becomes a Client because it is not >>> capable or qualified to participate in the routing and storage service >>> for other participants. So there was a suggestion that a Peer be called >>> a Full Peer and a Client a Limited Peer. >>> A participatnt that can be a Peer is certainly capable of what a Client >>> does. Why would we define another type of a limited peer that cannot >>> initiate GET/PUT? >>> >>> Thanks. >>> >>> Eunsoo >>> _______________________________________________ >>> p2p-sip mailing list >>> p2p-sip at cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> > From huang-ming.pan at comcast.net Mon Jun 12 11:46:58 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 08:46:58 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> Message-ID: <003501c68e37$70bf2b80$6400a8c0@comcast.net> Please prove that it work fine with just a simple example, instead of guessing someone else's goal when his is different from yours. Often answer is biased when anger is in your mind. By the way, I never said rport does not work; it works and I DO use it. What I argue is that nothing in current SIP RFCs seems work with your mentioned "substantial amounts of such equipments that sends and receives from different ports" WITHOUT STUN. Thanks. Peter ----- Original Message ----- From: Cullen Jennings To: Peter Pan Cc: p2p-sip at cs.columbia.edu Sent: Monday, June 12, 2006 8:36 AM Subject: Re: [p2p-sip] What are we doing, question 2 It seems your primary goal is to claim that something does not work. The truth is that it works fine if you follow the RFCs, many vendors have implemented it, there are many end points deployed that use rport. I don't know what else to say. You are right that if you violate the RFCs then it does not work. On Jun 11, 2006, at 9:10 PM, Peter Pan wrote: I'm sorry that you never read carefully the problem raised by my interop partner and my messages so far, especially on the "unequal ip" precondition. If you did, we can save all these back and forth :) BTW, please see [pp]s inline. Peter ----- Original Message ----- From: Cullen Jennings To: Peter Pan Cc: p2p-sip at cs.columbia.edu Sent: Sunday, June 11, 2006 8:48 PM Subject: Re: [p2p-sip] What are we doing, question 2 If the device receives SIP on the same ports it sends from, it adds an rport and all of this is irrelevant. If it does not send from the same port it receives from - nothing you are proposing will work and it will break existing devices. [pp]: No, when rx and tx on different ports and UAC sets sent-by = public rx address (w/o rport), it will work. Just need STUN. The advice is very simple, make you device send and receive SIP from same UDP port and add an rport flag in the Via - then everything works fine. [pp]: Didn't you say "substantial amounts of equipment that sends and receives from different ports" below??? I'm worry about thoseequipments, not mine. My device tx/rx on the same port from day one. I always hate trouble, but my interop partner seems love trouble :-) This does not need STUN to work, it works fine with NATs, and it is backwards compatible with devices that don't send on same port they receive on. [pp]: How can RFC 3261/3581 be "backwards compatible" with these substantial amounts of equipments when they are behind NAT without STUN ??? I really doubt it without your further elaborations. Thanks!! On Jun 11, 2006, at 8:28 PM, Peter Pan wrote: OK, with tx and rx on different ports, let's take the following UAC as a specific example: It sends msg at private address 192.168.1.1:5060 which is NAT-ed to public addr 209.133.55.1:20006. It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to public addr 209.133.55.1:20007. (Remind you that, in the issue of debate, the ip in Via sent-by is NOT equal to that in UDP header) Now UAC sends a req via UDP, with Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) UDP src addr= 209.133.55.1:20006 According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. Does the address 209.133.55.1:5070 make any sense? No, apparently!! (Neither, if send-by = 192.168.1.1:5060) You could say that UAC should probe STUN beforehand and set Via sent-by to the public (rx) address 209.133.55.1:20007 and it will work. Yes, but that will NOT be the same problem as the debated one because of precondition in the reminder above, not to mention that RFC 3581 (or rport) would have been completely unnecessary if UA could always consult STUN beforehand to set sent-by to a public address. Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Sunday, June 11, 2006 5:11 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't think there is anything "incomplete" about this part of the > spec. I think it is pretty clear how it works and I explained why it > worked that way in previous email. The way you are proposing (if I > understand correctly, and I certainly may not) does not work with > substantial amounts of equipment that sends and receives from > different ports. > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > >> > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > >> > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > >>> interop partner insists). > >> > >> I think you interop partner is correct. > > > > Actually the partner raised the issue via some sort of stress test > > possibly > > for curiosity. Her UAC (likely a robot) cannot resend the request > > on no > > response. There seems nothing practically correct or incorrect. > > > > Unless pointers to convincing explanations about what the responded > > address > > "ipX:portY" may be could kindly show up, personally I will close > > the case as > > an incompleteness of current SIP related RFCs. (Never mind it, for > > SIP alone > > seems never designed to cover all NAT scenarios:) -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/bf4d20c6/attachment-0001.html From huang-ming.pan at comcast.net Mon Jun 12 11:49:09 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 08:49:09 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <000d01c68e32$d0f0f880$6400a8c0@comcast.net> <8b2769930606120819x60075564va2c19e99f3b43f56@mail.gmail.com> Message-ID: <003e01c68e37$be99e520$6400a8c0@comcast.net> Before moving the thread elsewhere, could anyone send me a simple call example or trace (copy-n-paste is ok) illustrating how current SIP RFCs are backward compatible with those substantial amounts of equipments without STUN? If none, it is ok. I'm going to close the thread anyway since somebody of distinquish fame seems impatient with me for unknown reason. Thanks. Peter ----- Original Message ----- From: "David A. Bryan" To: "Peter Pan" Cc: "Stefan Nitschke" ; Sent: Monday, June 12, 2006 8:19 AM Subject: Re: [p2p-sip] What are we doing, question 2 > This might be a good thread to move to the Columbia SIP implementors > mailing list. That is generally the place with the most experience on > interop/implemenation type questions. > > David > > On 6/12/06, Peter Pan wrote: > > > > > > Hi, Stefan. > > > > Thanks for the comment. > > > > Unfortunately, as you could see below, the client below is NOT supporting > > symmetric signaling; it uses asymmetric signaling. Cullen mentioned below > > that there are substantial amounts of such equipments that sends and > > receives from different ports. > > > > Do you or anyone know how RFC 3261/3581 and other SIP RFCs together can be > > "backwards compatible" with those Cullen-mentioned "substantial amounts of > > equipments that sends and receives from different ports" when they are > > behind (any kind of) NAT and without STUN? > > > > I will appreciate any kindly elaboration. > > > > Thanks. > > > > > > Peter > > > > ----- Original Message ----- > > From: "Stefan Nitschke" > > To: > > Sent: Monday, June 12, 2006 1:24 AM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > Hi Peter, > > > > > > from my understanding the client has to use: > > > > > > Via sent-by = 192.168.1.1:5070;rport > > > > > > This way it signals to the reciever that it does support symmetric > > signaling > > > and the receiver can use the rport and received parameters to send it > > > response to. > > > A missing "rport" has the meaning of non symmetric signaling. > > > > > > regards, > > > Stefan > > > > > > > > > >From: "Peter Pan" > > > >To: "Cullen Jennings" > > > >CC: p2p-sip at cs.columbia.edu > > > >Subject: Re: [p2p-sip] What are we doing, question 2 > > > >Date: Sun, 11 Jun 2006 20:28:24 -0700 > > > > > > > >OK, with tx and rx on different ports, let's take the following UAC as a > > > >specific example: > > > > > > > >It sends msg at private address 192.168.1.1:5060 which is NAT-ed to > > public > > > >addr 209.133.55.1:20006. > > > >It recvs msg at private address 192.168.1.1:5070 which is NAT-ed to > > public > > > >addr 209.133.55.1:20007. > > > > > > > >(Remind you that, in the issue of debate, the ip in Via sent-by is NOT > > > >equal to that in UDP header) > > > > > > > >Now UAC sends a req via UDP, with > > > > > > > > Via sent-by = 192.168.1.1:5070 (without ";rport", per your comment) > > > > UDP src addr= 209.133.55.1:20006 > > > > > > > >According to current SIP RFCs, UAS must respond to 209.133.55.1:5070. > > > > > > > >Does the address 209.133.55.1:5070 make any sense? No, apparently!! > > > > > > > >(Neither, if send-by = 192.168.1.1:5060) > > > > > > > >You could say that UAC should probe STUN beforehand and set Via sent-by > > to > > > >the public (rx) address 209.133.55.1:20007 and it will work. Yes, but > > that > > > >will NOT be the same problem as the debated one because of precondition > > in > > > >the reminder above, not to mention that RFC 3581 (or rport) would have > > been > > > >completely unnecessary if UA could always consult STUN beforehand to set > > > >sent-by to a public address. > > > > > > > >Peter > > > >----- Original Message ----- > > > >From: "Cullen Jennings" > > > >To: "Peter Pan" > > > >Cc: > > > >Sent: Sunday, June 11, 2006 5:11 PM > > > >Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > > > > > > > > > > > > > > I don't think there is anything "incomplete" about this part of the > > > > > spec. I think it is pretty clear how it works and I explained why it > > > > > worked that way in previous email. The way you are proposing (if I > > > > > understand correctly, and I certainly may not) does not work with > > > > > substantial amounts of equipment that sends and receives from > > > > > different ports. > > > > > > > > > > On Jun 11, 2006, at 10:07 AM, Peter Pan wrote: > > > > > > > > > > > > > > > > >> > > > > > >> On Jun 9, 2006, at 11:03 PM, Peter Pan wrote: > > > > > >> > > > > > >>> It is not clear in RFC 3581 whether or not UAS MAY "voluntarily" > > > > > >>> add ";rport=5555" to the Via; so I assume "MAY NOT" (which is my > > > > > >>> interop partner insists). > > > > > >> > > > > > >> I think you interop partner is correct. > > > > > > > > > > > > Actually the partner raised the issue via some sort of stress test > > > > > > possibly > > > > > > for curiosity. Her UAC (likely a robot) cannot resend the request > > > > > > on no > > > > > > response. There seems nothing practically correct or incorrect. > > > > > > > > > > > > Unless pointers to convincing explanations about what the responded > > > > > > address > > > > > > "ipX:portY" may be could kindly show up, personally I will close > > > > > > the case as > > > > > > an incompleteness of current SIP related RFCs. (Never mind it, for > > > > > > SIP alone > > > > > > seems never designed to cover all NAT scenarios:) > > > > > > > > > >_______________________________________________ > > > >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 > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > From kyara543 at yahoo.com Mon Jun 12 12:44:22 2006 From: kyara543 at yahoo.com (K.Yamamoto) Date: Mon, 12 Jun 2006 09:44:22 -0700 (PDT) Subject: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand terminology draft posted) In-Reply-To: <001601c68d75$cb68f060$6400a8c0@comcast.net> Message-ID: <20060612164422.84115.qmail@web38605.mail.mud.yahoo.com> INTERESTING EQUATIONS, PETER. A INTERESTING ARTICLE BY A SOFTWARE ARCHITECT WHO WAS AN 3G/IMS ADVOCATOR BUT NOW SOUNDS DELUDED: http://www.telephonydiscussion.com/index.php?name=UpDownload&req=getit&lid=12 HARD FOR PERSISTENCE AND GRAND PLANS TO GET WELL ALONG. I HOPE THAT P2PSIP TEAM CAN WIN A TURING AWARD SOON. (http://en.wikipedia.org/wiki/Turing_Award) K.Y. Peter Pan wrote: client : peer = coke : pepsi ??? imo, on = ua (once find itself restricted) sn = on + registrar + proxy + dht for "simple session" initiation (!= "simple" session initiation:), p2psip(on,sn) = sip(ua,proxy) p2psip(sn,sn) = sip(all) + dht minimally, on = aa + sip_ua + stunx_client + turn_client sn = aa + sip_full + stunx + turn + dht where, stunx=distributed stun (!= rfc3489) on - aa = toy sn - aa = joke simpler? Peter ----- Original Message ----- From: Marocco Enrico To: Dean Willis ; Matteo Peraldo Cc: p2p-sip at cs.columbia.edu Sent: Sunday, June 11, 2006 3:36 AM Subject: Re: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand terminology draft posted) Dean Willis wrote: >> This Peer is a node that acts as client and as peer. You can imagine >> that there are no nodes in the overlay that act only as peers, but >> maybe it is useful keeping the two roles separeted. >> > > I think I like this taxonomy. > > But here's a question: If a node that acts as both a "peer" and a > "client" is executing a GET operation, does it do so using the same > protocol that a node that only acts as a "client" would use? I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed by a client has to locally retrieve credentials for signing or encripting the record being inserted, while the PUT served and then performed by a peer has to check them for authorizing the operation. I look at them as two distinct operations, both syntactically and functionally. > This gets to the heart of whether the client protocol (from the > concepts draft) is a syntactic subset of the peer protocol from that > draft. > > Some people have proposed that the client protocol might be SIP > (perhaps REGISTER transactions) and that the peer protocol might be > something entirely different that also provides a mechanism for GET > and PUT. If we have this kind of relationship between the two > protocols, then I don't think the above taxonomy accurately describes > the model. With this kind of relationship the PUT operation performed by a node which was both a client and a peer would result in a REGISTER sent locally. Actually it doesn't look different from the case where the peer performs directly the PUT in place of the user agent. 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 -------------------------------------------------------------------- _______________________________________________ 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/653cd2c9/attachment.html From huang-ming.pan at comcast.net Mon Jun 12 13:03:51 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 10:03:51 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com><9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it><448D81B8.8060309@research.panasonic.com> <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> Message-ID: <009101c68e42$2de7a7a0$6400a8c0@comcast.net> Sorry. One more question, possibly not p2psip related, for your comment. Is RFC 3489 based on assumption that STUN server is at least "dual-homed". Thanks. Peter ----- Original Message ----- From: "David A. Bryan" To: "Eunsoo Shim" Cc: Sent: Monday, June 12, 2006 8:16 AM Subject: Re: [p2p-sip] More on peers and clients (WAS: Re: P2PSIPConceptsand terminology draft posted) > We do have lots of put/get type things as peers enter and leave and > need to move resources. I agree with the arguments you make if the two > protocols are different, but of course, that isn't decided yet. The > two *could* be different, or could be one and the same. If they are > one and the same, then of course the get/put are logically identical > between the two, if the protocols are different, then a peer should > probably use peer type operations rather than client type. > > Personally, I still think we can do this with one protocol, but at > some level, this debate is a bit orthogonal to the discussion of what > we want to do at the most fundamental level. I think we can agree that > we want to: > > Allow endpoints and other "edge" devices (clients, in the document) to get/put > Allow peers to get/put in some way, as well as other operations > > The purpose of the get/put is the same between them, to place and > retrieve information. In some designs, it is also the same protocol > wise, and in others it isn't. That will likely be decided as the > protocol design moves forward, I would think. > > David > > On 6/12/06, Eunsoo Shim wrote: > > Marocco Enrico wrote: > > > > > > > > Dean Willis wrote: > > > >> This Peer is a node that acts as client and as peer. You can imagine > > > >> that there are no nodes in the overlay that act only as peers, but > > > >> maybe it is useful keeping the two roles separeted. > > > >> > > > > > > > > I think I like this taxonomy. > > > > > > > > But here's a question: If a node that acts as both a "peer" and a > > > > "client" is executing a GET operation, does it do so using the same > > > > protocol that a node that only acts as a "client" would use? > > > > > > I'd say yes. Perhaps the PUT case is more explanatory: a PUT performed > > > by a client has to locally retrieve credentials for signing or > > > encripting the record being inserted, while the PUT served and then > > > performed by a peer has to check them for authorizing the > > > operation. I look at them as two distinct operations, both > > > syntactically and functionally. > > > > I'd say no. > > When a Client initiatiates GET/PUT, the message from Client is sent to a > > Peer (GET/PUT Request message of the Client Protocol). > > Then the Peer forwards the request (not the message) to other Peers > > (GET/PUT Request message of the Peer Protocol) according to their > > routing algorithm. > > > > If a Peer initiates GET/PUT, why should the Peer send a GET/PUT Request > > message of the Client Protocol to another Peer? That will cause just an > > unnecessary message check and/or conversion from a Client Protocol's > > GET/PUT Request message to a Peer Protocol's GET/PUT Request message. > > > > So when a Peer initiates GET/PUT, it can and should send just a Peer > > Protocol's GET/PUT Request message from the beginning. That is all > > necessary. > > > > > > > > > This gets to the heart of whether the client protocol (from the > > > > concepts draft) is a syntactic subset of the peer protocol from that > > > > draft. > > > > > > > > Some people have proposed that the client protocol might be SIP > > > > (perhaps REGISTER transactions) and that the peer protocol might be > > > > something entirely different that also provides a mechanism for GET > > > > and PUT. If we have this kind of relationship between the two > > > > protocols, then I don't think the above taxonomy accurately describes > > > > the model. > > > > > > With this kind of relationship the PUT operation performed by a node > > > which was both a client and a peer would result in a REGISTER sent > > > locally. Actually it doesn't look different from the case where the > > > peer performs directly the PUT in place of the user agent. > > > > Your assumption about the protocol is beyond the scope of the discussion. > > We should stick to the logically distinguished two protocols - the > > Client Protocol and the Peer Protocol - in this architectural discussion. > > > > Another note about Client and Peer. > > I think the reason Client is introduced is to accomodate devices with > > limited physical resources (eg. limited cpu power or battery) or in a > > limited environment (eg. private address). > > To put it differently, a participant becomes a Client because it is not > > capable or qualified to participate in the routing and storage service > > for other participants. So there was a suggestion that a Peer be called > > a Full Peer and a Client a Limited Peer. > > A participatnt that can be a Peer is certainly capable of what a Client > > does. Why would we define another type of a limited peer that cannot > > initiate GET/PUT? > > > > Thanks. > > > > Eunsoo > > _______________________________________________ > > 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 fluffy at cisco.com Mon Jun 12 13:10:35 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 10:10:35 -0700 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <009101c68e42$2de7a7a0$6400a8c0@comcast.net> References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com><9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it><448D81B8.8060309@research.panasonic.com> <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> <009101c68e42$2de7a7a0$6400a8c0@comcast.net> Message-ID: On Jun 12, 2006, at 10:03 AM, Peter Pan wrote: > Is RFC 3489 based on assumption that STUN server is at least "dual- > homed". no but it is based on the idea that the stun server has two IP address - it is recommended that these are both on the same interface. However this changes in the update to it - draft-ietf- behave-rfc3489bis-03 does not require two IP addresses. From huang-ming.pan at comcast.net Mon Jun 12 13:19:48 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 10:19:48 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com><9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it><448D81B8.8060309@research.panasonic.com> <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> <009101c68e42$2de7a7a0$6400a8c0@comcast.net> Message-ID: <009d01c68e44$687e0f10$6400a8c0@comcast.net> Is it possible to realize a STUN sever defined by draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP? Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Monday, June 12, 2006 10:10 AM Subject: Re: [p2p-sip] STUN (rfc3489) > > On Jun 12, 2006, at 10:03 AM, Peter Pan wrote: > > > Is RFC 3489 based on assumption that STUN server is at least "dual- > > homed". > > no but it is based on the idea that the stun server has two IP > address - it is recommended that these are both on the same > interface. However this changes in the update to it - draft-ietf- > behave-rfc3489bis-03 does not require two IP addresses. From huang-ming.pan at comcast.net Mon Jun 12 13:24:26 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 10:24:26 -0700 Subject: [p2p-sip] STUN (rfc3489) Message-ID: <00a901c68e45$0e145920$6400a8c0@comcast.net> Sorry. I should have asked: Is it possible to realize a STUN sever defined by draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can discover the NAT type before a STUN client? Peter ----- Original Message ----- From: "Peter Pan" To: "Cullen Jennings" Cc: Sent: Monday, June 12, 2006 10:19 AM Subject: Re: [p2p-sip] STUN (rfc3489) > Is it possible to realize a STUN sever defined by > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP? > > Peter > ----- Original Message ----- > From: "Cullen Jennings" > To: "Peter Pan" > Cc: > Sent: Monday, June 12, 2006 10:10 AM > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > On Jun 12, 2006, at 10:03 AM, Peter Pan wrote: > > > > > Is RFC 3489 based on assumption that STUN server is at least "dual- > > > homed". > > > > no but it is based on the idea that the stun server has two IP > > address - it is recommended that these are both on the same > > interface. However this changes in the update to it - draft-ietf- > > behave-rfc3489bis-03 does not require two IP addresses. > From fluffy at cisco.com Mon Jun 12 13:27:43 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 10:27:43 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <003501c68e37$70bf2b80$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> Message-ID: <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> On Jun 12, 2006, at 8:46 AM, Peter Pan wrote: > What I argue is that nothing in current SIP RFCs seems work with > your mentioned "substantial amounts of such equipments that sends > and receives from different ports" WITHOUT STUN. > I think our miscommunication here may be over where these devices work. UAs that do not do rport will not work when they are behind NATs but the stuff that does this was not designed to be deployed behind NATs. From huang-ming.pan at comcast.net Mon Jun 12 13:29:51 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 10:29:51 -0700 Subject: [p2p-sip] STUN (rfc3489) Message-ID: <00c401c68e45$cfe50c20$6400a8c0@comcast.net> I found this in draft-ietf-behave-rfc3489bis-03 16. Changes Since RFC 3489 This specification updates RFC3489 [13]. This specification differs from RFC3489 in the following ways: o Removed the usage of STUN for NAT type detection and binding lifetime discovery. Here comes another question: Does P2PSIP need to know NAT type of a node before the node is classified as a peer (SN) or client (ON)? Peter ----- Original Message ----- From: "Peter Pan" To: "Cullen Jennings" Cc: Sent: Monday, June 12, 2006 10:24 AM Subject: Re: [p2p-sip] STUN (rfc3489) > Sorry. I should have asked: > > Is it possible to realize a STUN sever defined by > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can discover > the NAT type before a STUN client? > > Peter > ----- Original Message ----- > From: "Peter Pan" > To: "Cullen Jennings" > Cc: > Sent: Monday, June 12, 2006 10:19 AM > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > Is it possible to realize a STUN sever defined by > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP? > > > > Peter > > ----- Original Message ----- > > From: "Cullen Jennings" > > To: "Peter Pan" > > Cc: > > Sent: Monday, June 12, 2006 10:10 AM > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > > > > On Jun 12, 2006, at 10:03 AM, Peter Pan wrote: > > > > > > > Is RFC 3489 based on assumption that STUN server is at least "dual- > > > > homed". > > > > > > no but it is based on the idea that the stun server has two IP > > > address - it is recommended that these are both on the same > > > interface. However this changes in the update to it - draft-ietf- > > > behave-rfc3489bis-03 does not require two IP addresses. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/05fc7939/attachment.html From huang-ming.pan at comcast.net Mon Jun 12 13:35:27 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 10:35:27 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> Message-ID: <00ca01c68e46$9815ac90$6400a8c0@comcast.net> I see. But my interop partner insists that: * his device will NOT use rport * his device will NOT tx and rx on the same address * his device MAY or MAY NOT sit behind NAT I guess that his "device" is kind of B2BUA-based call manager sitting behind NAT. Peter ----- Original Message ----- From: "Cullen Jennings" To: "Peter Pan" Cc: Sent: Monday, June 12, 2006 10:27 AM Subject: Re: [p2p-sip] What are we doing, question 2 > > On Jun 12, 2006, at 8:46 AM, Peter Pan wrote: > > > What I argue is that nothing in current SIP RFCs seems work with > > your mentioned "substantial amounts of such equipments that sends > > and receives from different ports" WITHOUT STUN. > > > > I think our miscommunication here may be over where these devices > work. UAs that do not do rport will not work when they are behind > NATs but the stuff that does this was not designed to be deployed > behind NATs. From lowekamp at cs.wm.edu Mon Jun 12 15:33:13 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Mon, 12 Jun 2006 15:33:13 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <00c401c68e45$cfe50c20$6400a8c0@comcast.net> References: <00c401c68e45$cfe50c20$6400a8c0@comcast.net> Message-ID: My understanding is that part of 3489 was removed because many NATs are inconsistent---if you make decisions based on a one-time NAT type discovery as in 3489, that information might not be valid for other addresses or for some time in the future. I suspect the right way to decide on node classification is to try to establish connections with a number of peers. You can observe whether you are needing to perform port opening (behind a filter) or relaying (behind a very ugly NAT) and make your decision based on that. Of course, it might still change, but at least you've observed the property you want to observe with the nodes you care about, rather than basing an entire decision on an interaction with a single STUN server. Later on, if the node is relaying too much, that decision might need to be revisited. If we need to solve the classification problem with 3489bis, there are solutions. Bruce On 6/12/06, Peter Pan wrote: > > > I found this in draft-ietf-behave-rfc3489bis-03 > > > 16. Changes Since RFC 3489 > > This specification updates RFC3489 [13]. This specification differs > from RFC3489 in the following ways: > > o Removed the usage of STUN for NAT type detection and binding > lifetime discovery. > > > Here comes another question: > > Does P2PSIP need to know NAT type of a node before the node is classified as > a peer (SN) or client (ON)? > > > Peter > > ----- Original Message ----- > From: "Peter Pan" > To: "Cullen Jennings" > Cc: > > Sent: Monday, June 12, 2006 10:24 AM > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > Sorry. I should have asked: > > > > Is it possible to realize a STUN sever defined by > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can > discover > > the NAT type before a STUN client? > > > > Peter > > ----- Original Message ----- > > From: "Peter Pan" > > To: "Cullen Jennings" > > Cc: > > Sent: Monday, June 12, 2006 10:19 AM > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > Is it possible to realize a STUN sever defined by > > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP? > > > > > > Peter > > > ----- Original Message ----- > > > From: "Cullen Jennings" > > > To: "Peter Pan" > > > Cc: > > > Sent: Monday, June 12, 2006 10:10 AM > > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > > > > > > > > On Jun 12, 2006, at 10:03 AM, Peter Pan wrote: > > > > > > > > > Is RFC 3489 based on assumption that STUN server is at least "dual- > > > > > homed". > > > > > > > > no but it is based on the idea that the stun server has two IP > > > > address - it is recommended that these are both on the same > > > > interface. However this changes in the update to it - draft-ietf- > > > > behave-rfc3489bis-03 does not require two IP addresses. > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From huang-ming.pan at comcast.net Mon Jun 12 16:19:28 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 13:19:28 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00c401c68e45$cfe50c20$6400a8c0@comcast.net> Message-ID: <014701c68e5d$81f508e0$6400a8c0@comcast.net> Sounds quite complicated. By "try to establish connections with a number of 'peers' ", do you mean that a P2PSIP node can never determine its exact NAT type and must keep (by continuous attempts) hooking to DHT overlay without "precise" knowledge of its NAT type? If yes, would that inject series of avalanches of false (unreachable) node information into overlay? Peter ----- Original Message ----- From: "Bruce Lowekamp" To: "Peter Pan" Cc: "Cullen Jennings" ; Sent: Monday, June 12, 2006 12:33 PM Subject: Re: [p2p-sip] STUN (rfc3489) > My understanding is that part of 3489 was removed because many NATs > are inconsistent---if you make decisions based on a one-time NAT type > discovery as in 3489, that information might not be valid for other > addresses or for some time in the future. > > I suspect the right way to decide on node classification is to try to > establish connections with a number of peers. You can observe whether > you are needing to perform port opening (behind a filter) or relaying > (behind a very ugly NAT) and make your decision based on that. Of > course, it might still change, but at least you've observed the > property you want to observe with the nodes you care about, rather > than basing an entire decision on an interaction with a single STUN > server. Later on, if the node is relaying too much, that decision > might need to be revisited. > > If we need to solve the classification problem with 3489bis, there are > solutions. > > Bruce > > On 6/12/06, Peter Pan wrote: > > > > > > I found this in draft-ietf-behave-rfc3489bis-03 > > > > > > 16. Changes Since RFC 3489 > > > > This specification updates RFC3489 [13]. This specification differs > > from RFC3489 in the following ways: > > > > o Removed the usage of STUN for NAT type detection and binding > > lifetime discovery. > > > > > > Here comes another question: > > > > Does P2PSIP need to know NAT type of a node before the node is classified as > > a peer (SN) or client (ON)? > > > > > > Peter > > > > ----- Original Message ----- > > From: "Peter Pan" > > To: "Cullen Jennings" > > Cc: > > > > Sent: Monday, June 12, 2006 10:24 AM > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > Sorry. I should have asked: > > > > > > Is it possible to realize a STUN sever defined by > > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can > > discover > > > the NAT type before a STUN client? > > > > > > Peter > > > ----- Original Message ----- > > > From: "Peter Pan" > > > To: "Cullen Jennings" > > > Cc: > > > Sent: Monday, June 12, 2006 10:19 AM > > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > > > > Is it possible to realize a STUN sever defined by > > > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP? > > > > > > > > Peter > > > > ----- Original Message ----- > > > > From: "Cullen Jennings" > > > > To: "Peter Pan" > > > > Cc: > > > > Sent: Monday, June 12, 2006 10:10 AM > > > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > > > > > > > > > > > > On Jun 12, 2006, at 10:03 AM, Peter Pan wrote: > > > > > > > > > > > Is RFC 3489 based on assumption that STUN server is at least "dual- > > > > > > homed". > > > > > > > > > > no but it is based on the idea that the stun server has two IP > > > > > address - it is recommended that these are both on the same > > > > > interface. However this changes in the update to it - draft-ietf- > > > > > behave-rfc3489bis-03 does not require two IP addresses. > > > > > > > > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > From dean.willis at softarmor.com Mon Jun 12 16:23:31 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 12 Jun 2006 15:23:31 -0500 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <00ca01c68e46$9815ac90$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> Message-ID: On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: > I see. > > But my interop partner insists that: > * his device will NOT use rport > * his device will NOT tx and rx on the same address > * his device MAY or MAY NOT sit behind NAT > > I guess that his "device" is kind of B2BUA-based call manager > sitting behind > NAT. > You appear to have a partner, but no interop. If you were married, I would recommend a therapist. His stuff is broken. It's hard to interop with broken stuff, and I believe it can not be achieved in a standard manner in this case. You will probably have to do many tricky things to get it to even sort of work. While we wish you luck, this doesn't apply to the develop of a standard solution, and this isn't the right place to talk about tricky hacks for working with broken stuff. We're far more concerned with hacky tricks for unbreaking our own stuff. -- Dean From fluffy at cisco.com Mon Jun 12 16:31:43 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 13:31:43 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <00ca01c68e46$9815ac90$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> Message-ID: On Jun 12, 2006, at 10:35 AM, Peter Pan wrote: > But my interop partner insists that: > * his device will NOT use rport > * his device will NOT tx and rx on the same address > * his device MAY or MAY NOT sit behind NAT Your interop partners device will probably not work when it is behind a NAT. If you add a rport on to the via that a message came from, your device will be in violation of the rport specification, your devices will not work with other complaint devices, and most importantly, it *still* will not work with your interop partners devices because that device is sending from a different port than it receives on. From huang-ming.pan at comcast.net Mon Jun 12 16:32:25 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 13:32:25 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> Message-ID: <014f01c68e5f$515a2f60$6400a8c0@comcast.net> Wondering how a decent human being in any SIP working group could judge other people this way? Let's do this. If I provide you with the call trace and msgs from my interop partner under non-disclosure agreement, would you be responsible for your words and express some apology? Peter ----- Original Message ----- From: "Dean Willis" To: "Peter Pan" Cc: "Cullen Jennings" ; Sent: Monday, June 12, 2006 1:23 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: > > > I see. > > > > But my interop partner insists that: > > * his device will NOT use rport > > * his device will NOT tx and rx on the same address > > * his device MAY or MAY NOT sit behind NAT > > > > I guess that his "device" is kind of B2BUA-based call manager > > sitting behind > > NAT. > > > > You appear to have a partner, but no interop. If you were married, I > would recommend a therapist. > > His stuff is broken. It's hard to interop with broken stuff, and I > believe it can not be achieved in a standard manner in this case. You > will probably have to do many tricky things to get it to even sort of > work. While we wish you luck, this doesn't apply to the develop of a > standard solution, and this isn't the right place to talk about > tricky hacks for working with broken stuff. > > We're far more concerned with hacky tricks for unbreaking our own stuff. > > -- > Dean > > > From lowekamp at cs.wm.edu Mon Jun 12 16:32:14 2006 From: lowekamp at cs.wm.edu (Bruce Lowekamp) Date: Mon, 12 Jun 2006 16:32:14 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <014701c68e5d$81f508e0$6400a8c0@comcast.net> References: <00c401c68e45$cfe50c20$6400a8c0@comcast.net> <014701c68e5d$81f508e0$6400a8c0@comcast.net> Message-ID: Yeah, I think it is complicated. I think it's a true statement, though, that a node can never be sure it knows its exact NAT type. Of course, 99% of the time the situation probably won't be that complicated and determining the exact situation is fairly simple. As long as you have relays, though, a node is never unreachable. It's just too much of an effort to get to it for it to be practical to use. Such a node, if it accidentally gets in on the belief that it is easier to reach, can be gracefully taken out of the overlay without causing any errors. Fortunately, a lot of the use-cases don't require this complex of a setup, either. Bruce On 6/12/06, Peter Pan wrote: > Sounds quite complicated. > > By "try to establish connections with a number of 'peers' ", do you mean > that a P2PSIP node can never determine its exact NAT type and must keep (by > continuous attempts) hooking to DHT overlay without "precise" knowledge of > its NAT type? If yes, would that inject series of avalanches of false > (unreachable) node information into overlay? > > Peter > ----- Original Message ----- > From: "Bruce Lowekamp" > To: "Peter Pan" > Cc: "Cullen Jennings" ; > Sent: Monday, June 12, 2006 12:33 PM > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > My understanding is that part of 3489 was removed because many NATs > > are inconsistent---if you make decisions based on a one-time NAT type > > discovery as in 3489, that information might not be valid for other > > addresses or for some time in the future. > > > > I suspect the right way to decide on node classification is to try to > > establish connections with a number of peers. You can observe whether > > you are needing to perform port opening (behind a filter) or relaying > > (behind a very ugly NAT) and make your decision based on that. Of > > course, it might still change, but at least you've observed the > > property you want to observe with the nodes you care about, rather > > than basing an entire decision on an interaction with a single STUN > > server. Later on, if the node is relaying too much, that decision > > might need to be revisited. > > > > If we need to solve the classification problem with 3489bis, there are > > solutions. > > > > Bruce > > > > On 6/12/06, Peter Pan wrote: > > > > > > > > > I found this in draft-ietf-behave-rfc3489bis-03 > > > > > > > > > 16. Changes Since RFC 3489 > > > > > > This specification updates RFC3489 [13]. This specification differs > > > from RFC3489 in the following ways: > > > > > > o Removed the usage of STUN for NAT type detection and binding > > > lifetime discovery. > > > > > > > > > Here comes another question: > > > > > > Does P2PSIP need to know NAT type of a node before the node is > classified as > > > a peer (SN) or client (ON)? > > > > > > From fluffy at cisco.com Mon Jun 12 16:32:58 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 13:32:58 -0700 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> Message-ID: On Jun 12, 2006, at 1:23 PM, Dean Willis wrote: > You appear to have a partner, but no interop. If you were married, > I would recommend a therapist. Well that does some it up, I really think we should move this to sip- implementors if we want to continue. From fluffy at cisco.com Mon Jun 12 16:36:53 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 13:36:53 -0700 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <009d01c68e44$687e0f10$6400a8c0@comcast.net> References: <7F057670-D2D9-4878-8D02-E23964197516@softarmor.com><9E577E61D0108D4F8CD482029B613F5C90E0AF@PTPEVS108BA020.idc.cww.telecomitalia.it><448D81B8.8060309@research.panasonic.com> <8b2769930606120816y20ba08ecxaddeb472d0c527fc@mail.gmail.com> <009101c68e42$2de7a7a0$6400a8c0@comcast.net> <009d01c68e44$687e0f10$6400a8c0@comcast.net> Message-ID: <6200BAC3-AA3F-4001-B358-7BDFFA2708C5@cisco.com> On Jun 12, 2006, at 10:19 AM, Peter Pan wrote: > Is it possible to realize a STUN sever defined by > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP? yes. From fluffy at cisco.com Mon Jun 12 16:38:08 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 12 Jun 2006 13:38:08 -0700 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <00a901c68e45$0e145920$6400a8c0@comcast.net> References: <00a901c68e45$0e145920$6400a8c0@comcast.net> Message-ID: <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> On Jun 12, 2006, at 10:24 AM, Peter Pan wrote: > Is it possible to realize a STUN sever defined by > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can > discover > the NAT type before a STUN client? I have no idea what you mean by NAT type but if what you mean is the classification in RFC 3489, then NO. If what you mean is enough to detect connectivity such as used by ICE, then YES. From huang-ming.pan at comcast.net Mon Jun 12 16:44:06 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 13:44:06 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> Message-ID: <017701c68e60$f5ccc480$6400a8c0@comcast.net> > > On Jun 12, 2006, at 10:35 AM, Peter Pan wrote: > > > But my interop partner insists that: > > * his device will NOT use rport > > * his device will NOT tx and rx on the same address > > * his device MAY or MAY NOT sit behind NAT > > Your interop partners device will probably not work when it is behind > a NAT. this is what i've been looking for since i issued the question. based on "authoritative" knowledge from sip gurus here, i can turn to the partner and ask that he should do something on his side to correct the interoperability problem. > If you add a rport on to the via that a message came from, > your device will be in violation of the rport specification, your > devices will not work with other complaint devices, and most > importantly, it *still* will not work with your interop partners > devices because that device is sending from a different port than it > receives on. UAS adding rport or not seems not a key point here. the key point is on UAC side, as you said. From huang-ming.pan at comcast.net Mon Jun 12 16:51:04 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 13:51:04 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> Message-ID: <018d01c68e61$ebe2d080$6400a8c0@comcast.net> > On Jun 12, 2006, at 1:23 PM, Dean Willis wrote: > > > You appear to have a partner, but no interop. If you were married, > > I would recommend a therapist. > > Well that does some it up, I really think we should move this to sip- > implementors if we want to continue. well, that does some it up for outside world to see thru people here. let's close this sub thread !! From huang-ming.pan at comcast.net Mon Jun 12 17:10:20 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 14:10:20 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00c401c68e45$cfe50c20$6400a8c0@comcast.net> <014701c68e5d$81f508e0$6400a8c0@comcast.net> Message-ID: <01c301c68e64$9cc926e0$6400a8c0@comcast.net> Well, it sounds now like a tradeoff between a simple protocol (without the complexity) for 99% of real-world nodes and a complex protocol that takes the remaining 1% "rare nodes" into account. Peter ----- Original Message ----- From: "Bruce Lowekamp" To: "Peter Pan" Cc: "Cullen Jennings" ; Sent: Monday, June 12, 2006 1:32 PM Subject: Re: [p2p-sip] STUN (rfc3489) > Yeah, I think it is complicated. I think it's a true statement, > though, that a node can never be sure it knows its exact NAT type. Of > course, 99% of the time the situation probably won't be that > complicated and determining the exact situation is fairly simple. > > As long as you have relays, though, a node is never unreachable. It's > just too much of an effort to get to it for it to be practical to use. > Such a node, if it accidentally gets in on the belief that it is > easier to reach, can be gracefully taken out of the overlay without > causing any errors. > > Fortunately, a lot of the use-cases don't require this complex of a > setup, either. > > Bruce > > > On 6/12/06, Peter Pan wrote: > > Sounds quite complicated. > > > > By "try to establish connections with a number of 'peers' ", do you mean > > that a P2PSIP node can never determine its exact NAT type and must keep (by > > continuous attempts) hooking to DHT overlay without "precise" knowledge of > > its NAT type? If yes, would that inject series of avalanches of false > > (unreachable) node information into overlay? > > > > Peter > > ----- Original Message ----- > > From: "Bruce Lowekamp" > > To: "Peter Pan" > > Cc: "Cullen Jennings" ; > > Sent: Monday, June 12, 2006 12:33 PM > > Subject: Re: [p2p-sip] STUN (rfc3489) > > > > > > > My understanding is that part of 3489 was removed because many NATs > > > are inconsistent---if you make decisions based on a one-time NAT type > > > discovery as in 3489, that information might not be valid for other > > > addresses or for some time in the future. > > > > > > I suspect the right way to decide on node classification is to try to > > > establish connections with a number of peers. You can observe whether > > > you are needing to perform port opening (behind a filter) or relaying > > > (behind a very ugly NAT) and make your decision based on that. Of > > > course, it might still change, but at least you've observed the > > > property you want to observe with the nodes you care about, rather > > > than basing an entire decision on an interaction with a single STUN > > > server. Later on, if the node is relaying too much, that decision > > > might need to be revisited. > > > > > > If we need to solve the classification problem with 3489bis, there are > > > solutions. > > > > > > Bruce > > > > > > On 6/12/06, Peter Pan wrote: > > > > > > > > > > > > I found this in draft-ietf-behave-rfc3489bis-03 > > > > > > > > > > > > 16. Changes Since RFC 3489 > > > > > > > > This specification updates RFC3489 [13]. This specification differs > > > > from RFC3489 in the following ways: > > > > > > > > o Removed the usage of STUN for NAT type detection and binding > > > > lifetime discovery. > > > > > > > > > > > > Here comes another question: > > > > > > > > Does P2PSIP need to know NAT type of a node before the node is > > classified as > > > > a peer (SN) or client (ON)? > > > > > > > > From huang-ming.pan at comcast.net Mon Jun 12 18:13:45 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 15:13:45 -0700 Subject: [p2p-sip] STUN (rfc3489) References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> Message-ID: <01ef01c68e6d$78e46010$6400a8c0@comcast.net> > On Jun 12, 2006, at 10:24 AM, Peter Pan wrote: > > > Is it possible to realize a STUN sever defined by > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can > > discover > > the NAT type before a STUN client? > > I have no idea what you mean by NAT type but if what you mean is the > classification in RFC 3489, then NO. If what you mean is enough to > detect connectivity such as used by ICE, then YES. By NAT type I meant those terms such as "full-cone", "ip-restricted", "port-restricted" and "symmetric" that seem widely used in voip industry. (http://www.voip-info.org/wiki-STUN, or http://en.wikipedia.org/wiki/Symmetric_NAT) Never mind it. Sounds like P2PSIP no more needs that info. From dean.willis at softarmor.com Mon Jun 12 19:18:30 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 12 Jun 2006 18:18:30 -0500 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <014f01c68e5f$515a2f60$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> <014f01c68e5f$515a2f60$6400a8c0@comcast.net> Message-ID: <85149912-1A8B-459A-A8B6-D3BD9812D1C2@softarmor.com> I don't believe I understand the words you have done me the honor of addressing to me. Would you care to make them more clear? -- Dean Willis On Jun 12, 2006, at 3:32 PM, Peter Pan wrote: > Wondering how a decent human being in any SIP working group could > judge > other people this way? > > Let's do this. If I provide you with the call trace and msgs from > my interop > partner under non-disclosure agreement, would you be responsible > for your > words and express some apology? > > Peter > ----- Original Message ----- > From: "Dean Willis" > To: "Peter Pan" > Cc: "Cullen Jennings" ; > Sent: Monday, June 12, 2006 1:23 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > >> >> On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: >> >>> I see. >>> >>> But my interop partner insists that: >>> * his device will NOT use rport >>> * his device will NOT tx and rx on the same address >>> * his device MAY or MAY NOT sit behind NAT >>> >>> I guess that his "device" is kind of B2BUA-based call manager >>> sitting behind >>> NAT. >>> >> >> You appear to have a partner, but no interop. If you were married, I >> would recommend a therapist. >> >> His stuff is broken. It's hard to interop with broken stuff, and I >> believe it can not be achieved in a standard manner in this case. You >> will probably have to do many tricky things to get it to even sort of >> work. While we wish you luck, this doesn't apply to the develop of a >> standard solution, and this isn't the right place to talk about >> tricky hacks for working with broken stuff. >> >> We're far more concerned with hacky tricks for unbreaking our own >> stuff. >> >> -- >> Dean >> >> >> > From huang-ming.pan at comcast.net Mon Jun 12 19:34:16 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 16:34:16 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> <014f01c68e5f$515a2f60$6400a8c0@comcast.net> <85149912-1A8B-459A-A8B6-D3BD9812D1C2@softarmor.com> Message-ID: <021f01c68e78$b85f7080$6400a8c0@comcast.net> This sub thread has closed. Please take the "honor" and visit the therapist you would recommend. ----- Original Message ----- From: "Dean Willis" To: "Peter Pan" Cc: "Cullen Jennings" ; Sent: Monday, June 12, 2006 4:18 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't believe I understand the words you have done me the honor of > addressing to me. Would you care to make them more clear? > > -- > Dean Willis > > On Jun 12, 2006, at 3:32 PM, Peter Pan wrote: > > > Wondering how a decent human being in any SIP working group could > > judge > > other people this way? > > > > Let's do this. If I provide you with the call trace and msgs from > > my interop > > partner under non-disclosure agreement, would you be responsible > > for your > > words and express some apology? > > > > Peter > > ----- Original Message ----- > > From: "Dean Willis" > > To: "Peter Pan" > > Cc: "Cullen Jennings" ; > > Sent: Monday, June 12, 2006 1:23 PM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >> > >> On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: > >> > >>> I see. > >>> > >>> But my interop partner insists that: > >>> * his device will NOT use rport > >>> * his device will NOT tx and rx on the same address > >>> * his device MAY or MAY NOT sit behind NAT > >>> > >>> I guess that his "device" is kind of B2BUA-based call manager > >>> sitting behind > >>> NAT. > >>> > >> > >> You appear to have a partner, but no interop. If you were married, I > >> would recommend a therapist. > >> > >> His stuff is broken. It's hard to interop with broken stuff, and I > >> believe it can not be achieved in a standard manner in this case. You > >> will probably have to do many tricky things to get it to even sort of > >> work. While we wish you luck, this doesn't apply to the develop of a > >> standard solution, and this isn't the right place to talk about > >> tricky hacks for working with broken stuff. > >> > >> We're far more concerned with hacky tricks for unbreaking our own > >> stuff. > >> > >> -- > >> Dean > >> > >> > >> > > > From kyara543 at yahoo.com Mon Jun 12 20:41:37 2006 From: kyara543 at yahoo.com (K.Yamamoto) Date: Mon, 12 Jun 2006 17:41:37 -0700 (PDT) Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <021f01c68e78$b85f7080$6400a8c0@comcast.net> Message-ID: <20060613004137.77177.qmail@web38611.mail.mud.yahoo.com> THERAPIST IS USELESS TO YAKUZA WHO OCCUPY TOILET AND CAN NOT POO. YOU KNOW WHAT RFC MEAN? REQUEST FOR "CONSENT" YOU NOT CONSENT? WATCH STING!! KY Peter Pan wrote: This sub thread has closed. Please take the "honor" and visit the therapist you would recommend. ----- Original Message ----- From: "Dean Willis" To: "Peter Pan" Cc: "Cullen Jennings" ; Sent: Monday, June 12, 2006 4:18 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't believe I understand the words you have done me the honor of > addressing to me. Would you care to make them more clear? > > -- > Dean Willis > > On Jun 12, 2006, at 3:32 PM, Peter Pan wrote: > > > Wondering how a decent human being in any SIP working group could > > judge > > other people this way? > > > > Let's do this. If I provide you with the call trace and msgs from > > my interop > > partner under non-disclosure agreement, would you be responsible > > for your > > words and express some apology? > > > > Peter > > ----- Original Message ----- > > From: "Dean Willis" > > To: "Peter Pan" > > Cc: "Cullen Jennings" ; > > Sent: Monday, June 12, 2006 1:23 PM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >> > >> On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: > >> > >>> I see. > >>> > >>> But my interop partner insists that: > >>> * his device will NOT use rport > >>> * his device will NOT tx and rx on the same address > >>> * his device MAY or MAY NOT sit behind NAT > >>> > >>> I guess that his "device" is kind of B2BUA-based call manager > >>> sitting behind > >>> NAT. > >>> > >> > >> You appear to have a partner, but no interop. If you were married, I > >> would recommend a therapist. > >> > >> His stuff is broken. It's hard to interop with broken stuff, and I > >> believe it can not be achieved in a standard manner in this case. You > >> will probably have to do many tricky things to get it to even sort of > >> work. While we wish you luck, this doesn't apply to the develop of a > >> standard solution, and this isn't the right place to talk about > >> tricky hacks for working with broken stuff. > >> > >> We're far more concerned with hacky tricks for unbreaking our own > >> stuff. > >> > >> -- > >> Dean > >> > >> > >> > > > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060612/52ddab8a/attachment-0001.html From huang-ming.pan at comcast.net Mon Jun 12 21:07:22 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 18:07:22 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <20060613004137.77177.qmail@web38611.mail.mud.yahoo.com> Message-ID: <025201c68e85$ba7c9840$6400a8c0@comcast.net> ORZ... ----- Original Message ----- From: K.Yamamoto To: Peter Pan ; Dean Willis Cc: p2p-sip at cs.columbia.edu Sent: Monday, June 12, 2006 5:41 PM Subject: Re: [p2p-sip] What are we doing, question 2 THERAPIST IS USELESS TO YAKUZA WHO OCCUPY TOILET AND CAN NOT POO. YOU KNOW WHAT RFC MEAN? REQUEST FOR "CONSENT" YOU NOT CONSENT? WATCH STING!! KY Peter Pan wrote: This sub thread has closed. Please take the "honor" and visit the therapist you would recommend. ----- Original Message ----- From: "Dean Willis" To: "Peter Pan" Cc: "Cullen Jennings" ; Sent: Monday, June 12, 2006 4:18 PM Subject: Re: [p2p-sip] What are we doing, question 2 > > I don't believe I understand the words you have done me the honor of > addressing to me. Would you care to make them more clear? > > -- > Dean Willis > > On Jun 12, 2006, at 3:32 PM, Peter Pan wrote: > > > Wondering how a decent human being in any SIP working group could > > judge > > other people this way? > > > > Let's do this. If I provide you with the call trace and msgs from > > my interop > > partner under non-disclosure agreement, would you be responsible > > for your > > words and express some apology? > > > > Peter > > ----- Original Message ----- > > From: "Dean Willis" > > To: "Peter Pan" > > Cc: "Cullen Jennings" ; > > Sent: Monday, June 12, 2006 1:23 PM > > Subject: Re: [p2p-sip] What are we doing, question 2 > > > > > >> > >> On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: > >> > >>> I see. > >>> > >>> But my interop partner insists that: > >>> * his device will NOT use rport > >>> * his device will NOT tx and rx on the same address > >>> * his device MAY or MAY NOT sit behind NAT > >>> > >>> I guess that his "device" is kind of B2BUA-based call manager > >>> sitting behind > >>> NAT. > >>> > >> > >> You appear to have a partner, but no interop. If you were married, I > >> would recommend a therapist. > >> > >> His stuff is broken. It's hard to interop with broken stuff, and I > >> believe it can not be achieved in a standard manner in this case. You > >> will probably have to do many tricky things to get it to even sort of > >> work. While we wish you luck, this doesn't apply to the develop of a > >> standard solution, and this isn't the right place to talk about > >> tricky hacks for working with broken stuff. > >> > >> We're far more concerned with hacky tricks for unbreaking our own > >> stuff. > >> > >> -- > >> Dean > >> > >> > >> > > > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From dean.willis at softarmor.com Mon Jun 12 21:15:32 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 12 Jun 2006 20:15:32 -0500 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <021f01c68e78$b85f7080$6400a8c0@comcast.net> References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> <014f01c68e5f$515a2f60$6400a8c0@comcast.net> <85149912-1A8B-459A-A8B6-D3BD9812D1C2@softarmor.com> <021f01c68e78$b85f7080$6400a8c0@comcast.net> Message-ID: It is sometimes difficult to ascertain the intent of a communicator on a mailing list, but I have I have thought many of your messages on the p2p-sip list to be aggressive, disruptive, offensive, and quite possibly abusive in tone. This may well not have been your intent, and if I misunderstood, I apologize. I tried to lighten the tone a bit by applying humor, which you seem to have reacted to in a hostile fashion indicating that perhaps I was unclear. If I was unclear, then I also apologize for that, and I'd like to apologize to the larger community for having aggravated the situation. If on the other hand your intent is to be offensive, we don't have to put up with it. I would like to remind you that that the IETF community does have a variety of procedures for dealing with disruptive individuals. The foremost of these is to simply ignore the disruptive individual, but the formal procedures do allow for the removal of posting rights and the application of even more stringent sanctions. I certainly hope things can be worked out without having to resort to those sorts of measures. Thank you for your consideration. That said, I'd like to ask the list participants to honor your wishes and leave the thread closed, and let's all get back to work at coming up with a few more agreeable points of consensus. -- Dean Willis On Jun 12, 2006, at 6:34 PM, Peter Pan wrote: > > This sub thread has closed. Please take the "honor" and visit the > therapist > you would recommend. > > ----- Original Message ----- > From: "Dean Willis" > To: "Peter Pan" > Cc: "Cullen Jennings" ; > Sent: Monday, June 12, 2006 4:18 PM > Subject: Re: [p2p-sip] What are we doing, question 2 > > >> >> I don't believe I understand the words you have done me the honor of >> addressing to me. Would you care to make them more clear? >> >> -- >> Dean Willis >> >> On Jun 12, 2006, at 3:32 PM, Peter Pan wrote: >> >>> Wondering how a decent human being in any SIP working group could >>> judge >>> other people this way? >>> >>> Let's do this. If I provide you with the call trace and msgs from >>> my interop >>> partner under non-disclosure agreement, would you be responsible >>> for your >>> words and express some apology? >>> >>> Peter >>> ----- Original Message ----- >>> From: "Dean Willis" >>> To: "Peter Pan" >>> Cc: "Cullen Jennings" ; >>> Sent: Monday, June 12, 2006 1:23 PM >>> Subject: Re: [p2p-sip] What are we doing, question 2 >>> >>> >>>> >>>> On Jun 12, 2006, at 12:35 PM, Peter Pan wrote: >>>> >>>>> I see. >>>>> >>>>> But my interop partner insists that: >>>>> * his device will NOT use rport >>>>> * his device will NOT tx and rx on the same address >>>>> * his device MAY or MAY NOT sit behind NAT >>>>> >>>>> I guess that his "device" is kind of B2BUA-based call manager >>>>> sitting behind >>>>> NAT. >>>>> >>>> >>>> You appear to have a partner, but no interop. If you were >>>> married, I >>>> would recommend a therapist. >>>> >>>> His stuff is broken. It's hard to interop with broken stuff, and I >>>> believe it can not be achieved in a standard manner in this >>>> case. You >>>> will probably have to do many tricky things to get it to even >>>> sort of >>>> work. While we wish you luck, this doesn't apply to the develop >>>> of a >>>> standard solution, and this isn't the right place to talk about >>>> tricky hacks for working with broken stuff. >>>> >>>> We're far more concerned with hacky tricks for unbreaking our own >>>> stuff. >>>> >>>> -- >>>> Dean >>>> >>>> >>>> >>> >> > From huang-ming.pan at comcast.net Mon Jun 12 21:31:41 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 12 Jun 2006 18:31:41 -0700 Subject: [p2p-sip] What are we doing, question 2 References: <00b401c68a83$a3bab930$6400a8c0@comcast.net> <049101c68c53$a8ca6b10$6400a8c0@comcast.net> <0293E3F7-4443-4F69-AAA2-DF57EEE246D4@cisco.com> <003d01c68d79$87e3f2a0$6400a8c0@comcast.net> <001d01c68dd0$43dcb6d0$6400a8c0@comcast.net> <003e01c68dd6$3182a0c0$6400a8c0@comcast.net> <8103FA0C-88AD-4CB7-86C9-DA923027B574@cisco.com> <003501c68e37$70bf2b80$6400a8c0@comcast.net> <6455B9BC-9951-4587-BE68-B5393F937CAF@cisco.com> <00ca01c68e46$9815ac90$6400a8c0@comcast.net> <014f01c68e5f$515a2f60$6400a8c0@comcast.net> <85149912-1A8B-459A-A8B6-D3BD9812D1C2@softarmor.com> <021f01c68e78$b85f7080$6400a8c0@comcast.net> Message-ID: <025e01c68e89$1ffdd370$6400a8c0@comcast.net> > It is sometimes difficult to ascertain the intent of a communicator > on a mailing list, but I have I have thought many of your messages on > the p2p-sip list to be aggressive, disruptive, offensive, and quite > possibly abusive in tone. This may well not have been your intent, > and if I misunderstood, I apologize. I tried to lighten the tone a > bit by applying humor, which you seem to have reacted to in a hostile > fashion indicating that perhaps I was unclear. If I was unclear, then > I also apologize for that, and I'd like to apologize to the larger > community for having aggravated the situation. > > If on the other hand your intent is to be offensive, we don't have to > put up with it. I would like to remind you that that the IETF > community does have a variety of procedures for dealing with > disruptive individuals. The foremost of these is to simply ignore the > disruptive individual, but the formal procedures do allow for the > removal of posting rights and the application of even more stringent > sanctions. I certainly hope things can be worked out without having > to resort to those sorts of measures. Please review all my messages on this thread. If you could find anything as offensive as your msg that would recommend a therapist which you claim it a "humor" now, I would apologize the same times as you do. If you could not, please take my prior msg as my application of humor. Really ORZ... Peter From RADHIKA.R.ROY at saic.com Tue Jun 13 15:31:27 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Tue, 13 Jun 2006 15:31:27 -0400 Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP Message-ID: <62D92A9A02BCC845B202323D49A48426230E16@0591-ITS-EXMP02.us.saic.com> https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-June/000956.html Hi, David: I am just referring to the above thread. We had also very interesting discussions about the item: NAT Crossing by P2P-SIP as well as by CS-SIP. Can you please help us to summarize where do we stand about the issue: NAT crossing by P2P-SIP? We will appreciate your help. Best regards, Radhika R. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060613/ad1719dc/attachment.html From hu.xinyu at huawei.com Tue Jun 13 20:48:39 2006 From: hu.xinyu at huawei.com (Seaward Hu) Date: Wed, 14 Jun 2006 08:48:39 +0800 Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP In-Reply-To: <62D92A9A02BCC845B202323D49A48426230E16@0591-ITS-EXMP02.us.saic.com> Message-ID: <000501c68f4c$4a811da0$1a05a40a@china.huawei.com> May be we should update a record file in draft format once a week , filled with discussed and discussing problems. Thanks. Seaward hu -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Roy, Radhika R. Sent: Wednesday, June 14, 2006 3:31 AM To: bryan at ethernot.org Cc: p2p-sip at cs.columbia.edu Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-June/000956.html Hi, David: I am just referring to the above thread. We had also very interesting discussions about the item: NAT Crossing by P2P-SIP as well as by CS-SIP. Can you please help us to summarize where do we stand about the issue: NAT crossing by P2P-SIP? We will appreciate your help. Best regards, Radhika R. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060613/a361a281/attachment-0001.html From RADHIKA.R.ROY at saic.com Wed Jun 14 10:22:14 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Wed, 14 Jun 2006 10:22:14 -0400 Subject: [p2p-sip] FW: [NSIS] QOS-over-P2P Overlay Network Message-ID: <62D92A9A02BCC845B202323D49A48426230E1D@0591-ITS-EXMP02.us.saic.com> FYI _____ From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On Behalf Of Roy, Radhika R. Sent: Wednesday, June 14, 2006 10:20 AM To: nsis at ietf.org Subject: [NSIS] QOS-over-P2P Overlay Network Folks: While off-path QOS discussions are going on in the NSIS WG list, I am trying to draw your attention about the above topic as you know P2P networking schemes are discussed in the following formal and informal IETF WGs: * MANET * P2P-SIP In this connection, I am also providing a URL: http://nms.lcs.mit.edu/papers/overqos-nsdi04.html The above will provide light how QOS can be enhanced further for the P2P applications without fully relying on the IP layer. It might an interesting approach to look a little differently for solving the QOS problems, and NSIS WG, I think, is the right place to have a start on this. The ideas are as follows: * Is it possible to enhance QOS signaling protocols to meet the needs of the applications with a combination of higher layer and/or IP network layer (without overly dependent on the IP layer)? * If so, can NSIS QOS signaling protocols be used to help all areas: Higher Layers (Application, Presentation) and IP Networking layer? Best regards, Radhika R. Roy -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060614/5e222628/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT261435.txt Url: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060614/5e222628/ATT261435.txt From bryan at ethernot.org Wed Jun 14 10:49:34 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 14 Jun 2006 10:49:34 -0400 Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP In-Reply-To: <000501c68f4c$4a811da0$1a05a40a@china.huawei.com> References: <62D92A9A02BCC845B202323D49A48426230E16@0591-ITS-EXMP02.us.saic.com> <000501c68f4c$4a811da0$1a05a40a@china.huawei.com> Message-ID: <8b2769930606140749o4c10ebd3m9e683b026d560bde@mail.gmail.com> I am happy to start tracking the activities and keep them somewhere for everyone to view. Good suggestion. I have to admit, however, I'm not sure the thread on NAT traversal really got too far. We started some discussion there, and discussed a particular implementation issue that was somewhat related to P2PSIP, but I'm not sure we really got a good discussion of how the current tools (STUN/TURN/ICE) could be best used to enable things. Part of the problem is that we are a bit pressed to discuss the best NAT traversal techniques for P2PSIP when we are still discussing exactly what it is we want to do as a group, but I will start tracking conclusions as we reach them. David On 6/13/06, Seaward Hu wrote: > > > > May be we should update a record file in draft format once a week , filled > with discussed and discussing problems. > > > Thanks. > > Seaward hu > > > > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Roy, Radhika R. > Sent: Wednesday, June 14, 2006 3:31 AM > To: bryan at ethernot.org > Cc: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP > > > > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-June/000956.html > > > > Hi, David: > > > > I am just referring to the above thread. > > > > We had also very interesting discussions about the item: NAT Crossing by > P2P-SIP as well as by CS-SIP. > > > > Can you please help us to summarize where do we stand about the issue: NAT > crossing by P2P-SIP? > > > > We will appreciate your help. > > > > Best regards, > > Radhika R. Roy > From RADHIKA.R.ROY at saic.com Wed Jun 14 10:52:28 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Wed, 14 Jun 2006 10:52:28 -0400 Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP Message-ID: <62D92A9A02BCC845B202323D49A48426230E1F@0591-ITS-EXMP02.us.saic.com> David: Even this is enough what you have explained here to keep as a record for NAT traversal. We can then trace further bit by bit as time goes by. We all appreciate your help. Best regards, Radhika -----Original Message----- From: davidbryan at gmail.com [mailto:davidbryan at gmail.com] On Behalf Of David A. Bryan Sent: Wednesday, June 14, 2006 10:50 AM To: Seaward Hu Cc: Roy, Radhika R.; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP I am happy to start tracking the activities and keep them somewhere for everyone to view. Good suggestion. I have to admit, however, I'm not sure the thread on NAT traversal really got too far. We started some discussion there, and discussed a particular implementation issue that was somewhat related to P2PSIP, but I'm not sure we really got a good discussion of how the current tools (STUN/TURN/ICE) could be best used to enable things. Part of the problem is that we are a bit pressed to discuss the best NAT traversal techniques for P2PSIP when we are still discussing exactly what it is we want to do as a group, but I will start tracking conclusions as we reach them. David On 6/13/06, Seaward Hu wrote: > > > > May be we should update a record file in draft format once a week , filled > with discussed and discussing problems. > > > Thanks. > > Seaward hu > > > > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Roy, Radhika R. > Sent: Wednesday, June 14, 2006 3:31 AM > To: bryan at ethernot.org > Cc: p2p-sip at cs.columbia.edu > Subject: [p2p-sip] Issues and Resolutions: NAT Crossing by P2P-SIP > > > > > https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-June/000956.html > > > > Hi, David: > > > > I am just referring to the above thread. > > > > We had also very interesting discussions about the item: NAT Crossing by > P2P-SIP as well as by CS-SIP. > > > > Can you please help us to summarize where do we stand about the issue: NAT > crossing by P2P-SIP? > > > > We will appreciate your help. > > > > Best regards, > > Radhika R. Roy > From eunsoo at research.panasonic.com Wed Jun 14 12:13:47 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 14 Jun 2006 12:13:47 -0400 Subject: [p2p-sip] work items we agreed on and not agreed on Message-ID: <449035BB.5090406@research.panasonic.com> As repeatedly stressed, we should focus on creating the WG and thus on work items for the first charter. There was a discussion about whether an IETF WG should design a system or a set of tools. Jon Peterson suggested that the proposed P2PSIP WG should focus on tools. I believe his view is widely accepted in the group and I also agree with him. Eventually the IETF produces protocols and developers and vendors use the protocols to design and build systems . We were requested to present our architecture(s) to explain what we are going to do in the BOF in Dallas. But I believe the intention is to explain what kind of tools we are going to produce using the architectures but not to limit the architectures or systems that can use the tools. Maybe not fast as we have hoped, but I believe we have made meaningful progresses. Below is my summary of our status in terms of consensus on work items. There are other things like what protocol we will use for a certain thing but we are not required to agree on those things or more details of the tools/work items at this stage. We would build the following tools: * P2PSIP Overlay Client Protocol - GET and PUT request/reply * Types and formats of data to be stored and shared on the P2PSIP Overlay Network for P2PSIP - There should be associated descriptions of how SIP can use the defined data. * Mechanism(s) to locate proximate STUN servers (TURN relay in a different language) For NAT Traversal, we agreed that NAT traversal should be considered from the beginning and that STUN/TURN/ICE should and could be used for P2PSIP but we would talk to the relevant WGs if we need anything new in STUN/TURN/ICE. For security, we agreed that the P2PSIP Overlay Network will typically consist of users not trusted by each other and thus there should be security mechanisms built into the protocols for P2PSIP. For basic call setup, we agreed that the UAC retrieves the location/contact/route information of the UAS from the P2PSIP Overlay Network using the GET procedure and establishes the call following RFC3261. * P2PSIP Overlay Peer Protocol - GET,PUT,JOIN,LEAVE - Selection of the P2P algorithm (or DHT) There are three positions about this. - We should select at least a DHT algorithm and design the Peer Protocol for v1.0. - We should do it but postpone it after v1.0. (A variation of this position suggests that, for v1.0, we assume multicast/broadcast among Peers.) - We should not do this at all. Does this summary concur with what you think? Thanks. Eunsoo From RADHIKA.R.ROY at saic.com Wed Jun 14 13:30:15 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Wed, 14 Jun 2006 13:30:15 -0400 Subject: [p2p-sip] work items we agreed on and not agreed on Message-ID: <62D92A9A02BCC845B202323D49A48426230E20@0591-ITS-EXMP02.us.saic.com> Eunsoo: Thanks for the excellent summary. Can we poll on this in this mailing list for the following topic before the Dallas meeting, and present this result in the BoF to have the final rough consensus? * P2PSIP Overlay Peer Protocol - GET,PUT,JOIN,LEAVE - Selection of the P2P algorithm (or DHT) There are three positions about this. - We should select at least a DHT algorithm and design the Peer Protocol for v1.0. - We should do it but postpone it after v1.0. (A variation of this position suggests that, for v1.0, we assume multicast/broadcast among Peers.) - We should not do this at all. Best regards, Radhika -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eunsoo Shim Sent: Wednesday, June 14, 2006 12:14 PM To: P2P-SIP Subject: [p2p-sip] work items we agreed on and not agreed on As repeatedly stressed, we should focus on creating the WG and thus on work items for the first charter. There was a discussion about whether an IETF WG should design a system or a set of tools. Jon Peterson suggested that the proposed P2PSIP WG should focus on tools. I believe his view is widely accepted in the group and I also agree with him. Eventually the IETF produces protocols and developers and vendors use the protocols to design and build systems . We were requested to present our architecture(s) to explain what we are going to do in the BOF in Dallas. But I believe the intention is to explain what kind of tools we are going to produce using the architectures but not to limit the architectures or systems that can use the tools. Maybe not fast as we have hoped, but I believe we have made meaningful progresses. Below is my summary of our status in terms of consensus on work items. There are other things like what protocol we will use for a certain thing but we are not required to agree on those things or more details of the tools/work items at this stage. We would build the following tools: * P2PSIP Overlay Client Protocol - GET and PUT request/reply * Types and formats of data to be stored and shared on the P2PSIP Overlay Network for P2PSIP - There should be associated descriptions of how SIP can use the defined data. * Mechanism(s) to locate proximate STUN servers (TURN relay in a different language) For NAT Traversal, we agreed that NAT traversal should be considered from the beginning and that STUN/TURN/ICE should and could be used for P2PSIP but we would talk to the relevant WGs if we need anything new in STUN/TURN/ICE. For security, we agreed that the P2PSIP Overlay Network will typically consist of users not trusted by each other and thus there should be security mechanisms built into the protocols for P2PSIP. For basic call setup, we agreed that the UAC retrieves the location/contact/route information of the UAS from the P2PSIP Overlay Network using the GET procedure and establishes the call following RFC3261. * P2PSIP Overlay Peer Protocol - GET,PUT,JOIN,LEAVE - Selection of the P2P algorithm (or DHT) There are three positions about this. - We should select at least a DHT algorithm and design the Peer Protocol for v1.0. - We should do it but postpone it after v1.0. (A variation of this position suggests that, for v1.0, we assume multicast/broadcast among Peers.) - We should not do this at all. Does this summary concur with what you think? Thanks. Eunsoo _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Thu Jun 15 02:12:10 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Wed, 14 Jun 2006 23:12:10 -0700 Subject: [p2p-sip] work items we agreed on and not agreed on References: <62D92A9A02BCC845B202323D49A48426230E20@0591-ITS-EXMP02.us.saic.com> Message-ID: <003f01c69042$a3dc1a70$6400a8c0@comcast.net> > Can we poll on this in this mailing list for the following topic before > the Dallas meeting, and present this result in the BoF to have the final > rough consensus? > > > > > * P2PSIP Overlay Peer Protocol > - GET,PUT,JOIN,LEAVE > - Selection of the P2P algorithm (or DHT) [pp]: These two items should not be mutual dependent, as long as the primitives (GET,PUT,...) are well abstracted to fit 2+ popular DHTs. > > There are three positions about this. > - We should select at least a DHT algorithm and design the Peer > Protocol for v1.0. [pp]: This option feels like WakeField's knuckle ball bobbled behind the catcher, which strikes out those unlucky dogs who happen to have chosen another DHT, and leaves their third-base runners in a dilemma of diving home or not. > - We should do it but postpone it after v1.0. (A variation of > this position suggests that, for v1.0, we assume multicast/broadcast > among Peers.) [pp]: Avaya and eBay cannot be happier with this option :) > - We should not do this at all. [pp]: My ballot would favor this option if I'm allowed to vote. Though well-abstracted primitives may not necessarily realize direct interoperability between nodes of different DHTs, they hopefully can facilitate interoperability between nodes of the same DHT types, as long as DHT-dependency is avoided throughout the P2PSIP journey. That would be a great boon to those unlucky dogs who choose the wrong side for different technical belief but still care about protocol standardization. After all, reflexly we all speak the same language -- SIP. From Miguel.An.Garcia at nokia.com Thu Jun 15 02:31:48 2006 From: Miguel.An.Garcia at nokia.com (Miguel Garcia) Date: Thu, 15 Jun 2006 09:31:48 +0300 Subject: [p2p-sip] Sharing resources with SIP Message-ID: <4490FED4.30902@nokia.com> Hi: We have just submitted a couple of drafts that might be of interest, as additional literature, to SIP P2P list. The documents propose a mechanism for sharing resources (like files) between SIP endpoints, thus, they have interesting applications in P2P networks. Although we believe the drafts do not fit into any of the items of the proposed charter, still we would like to hear comments from people in this list. The authors are soliciting comments about these drafts: http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-sharing-framework-00.txt http://www.ietf.org/internet-drafts/draft-garcia-sipping-resource-event-package-00.txt or if you prefer HTML versions: http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-resource-sharing-framework-00.html http://people.nokia.net/~miguel/drafts/draft-garcia-sipping-resource-event-package-00.html /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia at openlaboratory.net Nokia Research Center Helsinki, Finland From eunsoo at research.panasonic.com Thu Jun 15 16:52:10 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 15 Jun 2006 16:52:10 -0400 Subject: [p2p-sip] work items we agreed on and not agreed on In-Reply-To: <003f01c69042$a3dc1a70$6400a8c0@comcast.net> References: <62D92A9A02BCC845B202323D49A48426230E20@0591-ITS-EXMP02.us.saic.com> <003f01c69042$a3dc1a70$6400a8c0@comcast.net> Message-ID: <4491C87A.2020608@research.panasonic.com> Peter Pan wrote: >> Can we poll on this in this mailing list for the following topic before >> the Dallas meeting, and present this result in the BoF to have the final >> rough consensus? >> >> >> >> >> * P2PSIP Overlay Peer Protocol >> - GET,PUT,JOIN,LEAVE >> - Selection of the P2P algorithm (or DHT) > > [pp]: These two items should not be mutual dependent, as long as the > primitives (GET,PUT,...) are well abstracted to fit 2+ popular DHTs. > What do you mean by 'primitives'? If they are API, I think we can define the API fairly independent of underling DHTs. The recent draft by Kundan and Henning ( http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-00.txt ) presents the point well. If they are protocol (message formats and procedures), it was pointed out that even GET and PUT procedures were likely to affected by the underling DHTs. For example, replication is likely to depend on the DHT. That's why GET and PUT were not separated from JOIN and LEAVE which are obviously dependent on the underling DHT. >> There are three positions about this. >> - We should select at least a DHT algorithm and design the Peer >> Protocol for v1.0. > > [pp]: This option feels like WakeField's knuckle ball bobbled behind the > catcher, which strikes out those unlucky dogs who happen to have chosen > another DHT, and leaves their third-base runners in a dilemma of diving home > or not. > >> - We should do it but postpone it after v1.0. (A variation of >> this position suggests that, for v1.0, we assume multicast/broadcast >> among Peers.) > > [pp]: Avaya and eBay cannot be happier with this option :) > >> - We should not do this at all. > > [pp]: My ballot would favor this option if I'm allowed to vote. Though > well-abstracted primitives may not necessarily realize direct > interoperability between nodes of different DHTs, they hopefully can > facilitate interoperability between nodes of the same DHT types, as long as > DHT-dependency is avoided throughout the P2PSIP journey. Again I think we need to clarify what you mean by 'primitivies'. Sharing the API does not enable interoperability. We need interoperability in the level of message formats and procedures. To specify the message formats and procedures, it is unavoidable to pick a DHT algorithm. Note: we are not talking about interoperation between different DHTs but just between nodes supporting the same DHT. That would be a > great boon to those unlucky dogs who choose the wrong side for different > technical belief but still care about protocol standardization. After all, > reflexly we all speak the same language -- SIP. > > Thanks. Eunsoo From philip_matthews at magma.ca Fri Jun 16 11:37:41 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 16 Jun 2006 11:37:41 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <447E702C.7060305@research.panasonic.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <447E702C.7060305@research.panasonic.com> Message-ID: <74CC351B-175E-464E-9AF6-B45C56DA12A3@magma.ca> On 1-Jun-06, at 00:42 , Eunsoo Shim wrote: >>> >>> >>> >>> True that it is not easy but it's not clear that it is any harder >>> than setting up RTP between two devices behind NAT which I >>> believe to >>> be a requirement of this work. >> >> > > For a given pair of nodes, I guess it is the same task as setting up a > RTP channel. > The difference is that, if a node behind NAT participates in DHT, it > should maintain multiple or many of such channels with nodes which may > change over time. > For Chord, a JOIN operation involves of O(log2 N) messages when no NAT > is involved. If NATs are involved, I am sure more traffic will be > required for a JOIN operation. > Which is why I don't think _vanilla_ Chord is a very good solution for P2PSIP. IF we choose Chord, then P2PSIP allows us to make some fairly simple modifications that reduce the overhead of joins and leaves. For example, we might require peers to re-register every 15 seconds, in which case the P2PSIP network might not have to do any work when a peer leaves. (Note that the SIP proxies for a major VoIP provider today currently enforce a 15 second timeout for registrations, so this is clearly workable). - Philip From huang-ming.pan at comcast.net Fri Jun 16 11:35:19 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 16 Jun 2006 08:35:19 -0700 Subject: [p2p-sip] work items we agreed on and not agreed on References: <62D92A9A02BCC845B202323D49A48426230E20@0591-ITS-EXMP02.us.saic.com> <003f01c69042$a3dc1a70$6400a8c0@comcast.net> <4491C87A.2020608@research.panasonic.com> Message-ID: <000a01c6915a$79d69cf0$6400a8c0@comcast.net> > What do you mean by 'primitives'? > If they are API, I think we can define the API fairly independent of > underling DHTs. > The recent draft by Kundan and Henning ( > http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-00.txt ) > presents the point well. > If they are protocol (message formats and procedures), it was pointed > out that even GET and PUT procedures were likely to affected by the > underling DHTs. For example, replication is likely to depend on the DHT. > That's why GET and PUT were not separated from JOIN and LEAVE which are > obviously dependent on the underling DHT. > [pp]: Sorry if I misuse it. By "primitives" I mean basic overlay operations of "generic" DHTs, not of a specific DHT. > Again I think we need to clarify what you mean by 'primitivies'. > Sharing the API does not enable interoperability. > We need interoperability in the level of message formats and procedures. > To specify the message formats and procedures, it is unavoidable to pick > a DHT algorithm. [pp]: Right. The primitives are not API but are procedures and messages of a generalized protocol (eg. XML/RPC based) that lies above popular DHTs to tunnel between P2PSIP nodes of *same DHT types*. Regretfully I'm not sure at all whether such a "dream protocol" is possible. If it is concluded as mirage, I agree a decisive ball is unavoidably necessary for things here to move on (but also unavoidably callous for those unlucky dogs to leave). > Note: we are not talking about interoperation between different DHTs but > just between nodes supporting the same DHT. [pp]: Well believed and appreciated for quite some time. From bryan at ethernot.org Fri Jun 16 11:38:50 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 16 Jun 2006 11:38:50 -0400 Subject: [p2p-sip] work items we agreed on and not agreed on In-Reply-To: <4491C87A.2020608@research.panasonic.com> References: <62D92A9A02BCC845B202323D49A48426230E20@0591-ITS-EXMP02.us.saic.com> <003f01c69042$a3dc1a70$6400a8c0@comcast.net> <4491C87A.2020608@research.panasonic.com> Message-ID: <8b2769930606160838l60747709r1ba84bc7d35a5e0e@mail.gmail.com> I agree with Eunsoo's last couple of points here. My thought is that if we do not select some sort of DHT, we can't (at least easily) have nodes from different vendors working together, which personally I view as the main reason to standardize things. Perhaps we could find someway to allow nodes to use different DHTs and yet allow them to fully interoperate, but I certainly can't imagine how. The purpose of standardization is to allow things from different vendors/open source implementations to interoperate in such a way that they can at least communicate and (hopefully) that components from different vendors can be combined in a deployment. It seems to me that if we have a "standard" where each implementation meets it but uses a different DHT and is thus an island, that isn't a "standard", it is a blessing from the IETF on a proprietary technology or something, which I don't think is really what we are here for. If we don't standardize *how* the p2p nodes interact with each other, it seems we are simply building islands. We can do that by having each faction write a BCP in SIPPING about how each DHT works and be done with it...no working group needed. I don't think that is really what we had in mind. I would think we may standardize a small but greater than 1 number of DHTs mind you, although I think we would have to see compelling distinctions between the DHTs to want to do that, not the sort of fractional speedups and nearly imperceptible algorithmic tweaks that differentiate most of the DHTs today from one another. My 2 cents. David Bryan On 6/15/06, Eunsoo Shim wrote: > Peter Pan wrote: > >> Can we poll on this in this mailing list for the following topic before > >> the Dallas meeting, and present this result in the BoF to have the final > >> rough consensus? > >> > >> > >> > >> > >> * P2PSIP Overlay Peer Protocol > >> - GET,PUT,JOIN,LEAVE > >> - Selection of the P2P algorithm (or DHT) > > > > [pp]: These two items should not be mutual dependent, as long as the > > primitives (GET,PUT,...) are well abstracted to fit 2+ popular DHTs. > > > What do you mean by 'primitives'? > If they are API, I think we can define the API fairly independent of > underling DHTs. > The recent draft by Kundan and Henning ( > http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-00.txt ) > presents the point well. > If they are protocol (message formats and procedures), it was pointed > out that even GET and PUT procedures were likely to affected by the > underling DHTs. For example, replication is likely to depend on the DHT. > That's why GET and PUT were not separated from JOIN and LEAVE which are > obviously dependent on the underling DHT. > > >> There are three positions about this. > >> - We should select at least a DHT algorithm and design the Peer > >> Protocol for v1.0. > > > > [pp]: This option feels like WakeField's knuckle ball bobbled behind the > > catcher, which strikes out those unlucky dogs who happen to have chosen > > another DHT, and leaves their third-base runners in a dilemma of diving home > > or not. > > > >> - We should do it but postpone it after v1.0. (A variation of > >> this position suggests that, for v1.0, we assume multicast/broadcast > >> among Peers.) > > > > [pp]: Avaya and eBay cannot be happier with this option :) > > > >> - We should not do this at all. > > > > [pp]: My ballot would favor this option if I'm allowed to vote. Though > > well-abstracted primitives may not necessarily realize direct > > interoperability between nodes of different DHTs, they hopefully can > > facilitate interoperability between nodes of the same DHT types, as long as > > DHT-dependency is avoided throughout the P2PSIP journey. > > Again I think we need to clarify what you mean by 'primitivies'. > Sharing the API does not enable interoperability. > We need interoperability in the level of message formats and procedures. > To specify the message formats and procedures, it is unavoidable to pick > a DHT algorithm. > > Note: we are not talking about interoperation between different DHTs but > just between nodes supporting the same DHT. > > That would be a > > great boon to those unlucky dogs who choose the wrong side for different > > technical belief but still care about protocol standardization. After all, > > reflexly we all speak the same language -- SIP. > > > > > > Thanks. > > Eunsoo > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From bryan at ethernot.org Fri Jun 16 11:42:31 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 16 Jun 2006 11:42:31 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <74CC351B-175E-464E-9AF6-B45C56DA12A3@magma.ca> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <447E702C.7060305@research.panasonic.com> <74CC351B-175E-464E-9AF6-B45C56DA12A3@magma.ca> Message-ID: <8b2769930606160842u6b14aad0w1e7f64beefbdf2cc@mail.gmail.com> Fully agree. At least from my experience both on the research side and my commercial implementation work, we had to tweak whatever algortithm we selected. My thought is we start with some DHT as a starting point and work on making it "optimized" for VoIP systems. David Bryan On 6/16/06, Philip Matthews wrote: > > On 1-Jun-06, at 00:42 , Eunsoo Shim wrote: > >>> > >>> > >>> > >>> True that it is not easy but it's not clear that it is any harder > >>> than setting up RTP between two devices behind NAT which I > >>> believe to > >>> be a requirement of this work. > >> > >> > > > > For a given pair of nodes, I guess it is the same task as setting up a > > RTP channel. > > The difference is that, if a node behind NAT participates in DHT, it > > should maintain multiple or many of such channels with nodes which may > > change over time. > > For Chord, a JOIN operation involves of O(log2 N) messages when no NAT > > is involved. If NATs are involved, I am sure more traffic will be > > required for a JOIN operation. > > > > Which is why I don't think _vanilla_ Chord is a very good solution > for P2PSIP. > IF we choose Chord, then P2PSIP allows us to make some fairly simple > modifications > that reduce the overhead of joins and leaves. > For example, we might require peers to re-register every 15 seconds, > in which case the P2PSIP network might not have to do any work when > a peer leaves. > (Note that the SIP proxies for a major VoIP provider today currently > enforce > a 15 second timeout for registrations, so this is clearly workable). > > - Philip > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From enrico.marocco at telecomitalia.it Fri Jun 16 12:17:29 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 16 Jun 2006 18:17:29 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <74CC351B-175E-464E-9AF6-B45C56DA12A3@magma.ca> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <447E702C.7060305@research.panasonic.com> <74CC351B-175E-464E-9AF6-B45C56DA12A3@magma.ca> Message-ID: <4492D999.5050408@telecomitalia.it> Philip Matthews wrote: > IF we choose Chord, then P2PSIP allows us to make some fairly simple > modifications > that reduce the overhead of joins and leaves. > For example, we might require peers to re-register every 15 seconds, > in which case the P2PSIP network might not have to do any work when > a peer leaves. > (Note that the SIP proxies for a major VoIP provider today currently > enforce > a 15 second timeout for registrations, so this is clearly workable). That's right. A short interval between successive stabilizations would also permit to maintain a fairly good finger table based only on the info retrieved from a few peers. This is IMHO the most important optimization, because querying hundreds of peer as _vanilla_ chord requires would be prohibitive in most of the environments where P2PSIP could be useful. Enrico From philip_matthews at magma.ca Fri Jun 16 11:37:05 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 16 Jun 2006 11:37:05 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> Message-ID: <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> [A belated comment on this -- sorry, but I have been busy with another project recently] I completely agree with Cullen's comments on this. To re-iterate with a few extra comments of my own: 1) IF we use a method like Chord as the distributed lookup mechanism (and I happen to think that there are other, non-DHT approaches, which have some attractive properties that Chord and other DHTs do not), then if a peer cannot keep the full finger table (because it is a wireless node or because it is behind a NAT), then it can drop every other finger table entry and everything still works, albeit with reduced performance. 2) Maintaining connections behind NATs does require a bit of work when the connection runs over UDP, especially if the peer is also wireless. However, it is easier when the connection runs over TCP. If our finger table connections run over TCP, then the effort of maintaining 20 of them may be equal to the effort required to maintain a single voice connection over UDP. - Philip On 31-May-06, at 22:33 , Cullen Jennings wrote: > > One trivial comment and one important comment inline... > > On May 31, 2006, at 9:07 AM, Eunsoo Shim wrote: > >> Cullen Jennings wrote: >> >>> >>> On May 30, 2006, at 10:39 AM, Alan Johnston wrote: >>> >>>> Cullen Jennings wrote: >>>> >>>>> Ok, I'm glad to hear that at least some people think we have some >>>>> consensus on this. It's been hard to tell following the list so I >>>>> appreciate people speaking up about it. >>>>> >>>>> I'll be very blunt about doing both proposal. It is not clear to >>>>> me if people think we should do both because >>>>> 1) this is the technical long term solution we want, or >>>>> 2) this would make it so at some level everyone agreed. >>>>> >>>>> Doing both will no doubt slow down finishing either. It is not >>>>> clear to the that the GET/PUT only protocol would be used if the >>>>> other GET/ PUT/JOIN/LEAVE exists - it seems like you would just >>>>> want the later of the two. So if we look at our end goal, is >>>>> there >>>>> a need for GET/ PUT only. >>>>> >>>> Yes. Real DHT nodes typically interact with 100s if not 1000s of >>>> peer nodes at any given instant. Will every SIP UA be capable of >>>> doing this? >>> >>> >>> I'll use chord as an example here not because I think chord is the >>> right DHT but only as a concrete example. A node that knew a few >>> other chord nodes but was not storing any data could easily interact >>> with the DHT and only have very few connections. >>> >> Please let me try to clarify the issure a little bit more. >> >> A node in Chord must maintain a finger table and data with keys of a >> certain range or locations of such data. >> Chord requires each node (in the Chord network) to have around log N >> fingers (where N is the total number of nodes in the Chord network >> and >> the base is 2). So if the network size is around 64,000, the >> number of >> fingers for each node is around 16. For a network of around a million >> nodes, the number becomes around 20. > > the trivial comment - A trivial modification to the Chord algo would > say that if a node wanted less finger tables, it dropped half the > current ones and kept every other finger entry - things would still > work. I'm not arguing this is a good idea but I am pointing out there > are many ways to modify a DHT to meet this somewhat requirement of > low connection count. The problem with most low power devices is not > keeping up 20 connection but instead how often they have to wake up > for traffic. It may be that P2P is a real bad idea for mobile devices > because you need to keep updating data. All this really does is worry > me that selecting a DHT for use in mobile environments is a research > problem. > >> >> There is a cost for maintaining the finger table when the network is >> dynamic (nodes join and leave). Furthermore, each node should provide >> routing for various Chord messages such as GET/PUT/JOIN/LEAVE. >> >> When a node has limited bandwidth or battery power, the above >> requirements may be too much. If the node is behind NAT, it is not >> simple maintaining connections with fingers and other nodes for which >> the node is a finger. > > True that it is not easy but it's not clear that it is any harder > than setting up RTP between two devices behind NAT which I believe to > be a requirement of this work. > >> >> What I said kind of justifies the distinction between devices (SIP >> UAs) >> that participate in the DHT (Chord) and devices (SIP UAs) that do >> not. >> The devices that do not participate in the DHT don't need to support >> JOIN and LEAVE but need to do just GET/PUT. >> >> So now we have two interfaces. >> >> Node in DHT Node in >> DHT Node not in DHT >> >> >> |<---------------------------------------->| >> <------------------------------------------------------>| >> (a) GET/PUT (b) >> GET/PUT >> JOIN/LEAVE >> >> Now the question has a few angles. >> - Will (a) GET/PUT be dependent of the underling DHT algorithm? >> - Will (a) GET/PUT and (b) GET/PUT have any difference in the >> syntax and >> semantics? >> - Will it be difficult to separate (a) GET/PUT from JOIN/LEAVE? >> >> If an answer for any of the above question is 'yes', I think we'd be >> better off by defining (b) GET/PUT as a separate protocol. And I >> think >> it is a safe assumption. >> If we find out none of the answers is 'yes', then we would not need a >> separate protocol for (b) GET/PUT. >> Nodes not in DHT can safely just implement and support GET/PUT but >> not >> JOIN/LEAVE. >> >> Hope I added some clarity, not confusion. > > Yes sort of. I think what you are saying is that if any of the > answers are yes, then we will not be able to build an interoperable > protocol to do the (a) side so we will need the (b) protocol. Do I > have this right? > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From enrico.marocco at telecomitalia.it Fri Jun 16 12:49:37 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 16 Jun 2006 18:49:37 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> Message-ID: <4492E121.7050809@telecomitalia.it> Philip Matthews wrote: > 2) Maintaining connections behind NATs does require a bit of work > when the > connection runs over UDP, especially if the peer is also wireless. > However, it is easier when the connection runs > over TCP. If our finger table connections run over TCP, then > the effort of > maintaining 20 of them may be equal to the effort required to > maintain > a single voice connection over UDP. The problem for a node behind a NAT is not maintaining connection with its fingers; instead, what is really difficult is being reachable from any peer. Unfortunately chord requires the latter. Enrico From philip_matthews at magma.ca Fri Jun 16 13:37:26 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 16 Jun 2006 13:37:26 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <4492E121.7050809@telecomitalia.it> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> Message-ID: [Removing Cullen from the CC list as he is probably pretty swamped right now ...] On 16-Jun-06, at 12:49 , Enrico Marocco wrote: > Philip Matthews wrote: >> 2) Maintaining connections behind NATs does require a bit of work >> when the >> connection runs over UDP, especially if the peer is also >> wireless. >> However, it is easier when the connection runs >> over TCP. If our finger table connections run over TCP, then >> the effort of >> maintaining 20 of them may be equal to the effort required to >> maintain >> a single voice connection over UDP. > > The problem for a node behind a NAT is not maintaining connection with > its fingers; instead, what is really difficult is being reachable from > any peer. Unfortunately chord requires the latter. Not true. If peers forward requests on to other peer, a individual peer only has to have connections to a very small subset of the entire peer population. In other words, say peer A wants to reach peer Z. Say A does not have a direct connection to Z, but does have a direct connection to (say) B and C. It picks the one that is closest to Z (say C), and forwards its message (say a SIP INVITE) to C. Peer C then looks at its finger table and discovers that it, too, does not have a direct connection to Z, but has a connection to D which is closer. So C forwards the message to D. And so on. Eric Cooper and I talked about this in the Internet Draft that I presented at the last P2PSIP ad-hoc in Dallas: http://www.p2psip.org/drafts/draft-matthews-p2psip-nats-and- overlays-00.html See section 4.4.2. Note that another problem with vanilla_Chord identified in this document is that it does not exhibit the "Symmetric Interest" property (see section 4.4.3). However, a fairly straight-forward modification does. - Philip From matthew at matthew.at Fri Jun 16 14:27:59 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 16 Jun 2006 11:27:59 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> Message-ID: <010c01c69172$9c0d1480$0202fea9@matthewdesk> Philip Matthews: > 1) IF we use a method like Chord as the distributed lookup mechanism > (and I happen to think that there are other, non-DHT > approaches, which > have some attractive properties that Chord and other > DHTs do not), I agree. Somewhere between "non-DHT" and "DHT-like" is probably the right answer for this problem. > then if a peer cannot keep the full finger table > (because it is a wireless node > or because it is behind a NAT), then it can drop every > other finger table entry > and everything still works, albeit with reduced performance. True for recursively-routed DHTs, not true for iteratively-routed DHTs. Matthew Kaufman matthew at matthew.at http://www.amicima.com From enrico.marocco at telecomitalia.it Fri Jun 16 15:04:46 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Fri, 16 Jun 2006 21:04:46 +0200 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> Message-ID: <449300CE.1010504@telecomitalia.it> Philip Matthews wrote: >> The problem for a node behind a NAT is not maintaining connection with >> its fingers; instead, what is really difficult is being reachable from >> any peer. Unfortunately chord requires the latter. > > Not true. If peers forward requests on to other peer, a individual peer > only > has to have connections to a very small subset of the entire peer > population. > > In other words, say peer A wants to reach peer Z. Say A does not have a > direct > connection to Z, but does have a direct connection to (say) B and C. It > picks > the one that is closest to Z (say C), and forwards its message (say a > SIP INVITE) > to C. Peer C then looks at its finger table and discovers that it, too, > does not have > a direct connection to Z, but has a connection to D which is closer. So > C forwards > the message to D. And so on. True. However this does not hold for an iterative implementation of chord. > Eric Cooper and I talked about this in the Internet Draft that I presented > at the last P2PSIP ad-hoc in Dallas: > http://www.p2psip.org/drafts/draft-matthews-p2psip-nats-and-overlays-00.html > See section 4.4.2. Note that another problem with vanilla_Chord identified in > this document is that it does not exhibit the "Symmetric Interest" property > (see section 4.4.3). However, a fairly straight-forward modification does. Without such a property, the number of connections each node needs for keeping the complexity logarithmic is huge: at least logN (where N is the number of nodes in the overlay, not the cardinality of the hash function) from it toward its fingers and - I guess, but I'm not sure - logN originated from nodes in the DHT which have it as a finger. Do these numbers agree with your analysis? Enrico From philip_matthews at magma.ca Fri Jun 16 17:31:59 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 16 Jun 2006 17:31:59 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <010c01c69172$9c0d1480$0202fea9@matthewdesk> References: <010c01c69172$9c0d1480$0202fea9@matthewdesk> Message-ID: <33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> On 16-Jun-06, at 14:27 , Matthew Kaufman wrote: > Philip Matthews: >> 1) IF we use a method like Chord as the distributed lookup mechanism >> (and I happen to think that there are other, non-DHT >> approaches, which >> have some attractive properties that Chord and other >> DHTs do not), > > I agree. Somewhere between "non-DHT" and "DHT-like" is probably the > right > answer for this problem. > Yes. My main concern with DHTs are that they cannot do wildcard searches efficiently. You have to know my exact AOR to phone me. Unless I can always be, for example, "philip_matthews" in every P2PSIP network, it will be hard for you to figure out how to phone me without an e- mail exchange or similar if you must enter my exact AOR. But if I can search for "Philip Matthews" and get back a list of users with some extra identifying information, you have a good chance of finding and phoning me. - Philip From bryan at ethernot.org Fri Jun 16 18:33:01 2006 From: bryan at ethernot.org (David A. Bryan) Date: Fri, 16 Jun 2006 18:33:01 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> References: <010c01c69172$9c0d1480$0202fea9@matthewdesk> <33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> Message-ID: <8b2769930606161533r226d6be7te59a18da387f8b5b@mail.gmail.com> Hmmm...interesting, but registrar functionality isn't really about search. If we are just building a replacement for registration that is distributed, search isn't a fundamental feature. David On 6/16/06, Philip Matthews wrote: > > On 16-Jun-06, at 14:27 , Matthew Kaufman wrote: > > > Philip Matthews: > >> 1) IF we use a method like Chord as the distributed lookup mechanism > >> (and I happen to think that there are other, non-DHT > >> approaches, which > >> have some attractive properties that Chord and other > >> DHTs do not), > > > > I agree. Somewhere between "non-DHT" and "DHT-like" is probably the > > right > > answer for this problem. > > > > Yes. My main concern with DHTs are that they cannot do wildcard searches > efficiently. You have to know my exact AOR to phone me. > > Unless I can always be, for example, "philip_matthews" in every > P2PSIP network, > it will be hard for you to figure out how to phone me without an e- > mail exchange > or similar if you must enter my exact AOR. > > But if I can search for "Philip Matthews" and get back a list of > users with some > extra identifying information, you have a good chance of finding and > phoning me. > > - Philip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From huang-ming.pan at comcast.net Fri Jun 16 18:45:33 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 16 Jun 2006 15:45:33 -0700 Subject: [p2p-sip] What are we doing - question 1 References: <010c01c69172$9c0d1480$0202fea9@matthewdesk><33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> <8b2769930606161533r226d6be7te59a18da387f8b5b@mail.gmail.com> Message-ID: <014101c69196$94111ff0$6400a8c0@comcast.net> In worse case, AOR search can be achieved by flooding. Who will feel and mind it? > Hmmm...interesting, but registrar functionality isn't really about > search. If we are just building a replacement for registration that is > distributed, search isn't a fundamental feature. > > David > > On 6/16/06, Philip Matthews wrote: > > > > On 16-Jun-06, at 14:27 , Matthew Kaufman wrote: > > > > > Philip Matthews: > > >> 1) IF we use a method like Chord as the distributed lookup mechanism > > >> (and I happen to think that there are other, non-DHT > > >> approaches, which > > >> have some attractive properties that Chord and other > > >> DHTs do not), > > > > > > I agree. Somewhere between "non-DHT" and "DHT-like" is probably the > > > right > > > answer for this problem. > > > > > > > Yes. My main concern with DHTs are that they cannot do wildcard searches > > efficiently. You have to know my exact AOR to phone me. > > > > Unless I can always be, for example, "philip_matthews" in every > > P2PSIP network, > > it will be hard for you to figure out how to phone me without an e- > > mail exchange > > or similar if you must enter my exact AOR. > > > > But if I can search for "Philip Matthews" and get back a list of > > users with some > > extra identifying information, you have a good chance of finding and > > phoning me. > > > > - Philip From arjunrc at gmail.com Fri Jun 16 20:17:58 2006 From: arjunrc at gmail.com (Arjun Roychowdhury) Date: Fri, 16 Jun 2006 20:17:58 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> References: <010c01c69172$9c0d1480$0202fea9@matthewdesk> <33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> Message-ID: Has anyone looked at hybrid architectures such as p-grid (www.p-grid.org). The p-grid network is structured as a combination of DHT functionality and a tree topology. Keys can then be stored as a function of the node-id value, instead of it being random, and a binary search could be done on node-id prefixes emulating a wildcard search. regds arjun On 6/16/06, Philip Matthews wrote: > > On 16-Jun-06, at 14:27 , Matthew Kaufman wrote: > > > Philip Matthews: > >> 1) IF we use a method like Chord as the distributed lookup mechanism > >> (and I happen to think that there are other, non-DHT > >> approaches, which > >> have some attractive properties that Chord and other > >> DHTs do not), > > > > I agree. Somewhere between "non-DHT" and "DHT-like" is probably the > > right > > answer for this problem. > > > > Yes. My main concern with DHTs are that they cannot do wildcard searches > efficiently. You have to know my exact AOR to phone me. > > Unless I can always be, for example, "philip_matthews" in every > P2PSIP network, > it will be hard for you to figure out how to phone me without an e- > mail exchange > or similar if you must enter my exact AOR. > > But if I can search for "Philip Matthews" and get back a list of > users with some > extra identifying information, you have a good chance of finding and > phoning me. > > - Philip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- Arjun Roychowdhury From huang-ming.pan at comcast.net Fri Jun 16 23:32:36 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Fri, 16 Jun 2006 20:32:36 -0700 Subject: [p2p-sip] What are we doing - question 1 References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com><44761920.7030403@research.panasonic.com><4476D80E.7070100@telecomitalia.it><4477341C.5000107@research.panasonic.com><447C2532.7010805@telecomitalia.it><447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com><447DBF51.8030803@research.panasonic.com><0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca><4492E121.7050809@telecomitalia.it> Message-ID: <01f001c691be$adf81bd0$6400a8c0@comcast.net> > Not true. If peers forward requests on to other peer, a individual > peer only > has to have connections to a very small subset of the entire peer > population. > > In other words, say peer A wants to reach peer Z. Say A does not have > a direct > connection to Z, but does have a direct connection to (say) B and C. > It picks > the one that is closest to Z (say C), and forwards its message (say a > SIP INVITE) > to C. Peer C then looks at its finger table and discovers that it, > too, does not have > a direct connection to Z, but has a connection to D which is closer. > So C forwards > the message to D. And so on. > > - Philip Will response traverse the same forwarding path (Z=>D=>C=>A)? If yes, this heuristic can leave uncertain number of outstanding call legs (and possibly loops) along the path. If no, Z's response sometime cannot penetrate A's NAT. Is it more decisive for A to first GET Z's location(s) and then shot the request directly to Z? Thanks. Peter From fluffy at cisco.com Sun Jun 18 16:48:48 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Sun, 18 Jun 2006 13:48:48 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <4492E121.7050809@telecomitalia.it> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <44761920.7030403@research.panasonic.com> <4476D80E.7070100@telecomitalia.it> <4477341C.5000107@research.panasonic.com> <447C2532.7010805@telecomitalia.it> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> Message-ID: <9D38CC2D-961B-4BBE-9A11-87300361354C@cisco.com> It's clear that the NAT issues do change how you might desire the DHT (or something similar) to deal with routing. If you pick something without considering NAT, I suspect it will be very hard to move it to NAT later. Because of this, I felt we wanted to have the NAT requirement in scope in the charter. It's clear that something like a iterative routed chord could probably work with NATs but not clear that is the best. Iterative routing has more problems from a security point of view than recursive routing because it is easier to reroute large parts of they namespace. I don't think we need to choose a solution to get to the point we have a charter but I do think this is part of the problem I want to deal with. Cullen On Jun 16, 2006, at 9:49 AM, Enrico Marocco wrote: > Philip Matthews wrote: >> 2) Maintaining connections behind NATs does require a bit of work >> when the >> connection runs over UDP, especially if the peer is also >> wireless. >> However, it is easier when the connection runs >> over TCP. If our finger table connections run over TCP, then >> the effort of >> maintaining 20 of them may be equal to the effort required to >> maintain >> a single voice connection over UDP. > > The problem for a node behind a NAT is not maintaining connection with > its fingers; instead, what is really difficult is being reachable from > any peer. Unfortunately chord requires the latter. From bryan at ethernot.org Sun Jun 18 20:44:34 2006 From: bryan at ethernot.org (David A. Bryan) Date: Sun, 18 Jun 2006 20:44:34 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <9D38CC2D-961B-4BBE-9A11-87300361354C@cisco.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> <9D38CC2D-961B-4BBE-9A11-87300361354C@cisco.com> Message-ID: <8b2769930606181744i3da9183dj3c6c99b184c379c2@mail.gmail.com> Hmmm...I think you might have iterative and recursive mixed up here, unless I'm missing something. Recursive (think proxy server) would be good for NAT punching, since you only need to keep connections to your fingers and nothing else. Iterative (think redirect server) on the other hand will require arbitrary punching. In addition to the point you made, on the security side, although the recursive mechanisms may gain you in firewall traversal, they can also be a DoS magnifier (or at least obfuscator) since you can send requests to nodes that then proxy that request on on behalf of the sender. Definitely an issue to weigh the security implications vs. the NAT traversal ease. (we've actually done a tech report at W&M that addresses the tradeoffs of recursive vs. iterative as one section, it is available here: http://www.cs.wm.edu/~lowekamp/papers/wm-cs-2006-03.pdf) --David On 6/18/06, Cullen Jennings wrote: > > It's clear that the NAT issues do change how you might desire the DHT > (or something similar) to deal with routing. If you pick something > without considering NAT, I suspect it will be very hard to move it to > NAT later. Because of this, I felt we wanted to have the NAT > requirement in scope in the charter. It's clear that something like a > iterative routed chord could probably work with NATs but not clear > that is the best. Iterative routing has more problems from a security > point of view than recursive routing because it is easier to reroute > large parts of they namespace. I don't think we need to choose a > solution to get to the point we have a charter but I do think this is > part of the problem I want to deal with. > > Cullen > > > On Jun 16, 2006, at 9:49 AM, Enrico Marocco wrote: > > > Philip Matthews wrote: > >> 2) Maintaining connections behind NATs does require a bit of work > >> when the > >> connection runs over UDP, especially if the peer is also > >> wireless. > >> However, it is easier when the connection runs > >> over TCP. If our finger table connections run over TCP, then > >> the effort of > >> maintaining 20 of them may be equal to the effort required to > >> maintain > >> a single voice connection over UDP. > > > > The problem for a node behind a NAT is not maintaining connection with > > its fingers; instead, what is really difficult is being reachable from > > any peer. Unfortunately chord requires the latter. > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From philip_matthews at magma.ca Mon Jun 19 17:01:34 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Mon, 19 Jun 2006 17:01:34 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <01f001c691be$adf81bd0$6400a8c0@comcast.net> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com><44761920.7030403@research.panasonic.com><4476D80E.7070100@telecomitalia.it><4477341C.5000107@research.panasonic.com><447C2532.7010805@telecomitalia.it><447C76DE.8070303@research.panasonic.com><447C8368.2070104@sipstation.com><447DBF51.8030803@research.panasonic.com><0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca><4492E121.7050809@telecomitalia.it> <01f001c691be$adf81bd0$6400a8c0@comcast.net> Message-ID: On 16-Jun-06, at 23:32 , Peter Pan wrote: >> Not true. If peers forward requests on to other peer, a individual >> peer only >> has to have connections to a very small subset of the entire peer >> population. >> >> In other words, say peer A wants to reach peer Z. Say A does not have >> a direct >> connection to Z, but does have a direct connection to (say) B and C. >> It picks >> the one that is closest to Z (say C), and forwards its message (say a >> SIP INVITE) >> to C. Peer C then looks at its finger table and discovers that it, >> too, does not have >> a direct connection to Z, but has a connection to D which is closer. >> So C forwards >> the message to D. And so on. >> >> - Philip > > Will response traverse the same forwarding path (Z=>D=>C=>A)? > > If yes, this heuristic can leave uncertain number of outstanding > call legs > (and possibly loops) along the path. > > If no, Z's response sometime cannot penetrate A's NAT. > > Is it more decisive for A to first GET Z's location(s) and then > shot the > request directly to Z? > We envision that the request and the response would be routed separately through the network. So the response might go Z => R => Q => A. This would be because C => A might be a short hop, but in the return path, Z tries to cover as much of the distance back to A on the first hop as it can, hence the Z => R hop. [All this would probably be much more understandable if we were standing in front of a whiteboard ...] - Philip From fluffy at cisco.com Mon Jun 19 20:28:17 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 19 Jun 2006 17:28:17 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <8b2769930606181744i3da9183dj3c6c99b184c379c2@mail.gmail.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <447C76DE.8070303@research.panasonic.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> <9D38CC2D-961B-4BBE-9A11-87300361354C@cisco.com> <8b2769930606181744i3da9183dj3c6c99b184c379c2@mail.gmail.com> Message-ID: <7A0593BD-8958-4C89-B3A4-BB6685B0DBB3@cisco.com> Good point - I guese what I really should say is it is clear there are interactions between the NAT traversal properties and security properties of any given method and I'm not clear what the interaction and trade offs are. I would suspect that we might want to scope this into the work that a WG was going to look at. On Jun 18, 2006, at 5:44 PM, David A. Bryan wrote: > Hmmm...I think you might have iterative and recursive mixed up here, > unless I'm missing something. Recursive (think proxy server) would be > good for NAT punching, since you only need to keep connections to your > fingers and nothing else. Iterative (think redirect server) on the > other hand will require arbitrary punching. > > In addition to the point you made, on the security side, although the > recursive mechanisms may gain you in firewall traversal, they can also > be a DoS magnifier (or at least obfuscator) since you can send > requests to nodes that then proxy that request on on behalf of the > sender. Definitely an issue to weigh the security implications vs. the > NAT traversal ease. (we've actually done a tech report at W&M that > addresses the tradeoffs of recursive vs. iterative as one section, it > is available here: > http://www.cs.wm.edu/~lowekamp/papers/wm-cs-2006-03.pdf) > > --David > > On 6/18/06, Cullen Jennings wrote: >> >> It's clear that the NAT issues do change how you might desire the DHT >> (or something similar) to deal with routing. If you pick something >> without considering NAT, I suspect it will be very hard to move it to >> NAT later. Because of this, I felt we wanted to have the NAT >> requirement in scope in the charter. It's clear that something like a >> iterative routed chord could probably work with NATs but not clear >> that is the best. Iterative routing has more problems from a security >> point of view than recursive routing because it is easier to reroute >> large parts of they namespace. I don't think we need to choose a >> solution to get to the point we have a charter but I do think this is >> part of the problem I want to deal with. >> >> Cullen >> >> >> On Jun 16, 2006, at 9:49 AM, Enrico Marocco wrote: >> >> > Philip Matthews wrote: >> >> 2) Maintaining connections behind NATs does require a bit of work >> >> when the >> >> connection runs over UDP, especially if the peer is also >> >> wireless. >> >> However, it is easier when the connection runs >> >> over TCP. If our finger table connections run over TCP, then >> >> the effort of >> >> maintaining 20 of them may be equal to the effort required to >> >> maintain >> >> a single voice connection over UDP. >> > >> > The problem for a node behind a NAT is not maintaining >> connection with >> > its fingers; instead, what is really difficult is being >> reachable from >> > any peer. Unfortunately chord requires the latter. >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> From bryan at ethernot.org Tue Jun 20 10:11:09 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 20 Jun 2006 10:11:09 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <7A0593BD-8958-4C89-B3A4-BB6685B0DBB3@cisco.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> <9D38CC2D-961B-4BBE-9A11-87300361354C@cisco.com> <8b2769930606181744i3da9183dj3c6c99b184c379c2@mail.gmail.com> <7A0593BD-8958-4C89-B3A4-BB6685B0DBB3@cisco.com> Message-ID: <8b2769930606200711u4f16b2f0q77936c5f25bf4b76@mail.gmail.com> Fully agree. This particular issue proves the broader point -- we *must* address security and NAT traversal from day one or it simply won't work. If there is a WG formed here, ensuring both are included (while allowing for systems such as ad-hoc that don't need as strong of a level of these features to not be unduely burdened) should be a must. David On 6/19/06, Cullen Jennings wrote: > Good point - I guese what I really should say is it is clear there > are interactions between the NAT traversal properties and security > properties of any given method and I'm not clear what the interaction > and trade offs are. I would suspect that we might want to scope this > into the work that a WG was going to look at. > > > On Jun 18, 2006, at 5:44 PM, David A. Bryan wrote: > > > Hmmm...I think you might have iterative and recursive mixed up here, > > unless I'm missing something. Recursive (think proxy server) would be > > good for NAT punching, since you only need to keep connections to your > > fingers and nothing else. Iterative (think redirect server) on the > > other hand will require arbitrary punching. > > > > In addition to the point you made, on the security side, although the > > recursive mechanisms may gain you in firewall traversal, they can also > > be a DoS magnifier (or at least obfuscator) since you can send > > requests to nodes that then proxy that request on on behalf of the > > sender. Definitely an issue to weigh the security implications vs. the > > NAT traversal ease. (we've actually done a tech report at W&M that > > addresses the tradeoffs of recursive vs. iterative as one section, it > > is available here: > > http://www.cs.wm.edu/~lowekamp/papers/wm-cs-2006-03.pdf) > > > > --David > > > > On 6/18/06, Cullen Jennings wrote: > >> > >> It's clear that the NAT issues do change how you might desire the DHT > >> (or something similar) to deal with routing. If you pick something > >> without considering NAT, I suspect it will be very hard to move it to > >> NAT later. Because of this, I felt we wanted to have the NAT > >> requirement in scope in the charter. It's clear that something like a > >> iterative routed chord could probably work with NATs but not clear > >> that is the best. Iterative routing has more problems from a security > >> point of view than recursive routing because it is easier to reroute > >> large parts of they namespace. I don't think we need to choose a > >> solution to get to the point we have a charter but I do think this is > >> part of the problem I want to deal with. > >> > >> Cullen > >> > >> > >> On Jun 16, 2006, at 9:49 AM, Enrico Marocco wrote: > >> > >> > Philip Matthews wrote: > >> >> 2) Maintaining connections behind NATs does require a bit of work > >> >> when the > >> >> connection runs over UDP, especially if the peer is also > >> >> wireless. > >> >> However, it is easier when the connection runs > >> >> over TCP. If our finger table connections run over TCP, then > >> >> the effort of > >> >> maintaining 20 of them may be equal to the effort required to > >> >> maintain > >> >> a single voice connection over UDP. > >> > > >> > The problem for a node behind a NAT is not maintaining > >> connection with > >> > its fingers; instead, what is really difficult is being > >> reachable from > >> > any peer. Unfortunately chord requires the latter. > >> _______________________________________________ > >> p2p-sip mailing list > >> p2p-sip at cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >> > From philip_matthews at magma.ca Tue Jun 20 11:55:50 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 20 Jun 2006 11:55:50 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <8b2769930606200711u4f16b2f0q77936c5f25bf4b76@mail.gmail.com> References: <00d501c6803b$3e694530$640fa8c0@cis.neustar.com> <447C8368.2070104@sipstation.com> <447DBF51.8030803@research.panasonic.com> <0B9365F5-99F4-4FF8-86B5-B49798395F69@magma.ca> <4492E121.7050809@telecomitalia.it> <9D38CC2D-961B-4BBE-9A11-87300361354C@cisco.com> <8b2769930606181744i3da9183dj3c6c99b184c379c2@mail.gmail.com> <7A0593BD-8958-4C89-B3A4-BB6685B0DBB3@cisco.com> <8b2769930606200711u4f16b2f0q77936c5f25bf4b76@mail.gmail.com> Message-ID: I also fully support looking at security and NAT traversal issues from day one. Neither of these are things that can easily be added later. - Philip On 20-Jun-06, at 10:11 , David A. Bryan wrote: > Fully agree. This particular issue proves the broader point -- we > *must* address security and NAT traversal from day one or it simply > won't work. If there is a WG formed here, ensuring both are included > (while allowing for systems such as ad-hoc that don't need as strong > of a level of these features to not be unduely burdened) should be a > must. > > David > > On 6/19/06, Cullen Jennings wrote: >> Good point - I guese what I really should say is it is clear there >> are interactions between the NAT traversal properties and security >> properties of any given method and I'm not clear what the interaction >> and trade offs are. I would suspect that we might want to scope this >> into the work that a WG was going to look at. >> >> >> On Jun 18, 2006, at 5:44 PM, David A. Bryan wrote: >> >>> Hmmm...I think you might have iterative and recursive mixed up here, >>> unless I'm missing something. Recursive (think proxy server) >>> would be >>> good for NAT punching, since you only need to keep connections to >>> your >>> fingers and nothing else. Iterative (think redirect server) on the >>> other hand will require arbitrary punching. >>> >>> In addition to the point you made, on the security side, although >>> the >>> recursive mechanisms may gain you in firewall traversal, they can >>> also >>> be a DoS magnifier (or at least obfuscator) since you can send >>> requests to nodes that then proxy that request on on behalf of the >>> sender. Definitely an issue to weigh the security implications >>> vs. the >>> NAT traversal ease. (we've actually done a tech report at W&M that >>> addresses the tradeoffs of recursive vs. iterative as one >>> section, it >>> is available here: >>> http://www.cs.wm.edu/~lowekamp/papers/wm-cs-2006-03.pdf) >>> >>> --David >>> >>> On 6/18/06, Cullen Jennings wrote: >>>> >>>> It's clear that the NAT issues do change how you might desire >>>> the DHT >>>> (or something similar) to deal with routing. If you pick something >>>> without considering NAT, I suspect it will be very hard to move >>>> it to >>>> NAT later. Because of this, I felt we wanted to have the NAT >>>> requirement in scope in the charter. It's clear that something >>>> like a >>>> iterative routed chord could probably work with NATs but not clear >>>> that is the best. Iterative routing has more problems from a >>>> security >>>> point of view than recursive routing because it is easier to >>>> reroute >>>> large parts of they namespace. I don't think we need to choose a >>>> solution to get to the point we have a charter but I do think >>>> this is >>>> part of the problem I want to deal with. >>>> >>>> Cullen >>>> >>>> >>>> On Jun 16, 2006, at 9:49 AM, Enrico Marocco wrote: >>>> >>>>> Philip Matthews wrote: >>>>>> 2) Maintaining connections behind NATs does require a bit of work >>>>>> when the >>>>>> connection runs over UDP, especially if the peer is also >>>>>> wireless. >>>>>> However, it is easier when the connection runs >>>>>> over TCP. If our finger table connections run over TCP, >>>>>> then >>>>>> the effort of >>>>>> maintaining 20 of them may be equal to the effort >>>>>> required to >>>>>> maintain >>>>>> a single voice connection over UDP. >>>>> >>>>> The problem for a node behind a NAT is not maintaining >>>> connection with >>>>> its fingers; instead, what is really difficult is being >>>> reachable from >>>>> any peer. Unfortunately chord requires the latter. >>>> _______________________________________________ >>>> 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 philip_matthews at magma.ca Tue Jun 20 21:33:46 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 20 Jun 2006 21:33:46 -0400 Subject: [p2p-sip] What are we doing, question 2 In-Reply-To: <200606052236.k55MWfX5018358@cs.columbia.edu> References: <200606052236.k55MWfX5018358@cs.columbia.edu> Message-ID: On 5-Jun-06, at 18:32 , David Barrett wrote: > Again, I love the idea of having a single "sip:" address that "just > works" > for both CS and P2P SIP. Please help me understand your proposal > better. > > Will I be able to print my combined CS/P2P SIP address on a > business card, > hand it to you, and have you type it into your SIP UA and get an > expected > result (a valid connection, if it's P2PSIP aware, or a message saying > "unsupported address type" if not)? If so, what might that address > look > like? > David: Here are two ways in which I see that this might work: 1) I happen to work for Avaya. If the entire Avaya phone system was converted to P2PSIP technology, then one or more of the peers could be elected to register themselves in DNS as proxy servers for resolving addresses of the form "sip:xxx at avaya.com". When they received an Invite, they could use PIPSIP mechanisms to resolve an AOR of the form "xxx at avaya.com" into a specific contact URI, and then forward the INVITE to that phone. In other words, those peers are acting as gateways between the internal Avaya network (assumed here to be a P2PSIP network) and the global CS- SIP network. 2) Say I got together with some friends to form a P2PSIP network, and say that we all had SIP AORs of the form xxx at ourprovider.com. Then our little P2PSIP network could elect one or more peers to register all of our AORs with the Registrar of ourprovider.com Then an incoming call from the outside world to me would first come to the Registrar of myprovider.com (a classic CS Registrar), be forwarded to one of peers in our little P2PSIP network, and finally get forwarded to me. Of course, you are probably saying "what if my friends use different service providers -- then what?" In this case, I think your P2PSIP network can be used for internal calls between peers, but each of the UAs in the network must separately register with the Registrar for its own domain. That is, each UA acts both as a P2PSIP UA and a CS- SIP UA. Phone calls to other peers go through the P2PSIP network, but phone calls to/from the outside do not. If you and I have joined the same P2PSIP network, and (1) and (2) do not apply, then can I call you using dbarrett at quinthar.com and have it go through the P2PSIP network? That is a good question. I believe Henning and his students have investigated this a bit, but I am not up on the details. - Philip From philip_matthews at magma.ca Tue Jun 20 17:50:45 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 20 Jun 2006 17:50:45 -0400 Subject: [p2p-sip] work items we agreed on and not agreed on In-Reply-To: <003f01c69042$a3dc1a70$6400a8c0@comcast.net> References: <62D92A9A02BCC845B202323D49A48426230E20@0591-ITS-EXMP02.us.saic.com> <003f01c69042$a3dc1a70$6400a8c0@comcast.net> Message-ID: Sorry to be slow in replying. See below... On 15-Jun-06, at 02:12 , Peter Pan wrote: > >> - We should do it but postpone it after v1.0. (A variation of >> this position suggests that, for v1.0, we assume multicast/broadcast >> among Peers.) > > [pp]: Avaya and eBay cannot be happier with this option :) > Well, I have not consulted with my fellow Avaya employees on this, but I, for one, would like to see the peer-to-peer protocol standardized as part of the initial charter. - Philip From fluffy at cisco.com Mon Jun 26 13:04:34 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Mon, 26 Jun 2006 10:04:34 -0700 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <014101c69196$94111ff0$6400a8c0@comcast.net> References: <010c01c69172$9c0d1480$0202fea9@matthewdesk><33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> <8b2769930606161533r226d6be7te59a18da387f8b5b@mail.gmail.com> <014101c69196$94111ff0$6400a8c0@comcast.net> Message-ID: <13EF7304-C1D3-45F8-BDA9-B14D803517D8@cisco.com> On Jun 16, 2006, at 3:45 PM, Peter Pan wrote: > In worse case, AOR search can be achieved by flooding. Who will > feel and > mind it? Peter, I don't understand your question - if it already got answered or was not a question, then there is no need to reply. If there was a key question that needed to be answered here, try and explain a bit more because I did not understand. Thanks, Cullen From huang-ming.pan at comcast.net Mon Jun 26 16:07:51 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 26 Jun 2006 13:07:51 -0700 Subject: [p2p-sip] What are we doing - question 1 References: <010c01c69172$9c0d1480$0202fea9@matthewdesk><33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> <8b2769930606161533r226d6be7te59a18da387f8b5b@mail.gmail.com> <014101c69196$94111ff0$6400a8c0@comcast.net> <13EF7304-C1D3-45F8-BDA9-B14D803517D8@cisco.com> Message-ID: <000901c6995c$3571cfd0$030aa8c0@comcast.net> > > > In worse case, AOR search can be achieved by flooding. Who will > > feel and > > mind it? > > Peter, I don't understand your question - if it already got answered > or was not a question, then there is no need to reply. If there was a > key question that needed to be answered here, try and explain a bit > more because I did not understand. > > Thanks, Cullen Thanks for the asking. "AOR search" is typo; it should be "name search". Skype might use flooding search as well. You can see a green neon running above for quite some time after you initiate a name search, in the meanwhile discrete replies in udp packets arrive continuously for several seconds. (Search results from central servers usually come in batches and all in once) Unless you use sniffer to see the flooding, you can hardly feel it. Peter From gregd at research.panasonic.com Mon Jun 26 17:04:10 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Mon, 26 Jun 2006 17:04:10 -0400 Subject: [p2p-sip] What are we doing - question 1 In-Reply-To: <000901c6995c$3571cfd0$030aa8c0@comcast.net> References: <010c01c69172$9c0d1480$0202fea9@matthewdesk><33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> <8b2769930606161533r226d6be7te59a18da387f8b5b@mail.gmail.com> <014101c69196$94111ff0$6400a8c0@comcast.net> <13EF7304-C1D3-45F8-BDA9-B14D803517D8@cisco.com> <000901c6995c$3571cfd0$030aa8c0@comcast.net> Message-ID: <44A04BCA.3080504@research.panasonic.com> Hi Peter, Peter Pan wrote: >>> In worse case, AOR search can be achieved by flooding. Who will >>> feel and >>> mind it? >> Peter, I don't understand your question - if it already got answered >> or was not a question, then there is no need to reply. If there was a >> key question that needed to be answered here, try and explain a bit >> more because I did not understand. >> >> Thanks, Cullen > > Thanks for the asking. "AOR search" is typo; it should be "name search". > > Skype might use flooding search as well. You can see a green neon running > above for quite some time after you initiate a name search, in the meanwhile > discrete replies in udp packets arrive continuously for several seconds. > (Search results from central servers usually come in batches and all in > once) Unless you use sniffer to see the flooding, you can hardly feel it. I actually think that searches of any sort are out-of-scope. Perhaps there would be guidance available on such mechanisms from IRTF, but the scope of the WG should be drilled down tight, so we can make progress. It's an important application, but not one which needs to be available for P2P-SIP on day one. Greg. From huang-ming.pan at comcast.net Mon Jun 26 17:24:36 2006 From: huang-ming.pan at comcast.net (Peter Pan) Date: Mon, 26 Jun 2006 14:24:36 -0700 Subject: [p2p-sip] What are we doing - question 1 References: <010c01c69172$9c0d1480$0202fea9@matthewdesk><33B03266-9EED-4480-9D72-F42BA9B814A0@magma.ca> <8b2769930606161533r226d6be7te59a18da387f8b5b@mail.gmail.com> <014101c69196$94111ff0$6400a8c0@comcast.net> <13EF7304-C1D3-45F8-BDA9-B14D803517D8@cisco.com> <000901c6995c$3571cfd0$030aa8c0@comcast.net> <44A04BCA.3080504@research.panasonic.com> Message-ID: <001a01c69966$ed11d2c0$030aa8c0@comcast.net> Hi, Greg. Totally agreed. This is why I mention-ed the bottom line, flooding search, after someone earlier in the thread seemed worrying about name search in DHT. Peter ----- Original Message ----- From: "Greg Daley" To: "Peter Pan" Cc: "Cullen Jennings" ; "P2P-SIP" ; "David A. Bryan" Sent: Monday, June 26, 2006 2:04 PM Subject: Re: [p2p-sip] What are we doing - question 1 > Hi Peter, > > Peter Pan wrote: > >>> In worse case, AOR search can be achieved by flooding. Who will > >>> feel and > >>> mind it? > >> Peter, I don't understand your question - if it already got answered > >> or was not a question, then there is no need to reply. If there was a > >> key question that needed to be answered here, try and explain a bit > >> more because I did not understand. > >> > >> Thanks, Cullen > > > > Thanks for the asking. "AOR search" is typo; it should be "name search". > > > > Skype might use flooding search as well. You can see a green neon running > > above for quite some time after you initiate a name search, in the meanwhile > > discrete replies in udp packets arrive continuously for several seconds. > > (Search results from central servers usually come in batches and all in > > once) Unless you use sniffer to see the flooding, you can hardly feel it. > > I actually think that searches of any sort are out-of-scope. > Perhaps there would be guidance available on such mechanisms > from IRTF, but the scope of the WG should be drilled down tight, > so we can make progress. > > It's an important application, but not one which needs to be > available for P2P-SIP on day one. > > Greg. From enrico.marocco at telecomitalia.it Thu Jun 29 11:12:28 2006 From: enrico.marocco at telecomitalia.it (Enrico Marocco) Date: Thu, 29 Jun 2006 17:12:28 +0200 Subject: [p2p-sip] [Fwd: [Sipping] Ad hoc meeting on P2PSIP] Message-ID: <44A3EDDC.20509@telecomitalia.it> Just to let you know. The early bird registration cutoff for the IETF meeting is tomorrow at noon ;-) Enrico -------- Original Message -------- Subject: [Sipping] Ad hoc meeting on P2PSIP Date: Thu, 29 Jun 2006 17:07:13 +0300 From: Gonzalo Camarillo To: sipping CC: Mary Barnes Folks, we do not know where or when yet, but we intend to organize an ad hoc meeting, which will be sponsored by the SIPPING WG, on peer-to-peer SIP during the Montreal meeting. We will let you know as soon as we get a time slot and a meeting room for this meeting. Cheers, Gonzalo SIPPING co-chair _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors at cs.columbia.edu for questions on current sip Use sip at ietf.org for new developments of core SIP From eunsoo at research.panasonic.com Thu Jun 29 12:15:18 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Thu, 29 Jun 2006 12:15:18 -0400 Subject: [p2p-sip] [Fwd: [Sipping] Ad hoc meeting on P2PSIP] In-Reply-To: <44A3EDDC.20509@telecomitalia.it> References: <44A3EDDC.20509@telecomitalia.it> Message-ID: <44A3FC96.9040700@research.panasonic.com> Since the date and time of the P2PSIP ad-hoc meeting is not set yet, I'd like to encourage folks who want to attend the meeting to keep the Friday afternoon (July 14) open for it. Thanks. Eunsoo Enrico Marocco wrote: >Just to let you know. > >The early bird registration cutoff for the IETF meeting is tomorrow at >noon ;-) > >Enrico > >-------- Original Message -------- >Subject: [Sipping] Ad hoc meeting on P2PSIP >Date: Thu, 29 Jun 2006 17:07:13 +0300 >From: Gonzalo Camarillo >To: sipping >CC: Mary Barnes > >Folks, > >we do not know where or when yet, but we intend to organize an ad hoc >meeting, which will be sponsored by the SIPPING WG, on peer-to-peer SIP >during the Montreal meeting. We will let you know as soon as we get a >time slot and a meeting room for this meeting. > >Cheers, > >Gonzalo >SIPPING co-chair > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors at cs.columbia.edu for questions on current sip >Use sip at ietf.org for new developments of core SIP >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From sgurminder at gmail.com Thu Jun 29 15:25:04 2006 From: sgurminder at gmail.com (Gurminder) Date: Fri, 30 Jun 2006 00:55:04 +0530 Subject: [p2p-sip] sip in ad-hoc n/ws Message-ID: Hi, I am working on an application which requires decentralised sip. Actually it is, providing VoIP services in Ad-hoc n/ws as in Disaster scenario, also I have seen this objective in one of slides of David, Bruce and Ensuoo. Before knowing about this p2p-sip project, we tried a design for this kind of application. Scenario is wireless mobile Ad-hoc n/ws using 802.11 b #To communicate to each other all nodes need to have unique IP, (thought of using Duplicate Address Detection) #Routing of messages will be done using AODV, so all should support it, #Each node should broadcast its presence to all others in network. Issues: * How to do DAD? * Does node need proxy services? As such there can be no centralised proxy server so every node will have a proxy server on it, So job of proxy server will be to perform lookups (in my view). Work Done: Tested voice call using Sip on multihop mobile n/w using AODV. So please tell me how this objective can be achieved or any other better design or idea for such application. Waiting for all of your valuable suggestions Gurminder Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060629/ea282325/attachment.html From gregd at research.panasonic.com Fri Jun 30 12:38:17 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Fri, 30 Jun 2006 12:38:17 -0400 Subject: [p2p-sip] sip in ad-hoc n/ws In-Reply-To: References: Message-ID: <44A55379.2050405@research.panasonic.com> Hi Gurminder, The issues of Adhoc network deployment and application/session layer SIP deployment are logically separate. The DAD/Address configuration operations you mention are required for every application, not just SIP. It may be that in general on the Internet, additional configuration may be passed along with address configuration, as in DHCP, but this is not strictly a function of networking or addressing configuration. So we should probably not assume analogous operations exist in Ad-hoc networks. And we had better not rely on anything like them for P2P-SIP networks. All P2P-SIP needs is addressing and packet carriage services, like other applications. Its in no way relies on special properties of the Ad-hoc network. Let's not conflate Ad-hoc and P2P-SIP concepts at this formative stage. It's an interesting application domain, but should have no bearing on the protocols. Greg Gurminder wrote: > Hi, > I am working on an application which requires decentralised > sip. Actually it is, providing VoIP services in Ad-hoc n/ws as in > Disaster scenario, also I have seen this objective in one of slides of > David, Bruce and Ensuoo. > > Before knowing about this p2p-sip project, we tried a design for this > kind of application. > > Scenario is wireless mobile Ad-hoc n/ws using 802.11 b > > #To communicate to each other all nodes need to have unique IP, (thought > of using Duplicate Address Detection) > #Routing of messages will be done using AODV, so all should support it, > #Each node should broadcast its presence to all others in network. > > Issues: > * How to do DAD? > * Does node need proxy services? > As such there can be no centralised proxy server so every node will have > a proxy server on it, > So job of proxy server will be to perform lookups (in my view). > > Work Done: > Tested voice call using Sip on multihop mobile n/w using AODV. > > So please tell me how this objective can be achieved or any other better > design or idea for such application. > > Waiting for all of your valuable suggestions > Gurminder Singh > > > ------------------------------------------------------------------------ > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From adamfisk at gmail.com Fri Jun 30 23:53:52 2006 From: adamfisk at gmail.com (Adam Fisk) Date: Fri, 30 Jun 2006 23:53:52 -0400 Subject: [p2p-sip] STUN (rfc3489) In-Reply-To: <01ef01c68e6d$78e46010$6400a8c0@comcast.net> References: <00a901c68e45$0e145920$6400a8c0@comcast.net> <9D8BFA67-C0A4-4349-8164-617109E9C456@cisco.com> <01ef01c68e6d$78e46010$6400a8c0@comcast.net> Message-ID: My understanding is that those terms for NATs have been deemed inadequate for describing NAT behavior in the field. I'm not up to speed on latest STUN drafts, but I believe Cullen's link gives the appropriate descriptions of the newer, more accurate NAT classifications. -Adam On 6/12/06, Peter Pan wrote: > > > > On Jun 12, 2006, at 10:24 AM, Peter Pan wrote: > > > > > Is it possible to realize a STUN sever defined by > > > draft-ietf-behave-rfc3489bis-03 on a host with ONLY ONE IP that can > > > discover > > > the NAT type before a STUN client? > > > > I have no idea what you mean by NAT type but if what you mean is the > > classification in RFC 3489, then NO. If what you mean is enough to > > detect connectivity such as used by ICE, then YES. > > By NAT type I meant those terms such as "full-cone", "ip-restricted", > "port-restricted" and "symmetric" that seem widely used in voip industry. > (http://www.voip-info.org/wiki-STUN, or > http://en.wikipedia.org/wiki/Symmetric_NAT) > > Never mind it. Sounds like P2PSIP no more needs that info. > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060630/e4df3f35/attachment-0001.html