From karstbj at yahoo.com Wed Feb 1 02:44:26 2006 From: karstbj at yahoo.com (Karst Bjorgson) Date: Tue, 31 Jan 2006 23:44:26 -0800 (PST) Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> Message-ID: <20060201074426.68978.qmail@web53006.mail.yahoo.com> > 3. Some elements of each peer association group MAY > be rooted in the > DNS such that they can be used for bootstrapping > operations. > However, a peer association group that is > operating entirely in an > isolated (or disconnected, or autonomous) mode > will rely on > alternate means of bootstrapping the peer > association group based > on the "zeroconf" work. Isn't the reference to the "zeroconf" working group a bit problematic? The group is flagged on the IETF web page as "concluded". Its only result was the publication of RFC 3927 (rfc3927) - Dynamic Configuration of IPv4 Link-Local Addresses. While useful, link local addresses are certainly not sufficient for "bootstrapping peer association". The quick fix is probably to just say "... rely on alternate means of bootstrapping the peer association group." (i.e. remove the mention of zeroconf.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jose at netlab.hut.fi Wed Feb 1 02:49:27 2006 From: jose at netlab.hut.fi (jose@netlab.hut.fi) Date: Wed, 1 Feb 2006 09:49:27 +0200 Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> References: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> Message-ID: <1138780167.43e06807e6c97@www.netlab.hut.fi> Hi David, The proposal looks pretty good. Rgds Jose > I've inlined a newer version of the charter draft (minor changes) > > Changes are adding the wording below about evaluating NAT > solutions/forwarding to other groups, changing slightly some wording > in the very last sentence of the first paragraph of the description > (the part about this being an alternative to the conventional > approach), and re-wording the first bullet in what is excluded (used > to say locating users for SIP, now says locating users for SIP-based > communications, since some folks were worried that didn't cover doing > presence/IM with the located resources, which we will likely want as > well as media calls). > > No other changes. > > I hope this incorporated many (most?) of the suggestions we seemed to > have reached consensus on. > > --David Bryan > > ------ > > > Peer-to-Peer Session Initiation Protocol (P2PSIP) > > Chairs: > TBD > > RAI Area Director(s): > TBD > > RAI Area Advisor: > Allison Mankin > > Mailing Lists: > General Discussion: p2p-sip at cs.columbia.edu > Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ > > Description of the Working Group > > The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol > working group (P2PSIP WG) is to develop guidelines and mechanisms for > the use of the Session Initiation Protocol (SIP) in settings where > establishing and managing sessions is either partially or entirely > handled by a collection of endpoints (peers) rather than centralized > servers. This is an alternative to the conventional SIP approach which > relies on service provider hosted proxies to which users get assigned > by out-of-band means, usually based on geography, association, or > business reasons. > > This is motivated by scenarios where a reduction in cost of equipment > and operation for non-end users is desired, and in situations where > such servers are not available. Some of the scenarios identified > include: > > 1. Self-organizing and highly available proxy farms, as opposed to the > fixed hierarchy of IMS-like systems. > > 2. Disconnected or partly-connected topologies with ephemeral > relationships such as small office systems (with little or no > central equipment), mesh networks, emergency response, and > battlelfield environments. > > 3. Recovery functions to allow endpoints to communicate in the event a > central server fails or the endpoints are isolated by a network > partitioning event. > > The working group starts with the following general assumptions: > > 1. Peer associations groups, which may be called "P2P networks". 'P2P > overlays", or "P2P federations" will provide namespaces within > which P2P-SIP resources are identified. These namespaces are > bounded by the identifier(s) of the peer association group, which > generally map to domain-level identifiers in the DNS. > > 2. Session establishment, capabilities negotiation, session > termination, subscription, notification, messaging, and related > functions traditionally performed using SIP will continue to be > performed using SIP. This working group is interested only in the > mechanisms for locating resources within peer association > groups. We generally refer to this as the "rendezvous problem". > > 3. Some elements of each peer association group MAY be rooted in the > DNS such that they can be used for bootstrapping operations. > However, a peer association group that is operating entirely in an > isolated (or disconnected, or autonomous) mode will rely on > alternate means of bootstrapping the peer association group based > on the "zeroconf" work. > > 4. Interactions between peer association groups (or members thereof) > and other peer association groups or conventional SIP installations > will be resolved using the resource location model of RFC 3263: > "Locating SIP Servers". > > 5. The level of authenticity of identity will vary by the peer > association group. However, the working group will define at least > one mechanism that will provide assertion of identity having > strength equivalent to that provided by the "SIP Identity > Mechanism" RFC, perhaps by reusing some or all of the mechanism of > that RFC. > > Specifically, the working group will: > > 1. Document scenarios in which a P2P architecture is appropriate for > SIP based solutions ("use-cases" document). > > 2. Develop a general architecture or framework for P2P-based SIP > applications. This will require evaluating the existing deployed > and proposed P2P-based SIP solutions for possible incorporation > into this work. > > 3. Define a distributed location mechanism for locating users in the > absence of a central server, including the protocols and algorithms > needed do establish, maintain, and query the distributed > information. > > 4. If SIP extensions are needed to support the peer-to-peer model, > define requirements for those extensions to be acted on by the SIP > working group. > > 5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate > them into the P2P SIP architecture or framework. If necessary, > define requirements for enhancements of existing techniques to be > acted on by other working groups. > > While ensuring: > > 1. Security is addressed in these systems. > > 2. Interoperability with existing client-server (CS) SIP and the PSTN. > > 3. The solutions proposed will function even with some or many nodes > located behind NATs or firewalls. > > 4. Existing protocols are reused whenever possible. > > The following topics are initially out of the Working Group's scope, > but may be considered in possible future charters: > > 1. Using P2P mechanisms to manage groups of distributed media relays. > > 2. Using distributed relays to enable anonymous communications. > > 3. Creating distributed voice mail systems. > > 4. Performing distributed search for users based on something other > than user id. > > The following topics are explicitly excluded from the Working Group's > scope: > > 1. Issues specific to applications other than locating users and > resources for the full range of SIP-based communications offered > in a conventional client-server SIP system, including but not > limited to real-time media, messaging, and presence. > > 2. Discussion of this technology as a replacement for conventional > (client-server) SIP. > > 3. Solving "research" type open questions related to P2P SIP. The > working group will instead forward such work to the IRTF. A few > such topics include: > o Fully distributed schemes for assuring unique user identities. > o Development of new structured P2P algorithms, such as DHTs. > o Developing a P2P-based replacements for DNS. > > The working group will operate in close cooperation with the SIP, > SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the > IRTF. Respecting the IETF specification change policy, the working > group will refer any possible changes or extensions as suggestions to > the appropriate WGs as needed. A guiding principal of the WG will be > to avoid extensions or change wherever possible. > > Goals and Milestones > Aug 2006 Submit use-cases document to the IESG (Informational) > Jan 2007 Submit architecture document to the IESG (Informational) > Jul 2007 Submit protocol and/or protocol extension documents to > the IESG (Standards-track) > > _______________________________________________ > 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 Feb 1 04:03:42 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Wed, 01 Feb 2006 01:03:42 -0800 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: <5EECA7C0-D917-4D0E-9E8C-D0362E1E01BB@softarmor.com> Message-ID: On 1/31/06 10:10 AM, "Dean Willis" wrote: > It is expected that the work of the P2P-SIP group may require > extensions to other IETF protocols, including SIP and its supporting > mechanisms for NAT traversal. When these requirements are identified > by the P2P-SIP group they will be communicated to the responsible > working group via the change process appropriate to that working > group or protocol. In most cases this communication will take the > form of an internet-draft outlining the problem, use cases, and > requirements to be met. > > How's that? I like something along the lines of that. Is there some specific issue that people forsee that this is not adequate to cover? If there is then we could think of how to deal with it. From dromasca at avaya.com Wed Feb 1 05:11:41 2006 From: dromasca at avaya.com (Romascanu, Dan (Dan)) Date: Wed, 1 Feb 2006 12:11:41 +0200 Subject: [p2p-sip] Revised Draft for possible WG charter Message-ID: > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Karst Bjorgson > Sent: Wednesday, February 01, 2006 9:44 AM > To: David A. Bryan; P2P-SIP > Subject: Re: [p2p-sip] Revised Draft for possible WG charter > > > 3. Some elements of each peer association group MAY be rooted in the > > DNS such that they can be used for bootstrapping operations. > > However, a peer association group that is operating > entirely in an > > isolated (or disconnected, or autonomous) mode will rely on > > alternate means of bootstrapping the peer association > group based > > on the "zeroconf" work. > > Isn't the reference to the "zeroconf" working group a bit > problematic? The group is flagged on the IETF web page as > "concluded". Its only result was the publication of RFC 3927 > (rfc3927) - Dynamic Configuration of IPv4 Link-Local > Addresses. While useful, link local addresses are certainly > not sufficient for "bootstrapping peer association". The > quick fix is probably to just say "... rely on alternate > means of bootstrapping the peer association group." (i.e. > remove the mention of zeroconf.) > I agree with this comment, 'zeroconf' should be at most mentioned as an example of 'means of bootstrapping' at most. Regards, Dan From eunsoo at research.panasonic.com Wed Feb 1 09:23:29 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 01 Feb 2006 09:23:29 -0500 Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: References: Message-ID: <43E0C461.2090103@research.panasonic.com> Romascanu, Dan (Dan) wrote: > > > > > >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Karst Bjorgson >>Sent: Wednesday, February 01, 2006 9:44 AM >>To: David A. Bryan; P2P-SIP >>Subject: Re: [p2p-sip] Revised Draft for possible WG charter >> >> >> >>>3. Some elements of each peer association group MAY be rooted in the >>> DNS such that they can be used for bootstrapping operations. >>> However, a peer association group that is operating >>> >>> >>entirely in an >> >> >>> isolated (or disconnected, or autonomous) mode will rely on >>> alternate means of bootstrapping the peer association >>> >>> >>group based >> >> >>> on the "zeroconf" work. >>> >>> >>Isn't the reference to the "zeroconf" working group a bit >>problematic? The group is flagged on the IETF web page as >>"concluded". Its only result was the publication of RFC 3927 >>(rfc3927) - Dynamic Configuration of IPv4 Link-Local >>Addresses. While useful, link local addresses are certainly >>not sufficient for "bootstrapping peer association". The >>quick fix is probably to just say "... rely on alternate >>means of bootstrapping the peer association group." (i.e. >>remove the mention of zeroconf.) >> >> >> > >I agree with this comment, 'zeroconf' should be at most mentioned as an >example of 'means of bootstrapping' at most. > > > I also agree to the above comment. It does not seem 'the zeroconf work' is broad enough. Regards, Eunsoo From dbarrett at quinthar.com Wed Feb 1 13:30:36 2006 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 1 Feb 2006 10:30:36 -0800 Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> Message-ID: <200602011834.k11IUn6i028461@cs.columbia.edu> I agree with the crowd, this draft looks great. The only nit I could pick: > -----Original Message----- > > While ensuring: > > 1. Security is addressed in these systems. Should we define security in this context? For example, does this include 'resistance to government monitoring' or 'compatibility with existing government monitoring systems' -- both of which fall under the umbrella of security depending on your viewpoint. I'm no security guru, but I'd toss out: "1. Interoperability with existing transport-level security infrastructures for encryption, tamper-resistance, and authentication." In other words, I'd suggest protection against traffic analysis, anonymous communications, or other really advanced (and research-centric) security topics be left out of scope. -david From dean.willis at softarmor.com Wed Feb 1 14:11:39 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 1 Feb 2006 13:11:39 -0600 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: <9A5DAB02-5EF7-4BCF-85C7-1D1F4DDAE1C5@magma.ca> References: <5EECA7C0-D917-4D0E-9E8C-D0362E1E01BB@softarmor.com> <9A5DAB02-5EF7-4BCF-85C7-1D1F4DDAE1C5@magma.ca> Message-ID: <85285E52-E77C-49A4-93C1-CAE687AFF599@softarmor.com> On Jan 31, 2006, at 12:40 PM, Philip Matthews wrote: > > How do you feel about the following? > > > NEW: > > The working group will operate in close cooperation with the SIP, > SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the > IRTF. It is expected that the work of the P2P-SIP group may require > extensions to other IETF protocols, including SIP and its supporting > mechanisms for NAT traversal. When these requirements are identified > by the P2P-SIP group they will be communicated to the responsible > working group via the change process appropriate to that working > group > or protocol. In most cases this communication will take the form > of an > internet-draft outlining the problem, use cases, and requirements > to b > met. A guiding principal of the WG will be to avoid extensions or > change > wherever possible. > This seems reasonable. -- Dean From dean.willis at softarmor.com Wed Feb 1 14:14:07 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 1 Feb 2006 13:14:07 -0600 Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: <20060201074426.68978.qmail@web53006.mail.yahoo.com> References: <20060201074426.68978.qmail@web53006.mail.yahoo.com> Message-ID: <2C62D287-3747-42B7-BFB9-E35AA43973D6@softarmor.com> On Feb 1, 2006, at 1:44 AM, Karst Bjorgson wrote: >> 3. Some elements of each peer association group MAY >> be rooted in the >> DNS such that they can be used for bootstrapping >> operations. >> However, a peer association group that is >> operating entirely in an >> isolated (or disconnected, or autonomous) mode >> will rely on >> alternate means of bootstrapping the peer >> association group based >> on the "zeroconf" work. > > Isn't the reference to the "zeroconf" working group a > bit problematic? The group is flagged on the IETF web > page as "concluded". Its only result was the > publication of RFC 3927 (rfc3927) - Dynamic > Configuration of IPv4 Link-Local Addresses. While > useful, link local addresses are certainly not > sufficient for "bootstrapping peer association". The > quick fix is probably to just say "... rely on > alternate means of bootstrapping the peer association > group." (i.e. remove the mention of zeroconf.) You've got a point. I was actually thinking "bonjour", but that's overly restrictive. -- Dean From sanghwan at cs.umn.edu Wed Feb 1 19:42:48 2006 From: sanghwan at cs.umn.edu (Sanghwan Lee) Date: Wed, 1 Feb 2006 18:42:48 -0600 (CST) Subject: [p2p-sip] running system? Message-ID: Hi, I'm new to this mailing list. I searched the archive, but I couldn't find the answer. Is there any running p2p sip system? If so, what is it like the system size now? Thanks. Sanghwan. From jtorrez at teksystems.com Thu Feb 9 11:47:29 2006 From: jtorrez at teksystems.com (Torrez, Joshua) Date: Thu, 9 Feb 2006 11:47:29 -0500 Subject: [p2p-sip] Would like to introduce myself Message-ID: <409DE63965C8B2499E0C4485A90496D002500AE4@AG00-EXMBX03.allegisgroup.com> My name is Joshua Torrez with TEKsystems, and I am a Professional IT Recruiter in Denver. I just wanted to provide my contact information as a resource for local and National opportunities to everybody. Currently I have a SIP engineer position in the Denver area. If anybody would be interested please feel free to contact me by phone or email. Respectfully, ________________________________ Joshua Torrez Technical Recruiter 6300 S. Syracuse Way, Ste. 200 800.786.6898 303.843.3760 F 303.694.7190 ________________________________ ____________________________________________________________________________________________________ This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic email or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply email so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060209/0a522ba6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1987 bytes Desc: image001.gif Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060209/0a522ba6/attachment.gif From slavitch at gmail.com Thu Feb 9 19:22:44 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 9 Feb 2006 19:22:44 -0500 Subject: [p2p-sip] P2PSIP WG Charter Message-ID: <1fc32c8f0602091622h36229e66k@mail.gmail.com> Hello folks; Just so that we can all be working on the same page can we have the current updated iteration of the proposed charter sent to this list? Regards Michael -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060209/d5abcf17/attachment.html From leonwang9999 at gmail.com Thu Feb 9 19:58:51 2006 From: leonwang9999 at gmail.com (leon wang) Date: Fri, 10 Feb 2006 08:58:51 +0800 Subject: [p2p-sip] p2p-sip Digest, Vol 7, Issue 4 In-Reply-To: References: Message-ID: <8786800c0602091658sa26951p@mail.gmail.com> Hi all I am leon wang I just make a p2p-voip tool prototype(base on DHT) named TStone in sourceforge.net. Now I get a voip and ivr position in beijing. 2006/2/10, p2p-sip-request at cs.columbia.edu : > > 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. Would like to introduce myself (Torrez, Joshua) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 9 Feb 2006 11:47:29 -0500 > From: "Torrez, Joshua" > Subject: [p2p-sip] Would like to introduce myself > To: > Message-ID: > < > 409DE63965C8B2499E0C4485A90496D002500AE4 at AG00-EXMBX03.allegisgroup.com> > > Content-Type: text/plain; charset="us-ascii" > > My name is Joshua Torrez with TEKsystems, and I am a Professional IT > Recruiter in Denver. I just wanted to provide my contact information as > a resource for local and National opportunities to everybody. > > Currently I have a SIP engineer position in the Denver area. > > If anybody would be interested please feel free to contact me by phone > or email. > > Respectfully, > > > > > > ________________________________ > > Joshua Torrez Technical Recruiter > > 6300 S. Syracuse Way, Ste. 200 > 800.786.6898 303.843.3760 > F 303.694.7190 > > > ________________________________ > > > > > > > ____________________________________________________________________________________________________ > This electronic mail (including any attachments) may contain information > that is privileged, confidential, and/or otherwise protected from disclosure > to anyone other than its intended recipient(s). Any dissemination or use of > this electronic email or its contents (including any attachments) by persons > other than the intended recipient(s) is strictly prohibited. If you have > received this message in error, please notify us immediately by reply email > so that we may correct our internal records. Please then delete the original > message (including any attachments) in its entirety. Thank you. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060209/0a522ba6/attachment-0001.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: image/gif > Size: 1987 bytes > Desc: image001.gif > Url : > https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060209/0a522ba6/attachment-0001.gif > > ------------------------------ > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > End of p2p-sip Digest, Vol 7, Issue 4 > ************************************* > -- Best Regards Leon Wang -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060209/d9d22abb/attachment.html From bryan at ethernot.org Thu Feb 9 22:23:32 2006 From: bryan at ethernot.org (David A. Bryan) Date: Thu, 9 Feb 2006 22:23:32 -0500 Subject: [p2p-sip] P2PSIP WG Charter In-Reply-To: <1fc32c8f0602091622h36229e66k@mail.gmail.com> References: <1fc32c8f0602091622h36229e66k@mail.gmail.com> Message-ID: <8b2769930602091923x1bbf8193jb5b9e10633440914@mail.gmail.com> I actually hadn't iterated it -- so far there were only a few new comments on the list that came for the last version, and I was waiting to see if there was anything else, but I'll go ahead and try to iterate and send out another revision tomorrow or Saturday. Obviously we'll also have a go at changing it in Dallas too. --David On 2/9/06, Michael Slavitch wrote: > Hello folks; > > Just so that we can all be working on the same page can we have the current > updated iteration of the proposed charter sent to this list? > > Regards > > Michael > > -- > Michael Slavitch > Ottawa, Ontario Canada > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From slavitch at gmail.com Fri Feb 10 09:10:16 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Fri, 10 Feb 2006 09:10:16 -0500 Subject: [p2p-sip] P2PSIP WG Charter In-Reply-To: <8b2769930602091923x1bbf8193jb5b9e10633440914@mail.gmail.com> References: <1fc32c8f0602091622h36229e66k@mail.gmail.com> <8b2769930602091923x1bbf8193jb5b9e10633440914@mail.gmail.com> Message-ID: <1fc32c8f0602100610m68e97769w@mail.gmail.com> Thanks for the update! Michael On 09/02/06, David A. Bryan wrote: > > I actually hadn't iterated it -- so far there were only a few new > comments on the list that came for the last version, and I was waiting > to see if there was anything else, but I'll go ahead and try to > iterate and send out another revision tomorrow or Saturday. Obviously > we'll also have a go at changing it in Dallas too. > > --David > > > On 2/9/06, Michael Slavitch wrote: > > Hello folks; > > > > Just so that we can all be working on the same page can we have the > current > > updated iteration of the proposed charter sent to this list? > > > > Regards > > > > Michael > > > > -- > > Michael Slavitch > > Ottawa, Ontario Canada > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060210/dc672c8b/attachment.html From shelby.tang at gmail.com Fri Feb 10 14:45:21 2006 From: shelby.tang at gmail.com (Shelby Tang) Date: Fri, 10 Feb 2006 11:45:21 -0800 Subject: [p2p-sip] what's the advantage of p2p-sip Message-ID: <2053c3920602101145k749f672doa18abdec011a04d3@mail.gmail.com> What's the advantage of p2p-sip. What's the problem we want to solve with p2p-sip? Looks like most of discussion focus on the registration and call setup. But with quality cluster servers and running linux, there is not much problem there. On the other side, what kind of value can p2p-sip bring to the users? We have a lot of choice of instant message client, MSN, Yahoo, QQ etc. They already have millions of users chatting there. But skype won. The main reason is voice qulity of skype is much better. Also, NAT of skype is nice, you can talk behind firewall. We are not sure how skype achieve this. So can p2p help on RTP? Can p2p provide some level of Qos for the voice streaming? That is more important for me. thanks, Shelby -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060210/e165c5ca/attachment.html From slavitch at gmail.com Fri Feb 10 15:49:28 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Fri, 10 Feb 2006 15:49:28 -0500 Subject: [p2p-sip] what's the advantage of p2p-sip In-Reply-To: <2053c3920602101145k749f672doa18abdec011a04d3@mail.gmail.com> References: <2053c3920602101145k749f672doa18abdec011a04d3@mail.gmail.com> Message-ID: <1fc32c8f0602101249w7bfd8450u@mail.gmail.com> If your logic rang true we would be having this conversation on 3270 terminals, under permission, for a fee. Taken to a further extreme the printing press would also be unnecessary, as everything we need to know could be provided by a scribe, under permission, for a fee, if it was so deemed by a higher authority, and then only then. The basis of the argument is not trivial. Regards Michael On 10/02/06, Shelby Tang wrote: > > > What's the advantage of p2p-sip. What's the problem we want to solve with > p2p-sip? Looks like most of discussion focus on the registration and call > setup. But with quality cluster servers and running linux, there is not much > problem there. > > On the other side, what kind of value can p2p-sip bring to the users? We > have a lot of choice of instant message client, MSN, Yahoo, QQ etc. They > already have millions of users chatting there. > > But skype won. The main reason is voice qulity of skype is much better. > Also, NAT of skype is nice, you can talk behind firewall. We are not sure > how skype achieve this. > > So can p2p help on RTP? Can p2p provide some level of Qos for the voice > streaming? That is more important for me. > > thanks, > Shelby > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060210/6b7b10af/attachment.html From RADHIKA.R.ROY at saic.com Fri Feb 10 14:57:17 2006 From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.) Date: Fri, 10 Feb 2006 14:57:17 -0500 Subject: [p2p-sip] what's the advantage of p2p-sip Message-ID: Shelby: I guess it was discussed extensively in the mailing list before. Let us not repeat this in this list. Some off-line discussions with members like David and others will help you what are those benefits. Because of the tremendous benefits of p2p arch, SIP also needs to be peer-to-peer as the Internet itself is p2p. Of course, NAT, QoS, security, etc. are to be addressed as a part of it. What vendors like Skype and others are doing are only the beginning taking some baby steps. The bright wonderful future lies ahead of us once we just make SIP a little better making it pure p2p for VoIP applications. Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Shelby Tang Sent: Fri 2/10/2006 2:45 PM To: p2p-sip at cs.columbia.edu Subject: [p2p-sip] what's the advantage of p2p-sip What's the advantage of p2p-sip. What's the problem we want to solve with p2p-sip? Looks like most of discussion focus on the registration and call setup. But with quality cluster servers and running linux, there is not much problem there. On the other side, what kind of value can p2p-sip bring to the users? We have a lot of choice of instant message client, MSN, Yahoo, QQ etc. They already have millions of users chatting there. But skype won. The main reason is voice qulity of skype is much better. Also, NAT of skype is nice, you can talk behind firewall. We are not sure how skype achieve this. So can p2p help on RTP? Can p2p provide some level of Qos for the voice streaming? That is more important for me. thanks, Shelby From edpimentl at gmail.com Sat Feb 11 19:15:34 2006 From: edpimentl at gmail.com (Edpimentl) Date: Sat, 11 Feb 2006 19:15:34 -0500 Subject: [p2p-sip] Bamboo - Chord Comparison Message-ID: <43EE7E26.3050107@gmail.com> Hello Et Al, Has anyone made a comparison of Bamboo and Chord? Thanks in advance, -E http://agileco.net From bryan at ethernot.org Sun Feb 12 15:41:09 2006 From: bryan at ethernot.org (David A. Bryan) Date: Sun, 12 Feb 2006 15:41:09 -0500 Subject: [p2p-sip] Newest iteration of the Draft Charter Message-ID: <8b2769930602121241v13f8aa60t80c4a2c294c8aa21@mail.gmail.com> As requested earlier in the week, here is the charter with a few changes suggested that seemed to have broad support: * Removal of explicit reference to zeroconf work * Reworded scenario 2 to be a bit more readable and to make it clear one covered enterprise networks * Changed bit about names generally mapping to domain-level identifiers to be may may to domain-level identifiers since a number of people seemed troubled by wording. Otherwise there isn't much changed. There were a few other things mentioned, but I think subsequent emails had cleared them up, so I think this reflects the current state. As always, comments welcome. David Bryan ------------------ Peer-to-Peer Session Initiation Protocol (P2PSIP) Chairs: TBD RAI Area Director(s): TBD RAI Area Advisor: Allison Mankin Mailing Lists: General Discussion: p2p-sip at cs.columbia.edu Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ Description of the Working Group The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is to develop guidelines and mechanisms for the use of the Session Initiation Protocol (SIP) in settings where establishing and managing sessions is either partially or entirely handled by a collection of endpoints (peers) rather than centralized servers. This is an alternative to the conventional SIP approach which relies on service provider hosted proxies to which users get assigned by out-of-band means, usually based on geography, association, or business reasons. This is motivated by scenarios where a reduction in cost of equipment and operation for non-end users is desired, and in situations where such servers are not available. Some of the scenarios identified include: 1. Self-organizing and highly available proxy farms, as opposed to the fixed hierarchy of IMS-like systems. 2. Topologies with ephemeral relationships such as small office systems (with little or no central equipment) mesh networks, emergency response, and battlefield environments. These systems may have limited or no connectivity to the Internet. 3. Recovery functions to allow endpoints to communicate in the event a central server fails or the endpoints are isolated by a network partitioning event. The working group starts with the following general assumptions: 1. Peer associations groups, which may be called "P2P networks". 'P2P overlays", or "P2P federations" will provide namespaces within which P2P-SIP resources are identified. These namespaces are bounded by the identifier(s) of the peer association group, which may map to domain-level identifiers in the DNS. 2. Session establishment, capabilities negotiation, session termination, subscription, notification, messaging, and related functions traditionally performed using SIP will continue to be performed using SIP. This working group is interested only in the mechanisms for locating resources within peer association groups. We generally refer to this as the "rendezvous problem". 3. Some elements of each peer association group MAY be rooted in the DNS such that they can be used for bootstrapping operations. However, a peer association group that is operating entirely in an isolated (or disconnected, or autonomous) mode will rely on alternate means of bootstrapping the peer association group. 4. Interactions between peer association groups (or members thereof) and other peer association groups or conventional SIP installations will be resolved using the resource location model of RFC 3263: "Locating SIP Servers". 5. The level of authenticity of identity will vary by the peer association group. However, the working group will define at least one mechanism that will provide assertion of identity having strength equivalent to that provided by the "SIP Identity Mechanism" RFC, perhaps by reusing some or all of the mechanism of that RFC. Specifically, the working group will: 1. Document scenarios in which a P2P architecture is appropriate for SIP based solutions ("use-cases" document). 2. Develop a general architecture or framework for P2P-based SIP applications. This will require evaluating the existing deployed and proposed P2P-based SIP solutions for possible incorporation into this work. 3. Define a distributed location mechanism for locating users in the absence of a central server, including the protocols and algorithms needed do establish, maintain, and query the distributed information. 4. If SIP extensions are needed to support the peer-to-peer model, define requirements for those extensions to be acted on by the SIP working group. 5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate them into the P2P SIP architecture or framework. If necessary, define requirements for enhancements of existing techniques to be acted on by other working groups. While ensuring: 1. Security is addressed in these systems. 2. Interoperability with existing client-server (CS) SIP and the PSTN. 3. The solutions proposed will function even with some or many nodes located behind NATs or firewalls. 4. Existing protocols are reused whenever possible. The following topics are initially out of the Working Group's scope, but may be considered in possible future charters: 1. Using P2P mechanisms to manage groups of distributed media relays. 2. Using distributed relays to enable anonymous communications. 3. Creating distributed voice mail systems. 4. Performing distributed search for users based on something other than user id. The following topics are explicitly excluded from the Working Group's scope: 1. Issues specific to applications other than locating users and resources for the full range of SIP-based communications offered in a conventional client-server SIP system, including but not limited to real-time media, messaging, and presence. 2. Discussion of this technology as a replacement for conventional (client-server) SIP. 3. Solving "research" type open questions related to P2P SIP. The working group will instead forward such work to the IRTF. A few such topics include: o Fully distributed schemes for assuring unique user identities. o Development of new structured P2P algorithms, such as DHTs. o Developing a P2P-based replacements for DNS. The working group will operate in close cooperation with the SIP, SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF. Respecting the IETF specification change policy, the working group will refer any possible changes or extensions as suggestions to the appropriate WGs as needed. A guiding principal of the WG will be to avoid extensions or change wherever possible. Goals and Milestones Aug 2006 Submit use-cases document to the IESG (Informational) Jan 2007 Submit architecture document to the IESG (Informational) Jul 2007 Submit protocol and/or protocol extension documents to the IESG (Standards-track) From slavitch at gmail.com Sun Feb 12 17:57:26 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Sun, 12 Feb 2006 17:57:26 -0500 Subject: [p2p-sip] Newest iteration of the Draft Charter In-Reply-To: <8b2769930602121241v13f8aa60t80c4a2c294c8aa21@mail.gmail.com> References: <8b2769930602121241v13f8aa60t80c4a2c294c8aa21@mail.gmail.com> Message-ID: <1fc32c8f0602121457y74ef0b00h@mail.gmail.com> This looks good. It gives enough scope to allow for broad and innovative practical use-cases. It also places within scope the basic mechanisms needed to succeed in fundamental areas of concern, including identity, SIP signalling and NAT traversal. For this I am very appreciative. Unless anyone can see any problems that have been missed I think we can go forward with this draft charter. Regards, Michael On 12/02/06, David A. Bryan wrote: > > As requested earlier in the week, here is the charter with a few > changes suggested that seemed to have broad support: > > * Removal of explicit reference to zeroconf work > > * Reworded scenario 2 to be a bit more readable and to make it clear > one covered enterprise networks > > * Changed bit about names generally mapping to domain-level > identifiers to be may may to domain-level identifiers since a number > of people seemed troubled by wording. > > Otherwise there isn't much changed. There were a few other things > mentioned, but I think subsequent emails had cleared them up, so I > think this reflects the current state. > > As always, comments welcome. > > David Bryan > > > ------------------ > > > > Peer-to-Peer Session Initiation Protocol (P2PSIP) > > Chairs: > TBD > > RAI Area Director(s): > TBD > > RAI Area Advisor: > Allison Mankin > > Mailing Lists: > General Discussion: p2p-sip at cs.columbia.edu > Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ > > Description of the Working Group > > The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol > working group (P2PSIP WG) is to develop guidelines and mechanisms for > the use of the Session Initiation Protocol (SIP) in settings where > establishing and managing sessions is either partially or entirely > handled by a collection of endpoints (peers) rather than centralized > servers. This is an alternative to the conventional SIP approach which > relies on service provider hosted proxies to which users get assigned > by out-of-band means, usually based on geography, association, or > business reasons. > > This is motivated by scenarios where a reduction in cost of equipment > and operation for non-end users is desired, and in situations where > such servers are not available. Some of the scenarios identified > include: > > 1. Self-organizing and highly available proxy farms, as opposed to the > fixed hierarchy of IMS-like systems. > > 2. Topologies with ephemeral relationships such as small office > systems (with little or no central equipment) mesh networks, > emergency response, and battlefield environments. These systems may > have limited or no connectivity to the Internet. > > 3. Recovery functions to allow endpoints to communicate in the event a > central server fails or the endpoints are isolated by a network > partitioning event. > > The working group starts with the following general assumptions: > > 1. Peer associations groups, which may be called "P2P networks". 'P2P > overlays", or "P2P federations" will provide namespaces within > which P2P-SIP resources are identified. These namespaces are > bounded by the identifier(s) of the peer association group, which > may map to domain-level identifiers in the DNS. > > 2. Session establishment, capabilities negotiation, session > termination, subscription, notification, messaging, and related > functions traditionally performed using SIP will continue to be > performed using SIP. This working group is interested only in the > mechanisms for locating resources within peer association > groups. We generally refer to this as the "rendezvous problem". > > 3. Some elements of each peer association group MAY be rooted in the > DNS such that they can be used for bootstrapping operations. > However, a peer association group that is operating entirely in an > isolated (or disconnected, or autonomous) mode will rely on > alternate means of bootstrapping the peer association group. > > 4. Interactions between peer association groups (or members thereof) > and other peer association groups or conventional SIP installations > will be resolved using the resource location model of RFC 3263: > "Locating SIP Servers". > > 5. The level of authenticity of identity will vary by the peer > association group. However, the working group will define at least > one mechanism that will provide assertion of identity having > strength equivalent to that provided by the "SIP Identity > Mechanism" RFC, perhaps by reusing some or all of the mechanism of > that RFC. > > Specifically, the working group will: > > 1. Document scenarios in which a P2P architecture is appropriate for > SIP based solutions ("use-cases" document). > > 2. Develop a general architecture or framework for P2P-based SIP > applications. This will require evaluating the existing deployed > and proposed P2P-based SIP solutions for possible incorporation > into this work. > > 3. Define a distributed location mechanism for locating users in the > absence of a central server, including the protocols and algorithms > needed do establish, maintain, and query the distributed > information. > > 4. If SIP extensions are needed to support the peer-to-peer model, > define requirements for those extensions to be acted on by the SIP > working group. > > 5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate > them into the P2P SIP architecture or framework. If necessary, > define requirements for enhancements of existing techniques to be > acted on by other working groups. > > While ensuring: > > 1. Security is addressed in these systems. > > 2. Interoperability with existing client-server (CS) SIP and the PSTN. > > 3. The solutions proposed will function even with some or many nodes > located behind NATs or firewalls. > > 4. Existing protocols are reused whenever possible. > > The following topics are initially out of the Working Group's scope, > but may be considered in possible future charters: > > 1. Using P2P mechanisms to manage groups of distributed media relays. > > 2. Using distributed relays to enable anonymous communications. > > 3. Creating distributed voice mail systems. > > 4. Performing distributed search for users based on something other > than user id. > > The following topics are explicitly excluded from the Working Group's > scope: > > 1. Issues specific to applications other than locating users and > resources for the full range of SIP-based communications offered > in a conventional client-server SIP system, including but not > limited to real-time media, messaging, and presence. > > 2. Discussion of this technology as a replacement for conventional > (client-server) SIP. > > 3. Solving "research" type open questions related to P2P SIP. The > working group will instead forward such work to the IRTF. A few > such topics include: > o Fully distributed schemes for assuring unique user identities. > o Development of new structured P2P algorithms, such as DHTs. > o Developing a P2P-based replacements for DNS. > > The working group will operate in close cooperation with the SIP, > SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the > IRTF. Respecting the IETF specification change policy, the working > group will refer any possible changes or extensions as suggestions to > the appropriate WGs as needed. A guiding principal of the WG will be > to avoid extensions or change wherever possible. > > Goals and Milestones > Aug 2006 Submit use-cases document to the IESG (Informational) > Jan 2007 Submit architecture document to the IESG (Informational) > Jul 2007 Submit protocol and/or protocol extension documents to > the IESG (Standards-track) > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060212/97d3404c/attachment.html From edpimentl at gmail.com Sun Feb 12 18:06:21 2006 From: edpimentl at gmail.com (Edpimentl) Date: Sun, 12 Feb 2006 18:06:21 -0500 Subject: [p2p-sip] Newest iteration of the Draft Charter In-Reply-To: <8b2769930602121241v13f8aa60t80c4a2c294c8aa21@mail.gmail.com> References: <8b2769930602121241v13f8aa60t80c4a2c294c8aa21@mail.gmail.com> Message-ID: <43EFBF6D.7030803@gmail.com> Hello David, Excellent draft, What would be your reaction on adding one or two regarding how Trust, Privacy, Presence and Preference would be supported when initiating a P2P session or how P2P-SIP would supported. Best, -E http://GooGaYa.com David A. Bryan wrote: >As requested earlier in the week, here is the charter with a few >changes suggested that seemed to have broad support: > >* Removal of explicit reference to zeroconf work > >* Reworded scenario 2 to be a bit more readable and to make it clear >one covered enterprise networks > >* Changed bit about names generally mapping to domain-level >identifiers to be may may to domain-level identifiers since a number >of people seemed troubled by wording. > >Otherwise there isn't much changed. There were a few other things >mentioned, but I think subsequent emails had cleared them up, so I >think this reflects the current state. > >As always, comments welcome. > >David Bryan > > >------------------ > > > >Peer-to-Peer Session Initiation Protocol (P2PSIP) > >Chairs: >TBD > >RAI Area Director(s): >TBD > >RAI Area Advisor: >Allison Mankin > >Mailing Lists: >General Discussion: p2p-sip at cs.columbia.edu >Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip >Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ > >Description of the Working Group > >The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol >working group (P2PSIP WG) is to develop guidelines and mechanisms for >the use of the Session Initiation Protocol (SIP) in settings where >establishing and managing sessions is either partially or entirely >handled by a collection of endpoints (peers) rather than centralized >servers. This is an alternative to the conventional SIP approach which >relies on service provider hosted proxies to which users get assigned >by out-of-band means, usually based on geography, association, or >business reasons. > >This is motivated by scenarios where a reduction in cost of equipment >and operation for non-end users is desired, and in situations where >such servers are not available. Some of the scenarios identified >include: > >1. Self-organizing and highly available proxy farms, as opposed to the > fixed hierarchy of IMS-like systems. > >2. Topologies with ephemeral relationships such as small office > systems (with little or no central equipment) mesh networks, > emergency response, and battlefield environments. These systems may > have limited or no connectivity to the Internet. > >3. Recovery functions to allow endpoints to communicate in the event a > central server fails or the endpoints are isolated by a network > partitioning event. > >The working group starts with the following general assumptions: > >1. Peer associations groups, which may be called "P2P networks". 'P2P > overlays", or "P2P federations" will provide namespaces within > which P2P-SIP resources are identified. These namespaces are > bounded by the identifier(s) of the peer association group, which > may map to domain-level identifiers in the DNS. > >2. Session establishment, capabilities negotiation, session > termination, subscription, notification, messaging, and related > functions traditionally performed using SIP will continue to be > performed using SIP. This working group is interested only in the > mechanisms for locating resources within peer association > groups. We generally refer to this as the "rendezvous problem". > >3. Some elements of each peer association group MAY be rooted in the > DNS such that they can be used for bootstrapping operations. > However, a peer association group that is operating entirely in an > isolated (or disconnected, or autonomous) mode will rely on > alternate means of bootstrapping the peer association group. > >4. Interactions between peer association groups (or members thereof) > and other peer association groups or conventional SIP installations > will be resolved using the resource location model of RFC 3263: > "Locating SIP Servers". > >5. The level of authenticity of identity will vary by the peer > association group. However, the working group will define at least > one mechanism that will provide assertion of identity having > strength equivalent to that provided by the "SIP Identity > Mechanism" RFC, perhaps by reusing some or all of the mechanism of > that RFC. > >Specifically, the working group will: > >1. Document scenarios in which a P2P architecture is appropriate for > SIP based solutions ("use-cases" document). > >2. Develop a general architecture or framework for P2P-based SIP > applications. This will require evaluating the existing deployed > and proposed P2P-based SIP solutions for possible incorporation > into this work. > >3. Define a distributed location mechanism for locating users in the > absence of a central server, including the protocols and algorithms > needed do establish, maintain, and query the distributed > information. > >4. If SIP extensions are needed to support the peer-to-peer model, > define requirements for those extensions to be acted on by the SIP > working group. > >5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate > them into the P2P SIP architecture or framework. If necessary, > define requirements for enhancements of existing techniques to be > acted on by other working groups. > >While ensuring: > >1. Security is addressed in these systems. > >2. Interoperability with existing client-server (CS) SIP and the PSTN. > >3. The solutions proposed will function even with some or many nodes > located behind NATs or firewalls. > >4. Existing protocols are reused whenever possible. > >The following topics are initially out of the Working Group's scope, >but may be considered in possible future charters: > >1. Using P2P mechanisms to manage groups of distributed media relays. > >2. Using distributed relays to enable anonymous communications. > >3. Creating distributed voice mail systems. > >4. Performing distributed search for users based on something other > than user id. > >The following topics are explicitly excluded from the Working Group's >scope: > >1. Issues specific to applications other than locating users and > resources for the full range of SIP-based communications offered > in a conventional client-server SIP system, including but not > limited to real-time media, messaging, and presence. > >2. Discussion of this technology as a replacement for conventional > (client-server) SIP. > >3. Solving "research" type open questions related to P2P SIP. The > working group will instead forward such work to the IRTF. A few > such topics include: > o Fully distributed schemes for assuring unique user identities. > o Development of new structured P2P algorithms, such as DHTs. > o Developing a P2P-based replacements for DNS. > >The working group will operate in close cooperation with the SIP, >SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the >IRTF. Respecting the IETF specification change policy, the working >group will refer any possible changes or extensions as suggestions to >the appropriate WGs as needed. A guiding principal of the WG will be >to avoid extensions or change wherever possible. > >Goals and Milestones >Aug 2006 Submit use-cases document to the IESG (Informational) >Jan 2007 Submit architecture document to the IESG (Informational) >Jul 2007 Submit protocol and/or protocol extension documents to > the IESG (Standards-track) > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From bryan at ethernot.org Sun Feb 12 22:16:42 2006 From: bryan at ethernot.org (David A. Bryan) Date: Sun, 12 Feb 2006 22:16:42 -0500 Subject: [p2p-sip] Newest iteration of the Draft Charter In-Reply-To: <43EFBF6D.7030803@gmail.com> References: <8b2769930602121241v13f8aa60t80c4a2c294c8aa21@mail.gmail.com> <43EFBF6D.7030803@gmail.com> Message-ID: <8b2769930602121916m2f919469m9aae3a0872ce1b12@mail.gmail.com> I think that presence is in there already (in that item 1 of what is out of scope says 1. Issues specific to applications other than locating users and resources for the full range of SIP-based communications offered in a conventional client-server SIP system, including but not limited to real-time media, messaging, and presence. So I think that gets presence in there. I think most of the rest is likely to be either 1) able to be done in the same way as for CS SIP or would likely be things we can look at later -- I want to try to keep the initial scope narrow, so we can actually get the basic signaling done -- hopefully something we can extend later. I worry that distributed trust and privacy also tread close to what I think may be too close to the general distributed identity problem listed as out of scope for comfort -- they may very well be difficult research problems unless some more traditional methods from CS SIP (such as certificates from a central server) are used. David On 2/12/06, Edpimentl wrote: > Hello David, > > Excellent draft, > What would be your reaction on adding one or two regarding how Trust, > Privacy, Presence and Preference would > be supported when initiating a P2P session or how P2P-SIP would supported. > > Best, > -E > http://GooGaYa.com > > David A. Bryan wrote: > > >As requested earlier in the week, here is the charter with a few > >changes suggested that seemed to have broad support: > > > >* Removal of explicit reference to zeroconf work > > > >* Reworded scenario 2 to be a bit more readable and to make it clear > >one covered enterprise networks > > > >* Changed bit about names generally mapping to domain-level > >identifiers to be may may to domain-level identifiers since a number > >of people seemed troubled by wording. > > > >Otherwise there isn't much changed. There were a few other things > >mentioned, but I think subsequent emails had cleared them up, so I > >think this reflects the current state. > > > >As always, comments welcome. > > > >David Bryan > > > > > >------------------ > > > > > > > >Peer-to-Peer Session Initiation Protocol (P2PSIP) > > > >Chairs: > >TBD > > > >RAI Area Director(s): > >TBD > > > >RAI Area Advisor: > >Allison Mankin > > > >Mailing Lists: > >General Discussion: p2p-sip at cs.columbia.edu > >Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip > >Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/ > > > >Description of the Working Group > > > >The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol > >working group (P2PSIP WG) is to develop guidelines and mechanisms for > >the use of the Session Initiation Protocol (SIP) in settings where > >establishing and managing sessions is either partially or entirely > >handled by a collection of endpoints (peers) rather than centralized > >servers. This is an alternative to the conventional SIP approach which > >relies on service provider hosted proxies to which users get assigned > >by out-of-band means, usually based on geography, association, or > >business reasons. > > > >This is motivated by scenarios where a reduction in cost of equipment > >and operation for non-end users is desired, and in situations where > >such servers are not available. Some of the scenarios identified > >include: > > > >1. Self-organizing and highly available proxy farms, as opposed to the > > fixed hierarchy of IMS-like systems. > > > >2. Topologies with ephemeral relationships such as small office > > systems (with little or no central equipment) mesh networks, > > emergency response, and battlefield environments. These systems may > > have limited or no connectivity to the Internet. > > > >3. Recovery functions to allow endpoints to communicate in the event a > > central server fails or the endpoints are isolated by a network > > partitioning event. > > > >The working group starts with the following general assumptions: > > > >1. Peer associations groups, which may be called "P2P networks". 'P2P > > overlays", or "P2P federations" will provide namespaces within > > which P2P-SIP resources are identified. These namespaces are > > bounded by the identifier(s) of the peer association group, which > > may map to domain-level identifiers in the DNS. > > > >2. Session establishment, capabilities negotiation, session > > termination, subscription, notification, messaging, and related > > functions traditionally performed using SIP will continue to be > > performed using SIP. This working group is interested only in the > > mechanisms for locating resources within peer association > > groups. We generally refer to this as the "rendezvous problem". > > > >3. Some elements of each peer association group MAY be rooted in the > > DNS such that they can be used for bootstrapping operations. > > However, a peer association group that is operating entirely in an > > isolated (or disconnected, or autonomous) mode will rely on > > alternate means of bootstrapping the peer association group. > > > >4. Interactions between peer association groups (or members thereof) > > and other peer association groups or conventional SIP installations > > will be resolved using the resource location model of RFC 3263: > > "Locating SIP Servers". > > > >5. The level of authenticity of identity will vary by the peer > > association group. However, the working group will define at least > > one mechanism that will provide assertion of identity having > > strength equivalent to that provided by the "SIP Identity > > Mechanism" RFC, perhaps by reusing some or all of the mechanism of > > that RFC. > > > >Specifically, the working group will: > > > >1. Document scenarios in which a P2P architecture is appropriate for > > SIP based solutions ("use-cases" document). > > > >2. Develop a general architecture or framework for P2P-based SIP > > applications. This will require evaluating the existing deployed > > and proposed P2P-based SIP solutions for possible incorporation > > into this work. > > > >3. Define a distributed location mechanism for locating users in the > > absence of a central server, including the protocols and algorithms > > needed do establish, maintain, and query the distributed > > information. > > > >4. If SIP extensions are needed to support the peer-to-peer model, > > define requirements for those extensions to be acted on by the SIP > > working group. > > > >5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate > > them into the P2P SIP architecture or framework. If necessary, > > define requirements for enhancements of existing techniques to be > > acted on by other working groups. > > > >While ensuring: > > > >1. Security is addressed in these systems. > > > >2. Interoperability with existing client-server (CS) SIP and the PSTN. > > > >3. The solutions proposed will function even with some or many nodes > > located behind NATs or firewalls. > > > >4. Existing protocols are reused whenever possible. > > > >The following topics are initially out of the Working Group's scope, > >but may be considered in possible future charters: > > > >1. Using P2P mechanisms to manage groups of distributed media relays. > > > >2. Using distributed relays to enable anonymous communications. > > > >3. Creating distributed voice mail systems. > > > >4. Performing distributed search for users based on something other > > than user id. > > > >The following topics are explicitly excluded from the Working Group's > >scope: > > > >1. Issues specific to applications other than locating users and > > resources for the full range of SIP-based communications offered > > in a conventional client-server SIP system, including but not > > limited to real-time media, messaging, and presence. > > > >2. Discussion of this technology as a replacement for conventional > > (client-server) SIP. > > > >3. Solving "research" type open questions related to P2P SIP. The > > working group will instead forward such work to the IRTF. A few > > such topics include: > > o Fully distributed schemes for assuring unique user identities. > > o Development of new structured P2P algorithms, such as DHTs. > > o Developing a P2P-based replacements for DNS. > > > >The working group will operate in close cooperation with the SIP, > >SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the > >IRTF. Respecting the IETF specification change policy, the working > >group will refer any possible changes or extensions as suggestions to > >the appropriate WGs as needed. A guiding principal of the WG will be > >to avoid extensions or change wherever possible. > > > >Goals and Milestones > >Aug 2006 Submit use-cases document to the IESG (Informational) > >Jan 2007 Submit architecture document to the IESG (Informational) > >Jul 2007 Submit protocol and/or protocol extension documents to > > the IESG (Standards-track) > > > >_______________________________________________ > >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 Feb 27 18:22:26 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 27 Feb 2006 18:22:26 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP Message-ID: <440389B2.5040801@research.panasonic.com> We submitted an I-D that describes an architecture for P2P SIP. You can get it from the link below until it appears in the IETF I-D directory. We hope this draft can help the architecture and charter discussion in BOF. Your comments will be appreciated. Thanks. Eunsoo http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p-arch-00.txt Abstract This document describes an architecture for peer-to-peer SIP systems in which a separate and independent peer-to-peer overlay layer provides a distributed resource placement and search service for SIP. It also aims to help identify what should be specified for interoperation. From kns10 at cs.columbia.edu Mon Feb 27 20:08:04 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Mon, 27 Feb 2006 20:08:04 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: <440389B2.5040801@research.panasonic.com> References: <440389B2.5040801@research.panasonic.com> Message-ID: <4403A274.2050906@cs.columbia.edu> Hi All, On a similar note: Henning and I had written a tech report documenting our experience with "Using an external DHT as a SIP location service". If you are interested, you can read the report at http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 In particular, it describes using OpenDHT.org for contact management, key storage, presence, offline messages and STUN server discovery using pseudo code and examples. Eunsoo Shim wrote: > We submitted an I-D that describes an architecture for P2P SIP. > You can get it from the link below until it appears in the IETF I-D > directory. > We hope this draft can help the architecture and charter discussion in BOF. > Your comments will be appreciated. > Thanks. > > Eunsoo > > http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p-arch-00.txt From bryan at ethernot.org Mon Feb 27 22:09:35 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 27 Feb 2006 22:09:35 -0500 Subject: [p2p-sip] Agendas for BOF and ad-hoc meeting at IETF-65 in Dallas Message-ID: <8b2769930602271909x14c23c63i55ad5e8d4e080af1@mail.gmail.com> Hello all, Things are moving along for the BOF at IETF-65. At this point, it does still appears there will be a BOF and a separate "sometime Friday" meeting to discuss particular technical issues near and dear to people's hearts. Currently, the agenda for the BOF looks like: Agenda Bash Problem Overview, (What are we doing here?), David Bryan to develop slides Scope and Draft Charter, Organization of WG, Dean Willis to develop slides Discussion of Use Cases (draft-bryan-sipping-p2p-usecases-00), Bruce B. Lowekamp to develop slides Discussion of Requirements (draft-basset-sipping-p2preq-00), ??? to develop slides We need a volunteer from the authors of the p2preq draft to volunteer to prepare some slides for that. For the "sometime Friday" meeting, we have: Agenda Bash Architecture Discussion (draft-shim-sipping-p2p-arch-00), Eunsoo Shim NAT Traversal Discussion (draft-matthews-p2psip-nats-and-overlays-00), ??? (volunteer?) ??? If you would like to request some time at the later meeting, please send Dean and myself an email. I've put these agendas and the most recent iteration of the charter up under the IETF section over at p2psip.org. David Bryan From ag at ag-projects.com Tue Feb 28 05:02:28 2006 From: ag at ag-projects.com (Adrian Georgescu) Date: Tue, 28 Feb 2006 11:02:28 +0100 Subject: [p2p-sip] Using DNS to bootstrap the DHT In-Reply-To: <440389B2.5040801@research.panasonic.com> References: <440389B2.5040801@research.panasonic.com> Message-ID: <294E6907-4DB5-4CF1-9F07-A27989A0345A@ag-projects.com> Hello Eunsoo, I like much this document because it outlines several things the make sense and can be achieved. I personally spent some time in the bootstrap realm, what I end-up with is described at: http://www.ag-projects.com/doc/SIPThor_UsingDNSforDHTlookup.txt Regards, Adrian On Feb 28, 2006, at 12:22 AM, Eunsoo Shim wrote: > We submitted an I-D that describes an architecture for P2P SIP. > You can get it from the link below until it appears in the IETF I-D > directory. > We hope this draft can help the architecture and charter discussion > in BOF. > Your comments will be appreciated. > Thanks. > > Eunsoo > > http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p- > arch-00.txt > > Abstract > > This document describes an architecture for peer-to-peer SIP > systems > in which a separate and independent peer-to-peer overlay layer > provides a distributed resource placement and search service for > SIP. > It also aims to help identify what should be specified for > interoperation. > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From ag at ag-projects.com Tue Feb 28 05:07:28 2006 From: ag at ag-projects.com (Adrian Georgescu) Date: Tue, 28 Feb 2006 11:07:28 +0100 Subject: [p2p-sip] Using DNS to bootstrap the DHT - corrected link In-Reply-To: <294E6907-4DB5-4CF1-9F07-A27989A0345A@ag-projects.com> References: <440389B2.5040801@research.panasonic.com> <294E6907-4DB5-4CF1-9F07-A27989A0345A@ag-projects.com> Message-ID: http://www.ag-projects.com/docs/SIPThor_UsingDNSforDHTlookup.txt On Feb 28, 2006, at 11:02 AM, Adrian Georgescu wrote: > Hello Eunsoo, > > I like much this document because it outlines several things the > make sense and can be achieved. > > I personally spent some time in the bootstrap realm, what I end-up > with is described at: > > http://www.ag-projects.com/doc/SIPThor_UsingDNSforDHTlookup.txt > > Regards, > Adrian > > > On Feb 28, 2006, at 12:22 AM, Eunsoo Shim wrote: > >> We submitted an I-D that describes an architecture for P2P SIP. >> You can get it from the link below until it appears in the IETF I-D >> directory. >> We hope this draft can help the architecture and charter >> discussion in BOF. >> Your comments will be appreciated. >> Thanks. >> >> Eunsoo >> >> http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p- >> arch-00.txt >> >> Abstract >> >> This document describes an architecture for peer-to-peer SIP >> systems >> in which a separate and independent peer-to-peer overlay layer >> provides a distributed resource placement and search service >> for SIP. >> It also aims to help identify what should be specified for >> interoperation. >> >> >> >> >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From alexander.mayrhofer at enum.at Tue Feb 28 05:30:47 2006 From: alexander.mayrhofer at enum.at (Alexander Mayrhofer) Date: Tue, 28 Feb 2006 11:30:47 +0100 Subject: [p2p-sip] FYI: I-D regarding decentralized identity infrastructure based on ENUM Message-ID: <44042657.8040009@enum.at> Hi, i've recently submitted a draft which describes an approach to use ENUM as a distributed/decentralized identity architecture: http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.txt Abstract: This document creates a decentralized indentity infrastructure by combining technology from E.164 Number Mapping (ENUM) and DomainKeys Identified Mail (DKIM). This infrastructure uses E.164 numbers as identities, ENUM DNS for key distribution, and leverages the trust relations from ENUM validation to actual messages signed by the number holder. This is currently supposed to "document the basic idea", not a perfect protocol. Since one of the potential use cases is P2P communication i'd appreciate any feedback about this document. I'm not sure if i can attend the friday afternoon p2psip session, but if there is demand, i'd provide a few slides about the concept anyways (I'll present it in the ENUM WG anyways). cheers alex From marc1.bailly at francetelecom.com Tue Feb 28 05:55:42 2006 From: marc1.bailly at francetelecom.com (BAILLY Marc RD-CORE-LAN) Date: Tue, 28 Feb 2006 11:55:42 +0100 Subject: [p2p-sip] I-D: An Architecture for P2P SIP Message-ID: Hi Eunsoo, Thank your for your interesting draft. I have some questions about the supernode selection criteria. It is mentionned in your draft that "it is recommended that SNs should be on the public internet" in order to receive P2P messages. I think it would be interesting to know the proportion of non NATed users in the use case of public P2P VoIP network. Given that it seems that there are more and more NATed users, I fear that the number of potential SN by comparison with the number of ON is too low. Does anyone has information about this? Does anyone has an idea of the number of nated ON that can be connected to a SN as a function of the SN capabilities? That's why I'm wondering if it could be possible to use NAT traversal mechanisms in the P2P overlay in order to be able to include NATed nodes in it (I know this is not a SIP problem but it has impact on the P2P SIP architecture). Is it possible with a DHT? If possible, what are the impacts on the DHT efficiency? Regards, Marc > -----Message d'origine----- > De : p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] De la part de Eunsoo Shim > Envoy? : mardi 28 f?vrier 2006 00:22 > ? : P2P-SIP > Objet : [p2p-sip] I-D: An Architecture for P2P SIP > > We submitted an I-D that describes an architecture for P2P SIP. > You can get it from the link below until it appears in the IETF I-D > directory. > We hope this draft can help the architecture and charter > discussion in BOF. > Your comments will be appreciated. > Thanks. > > Eunsoo > > http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping- > p2p-arch-00.txt > > Abstract > > This document describes an architecture for peer-to-peer > SIP systems > in which a separate and independent peer-to-peer overlay layer > provides a distributed resource placement and search > service for SIP. > It also aims to help identify what should be specified for > interoperation. > > > > > > _______________________________________________ > 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 Tue Feb 28 07:26:26 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Tue, 28 Feb 2006 07:26:26 -0500 (EST) Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: References: Message-ID: > I have some questions about the supernode selection criteria. It is mentionned in your draft that "it is recommended that SNs should be on the public internet" in order to receive P2P messages. > I think it would be interesting to know the proportion of non NATed users in the use case of public P2P VoIP network. Given that it seems that there are more and more NATed users, I fear that the number of potential SN by comparison with the number of ON is too low. Does anyone has information about this? A non-statistical answer: Skype works. According to Nielsen ratings 2 out of 5 Americans have broadband access at home. http://www.nielsen-netratings.com/pr/pr_050928.pdf One can draw his/her own NAT proportion figures based on Nielsen numbers. I had come across a figure that said about 30% of home Internet users are behind NATs. However, that figure probably does not tell anything about the number of non-natted university users. Unfortunately, I am not able to find the source of that figure. > Does anyone has an idea of the number of nated ON that can be connected to a SN as a function of the SN capabilities? SN has two critical capabilities. Message routing and NAT relay. The former requires less bandwidth while the later can consume a significant chunk of broadband bandwidth (30-60 kbps out of a 256 kbps, 512 kbps broadband connection). Given that there are Y number of online users and X number of user pairs are in a call at a time, and out of those user pairs x% are both behind a NAT then, loosely speaking, NAT relays are required only for those x%*2 users. Y=Total online users. X=No of users that make a call per second or no of calls per second. x=Percentage of users behindth of them are behind a NAT. or the percentage of calls that require a NAT relay x 2. PSTN numbers can be plugged in here to estimate calls per second. > > That's why I'm wondering if it could be possible to use NAT traversal mechanisms in the P2P overlay in order to be able to include NATed nodes in it (I know this is not a SIP problem but it has impact on the P2P SIP architecture). > Is it possible with a DHT? If possible, what are the impacts on the DHT efficiency? NATed hosts are generally (statistically?) bandwidth limited hosts. It is an interesting question why Skype did not choose NATed hosts for voice relays. regards, salman > Regards, > > Marc > > > > -----Message d'origine----- > > De : p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu] De la part de Eunsoo Shim > > Envoy? : mardi 28 f?vrier 2006 00:22 > > ? : P2P-SIP > > Objet : [p2p-sip] I-D: An Architecture for P2P SIP > > > > We submitted an I-D that describes an architecture for P2P SIP. > > You can get it from the link below until it appears in the IETF I-D > > directory. > > We hope this draft can help the architecture and charter > > discussion in BOF. > > Your comments will be appreciated. > > Thanks. > > > > Eunsoo > > > > http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping- > > p2p-arch-00.txt > > > > Abstract > > > > This document describes an architecture for peer-to-peer > > SIP systems > > in which a separate and independent peer-to-peer overlay layer > > provides a distributed resource placement and search > > service for SIP. > > It also aims to help identify what should be specified for > > interoperation. > > > > > > > > > > > > _______________________________________________ > > 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 Feb 28 08:22:33 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 28 Feb 2006 08:22:33 -0500 Subject: [p2p-sip] New I-D: The effect of NATs on P2P SIP Overlay Architecture Message-ID: Eric Cooper and I have written an internet-draft that talks about the effect of NATs on the architecture of a P2P SIP overlay network. In brief, the draft begins with a list of assumptions on what types of NATs exist in the network and where the peers are located. We argue why we feel these assumptions are the right ones. We then describes the consequences of these assumptions on the P2P SIP overlay architecture. Perhaps the most interesting assumption is that, in at least some P2P SIP networks, _ALL_ the peers may be located behind NATs. We argue that, with the increasing proliferation of NATs today, this is a very realistic possibility, especially in a smaller P2P SIP network or in a P2P SIP network where a large proportion of the peers are enterprise users. The draft goes on to describe various ways an overlay network can be constructed given these assumptions. This draft is NOT trying advocate one particular overlay architecture. Rather, it is trying to show the range of architectures available given the set of assumptions, and give some measures by which the various architectures can be compared. However, it does conclude that there is really not a lot of choice -- given the assumptions, there seems to be only one overlay architecture that makes any real sense. This is a partial-mesh architecture exhibiting a property we call "symmetric interest". Note that the draft focuses ONLY on the structure of the overlay network. We do NOT describe how searches for users and nodes might be done in the network. This is an orthogonal question which is left to other drafts. Our goal is simply to describe the connection structure between peers in the overlay network. We are very interested any any comments people might have, either on our set of assumptions or on our analysis of possible architectures that meet these assumptions. The plain text version of the draft is available at http://www.ietf.org/internet-drafts/draft-matthews-p2psip-nats-and- overlays-00.txt There is also an HTML version which some people might find easier to read. We hope to get this version up on a website shortly, but for now you can e-mail either one of us for a copy. Here is the abstract from the draft: This document discusses the constraints that NATs put on the possible overlay architectures of a P2P SIP system. Given what seems to be a reasonable set of assumptions on where nodes are deployed and the kinds of NATs they are located behind, the document concludes that a structured partial-mesh overlay network exhibiting a property known as "symmetric interest" is the most reasonable overlay architecture. - Philip From philip_matthews at magma.ca Tue Feb 28 09:03:35 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 28 Feb 2006 09:03:35 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: References: Message-ID: <0838EDF1-BF2F-46B0-B679-02C2614294A5@magma.ca> >> I have some questions about the supernode selection criteria. It >> is mentionned in your draft that "it is recommended that SNs >> should be on the public internet" in order to receive P2P messages. >> I think it would be interesting to know the proportion of non >> NATed users in the use case of public P2P VoIP network. Given that >> it seems that there are more and more NATed users, I fear that the >> number of potential SN by comparison with the number of ON is too >> low. Does anyone has information about this? > > A non-statistical answer: Skype works. > According to Nielsen ratings 2 out of 5 Americans have broadband > access at > home. > http://www.nielsen-netratings.com/pr/pr_050928.pdf > > One can draw his/her own NAT proportion figures based on Nielsen > numbers. > > I had come across a figure that said about 30% of home Internet > users are > behind NATs. However, that figure probably does not tell anything > about > the number of non-natted university users. Unfortunately, I am not > able to > find the source of that figure. [Background for those who have not read the analysis of Skype paper: Skype seems to use superpeers that have public IP addresses] In my opinion: - Skype works because it is one single public network, and the network operators can simply add additional superpeers whenever the ratio of superpeers to peers becomes too low (by adding computers with public addresses that run the Skype client software to the Internet) - We are trying to create protocols that allow lots of distinct P2P SIP networks. Some of these may be public networks and some may be private networks. In some cases, none of the peers may have public addresses. - The vast majority of computers used in enterprise environments are located behind NATs/Firewalls. - The vast majority of computers used in homes with two or more computers and high-speed internet access sit behind a NAT (i.e., the family buys a NAT rather that purchasing two or more dynamic IP addresses from their provider). - IPv6 may get rid of NATs, but people will replace them with firewalls with similar filtering properties (e.g., Address-Restricted filtering, to use the terminology of the BEHAVE working group). I would guess that the vast majority of non-NATed computers today are: - Dial-up home users - Universities - Public web servers and similar I believe that there are some companies that acquired enough IP addresses back in the 1980s so that they do not need to NAT. I believe that Nortel is an example. However, I suspect that they still run firewalls with similar filtering properties. [Parts of the previous message deleted] > >> >> That's why I'm wondering if it could be possible to use NAT >> traversal mechanisms in the P2P overlay in order to be able to >> include NATed nodes in it (I know this is not a SIP problem but it >> has impact on the P2P SIP architecture). >> Is it possible with a DHT? If possible, what are the impacts on >> the DHT efficiency? > > NATed hosts are generally (statistically?) bandwidth limited hosts. It > is an interesting question why Skype did not choose NATed hosts for > voice > relays. > I believe this is less and less true today as enterprises and homes with multiple computers and high-speed access deploy NATs. - Philip From bryan at ethernot.org Tue Feb 28 09:34:30 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 28 Feb 2006 09:34:30 -0500 Subject: [p2p-sip] New I-D: The effect of NATs on P2P SIP Overlay Architecture In-Reply-To: References: Message-ID: <8b2769930602280634x296287a3qf382a0aeda54a5c4@mail.gmail.com> On 2/28/06, Philip Matthews wrote: > There is also an HTML version which some people might find > easier to read. We hope to get this version up on a website shortly, > but for now you can e-mail either one of us for a copy. The html version is now up on p2psip.org for those that prefer html. David From salman at cs.columbia.edu Tue Feb 28 09:39:12 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Tue, 28 Feb 2006 09:39:12 -0500 (EST) Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: <0838EDF1-BF2F-46B0-B679-02C2614294A5@magma.ca> References: <0838EDF1-BF2F-46B0-B679-02C2614294A5@magma.ca> Message-ID: > In my opinion: > - Skype works because it is one single public network, and the > network operators can simply add > additional superpeers whenever the ratio of superpeers to peers > becomes too low (by adding > computers with public addresses that run the Skype client software > to the Internet) I am not sure what exactly you mean by network operators adding superpeers. Perhaps, you mean network operator adds superpeers in its administrative domain (or rather NAT relays). Skype will administer NAT relays only if it measures that existing peers are insufficient to meet NAT relay requirements. We conducted experiments in which two Skype clients were forced to use a relay for a call. Unless Skype is using obscured IP addresses, we do not think that calls were ever relayed through Skype relays none of which were administered by Skype. > I would guess that the vast majority of non-NATed computers today are: > - Dial-up home users > - Universities > - Public web servers and similar Roughly, 18% of relays had hostnames ending a '.edu' in our Skype experiments. A total of 7,500 successful calls were made. I sometimes wonder if universities have enough bandwidth to support relays for a significant portion of Internet call traffic. regards, salman From laurent.castaignet at francetelecom.com Tue Feb 28 10:25:38 2006 From: laurent.castaignet at francetelecom.com (CASTAIGNET Laurent RD-MAPS-ISS) Date: Tue, 28 Feb 2006 16:25:38 +0100 Subject: [p2p-sip] Standardizing upon patented technology ? Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE03544194@ftrdmel3.rd.francetelecom.fr> Hi all, I was recently informed of the existence of a patent filed mid-2003 by a so-called "skyper" company (search "skyper" in the PCT database there: http://www.wipo.int/ipdl/en/). As a summary, the claims include at least the following points, as far as I understood: * A decentralized telephone system, based on a peer-to-peer network in which: => A DHT algorithm (referenced as "global index technology") may be used to handle end user related data => Peers may be used as relays when direct communication is not possible * An access control based on certificate exchanges * End user administration means * Etc. Of course, what is protected there is simply the Skype architecture. It seems quite frightening to me, knowing that many of the points mentioned in this patent are obviously important building blocks for what this (future) working group is trying to build ... I'm not aware of the usual IETF procedures in this case. Can anyone enlight me ? I know that integrating patented technologies in the scope of an existing working group has already been done, but is it also the case before its creation ? Thanks, Laurent Castaignet. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060228/7dca53cb/attachment.html From slavitch at gmail.com Tue Feb 28 10:36:40 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Tue, 28 Feb 2006 10:36:40 -0500 Subject: [p2p-sip] Standardizing upon patented technology ? In-Reply-To: <2AF8FF7D89242541B12E7A47F6ECB4BE03544194@ftrdmel3.rd.francetelecom.fr> References: <2AF8FF7D89242541B12E7A47F6ECB4BE03544194@ftrdmel3.rd.francetelecom.fr> Message-ID: <1fc32c8f0602280736w1f56fcd0i@mail.gmail.com> Prior art is of course prior art, and far too many patents are far too easily granted. M On 28/02/06, CASTAIGNET Laurent RD-MAPS-ISS < laurent.castaignet at francetelecom.com> wrote: > > Hi all, > > I was recently informed of the existence of a patent filed mid-2003 by a > so-called "skyper" company (search "skyper" in the PCT database there: * > http://www.wipo.int/ipdl/en/* ). As a > summary, the claims include at least the following points, as far as I > understood: > > * A decentralized telephone system, based on a peer-to-peer network in > which: > => A DHT algorithm (referenced as "global index technology") may > be used to handle end user related data > => Peers may be used as relays when direct communication is not > possible > * An access control based on certificate exchanges > * End user administration means > * Etc. > > Of course, what is protected there is simply the Skype architecture. It > seems quite frightening to me, knowing that many of the points mentioned in > this patent are obviously important building blocks for what this (future) > working group is trying to build ? > > I'm not aware of the usual IETF procedures in this case. Can anyone > enlight me ? I know that integrating patented technologies in the scope of > an existing working group has already been done, but is it also the case > before its creation ? > > Thanks, > > Laurent Castaignet. > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060228/1d44f6da/attachment.html From hannes.tschofenig at siemens.com Tue Feb 28 10:40:47 2006 From: hannes.tschofenig at siemens.com (Tschofenig, Hannes) Date: Tue, 28 Feb 2006 16:40:47 +0100 Subject: [p2p-sip] Standardizing upon patented technology ? Message-ID: hi, you might want to look at: http://www.ietf.org/html.charters/ipr-charter.html a suggestion to other folks on the list: from a legal point of view i would discourage people from sending comments about patents. ciao hannes ________________________________ Von: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] Im Auftrag von CASTAIGNET Laurent RD-MAPS-ISS Gesendet: Dienstag, 28. Februar 2006 16:26 An: p2p-sip at cs.columbia.edu Betreff: [p2p-sip] Standardizing upon patented technology ? Hi all, I was recently informed of the existence of a patent filed mid-2003 by a so-called "skyper" company (search "skyper" in the PCT database there: http://www.wipo.int/ipdl/en/ ). As a summary, the claims include at least the following points, as far as I understood: * A decentralized telephone system, based on a peer-to-peer network in which: => A DHT algorithm (referenced as "global index technology") may be used to handle end user related data => Peers may be used as relays when direct communication is not possible * An access control based on certificate exchanges * End user administration means * Etc. Of course, what is protected there is simply the Skype architecture. It seems quite frightening to me, knowing that many of the points mentioned in this patent are obviously important building blocks for what this (future) working group is trying to build ... I'm not aware of the usual IETF procedures in this case. Can anyone enlight me ? I know that integrating patented technologies in the scope of an existing working group has already been done, but is it also the case before its creation ? Thanks, Laurent Castaignet. From philip_matthews at magma.ca Tue Feb 28 12:57:23 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 28 Feb 2006 12:57:23 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: References: <0838EDF1-BF2F-46B0-B679-02C2614294A5@magma.ca> Message-ID: <10A1D876-8997-428A-8B60-F64A7D26F826@magma.ca> Salman: I don't completely understand your reply. This may be because it has been a while since I read your Skype analysis paper. What I meant by my comment was: Say the network operators at Skype notice that the number of peers with public IP addresses is running low. Then they can take a few cheap PCs, load their client software onto them, assign them public IP addresses, and Voila! Some new peers with public IP addresses. If I understand what you said in your message, you agree with the above statement (perhaps with some qualifications)??? My point was that Skype can do this because there is just ONE network. However, for P2P SIP we want to allow people to have their own private networks. These networks may not have enough peers with public addresses, and their may be no easy way to add more. Do you agree? - philipp On 28-Feb-06, at 9:39 , Salman Abdul Baset wrote: >> In my opinion: >> - Skype works because it is one single public network, and the >> network operators can simply add >> additional superpeers whenever the ratio of superpeers to peers >> becomes too low (by adding >> computers with public addresses that run the Skype client software >> to the Internet) > > I am not sure what exactly you mean by network operators adding > superpeers. Perhaps, you mean network operator adds superpeers in its > administrative domain (or rather NAT relays). > > Skype will administer NAT relays only if it measures that existing > peers > are insufficient to meet NAT relay requirements. We conducted > experiments > in which two Skype clients were forced to use a relay for a call. > Unless > Skype is using obscured IP addresses, we do not think that calls > were ever relayed through Skype relays none of which were > administered by > Skype. > > >> I would guess that the vast majority of non-NATed computers today >> are: >> - Dial-up home users >> - Universities >> - Public web servers and similar > > Roughly, 18% of relays had hostnames ending a '.edu' in our Skype > experiments. A total of 7,500 successful calls were made. I sometimes > wonder if universities have enough bandwidth to support relays for a > significant portion of Internet call traffic. > > regards, > salman From salman at cs.columbia.edu Tue Feb 28 14:09:50 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Tue, 28 Feb 2006 14:09:50 -0500 (EST) Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: <10A1D876-8997-428A-8B60-F64A7D26F826@magma.ca> References: <0838EDF1-BF2F-46B0-B679-02C2614294A5@magma.ca> <10A1D876-8997-428A-8B60-F64A7D26F826@magma.ca> Message-ID: > What I meant by my comment was: > Say the network operators at Skype notice that the number of peers > with public IP addresses > is running low. Then they can take a few cheap PCs, load their client > software onto them, > assign them public IP addresses, and Voila! Some new peers with > public IP addresses. > > If I understand what you said in your message, you agree with the > above statement > (perhaps with some qualifications)??? It is the bandwidth problem not the public IP address problem. If the Skype network operators noticed that there were not enough relays for NATed users, they could add more bandwidth to the machines running default super nodes. In a large p2p network, it is good to have many machines with public IP addresses and broadband network connectivity because it allows p2p vendors like Skype not to buy too much bandwidth for NAT relays. > My point was that Skype can do this because there is just ONE network. > However, for P2P SIP we want to allow people to have their own > private networks. > These networks may not have enough peers with public addresses, and > their may > be no easy way to add more. > > Do you agree? I assume you want to solve the NAT traversal problem. The 'vendors' can add central TURN-equivalent servers as MSN, Yahoo, and Talk messengers do. -salman > - philipp > > On 28-Feb-06, at 9:39 , Salman Abdul Baset wrote: > > >> In my opinion: > >> - Skype works because it is one single public network, and the > >> network operators can simply add > >> additional superpeers whenever the ratio of superpeers to peers > >> becomes too low (by adding > >> computers with public addresses that run the Skype client software > >> to the Internet) > > > > I am not sure what exactly you mean by network operators adding > > superpeers. Perhaps, you mean network operator adds superpeers in its > > administrative domain (or rather NAT relays). > > > > Skype will administer NAT relays only if it measures that existing > > peers > > are insufficient to meet NAT relay requirements. We conducted > > experiments > > in which two Skype clients were forced to use a relay for a call. > > Unless > > Skype is using obscured IP addresses, we do not think that calls > > were ever relayed through Skype relays none of which were > > administered by > > Skype. > > > > > >> I would guess that the vast majority of non-NATed computers today > >> are: > >> - Dial-up home users > >> - Universities > >> - Public web servers and similar > > > > Roughly, 18% of relays had hostnames ending a '.edu' in our Skype > > experiments. A total of 7,500 successful calls were made. I sometimes > > wonder if universities have enough bandwidth to support relays for a > > significant portion of Internet call traffic. > > > > regards, > > salman > From kns10 at cs.columbia.edu Tue Feb 28 14:17:08 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Tue, 28 Feb 2006 14:17:08 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: <440389B2.5040801@research.panasonic.com> References: <440389B2.5040801@research.panasonic.com> Message-ID: <4404A1B4.10307@cs.columbia.edu> Some comments and feedback: - Seems like you propose to do P2P lookup first and then fall back to DNS (RFC3263). But since P2P lookup is slower, the reverse is probably more desirable, i.e., if DNS SRV/NAPTR exists, try that first. (or for INVITE do parallel forking to DNS and P2P destinations). - sec 8: regarding the format of records: It is probably better to reuse the existing SIP Contact header format. Since implementations will do SIP parsing anyway, and having multiple formats is just more work for translating from one to another. Thus instead of splitting IP, port, transport, etc., e.g., just put if it supports only UDP, and ignore transport= param if it supports both. Multiple ports can be specified using multiple contacts. (appendix A of my tech report http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 has another example of the data format for P2P-SIP). Also a minor nit: calling it a 'resource record' may be confusing it with DNS RR. - I am not quite clear about the purpose of 'login server'. Is this contacted every time the phone is started (like Skype's login server), in which case it is clearly not desirable unless it can be made p2p or distributed. Or is it like a certifying authority that is contacted only (once?) for issuing or renewing the certificate. Minor corrections: - page 15: typo: ...peers may be able [to] use... - sec 5.3: I think we should add TLS (either separately or same line as TCP). - 5.4: incomplete sentence 'After the association' - 5.4: '...credentials [MAY=>MUST] be needed...' I think. Similarly, '... the ON [will wish to=>MUST] authenticate the SN... - 7: typo: befind=>behind - 11.6: recorrds=>records - 12: as per my record 'Salman [Basset=>Baset]' Regards. Eunsoo Shim wrote: > We submitted an I-D that describes an architecture for P2P SIP. > You can get it from the link below until it appears in the IETF I-D > directory. > We hope this draft can help the architecture and charter discussion in BOF. > Your comments will be appreciated. > Thanks. > > Eunsoo > > http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p-arch-00.txt From sathya at research.panasonic.com Tue Feb 28 14:14:21 2006 From: sathya at research.panasonic.com (Sathya Narayanan) Date: Tue, 28 Feb 2006 14:14:21 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: References: Message-ID: <4404A10D.1010709@Research.Panasonic.COM> >I have some questions about the supernode selection criteria. It is mentionned in your draft that "it is recommended that SNs should be on the public internet" in order to receive P2P messages. > > The text in the first half of this sentence provides the context to this recommendation. The complete line is, When a P2P overlay network spans over the global Internet and contains peers private IP addresses as well as peers with public IP addresses, SNs need to perform STUN, and possibly TURN server operations thus it is RECOMMENDED that SNs should be on the public Internet, and publicly addressed [5][10]. In this line, we are specifically talking about a P2P overlay spanning the global Internet. For use cases where the P2P overlay is within a private network, as pointed out my Phillip, this recommendation doesn't apply. The only mandatory requirement is, 1) MUST be able to receive messages on predetermined protocols and ports from other SNs on the overlay network. If all the nodes are within a private network, they must be able to exchange messsages without any problem and most of the nodes can become a SN. We struggled with the wording for this requirement to make it applicable to all use-cases. If somebody has a better suggestion, we will be happy to revise the text. - Sathya >>-----Message d'origine----- >>De : p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] De la part de Eunsoo Shim >>Envoy? : mardi 28 f?vrier 2006 00:22 >>? : P2P-SIP >>Objet : [p2p-sip] I-D: An Architecture for P2P SIP >> >>We submitted an I-D that describes an architecture for P2P SIP. >>You can get it from the link below until it appears in the IETF I-D >>directory. >>We hope this draft can help the architecture and charter >>discussion in BOF. >>Your comments will be appreciated. >>Thanks. >> >>Eunsoo >> >>http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping- >>p2p-arch-00.txt >> >>Abstract >> >> This document describes an architecture for peer-to-peer >>SIP systems >> in which a separate and independent peer-to-peer overlay layer >> provides a distributed resource placement and search >>service for SIP. >> It also aims to help identify what should be specified for >> interoperation. >> >> >> >> >> >>_______________________________________________ >>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 kns10 at cs.columbia.edu Tue Feb 28 14:26:22 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Tue, 28 Feb 2006 14:26:22 -0500 Subject: [p2p-sip] Using DNS to bootstrap the DHT - corrected link In-Reply-To: References: <440389B2.5040801@research.panasonic.com> <294E6907-4DB5-4CF1-9F07-A27989A0345A@ag-projects.com> Message-ID: <4404A3DE.30203@cs.columbia.edu> Hi all, Similar to this DNS idea, I had seen a post on opendht mailing list sometime ago: Posted by Sean Rhea srhea at MIT.EDU Tue, 31 Jan 2006 16:10:34 -0500 I'm pleased to announce that there is now a DNS-based alternative. Just lookup the hostname opendht.nyuld.net, and it will return two proximal OpenDHT servers. For example: $ dig +short opendht.nyuld.net opendht.803b43c9.oasis.nyuld.net. 128.59.67.200 128.119.247.211 As you might guess from the hostname, this service is being provided by Mike Freedman's new OASIS service, soon to be published in NSDI'06: http://www.usenix.org/events/nsdi06/prelim.html Enjoy, and thank Mike for help making this happen. Sean -- Adrian Georgescu wrote: > http://www.ag-projects.com/docs/SIPThor_UsingDNSforDHTlookup.txt > > > > On Feb 28, 2006, at 11:02 AM, Adrian Georgescu wrote: > > >>Hello Eunsoo, >> >>I like much this document because it outlines several things the >>make sense and can be achieved. >> >>I personally spent some time in the bootstrap realm, what I end-up >>with is described at: >> >>http://www.ag-projects.com/doc/SIPThor_UsingDNSforDHTlookup.txt >> >>Regards, >>Adrian >> >> >>On Feb 28, 2006, at 12:22 AM, Eunsoo Shim wrote: >> >> >>>We submitted an I-D that describes an architecture for P2P SIP. >>>You can get it from the link below until it appears in the IETF I-D >>>directory. >>>We hope this draft can help the architecture and charter >>>discussion in BOF. >>>Your comments will be appreciated. >>>Thanks. >>> >>>Eunsoo >>> >>>http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping-p2p- >>>arch-00.txt >>> >>>Abstract >>> >>> This document describes an architecture for peer-to-peer SIP >>>systems >>> in which a separate and independent peer-to-peer overlay layer >>> provides a distributed resource placement and search service >>>for SIP. >>> It also aims to help identify what should be specified for >>> interoperation. >>> >>> >>> >>> >>> >>>_______________________________________________ >>>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 s.schaelle at redus.ch Tue Feb 28 14:45:04 2006 From: s.schaelle at redus.ch (=?ISO-8859-1?Q?Stefan_Sch=E4lle?=) Date: Tue, 28 Feb 2006 20:45:04 +0100 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: <4404A10D.1010709@Research.Panasonic.COM> References: <4404A10D.1010709@Research.Panasonic.COM> Message-ID: To solve the NAT Problem, read this Articel: http://www.brynosaurus.com/pub/net/p2pnat/ I think, with this solution, yout can solve the problem without any relays. Stefan From hgs at cs.columbia.edu Tue Feb 28 15:13:06 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Tue, 28 Feb 2006 15:13:06 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: References: <4404A10D.1010709@Research.Panasonic.COM> Message-ID: <4404AED2.1030801@cs.columbia.edu> This only applies to a certain subset of NATs, namely those where STUN is sufficient. Stefan Sch?lle wrote: > To solve the NAT Problem, read this Articel: > http://www.brynosaurus.com/pub/net/p2pnat/ > > I think, with this solution, yout can solve the problem without any relays. > > Stefan > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From kns10 at cs.columbia.edu Tue Feb 28 15:46:31 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Tue, 28 Feb 2006 15:46:31 -0500 Subject: [p2p-sip] FYI: I-D regarding decentralized identity infrastructure based on ENUM In-Reply-To: <44042657.8040009@enum.at> References: <44042657.8040009@enum.at> Message-ID: <4404B6A7.3010706@cs.columbia.edu> Hi Alex, Based on a quick read, I understand (correct me if I am wrong) that you propose to use E.164 identifiers instead of user at domain because: - it can be validated that the owner of this DNS record is the right person who owns the telephone number. - friends already know the phone number, so can use that to contact you in p2p. This has a problem: phone numbers are too rigid and tied to a physical port/line. Users may get E.164 number but what about entities like virtual user identifiers or devices (e.g., sip:lamp at cs.columbia.edu belongs to an electric x10 controlled lamp in our lab). Phone numbers are hard to remember and hence most users will need address book entry anyway. Thus it doesn't make much difference whether phone number, or email address (SIP URI) is used when you know the remote's public key, I think. So the real problem is the distribution of public key for the user identifier (which can be user at domain or phone number). One option could be to allow only self certifying identifiers in the p2p network and let users maintain the pet names individually and independently (or verify using any means such as your draft or trusted CA which attaches SIP URI to email address). Thus everything in your draft will work as it is, except that instead of E.164 identifier it will be SHA1(user's-public-key), and instead of ENUM it will be a DNS name of form 7A.5C....54.sha1.scid.arpa, where (7A5C...54) is SHA1(public-key). An automated program can update the DNS entry for any user by interacting with the user and making sure that the user has the corresponding public key. The interaction could be on email for example, or on VoiceXML dialog if verifying by phone. But I don't think there is much difference between this approach and the one that uses user certificates from some well known CA (certifying authority). Minor comments: In section 3.1: 'However, a centralized...still required' => can you give an example? Similarly, 'credential verification by a central component' is not true in P2P, e.g., in certificate based verifications each client can do the verification without contacting the CA every time. Alexander Mayrhofer wrote: > Hi, > > i've recently submitted a draft which describes an approach to use ENUM as a > distributed/decentralized identity architecture: > > http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-domainkeys-00.txt > > Abstract: > > This document creates a decentralized indentity infrastructure by > combining technology from E.164 Number Mapping (ENUM) and DomainKeys > Identified Mail (DKIM). This infrastructure uses E.164 numbers as > identities, ENUM DNS for key distribution, and leverages the trust > relations from ENUM validation to actual messages signed by the > number holder. > > This is currently supposed to "document the basic idea", not a perfect > protocol. Since one of the potential use cases is P2P communication i'd > appreciate any feedback about this document. > > I'm not sure if i can attend the friday afternoon p2psip session, but if > there is demand, i'd provide a few slides about the concept anyways (I'll > present it in the ENUM WG anyways). > > cheers > > alex > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From gregd at research.panasonic.com Tue Feb 28 16:16:10 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Tue, 28 Feb 2006 16:16:10 -0500 Subject: [p2p-sip] NAT and Overlay Maintenance Message-ID: <4404BD9A.5060001@research.panasonic.com> Hi, It seems that there is a robust discussion going on about P2P SIP and the participation of devices behind firewalls and NATs. As we know a large number of devices may exist behind NATs and firewalls, potentially dwarfing those available outside. There may be significant load issues if every device behind a NAT or Firewall makes use of a Super Node as the referrer for location lookups in a P2P network. I'd like to describe some of the reasoning used in describing a two layer hierarchy as described in the arch draft, and elicit further comment regarding the assumptions we made, and also the conclusions drawn. So to summarize the draft (perhaps inappropriately: please read it). we: * Classify the network into Ordinary nodes and Super Nodes. * Supernodes are involved in Overlay Maintenance * Ordinary Nodes are not. * Either node can place data records into the P2P Overlay * Super Nodes assist Ordinary Nodes to join the overlay. * after bootstrap, SNs only perform get(), update() and add() operations on behalf of ONs * Media/SIP (TURN) relaying operations may be done by non overlay nodes, or by a service co-located with an SN. At issue here: * Super Nodes are only drawn from the pool of publicly addressed/ reachable nodes. As described by Sathya, this is the inter-network view of things, based on the fact that devices behind NAT are difficult to reach reliably. For P2P overlay networks which remain within an administrative domain, the addressing requirement may not be strictly necessary (the reachability may be though). So let's explore the assumptions underpinning the idea that SNs can only be publicly addressed (with Sathya's caveat): * Inbound messages need to be supported. - an SN needs to be able to receive overlay update and lookup messages from other peer SNs * The stability of the Overlay network is at the mercy of weak nodes - where a portion of the name/location lookup information is stored behind a NAT, failure of the NAT, the NAT mapping or a TURN relay effectively isolate a portion of the overlay network. - this could cause significant damage to the data held on the overlay As such, the role of overlay maintenance nodes has been delegated to the fully reachable SNs. * Ordinary Nodes may fail without affecting the overlay maintenance. * Nodes which have a reachability impediment are not eligible for Overlay Maintenance (SN) roles. Please be aware that alternative mechanisms to handle peer-to-peer operation within an isolated domain, and then connect it to the global network (even if that global network is partly P2P). In the current draft, this scenario could use P2P internally, and may use a SIP Proxy with some P2P function (a P2PProxy) to cross an administrative domain to the global network. Some additional media relaying function may yet be required (for establishing inbound media paths for example). Please note that the P2P proxy may not need to be an SN on the global network, in order to perform the lookup operations, and advertise the domain. Greg From gregd at research.panasonic.com Tue Feb 28 16:19:49 2006 From: gregd at research.panasonic.com (Greg Daley) Date: Tue, 28 Feb 2006 16:19:49 -0500 Subject: [p2p-sip] I-D: An Architecture for P2P SIP In-Reply-To: <4404A1B4.10307@cs.columbia.edu> References: <440389B2.5040801@research.panasonic.com> <4404A1B4.10307@cs.columbia.edu> Message-ID: <4404BE75.9080908@research.panasonic.com> Hi Kundan, I liked your tech report. Kundan Singh wrote: > Some comments and feedback: > > - Seems like you propose to do P2P lookup first and then fall back to > DNS (RFC3263). But since P2P lookup is slower, the reverse is probably > more desirable, i.e., if DNS SRV/NAPTR exists, try that first. (or for > INVITE do parallel forking to DNS and P2P destinations). I take your point, although there may be other reasons to try P2P first rather than go for CS/SIP related DNS infrastructure (for example, cost, or more accurate local lookup information). > - sec 8: regarding the format of records: It is probably better to reuse > the existing SIP Contact header format. Since implementations will do > SIP parsing anyway, and having multiple formats is just more work for > translating from one to another. Thus instead of splitting IP, port, > transport, etc., e.g., just put > if it supports only UDP, and > ignore transport= param if it supports both. Multiple ports can be > specified using multiple contacts. (appendix A of my tech report > http://mice.cs.columbia.edu/getTechreport.php?techreportID=388 has > another example of the data format for P2P-SIP). Something very explicitly stated in the draft is the fact that we want to have a different (and possibly quite distinct) protocol layer undertaking the protocol operations for the P2P lookups. We may be able to make use of existing formats so long as this doesn't cause confusion about which components belong to which layer. > Also a minor nit: calling it a 'resource record' may be confusing it > with DNS RR. Suggestions are welcome. > - I am not quite clear about the purpose of 'login server'. Is this > contacted every time the phone is started (like Skype's login server), > in which case it is clearly not desirable unless it can be made p2p or > distributed. Or is it like a certifying authority that is contacted only > (once?) for issuing or renewing the certificate. It may yet be too early to say, but may have some preference not to contact a server each time. I'm actually not sure what other systems do right now with regard to login (few people are). Some people may think it is valuable to explicitly authorize participants to join the network. > Minor corrections: > > - page 15: typo: ...peers may be able [to] use... > > - sec 5.3: I think we should add TLS (either separately or same line as > TCP). UDP and TCP can both use TLS/dTLS. We describe transport security in the security considerations section. So we're not saying "in the clear" TCP. Once again, it may be too early to say. > - 5.4: incomplete sentence 'After the association' > > - 5.4: '...credentials [MAY=>MUST] be needed...' I think. Similarly, > '... the ON [will wish to=>MUST] authenticate the SN... We need to go through these requirements individually. Within the authors team we had these discussions, and made the terms flexible for the initial description. > - 7: typo: befind=>behind > > - 11.6: recorrds=>records > > - 12: as per my record 'Salman [Basset=>Baset]' > Thanks Greg. From kns10 at cs.columbia.edu Tue Feb 28 16:41:28 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Tue, 28 Feb 2006 16:41:28 -0500 Subject: [p2p-sip] New I-D: The effect of NATs on P2P SIP Overlay Architecture In-Reply-To: References: Message-ID: <4404C388.9090408@cs.columbia.edu> > The plain text version of the draft is available at > http://www.ietf.org/internet-drafts/draft-matthews-p2psip-nats-and- > overlays-00.txt I liked the analysis in the draft and agree with the conclusions. sec 4.4.3: I think Kademlia does symmetric that can fit the description there. sec 4.4.2: I think the number 160 is misleading, since usually N << 2^160, and nodes will maintain only approx O(logN) connections. For example, only 32 connections per peer for four billion peers (2^32). sec 4.3: just to understand: is static connection == pointers in DHT routing table? and dynamic == call setup? Otherwise, what does static mean? Regards. From marc1.bailly at francetelecom.com Tue Feb 28 17:55:36 2006 From: marc1.bailly at francetelecom.com (BAILLY Marc RD-CORE-LAN) Date: Tue, 28 Feb 2006 23:55:36 +0100 Subject: [p2p-sip] I-D: An Architecture for P2P SIP Message-ID: Hi Sathya, My comments inline. > >I have some questions about the supernode selection > criteria. It is mentionned in your draft that "it is > recommended that SNs should be on the public internet" in > order to receive P2P messages. > > > > > The text in the first half of this sentence provides the > context to this > recommendation. The complete line is, > > When a P2P overlay network spans > over the global Internet and contains peers private IP addresses as > well as peers with public IP addresses, SNs need to > perform STUN, and > possibly TURN server operations thus it is RECOMMENDED that SNs > should be on the public Internet, and publicly addressed [5][10]. > Maybe it would be interesting to mention that there must be enough nodes that can become super node (i.e. at least with a public IP address) in comparison to the total number of nodes (especially if TURN functions are embbeded in supernodes). I agree with this architecture proposition with this hypothesis. The question is : will it be the case in a few months or years? Regards, Marc > > >>-----Message d'origine----- > >>De : p2p-sip-bounces at cs.columbia.edu > >>[mailto:p2p-sip-bounces at cs.columbia.edu] De la part de Eunsoo Shim > >>Envoy? : mardi 28 f?vrier 2006 00:22 > >>? : P2P-SIP > >>Objet : [p2p-sip] I-D: An Architecture for P2P SIP > >> > >>We submitted an I-D that describes an architecture for P2P SIP. > >>You can get it from the link below until it appears in the IETF I-D > >>directory. > >>We hope this draft can help the architecture and charter > >>discussion in BOF. > >>Your comments will be appreciated. > >>Thanks. > >> > >>Eunsoo > >> > >>http://www.comet.columbia.edu/~eunsoo/ietf/draft-shim-sipping- > >>p2p-arch-00.txt > >> > >>Abstract > >> > >> This document describes an architecture for peer-to-peer > >>SIP systems > >> in which a separate and independent peer-to-peer overlay layer > >> provides a distributed resource placement and search > >>service for SIP. > >> It also aims to help identify what should be specified for > >> interoperation. > >> > >> > >> > >> > >> > >>_______________________________________________ > >>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 marc1.bailly at francetelecom.com Wed Feb 22 08:05:35 2006 From: marc1.bailly at francetelecom.com (BAILLY Marc RD-CORE-LAN) Date: Wed, 22 Feb 2006 14:05:35 +0100 Subject: [p2p-sip] New paper about Skype Message-ID: Hi, I just would like to mention a new paper about Skype analysis that could be added to the "Research and Reading" section of p2psip.org There are some interesting statistics about Skype p2p network. http://saikat.guha.cc/pub/iptps06-skype.pdf Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060222/e921dddf/attachment.html