From hgs at cs.columbia.edu Fri Jan 6 09:00:20 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Fri, 06 Jan 2006 09:00:20 -0500 Subject: [p2p-sip] OpenWengo Message-ID: <43BE77F4.5030105@cs.columbia.edu> Another SIP client, but open source: http://www.openwengo.com/ Does not appear to run in p2p mode, but might be a basis for experiments in that space, given the GPL license. (My only involvement with the client is that I downloaded it; don't know whether it is any good or fries your machine.) From enrico.marocco at TILAB.COM Mon Jan 9 05:52:15 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Mon, 09 Jan 2006 11:52:15 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: <43BE77F4.5030105@cs.columbia.edu> References: <43BE77F4.5030105@cs.columbia.edu> Message-ID: <43C2405F.2000606@tilab.com> Henning Schulzrinne wrote: > Another SIP client, but open source: http://www.openwengo.com/ It looks very skypish :-) > Does not appear to run in p2p mode, but might be a basis for experiments > in that space, given the GPL license. I completely agree that an open source approach would be great for both supporting the specification and facilitating its adoption. However, I think it would be most useful (and maybe easyer) to implement the p2p support on an existing open source stack; in this way, test applications will be simple and won't have to care about complex gui stuff, while the (as minimal as possible) effort to add p2p features to existing programs using that stack, can be made by official developers. Is anyone interested in such a kind of project? Among available stacks, my preference would go to nokia's sofia-sip (http://sofia-sip.sourceforge.net/), which is pretty modular and well documented. Cheers Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From henry at pulver.com Mon Jan 9 15:02:00 2006 From: henry at pulver.com (Henry Sinnreich) Date: Mon, 9 Jan 2006 14:02:00 -0600 Subject: [p2p-sip] OpenWengo In-Reply-To: <43C2405F.2000606@tilab.com> Message-ID: <200601092005.k09K23Gt014088@cs.columbia.edu> Enrico, > my preference would go to nokia's sofia-sip (http://sofia- > sip.sourceforge.net/), which is pretty modular and well documented. It appears the Nokia SIP UA does not seem to support Windows desktops or the Pocket PC. Is this correct? Henry -----Original Message----- From: Enrico Marocco [mailto:enrico.marocco at TILAB.COM] Sent: Monday, January 09, 2006 4:52 AM To: Henning Schulzrinne Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] OpenWengo Henning Schulzrinne wrote: > Another SIP client, but open source: http://www.openwengo.com/ It looks very skypish :-) > Does not appear to run in p2p mode, but might be a basis for experiments > in that space, given the GPL license. I completely agree that an open source approach would be great for both supporting the specification and facilitating its adoption. However, I think it would be most useful (and maybe easyer) to implement the p2p support on an existing open source stack; in this way, test applications will be simple and won't have to care about complex gui stuff, while the (as minimal as possible) effort to add p2p features to existing programs using that stack, can be made by official developers. Is anyone interested in such a kind of project? Among available stacks, my preference would go to nokia's sofia-sip (http://sofia-sip.sourceforge.net/), which is pretty modular and well documented. Cheers Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From Kasthuriram_V at infosys.com Tue Jan 10 03:42:02 2006 From: Kasthuriram_V at infosys.com (Kasthuri Ram V.) Date: Tue, 10 Jan 2006 14:12:02 +0530 Subject: [p2p-sip] OpenWengo Message-ID: <1136882522.5752.18.camel@samish.india.ascend.com> > Is anyone interested in such a kind of project? Yes. > Among available stacks, my preference would go to nokia's sofia-sip > (http://sofia-sip.sourceforge.net/), which is pretty modular and well > documented. I was more interested in GNU osip library http://www.gnu.org/software/osip/osip.html sofia-sip looks to have better documentation than osip. I would be interested in knowing any other advantages of sofia-sip over osip or vovida's sip stack with reference to p2p. Thanks, Ram -- **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From enrico.marocco at TILAB.COM Tue Jan 10 04:05:33 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Tue, 10 Jan 2006 10:05:33 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: <200601092005.k09K23Gt014088@cs.columbia.edu> References: <200601092005.k09K23Gt014088@cs.columbia.edu> Message-ID: <43C378DD.5020607@tilab.com> Henry Sinnreich wrote: >>my preference would go to nokia's sofia-sip (http://sofia- >>sip.sourceforge.net/), which is pretty modular and well documented. > > It appears the Nokia SIP UA does not seem to support Windows desktops or the > Pocket PC. > > Is this correct? I haven't tried myself, but, at least on windows, I'd guess it does. It uses a module which provides abstraction of system specific tasks (eg memory management, threads, sockets, etc) and I can see a lot of windows stuff there (#ifdef.... #include ...). Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From enrico.marocco at TILAB.COM Tue Jan 10 04:07:10 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Tue, 10 Jan 2006 10:07:10 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: References: <43BE77F4.5030105@cs.columbia.edu> <43C2405F.2000606@tilab.com> Message-ID: <43C3793E.5010208@tilab.com> Aymeric Moizard wrote: >> I completely agree that an open source approach would be great for both >> supporting the specification and facilitating its adoption. However, I >> think it would be most useful (and maybe easyer) to implement the p2p >> support on an existing open source stack; in this way, test applications >> will be simple and won't have to care about complex gui stuff, while the >> (as minimal as possible) effort to add p2p features to existing programs >> using that stack, can be made by official developers. >> >> Is anyone interested in such a kind of project? > > I maintain the eXosip stack. (http://www.antisip.com/download/) > It's wriiten in C, portable, simple to use, simple to extend and it's > GPL code. > > I would (and will anyway) personally help much for adding p2p support in > it. Obviously the willingness of the maintainer to cooperate is a big bonus for the stack ;-) I think a good starting point should be the implementation on the existing api of a simple application acting as a p2p node; if your stack is well suited for such task, it could be a valid choice IMHO. Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From Kai.Vehmanen at nokia.com Tue Jan 10 05:09:33 2006 From: Kai.Vehmanen at nokia.com (Kai.Vehmanen@nokia.com) Date: Tue, 10 Jan 2006 12:09:33 +0200 Subject: [p2p-sip] OpenWengo In-Reply-To: <43C3793E.5010208@tilab.com> Message-ID: <719D5CCC2F6E3644B0A9F5C9B1D0008801567D4F@esebe104.NOE.Nokia.com> Hi, On 10 Jan 2006, Enrico Marocco wrote: > Aymeric Moizard wrote: >> I maintain the eXosip stack. (http://www.antisip.com/download/) >> It's wriiten in C, portable, simple to use, simple to extend and it's >> GPL code. >> >> I would (and will anyway) personally help much for adding p2p support >> in it. > >Obviously the willingness of the maintainer to cooperate is a >big bonus for the stack ;-) well, some of us in the Sofia-SIP project would be also interested in this work. It seems we are all here. :) Anyways, not to turn this into full marketing thread, eXosip/osip is a good combo as well, and there are also couple of other very good alternatives available now such as the new pjsip stack (plus of course vovida and resip): http://www.bulukucing.org/pjsip.html A comparison of basic features is available at: http://www.huisetalage.nl/sip/stacks.pdf A more complete feature set SIP/SDP wise for Sofia-SIP can be found at: http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html As for our win32/pocketpc support, we basicly have the code working under both cygwin/mingw and natively compiled with visualc, but no pocketpc-support yet. Some people have been testing the code on OSX. >I think a good starting point should be the implementation on >the existing api of a simple application acting as a p2p node; >if your stack is well suited for such task, it could be a >valid choice IMHO. With Sofia-SIP, an easy start could be for instance to add p2p-node functionality to the the gaim+sofia-sip combo: http://sofia-sip.sourceforge.net/ssip-gst.html Especially without audio support (no gstreamer needed => turn gaim into a p2p SIP-IM app), this is very easy combo for developers, as both Gaim and Sofia-SIP are well documented and have lots of example code available. Similar thing can be of course done with other stacks as well. -- http://research.nokia.com/people/kai_vehmanen/ Networking Technologies Laboratory, Nokia Research Center From enrico.marocco at TILAB.COM Tue Jan 10 06:17:45 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Tue, 10 Jan 2006 12:17:45 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: <1136882522.5752.18.camel@samish.india.ascend.com> References: <1136882522.5752.18.camel@samish.india.ascend.com> Message-ID: <43C397D9.2020501@tilab.com> Kasthuri Ram V. wrote: >>Among available stacks, my preference would go to nokia's sofia-sip >>(http://sofia-sip.sourceforge.net/), which is pretty modular and well >>documented. > > > I was more interested in GNU osip library > http://www.gnu.org/software/osip/osip.html > > sofia-sip looks to have better documentation than osip. I would be > interested in knowing any other advantages of sofia-sip over osip or > vovida's sip stack with reference to p2p. Just for implementing a p2p node (ie sending REGISTER requests and repling with 200/302 responses), I think the documentation is the main advantage. On the other hand, osip and vovida provide low level functionalities, while sofia-sip (as also eXosip) has a nice high level api. This should have influence on the decision in so far as we consider the integration of p2p support in such stack. If developing a p2p node we were able to integrate the functionalities in a middle layer of the stack (I figure a kind of routing logic in the transaction layer), the p2p support would be easily made available for the layers above (eg user agent, event server, ecc). Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From jack at fauche.org Tue Jan 10 07:46:38 2006 From: jack at fauche.org (Aymeric Moizard) Date: Tue, 10 Jan 2006 13:46:38 +0100 (CET) Subject: [p2p-sip] OpenWengo Message-ID: On Mon, 9 Jan 2006, Enrico Marocco wrote: > Henning Schulzrinne wrote: >> Another SIP client, but open source: http://www.openwengo.com/ > > It looks very skypish :-) and based on deprecated source of eXosip... >> Does not appear to run in p2p mode, but might be a basis for experiments >> in that space, given the GPL license. > > I completely agree that an open source approach would be great for both > supporting the specification and facilitating its adoption. However, I > think it would be most useful (and maybe easyer) to implement the p2p > support on an existing open source stack; in this way, test applications > will be simple and won't have to care about complex gui stuff, while the > (as minimal as possible) effort to add p2p features to existing programs > using that stack, can be made by official developers. > > Is anyone interested in such a kind of project? I maintain the eXosip stack. (http://www.antisip.com/download/) It's wriiten in C, portable, simple to use, simple to extend and it's GPL code. I would (and will anyway) personally help much for adding p2p support in it. Aymeric > Among available stacks, my preference would go to nokia's sofia-sip > (http://sofia-sip.sourceforge.net/), which is pretty modular and well > documented. > > Cheers > Enrico > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin at tilab.com. Thank you > ==================================================================== > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From Kasthuriram_V at infosys.com Tue Jan 10 07:09:36 2006 From: Kasthuriram_V at infosys.com (Kasthuri Ram V.) Date: Tue, 10 Jan 2006 17:39:36 +0530 Subject: [p2p-sip] OpenWengo In-Reply-To: References: Message-ID: <1136894976.5752.26.camel@samish.india.ascend.com> On Tue, 2006-01-10 at 13:46 +0100, Aymeric Moizard wrote: > > Is anyone interested in such a kind of project? > > I maintain the eXosip stack. (http://www.antisip.com/download/) > It's wriiten in C, portable, simple to use, simple to extend and it's GPL code. > > I would (and will anyway) personally help much for adding p2p support in it. Sure. That would be great! I was exploring eXosip a few days back. Only thing that put me off with eXosip was that I couldn't find enough documentation on it. Would be glad if a good documentation is available. (If one is not available, atleast a wiki on antisip site would have helped things). Cheers, Ram -- > > Aymeric > > > Among available stacks, my preference would go to nokia's sofia-sip > > (http://sofia-sip.sourceforge.net/), which is pretty modular and well > > documented. > > > > Cheers > > Enrico > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > > > ==================================================================== > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please send an e_mail to > > MailAdmin at tilab.com. Thank you > > ==================================================================== > > > > _______________________________________________ > > 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 **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From lists at bulukucing.org Tue Jan 10 08:33:11 2006 From: lists at bulukucing.org (Benny Prijono) Date: Tue, 10 Jan 2006 13:33:11 +0000 Subject: [p2p-sip] OpenWengo In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D0008801567D4F@esebe104.NOE.Nokia.com> References: <719D5CCC2F6E3644B0A9F5C9B1D0008801567D4F@esebe104.NOE.Nokia.com> Message-ID: <43C3B797.6010902@bulukucing.org> Kai.Vehmanen at nokia.com wrote: > Anyways, not to turn this into full marketing thread, eXosip/osip > is a good combo as well, and there are also couple of other > very good alternatives available now such as the new > pjsip stack (plus of course vovida and resip): > > http://www.bulukucing.org/pjsip.html > Thanks Kai for spreading the news. Just to inform that pjsip site has moved to http://www.pjproject.net pjsip as it stands lacks the impressive features of resiprocate or sofia-sip; only up to transaction layer has been implemented and tested, although i'm working daily to improve the situation. But documentation is complete, I hope. regards, Benny From eunsoo at research.panasonic.com Tue Jan 10 09:33:09 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 10 Jan 2006 09:33:09 -0500 Subject: [p2p-sip] OpenWengo In-Reply-To: References: Message-ID: <43C3C5A5.8050205@research.panasonic.com> This is great. It is a fantastic idea to have an open source stack supporting the (future) P2P SIP spec the IETF will come up. BTW, I am interested in Java-based implementation. Would anyone recommend any particular Java-based SIP stack implementation? Thanks. Eunsoo Aymeric Moizard wrote: >On Mon, 9 Jan 2006, Enrico Marocco wrote: > > > >>Henning Schulzrinne wrote: >> >> >>>Another SIP client, but open source: http://www.openwengo.com/ >>> >>> >>It looks very skypish :-) >> >> > >and based on deprecated source of eXosip... > > > >>>Does not appear to run in p2p mode, but might be a basis for experiments >>>in that space, given the GPL license. >>> >>> >>I completely agree that an open source approach would be great for both >>supporting the specification and facilitating its adoption. However, I >>think it would be most useful (and maybe easyer) to implement the p2p >>support on an existing open source stack; in this way, test applications >>will be simple and won't have to care about complex gui stuff, while the >>(as minimal as possible) effort to add p2p features to existing programs >>using that stack, can be made by official developers. >> >>Is anyone interested in such a kind of project? >> >> > >I maintain the eXosip stack. (http://www.antisip.com/download/) >It's wriiten in C, portable, simple to use, simple to extend and it's GPL code. > >I would (and will anyway) personally help much for adding p2p support in it. > >Aymeric > > > >>Among available stacks, my preference would go to nokia's sofia-sip >>(http://sofia-sip.sourceforge.net/), which is pretty modular and well >>documented. >> >>Cheers >>Enrico >> >> >>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. >> >>==================================================================== >>CONFIDENTIALITY NOTICE >>This message and its attachments are addressed solely to the persons >>above and may contain confidential information. If you have received >>the message in error, be informed that any use of the content hereof >>is prohibited. Please return it immediately to the sender and delete >>the message. Should you have any questions, please send an e_mail to >>MailAdmin at tilab.com. Thank you >>==================================================================== >> >>_______________________________________________ >>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 henry at pulver.com Tue Jan 10 09:34:33 2006 From: henry at pulver.com (Henry Sinnreich) Date: Tue, 10 Jan 2006 08:34:33 -0600 Subject: [p2p-sip] Evaluating SIP implementations In-Reply-To: <719D5CCC2F6E3644B0A9F5C9B1D0008801567D4F@esebe104.NOE.Nokia.com> Message-ID: <200601101434.k0AEYjGt022854@cs.columbia.edu> Thanks for all the good information about available SIP implementations! It is hard to judge how much compliant SIP implementations are unless we go by some objective and agreed criteria. http://www.huisetalage.nl/sip/stacks.pdf is a good start but some more is required. Here is a proposed list of RFCs that a mixed P2P and CS SIP solution has to support. A matrix with check boxes would be the next step. Maybe Robert Sparks can also advise us how the SIPit does it now. I would be interested: 1. Is this list reasonable? 2. How does one check actual compliance with such a list? 3. How would a _reasonable_ compliance matrix look like? Here is what I mean (some links may be stale already). What do you think? Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device Requirements and Configuration" http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002. Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003. Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. Summers, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2003. Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. Mahy, R., Biggs, B. and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. Arkko, J., Torvinen, V., Camarillo, G., Niemi, A. and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003. Rosenberg, J. and H. Schulzrinne, "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing", RFC 3581, August 2003. Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. Peterson, J., Liu, H., Yu, J. and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004. Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004. Mahy, R., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", draft-ietf-sipping-cc-framework-03 (work in progress), October 2003. Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-08 (work in progress), December 2004. Rosenberg, J., "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", draft-ietf-sip-callee-caps-03 (work in progress), January 2004. Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), September 2004. Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sip-connect-reuse-03 (work in progress), October 2004. Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. Levin, O., "Suppression of REFER Implicit Subscription", draft-ietf-sip-refer-with-norefersub-00 (work in progress), January 2005. Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples", draft-ietf-sipping-service-examples-07 (work in progress), July 2004. Rosenberg, J., "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-05 (work in progress), November 2004. Sparks, R., "Session Initiation Protocol Torture Test Messages", draft-ietf-sipping-torture-tests-04 (work in progress), July 2004. Sparks, R. and A. Johnston, "Session Initiation Protocol Call Control - Transfer", draft-ietf-sipping-cc-transfer-03 (work in progress), October 2004. Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-05 (work in progress), November 2004.. Camarillo, G. and A. Roach, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-subscribe-02 (work in progress), January 2005. Jennings, C. and J. Peterson, "Certificate Management Service for SIP", draft-ietf-sipping-certs-01 (work in progress), October 2004. Wijk, A., "Framework of requirements for real-time text conversation using SIP.", draft-ietf-sipping-toip-00 (work in progress), October 2004. RFC 2327: "SDP: Session Description Protocol" by M. Handley, V. Jacobson, IETF, April 1998 RFC 3999: "The TEL URI for Telephone Numbers" by H. Schulzrinne, IETF, June 2004. Johnston, H. Sinnreich, A. Clark, and A. Pendleton, " SIP Service Quality Reporting Event" IETF Internet-Draft, October 2004, Work in progress. RFC 3550: "RTP: A Transport Protocol for Real-Time Applications" by H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, IETF, July 2003. RFC 3551: "RTP Profile for Audio and Video Conferences with Minimal Control " by H. Schulzrinne and S. Casner, IETF, July 2003. RFC 3761: "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)" by P. Falstrom and M. Mealing, IETF, April 2004. RFC 3952: "Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech" by A. Duric, S. Andersen, IETF, December 2004. RFC 3611: "RTP Control Protocol Extended Reports (RTCP XR)" by T. Friedman, Ed., R. Caceres, Ed., A. Clark, November 2003. RFC 3711: " The Secure Real-time Transport Protocol (SRTP)," by M. Baugher et al, March 2004 RFC 3830: "MIKEY: Multimedia Internet KEYing" by J. Arkko et al, August 2004 "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" by J. Arkko et al, draft-ietf-mmusic-kmgmt-ext-12.txt, November 2004. RFC 2246: "The TLS Protocol Version 1.0" by T. Dierks and C. Allen, IETF, January 1999 RFC 3489: "STUN-Simple Traversal of UDP Through NAT" by J. Rosenberg et al. IETF, March 2003. "Traversal Using Relay NAT" by J. Rosenberg, R. Mahy, and C. Huitema, IETF Internet-Draft, October 2004. "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols" by J. Rosenberg, IETF Internet Draft, October 2004. "Symmetric RTP and RTCP Considered Helpful" by D. Wing, IETF Internet Draft, October 2004. RFC 2833: "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals" by H. Schuzrinne and S. Petrack, IETF, May 2000. Thanks, Henry -----Original Message----- From: Kai.Vehmanen at nokia.com [mailto:Kai.Vehmanen at nokia.com] Sent: Tuesday, January 10, 2006 4:10 AM To: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] OpenWengo Hi, On 10 Jan 2006, Enrico Marocco wrote: > Aymeric Moizard wrote: >> I maintain the eXosip stack. (http://www.antisip.com/download/) >> It's wriiten in C, portable, simple to use, simple to extend and it's >> GPL code. >> >> I would (and will anyway) personally help much for adding p2p support >> in it. > >Obviously the willingness of the maintainer to cooperate is a >big bonus for the stack ;-) well, some of us in the Sofia-SIP project would be also interested in this work. It seems we are all here. :) Anyways, not to turn this into full marketing thread, eXosip/osip is a good combo as well, and there are also couple of other very good alternatives available now such as the new pjsip stack (plus of course vovida and resip): http://www.bulukucing.org/pjsip.html A comparison of basic features is available at: http://www.huisetalage.nl/sip/stacks.pdf A more complete feature set SIP/SDP wise for Sofia-SIP can be found at: http://sofia-sip.sourceforge.net/refdocs/sofia_sip_conformance.html As for our win32/pocketpc support, we basicly have the code working under both cygwin/mingw and natively compiled with visualc, but no pocketpc-support yet. Some people have been testing the code on OSX. >I think a good starting point should be the implementation on >the existing api of a simple application acting as a p2p node; >if your stack is well suited for such task, it could be a >valid choice IMHO. With Sofia-SIP, an easy start could be for instance to add p2p-node functionality to the the gaim+sofia-sip combo: http://sofia-sip.sourceforge.net/ssip-gst.html Especially without audio support (no gstreamer needed => turn gaim into a p2p SIP-IM app), this is very easy combo for developers, as both Gaim and Sofia-SIP are well documented and have lots of example code available. Similar thing can be of course done with other stacks as well. -- http://research.nokia.com/people/kai_vehmanen/ Networking Technologies Laboratory, Nokia Research Center From lists at bulukucing.org Tue Jan 10 09:59:23 2006 From: lists at bulukucing.org (Benny Prijono) Date: Tue, 10 Jan 2006 14:59:23 +0000 Subject: [p2p-sip] OpenWengo In-Reply-To: <43C3C5A5.8050205@research.panasonic.com> References: <43C3C5A5.8050205@research.panasonic.com> Message-ID: <43C3CBCB.50607@bulukucing.org> Eunsoo Shim wrote: > This is great. > It is a fantastic idea to have an open source stack supporting the > (future) P2P SIP spec the IETF will come up. > Now if only the spec is available so that us mere programmers can begin to code.. ;) > BTW, I am interested in Java-based implementation. Would anyone > recommend any particular Java-based SIP stack implementation? > Thanks. > I personally like JAIN SIP. The design is good, with clear separation from stateless message, transaction layer, and dialog layer. At least from what I read from the documentation, which is excellent btw. An open source JAIN SIP stack is also available: http://snad.ncsl.nist.gov/proj/iptel/ regards, Benny > Eunsoo > From ssal at intracom.gr Tue Jan 10 11:03:49 2006 From: ssal at intracom.gr (Sotiris Salloum) Date: Tue, 10 Jan 2006 17:03:49 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: <43C3C5A5.8050205@research.panasonic.com> Message-ID: <200601101448.k0AEmpq25282@hal.intranet.gr> Hi, Jain SIP from NIST, http://java.sun.com/products/jain/certprod_table.html https://jain-sip.dev.java.net/ Regards Sotiris Salloum MSc. Staff Engineer R&D INTRACOM SA - Content Delivery System Athens, Greece 19002, www.intracom.com -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eunsoo Shim Sent: Tuesday, January 10, 2006 3:33 PM To: Aymeric Moizard Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] OpenWengo This is great. It is a fantastic idea to have an open source stack supporting the (future) P2P SIP spec the IETF will come up. BTW, I am interested in Java-based implementation. Would anyone recommend any particular Java-based SIP stack implementation? Thanks. Eunsoo Aymeric Moizard wrote: >On Mon, 9 Jan 2006, Enrico Marocco wrote: > > > >>Henning Schulzrinne wrote: >> >> >>>Another SIP client, but open source: http://www.openwengo.com/ >>> >>> >>It looks very skypish :-) >> >> > >and based on deprecated source of eXosip... > > > >>>Does not appear to run in p2p mode, but might be a basis for experiments >>>in that space, given the GPL license. >>> >>> >>I completely agree that an open source approach would be great for both >>supporting the specification and facilitating its adoption. However, I >>think it would be most useful (and maybe easyer) to implement the p2p >>support on an existing open source stack; in this way, test applications >>will be simple and won't have to care about complex gui stuff, while the >>(as minimal as possible) effort to add p2p features to existing programs >>using that stack, can be made by official developers. >> >>Is anyone interested in such a kind of project? >> >> > >I maintain the eXosip stack. (http://www.antisip.com/download/) >It's wriiten in C, portable, simple to use, simple to extend and it's GPL code. > >I would (and will anyway) personally help much for adding p2p support in it. > >Aymeric > > > >>Among available stacks, my preference would go to nokia's sofia-sip >>(http://sofia-sip.sourceforge.net/), which is pretty modular and well >>documented. >> >>Cheers >>Enrico >> >> >>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. >> >>==================================================================== >>CONFIDENTIALITY NOTICE >>This message and its attachments are addressed solely to the persons >>above and may contain confidential information. If you have received >>the message in error, be informed that any use of the content hereof >>is prohibited. Please return it immediately to the sender and delete >>the message. Should you have any questions, please send an e_mail to >>MailAdmin at tilab.com. Thank you >>==================================================================== >> >>_______________________________________________ >>p2p-sip mailing list >>p2p-sip at cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >> >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From eunsoo at research.panasonic.com Tue Jan 10 10:18:59 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 10 Jan 2006 10:18:59 -0500 Subject: [p2p-sip] OpenWengo In-Reply-To: <43C3CBCB.50607@bulukucing.org> References: <43C3C5A5.8050205@research.panasonic.com> <43C3CBCB.50607@bulukucing.org> Message-ID: <43C3D063.5010204@research.panasonic.com> Benny Prijono wrote: > Eunsoo Shim wrote: > >> This is great. >> It is a fantastic idea to have an open source stack supporting the >> (future) P2P SIP spec the IETF will come up. >> > > Now if only the spec is available so that us mere programmers can > begin to code.. ;) > May the WG be formed soo..n! >> BTW, I am interested in Java-based implementation. Would anyone >> recommend any particular Java-based SIP stack implementation? >> Thanks. >> > > I personally like JAIN SIP. The design is good, with clear separation > from stateless message, transaction layer, and dialog layer. At least > from what I read from the documentation, which is excellent btw. An > open source JAIN SIP stack is also available: > > http://snad.ncsl.nist.gov/proj/iptel/ > Thanks for the information about JAIN SIP stack. Regards, Eunsoo >> From jack at fauche.org Tue Jan 10 11:26:42 2006 From: jack at fauche.org (Aymeric Moizard) Date: Tue, 10 Jan 2006 17:26:42 +0100 (CET) Subject: [p2p-sip] OpenWengo In-Reply-To: <1136894976.5752.26.camel@samish.india.ascend.com> References: <1136894976.5752.26.camel@samish.india.ascend.com> Message-ID: On Tue, 10 Jan 2006, Kasthuri Ram V. wrote: > > On Tue, 2006-01-10 at 13:46 +0100, Aymeric Moizard wrote: >> I maintain the eXosip stack. (http://www.antisip.com/download/) It's >> wriiten in C, portable, simple to use, simple to extend and it's GPL >> code. >> >> I would (and will anyway) personally help much for adding p2p support >> in it. > > Sure. That would be great! > > I was exploring eXosip a few days back. Only thing that put me off with > eXosip was that I couldn't find enough documentation on it. Would be > glad if a good documentation is available. (If one is not available, > atleast a wiki on antisip site would have helped things). http://www.antisip.com/documentation/eXosip2 Then, for howto: http://www.antisip.com/documentation/eXosip2/modules.html The doc is doxygen generated and thus included in the code. Aymeric > Cheers, > Ram > -- > >> >> Aymeric >> >>> Among available stacks, my preference would go to nokia's sofia-sip >>> (http://sofia-sip.sourceforge.net/), which is pretty modular and well >>> documented. >>> >>> Cheers >>> Enrico >>> >>> >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. >>> >>> ==================================================================== >>> CONFIDENTIALITY NOTICE >>> This message and its attachments are addressed solely to the persons >>> above and may contain confidential information. If you have received >>> the message in error, be informed that any use of the content hereof >>> is prohibited. Please return it immediately to the sender and delete >>> the message. Should you have any questions, please send an e_mail to >>> MailAdmin at tilab.com. Thank you >>> ==================================================================== >>> >>> _______________________________________________ >>> 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 > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > From lists at bulukucing.org Tue Jan 10 11:09:05 2006 From: lists at bulukucing.org (Benny Prijono) Date: Tue, 10 Jan 2006 16:09:05 +0000 Subject: [p2p-sip] Evaluating SIP implementations In-Reply-To: <200601101434.k0AEYjGt022854@cs.columbia.edu> References: <200601101434.k0AEYjGt022854@cs.columbia.edu> Message-ID: <43C3DC21.8030303@bulukucing.org> Henry Sinnreich wrote: > Here is a proposed list of RFCs that a mixed P2P and CS SIP solution has to > support. A matrix with check boxes would be the next step. Maybe Robert > Sparks can also advise us how the SIPit does it now. > > I would be interested: > > 1. Is this list reasonable? > 2. How does one check actual compliance with such a list? Your list with 50+ RFCs looks absolutely horrifying! It will take longer than forever and twice infinite number of man months to support all of them. A better approach would be to divide the requirements based on the features claimed by a device, just like what draft-sinnreich-sipdev-req-08.txt is doing. It will make them more manageable. > 3. How would a _reasonable_ compliance matrix look like? *Reasonable* is really the key here. I've tried once to translate RFC 3261 (and its close friends) into requirement items, and ~5 RFCs can easily produce more than 200 specific requirement items, because basicly each paragraph in the RFC produces one requirement item. Here's what my requirement document looks like: http://anonymous at svn.pjproject.net/repos/pjproject/trunk/pjsip/docs/PJSIP-Testing.pdf The list gets so exhaustive that I don't even bother to read it again! But if we must make a (strict) compliance matrix, then probably it will look horrifyingly similar to that. > Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device Requirements and > Configuration" > http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt Btw the link should read http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt (missing "o" in ".org"). regards, Benny From henry at pulver.com Tue Jan 10 11:44:33 2006 From: henry at pulver.com (Henry Sinnreich) Date: Tue, 10 Jan 2006 10:44:33 -0600 Subject: [p2p-sip] Evaluating SIP implementations In-Reply-To: <43C3DC21.8030303@bulukucing.org> Message-ID: <200601101644.k0AGicGt017578@cs.columbia.edu> Benny Prijono wrote: > Your list with 50+ RFCs looks absolutely horrifying! Unfortunately I have to agree with you, but how can we dismiss all this work performed in the IETF? What would we say to the authors? The whole list is actually much bigger, if you only take a look at: http://rfc3261.net/ published by Nils Ohlmeier cc:'d here. Thanks, Henry -----Original Message----- From: Benny Prijono [mailto:lists at bulukucing.org] Sent: Tuesday, January 10, 2006 10:09 AM To: henry at pulver.com Cc: Kai.Vehmanen at nokia.com; p2p-sip at cs.columbia.edu; 'Robert Sparks'; 'Alan Johnston' Subject: Re: [p2p-sip] Evaluating SIP implementations Henry Sinnreich wrote: > Here is a proposed list of RFCs that a mixed P2P and CS SIP solution has to > support. A matrix with check boxes would be the next step. Maybe Robert > Sparks can also advise us how the SIPit does it now. > > I would be interested: > > 1. Is this list reasonable? > 2. How does one check actual compliance with such a list? Your list with 50+ RFCs looks absolutely horrifying! It will take longer than forever and twice infinite number of man months to support all of them. A better approach would be to divide the requirements based on the features claimed by a device, just like what draft-sinnreich-sipdev-req-08.txt is doing. It will make them more manageable. > 3. How would a _reasonable_ compliance matrix look like? *Reasonable* is really the key here. I've tried once to translate RFC 3261 (and its close friends) into requirement items, and ~5 RFCs can easily produce more than 200 specific requirement items, because basicly each paragraph in the RFC produces one requirement item. Here's what my requirement document looks like: http://anonymous at svn.pjproject.net/repos/pjproject/trunk/pjsip/docs/PJSIP-Te sting.pdf The list gets so exhaustive that I don't even bother to read it again! But if we must make a (strict) compliance matrix, then probably it will look horrifyingly similar to that. > Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device Requirements and > Configuration" > http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt Btw the link should read http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt (missing "o" in ".org"). regards, Benny From eunsoo at research.panasonic.com Tue Jan 10 11:57:58 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 10 Jan 2006 11:57:58 -0500 Subject: [p2p-sip] Evaluating SIP implementations In-Reply-To: <200601101644.k0AGicGt017578@cs.columbia.edu> References: <200601101644.k0AGicGt017578@cs.columbia.edu> Message-ID: <43C3E796.6070802@research.panasonic.com> I don't know whether it is the best or feasible for SIP but please let me remind you of an approach taken for MPEG-4. They defined multiple 'profiles'. Each profile has a set of requirements and an implementation may be compliant with only one or multiple profiles. So compliance is per profile rather than for the whole MPEG-4 spec. If this approach is feasible for SIP, it can ease the horror. Thanks. Eunsoo Henry Sinnreich wrote: >Benny Prijono wrote: > > > >>Your list with 50+ RFCs looks absolutely horrifying! >> >> > >Unfortunately I have to agree with you, but how can we dismiss all this work >performed in the IETF? What would we say to the authors? > >The whole list is actually much bigger, if you only take a look at: > >http://rfc3261.net/ published by Nils Ohlmeier cc:'d here. > >Thanks, Henry > > >-----Original Message----- >From: Benny Prijono [mailto:lists at bulukucing.org] >Sent: Tuesday, January 10, 2006 10:09 AM >To: henry at pulver.com >Cc: Kai.Vehmanen at nokia.com; p2p-sip at cs.columbia.edu; 'Robert Sparks'; 'Alan >Johnston' >Subject: Re: [p2p-sip] Evaluating SIP implementations > >Henry Sinnreich wrote: > > >>Here is a proposed list of RFCs that a mixed P2P and CS SIP solution has >> >> >to > > >>support. A matrix with check boxes would be the next step. Maybe Robert >>Sparks can also advise us how the SIPit does it now. >> >>I would be interested: >> >>1. Is this list reasonable? >> >> > > 2. How does one check actual compliance with such a list? > >Your list with 50+ RFCs looks absolutely horrifying! It will take >longer than forever and twice infinite number of man months to support >all of them. > >A better approach would be to divide the requirements based on the >features claimed by a device, just like what >draft-sinnreich-sipdev-req-08.txt is doing. It will make them more >manageable. > > > 3. How would a _reasonable_ compliance matrix look like? > >*Reasonable* is really the key here. >I've tried once to translate RFC 3261 (and its close friends) into >requirement items, and ~5 RFCs can easily produce more than 200 >specific requirement items, because basicly each paragraph in the RFC >produces one requirement item. Here's what my requirement document >looks like: > >http://anonymous at svn.pjproject.net/repos/pjproject/trunk/pjsip/docs/PJSIP-Te >sting.pdf > >The list gets so exhaustive that I don't even bother to read it again! >But if we must make a (strict) compliance matrix, then probably it >will look horrifyingly similar to that. > > > >>Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device Requirements >> >> >and > > >>Configuration" >>http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt >> >> > >Btw the link should read >http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt >(missing "o" in ".org"). > >regards, >Benny > > > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From tme at multicasttech.com Tue Jan 10 12:22:13 2006 From: tme at multicasttech.com (Marshall Eubanks) Date: Tue, 10 Jan 2006 12:22:13 -0500 Subject: [p2p-sip] Evaluating SIP implementations In-Reply-To: <43C3E796.6070802@research.panasonic.com> References: <200601101644.k0AGicGt017578@cs.columbia.edu> <43C3E796.6070802@research.panasonic.com> Message-ID: <1694DC18-9E8B-4848-A09F-7BC1549B3DCE@multicasttech.com> Yes, and then the Internet Streaming Media Alliance (ISMA.tv) picks the particular profiles that they will require interoperability for, which become the ones to use. Note that this is an industry forum. That seems appropriate for a body that is basically trying to decide what part of a large protocol to actually use. So, there is a SIP Forum, with a Technical Working Group http://www.sipforum.org/content/view/28/139/ but I know little about them. Is this something that they are doing ? Is it something that they should be doing ? On Jan 10, 2006, at 11:57 AM, Eunsoo Shim wrote: > I don't know whether it is the best or feasible for SIP but please let > me remind you of an approach taken for MPEG-4. > They defined multiple 'profiles'. Each profile has a set of > requirements > and an implementation may be compliant with only one or multiple > profiles. > So compliance is per profile rather than for the whole MPEG-4 spec. > If this approach is feasible for SIP, it can ease the horror. > Thanks. > > Eunsoo > Regards Marshall Eubanks > > Henry Sinnreich wrote: > >> Benny Prijono wrote: >> >> >> >>> Your list with 50+ RFCs looks absolutely horrifying! >>> >>> >> >> Unfortunately I have to agree with you, but how can we dismiss all >> this work >> performed in the IETF? What would we say to the authors? >> >> The whole list is actually much bigger, if you only take a look at: >> >> http://rfc3261.net/ published by Nils Ohlmeier cc:'d here. >> >> Thanks, Henry >> >> >> -----Original Message----- >> From: Benny Prijono [mailto:lists at bulukucing.org] >> Sent: Tuesday, January 10, 2006 10:09 AM >> To: henry at pulver.com >> Cc: Kai.Vehmanen at nokia.com; p2p-sip at cs.columbia.edu; 'Robert >> Sparks'; 'Alan >> Johnston' >> Subject: Re: [p2p-sip] Evaluating SIP implementations >> >> Henry Sinnreich wrote: >> >> >>> Here is a proposed list of RFCs that a mixed P2P and CS SIP >>> solution has >>> >>> >> to >> >> >>> support. A matrix with check boxes would be the next step. Maybe >>> Robert >>> Sparks can also advise us how the SIPit does it now. >>> >>> I would be interested: >>> >>> 1. Is this list reasonable? >>> >>> >>> 2. How does one check actual compliance with such a list? >> >> Your list with 50+ RFCs looks absolutely horrifying! It will take >> longer than forever and twice infinite number of man months to >> support >> all of them. >> >> A better approach would be to divide the requirements based on the >> features claimed by a device, just like what >> draft-sinnreich-sipdev-req-08.txt is doing. It will make them more >> manageable. >> >>> 3. How would a _reasonable_ compliance matrix look like? >> >> *Reasonable* is really the key here. >> I've tried once to translate RFC 3261 (and its close friends) into >> requirement items, and ~5 RFCs can easily produce more than 200 >> specific requirement items, because basicly each paragraph in the RFC >> produces one requirement item. Here's what my requirement document >> looks like: >> >> http://anonymous at svn.pjproject.net/repos/pjproject/trunk/pjsip/ >> docs/PJSIP-Te >> sting.pdf >> >> The list gets so exhaustive that I don't even bother to read it >> again! >> But if we must make a (strict) compliance matrix, then probably it >> will look horrifyingly similar to that. >> >> >> >>> Sinnreich, H., Lass S., Stredicke C: " IP Telephony Device >>> Requirements >>> >>> >> and >> >> >>> Configuration" >>> http://www.ietf.rg/internet-drafts/draft-sinnreich-sipdev-req-08.txt >>> >>> >> >> Btw the link should read >> http://www.ietf.org/internet-drafts/draft-sinnreich-sipdev-req-08.txt >> (missing "o" in ".org"). >> >> regards, >> Benny >> >> >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From dbarrett at quinthar.com Tue Jan 10 14:51:03 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 10 Jan 2006 11:51:03 -0800 Subject: [p2p-sip] Requirements Explosion (was: Evaluating SIP implementations) In-Reply-To: <200601101644.k0AGicGt017578@cs.columbia.edu> References: <200601101644.k0AGicGt017578@cs.columbia.edu> Message-ID: <43C41027.60206@quinthar.com> Henry Sinnreich wrote: > Benny Prijono wrote: > >>Your list with 50+ RFCs looks absolutely horrifying! > > Unfortunately I have to agree with you, but how can we dismiss all this work > performed in the IETF? What would we say to the authors? Is it just me or is this the elephant in the room that nobody discusses? For example, SIP alone is documented in over *30 different RFCs* according to Henry's list, and that's just *one* protocol. To do anything meaningful you also need SDP, STUN, TURN, ICE, RTP, RTCP, etc, etc. Every one of these requires its own parsers, and its own state machines. Given this, just building a reasonably compliant "Hello world!" VoIP app is an incredible undertaking. Furthermore, while a totally vanilla VoIP app can be simplified with off-the-shelf libraries, bending the RFCs in ways the authors didn't intend (such as P2P-SIP) is a Herculean effort because it's not just one library that needs tweaking, but many -- each with its own maintainer, own build process, own CVS repository, update cycle, bug database, etc. What I think would help SIP adoption more than anything is a "SIP 2.0" that is a distillation of everything learned up to date, re-unified into a single document with a single grammar, parser, and update cycle. Personally, I would pull together the essential elements of the various text protocols (SIP, SDP, STUN, TURN, ICE, and some DHT-maintenance commands), but leave RTP and the binary protocols separate. With this tighter, smaller standard, true interoperability within this minimal subset might have a greater chance of succeeding. Until then, given that *nobody* understand the big picture entirely, and even *fewer* have the resources to build it, everyone will just do the best they can and we'll end up basically where we are -- with a wide collection of "SIP compliant" devices and services that, despite the best intentions of the designers, are mostly incompatible, or that only achieve compatibility through extreme testing and custom tweaking. Am I a lone pessimist in this view, or would you agree? -david From royrr at us.saic.com Tue Jan 10 15:09:51 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Tue, 10 Jan 2006 15:09:51 -0500 Subject: [p2p-sip] Requirements Explosion (was: Evaluating SIPimplemen tations) Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F622BF5@0591-its-exmp01.us.saic.com> Hi, Folks: I would say that it is not an elephant in the room. In fact, if you include all SIP RFCs, it only exemplifies some additional aspects of SIP RFC 3261. To summarize those in relation to p2p-SIP works, there is not much in addition to the base RFC 3261. While we go on working on p2p-SIP, it will not only use all RFCs of SIP, we will also scan all of the information of p2p works that are being progressing independent of SIP in addition to DNS, IPv6, routing, AAA/DIAMETER, Security, Mobile IP4/IPv6, mobile routers/networks (NEMO), MANET, and others. What we will do eventually is to scan all the relevant points of those on-going works for p2p-SIP without blindly reading all of the pages of all documents. Well there may be some lapses as we mover forward as it happens for all cases, we do need to face the challenge. Otherwise, our works will be obsolete and will not meet the needs with the test of time. Who will do these challenging works? The answer is: It is all of us together. Best regards, Radhika -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu ] On Behalf Of David Barrett Sent: Tuesday, January 10, 2006 2:51 PM To: henry at pulver.com Cc: 'Nils Ohlmeier'; 'Alan Johnston'; 'Robert Sparks'; p2p-sip at cs.columbia.edu; Kai.Vehmanen at nokia.com Subject: Re: [p2p-sip] Requirements Explosion (was: Evaluating SIPimplementations) Henry Sinnreich wrote: > Benny Prijono wrote: > >>Your list with 50+ RFCs looks absolutely horrifying! > > Unfortunately I have to agree with you, but how can we dismiss all this work > performed in the IETF? What would we say to the authors? Is it just me or is this the elephant in the room that nobody discusses? For example, SIP alone is documented in over *30 different RFCs* according to Henry's list, and that's just *one* protocol. To do anything meaningful you also need SDP, STUN, TURN, ICE, RTP, RTCP, etc, etc. Every one of these requires its own parsers, and its own state machines. Given this, just building a reasonably compliant "Hello world!" VoIP app is an incredible undertaking. Furthermore, while a totally vanilla VoIP app can be simplified with off-the-shelf libraries, bending the RFCs in ways the authors didn't intend (such as P2P-SIP) is a Herculean effort because it's not just one library that needs tweaking, but many -- each with its own maintainer, own build process, own CVS repository, update cycle, bug database, etc. What I think would help SIP adoption more than anything is a "SIP 2.0" that is a distillation of everything learned up to date, re-unified into a single document with a single grammar, parser, and update cycle. Personally, I would pull together the essential elements of the various text protocols (SIP, SDP, STUN, TURN, ICE, and some DHT-maintenance commands), but leave RTP and the binary protocols separate. With this tighter, smaller standard, true interoperability within this minimal subset might have a greater chance of succeeding. Until then, given that *nobody* understand the big picture entirely, and even *fewer* have the resources to build it, everyone will just do the best they can and we'll end up basically where we are -- with a wide collection of "SIP compliant" devices and services that, despite the best intentions of the designers, are mostly incompatible, or that only achieve compatibility through extreme testing and custom tweaking. Am I a lone pessimist in this view, or would you agree? -david -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060110/e45e02cc/attachment.html From eunsoo at research.panasonic.com Tue Jan 10 16:13:40 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 10 Jan 2006 16:13:40 -0500 Subject: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations) In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622BF5@0591-its-exmp01.us.saic .com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622BF5@0591-its-exmp01.us.saic. com> Message-ID: <43C42384.3050702@research.panasonic.com> I appreciate the spirit of 'facing challenges' and also understand the importance of defining what means 'SIP compliant'. Certainly it will become an issue for P2P SIP. Eventually we may have to define 'P2P SIP compliance' that is based on 'SIP compliance'. However, please let me suggest we take a caution with respect to the issue. I doubt that we need to scan all the documents relevant to SIP and P2P for specifying P2P SIP at the current stage. Maybe we have to do so in the far future. As a number of people said before, we may as well focus on 'basic' features of SIP in designing P2P SIP in the beginning. I still hope we can focus on basic problems before attacking more complex problems and all the features of SIP (that are growing continuously). Furthermore, if we take a certain approach in designing P2P SIP (like the one presented as 'DHT-based approach'), we can have a decent modularity in P2P SIP that means the P2P aspects (building and maintain an overlay network and performing resource search and placement) are separated from SIP call control features quite decently. In that case, we will have to worry less about all the details of SIP features than otherwise. This architecture design is still an open issue and I'd like to have it not forgotten. Thanks. Eunsoo Roy, Radhika R. wrote: > Hi, Folks: > > I would say that it is not an elephant in the room. In fact, if you > include all SIP RFCs, it only exemplifies some additional aspects of > SIP RFC 3261. To summarize those in relation to p2p-SIP works, there > is not much in addition to the base RFC 3261. > > While we go on working on p2p-SIP, it will not only use all RFCs of > SIP, we will also scan all of the information of p2p works that are > being progressing independent of SIP in addition to DNS, IPv6, > routing, AAA/DIAMETER, Security, Mobile IP4/IPv6, mobile > routers/networks (NEMO), MANET, and others. > > What we will do eventually is to scan all the relevant points of those > on-going works for p2p-SIP without blindly reading all of the pages of > all documents. Well there may be some lapses as we mover forward as it > happens for all cases, we do need to face the challenge. Otherwise, > our works will be obsolete and will not meet the needs with the test > of time. > > Who will do these challenging works? The answer is: It is all of us > together. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Tuesday, January 10, 2006 2:51 PM > To: henry at pulver.com > Cc: 'Nils Ohlmeier'; 'Alan Johnston'; 'Robert Sparks'; > p2p-sip at cs.columbia.edu; Kai.Vehmanen at nokia.com > Subject: Re: [p2p-sip] Requirements Explosion (was: Evaluating > SIPimplementations) > > Henry Sinnreich wrote: > >> Benny Prijono wrote: > >> > >>>Your list with 50+ RFCs looks absolutely horrifying! > >> > >> Unfortunately I have to agree with you, but how can we dismiss all > this work > >> performed in the IETF? What would we say to the authors? > > Is it just me or is this the elephant in the room that nobody discusses? > > For example, SIP alone is documented in over *30 different RFCs* > > according to Henry's list, and that's just *one* protocol. To do > > anything meaningful you also need SDP, STUN, TURN, ICE, RTP, RTCP, etc, > > etc. Every one of these requires its own parsers, and its own state > > machines. Given this, just building a reasonably compliant "Hello > > world!" VoIP app is an incredible undertaking. > > Furthermore, while a totally vanilla VoIP app can be simplified with > > off-the-shelf libraries, bending the RFCs in ways the authors didn't > > intend (such as P2P-SIP) is a Herculean effort because it's not just one > > library that needs tweaking, but many -- each with its own maintainer, > > own build process, own CVS repository, update cycle, bug database, etc. > > > What I think would help SIP adoption more than anything is a "SIP 2.0" > > that is a distillation of everything learned up to date, re-unified into > > a single document with a single grammar, parser, and update cycle. > > Personally, I would pull together the essential elements of the various > > text protocols (SIP, SDP, STUN, TURN, ICE, and some DHT-maintenance > > commands), but leave RTP and the binary protocols separate. With this > > tighter, smaller standard, true interoperability within this minimal > > subset might have a greater chance of succeeding. > > Until then, given that *nobody* understand the big picture entirely, and > > even *fewer* have the resources to build it, everyone will just do the > > best they can and we'll end up basically where we are -- with a wide > > collection of "SIP compliant" devices and services that, despite the > > best intentions of the designers, are mostly incompatible, or that only > > achieve compatibility through extreme testing and custom tweaking. > > Am I a lone pessimist in this view, or would you agree? > > -david > >------------------------------------------------------------------------ > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From dbarrett at quinthar.com Tue Jan 10 17:06:44 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 10 Jan 2006 14:06:44 -0800 Subject: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations) In-Reply-To: <43C42384.3050702@research.panasonic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622BF5@0591-its-exmp01.us.saic. com> <43C42384.3050702@research.panasonic.com> Message-ID: <43C42FF4.8070705@quinthar.com> Eunsoo Shim wrote: > However, please let me suggest we take a caution with respect to the issue. > I doubt that we need to scan all the documents relevant to SIP and P2P > for specifying P2P SIP at the current stage. Maybe we have to do so in > the far future. I agree this is what needs to be done to stay relevant in the real world. But it's a tacit acknowledgment that SIP is too difficult to even attempt "correctly". This seems a red flag if even an IETF working group -- with no deadlines or market pressures -- is unwilling to tackle SIP as a whole. It feels like we're adding another level to a house of cards. When I was doing iGlance (www.iglance.com) I started with the attitude "Yes! Let's do this thing 100% SIP compliant." But my productivity dropped to basically zero once I took up the reigns. Thus my attitude went to, "Ok, let's strive for 100% compliance later, but let's get the basics up first." And then "Ok, even the basics are too complicated to worry about now, so let's stay compliant with the state machines and worry about the syntax later." And then "Boy, these state machines are restrictive, let's just stay SIP influenced for now, so maybe someday we can come back and do it 'right'." Henning sold me on SIP in person, and I still believe it's an awesome, well-designed, rich and robust architecture. But it's grown out of control to the point it is brittle and cumbersome -- the antithesis of what it was intended to be. I believe were we to circle the wagons a bit wider and be more deliberate with compliance (and non-compliance), we'd move faster and produce a more usable result. But so long as we attempt to comply with everything ever written on SIP (and its pantheon of supporting protocols), we'll never agree on anything, we'll never be able to verify success, and the final result will be so cumbersome (by definition, more cumbersome that what is already in place), that it won't matter. So again I'd propose the P2P-SIP group focus less on seamless integration with the chaotic SIP universe as a whole, and more on creating an ordered, simple subset of the universe that is easy to understand, covers all the bases that real applications deal with in the real world, and "just works" with minimum dependency on external documents. -david From henry at pulver.com Tue Jan 10 17:27:54 2006 From: henry at pulver.com (Henry Sinnreich) Date: Tue, 10 Jan 2006 16:27:54 -0600 Subject: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations) In-Reply-To: <43C42FF4.8070705@quinthar.com> Message-ID: <200601102228.k0AMS5Gt003268@cs.columbia.edu> >creating an ordered, simple subset of the universe that is easy to >understand, covers all the bases that real applications deal with in the >real world, and "just works" with minimum dependency on external documents. This is an excellent goal. The work will probably have to be a volunteer effort, since it would be difficult to make this a charter objective for a (hopefully) IETF WG. Such a document could be submitted eventually to the P2P SIP WG only after it will be formed. Any volunteers for a minimum and doable list of requirements for the P2P SIP peer node? Thanks, Henry -----Original Message----- From: David Barrett [mailto:dbarrett at quinthar.com] Sent: Tuesday, January 10, 2006 4:07 PM To: Eunsoo Shim Cc: Roy, Radhika R.; henry at pulver.com; Nils Ohlmeier; Robert Sparks; Alan Johnston; Kai.Vehmanen at nokia.com; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations) Eunsoo Shim wrote: > However, please let me suggest we take a caution with respect to the issue. > I doubt that we need to scan all the documents relevant to SIP and P2P > for specifying P2P SIP at the current stage. Maybe we have to do so in > the far future. I agree this is what needs to be done to stay relevant in the real world. But it's a tacit acknowledgment that SIP is too difficult to even attempt "correctly". This seems a red flag if even an IETF working group -- with no deadlines or market pressures -- is unwilling to tackle SIP as a whole. It feels like we're adding another level to a house of cards. When I was doing iGlance (www.iglance.com) I started with the attitude "Yes! Let's do this thing 100% SIP compliant." But my productivity dropped to basically zero once I took up the reigns. Thus my attitude went to, "Ok, let's strive for 100% compliance later, but let's get the basics up first." And then "Ok, even the basics are too complicated to worry about now, so let's stay compliant with the state machines and worry about the syntax later." And then "Boy, these state machines are restrictive, let's just stay SIP influenced for now, so maybe someday we can come back and do it 'right'." Henning sold me on SIP in person, and I still believe it's an awesome, well-designed, rich and robust architecture. But it's grown out of control to the point it is brittle and cumbersome -- the antithesis of what it was intended to be. I believe were we to circle the wagons a bit wider and be more deliberate with compliance (and non-compliance), we'd move faster and produce a more usable result. But so long as we attempt to comply with everything ever written on SIP (and its pantheon of supporting protocols), we'll never agree on anything, we'll never be able to verify success, and the final result will be so cumbersome (by definition, more cumbersome that what is already in place), that it won't matter. So again I'd propose the P2P-SIP group focus less on seamless integration with the chaotic SIP universe as a whole, and more on creating an ordered, simple subset of the universe that is easy to understand, covers all the bases that real applications deal with in the real world, and "just works" with minimum dependency on external documents. -david From eunsoo at research.panasonic.com Tue Jan 10 17:42:11 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 10 Jan 2006 17:42:11 -0500 Subject: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations) In-Reply-To: <43C42FF4.8070705@quinthar.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622BF5@0591-its-exmp01.us.saic. com> <43C42384.3050702@research.panasonic.com> <43C42FF4.8070705@quinthar.com> Message-ID: <43C43843.7010500@research.panasonic.com> David Barrett wrote: > Eunsoo Shim wrote: > >> However, please let me suggest we take a caution with respect to the >> issue. >> I doubt that we need to scan all the documents relevant to SIP and >> P2P for specifying P2P SIP at the current stage. Maybe we have to do >> so in the far future. > > > I agree this is what needs to be done to stay relevant in the real > world. But it's a tacit acknowledgment that SIP is too difficult to > even attempt "correctly". I respect your experiences with SIP and your thoughts after that and I am not a person to argue about them. Even if I can, I would not like to do it. Just let me supplement my statements with respect to your comment above. I did not mean that SIP was too difficult to even attempt correctly. The background of my statement in my previous message was that I did not think P2P SIP would require lots of changes in many aspects of SIP. I think (actually believe) we can design P2P SIP in such a way that the P2P aspects are fairly independent of SIP call control procedures, probably independent of most of the RFCs relevant to SIP. > This seems a red flag if even an IETF working group -- with no > deadlines or market pressures -- is unwilling to tackle SIP as a whole. Again, I do not think I raised such a flag. Obviously I am not representing an IETF working group, either. I expressed just an opinion shared with a number of people that P2P SIP could be designed with little or minimum change in SIP. > It feels like we're adding another level to a house of cards. > > When I was doing iGlance (www.iglance.com) I started with the attitude > "Yes! Let's do this thing 100% SIP compliant." But my productivity > dropped to basically zero once I took up the reigns. Thus my attitude > went to, "Ok, let's strive for 100% compliance later, but let's get > the basics up first." And then "Ok, even the basics are too > complicated to worry about now, so let's stay compliant with the state > machines and worry about the syntax later." And then "Boy, these > state machines are restrictive, let's just stay SIP influenced for > now, so maybe someday we can come back and do it 'right'." > > Henning sold me on SIP in person, and I still believe it's an awesome, > well-designed, rich and robust architecture. But it's grown out of > control to the point it is brittle and cumbersome -- the antithesis of > what it was intended to be. > > > I believe were we to circle the wagons a bit wider and be more > deliberate with compliance (and non-compliance), we'd move faster and > produce a more usable result. > > But so long as we attempt to comply with everything ever written on > SIP (and its pantheon of supporting protocols), we'll never agree on > anything, we'll never be able to verify success, and the final result > will be so cumbersome (by definition, more cumbersome that what is > already in place), that it won't matter. > > So again I'd propose the P2P-SIP group focus less on seamless > integration with the chaotic SIP universe as a whole, and more on > creating an ordered, simple subset of the universe that is easy to > understand, covers all the bases that real applications deal with in > the real world, and "just works" with minimum dependency on external > documents. > > -david Regards, Eunsoo From royrr at us.saic.com Tue Jan 10 22:27:02 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Tue, 10 Jan 2006 22:27:02 -0500 Subject: [p2p-sip] Requirements Explosion Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F6233D6@0591-its-exmp01.us.saic.com> H, Eunsoo: Right. What we need to do is to develop a basic core spec that will define the base p2p-SIP protocol (just recall what SIP has been before 3261) that will make SIP as p2p protocol augmenting its utility as well as it will be compliant of SIP. Once we start the base work, we will then look into this what we are missing. I am sure people are here to provide comments and will judge its value what we mean by p2p-SIP protocol (by the way, it may be a baby step). On the other hand, if we look into the big picture of the entire SIP works in the IETF, what are those? Are these not some basic extensions of SIP RFC 3261? Are there any fundamental changes in the direction of SIP protocol? I do not think so. There are some important problems remain to be solved in the FW/NAT areas. However, it is NOT SIP problems. It is the problem of the IP network/transport layer for the entire Internet that is NOT allowing to SIP signaling and its payload to cross the "traditional" FWs/NATs for a session that last for hours. In addition, multipoint conferencing problems using multiple media are yet to be solved satisfactorily even for the centralized case. We expect, p2p-SIP will also be able to solve FWs/NATs crossing and multipoint conferencing to the best satisfaction of SIP eventually. So, we have a long way to go to solve all those problems from pure p2p point of view as we see the limitations of SIP are becoming apparent in the context of the p2p public Internet. Best regards, Radhika -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu ] On Behalf Of Eunsoo Shim Sent: Tuesday, January 10, 2006 4:14 PM To: Roy, Radhika R. Cc: Nils Ohlmeier; Alan Johnston; Robert Sparks; henry at pulver.com; p2p-sip at cs.columbia.edu; Kai.Vehmanen at nokia.com Subject: Re: [p2p-sip] Requirements Explosion(was: EvaluatingSIPimplementations) I appreciate the spirit of 'facing challenges' and also understand the importance of defining what means 'SIP compliant'. Certainly it will become an issue for P2P SIP. Eventually we may have to define 'P2P SIP compliance' that is based on 'SIP compliance'. However, please let me suggest we take a caution with respect to the issue. I doubt that we need to scan all the documents relevant to SIP and P2P for specifying P2P SIP at the current stage. Maybe we have to do so in the far future. As a number of people said before, we may as well focus on 'basic' features of SIP in designing P2P SIP in the beginning. I still hope we can focus on basic problems before attacking more complex problems and all the features of SIP (that are growing continuously). Furthermore, if we take a certain approach in designing P2P SIP (like the one presented as 'DHT-based approach'), we can have a decent modularity in P2P SIP that means the P2P aspects (building and maintain an overlay network and performing resource search and placement) are separated from SIP call control features quite decently. In that case, we will have to worry less about all the details of SIP features than otherwise. This architecture design is still an open issue and I'd like to have it not forgotten. Thanks. Eunsoo Roy, Radhika R. wrote: > Hi, Folks: > > I would say that it is not an elephant in the room. In fact, if you > include all SIP RFCs, it only exemplifies some additional aspects of > SIP RFC 3261. To summarize those in relation to p2p-SIP works, there > is not much in addition to the base RFC 3261. > > While we go on working on p2p-SIP, it will not only use all RFCs of > SIP, we will also scan all of the information of p2p works that are > being progressing independent of SIP in addition to DNS, IPv6, > routing, AAA/DIAMETER, Security, Mobile IP4/IPv6, mobile > routers/networks (NEMO), MANET, and others. > > What we will do eventually is to scan all the relevant points of those > on-going works for p2p-SIP without blindly reading all of the pages of > all documents. Well there may be some lapses as we mover forward as it > happens for all cases, we do need to face the challenge. Otherwise, > our works will be obsolete and will not meet the needs with the test > of time. > > Who will do these challenging works? The answer is: It is all of us > together. > > Best regards, > > Radhika > From dbarrett at quinthar.com Wed Jan 11 00:44:35 2006 From: dbarrett at quinthar.com (David Barrett) Date: Tue, 10 Jan 2006 21:44:35 -0800 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F6233D6@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233D6@0591-its-exmp01.us.saic.com> Message-ID: <43C49B43.3010401@quinthar.com> Roy, Radhika R. wrote: > There are some important problems remain to be solved in the FW/NAT areas. > However, it is NOT SIP problems. It is the problem of the IP > network/transport layer for the entire Internet that is NOT allowing to SIP > signaling and its payload to cross the "traditional" FWs/NATs for a session > that last for hours. Well, saying "it's not SIP's problem" is small comfort if it renders SIP unusable (or prohibitively difficult) in the real world. If the goal of the P2P-SIP group is to improve interoperability between P2P implementations of SIP, and if the #1 P2P complexity is NAT/FW traversal, then it sure would be nice if the P2P-SIP group did something about it. A unified INVITE/ACK grammar that automatically pierced NATs would simplify the overall architecture tremendously and make SIP a more practical solution for real-world use on the real-world internet. -david From kns10 at cs.columbia.edu Wed Jan 11 01:53:57 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Wed, 11 Jan 2006 01:53:57 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <200601102228.k0AMS5Gt003268@cs.columbia.edu> References: <200601102228.k0AMS5Gt003268@cs.columbia.edu> Message-ID: <43C4AB85.5000106@cs.columbia.edu> >>creating an ordered, simple subset of the universe that is easy to >>understand, covers all the bases that real applications deal with in the >>real world, and "just works" with minimum dependency on external documents. > I think this is a very hard problem because of the interpretation of "real" by different people at different times. For each X in conferencing, voicemail, NAT traversal, ..., Is X part of a real app? Such questions can be either yes or no depending on what you want to build. For example, I don't need NAT travesal for my Intranet phone, and I don't need Voicemail for my SIP-IM client. So essentially this becomes a product or application requirement but not a protocol requirement. I this we should first focus on the protocol requirement, and then build the application satisfying the base protocol requirement. And later, incrementally add new application requirements in the software. Regarding the number of RFCs/drafts in SIP, I think it signifies a good sign that SIP can be extended for various new requirements without affecting the base SIP protocol. Thus a "real" application can choose which RFCs/drafts (application requirements) to implement and still be interoperable with other application that implement the same drafts/RFCs (requirements). For example, in Henning's class, students built basic SIP-based video phones with limited features that just works as part of their class assignments. So SIP is not that hard, as it sounded in the earlier postings. As for P2P-SIP, I think it should just depend on the base protocol RFC 3261. Unless we want to create specific profiles such as P2P-SIP-NAT-Conf, P2P-RTP/SDP-SIP, or P2P-SIP-Presence-IM. If we agree on the 'external DHT/P2P' architecture, P2P-SIP can further reduce to just P2P-Location-Service without depending on SIP at all. So in that case all the RFCs/drafts become external to the protocol, and we need only one 'Location-Service' protocol. So in my opinion, to get started we should pick an existing location service protocol (using get/put APIs) and create opensource software that glues some existing SIP and DHT implementations using this location service protocol. Even if we don't agree on 'external DHT/P2P' architecture, a standardized location-service API helps to interoperate various SIP implementations with various P2P networks, even if the P2P network maintenance is done by, say, SIP. Regarding th location-service API/protocol: starting point could be the get/put/remove APIs with some identity assertion and verifications. (e.g., see the OpenDHT paper - http://www.opendht.org). Soon we realize that we need another set of protocol/APIs for join/leave/lookup for adding new services. For example, if a Turn server wants to get discovered or a SIP presence server wants to get discovered on P2P. So the service can join on P2P network indicating it's service profile (based on one or more RFC/draft) and identity (or domain that the service is serving). Others can lookup the service on P2P using some criteria (such as service profile, proximity, etc). This is similar to DNS SRV/NAPTR on P2P. So the protocol can evolve in two dimensions: location-service (get/put/remove) and P2P-service (join/leave/lookup). Our implementation may initially implement either or both for a basic SIP phone, and later add various application requirements (e.g., presence, NAT traversal, etc). A generic location-service protocol can be specified using existing RFC formats such as Sun RPC, XML-RPC or SOAP -- this is the on-the-wire protocol. A particular location-service is specific for the type of lookup you want to do and defines the 'data-format'. So a SIP-location-service will implement something like get(user at domain), put(user at domain,contacts), etc. So SIP-LS will define a specific 'data format' for parameters to get/put. Similarly, a Presence-LS will define how presence data gets stored (e.g., just put the PUBLISH message body with a given key, thus reusing the existing work done in SIPPING/SIP). A generic P2P-service protocol should be specified using some common on-the-wire protocol so that it can work with various P2P networks. A specific P2P-service is implemented using some underlying P2P network, say Chord, Kademlia, or Pastry. The API can be something like: join(service-name, serving-identifier, server-addresses); & leave(...). server-addresses := lookup(service-name, serving-identifier, criteria); (server-addresses,identifier) := lookup(service-name, criteria); where criteria could be something like fastest, closest, etc. The location-service and P2P-service can be layered on top of each other but that is an implementation choice. For example, all P2P-SIP proxies can provie get/put/remove as well as join and lookup among each other using service-name = "SIP-LS" and serving-identifier="example.net" if serving users at example.net. Similarly, all P2P-SIP clients can just join using service-name = "SIP-LS" and serving-identifier="user at example.net". A SIP client that as external DHT interface, can just call get/put/remove to any existing provider DHT node. and so on. So in conclusion, I think we should start with defining the generic location-service and P2P-service protocol, and then specific data format for SIP-location-service, and implement it for basic audio-only no-NAT SIP user agent and basic SIP proxy and registrar using some existing DHT/P2P algorithm. Comments? Regards, Kundan From enrico.marocco at TILAB.COM Wed Jan 11 03:36:24 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Wed, 11 Jan 2006 09:36:24 +0100 Subject: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations) In-Reply-To: <200601102228.k0AMS5Gt003268@cs.columbia.edu> References: <200601102228.k0AMS5Gt003268@cs.columbia.edu> Message-ID: <43C4C388.1090304@tilab.com> Henry Sinnreich wrote: >>creating an ordered, simple subset of the universe that is easy to >>understand, covers all the bases that real applications deal with in the >>real world, and "just works" with minimum dependency on external documents. > > This is an excellent goal. The work will probably have to be a volunteer > effort, since it would be difficult to make this a charter objective for a > (hopefully) IETF WG. Such a document could be submitted eventually to the > P2P SIP WG only after it will be formed. > > Any volunteers for a minimum and doable list of requirements for the P2P SIP > peer node? I'm not quite sure I understand which kind of requirements we are talking about; can you better explain the relation between such list and the Salman's one (draft-baset-sipping-p2preq-00)? Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From ag at ag-projects.com Wed Jan 11 03:55:16 2006 From: ag at ag-projects.com (Adrian Georgescu) Date: Wed, 11 Jan 2006 09:55:16 +0100 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C4AB85.5000106@cs.columbia.edu> References: <200601102228.k0AMS5Gt003268@cs.columbia.edu> <43C4AB85.5000106@cs.columbia.edu> Message-ID: <06C2CA10-1079-4135-A84A-FBE94AA19523@ag-projects.com> Hi Kundan, It is a brilliant description of indeed achievable goals. Regards, Adrian On Jan 11, 2006, at 7:53 AM, Kundan Singh wrote: >>> creating an ordered, simple subset of the universe that is easy to >>> understand, covers all the bases that real applications deal with >>> in the >>> real world, and "just works" with minimum dependency on external >>> documents. >> > > I think this is a very hard problem because of the interpretation of > "real" by different people at different times. For each X in > conferencing, voicemail, NAT traversal, ..., Is X part of a real app? > Such questions can be either yes or no depending on what you want to > build. For example, I don't need NAT travesal for my Intranet > phone, and > I don't need Voicemail for my SIP-IM client. So essentially this > becomes > a product or application requirement but not a protocol requirement. > > I this we should first focus on the protocol requirement, and then > build > the application satisfying the base protocol requirement. And later, > incrementally add new application requirements in the software. > > Regarding the number of RFCs/drafts in SIP, I think it signifies a > good > sign that SIP can be extended for various new requirements without > affecting the base SIP protocol. Thus a "real" application can choose > which RFCs/drafts (application requirements) to implement and still be > interoperable with other application that implement the same drafts/ > RFCs > (requirements). For example, in Henning's class, students built basic > SIP-based video phones with limited features that just works as > part of > their class assignments. So SIP is not that hard, as it sounded in the > earlier postings. > > As for P2P-SIP, I think it should just depend on the base protocol RFC > 3261. Unless we want to create specific profiles such as > P2P-SIP-NAT-Conf, P2P-RTP/SDP-SIP, or P2P-SIP-Presence-IM. > > If we agree on the 'external DHT/P2P' architecture, P2P-SIP can > further > reduce to just P2P-Location-Service without depending on SIP at > all. So > in that case all the RFCs/drafts become external to the protocol, > and we > need only one 'Location-Service' protocol. > So in my opinion, to get started we should pick an existing location > service protocol (using get/put APIs) and create opensource software > that glues some existing SIP and DHT implementations using this > location > service protocol. > > Even if we don't agree on 'external DHT/P2P' architecture, a > standardized location-service API helps to interoperate various SIP > implementations with various P2P networks, even if the P2P network > maintenance is done by, say, SIP. > > Regarding th location-service API/protocol: starting point could be > the > get/put/remove APIs with some identity assertion and verifications. > (e.g., see the OpenDHT paper - http://www.opendht.org). > > Soon we realize that we need another set of protocol/APIs for > join/leave/lookup for adding new services. For example, if a Turn > server > wants to get discovered or a SIP presence server wants to get > discovered > on P2P. So the service can join on P2P network indicating it's service > profile (based on one or more RFC/draft) and identity (or domain that > the service is serving). Others can lookup the service on P2P using > some > criteria (such as service profile, proximity, etc). This is similar to > DNS SRV/NAPTR on P2P. > > So the protocol can evolve in two dimensions: location-service > (get/put/remove) and P2P-service (join/leave/lookup). Our > implementation > may initially implement either or both for a basic SIP phone, and > later > add various application requirements (e.g., presence, NAT > traversal, etc). > > A generic location-service protocol can be specified using existing > RFC > formats such as Sun RPC, XML-RPC or SOAP -- this is the on-the-wire > protocol. A particular location-service is specific for the type of > lookup you want to do and defines the 'data-format'. So a > SIP-location-service will implement something like get(user at domain), > put(user at domain,contacts), etc. So SIP-LS will define a specific 'data > format' for parameters to get/put. Similarly, a Presence-LS will > define > how presence data gets stored (e.g., just put the PUBLISH message body > with a given key, thus reusing the existing work done in SIPPING/SIP). > > A generic P2P-service protocol should be specified using some common > on-the-wire protocol so that it can work with various P2P networks. A > specific P2P-service is implemented using some underlying P2P network, > say Chord, Kademlia, or Pastry. The API can be something like: > join(service-name, serving-identifier, server-addresses); & leave > (...). > server-addresses := lookup(service-name, serving-identifier, > criteria); > (server-addresses,identifier) := lookup(service-name, criteria); > where criteria could be something like fastest, closest, etc. > > The location-service and P2P-service can be layered on top of each > other > but that is an implementation choice. For example, all P2P-SIP proxies > can provie get/put/remove as well as join and lookup among each other > using service-name = "SIP-LS" and serving-identifier="example.net" if > serving users at example.net. Similarly, all P2P-SIP clients can just > join > using service-name = "SIP-LS" and serving- > identifier="user at example.net". > A SIP client that as external DHT interface, can just call > get/put/remove to any existing provider DHT node. and so on. > > So in conclusion, I think we should start with defining the generic > location-service and P2P-service protocol, and then specific data > format > for SIP-location-service, and implement it for basic audio-only no-NAT > SIP user agent and basic SIP proxy and registrar using some existing > DHT/P2P algorithm. > > Comments? > > Regards, > > Kundan > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From Kasthuriram_V at infosys.com Wed Jan 11 04:04:23 2006 From: Kasthuriram_V at infosys.com (Kasthuri Ram V.) Date: Wed, 11 Jan 2006 14:34:23 +0530 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C4AB85.5000106@cs.columbia.edu> References: <200601102228.k0AMS5Gt003268@cs.columbia.edu> <43C4AB85.5000106@cs.columbia.edu> Message-ID: <1136970263.26020.6.camel@samish.india.ascend.com> Hi Kundan, On Wed, 2006-01-11 at 01:53 -0500, Kundan Singh wrote: > So in conclusion, I think we should start with defining the generic > location-service and P2P-service protocol, and then specific data format > for SIP-location-service, and implement it for basic audio-only no-NAT > SIP user agent and basic SIP proxy and registrar using some existing > DHT/P2P algorithm. > Comments? Well summarized!! This is where we should begin and carry it forward. Cheers, Ram -- > > Regards, > > Kundan > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From enrico.marocco at TILAB.COM Wed Jan 11 04:37:22 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Wed, 11 Jan 2006 10:37:22 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: <43C3CBCB.50607@bulukucing.org> References: <43C3C5A5.8050205@research.panasonic.com> <43C3CBCB.50607@bulukucing.org> Message-ID: <43C4D1D2.1000506@tilab.com> Benny Prijono wrote: > Eunsoo Shim wrote: > >>This is great. >>It is a fantastic idea to have an open source stack supporting the >>(future) P2P SIP spec the IETF will come up. > > Now if only the spec is available so that us mere programmers can > begin to code.. ;) But code is also needed by writers for refining their specs: we're trapped :-) I think it would be useful to start coding the draft spec (some work has been done at Columbia and at William And Mary, but it's not open source) for contributing feedback and suggestions. In this way, keeping alingned coding and writing, we should end with good code and complete specs. Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From dbarrett at quinthar.com Wed Jan 11 04:38:21 2006 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 11 Jan 2006 01:38:21 -0800 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C4AB85.5000106@cs.columbia.edu> References: <200601102228.k0AMS5Gt003268@cs.columbia.edu> <43C4AB85.5000106@cs.columbia.edu> Message-ID: <43C4D20D.7030908@quinthar.com> Hi Kundan! Glad to see you're still active with P2P/SIP. Kundan Singh wrote: > So in conclusion, I think we should start with defining the generic > location-service and P2P-service protocol, and then specific data format > for SIP-location-service, and implement it for basic audio-only no-NAT > SIP user agent and basic SIP proxy and registrar using some existing > DHT/P2P algorithm. I think this is a great proposal, though quite different than mine. What I like about your proposal is that it has a clear and limited goal; it doesn't try to satisfy everybody. Unfortunately, it doesn't satisfy me. (Which is fine; my proposal would certainly leave others dissatisfied, too.) What it sounds like we both agree upon is the need to trim back the requirements to a smaller, clearer set: You're emphasizing serverless operation, while I'm focused on NAT/firewall traversal. Both are "P2P" and within the scope of the use cases outlined last month. And both are areas that can see great improvement. It's really a matter of whether to focus on adding more features to the SIP universe (serverless operation), or refactoring what's already in place (NAT/firewall traversal). Personally, I think SIP has come so far it's in desperate need for a breather, and we have a great opportunity to "retreat and regroup" such that future efforts (such as serverless operation) are less painful. But I understand that's just one view. -david From royrr at us.saic.com Wed Jan 11 08:16:46 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Wed, 11 Jan 2006 08:16:46 -0500 Subject: [p2p-sip] Requirements Explosion Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F6233D7@0591-its-exmp01.us.saic.com> Kundan: If I understand correctly, you are suggesting that we should start to develop a generic p2p-(problem-specific) protocol and then use/apply/implement this using SIP protocol standards. Is this correct interpretation? I thought that we would examine the present SIP protocol standards and will find which parts of the SIP standards are NOT in consistent with the p2p public Internet. To me, to make SIP a pure p2p protocol in different aspects like registration, location, removing the needs of middle network functional entities like proxies, transparent crossing of FWs/NATs by SIP signaling messages and audio/video payload, etc., we will develop p2p-SIP protocol. To develop the p2p-SIP protocol, we may have to take couple of steps as follows: 1. Base p2p-SIP protocol (no FW/NAT crossing, no location services, etc., but may allow to use SIP without the need intermediate entities like proxies) 2. Extend the base p2p-SIP protocol to solve the complex problems like FW/NAT crossing, location services, etc. 3. Extend the same for multipoint multimedia conferencing 4. Others Would you please help us to clarify the above? Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Kasthuri Ram V. Sent: Wed 1/11/2006 4:04 AM To: Kundan Singh Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Requirements Explosion Hi Kundan, On Wed, 2006-01-11 at 01:53 -0500, Kundan Singh wrote: > So in conclusion, I think we should start with defining the generic > location-service and P2P-service protocol, and then specific data format > for SIP-location-service, and implement it for basic audio-only no-NAT > SIP user agent and basic SIP proxy and registrar using some existing > DHT/P2P algorithm. > Comments? Well summarized!! This is where we should begin and carry it forward. Cheers, Ram -- > > Regards, > > Kundan > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From vkg at lucent.com Wed Jan 11 08:41:39 2006 From: vkg at lucent.com (Vijay K. Gurbani) Date: Wed, 11 Jan 2006 07:41:39 -0600 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F6233D6@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233D6@0591-its-exmp01.us.saic.com> Message-ID: <43C50B13.7020306@lucent.com> Roy, Radhika R. wrote: > There are some important problems remain to be solved in the FW/NAT areas. > However, it is NOT SIP problems. It is the problem of the IP > network/transport layer for the entire Internet that is NOT allowing to SIP > signaling and its payload to cross the "traditional" FWs/NATs for a session > that last for hours. Nonetheless, SIP is increasingly being viewed as a tool in the arsenal for UDP and TCP connectivity. See [1], which argues that SIP should take a broader architectural role in P2P network layer connectivity. [1] Saikat Guha, Yutaka Takeda, and Paul Francis, "NUTSS: A SIP- based Approach to UDP and TCP Network Connectivity," Proceedings of the ACM SIGCOMM 2004 Workshop on Future directions in network architecture, Aug-Sept. 2004, pp. 43-48. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Lucent Technologies/Bell Laboratories, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 10301 bytes Desc: S/MIME Cryptographic Signature Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060111/f1940755/smime-0001.bin From eunsoo at research.panasonic.com Wed Jan 11 10:03:20 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 11 Jan 2006 10:03:20 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C49B43.3010401@quinthar.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233D6@0591-its-exmp01.us.saic. com> <43C49B43.3010401@quinthar.com> Message-ID: <43C51E38.8050904@research.panasonic.com> David Barrett wrote: > Roy, Radhika R. wrote: > >> There are some important problems remain to be solved in the FW/NAT >> areas. >> However, it is NOT SIP problems. It is the problem of the IP >> network/transport layer for the entire Internet that is NOT allowing >> to SIP >> signaling and its payload to cross the "traditional" FWs/NATs for a >> session >> that last for hours. > > > Well, saying "it's not SIP's problem" is small comfort if it renders > SIP unusable (or prohibitively difficult) in the real world. If the > goal of the P2P-SIP group is to improve interoperability between P2P > implementations of SIP, and if the #1 P2P complexity is NAT/FW > traversal, then it sure would be nice if the P2P-SIP group did > something about it. > I guess lots of peers will be located behind NAT/FW. Thus I think also that P2P SIP community (or the future P2P SIP WG) would need to look into NAT/FW traversal issues with collaboration with other WGs such as BEHAVE and MMUSIC. > A unified INVITE/ACK grammar that automatically pierced NATs would > simplify the overall architecture tremendously and make SIP a more > practical solution for real-world use on the real-world internet. > > -david Thanks. Eunsoo From eunsoo at research.panasonic.com Wed Jan 11 10:09:28 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 11 Jan 2006 10:09:28 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C4AB85.5000106@cs.columbia.edu> References: <200601102228.k0AMS5Gt003268@cs.columbia.edu> <43C4AB85.5000106@cs.columbia.edu> Message-ID: <43C51FA8.1090000@research.panasonic.com> > >So in conclusion, I think we should start with defining the generic >location-service and P2P-service protocol, and then specific data format >for SIP-location-service, and implement it for basic audio-only no-NAT >SIP user agent and basic SIP proxy and registrar using some existing >DHT/P2P algorithm. > > I like this proposal a lot like many other people. Regards, Eunsoo From henry at pulver.com Wed Jan 11 12:11:36 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 11 Jan 2006 11:11:36 -0600 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C51FA8.1090000@research.panasonic.com> Message-ID: <200601111712.k0BHBhGt010728@cs.columbia.edu> > for basic audio-only no-NAT >SIP user agent I hope we include presence and IM right from the start and see no difference if video will be there as well. Thanks, Henry -----Original Message----- From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] Sent: Wednesday, January 11, 2006 9:09 AM To: Kundan Singh Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Requirements Explosion > >So in conclusion, I think we should start with defining the generic >location-service and P2P-service protocol, and then specific data format >for SIP-location-service, and implement it for basic audio-only no-NAT >SIP user agent and basic SIP proxy and registrar using some existing >DHT/P2P algorithm. > > I like this proposal a lot like many other people. Regards, Eunsoo From kns10 at cs.columbia.edu Wed Jan 11 12:40:02 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Wed, 11 Jan 2006 12:40:02 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F6233D7@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233D7@0591-its-exmp01.us.saic.com> Message-ID: <43C542F2.7040006@cs.columbia.edu> > If I understand correctly, you are suggesting that we should start to > develop a generic p2p-(problem-specific) protocol and then > use/apply/implement this using SIP protocol standards. Is this correct > interpretation? Yes. The intended application has two parts: P2P network (chord, pastry etc) and application (SIP video call, presence, etc). I said that we should first define the interface between the two, and then add the two parts (which can be done independently). The interface can be defined in two steps: (1) a generic API/protocol for accessing the services of or providing services to any P2P network. (2) application specific profiles such as for SIP location service, presence services, etc. > I thought that we would examine the present SIP protocol standards and will > find which parts of the SIP standards are NOT in consistent with the p2p > public Internet. > > To me, to make SIP a pure p2p protocol in different aspects like > registration, location, removing the needs of middle network functional > entities like proxies, transparent crossing of FWs/NATs by SIP signaling > messages and audio/video payload, etc., we will develop p2p-SIP protocol. To True. These can form the application specific profiles. I think, these are important but independent problems and an application can implement some or all of these. For example, in the P2P-SIP-Nat-Audio profile we can list the following requirements, and require that an application meets all these to be called a P2P-SIP-Nat-Audio phone: 1. Transport: TLS. URI: sips. (or pick SMIME; but pick one as mandatory) 2. All sent messages are in canonical form of SIP message/headers. 3. Connection reuse (for reverse direction messages). 4. Do P2P lookup and updates as per SIP-LS profile (above). RFC3263 not required. But some way to bootstrap should be defined. 5. Support INVITE/ACK/CANCEL/BYE/OPTIONS. (REGISTER not needed). 6. Must support ICE, SRTP, etc., for media. (or should it be RTP over TCP/TLS?) 7. RFC3261: interpret all SHOULD as MUST, SHOULD NOT as MUST NOT. 8. SDP in INVITE and 200 OK a MUST. re-INVITE must be supported. 9. Each node also a TURN/STUN server. 10.Dynamic ports instead of listening on 5060 always. 11. Must support REFER. 12. Must support G.711, GSM, iLBC, and Speex (both 8 and 16kHz). 13. Must support at least one audio session per call. 14. No need to emulate PSTN or interoperate (for basic phone). So no DTMF, ENUM, tel, etc. ... n. Gracefully handle any incoming SIP messages in a SIP compliant way (e.g., may reject as '400 Not in canonical form' if the parser is not capable of handling non canonical SIP messages.) Similarly there can be P2P-SIP-Multimedia-IM, P2P-SIP-Proxy, P2P-SIP-presence requirements. But these requirements are just specific application profiles. We can define the minimum requirements for an application profile for interoperability, ease of development and 'just works' user experience. As and when new applications get developed, new application profiles can be added for compliance with P2P-SIP. So I think the steps could be: (1) define the P2P location (get/put) and service (join/lookup) protocol, (2) define the application specific protocol for SIP lookup and presence, initially, (3) define the minimum set of requirements for a P2P-SIP-Nat-Audio-Video-IM application and P2P-SIP-Proxy application using this P2P location and service protocols, (4) implement such a phone and proxy using some existing SIP and DHT implementations. Regards, Kundan From bryan at ethernot.org Wed Jan 11 13:39:59 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 11 Jan 2006 13:39:59 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C542F2.7040006@cs.columbia.edu> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233D7@0591-its-exmp01.us.saic.com> <43C542F2.7040006@cs.columbia.edu> Message-ID: <8b2769930601111039m1c7db61fs5979c7d3a003211d@mail.gmail.com> I think a lot of the architecture proposed by Kundan makes good sense, and is inline with the direction people seemed interested in taking things at the meeting in Vancouver. There seemed to be strong agreement to separate the SIP call completion from the P2P lookup service. (although I think the protocol for transport of the lookup was still up in the air, with some advocating something looking like SIP (or even using SIP), and others advocating something like XML or SOAP or the like, but the two being separated no matter which decision was made) As far as the specific requirements, I'm not sure specifying such a broad range of codecs is really needed -- SDP negotiation can be used just as in conventional SIP, and people may want to use others, not support one or more of the mentioned ones, etc. That said, agreeing on at least one seems essential for interoperability. Tough decision. I also think that one of the advantages in a SIP based P2P communications system, rather than a non-SIP one, is the ability to connect to existing devices and gateways, so I think things like PSTN interoperability are critical -- more critical in my mind than things like REFER and the features that enables, actually, although obviously both are important. That probably means at least the capacity for register too...not sure how else can provide outside connectivity to existing systems for PSTN connectivity. I think each node being a STUN/TURN server, connection reuse, ICE, etc. is definitely critical. We must assume nodes will be behind NATs as a matter of course. Thoughts? David Bryan On 1/11/06, Kundan Singh wrote: > > If I understand correctly, you are suggesting that we should start to > > develop a generic p2p-(problem-specific) protocol and then > > use/apply/implement this using SIP protocol standards. Is this correct > > interpretation? > > Yes. The intended application has two parts: P2P network (chord, pastry > etc) and application (SIP video call, presence, etc). I said that we > should first define the interface between the two, and then add the two > parts (which can be done independently). The interface can be defined in > two steps: (1) a generic API/protocol for accessing the services of or > providing services to any P2P network. (2) application specific profiles > such as for SIP location service, presence services, etc. > > > I thought that we would examine the present SIP protocol standards and will > > find which parts of the SIP standards are NOT in consistent with the p2p > > public Internet. > > > > To me, to make SIP a pure p2p protocol in different aspects like > > registration, location, removing the needs of middle network functional > > entities like proxies, transparent crossing of FWs/NATs by SIP signaling > > messages and audio/video payload, etc., we will develop p2p-SIP protocol. To > > True. These can form the application specific profiles. I think, these > are important but independent problems and an application can implement > some or all of these. For example, in the P2P-SIP-Nat-Audio profile we > can list the following requirements, and require that an application > meets all these to be called a P2P-SIP-Nat-Audio phone: > 1. Transport: TLS. URI: sips. (or pick SMIME; but pick one as mandatory) > 2. All sent messages are in canonical form of SIP message/headers. > 3. Connection reuse (for reverse direction messages). > 4. Do P2P lookup and updates as per SIP-LS profile (above). RFC3263 not > required. But some way to bootstrap should be defined. > 5. Support INVITE/ACK/CANCEL/BYE/OPTIONS. (REGISTER not needed). > 6. Must support ICE, SRTP, etc., for media. (or should it be RTP over > TCP/TLS?) > 7. RFC3261: interpret all SHOULD as MUST, SHOULD NOT as MUST NOT. > 8. SDP in INVITE and 200 OK a MUST. re-INVITE must be supported. > 9. Each node also a TURN/STUN server. > 10.Dynamic ports instead of listening on 5060 always. > 11. Must support REFER. > 12. Must support G.711, GSM, iLBC, and Speex (both 8 and 16kHz). > 13. Must support at least one audio session per call. > 14. No need to emulate PSTN or interoperate (for basic phone). So no > DTMF, ENUM, tel, etc. > ... people think should be in a basic P2P-SIP audio/video/IM client> > n. Gracefully handle any incoming SIP messages in a SIP compliant way > (e.g., may reject as '400 Not in canonical form' if the parser is not > capable of handling non canonical SIP messages.) > > Similarly there can be P2P-SIP-Multimedia-IM, P2P-SIP-Proxy, > P2P-SIP-presence requirements. But these requirements are just specific > application profiles. We can define the minimum requirements for an > application profile for interoperability, ease of development and 'just > works' user experience. As and when new applications get developed, new > application profiles can be added for compliance with P2P-SIP. > > So I think the steps could be: (1) define the P2P location (get/put) and > service (join/lookup) protocol, (2) define the application specific > protocol for SIP lookup and presence, initially, (3) define the minimum > set of requirements for a P2P-SIP-Nat-Audio-Video-IM application and > P2P-SIP-Proxy application using this P2P location and service protocols, > (4) implement such a phone and proxy using some existing SIP and DHT > implementations. > > Regards, > Kundan > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From eunsoo at research.panasonic.com Wed Jan 11 13:41:52 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 11 Jan 2006 13:41:52 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <20060111170039.DD7A51E9460@redwood.research.panasonic.com> References: <20060111170039.DD7A51E9460@redwood.research.panasonic.com> Message-ID: <43C55170.4050204@research.panasonic.com> Henry Sinnreich wrote: >>for basic audio-only no-NAT >>SIP user agent >> >> > >I hope we include presence and IM right from the start and see no difference >if video will be there as well. > > > I believe, once we have a design to support audio-only SIP user agents following the external DHT approach (or DHT-based approach), it will be fairly straightforward to support presence, IM and video in that approach. So I support Henry's proposal with respect to setting our very initial design target. Thanks. Eunsoo >Thanks, Henry > >-----Original Message----- >From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] >Sent: Wednesday, January 11, 2006 9:09 AM >To: Kundan Singh >Cc: p2p-sip at cs.columbia.edu >Subject: Re: [p2p-sip] Requirements Explosion > > > > >>So in conclusion, I think we should start with defining the generic >>location-service and P2P-service protocol, and then specific data format >>for SIP-location-service, and implement it for basic audio-only no-NAT >>SIP user agent and basic SIP proxy and registrar using some existing >>DHT/P2P algorithm. >> >> >> >> >I like this proposal a lot like many other people. >Regards, > >Eunsoo > > > > From drage at lucent.com Wed Jan 11 14:02:19 2006 From: drage at lucent.com (Drage, Keith (Keith)) Date: Wed, 11 Jan 2006 19:02:19 -0000 Subject: [p2p-sip] Requirements Explosion Message-ID: <475FF955A05DD411980D00508B6D5FB00C290750@en0033exch001u.uk.lucent.com> I'm afraid I have totally lost the purpose of this point-to-point SIP stuff - or rather I think some of the other members of this list have. If it is going to be called SIP, then all entities must at least follow some basic SIP compatibility rules. I assume also that SIP methods and headers that normally operate between user agents will still operate between user agents. It should only be protocol that is currently impacted by stuff in the middle that should in any way be impacted by the scope of this work. So maybe can I propose that SIP p2p supports all SIP methods and headers that normally operate only on a UA to UA basis. If we agree that, then we automatically support 90% of all the SIP RFCs that exist out there, including presence, IM and video. P2P SIP should only impact the protocol elements that deal with making sure that end-to-end stuff happens. Thus while I might expect that something like Path or Service-Route will not work, or anything based on "trust domains", I would like to be confident that something like SUBSCRIBE or Replaces does. If people really want to build something that doesn't do that, then surely you need to change the title of the list, as it is no longer SIP - and we will see where the IETF stand in terms of inventing a totally new VOIP protocol. Remember, in Vancouver, I believe we were trying to address something that could be done by an IETF group, the discussion I have seen over the last few days seems to be determined to consign all the work to IRTF. regards Keith > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim > Sent: 11 January 2006 18:42 > To: henry at pulver.com > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] Requirements Explosion > > > Henry Sinnreich wrote: > > >>for basic audio-only no-NAT > >>SIP user agent > >> > >> > > > >I hope we include presence and IM right from the start and > see no difference > >if video will be there as well. > > > > > > > I believe, once we have a design to support audio-only SIP > user agents > following the external DHT approach (or DHT-based approach), > it will be > fairly straightforward to support presence, IM and video in > that approach. > So I support Henry's proposal with respect to setting our > very initial > design target. > Thanks. > > Eunsoo > > >Thanks, Henry > > > >-----Original Message----- > >From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > >Sent: Wednesday, January 11, 2006 9:09 AM > >To: Kundan Singh > >Cc: p2p-sip at cs.columbia.edu > >Subject: Re: [p2p-sip] Requirements Explosion > > > > > > > > > >>So in conclusion, I think we should start with defining the generic > >>location-service and P2P-service protocol, and then > specific data format > >>for SIP-location-service, and implement it for basic > audio-only no-NAT > >>SIP user agent and basic SIP proxy and registrar using some > existing > >>DHT/P2P algorithm. > >> > >> > >> > >> > >I like this proposal a lot like many other people. > >Regards, > > > >Eunsoo > > > > > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From ssal at intracom.gr Wed Jan 11 15:39:36 2006 From: ssal at intracom.gr (Sotiris Salloum) Date: Wed, 11 Jan 2006 21:39:36 +0100 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C542F2.7040006@cs.columbia.edu> Message-ID: <200601111924.k0BJObq16212@hal.intranet.gr> Dear all, >From my point of view p2p-sip could provide standardization in a field where no standardization exist for the moment (but instead proprietary solutions) Based on the increasing (day by day) bandwidth availability, an increasing field of application's will appear to take into advantage all the interconnected computing power (either for VoIp, VoD, research, location etc). This will require a common protocol to work as a basis like TCP/UDP did for the past. Based on the above assumptions I wanted to share with you my proposal that maybe this work could be better to have another acronym? (pip) in order to avoid confusion with VoIP and Skype and to show it's full potentials and dynamics? Regards Sotiris Sotiris Salloum MSc. PhD Candidate INTRACOM SA - Content Distribution Networks Athens Greece 19002 Peania Attica -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Kundan Singh Sent: Wednesday, January 11, 2006 6:40 PM To: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Requirements Explosion > If I understand correctly, you are suggesting that we should start to > develop a generic p2p-(problem-specific) protocol and then > use/apply/implement this using SIP protocol standards. Is this correct > interpretation? Yes. The intended application has two parts: P2P network (chord, pastry etc) and application (SIP video call, presence, etc). I said that we should first define the interface between the two, and then add the two parts (which can be done independently). The interface can be defined in two steps: (1) a generic API/protocol for accessing the services of or providing services to any P2P network. (2) application specific profiles such as for SIP location service, presence services, etc. > I thought that we would examine the present SIP protocol standards and will > find which parts of the SIP standards are NOT in consistent with the p2p > public Internet. > > To me, to make SIP a pure p2p protocol in different aspects like > registration, location, removing the needs of middle network functional > entities like proxies, transparent crossing of FWs/NATs by SIP signaling > messages and audio/video payload, etc., we will develop p2p-SIP protocol. To True. These can form the application specific profiles. I think, these are important but independent problems and an application can implement some or all of these. For example, in the P2P-SIP-Nat-Audio profile we can list the following requirements, and require that an application meets all these to be called a P2P-SIP-Nat-Audio phone: 1. Transport: TLS. URI: sips. (or pick SMIME; but pick one as mandatory) 2. All sent messages are in canonical form of SIP message/headers. 3. Connection reuse (for reverse direction messages). 4. Do P2P lookup and updates as per SIP-LS profile (above). RFC3263 not required. But some way to bootstrap should be defined. 5. Support INVITE/ACK/CANCEL/BYE/OPTIONS. (REGISTER not needed). 6. Must support ICE, SRTP, etc., for media. (or should it be RTP over TCP/TLS?) 7. RFC3261: interpret all SHOULD as MUST, SHOULD NOT as MUST NOT. 8. SDP in INVITE and 200 OK a MUST. re-INVITE must be supported. 9. Each node also a TURN/STUN server. 10.Dynamic ports instead of listening on 5060 always. 11. Must support REFER. 12. Must support G.711, GSM, iLBC, and Speex (both 8 and 16kHz). 13. Must support at least one audio session per call. 14. No need to emulate PSTN or interoperate (for basic phone). So no DTMF, ENUM, tel, etc. ... n. Gracefully handle any incoming SIP messages in a SIP compliant way (e.g., may reject as '400 Not in canonical form' if the parser is not capable of handling non canonical SIP messages.) Similarly there can be P2P-SIP-Multimedia-IM, P2P-SIP-Proxy, P2P-SIP-presence requirements. But these requirements are just specific application profiles. We can define the minimum requirements for an application profile for interoperability, ease of development and 'just works' user experience. As and when new applications get developed, new application profiles can be added for compliance with P2P-SIP. So I think the steps could be: (1) define the P2P location (get/put) and service (join/lookup) protocol, (2) define the application specific protocol for SIP lookup and presence, initially, (3) define the minimum set of requirements for a P2P-SIP-Nat-Audio-Video-IM application and P2P-SIP-Proxy application using this P2P location and service protocols, (4) implement such a phone and proxy using some existing SIP and DHT implementations. Regards, Kundan _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From matthewsp at avaya.com Wed Jan 11 14:57:18 2006 From: matthewsp at avaya.com (Matthews, Philip (Philip)) Date: Wed, 11 Jan 2006 14:57:18 -0500 Subject: [p2p-sip] OpenWengo Message-ID: As much as I really appreciate the work that David Bryan and Cullen Jennings did on their draft, I don't think we should consider it a "draft specification". I feel strongly that the group needs to start by considering the requirements and examining the design space before considering what direction to move in. David's SoSimple system, and the similar system from Henning and team are very interesting, but I would like us to investigate alternatives before deciding that their system is the way to go. In particular: - Both systems use Chord, which is easy to understand, but a number of people have suggested to me privately that Chord has some problems. - Both systems take the approach of integrating the DHT maintenance messages into SIP, which many people at the ad-hoc meeting in Vancouver didn't like. (There was quite a bit of discussion about this at the meeting. I was one of those who proposed the two be kept separate, though I am starting to reconsider my position). To my mind, the strength of David and Cullen's draft is that it gives us an example of a system. I would encourage others to publish drafts giving other examples. This will help us understand where we want to go. - Philip > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Enrico Marocco > Sent: January 11, 2006 04:37 > To: Benny Prijono > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] OpenWengo > > Benny Prijono wrote: > > Eunsoo Shim wrote: > > > >>This is great. > >>It is a fantastic idea to have an open source stack supporting the > >>(future) P2P SIP spec the IETF will come up. > > > > Now if only the spec is available so that us mere programmers can > > begin to code.. ;) > > But code is also needed by writers for refining their specs: we're > trapped :-) > > I think it would be useful to start coding the draft spec > (some work has > been done at Columbia and at William And Mary, but it's not > open source) > for contributing feedback and suggestions. In this way, > keeping alingned > coding and writing, we should end with good code and complete specs. > > Enrico > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom > Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin at tilab.com. Thank you > ==================================================================== > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From henry at pulver.com Wed Jan 11 15:38:11 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 11 Jan 2006 14:38:11 -0600 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290750@en0033exch001u.uk.lucent.com> Message-ID: <200601112038.k0BKcNGt004705@cs.columbia.edu> I am pleased to share there is a nifty public P2P SIP service out there: http://damaka.com/download.htm It is a pretty rich product that works apparently both P2P and CS SIP, has presence, IM, voice, video, lots of nice applications and NAT traversal without any network servers. This group is best qualified to give Damaka a hearty welcome! Thanks, Henry From eunsoo at research.panasonic.com Wed Jan 11 15:52:44 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 11 Jan 2006 15:52:44 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290750@en0033exch001u.uk.luc ent.com> References: <475FF955A05DD411980D00508B6D5FB00C290750@en0033exch001u.uk.luce nt.com> Message-ID: <43C5701C.1000504@research.panasonic.com> Please let me try to supplement the comments about 'point-to-point SIP stuff'. I seems we need a document about the different P2P SIP design approaches so that we can synchronize our discussion in the mailing list more efficiently. I will try to prepare the document as soon as possible. Meanwhile, I'd like to encourage people to review the presentation I gave in Vancouver (http://www.p2psip.org/ietf64.php Presentation on comparison of pure SIP vs DHT based solutions ). Kundan's email describes what needs to be done if we follow the DHT based approach (or External DHT approach) (Obviously we need to unify the term to call the approach). Please let me try to explain or reiterate some points here. - If we follow the DHT based approach, the SIP call control procedures are independent of DHT maintenance (join/leave) and resource lookup and placement. In an extreme, nothing has to be changed in the SIP messages. To realize P2P SIP (or P2P style SIP-based Internet telephony, IM, etc), we need to define three things in this approach: a protocol for DHT maintenance and resource lookup/placement, resources types and their data formats for the resources to be placed in the P2P overlay network, and the rules to generate the resource ID given a resource type and its data format. Once the resource ID is set, the underling DHT determines where to place the resource and how to look it up. A most important resource (data) is the user location (mapping of URI to IP address). For a basic one-to-one call setup without NAT/FW traversal, the user location is all we need to place in the overlay network and lookup. It is the same whether the call is audio-only or audio/video together. For Presence, we need a format for presence data. A peer storing presence data of another peer will behave as a presence server. More advanced or complex session control procedures may need more work for P2P style operation. For conferencing, we can have some choices: whether we will make a peer play a role of a rendezvous point or design a more distributed operation. If a peer becomes a rendezvous point, XCON will work almost as it is on top of the P2P overlay network. If we want a more distributed conferencing control, it will become a topic on its own. Probably it is not in scope of the future P2P SIP WG. As you can see, the protocol(s) for DHT maintenance and resource lookup/placement is independent of SIP call control procedures, services, and resource types. Once the protocol is well designed, we can enhance the services/features of P2P SIP step by step without changing the protocol. So the point made by some people, including Kundan, in my understanding, is that we should start with a limited set of SIP features and design the protocol for DHT maintenance and resource lookup/placement and a limited set of resource types (and formats) required for the feauters. By doing this, I would say we will achieve the most important piece(s) for P2P SIP. In this sense, whether we cover any specific method or header field or an option in various RFCs is not important in the beginning. This does not mean we don't care about supporting all kinds of advanced SIP features in P2P SIP domain. I believe no one disregards the importance of interoperation between P2P SIP domain and client-server SIP domain (and even PSTN). I guess many RFCs related to SIP won't require any new data type/format for SIP operation in P2P fashion. But eventually every single SIP feature should be checked whether it requires a new data type/format to be placed in the P2P overlay network or even a new call control procedure for P2P SIP, if we want to make sure all the SIP features described in every SIP related RFC can be used in P2P SIP domain. Again, what has been suggested is that we focus on simple and widely used features first and worry about others later (in ordely fashion as David Barret described). - If we follow the other design approach where DHT maintenance and resource lookup/placement are integrated tightly with existing SIP procedures and messages, the design work becomes less modular. In this approach, it is actually more important to select some of the SIP features we want support with P2P SIP in the beginning. As we move forward to support more and more SIP features in P2P SIP domain, it is likely that we will be doing still lots of work everytime we add a new SIP feature into P2P SIP domain because of poor modularity of the design. So could we agree on a small set of SIP features as our stating point? Regards, Eunsoo // Drage, Keith (Keith) wrote: >I'm afraid I have totally lost the purpose of this point-to-point SIP stuff - or rather I think some of the other members of this list have. > >If it is going to be called SIP, then all entities must at least follow some basic SIP compatibility rules. I assume also that SIP methods and headers that normally operate between user agents will still operate between user agents. It should only be protocol that is currently impacted by stuff in the middle that should in any way be impacted by the scope of this work. > >So maybe can I propose that SIP p2p supports all SIP methods and headers that normally operate only on a UA to UA basis. If we agree that, then we automatically support 90% of all the SIP RFCs that exist out there, including presence, IM and video. > >P2P SIP should only impact the protocol elements that deal with making sure that end-to-end stuff happens. > >Thus while I might expect that something like Path or Service-Route will not work, or anything based on "trust domains", I would like to be confident that something like SUBSCRIBE or Replaces does. > >If people really want to build something that doesn't do that, then surely you need to change the title of the list, as it is no longer SIP - and we will see where the IETF stand in terms of inventing a totally new VOIP protocol. > >Remember, in Vancouver, I believe we were trying to address something that could be done by an IETF group, the discussion I have seen over the last few days seems to be determined to consign all the work to IRTF. > >regards > >Keith > > > >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim >>Sent: 11 January 2006 18:42 >>To: henry at pulver.com >>Cc: p2p-sip at cs.columbia.edu >>Subject: Re: [p2p-sip] Requirements Explosion >> >> >>Henry Sinnreich wrote: >> >> >> >>>>for basic audio-only no-NAT >>>>SIP user agent >>>> >>>> >>>> >>>> >>>I hope we include presence and IM right from the start and >>> >>> >>see no difference >> >> >>>if video will be there as well. >>> >>> >>> >>> >>> >>I believe, once we have a design to support audio-only SIP >>user agents >>following the external DHT approach (or DHT-based approach), >>it will be >>fairly straightforward to support presence, IM and video in >>that approach. >>So I support Henry's proposal with respect to setting our >>very initial >>design target. >>Thanks. >> >>Eunsoo >> >> >> >>>Thanks, Henry >>> >>>-----Original Message----- >>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] >>>Sent: Wednesday, January 11, 2006 9:09 AM >>>To: Kundan Singh >>>Cc: p2p-sip at cs.columbia.edu >>>Subject: Re: [p2p-sip] Requirements Explosion >>> >>> >>> >>> >>> >>> >>>>So in conclusion, I think we should start with defining the generic >>>>location-service and P2P-service protocol, and then >>>> >>>> >>specific data format >> >> >>>>for SIP-location-service, and implement it for basic >>>> >>>> >>audio-only no-NAT >> >> >>>>SIP user agent and basic SIP proxy and registrar using some >>>> >>>> >>existing >> >> >>>>DHT/P2P algorithm. >>>> >>>> >>>> >>>> >>>> >>>> >>>I like this proposal a lot like many other people. >>>Regards, >>> >>>Eunsoo >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>p2p-sip mailing list >>p2p-sip at cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >> From eunsoo at research.panasonic.com Wed Jan 11 16:07:37 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 11 Jan 2006 16:07:37 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <200601111924.k0BJObq16212@hal.intranet.gr> References: <200601111924.k0BJObq16212@hal.intranet.gr> Message-ID: <43C57399.2030400@research.panasonic.com> It sounds that you are proposing we focus on (a) generic P2P protocol(s). I understand your point but it is one of the things some of us, including myself, have been carefully excluding. One reason I have is that I think that P2P technologies are diverse and different P2P technologies serve different applications better than others. It seems it will become a very difficult task to find and standardize, within a WG, a small set of P2P technologies suiting all kinds of applications. So I think we should have and maintain a clear focus on the target P2P application, which is P2P real-time communications (Internet telephony, Presence, IM) in this P2P SIP community. Thanks. Eunsoo Sotiris Salloum wrote: >Dear all, > >>From my point of view p2p-sip could provide standardization in a field where >no standardization exist for the moment (but instead proprietary solutions) > >Based on the increasing (day by day) bandwidth availability, an increasing >field of application's will appear to take into advantage all the >interconnected computing power (either for VoIp, VoD, research, location >etc). This will require a common protocol to work as a basis like TCP/UDP >did for the past. > >Based on the above assumptions I wanted to share with you my proposal that >maybe this work could be better to have another acronym? (pip) in order to >avoid confusion with VoIP and Skype and to show it's full potentials and >dynamics? > >Regards >Sotiris > >Sotiris Salloum MSc. PhD Candidate >INTRACOM SA - Content Distribution Networks >Athens Greece >19002 Peania Attica > > >-----Original Message----- >From: p2p-sip-bounces at cs.columbia.edu >[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Kundan Singh >Sent: Wednesday, January 11, 2006 6:40 PM >To: p2p-sip at cs.columbia.edu >Subject: Re: [p2p-sip] Requirements Explosion > > > >>If I understand correctly, you are suggesting that we should start to >>develop a generic p2p-(problem-specific) protocol and then >>use/apply/implement this using SIP protocol standards. Is this correct >>interpretation? >> >> > >Yes. The intended application has two parts: P2P network (chord, pastry >etc) and application (SIP video call, presence, etc). I said that we >should first define the interface between the two, and then add the two >parts (which can be done independently). The interface can be defined in >two steps: (1) a generic API/protocol for accessing the services of or >providing services to any P2P network. (2) application specific profiles >such as for SIP location service, presence services, etc. > > > >>I thought that we would examine the present SIP protocol standards and >> >> >will > > >>find which parts of the SIP standards are NOT in consistent with the p2p >>public Internet. >> >>To me, to make SIP a pure p2p protocol in different aspects like >>registration, location, removing the needs of middle network functional >>entities like proxies, transparent crossing of FWs/NATs by SIP signaling >>messages and audio/video payload, etc., we will develop p2p-SIP protocol. >> >> >To > >True. These can form the application specific profiles. I think, these >are important but independent problems and an application can implement >some or all of these. For example, in the P2P-SIP-Nat-Audio profile we >can list the following requirements, and require that an application >meets all these to be called a P2P-SIP-Nat-Audio phone: >1. Transport: TLS. URI: sips. (or pick SMIME; but pick one as mandatory) >2. All sent messages are in canonical form of SIP message/headers. >3. Connection reuse (for reverse direction messages). >4. Do P2P lookup and updates as per SIP-LS profile (above). RFC3263 not >required. But some way to bootstrap should be defined. >5. Support INVITE/ACK/CANCEL/BYE/OPTIONS. (REGISTER not needed). >6. Must support ICE, SRTP, etc., for media. (or should it be RTP over >TCP/TLS?) >7. RFC3261: interpret all SHOULD as MUST, SHOULD NOT as MUST NOT. >8. SDP in INVITE and 200 OK a MUST. re-INVITE must be supported. >9. Each node also a TURN/STUN server. >10.Dynamic ports instead of listening on 5060 always. >11. Must support REFER. >12. Must support G.711, GSM, iLBC, and Speex (both 8 and 16kHz). >13. Must support at least one audio session per call. >14. No need to emulate PSTN or interoperate (for basic phone). So no >DTMF, ENUM, tel, etc. >... people think should be in a basic P2P-SIP audio/video/IM client> >n. Gracefully handle any incoming SIP messages in a SIP compliant way >(e.g., may reject as '400 Not in canonical form' if the parser is not >capable of handling non canonical SIP messages.) > >Similarly there can be P2P-SIP-Multimedia-IM, P2P-SIP-Proxy, >P2P-SIP-presence requirements. But these requirements are just specific >application profiles. We can define the minimum requirements for an >application profile for interoperability, ease of development and 'just >works' user experience. As and when new applications get developed, new >application profiles can be added for compliance with P2P-SIP. > >So I think the steps could be: (1) define the P2P location (get/put) and >service (join/lookup) protocol, (2) define the application specific >protocol for SIP lookup and presence, initially, (3) define the minimum >set of requirements for a P2P-SIP-Nat-Audio-Video-IM application and >P2P-SIP-Proxy application using this P2P location and service protocols, >(4) implement such a phone and proxy using some existing SIP and DHT >implementations. > >Regards, >Kundan >_______________________________________________ >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 henry at pulver.com Wed Jan 11 16:50:51 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 11 Jan 2006 15:50:51 -0600 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <43C5701C.1000504@research.panasonic.com> Message-ID: <200601112151.k0BLoxGt021340@cs.columbia.edu> It looks Eunsoo has a very logical approach. Thanks, Henry -----Original Message----- From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] Sent: Wednesday, January 11, 2006 2:53 PM To: Drage, Keith (Keith) Cc: henry at pulver.com; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Requirements Explosion Please let me try to supplement the comments about 'point-to-point SIP stuff'. I seems we need a document about the different P2P SIP design approaches so that we can synchronize our discussion in the mailing list more efficiently. I will try to prepare the document as soon as possible. Meanwhile, I'd like to encourage people to review the presentation I gave in Vancouver (http://www.p2psip.org/ietf64.php Presentation on comparison of pure SIP vs DHT based solutions ). Kundan's email describes what needs to be done if we follow the DHT based approach (or External DHT approach) (Obviously we need to unify the term to call the approach). Please let me try to explain or reiterate some points here. - If we follow the DHT based approach, the SIP call control procedures are independent of DHT maintenance (join/leave) and resource lookup and placement. In an extreme, nothing has to be changed in the SIP messages. To realize P2P SIP (or P2P style SIP-based Internet telephony, IM, etc), we need to define three things in this approach: a protocol for DHT maintenance and resource lookup/placement, resources types and their data formats for the resources to be placed in the P2P overlay network, and the rules to generate the resource ID given a resource type and its data format. Once the resource ID is set, the underling DHT determines where to place the resource and how to look it up. A most important resource (data) is the user location (mapping of URI to IP address). For a basic one-to-one call setup without NAT/FW traversal, the user location is all we need to place in the overlay network and lookup. It is the same whether the call is audio-only or audio/video together. For Presence, we need a format for presence data. A peer storing presence data of another peer will behave as a presence server. More advanced or complex session control procedures may need more work for P2P style operation. For conferencing, we can have some choices: whether we will make a peer play a role of a rendezvous point or design a more distributed operation. If a peer becomes a rendezvous point, XCON will work almost as it is on top of the P2P overlay network. If we want a more distributed conferencing control, it will become a topic on its own. Probably it is not in scope of the future P2P SIP WG. As you can see, the protocol(s) for DHT maintenance and resource lookup/placement is independent of SIP call control procedures, services, and resource types. Once the protocol is well designed, we can enhance the services/features of P2P SIP step by step without changing the protocol. So the point made by some people, including Kundan, in my understanding, is that we should start with a limited set of SIP features and design the protocol for DHT maintenance and resource lookup/placement and a limited set of resource types (and formats) required for the feauters. By doing this, I would say we will achieve the most important piece(s) for P2P SIP. In this sense, whether we cover any specific method or header field or an option in various RFCs is not important in the beginning. This does not mean we don't care about supporting all kinds of advanced SIP features in P2P SIP domain. I believe no one disregards the importance of interoperation between P2P SIP domain and client-server SIP domain (and even PSTN). I guess many RFCs related to SIP won't require any new data type/format for SIP operation in P2P fashion. But eventually every single SIP feature should be checked whether it requires a new data type/format to be placed in the P2P overlay network or even a new call control procedure for P2P SIP, if we want to make sure all the SIP features described in every SIP related RFC can be used in P2P SIP domain. Again, what has been suggested is that we focus on simple and widely used features first and worry about others later (in ordely fashion as David Barret described). - If we follow the other design approach where DHT maintenance and resource lookup/placement are integrated tightly with existing SIP procedures and messages, the design work becomes less modular. In this approach, it is actually more important to select some of the SIP features we want support with P2P SIP in the beginning. As we move forward to support more and more SIP features in P2P SIP domain, it is likely that we will be doing still lots of work everytime we add a new SIP feature into P2P SIP domain because of poor modularity of the design. So could we agree on a small set of SIP features as our stating point? Regards, Eunsoo // Drage, Keith (Keith) wrote: >I'm afraid I have totally lost the purpose of this point-to-point SIP stuff - or rather I think some of the other members of this list have. > >If it is going to be called SIP, then all entities must at least follow some basic SIP compatibility rules. I assume also that SIP methods and headers that normally operate between user agents will still operate between user agents. It should only be protocol that is currently impacted by stuff in the middle that should in any way be impacted by the scope of this work. > >So maybe can I propose that SIP p2p supports all SIP methods and headers that normally operate only on a UA to UA basis. If we agree that, then we automatically support 90% of all the SIP RFCs that exist out there, including presence, IM and video. > >P2P SIP should only impact the protocol elements that deal with making sure that end-to-end stuff happens. > >Thus while I might expect that something like Path or Service-Route will not work, or anything based on "trust domains", I would like to be confident that something like SUBSCRIBE or Replaces does. > >If people really want to build something that doesn't do that, then surely you need to change the title of the list, as it is no longer SIP - and we will see where the IETF stand in terms of inventing a totally new VOIP protocol. > >Remember, in Vancouver, I believe we were trying to address something that could be done by an IETF group, the discussion I have seen over the last few days seems to be determined to consign all the work to IRTF. > >regards > >Keith > > > >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim >>Sent: 11 January 2006 18:42 >>To: henry at pulver.com >>Cc: p2p-sip at cs.columbia.edu >>Subject: Re: [p2p-sip] Requirements Explosion >> >> >>Henry Sinnreich wrote: >> >> >> >>>>for basic audio-only no-NAT >>>>SIP user agent >>>> >>>> >>>> >>>> >>>I hope we include presence and IM right from the start and >>> >>> >>see no difference >> >> >>>if video will be there as well. >>> >>> >>> >>> >>> >>I believe, once we have a design to support audio-only SIP >>user agents >>following the external DHT approach (or DHT-based approach), >>it will be >>fairly straightforward to support presence, IM and video in >>that approach. >>So I support Henry's proposal with respect to setting our >>very initial >>design target. >>Thanks. >> >>Eunsoo >> >> >> >>>Thanks, Henry >>> >>>-----Original Message----- >>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] >>>Sent: Wednesday, January 11, 2006 9:09 AM >>>To: Kundan Singh >>>Cc: p2p-sip at cs.columbia.edu >>>Subject: Re: [p2p-sip] Requirements Explosion >>> >>> >>> >>> >>> >>> >>>>So in conclusion, I think we should start with defining the generic >>>>location-service and P2P-service protocol, and then >>>> >>>> >>specific data format >> >> >>>>for SIP-location-service, and implement it for basic >>>> >>>> >>audio-only no-NAT >> >> >>>>SIP user agent and basic SIP proxy and registrar using some >>>> >>>> >>existing >> >> >>>>DHT/P2P algorithm. >>>> >>>> >>>> >>>> >>>> >>>> >>>I like this proposal a lot like many other people. >>>Regards, >>> >>>Eunsoo >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>p2p-sip mailing list >>p2p-sip at cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >> From slavitch at gmail.com Wed Jan 11 16:54:48 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 11 Jan 2006 16:54:48 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <200601112151.k0BLoxGt021340@cs.columbia.edu> References: <43C5701C.1000504@research.panasonic.com> <200601112151.k0BLoxGt021340@cs.columbia.edu> Message-ID: <1fc32c8f0601111354v6b106cdq@mail.gmail.com> One thing we mustn't forget is that it would be very kind if all these different P2P applications could find, verify and communicate with one another. Unless we want to balkanize things even further. On 11/01/06, Henry Sinnreich wrote: > > It looks Eunsoo has a very logical approach. > > Thanks, Henry > > > > -----Original Message----- > From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > Sent: Wednesday, January 11, 2006 2:53 PM > To: Drage, Keith (Keith) > Cc: henry at pulver.com; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] Requirements Explosion > > Please let me try to supplement the comments about 'point-to-point SIP > stuff'. > > I seems we need a document about the different P2P SIP design approaches > so that we can synchronize our discussion in the mailing list more > efficiently. > I will try to prepare the document as soon as possible. Meanwhile, I'd > like to encourage people to review the presentation I gave in Vancouver > (http://www.p2psip.org/ietf64.php Presentation on comparison of pure > SIP vs DHT based solutions > ). > Kundan's email describes what needs to be done if we follow the DHT > based approach (or External DHT approach) (Obviously we need to unify > the term to call the approach). > > Please let me try to explain or reiterate some points here. > > - If we follow the DHT based approach, the SIP call control procedures > are independent of DHT maintenance (join/leave) and resource lookup and > placement. In an extreme, nothing has to be changed in the SIP messages. > To realize P2P SIP (or P2P style SIP-based Internet telephony, IM, etc), > we need to define three things in this approach: a protocol for DHT > maintenance and resource lookup/placement, resources types and their > data formats for the resources to be placed in the P2P overlay network, > and the rules to generate the resource ID given a resource type and its > data format. Once the resource ID is set, the underling DHT determines > where to place the resource and how to look it up. > > A most important resource (data) is the user location (mapping of URI to > IP address). For a basic one-to-one call setup without NAT/FW traversal, > the user location is all we need to place in the overlay network and > lookup. It is the same whether the call is audio-only or audio/video > together. > For Presence, we need a format for presence data. A peer storing > presence data of another peer will behave as a presence server. > > More advanced or complex session control procedures may need more work > for P2P style operation. > For conferencing, we can have some choices: whether we will make a peer > play a role of a rendezvous point or design a more distributed > operation. If a peer becomes a rendezvous point, XCON will work almost > as it is on top of the P2P overlay network. If we want a more > distributed conferencing control, it will become a topic on its own. > Probably it is not in scope of the future P2P SIP WG. > > As you can see, the protocol(s) for DHT maintenance and resource > lookup/placement is independent of SIP call control procedures, > services, and resource types. Once the protocol is well designed, we can > enhance the services/features of P2P SIP step by step without changing > the protocol. So the point made by some people, including Kundan, in my > understanding, is that we should start with a limited set of SIP > features and design the protocol for DHT maintenance and resource > lookup/placement and a limited set of resource types (and formats) > required for the feauters. By doing this, I would say we will achieve > the most important piece(s) for P2P SIP. In this sense, whether we cover > any specific method or header field or an option in various RFCs is not > important in the beginning. > > This does not mean we don't care about supporting all kinds of advanced > SIP features in P2P SIP domain. I believe no one disregards the > importance of interoperation between P2P SIP domain and client-server > SIP domain (and even PSTN). > > I guess many RFCs related to SIP won't require any new data type/format > for SIP operation in P2P fashion. But eventually every single SIP > feature should be checked whether it requires a new data type/format to > be placed in the P2P overlay network or even a new call control > procedure for P2P SIP, if we want to make sure all the SIP features > described in every SIP related RFC can be used in P2P SIP domain. Again, > what has been suggested is that we focus on simple and widely used > features first and worry about others later (in ordely fashion as David > Barret described). > > - If we follow the other design approach where DHT maintenance and > resource lookup/placement are integrated tightly with existing SIP > procedures and messages, the design work becomes less modular. In this > approach, it is actually more important to select some of the SIP > features we want support with P2P SIP in the beginning. As we move > forward to support more and more SIP features in P2P SIP domain, it is > likely that we will be doing still lots of work everytime we add a new > SIP feature into P2P SIP domain because of poor modularity of the design. > > So could we agree on a small set of SIP features as our stating point? > > Regards, > > Eunsoo > > // > Drage, Keith (Keith) wrote: > > >I'm afraid I have totally lost the purpose of this point-to-point SIP > stuff > - or rather I think some of the other members of this list have. > > > >If it is going to be called SIP, then all entities must at least follow > some basic SIP compatibility rules. I assume also that SIP methods and > headers that normally operate between user agents will still operate > between > user agents. It should only be protocol that is currently impacted by > stuff > in the middle that should in any way be impacted by the scope of this > work. > > > >So maybe can I propose that SIP p2p supports all SIP methods and headers > that normally operate only on a UA to UA basis. If we agree that, then we > automatically support 90% of all the SIP RFCs that exist out there, > including presence, IM and video. > > > >P2P SIP should only impact the protocol elements that deal with making > sure > that end-to-end stuff happens. > > > >Thus while I might expect that something like Path or Service-Route will > not work, or anything based on "trust domains", I would like to be > confident > that something like SUBSCRIBE or Replaces does. > > > >If people really want to build something that doesn't do that, then > surely > you need to change the title of the list, as it is no longer SIP - and we > will see where the IETF stand in terms of inventing a totally new VOIP > protocol. > > > >Remember, in Vancouver, I believe we were trying to address something > that > could be done by an IETF group, the discussion I have seen over the last > few > days seems to be determined to consign all the work to IRTF. > > > >regards > > > >Keith > > > > > > > >>-----Original Message----- > >>From: p2p-sip-bounces at cs.columbia.edu > >>[mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim > >>Sent: 11 January 2006 18:42 > >>To: henry at pulver.com > >>Cc: p2p-sip at cs.columbia.edu > >>Subject: Re: [p2p-sip] Requirements Explosion > >> > >> > >>Henry Sinnreich wrote: > >> > >> > >> > >>>>for basic audio-only no-NAT > >>>>SIP user agent > >>>> > >>>> > >>>> > >>>> > >>>I hope we include presence and IM right from the start and > >>> > >>> > >>see no difference > >> > >> > >>>if video will be there as well. > >>> > >>> > >>> > >>> > >>> > >>I believe, once we have a design to support audio-only SIP > >>user agents > >>following the external DHT approach (or DHT-based approach), > >>it will be > >>fairly straightforward to support presence, IM and video in > >>that approach. > >>So I support Henry's proposal with respect to setting our > >>very initial > >>design target. > >>Thanks. > >> > >>Eunsoo > >> > >> > >> > >>>Thanks, Henry > >>> > >>>-----Original Message----- > >>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > >>>Sent: Wednesday, January 11, 2006 9:09 AM > >>>To: Kundan Singh > >>>Cc: p2p-sip at cs.columbia.edu > >>>Subject: Re: [p2p-sip] Requirements Explosion > >>> > >>> > >>> > >>> > >>> > >>> > >>>>So in conclusion, I think we should start with defining the generic > >>>>location-service and P2P-service protocol, and then > >>>> > >>>> > >>specific data format > >> > >> > >>>>for SIP-location-service, and implement it for basic > >>>> > >>>> > >>audio-only no-NAT > >> > >> > >>>>SIP user agent and basic SIP proxy and registrar using some > >>>> > >>>> > >>existing > >> > >> > >>>>DHT/P2P algorithm. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>I like this proposal a lot like many other people. > >>>Regards, > >>> > >>>Eunsoo > >>> > >>> > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>p2p-sip mailing list > >>p2p-sip at cs.columbia.edu > >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >> > >> > >> > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060111/8801e2a7/attachment.html From lists at bulukucing.org Wed Jan 11 17:56:54 2006 From: lists at bulukucing.org (Benny Prijono) Date: Wed, 11 Jan 2006 22:56:54 +0000 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <200601112038.k0BKcNGt004705@cs.columbia.edu> References: <200601112038.k0BKcNGt004705@cs.columbia.edu> Message-ID: <43C58D36.80609@bulukucing.org> Henry Sinnreich wrote: > I am pleased to share there is a nifty public P2P SIP service out there: > > http://damaka.com/download.htm > > It is a pretty rich product that works apparently both P2P and CS SIP, has > presence, IM, voice, video, lots of nice applications and NAT traversal > without any network servers. > > This group is best qualified to give Damaka a hearty welcome! > Henry, Is it really "public" and "p2p SIP" as you claimed? I just downloaded and tried the client, and it seems that you can only call (or be called by, maybe) people in the same damaka network. Hardly "public" by average definitions, and surprisingly matches perfectly the definition of "walled garden", which we love to discuss. I listened to a podcast, they say the way it works is: "the client contacts the (central) server to get the address of the buddies, then the client call the buddy directly without going through any server". That doesn't seem like p2p that we discuss in this list. Maybe someone would clarify. It will be great to have more details. -benny From enrico.marocco at TILAB.COM Thu Jan 12 10:42:34 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Thu, 12 Jan 2006 16:42:34 +0100 Subject: [p2p-sip] OpenWengo In-Reply-To: References: Message-ID: <43C678EA.7020102@tilab.com> Matthews, Philip (Philip) wrote: > As much as I really appreciate the work that David Bryan > and Cullen Jennings did on their draft, I don't think we > should consider it a "draft specification". I feel strongly > that the group needs to start by considering the requirements > and examining the design space before considering what direction > to move in. It seems that a lot of people here share the same feeling. > To my mind, the strength of David and Cullen's draft is that it gives > us an example of a system. I would encourage others to publish drafts > giving other examples. This will help us understand where we want to go. I would also encourage others to feel what we are talking about. That draft has a great quality: it's easy to implement on an existing stack. Even if the p2p-using-sip approach got less hums, I think the work of this group would benefit if people could play with its implementation. At least, people coding that spec would benefit inasmuch as you had benefit from the experience you described in Vancouver. Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From huang-ming.pan at comcast.net Thu Jan 12 11:32:59 2006 From: huang-ming.pan at comcast.net (PP) Date: Thu, 12 Jan 2006 08:32:59 -0800 Subject: [p2p-sip] Public P2P SIP service: Damaka.com References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> Message-ID: <001b01c61795$e1201560$030aa8c0@ao.lop.com> "That doesn't seem like p2p that we discuss in this list." With my limited knowledge and experience, I think, in no case, a client can just be installed, boot up and immediately locate its buddies, without looking up some sort of central server (eg. for address of at least one super node), unless the client assumes "flooding" search approach, can it? Peter ----- Original Message ----- From: "Benny Prijono" To: Cc: ; "'Siva Ravikumar'" ; Sent: Wednesday, January 11, 2006 2:56 PM Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com > Henry Sinnreich wrote: > > I am pleased to share there is a nifty public P2P SIP service out there: > > > > http://damaka.com/download.htm > > > > It is a pretty rich product that works apparently both P2P and CS SIP, has > > presence, IM, voice, video, lots of nice applications and NAT traversal > > without any network servers. > > > > This group is best qualified to give Damaka a hearty welcome! > > > > Henry, > > Is it really "public" and "p2p SIP" as you claimed? > > I just downloaded and tried the client, and it seems that you can only > call (or be called by, maybe) people in the same damaka network. > Hardly "public" by average definitions, and surprisingly matches > perfectly the definition of "walled garden", which we love to discuss. > > I listened to a podcast, they say the way it works is: > > "the client contacts the (central) server to get the address of the > buddies, then the client call the buddy directly without going through > any server". > > That doesn't seem like p2p that we discuss in this list. Maybe someone > would clarify. It will be great to have more details. > > -benny > > > > From slavitch at gmail.com Thu Jan 12 11:44:24 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 12 Jan 2006 11:44:24 -0500 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <001b01c61795$e1201560$030aa8c0@ao.lop.com> References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> <001b01c61795$e1201560$030aa8c0@ao.lop.com> Message-ID: <1fc32c8f0601120844x6f40d481r@mail.gmail.com> It's also a not-so-subtle kick in the pants for all of us to get moving and produce something before we become irrelevant. Thanks, Henry. On 12/01/06, PP wrote: > > "That doesn't seem like p2p that we discuss in this list." > > With my limited knowledge and experience, I think, in no case, a client > can > just be installed, boot up and immediately locate its buddies, without > looking up some sort of central server (eg. for address of at least one > super node), unless the client assumes "flooding" search approach, can it? > > Peter > ----- Original Message ----- > From: "Benny Prijono" > To: > Cc: ; "'Siva Ravikumar'" ; > > Sent: Wednesday, January 11, 2006 2:56 PM > Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com > > > > Henry Sinnreich wrote: > > > I am pleased to share there is a nifty public P2P SIP service out > there: > > > > > > http://damaka.com/download.htm > > > > > > It is a pretty rich product that works apparently both P2P and CS SIP, > has > > > presence, IM, voice, video, lots of nice applications and NAT > traversal > > > without any network servers. > > > > > > This group is best qualified to give Damaka a hearty welcome! > > > > > > > Henry, > > > > Is it really "public" and "p2p SIP" as you claimed? > > > > I just downloaded and tried the client, and it seems that you can only > > call (or be called by, maybe) people in the same damaka network. > > Hardly "public" by average definitions, and surprisingly matches > > perfectly the definition of "walled garden", which we love to discuss. > > > > I listened to a podcast, they say the way it works is: > > > > "the client contacts the (central) server to get the address of the > > buddies, then the client call the buddy directly without going through > > any server". > > > > That doesn't seem like p2p that we discuss in this list. Maybe someone > > would clarify. It will be great to have more details. > > > > -benny > > > > > > > > > > _______________________________________________ > 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/20060112/714a90e5/attachment.html From lists at bulukucing.org Thu Jan 12 12:24:03 2006 From: lists at bulukucing.org (Benny Prijono) Date: Thu, 12 Jan 2006 17:24:03 +0000 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <001b01c61795$e1201560$030aa8c0@ao.lop.com> References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> <001b01c61795$e1201560$030aa8c0@ao.lop.com> Message-ID: <43C690B3.8070504@bulukucing.org> PP wrote: > "That doesn't seem like p2p that we discuss in this list." > > With my limited knowledge and experience, I think, in no case, a client can > just be installed, boot up and immediately locate its buddies, without > looking up some sort of central server (eg. for address of at least one > super node), unless the client assumes "flooding" search approach, can it? > I wouldn't say it's impossible; in fact that's one of the key problem that P2P SIP would like to address, i.e. to remove the requirement of having one central server. draft-bryan-sipping-p2p-01.txt talks about several ways to bootstrap the client: 1. to contact list of "well known" supernodes. 2. to contact cached address of my buddies, if I already have buddies. 3. or to "flood" (multicast, or whatever). Option 2 is pretty good actually. Today, if I start up my Yahoo Messenger, I *always* have one or more buddies online, no matter what the time is. So I would say that if you have >70 buddies, there is a good chance that you'll be able to bootstrap your P2P client by contacting the buddies at their cached address. When you're installing the client for the first time, the P2P service provider may preconfigure the client with "virtual buddies" (e.g. "London Echo server", "NY Echo Server"), so that the client can bootstrap with Option 2 above. Or with list of supernodes, for bootstrapping with Option 1. But still the very idea of P2P is there shouldn't be a central server. -benny > Peter From huang-ming.pan at comcast.net Thu Jan 12 12:33:33 2006 From: huang-ming.pan at comcast.net (PP) Date: Thu, 12 Jan 2006 09:33:33 -0800 Subject: [p2p-sip] Public P2P SIP service: Damaka.com References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> <001b01c61795$e1201560$030aa8c0@ao.lop.com> <43C690B3.8070504@bulukucing.org> Message-ID: <004301c6179e$5682c480$030aa8c0@ao.lop.com> > 1. to contact list of "well known" supernodes. Isn't this some sort of centralization? How many pre-known super nodes to configure in all uniformly downloaded soft clients or manufactured hard clients? > 2. to contact cached address of my buddies, if I already have buddies. Where did the "cached" address come from for a client that is launched the very first time? > 3. or to "flood" (multicast, or whatever). How to multicast on WAN without blindly flooding the Internet? Peter ----- Original Message ----- From: "Benny Prijono" To: "PP" Cc: ; ; "'Siva Ravikumar'" ; Sent: Thursday, January 12, 2006 9:24 AM Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com > PP wrote: > > "That doesn't seem like p2p that we discuss in this list." > > > > With my limited knowledge and experience, I think, in no case, a client can > > just be installed, boot up and immediately locate its buddies, without > > looking up some sort of central server (eg. for address of at least one > > super node), unless the client assumes "flooding" search approach, can it? > > > > I wouldn't say it's impossible; in fact that's one of the key problem > that P2P SIP would like to address, i.e. to remove the requirement of > having one central server. > > draft-bryan-sipping-p2p-01.txt talks about several ways to bootstrap > the client: > > 1. to contact list of "well known" supernodes. > 2. to contact cached address of my buddies, if I already have buddies. > 3. or to "flood" (multicast, or whatever). > > Option 2 is pretty good actually. Today, if I start up my Yahoo > Messenger, I *always* have one or more buddies online, no matter what > the time is. So I would say that if you have >70 buddies, there is a > good chance that you'll be able to bootstrap your P2P client by > contacting the buddies at their cached address. > > When you're installing the client for the first time, the P2P service > provider may preconfigure the client with "virtual buddies" (e.g. > "London Echo server", "NY Echo Server"), so that the client can > bootstrap with Option 2 above. Or with list of supernodes, for > bootstrapping with Option 1. > > But still the very idea of P2P is there shouldn't be a central server. > > -benny > > > > Peter > From matthewsp at avaya.com Thu Jan 12 12:51:18 2006 From: matthewsp at avaya.com (Matthews, Philip (Philip)) Date: Thu, 12 Jan 2006 12:51:18 -0500 Subject: [p2p-sip] Public P2P SIP service: Damaka.com Message-ID: Benny Prijono wrote: > draft-bryan-sipping-p2p-01.txt talks about several ways to bootstrap > the client: > > 1. to contact list of "well known" supernodes. > 2. to contact cached address of my buddies, if I already have buddies. > 3. or to "flood" (multicast, or whatever). > These three techniques all work pretty well in large P2P SIP networks (many thousands of peers). Thus Skype and most of the large file-sharing P2P networks rely on these techniques. But they do not work as well in smaller P2P SIP networks. Consider, for example, the "Ad-Hoc and Ephemeral Group" use-case described in the use-case draft. In this use-case: - There are no "well known" supernodes since the network was only recently created. - When you join for the first time, you have no buddy list. Or, if it has been a while since you last were on the network, your buddies may all have different IP addresses (for DHCP and/or NAT reasons). - If the nodes are located on different subnets, multicast may not work. In this case, you must either learn an IP address (and port, if NATs are involved) of another peer through out-of-band techniques ("Hey Joe, what's your IP address?") or use a rendevous server. - Philip From henry at pulver.com Thu Jan 12 12:53:47 2006 From: henry at pulver.com (Henry Sinnreich) Date: Thu, 12 Jan 2006 11:53:47 -0600 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <43C690B3.8070504@bulukucing.org> Message-ID: <200601121754.k0CHrmGt027987@cs.columbia.edu> >the key problem that P2P SIP would like to address, i.e. >to remove the requirement of having one central server. It is not the cost of the servers and all the other useless VoIP infrastructure (SBC, softswitch, media server, component servers, QoS network gear, MPLS, QoS monitoring, policy servers, etc.) but the cost of the operations payroll for 7x24 staffing, plus manager, plus director, plus VP, plus politics,... VoIP operations payroll + complexity of VoIP infrastructure = get broke. The self organizing property of P2P is nothing short of a revolution in communication services. Besides the better resiliency, control in the endpoint, getting rid of all the legacy telecom fetishes, etc., etc. Thanks, Henry -----Original Message----- From: Benny Prijono [mailto:lists at bulukucing.org] Sent: Thursday, January 12, 2006 11:24 AM To: PP Cc: henry at pulver.com; p2p-sip at cs.columbia.edu; 'Siva Ravikumar'; satish at damaka.net Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com PP wrote: > "That doesn't seem like p2p that we discuss in this list." > > With my limited knowledge and experience, I think, in no case, a client can > just be installed, boot up and immediately locate its buddies, without > looking up some sort of central server (eg. for address of at least one > super node), unless the client assumes "flooding" search approach, can it? > I wouldn't say it's impossible; in fact that's one of the key problem that P2P SIP would like to address, i.e. to remove the requirement of having one central server. draft-bryan-sipping-p2p-01.txt talks about several ways to bootstrap the client: 1. to contact list of "well known" supernodes. 2. to contact cached address of my buddies, if I already have buddies. 3. or to "flood" (multicast, or whatever). Option 2 is pretty good actually. Today, if I start up my Yahoo Messenger, I *always* have one or more buddies online, no matter what the time is. So I would say that if you have >70 buddies, there is a good chance that you'll be able to bootstrap your P2P client by contacting the buddies at their cached address. When you're installing the client for the first time, the P2P service provider may preconfigure the client with "virtual buddies" (e.g. "London Echo server", "NY Echo Server"), so that the client can bootstrap with Option 2 above. Or with list of supernodes, for bootstrapping with Option 1. But still the very idea of P2P is there shouldn't be a central server. -benny > Peter From lists at bulukucing.org Thu Jan 12 13:05:02 2006 From: lists at bulukucing.org (Benny Prijono) Date: Thu, 12 Jan 2006 18:05:02 +0000 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <004301c6179e$5682c480$030aa8c0@ao.lop.com> References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> <001b01c61795$e1201560$030aa8c0@ao.lop.com> <43C690B3.8070504@bulukucing.org> <004301c6179e$5682c480$030aa8c0@ao.lop.com> Message-ID: <43C69A4E.8010006@bulukucing.org> Peter, PP wrote: >>1. to contact list of "well known" supernodes. > > > Isn't this some sort of centralization? To some degree, maybe yes. And I don't think it's possible to have a completely distributed P2P network without supernodes (taking into account NAT traversal). So yes, this is some sort of centralization to some degree. But there is still a big difference between having several supernodes and *one* central logical server. It is this *one* central server that we don't want to have in P2P SIP. > How many pre-known super nodes to > configure in all uniformly downloaded soft clients or manufactured hard > clients? > Well, I don't know. And I don't quite catch what you meant I'm affraid. I guess the answer is "enough", to guarantee that clients can bootstrap. > >>2. to contact cached address of my buddies, if I already have buddies. > > > Where did the "cached" address come from for a client that is launched the > very first time? > That wouldn't be possible, of course. But like I said, if you're a service provider, you can do a trick by putting virtual buddies (just like "Echo Server" in Skype) preconfigured in the client, so that the client can bootstrap. > >>3. or to "flood" (multicast, or whatever). > > > How to multicast on WAN without blindly flooding the Internet? > I trully don't know.. But it may still be a valid options to try, when else fail. Who knows may be somebody else in my office is using the same SIP P2P network. -benny > Peter From huang-ming.pan at comcast.net Thu Jan 12 13:32:05 2006 From: huang-ming.pan at comcast.net (PP) Date: Thu, 12 Jan 2006 10:32:05 -0800 Subject: [p2p-sip] Public P2P SIP service: Damaka.com References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> <001b01c61795$e1201560$030aa8c0@ao.lop.com> <43C690B3.8070504@bulukucing.org> <004301c6179e$5682c480$030aa8c0@ao.lop.com> <43C69A4E.8010006@bulukucing.org> Message-ID: <005501c617a6$7da2d070$030aa8c0@ao.lop.com> Benny, Thanks for the comments. > But there is still a big difference between having several supernodes > and *one* central logical server. It is this *one* central server that > we don't want to have in P2P SIP. As i know, in current C/S deployments such as Vonage, SunRocket, and Net2Phone, "one single central server" approach never happen. Clients are provisioned with a long list of proxies/registrars for redundancy and load balance. However, their "fewer" provisioning serverS seem more like "centralized" stuff then. Anyway I'm here all for p2p not for c/s. Just don't know, at least not yet seen here, that an approach without any centralized stuff can be possible for commercial practices, from download/manufacture, bootstrapping, the first call routing to later on maintaining a usable DHT finger table without assistance of some "centralized" stuff. Even Skype has one sort of centralization -- signup servers which all Skype clients must contact at least once during their life time and signin servers which any Skype clients must contact every time when it boots up. I must admire Skype engineers who seem sophisticated in provisioning and operating a strong secure VoIP network both in design phase and operation phase -- even it is not 100% p2p. Maybe a short-term goal here can be a network that has everything Skype currently has but just replaces its call signaling protocol with SIP. At least, one network should come out quickly with no less sophistication than Skype has. peter ----- Original Message ----- From: "Benny Prijono" To: "PP" Cc: ; ; "'Siva Ravikumar'" ; Sent: Thursday, January 12, 2006 10:05 AM Subject: Re: [p2p-sip] Public P2P SIP service: Damaka.com > Peter, > > PP wrote: > >>1. to contact list of "well known" supernodes. > > > > > > Isn't this some sort of centralization? > > To some degree, maybe yes. And I don't think it's possible to have a > completely distributed P2P network without supernodes (taking into > account NAT traversal). So yes, this is some sort of centralization to > some degree. > > But there is still a big difference between having several supernodes > and *one* central logical server. It is this *one* central server that > we don't want to have in P2P SIP. > > > How many pre-known super nodes to > > configure in all uniformly downloaded soft clients or manufactured hard > > clients? > > > > Well, I don't know. And I don't quite catch what you meant I'm > affraid. I guess the answer is "enough", to guarantee that clients can > bootstrap. > > > > >>2. to contact cached address of my buddies, if I already have buddies. > > > > > > Where did the "cached" address come from for a client that is launched the > > very first time? > > > > That wouldn't be possible, of course. > But like I said, if you're a service provider, you can do a trick by > putting virtual buddies (just like "Echo Server" in Skype) > preconfigured in the client, so that the client can bootstrap. > > > > >>3. or to "flood" (multicast, or whatever). > > > > > > How to multicast on WAN without blindly flooding the Internet? > > > > I trully don't know.. > But it may still be a valid options to try, when else fail. Who knows > may be somebody else in my office is using the same SIP P2P network. > > > -benny > > > Peter From lists at bulukucing.org Thu Jan 12 13:32:06 2006 From: lists at bulukucing.org (Benny Prijono) Date: Thu, 12 Jan 2006 18:32:06 +0000 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] In-Reply-To: References: Message-ID: <43C6A0A6.80506@bulukucing.org> [changed the subject] Philip, What you said below are all valid problems that are being solved by our dear SIP P2P designers (i.e. not me, hehe..). I'm just saying from what I read in drafts/articles. But I just came up with an idea. Instead of designing SIP P2P *protocol*, why don't we design a SIP P2P *universe*. Just like we have one universe for IP network (the Internet), we will have *one* SIP P2P network for the whole universe. Only one. All service providers shares the same network infrastructure (i.e. nodes, supernodes). They will just have different domain/realm. So are "Ad-Hoc and Ephemeral Groups", they're just a temporary domain/realm. I believe that would solve our little bootstrapping problems. :) Does this make sense? Any study been done in this area? -benny Matthews, Philip (Philip) wrote: > Benny Prijono wrote: > >>draft-bryan-sipping-p2p-01.txt talks about several ways to bootstrap >>the client: >> >>1. to contact list of "well known" supernodes. >>2. to contact cached address of my buddies, if I already have buddies. >>3. or to "flood" (multicast, or whatever). >> > > > These three techniques all work pretty well in large P2P SIP networks > (many thousands of peers). Thus Skype and most of the large file-sharing > P2P networks > rely on these techniques. > > But they do not work as well in smaller P2P SIP networks. Consider, for > example, > the "Ad-Hoc and Ephemeral Group" use-case described in the use-case > draft. > In this use-case: > - There are no "well known" supernodes since the network was only > recently created. > - When you join for the first time, you have no buddy list. > Or, if it has been a while since you last were on the network, your > buddies may all > have different IP addresses (for DHCP and/or NAT reasons). > - If the nodes are located on different subnets, multicast may not work. > > In this case, you must either learn an IP address (and port, if NATs are > involved) > of another peer through out-of-band techniques ("Hey Joe, what's your IP > address?") > or use a rendevous server. > > - Philip > From lists at bulukucing.org Thu Jan 12 13:46:12 2006 From: lists at bulukucing.org (Benny Prijono) Date: Thu, 12 Jan 2006 18:46:12 +0000 Subject: [p2p-sip] Public P2P SIP service: Damaka.com In-Reply-To: <005501c617a6$7da2d070$030aa8c0@ao.lop.com> References: <200601112038.k0BKcNGt004705@cs.columbia.edu> <43C58D36.80609@bulukucing.org> <001b01c61795$e1201560$030aa8c0@ao.lop.com> <43C690B3.8070504@bulukucing.org> <004301c6179e$5682c480$030aa8c0@ao.lop.com> <43C69A4E.8010006@bulukucing.org> <005501c617a6$7da2d070$030aa8c0@ao.lop.com> Message-ID: <43C6A3F4.2020907@bulukucing.org> PP wrote: >>But there is still a big difference between having several supernodes >>and *one* central logical server. It is this *one* central server that >>we don't want to have in P2P SIP. > > > As i know, in current C/S deployments such as Vonage, SunRocket, and > Net2Phone, "one single central server" approach never happen. Clients are > provisioned with a long list of proxies/registrars for redundancy and load > balance. However, their "fewer" provisioning serverS seem more like > "centralized" stuff then. > That's why I said *logical* server, not just "server" ;) (although to be fair, I missed the "logical" word in the second sentence). I might as well have chosen a completely wrong word for that. -benny From matthewsp at avaya.com Thu Jan 12 13:50:57 2006 From: matthewsp at avaya.com (Matthews, Philip (Philip)) Date: Thu, 12 Jan 2006 13:50:57 -0500 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] Message-ID: Benny, Your proposal for a P2P SIP "universe" is certainly technically feasible. However, there is a question of how acceptable it would be to customers and 'service providers' (where 'service provider' in this context has a somewhat unusual meaning!!). Consider the application that I am interested in, that of an Enterprise PBX built using P2P SIP technology. Under your proposal, information about users and devices (= hard and soft phones) for company X may well be stored on devices owned by company Y. If company X and Y are fierce competitors, that may not be politically acceptable. Or course, if both companies use Skype this happens today, but perception can be important. Also, this proposal doesn't work in the "Ad-Hoc and Ephemeral Groups" case where phones do not have access to the Internet. I think this is an interesting question for us to debate. Are we building a protocol for one world-wide network, or for multiple independent networks? - Philip > -----Original Message----- > From: Benny Prijono [mailto:lists at bulukucing.org] > Sent: January 12, 2006 13:32 > To: Matthews, Philip (Philip) > Cc: p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP > service: Damaka.com] > > [changed the subject] > > Philip, > > What you said below are all valid problems that are being solved by > our dear SIP P2P designers (i.e. not me, hehe..). I'm just > saying from > what I read in drafts/articles. > > But I just came up with an idea. > > Instead of designing SIP P2P *protocol*, why don't we design > a SIP P2P > *universe*. Just like we have one universe for IP network (the > Internet), we will have *one* SIP P2P network for the whole universe. > Only one. > > All service providers shares the same network infrastructure (i.e. > nodes, supernodes). They will just have different > domain/realm. So are > "Ad-Hoc and Ephemeral Groups", they're just a temporary domain/realm. > > I believe that would solve our little bootstrapping problems. :) > > Does this make sense? Any study been done in this area? > > -benny > > Matthews, Philip (Philip) wrote: > > Benny Prijono wrote: > > > >>draft-bryan-sipping-p2p-01.txt talks about several ways to > bootstrap > >>the client: > >> > >>1. to contact list of "well known" supernodes. > >>2. to contact cached address of my buddies, if I already > have buddies. > >>3. or to "flood" (multicast, or whatever). > >> > > > > > > These three techniques all work pretty well in large P2P > SIP networks > > (many thousands of peers). Thus Skype and most of the large > file-sharing > > P2P networks > > rely on these techniques. > > > > But they do not work as well in smaller P2P SIP networks. > Consider, for > > example, > > the "Ad-Hoc and Ephemeral Group" use-case described in the use-case > > draft. > > In this use-case: > > - There are no "well known" supernodes since the network was only > > recently created. > > - When you join for the first time, you have no buddy list. > > Or, if it has been a while since you last were on the > network, your > > buddies may all > > have different IP addresses (for DHCP and/or NAT reasons). > > - If the nodes are located on different subnets, multicast > may not work. > > > > In this case, you must either learn an IP address (and > port, if NATs are > > involved) > > of another peer through out-of-band techniques ("Hey Joe, > what's your IP > > address?") > > or use a rendevous server. > > > > - Philip > > > > From lists at bulukucing.org Thu Jan 12 16:36:50 2006 From: lists at bulukucing.org (Benny Prijono) Date: Thu, 12 Jan 2006 21:36:50 +0000 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] In-Reply-To: References: Message-ID: <43C6CBF2.3000905@bulukucing.org> Philip, let me again assert my position that I'm not in any way knowledgeable in P2P technology, so what I'm going to say here is purely based only on reading couple of sip p2p drafts. But I would say they're quite logical. For the sake of discussions, let me try to push my argument to the limit, until someone says "stop! it's silly, get out of here!". I have two main motivation for proposing a single sip p2p universe. First, it sounds great! A trully global, free, sip p2p network without border. Second, because once we solved all the problems with "normal" sip p2p protocol, I suppose we'll end up with a protocol that is good enough to build this global sip p2p network. Because the issues that we need to solve in "global" sip p2p network *are* basicly the same issues in "normal" sip p2p. The only differences are: - number of nodes will be bigger, which I suppose is not a big deal. Once we design p2p protocol to accomodate 221 million users, it should be good enough to handle 10 billion users (or limit it to 4 billion, if we want to stick with 32bit unsigned integer). - p2p overlays need to work together. So if a request arrive in a node from different overlay, the node should at least be able to direct the request to other node which it thinks belong to/or closer to the correct overlay. While the benetifs of one global sip p2p network are: - more supernodes, means easier bootstrap, more reliable, more connectivity, more routing choices, better network quality. - no more walled garden. People (or "service providers") know that they need to work together to make the network works. Once they put wall in their garden, everybody will put wall in their garden too, and the network will collapse, and so is their business. Now to address specific issues that you raised: - security. Same issue with "normal" and "global" sip p2p. Remember that there is only one sip p2p protocol. If this issue is not addressed in "normal" sip p2p protocol, then there is nothing to protect you against malicious users trying to get access to your overlay, because the protocol itself is open and anybody can build a custom UA. But once this has been solved, it should be good for the "global" version of sip p2p. - local, ephemeral overlay. There is no reason why it shouldn't work. Just like the IP protocol, where you can build a local/private network, there's nothing stopping you from building your local SIP p2p network using the very same sip p2p protocol. Same as you, I'm waiting for someone more knowledgeable to step-in in the discussion. -benny Matthews, Philip (Philip) wrote: > Benny, > > Your proposal for a P2P SIP "universe" is certainly technically > feasible. > > However, there is a question of how acceptable it would be to customers > and 'service providers' (where 'service provider' in this context has a > somewhat unusual meaning!!). > > Consider the application that I am interested in, that of an Enterprise > PBX built using P2P SIP technology. > > Under your proposal, information about users and devices (= hard and > soft > phones) for company X may well be stored on devices owned by company Y. > If company X and Y are fierce competitors, that may not be politically > acceptable. Or course, if both companies use Skype this happens today, > but perception can be important. > > Also, this proposal doesn't work in the "Ad-Hoc and Ephemeral Groups" > case > where phones do not have access to the Internet. > > I think this is an interesting question for us to debate. > Are we building a protocol for one world-wide network, or for multiple > independent networks? > > - Philip > > From slavitch at gmail.com Thu Jan 12 16:52:30 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 12 Jan 2006 16:52:30 -0500 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] In-Reply-To: <43C6CBF2.3000905@bulukucing.org> References: <43C6CBF2.3000905@bulukucing.org> Message-ID: <1fc32c8f0601121352s6d647021y@mail.gmail.com> This is EXACTLY what I want to see with P2P SIP. A global SIP galaxy, interconnecting thousands of small communities or sub-communities or sub-sub-communities. Now the sub-communites could be P2P communities, regular SIP domains, or even proprietary things like MSN, or (horrors) the traditional PSTN using gateways that convert the global P2P context to whatever context the local domain is in. Now, define "free". Communications between P2P entities will likely be "free" after the pipe and the bits are paid for, but the P2P services that operate on the network? That's something else, something that could be subscribed to and charged for. How that subscription is done is another issue, for a later standard, once the dust settles and global P2P SIP is a reality. How sub-communities, services and such publish themselves in the global community, so that they can be found? That too is for later once the dust settles. But first, let us build the underlying infrastructure that supports this. Let's stop pussyfooting around. On 12/01/06, Benny Prijono wrote: > > Philip, > > let me again assert my position that I'm not in any way knowledgeable > in P2P technology, so what I'm going to say here is purely based only > on reading couple of sip p2p drafts. But I would say they're quite > logical. > > For the sake of discussions, let me try to push my argument to the > limit, until someone says "stop! it's silly, get out of here!". > > I have two main motivation for proposing a single sip p2p universe. > > First, it sounds great! A trully global, free, sip p2p network without > border. > > Second, because once we solved all the problems with "normal" sip p2p > protocol, I suppose we'll end up with a protocol that is good enough > to build this global sip p2p network. Because the issues that we need > to solve in "global" sip p2p network *are* basicly the same issues in > "normal" sip p2p. > > The only differences are: > - number of nodes will be bigger, which I suppose is not a big deal. > Once we design p2p protocol to accomodate 221 million users, it should > be good enough to handle 10 billion users (or limit it to 4 billion, > if we want to stick with 32bit unsigned integer). > > - p2p overlays need to work together. So if a request arrive in a node > from different overlay, the node should at least be able to direct the > request to other node which it thinks belong to/or closer to the > correct overlay. > > While the benetifs of one global sip p2p network are: > - more supernodes, means easier bootstrap, more reliable, more > connectivity, more routing choices, better network quality. > > - no more walled garden. People (or "service providers") know that > they need to work together to make the network works. Once they put > wall in their garden, everybody will put wall in their garden too, and > the network will collapse, and so is their business. > > Now to address specific issues that you raised: > - security. Same issue with "normal" and "global" sip p2p. Remember > that there is only one sip p2p protocol. If this issue is not > addressed in "normal" sip p2p protocol, then there is nothing to > protect you against malicious users trying to get access to your > overlay, because the protocol itself is open and anybody can build a > custom UA. But once this has been solved, it should be good for the > "global" version of sip p2p. > > - local, ephemeral overlay. There is no reason why it shouldn't work. > Just like the IP protocol, where you can build a local/private > network, there's nothing stopping you from building your local SIP p2p > network using the very same sip p2p protocol. > > > Same as you, I'm waiting for someone more knowledgeable to step-in in > the discussion. > > -benny > > > Matthews, Philip (Philip) wrote: > > Benny, > > > > Your proposal for a P2P SIP "universe" is certainly technically > > feasible. > > > > However, there is a question of how acceptable it would be to customers > > and 'service providers' (where 'service provider' in this context has a > > somewhat unusual meaning!!). > > > > Consider the application that I am interested in, that of an Enterprise > > PBX built using P2P SIP technology. > > > > Under your proposal, information about users and devices (= hard and > > soft > > phones) for company X may well be stored on devices owned by company Y. > > If company X and Y are fierce competitors, that may not be politically > > acceptable. Or course, if both companies use Skype this happens today, > > but perception can be important. > > > > Also, this proposal doesn't work in the "Ad-Hoc and Ephemeral Groups" > > case > > where phones do not have access to the Internet. > > > > I think this is an interesting question for us to debate. > > Are we building a protocol for one world-wide network, or for multiple > > independent networks? > > > > - Philip > > > > > _______________________________________________ > 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/20060112/86dfae47/attachment.html From drage at lucent.com Fri Jan 13 10:19:04 2006 From: drage at lucent.com (Drage, Keith (Keith)) Date: Fri, 13 Jan 2006 15:19:04 -0000 Subject: [p2p-sip] Requirements Explosion Message-ID: <475FF955A05DD411980D00508B6D5FB011BDD4FB@en0033exch001u.uk.lucent.com> Could I suggest then that part of the draft charter we write for the BOF contains something along the lines of: (having of course scoped the mechanism first) The mechanism will provide a means of sending a SIP method (possibly unknown) containing SIP headers (possibly unknown) and message bodies, to a SIP-URI or other URI within a Request-URI parameter. This means we have a goal of supporting a large number of existing SIP mechanisms that already operate end to end, and which will continue to do so. regards Keith > -----Original Message----- > From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > Sent: 11 January 2006 20:53 > To: Drage, Keith (Keith) > Cc: henry at pulver.com; p2p-sip at cs.columbia.edu > Subject: Re: [p2p-sip] Requirements Explosion > > > Please let me try to supplement the comments about > 'point-to-point SIP > stuff'. > > I seems we need a document about the different P2P SIP design > approaches > so that we can synchronize our discussion in the mailing list more > efficiently. > I will try to prepare the document as soon as possible. > Meanwhile, I'd > like to encourage people to review the presentation I gave in > Vancouver > (http://www.p2psip.org/ietf64.php Presentation on comparison of pure > SIP vs DHT based solutions > Shim.ppt>). > Kundan's email describes what needs to be done if we follow the DHT > based approach (or External DHT approach) (Obviously we need to unify > the term to call the approach). > > Please let me try to explain or reiterate some points here. > > - If we follow the DHT based approach, the SIP call control > procedures > are independent of DHT maintenance (join/leave) and resource > lookup and > placement. In an extreme, nothing has to be changed in the > SIP messages. > To realize P2P SIP (or P2P style SIP-based Internet > telephony, IM, etc), > we need to define three things in this approach: a protocol for DHT > maintenance and resource lookup/placement, resources types and their > data formats for the resources to be placed in the P2P > overlay network, > and the rules to generate the resource ID given a resource > type and its > data format. Once the resource ID is set, the underling DHT > determines > where to place the resource and how to look it up. > > A most important resource (data) is the user location > (mapping of URI to > IP address). For a basic one-to-one call setup without NAT/FW > traversal, > the user location is all we need to place in the overlay network and > lookup. It is the same whether the call is audio-only or audio/video > together. > For Presence, we need a format for presence data. A peer storing > presence data of another peer will behave as a presence server. > > More advanced or complex session control procedures may need > more work > for P2P style operation. > For conferencing, we can have some choices: whether we will > make a peer > play a role of a rendezvous point or design a more distributed > operation. If a peer becomes a rendezvous point, XCON will > work almost > as it is on top of the P2P overlay network. If we want a more > distributed conferencing control, it will become a topic on its own. > Probably it is not in scope of the future P2P SIP WG. > > As you can see, the protocol(s) for DHT maintenance and resource > lookup/placement is independent of SIP call control procedures, > services, and resource types. Once the protocol is well > designed, we can > enhance the services/features of P2P SIP step by step without > changing > the protocol. So the point made by some people, including > Kundan, in my > understanding, is that we should start with a limited set of SIP > features and design the protocol for DHT maintenance and resource > lookup/placement and a limited set of resource types (and formats) > required for the feauters. By doing this, I would say we will achieve > the most important piece(s) for P2P SIP. In this sense, > whether we cover > any specific method or header field or an option in various > RFCs is not > important in the beginning. > > This does not mean we don't care about supporting all kinds > of advanced > SIP features in P2P SIP domain. I believe no one disregards the > importance of interoperation between P2P SIP domain and client-server > SIP domain (and even PSTN). > > I guess many RFCs related to SIP won't require any new data > type/format > for SIP operation in P2P fashion. But eventually every single SIP > feature should be checked whether it requires a new data > type/format to > be placed in the P2P overlay network or even a new call control > procedure for P2P SIP, if we want to make sure all the SIP features > described in every SIP related RFC can be used in P2P SIP > domain. Again, > what has been suggested is that we focus on simple and widely used > features first and worry about others later (in ordely > fashion as David > Barret described). > > - If we follow the other design approach where DHT maintenance and > resource lookup/placement are integrated tightly with existing SIP > procedures and messages, the design work becomes less > modular. In this > approach, it is actually more important to select some of the SIP > features we want support with P2P SIP in the beginning. As we move > forward to support more and more SIP features in P2P SIP > domain, it is > likely that we will be doing still lots of work everytime we > add a new > SIP feature into P2P SIP domain because of poor modularity of > the design. > > So could we agree on a small set of SIP features as our stating point? > > Regards, > > Eunsoo > > // > Drage, Keith (Keith) wrote: > > >I'm afraid I have totally lost the purpose of this > point-to-point SIP stuff - or rather I think some of the > other members of this list have. > > > >If it is going to be called SIP, then all entities must at > least follow some basic SIP compatibility rules. I assume > also that SIP methods and headers that normally operate > between user agents will still operate between user agents. > It should only be protocol that is currently impacted by > stuff in the middle that should in any way be impacted by the > scope of this work. > > > >So maybe can I propose that SIP p2p supports all SIP methods > and headers that normally operate only on a UA to UA basis. > If we agree that, then we automatically support 90% of all > the SIP RFCs that exist out there, including presence, IM and video. > > > >P2P SIP should only impact the protocol elements that deal > with making sure that end-to-end stuff happens. > > > >Thus while I might expect that something like Path or > Service-Route will not work, or anything based on "trust > domains", I would like to be confident that something like > SUBSCRIBE or Replaces does. > > > >If people really want to build something that doesn't do > that, then surely you need to change the title of the list, > as it is no longer SIP - and we will see where the IETF stand > in terms of inventing a totally new VOIP protocol. > > > >Remember, in Vancouver, I believe we were trying to address > something that could be done by an IETF group, the discussion > I have seen over the last few days seems to be determined to > consign all the work to IRTF. > > > >regards > > > >Keith > > > > > > > >>-----Original Message----- > >>From: p2p-sip-bounces at cs.columbia.edu > >>[mailto:p2p-sip-bounces at cs.columbia.edu]On Behalf Of Eunsoo Shim > >>Sent: 11 January 2006 18:42 > >>To: henry at pulver.com > >>Cc: p2p-sip at cs.columbia.edu > >>Subject: Re: [p2p-sip] Requirements Explosion > >> > >> > >>Henry Sinnreich wrote: > >> > >> > >> > >>>>for basic audio-only no-NAT > >>>>SIP user agent > >>>> > >>>> > >>>> > >>>> > >>>I hope we include presence and IM right from the start and > >>> > >>> > >>see no difference > >> > >> > >>>if video will be there as well. > >>> > >>> > >>> > >>> > >>> > >>I believe, once we have a design to support audio-only SIP > >>user agents > >>following the external DHT approach (or DHT-based approach), > >>it will be > >>fairly straightforward to support presence, IM and video in > >>that approach. > >>So I support Henry's proposal with respect to setting our > >>very initial > >>design target. > >>Thanks. > >> > >>Eunsoo > >> > >> > >> > >>>Thanks, Henry > >>> > >>>-----Original Message----- > >>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > >>>Sent: Wednesday, January 11, 2006 9:09 AM > >>>To: Kundan Singh > >>>Cc: p2p-sip at cs.columbia.edu > >>>Subject: Re: [p2p-sip] Requirements Explosion > >>> > >>> > >>> > >>> > >>> > >>> > >>>>So in conclusion, I think we should start with defining > the generic > >>>>location-service and P2P-service protocol, and then > >>>> > >>>> > >>specific data format > >> > >> > >>>>for SIP-location-service, and implement it for basic > >>>> > >>>> > >>audio-only no-NAT > >> > >> > >>>>SIP user agent and basic SIP proxy and registrar using some > >>>> > >>>> > >>existing > >> > >> > >>>>DHT/P2P algorithm. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>I like this proposal a lot like many other people. > >>>Regards, > >>> > >>>Eunsoo > >>> > >>> > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>p2p-sip mailing list > >>p2p-sip at cs.columbia.edu > >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >> > >> > >> > From royrr at us.saic.com Fri Jan 13 13:14:15 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Fri, 13 Jan 2006 13:14:15 -0500 Subject: [p2p-sip] Requirements Explosion Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F6233EA@0591-its-exmp01.us.saic.com> Keith: I would support this approach as a part of p2p-SIP protocol. In fact, if we follow this, we can reuse all the features of SIP that are already p2p. In this case, we need NOT to build a new p2p protocol from the scratch to solve all the problems that we are discussing. That is why, I asked the pointed question to Kundan, and we got his answer that is NOT along the line of the above approach. Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Drage, Keith (Keith) Sent: Fri 1/13/2006 10:19 AM To: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Requirements Explosion Could I suggest then that part of the draft charter we write for the BOF contains something along the lines of: (having of course scoped the mechanism first) The mechanism will provide a means of sending a SIP method (possibly unknown) containing SIP headers (possibly unknown) and message bodies, to a SIP-URI or other URI within a Request-URI parameter. This means we have a goal of supporting a large number of existing SIP mechanisms that already operate end to end, and which will continue to do so. regards Keith From huang-ming.pan at comcast.net Fri Jan 13 14:24:28 2006 From: huang-ming.pan at comcast.net (PP) Date: Fri, 13 Jan 2006 11:24:28 -0800 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] References: <43C6CBF2.3000905@bulukucing.org> <1fc32c8f0601121352s6d647021y@mail.gmail.com> Message-ID: <005a01c61876$fc81f260$030aa8c0@ao.lop.com> Quoted: "But first, let us build the underlying infrastructure that supports this. Let's stop pussyfooting around." I agree with Michael on putting "underlying infrastructure" on the first place, before P2P and SIP, in my opinion. This is why I've been curious and worry why nobody here so far would like to address the "security" layer of the underlying infrastructure, which seems to be the most bottom layer of the foundation above transport layers. Sorry, I must mention Skype again, but Skype did spend lots of (smart) efforts on its security mechansim, though it is based on grandpa's RSA-1536/2048 public-key cryptograph that consumes much network bandwidth on key exchanging and negotiation among nodes, and not a little cpu time on private-key related operations especially on the signup servers which are responsible for signing node certificates. Without STRONG and EFFICIENT security, even 100% of SIP-related RFCs and aboundance of features are placed upon the infrastructure, the network will be severely criticized and challenged, won't it? peter ----- Original Message ----- From: Michael Slavitch To: Benny Prijono ; p2p-sip at cs.columbia.edu Sent: Thursday, January 12, 2006 1:52 PM Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] This is EXACTLY what I want to see with P2P SIP. A global SIP galaxy, interconnecting thousands of small communities or sub-communities or sub-sub-communities. Now the sub-communites could be P2P communities, regular SIP domains, or even proprietary things like MSN, or (horrors) the traditional PSTN using gateways that convert the global P2P context to whatever context the local domain is in. Now, define "free". Communications between P2P entities will likely be "free" after the pipe and the bits are paid for, but the P2P services that operate on the network? That's something else, something that could be subscribed to and charged for. How that subscription is done is another issue, for a later standard, once the dust settles and global P2P SIP is a reality. How sub-communities, services and such publish themselves in the global community, so that they can be found? That too is for later once the dust settles. But first, let us build the underlying infrastructure that supports this. Let's stop pussyfooting around. On 12/01/06, Benny Prijono wrote: Philip, let me again assert my position that I'm not in any way knowledgeable in P2P technology, so what I'm going to say here is purely based only on reading couple of sip p2p drafts. But I would say they're quite logical. For the sake of discussions, let me try to push my argument to the limit, until someone says "stop! it's silly, get out of here!". I have two main motivation for proposing a single sip p2p universe. First, it sounds great! A trully global, free, sip p2p network without border. Second, because once we solved all the problems with "normal" sip p2p protocol, I suppose we'll end up with a protocol that is good enough to build this global sip p2p network. Because the issues that we need to solve in "global" sip p2p network *are* basicly the same issues in "normal" sip p2p. The only differences are: - number of nodes will be bigger, which I suppose is not a big deal. Once we design p2p protocol to accomodate 221 million users, it should be good enough to handle 10 billion users (or limit it to 4 billion, if we want to stick with 32bit unsigned integer). - p2p overlays need to work together. So if a request arrive in a node from different overlay, the node should at least be able to direct the request to other node which it thinks belong to/or closer to the correct overlay. While the benetifs of one global sip p2p network are: - more supernodes, means easier bootstrap, more reliable, more connectivity, more routing choices, better network quality. - no more walled garden. People (or "service providers") know that they need to work together to make the network works. Once they put wall in their garden, everybody will put wall in their garden too, and the network will collapse, and so is their business. Now to address specific issues that you raised: - security. Same issue with "normal" and "global" sip p2p. Remember that there is only one sip p2p protocol. If this issue is not addressed in "normal" sip p2p protocol, then there is nothing to protect you against malicious users trying to get access to your overlay, because the protocol itself is open and anybody can build a custom UA. But once this has been solved, it should be good for the "global" version of sip p2p. - local, ephemeral overlay. There is no reason why it shouldn't work. Just like the IP protocol, where you can build a local/private network, there's nothing stopping you from building your local SIP p2p network using the very same sip p2p protocol. Same as you, I'm waiting for someone more knowledgeable to step-in in the discussion. -benny Matthews, Philip (Philip) wrote: > Benny, > > Your proposal for a P2P SIP "universe" is certainly technically > feasible. > > However, there is a question of how acceptable it would be to customers > and 'service providers' (where 'service provider' in this context has a > somewhat unusual meaning!!). > > Consider the application that I am interested in, that of an Enterprise > PBX built using P2P SIP technology. > > Under your proposal, information about users and devices (= hard and > soft > phones) for company X may well be stored on devices owned by company Y. > If company X and Y are fierce competitors, that may not be politically > acceptable. Or course, if both companies use Skype this happens today, > but perception can be important. > > Also, this proposal doesn't work in the "Ad-Hoc and Ephemeral Groups" > case > where phones do not have access to the Internet. > > I think this is an interesting question for us to debate. > Are we building a protocol for one world-wide network, or for multiple > independent networks? > > - Philip > > _______________________________________________ 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/20060113/bf0fb36a/attachment.html From royrr at us.saic.com Fri Jan 13 14:50:32 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Fri, 13 Jan 2006 14:50:32 -0500 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.co m] Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F6233EC@0591-its-exmp01.us.saic.com> PP: Before becoming too abstracts, let us define what are those underlying infrastructures clearly (i.e.., security, routing, others, etc.) that you might have in your mind. You have explained so many things, this is good. Now, it is the time, I think, to put in a IETF draft listing those items with related problem definitions and solution objectives. Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of PP Sent: Fri 1/13/2006 2:24 PM To: Michael Slavitch; Benny Prijono; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] Quoted: "But first, let us build the underlying infrastructure that supports this. Let's stop pussyfooting around." I agree with Michael on putting "underlying infrastructure" on the first place, before P2P and SIP, in my opinion. This is why I've been curious and worry why nobody here so far would like to address the "security" layer of the underlying infrastructure, which seems to be the most bottom layer of the foundation above transport layers. Sorry, I must mention Skype again, but Skype did spend lots of (smart) efforts on its security mechansim, though it is based on grandpa's RSA-1536/2048 public-key cryptograph that consumes much network bandwidth on key exchanging and negotiation among nodes, and not a little cpu time on private-key related operations especially on the signup servers which are responsible for signing node certificates. Without STRONG and EFFICIENT security, even 100% of SIP-related RFCs and aboundance of features are placed upon the infrastructure, the network will be severely criticized and challenged, won't it? peter From Richard.Stastny at oefeg.at Fri Jan 13 03:57:16 2006 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Fri, 13 Jan 2006 09:57:16 +0100 Subject: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2338@oefeg-s04.oefeg.loc> >Now, define "free". Communications between P2P entities will likely be "free" after the pipe and the bits are paid >for, but the P2P services that operate on the network? That's something else, something that could be subscribed to >and charged for. So far I could follow the dream in this thread, but now I am getting confused: What do you mean with (centralized, subscribed, paid-for) P2P services? This is a contradiction in itself. IMHO the ONLY centralized service a P2P universe on the Internet could rely on is the DNS, where any peer is taking care of (pay-for, subscribe) by himself Richard ________________________________ From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch Sent: Thursday, January 12, 2006 10:53 PM To: Benny Prijono; p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] P2P Universe [was Public P2P SIP service: Damaka.com] This is EXACTLY what I want to see with P2P SIP. A global SIP galaxy, interconnecting thousands of small communities or sub-communities or sub-sub-communities. Now the sub-communites could be P2P communities, regular SIP domains, or even proprietary things like MSN, or (horrors) the traditional PSTN using gateways that convert the global P2P context to whatever context the local domain is in. Now, define "free". Communications between P2P entities will likely be "free" after the pipe and the bits are paid for, but the P2P services that operate on the network? That's something else, something that could be subscribed to and charged for. How that subscription is done is another issue, for a later standard, once the dust settles and global P2P SIP is a reality. How sub-communities, services and such publish themselves in the global community, so that they can be found? That too is for later once the dust settles. But first, let us build the underlying infrastructure that supports this. Let's stop pussyfooting around. On 12/01/06, Benny Prijono wrote: Philip, let me again assert my position that I'm not in any way knowledgeable in P2P technology, so what I'm going to say here is purely based only on reading couple of sip p2p drafts. But I would say they're quite logical. For the sake of discussions, let me try to push my argument to the limit, until someone says "stop! it's silly, get out of here!". I have two main motivation for proposing a single sip p2p universe. First, it sounds great! A trully global, free, sip p2p network without border. Second, because once we solved all the problems with "normal" sip p2p protocol, I suppose we'll end up with a protocol that is good enough to build this global sip p2p network. Because the issues that we need to solve in "global" sip p2p network *are* basicly the same issues in "normal" sip p2p. The only differences are: - number of nodes will be bigger, which I suppose is not a big deal. Once we design p2p protocol to accomodate 221 million users, it should be good enough to handle 10 billion users (or limit it to 4 billion, if we want to stick with 32bit unsigned integer). - p2p overlays need to work together. So if a request arrive in a node from different overlay, the node should at least be able to direct the request to other node which it thinks belong to/or closer to the correct overlay. While the benetifs of one global sip p2p network are: - more supernodes, means easier bootstrap, more reliable, more connectivity, more routing choices, better network quality. - no more walled garden. People (or "service providers") know that they need to work together to make the network works. Once they put wall in their garden, everybody will put wall in their garden too, and the network will collapse, and so is their business. Now to address specific issues that you raised: - security. Same issue with "normal" and "global" sip p2p. Remember that there is only one sip p2p protocol. If this issue is not addressed in "normal" sip p2p protocol, then there is nothing to protect you against malicious users trying to get access to your overlay, because the protocol itself is open and anybody can build a custom UA. But once this has been solved, it should be good for the "global" version of sip p2p. - local, ephemeral overlay. There is no reason why it shouldn't work. Just like the IP protocol, where you can build a local/private network, there's nothing stopping you from building your local SIP p2p network using the very same sip p2p protocol. Same as you, I'm waiting for someone more knowledgeable to step-in in the discussion. -benny Matthews, Philip (Philip) wrote: > Benny, > > Your proposal for a P2P SIP "universe" is certainly technically > feasible. > > However, there is a question of how acceptable it would be to customers > and 'service providers' (where 'service provider' in this context has a > somewhat unusual meaning!!). > > Consider the application that I am interested in, that of an Enterprise > PBX built using P2P SIP technology. > > Under your proposal, information about users and devices (= hard and > soft > phones) for company X may well be stored on devices owned by company Y. > If company X and Y are fierce competitors, that may not be politically > acceptable. Or course, if both companies use Skype this happens today, > but perception can be important. > > Also, this proposal doesn't work in the "Ad-Hoc and Ephemeral Groups" > case > where phones do not have access to the Internet. > > I think this is an interesting question for us to debate. > Are we building a protocol for one world-wide network, or for multiple > independent networks? > > - Philip > > _______________________________________________ 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/20060113/f481004a/attachment-0001.html From kns10 at cs.columbia.edu Fri Jan 13 23:04:03 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Fri, 13 Jan 2006 23:04:03 -0500 Subject: [p2p-sip] P2P Universe Message-ID: <43C87833.9070102@cs.columbia.edu> I too agree. Security is one of the main problem for any DHT-based P2P network. Although, parts of the problem are solvable. For example, using RSA keys and certificates one can verify that one is talking to the right person possibly in a private conversation. The hard part is to guarantee that the peers are co-operative and route your calls instead of silently discarding some call requests. This is especially true when the implementation is based on open protocols unlike the unmodifiable Skype implementation. PP wrote: > Quoted: "But first, let us build the underlying infrastructure that supports this. Let's stop pussyfooting around." > > I agree with Michael on putting "underlying infrastructure" on the first place, before P2P and SIP, in my opinion. This is why I've been curious and worry why nobody here so far would like to address the "security" layer of the underlying infrastructure, which seems to be the most bottom layer of the foundation above transport layers. > > Sorry, I must mention Skype again, but Skype did spend lots of (smart) efforts on its security mechansim, though it is based on grandpa's RSA-1536/2048 public-key cryptograph that consumes much network bandwidth on key exchanging and negotiation among nodes, and not a little cpu time on private-key related operations especially on the signup servers which are responsible for signing node certificates. > > Without STRONG and EFFICIENT security, even 100% of SIP-related RFCs and aboundance of features are placed upon the infrastructure, the network will be severely criticized and challenged, won't it? > > peter From kns10 at cs.columbia.edu Fri Jan 13 23:17:11 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Fri, 13 Jan 2006 23:17:11 -0500 Subject: [p2p-sip] Requirements Explosion In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F6233EA@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233EA@0591-its-exmp01.us.saic.com> Message-ID: <43C87B47.9090202@cs.columbia.edu> > I would support this approach as a part of p2p-SIP protocol. In fact, if we > follow this, we can reuse all the features of SIP that are already p2p. In > this case, we need NOT to build a new p2p protocol from the scratch to solve > all the problems that we are discussing. > > That is why, I asked the pointed question to Kundan, and we got his answer > that is NOT along the line of the above approach. Not entirely. There is a difference between 'generic protocol for the interface between application and P2P network' and 'generic P2P protocol as a replacement of Chord, Kademlia, Pastry, etc.' I suggested to work on the former before defining P2P-SIP. A well-defined protocol for the interface is necessary, in my opinion, to avoid having to deal with a number of different existing P2P networks when we want to provide P2P-SIP independent of a particular P2P network. This way, an existing P2P network needs to only provide the particular interface to be suitable for use in P2P-SIP. A well defined interface can then be made specific in the context of SIP lookup and presence for P2P-SIP. In fact DHT interfaces (get/put and join/lookup) already exist in the context of specific implementations such as OpenDHT, Chord. So we just need to survey those and generalize them to be suitable for our application. From dean.willis at softarmor.com Fri Jan 13 23:37:22 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Fri, 13 Jan 2006 22:37:22 -0600 Subject: [p2p-sip] Towards Reining In the Scope In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F6233EC@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233EC@0591-its-exmp01.us.saic.com> Message-ID: <43C88002.8030102@softarmor.com> So far I've heard ideas ranging from replacing DNS with a global search mechanism to finding a way to make a SIP supergalaxy that includes all known federations, the GSTN/PSTN, and rogue black holes in its gravitic clutches. I'm not committed to solving the general P2P problem at this time, and I have no intent to sponsor or support that work within the IETF right now. It's a fine IRTF problem, but it needs a lot more thinking before it becomes an IETF problem. So I'd like to propose reducing the discussed scope to something I think is suitable for an IETF working group. Mission: To apply P2P techniques for correspondent or resource discovery within a P2P federation for the establishment of SIP transactions between nodes of that P2P federation. This is an alternative to the "proxy routed" model of conventional SIP. Assumptions: 1) Session establishment, capabilities negotiation, session termination, subscription, notification, messaging, and related functions traditionally performed using SIP will continue to be performed using SIP. 2) We will develop new protocol mechanisms for the purpose of correspondent (other users) or resource (NAT traveres, VM servers, etc.) discovery and declaration (insertion, publishing, whatever) within the P2P federation. 3) Some elements of each P2P federation MAY be rooted in the DNS such that they can be used for bootstrapping operations. However, a federation that is operating entirely in an isolated (or disconnected, or autonomous, whatever) mode will rely on alternate means of bootstrapping the federation based on the "zeroconf" work. 4) The DNS conditions of #3 will commonly be true when the P2P federation in question is not operating in isolation from the greater Internet. 5) The DNS conditions of #3 will by definition be true when there are communications originating from the greater Internet toward elements of the P2P federation. 6) Elements of the P2P federation will interact as conventional SIP UAs with non-P2P network nodes. 7) The identity of users or nodes will be expressed within a namespace defined at the federation level. It will not be unbounded. 8) The level of authenticity of identity will vary by the federation. However, we 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. Where do I think this sort of solution would be useful? 1) Self-organizing and highly available proxy farms, as opposed to the rigid hierarchical topologies of today's IMS. 2) Disconnected or partly-disconnected topologies such as those found in mesh networks, emergency response, battlefield, and other highly fluid environments. 3) Slightly coooperative communities of users distributed across the Internet (aka Skype-like communities). 4) Enterprise-like communities, both on private networks and on the greater Internet. -- Dean Willis From lists at bulukucing.org Sat Jan 14 07:13:52 2006 From: lists at bulukucing.org (Benny Prijono) Date: Sat, 14 Jan 2006 12:13:52 +0000 Subject: [p2p-sip] Towards Reining In the Scope In-Reply-To: <43C88002.8030102@softarmor.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233EC@0591-its-exmp01.us.saic.com> <43C88002.8030102@softarmor.com> Message-ID: <43C8EB00.3070608@bulukucing.org> Dean Willis wrote: > So far I've heard ideas ranging from replacing DNS with a global search > mechanism to finding a way to make a SIP supergalaxy that includes all > known federations, the GSTN/PSTN, and rogue black holes in its gravitic > clutches. > > I'm not committed to solving the general P2P problem at this time, and I > have no intent to sponsor or support that work within the IETF right > now. It's a fine IRTF problem, but it needs a lot more thinking before > it becomes an IETF problem. > > So I'd like to propose reducing the discussed scope to something I think > is suitable for an IETF working group. > Agreed (completely). It was not my intention to burden IRTF researchers with developing something that is completely in different scope/assumptions that current works. But I felt that goal is not too far/unreachable either. All we need to do, for now, is just to add couple more assumptions below between your item number 7 and 8. 7.5) Federations that are connected to Internet are expected to have a globally unique federation name/id. 7.6) P2P nodes MUST be able to associate P2P communications with the federation where the communication belongs. This MAY imply that the federation id is embedded in each P2P message. That's all! Those assumptions may even be the case now, although perhaps not explicitly stated. What do you or others think? -benny > > 7) The identity of users or nodes will be expressed within a namespace > defined at the federation level. It will not be unbounded. > > 8) The level of authenticity of identity will vary by the federation. > However, we 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. > > From henry at pulver.com Sat Jan 14 18:53:57 2006 From: henry at pulver.com (Henry Sinnreich) Date: Sat, 14 Jan 2006 17:53:57 -0600 Subject: [p2p-sip] Towards Reining In the Scope In-Reply-To: <43C8EB00.3070608@bulukucing.org> Message-ID: <200601142354.k0ENs5Gt019824@cs.columbia.edu> I agree with Dean. Besides, federations are not scalable and smack of cartel behavior, of discrimination. Bigcarrier.com will not federate with my home.net. They will not even answer my calls. Thanks, Henry -----Original Message----- From: Benny Prijono [mailto:lists at bulukucing.org] Sent: Saturday, January 14, 2006 6:14 AM To: Dean Willis Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Towards Reining In the Scope Dean Willis wrote: > So far I've heard ideas ranging from replacing DNS with a global search > mechanism to finding a way to make a SIP supergalaxy that includes all > known federations, the GSTN/PSTN, and rogue black holes in its gravitic > clutches. > > I'm not committed to solving the general P2P problem at this time, and I > have no intent to sponsor or support that work within the IETF right > now. It's a fine IRTF problem, but it needs a lot more thinking before > it becomes an IETF problem. > > So I'd like to propose reducing the discussed scope to something I think > is suitable for an IETF working group. > Agreed (completely). It was not my intention to burden IRTF researchers with developing something that is completely in different scope/assumptions that current works. But I felt that goal is not too far/unreachable either. All we need to do, for now, is just to add couple more assumptions below between your item number 7 and 8. 7.5) Federations that are connected to Internet are expected to have a globally unique federation name/id. 7.6) P2P nodes MUST be able to associate P2P communications with the federation where the communication belongs. This MAY imply that the federation id is embedded in each P2P message. That's all! Those assumptions may even be the case now, although perhaps not explicitly stated. What do you or others think? -benny > > 7) The identity of users or nodes will be expressed within a namespace > defined at the federation level. It will not be unbounded. > > 8) The level of authenticity of identity will vary by the federation. > However, we 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. > > From lists at bulukucing.org Sat Jan 14 20:56:29 2006 From: lists at bulukucing.org (Benny Prijono) Date: Sun, 15 Jan 2006 01:56:29 +0000 Subject: [p2p-sip] Towards Reining In the Scope In-Reply-To: <20060114235406.5D89BE000092@twilight.systems.pipex.net> References: <20060114235406.5D89BE000092@twilight.systems.pipex.net> Message-ID: <43C9ABCD.5060004@bulukucing.org> Henry Sinnreich wrote: > I agree with Dean. > > Besides, federations are not scalable and smack of cartel behavior, of > discrimination. > Erm, I don't understand. I assumed that "p2p federation" in Dean's email is synonymous with "p2p overlay network" (although I just realized that none of the drafts mention the federation term). So in that context, we *are* building federations with p2p sip. When your p2p node joins a p2p "network", you are joining a particular sip p2p federation. What I asked was simply to consider that: 1) there is possibility that we may need to accomodate communications between p2p overlays / federations. 2) there is possibility that there may be overlapping overlays (i.e. nodes that belong to more than one overlays). I believe there is a real use case for that. > Bigcarrier.com will not federate with my home.net. > They will not even answer my calls. > My view is, just because of that, doesn't mean we should throw away the capability in the protocol level. Just because bigcarrier.com will not route my IP packet, doesn't mean we don't need IP routing. -benny > Thanks, Henry > From Richard.Stastny at oefeg.at Sun Jan 15 07:14:34 2006 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Sun, 15 Jan 2006 13:14:34 +0100 Subject: [p2p-sip] Towards Reining In the Scope Message-ID: <32755D354E6B65498C3BD9FD496C7D462C477F@oefeg-s04.oefeg.loc> >I assumed that "p2p federation" in Dean's email is synonymous with >"p2p overlay network" (although I just realized that none of the >drafts mention the federation term). I think "federation" is not synonymous with "p2p network" A federation is a group of "p2p networks" having a predefined peering agreement and policy >So in that context, we *are* building federations with p2p sip. When >your p2p node joins a p2p "network", you are joining a particular sip >p2p federation. No, IMHO you are joining only a "p2p network", the federations exist a-priori. That of course leaves the question open how ad-hoc "p2p networks" may join a "federation". Because of predefined policies and agreements there is nothing like a ad-hoc federation, or? Richard ________________________________ Von: p2p-sip-bounces at cs.columbia.edu im Auftrag von Benny Prijono Gesendet: So 15.01.2006 02:56 An: henry at pulver.com Cc: p2p-sip at cs.columbia.edu Betreff: Re: [p2p-sip] Towards Reining In the Scope Henry Sinnreich wrote: > I agree with Dean. > > Besides, federations are not scalable and smack of cartel behavior, of > discrimination. > Erm, I don't understand. I assumed that "p2p federation" in Dean's email is synonymous with "p2p overlay network" (although I just realized that none of the drafts mention the federation term). So in that context, we *are* building federations with p2p sip. When your p2p node joins a p2p "network", you are joining a particular sip p2p federation. What I asked was simply to consider that: 1) there is possibility that we may need to accomodate communications between p2p overlays / federations. 2) there is possibility that there may be overlapping overlays (i.e. nodes that belong to more than one overlays). I believe there is a real use case for that. > Bigcarrier.com will not federate with my home.net. > They will not even answer my calls. > My view is, just because of that, doesn't mean we should throw away the capability in the protocol level. Just because bigcarrier.com will not route my IP packet, doesn't mean we don't need IP routing. -benny > Thanks, Henry > _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From royrr at us.saic.com Sun Jan 15 12:55:24 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Sun, 15 Jan 2006 12:55:24 -0500 Subject: [p2p-sip] Towards Reining In the Scope Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F6233F5@0591-its-exmp01.us.saic.com> Inline [RRR] _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Stastny Richard Sent: Sun 1/15/2006 7:14 AM To: Benny Prijono; henry at pulver.com Cc: p2p-sip at cs.columbia.edu Subject: Re: [p2p-sip] Towards Reining In the Scope >So in that context, we *are* building federations with p2p sip. When >your p2p node joins a p2p "network", you are joining a particular sip >p2p federation. No, IMHO you are joining only a "p2p network", the federations exist a-priori. [RRR] If this is the case, is it not the case that many of the problems such as security, QoS, service profiles, and others that have been described other members including Kundan can be addressed more easily in p2p federated networks? Richard From dean.willis at softarmor.com Mon Jan 16 17:04:14 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 16 Jan 2006 16:04:14 -0600 Subject: [p2p-sip] Towards Reining In the Scope In-Reply-To: <43C8EB00.3070608@bulukucing.org> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233EC@0591-its-exmp01.us.saic.com> <43C88002.8030102@softarmor.com> <43C8EB00.3070608@bulukucing.org> Message-ID: <35D2AC0D-A870-47D0-B0C2-10312856B91B@softarmor.com> On Jan 14, 2006, at 6:13 AM, Benny Prijono wrote: > 7.5) Federations that are connected to Internet are expected to > have a globally unique federation name/id. > This may be overspecified. What says there can't be multiple names for the federation? As long as it preserves a consistent namespace, I think we're ok. > 7.6) P2P nodes MUST be able to associate P2P communications with > the federation where the communication belongs. This MAY imply that > the federation id is embedded in each P2P message. Given that user identity is dependent on "federation identity" (assumption 7), I think this property is already preserved by the identity assertion of assumption 8. > >> 7) The identity of users or nodes will be expressed within a >> namespace defined at the federation level. It will not be unbounded. >> 8) The level of authenticity of identity will vary by the >> federation. However, we 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. > -- Dean From lists at bulukucing.org Mon Jan 16 19:15:43 2006 From: lists at bulukucing.org (Benny Prijono) Date: Tue, 17 Jan 2006 00:15:43 +0000 Subject: [p2p-sip] Towards Reining In the Scope In-Reply-To: <35D2AC0D-A870-47D0-B0C2-10312856B91B@softarmor.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F6233EC@0591-its-exmp01.us.saic.com> <43C88002.8030102@softarmor.com> <43C8EB00.3070608@bulukucing.org> <35D2AC0D-A870-47D0-B0C2-10312856B91B@softarmor.com> Message-ID: <43CC372F.2000401@bulukucing.org> Dean Willis wrote: > > On Jan 14, 2006, at 6:13 AM, Benny Prijono wrote: > >> 7.5) Federations that are connected to Internet are expected to have >> a globally unique federation name/id. >> > > This may be overspecified. What says there can't be multiple names for > the federation? As long as it preserves a consistent namespace, I think > we're ok. > Right, okay. I guess I was wrong (mainly because I thought a federation is synonymous with a p2p overlay). What I wanted say is there should be some kind of identification of which overlay a user belongs, so that it is possible to make communications between overlays. But with federation, it is clear that communications between overlays are possible, so I guess this requirement is already implied in the assumptions. It all make sense now. -benny From bryan at ethernot.org Tue Jan 17 00:30:19 2006 From: bryan at ethernot.org (David A. Bryan) Date: Tue, 17 Jan 2006 00:30:19 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> A number of us (myself, Dean Willis, Eunsoo Shim, Henry Sinnreich, Cullen Jennings, Philip Matthews, Henning Schulzrinne, and others I am sure I have forgotten) have been bouncing around a few ideas for a proposed draft charter for a WG to address some of the problems we have been discussing on the mailing list. We pulled things into a document and wanted to post it to the mailing list to get feedback. Please take a look and comment. (inline and attached) --David Bryan ----- Note: This working group is likely to be moved to the RAI, rather than Transport as soon as such a group exists. We'll list Transport for now as place holder text Peer-to-Peer Session Initiation Protocol (P2PSIP) DRAFT 2006/01/16 Chairs: TBD Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD 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 of using a hierarchy of proxies where the mapping of users to proxies is determined by a combination of out-of-band and geographic mechanisms. 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 3262: "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. 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 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 SIP-based communications. 2. Discussion of this technology as a replacement for 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) -------------- next part -------------- Note: This working group is likely to be moved to the RAI, rather than Transport as soon as such a group exists. We'll list Transport for now as place holder text Peer-to-Peer Session Initiation Protocol (P2PSIP) DRAFT 2006/01/16 Chairs: TBD Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD 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 of using a hierarchy of proxies where the mapping of users to proxies is determined by a combination of out-of-band and geographic mechanisms. 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 3262: "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. 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 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 SIP-based communications. 2. Discussion of this technology as a replacement for 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 kns10 at cs.columbia.edu Tue Jan 17 08:41:08 2006 From: kns10 at cs.columbia.edu (Kundan Singh) Date: Tue, 17 Jan 2006 08:41:08 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> Message-ID: <43CCF3F4.4000409@cs.columbia.edu> Minor suggestions/corrections below -- > 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 3262: > "Locating SIP Servers". RFC 3262 => RFC 3263 > 3. The solutions proposed will function even with many nodes located > behind NATs or firewalls. Should this be "some nodes" instead of "many nodes"? Just so that we don't have to guarantee that it works efficiently if 99% nodes are behind NATs. > 4. Performing distributed search for users based on something other > than user id. user id => SIP address-of-record, or namespace plus user id. (unless userid is assumed as user at domain or namespace+userid) > 2. Discussion of this technology as a replacement for SIP. SIP => conventional SIP (or client-server)? From philip_matthews at magma.ca Tue Jan 17 09:33:16 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 17 Jan 2006 09:33:16 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43CCF3F4.4000409@cs.columbia.edu> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> <43CCF3F4.4000409@cs.columbia.edu> Message-ID: <708FF44A-E2A7-4D63-BB1C-AEF00F6F58C2@magma.ca> On 17-Jan-06, at 8:41 , Kundan Singh wrote: [snip] > >> 3. The solutions proposed will function even with many nodes located >> behind NATs or firewalls. > > Should this be "some nodes" instead of "many nodes"? Just so that we > don't have to guarantee that it works efficiently if 99% nodes are > behind NATs. I personally think it is important that whatever solution we come up with work effectively if ALL the peers are located behind NATs. In very large networks, especially networks composed of home and academic nodes, it may be reasonable to assume that there will be peers that are not behind a NAT. However, in smaller networks and/or in enterprise settings, I believe that assumption is not reasonable. On the contrary, I believe it will be normal for EVERY peer to be located behind a NAT. - Philip From enrico.marocco at TILAB.COM Tue Jan 17 10:05:22 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Tue, 17 Jan 2006 16:05:22 +0100 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> Message-ID: <43CD07B2.1090206@tilab.com> I like it very much, but it doesn't clarify one issue: how will the group deal with presence? I can imagine that we don't intend to specify a distributed presence server, but what about regev? Does it fall under out of scope stuff? Actually, the topic is treated in a couple of drafts, but it's never been deepened. Enrico David A. Bryan wrote: > A number of us (myself, Dean Willis, Eunsoo Shim, Henry Sinnreich, > Cullen Jennings, Philip Matthews, Henning Schulzrinne, and others I am > sure I have forgotten) have been bouncing around a few ideas for a > proposed draft charter for a WG to address some of the problems we > have been discussing on the mailing list. We pulled things into a > document and wanted to post it to the mailing list to get feedback. > Please take a look and comment. (inline and attached) > > --David Bryan Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From dbarrett at quinthar.com Wed Jan 18 13:37:47 2006 From: dbarrett at quinthar.com (David Barrett) Date: Wed, 18 Jan 2006 13:37:47 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <708FF44A-E2A7-4D63-BB1C-AEF00F6F58C2@magma.ca> Message-ID: <200601181838.k0IIc0KF009291@cs.columbia.edu> > -----Original Message----- > From: Philip Matthews > Sent: Tuesday, January 17, 2006 9:33 AM > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > However, in smaller networks and/or in enterprise settings, I believe > that > assumption is not reasonable. On the contrary, I believe it will be > normal > for EVERY peer to be located behind a NAT. In an enterprise setting it's likely all nodes will be behind the *same* NAT, but unlikely they'll be behind different NATs. Indeed, I think it unlikely there will *ever* be a deployment where each and every node is behind its own unique NAT. Regardless, so long as there is *some* connectivity path between all nodes (ie, A->B->C->D) I guess it'd be possible to forward NAT traversal requests just like INVITE requests are forward in SIP (and another reason why to build the NAT traversal algorithm into the SIP protocol itself). And if two nodes have *no* connectivity path, you could use a Roti-like port-scanning technique (which requires no rendezvous service). But all this sounds like a pretty extreme boundary case. While there are certainly people working on isolated networks, I really doubt they'll be using NATs too. I'd offer P2P-SIP should work: 1) On the internet where some global bootstrapping service is available, and some or all non-bootstrapping nodes are behind NATs. 2) Off the internet where UDP broadcasts work, no nodes are behind NATs, and no bootstrapping service is available. -david From philip_matthews at magma.ca Wed Jan 18 14:40:09 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Jan 2006 14:40:09 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <200601181838.k0IIc0Sc015722@in2.magma.ca> References: <200601181838.k0IIc0Sc015722@in2.magma.ca> Message-ID: <784AC829-0BC8-4771-A120-739DCF24BFAA@magma.ca> David: I fully agree with your first scenario: > 1) On the internet where some global bootstrapping service is > available, and > some or all non-bootstrapping nodes are behind NATs. Regarding your second scenario: > 2) Off the internet where UDP broadcasts work, no nodes are behind > NATs, and > no bootstrapping service is available. I would suggest that this be replaced by the statement that a bootstrapping service (Rendezvous Server) will not the only way for a new node to locate a peer on the network. Other methods, like multicast, buddy lists, and even manual configuration should also be tried. A few other minor comments below. On 18-Jan-06, at 13:37 , David Barrett wrote: >> -----Original Message----- >> From: Philip Matthews >> Sent: Tuesday, January 17, 2006 9:33 AM >> Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG >> >> However, in smaller networks and/or in enterprise settings, I believe >> that >> assumption is not reasonable. On the contrary, I believe it will be >> normal >> for EVERY peer to be located behind a NAT. > > In an enterprise setting it's likely all nodes will be behind the > *same* > NAT, but unlikely they'll be behind different NATs. I disagree. What about a small company with offices in different cities and no corporate VPN? Or a small company with teleworkers? > > Indeed, I think it unlikely there will *ever* be a deployment where > each and > every node is behind its own unique NAT. Again, I disagree. What about a group of friends with phones at their homes who want their own private P2P network? Or a small company where everyone works from a home office? But these are minor points and I think we agree that a network where all the phones are all located behind NATs (with some of the phones are behind one NAT and other phone are behind other NATs) is quite possible. - Philip From dean.willis at softarmor.com Wed Jan 18 14:48:04 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 18 Jan 2006 13:48:04 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43CCF3F4.4000409@cs.columbia.edu> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> <43CCF3F4.4000409@cs.columbia.edu> Message-ID: <8B96E8BA-10CA-436B-B9B0-A9CA6BF01AFA@softarmor.com> On Jan 17, 2006, at 7:41 AM, Kundan Singh wrote: > Minor suggestions/corrections below -- > >> 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 3262: >> "Locating SIP Servers". > > RFC 3262 => RFC 3263 > Good catch. I typoed. >> 3. The solutions proposed will function even with many nodes located >> behind NATs or firewalls. > > Should this be "some nodes" instead of "many nodes"? Just so that we > don't have to guarantee that it works efficiently if 99% nodes are > behind NATs. > Makes no difference to me. >> 4. Performing distributed search for users based on something other >> than user id. > > user id => SIP address-of-record, or namespace plus user id. > (unless userid is assumed as user at domain or namespace+userid) > >> 2. Discussion of this technology as a replacement for SIP. > > SIP => conventional SIP (or client-server)? > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From dean.willis at softarmor.com Wed Jan 18 14:59:31 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 18 Jan 2006 13:59:31 -0600 Subject: [p2p-sip] Draft: BOF request for p2p-sip Message-ID: <9B582A38-DAD6-40AA-ADA6-E6514EC9C975@softarmor.com> BOF Name: Peer to Peer support for Session Initiation Protocol [P2P-SIP] Transport Area (Allison Mankin, sponsoring AD) BOF Chairs: Dean Willis , David Bryan Agenda: ----------- Agenda Bash, 5 minutes Discussion of Draft Charter and Scope, 30 minutes Discussion of Potential Working Group Organization (volunteering of chairs, secretary) 25 Minutes Discussion of Use Cases Document (draft-bryan-sipping-p2p-usecases) 30 Minutes Discussion of Requirements (draft-baset-sipping-p2preq) 30 minutes Supporting documents: draft-johnston-sipping-p2p-ipcom draft-bryan-sipping-p2p Standard "Question 4" Answers for Scheduling: --------------------------------------------------------------- a. Working Group or BOF full name with acronym in brackets: Peer to Peer Support for Session Initiation Protocol [P2P-SIP] b. AREA under which Working Group or BOF appears: Transport c. CONFLICTS you wish to avoid, please be as specific as possible: SIP, SIPPING, SIMPLE, BEHAVE, ECRIT, TSVWG, TSVAREA, AVT, d. Expected Attendance 200 e. Special requests None f. Number of sessions: We'd like one session during the regular IETF and would like to organize an additional gathering on Friday afternoon following the regular IETF session. g. Length of sessions: The "regular session" should be at least 2 hours if possible but we can make do with a 1 hour regular session assuming we have the extended "after meeting" session. Working Group Description ------------------------------------- The Draft Charter (see following text) contains a detailed description of the proposed working group as well as references to the mailing list and its archive. The constituency met in an ad-hoc fashion under the auspices of the SIPPING working group at IETF 62, 63 64. Minutes of those discussions are posted at: http://www.softarmor.com/sipping/meets/ietf62/notes/notes-dwillis- p2padhoc-sipping-62.html http://www.softarmor.com/sipping/meets/ietf63/notes/p2p-ad-hoc- sipping-ietf63.txt http://www.softarmor.com/sipping/meets/ietf64/notes/minutes-p2p- sipping-ietf64.txt Historically, the level of interest in this work gas been very high, with more than 50 people attending the ad-hoc sessions despite their unusual scheduling. There are existing drafts for use cases, requirements, and two different solution approaches in the IETF repository at the time of this request. Some of these documents have been revised several times and are beginning to mature. The most significant challenge the constituency has faced is narrowing its focus to a scope that is manageable in an IETF working group. We believe the following draft charter addresses that focus and has strong consensus in the community. Draft Charter ------------------ Peer-to-Peer Session Initiation Protocol (P2PSIP) Chairs: TBD Transport Area Director(s): Allison Mankin Jon Peterson Transport Area Advisor: TBD 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 of using a hierarchy of proxies where the mapping of users to proxies is determined by a combination of out-of-band and geographic mechanisms. 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. 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 SIP-based communications. 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 philip_matthews at magma.ca Wed Jan 18 16:23:48 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Wed, 18 Jan 2006 16:23:48 -0500 Subject: [p2p-sip] Draft: BOF request for p2p-sip In-Reply-To: <9B582A38-DAD6-40AA-ADA6-E6514EC9C975@softarmor.com> References: <9B582A38-DAD6-40AA-ADA6-E6514EC9C975@softarmor.com> Message-ID: <8EA4E295-EA0A-4132-9E80-ACEE75DB1EED@magma.ca> Dean: You didn't say how long we wanted the additional session on Friday afternoon to be. Perhaps request a 4-hour session (1 - 5pm) like we had in Vancouver? If more internet-drafts are better, then I can easily re-submit my now-expired draft from the spring. Should we also avoid a conflict with the p2prg (if it will meet again in Dallas)? - Philip On 18-Jan-06, at 14:59 , Dean Willis wrote: > > BOF Name: Peer to Peer support for Session Initiation Protocol [P2P- > SIP] > Transport Area (Allison Mankin, sponsoring AD) > BOF Chairs: Dean Willis , David Bryan > > > Agenda: > ----------- > > Agenda Bash, 5 minutes > Discussion of Draft Charter and Scope, 30 minutes > Discussion of Potential Working Group Organization (volunteering of > chairs, secretary) 25 Minutes > Discussion of Use Cases Document (draft-bryan-sipping-p2p-usecases) > 30 Minutes > Discussion of Requirements (draft-baset-sipping-p2preq) 30 minutes > > Supporting documents: > draft-johnston-sipping-p2p-ipcom > draft-bryan-sipping-p2p > > > Standard "Question 4" Answers for Scheduling: > --------------------------------------------------------------- > > a. Working Group or BOF full name with acronym in brackets: > > Peer to Peer Support for Session Initiation Protocol [P2P-SIP] > > b. AREA under which Working Group or BOF appears: > > Transport > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > SIP, SIPPING, SIMPLE, BEHAVE, ECRIT, TSVWG, TSVAREA, AVT, > > > d. Expected Attendance > > 200 > > e. Special requests > > None > > f. Number of sessions: > > We'd like one session during the regular IETF and would like to > organize an additional gathering on Friday afternoon following the > regular IETF session. > > g. Length of sessions: > > The "regular session" should be at least 2 hours if possible but we > can make do with a 1 hour regular session assuming we have the > extended "after meeting" session. > > > > Working Group Description > ------------------------------------- > > The Draft Charter (see following text) contains a detailed > description of the proposed working group as well as references to > the mailing list and its archive. The constituency met in an ad-hoc > fashion under the auspices of the SIPPING working group at IETF 62, > 63 64. Minutes of those discussions are posted at: > > http://www.softarmor.com/sipping/meets/ietf62/notes/notes-dwillis- > p2padhoc-sipping-62.html > http://www.softarmor.com/sipping/meets/ietf63/notes/p2p-ad-hoc- > sipping-ietf63.txt > http://www.softarmor.com/sipping/meets/ietf64/notes/minutes-p2p- > sipping-ietf64.txt > > Historically, the level of interest in this work gas been very high, > with more than 50 people attending the ad-hoc sessions despite their > unusual scheduling. There are existing drafts for use cases, > requirements, and two different solution approaches in the IETF > repository at the time of this request. Some of these documents have > been revised several times and are beginning to mature. > > The most significant challenge the constituency has faced is > narrowing its focus to a scope that is manageable in an IETF working > group. We believe the following draft charter addresses that focus > and has strong consensus in the community. > > > Draft Charter > ------------------ > > > Peer-to-Peer Session Initiation Protocol (P2PSIP) > > Chairs: > TBD > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: > TBD > > 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 of > using a hierarchy of proxies where the mapping of users to proxies is > determined by a combination of out-of-band and geographic mechanisms. > > 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. > > 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 SIP-based communications. > > 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 buford at research.panasonic.com Wed Jan 18 16:29:27 2006 From: buford at research.panasonic.com (John Buford) Date: Wed, 18 Jan 2006 16:29:27 -0500 Subject: [p2p-sip] Draft: BOF request for p2p-sip In-Reply-To: <8EA4E295-EA0A-4132-9E80-ACEE75DB1EED@magma.ca> Message-ID: Regarding p2prg, a meeting is being planned for Dallas, though time has not been set yet. So avoiding the conflict would be great. John ---------------------------------- Dean: You didn't say how long we wanted the additional session on Friday afternoon to be. Perhaps request a 4-hour session (1 - 5pm) like we had in Vancouver? If more internet-drafts are better, then I can easily re-submit my now-expired draft from the spring. Should we also avoid a conflict with the p2prg (if it will meet again in Dallas)? - Philip On 18-Jan-06, at 14:59 , Dean Willis wrote: > > BOF Name: Peer to Peer support for Session Initiation Protocol [P2P- > SIP] > Transport Area (Allison Mankin, sponsoring AD) > BOF Chairs: Dean Willis , David Bryan > > > Agenda: > ----------- > > Agenda Bash, 5 minutes > Discussion of Draft Charter and Scope, 30 minutes > Discussion of Potential Working Group Organization (volunteering of > chairs, secretary) 25 Minutes > Discussion of Use Cases Document (draft-bryan-sipping-p2p-usecases) > 30 Minutes > Discussion of Requirements (draft-baset-sipping-p2preq) 30 minutes > > Supporting documents: > draft-johnston-sipping-p2p-ipcom > draft-bryan-sipping-p2p > > > Standard "Question 4" Answers for Scheduling: > --------------------------------------------------------------- > > a. Working Group or BOF full name with acronym in brackets: > > Peer to Peer Support for Session Initiation Protocol [P2P-SIP] > > b. AREA under which Working Group or BOF appears: > > Transport > > c. CONFLICTS you wish to avoid, please be as specific as possible: > > SIP, SIPPING, SIMPLE, BEHAVE, ECRIT, TSVWG, TSVAREA, AVT, > > > d. Expected Attendance > > 200 > > e. Special requests > > None > > f. Number of sessions: > > We'd like one session during the regular IETF and would like to > organize an additional gathering on Friday afternoon following the > regular IETF session. > > g. Length of sessions: > > The "regular session" should be at least 2 hours if possible but we > can make do with a 1 hour regular session assuming we have the > extended "after meeting" session. > > > > Working Group Description > ------------------------------------- > > The Draft Charter (see following text) contains a detailed > description of the proposed working group as well as references to > the mailing list and its archive. The constituency met in an ad-hoc > fashion under the auspices of the SIPPING working group at IETF 62, > 63 64. Minutes of those discussions are posted at: > > http://www.softarmor.com/sipping/meets/ietf62/notes/notes-dwillis- > p2padhoc-sipping-62.html > http://www.softarmor.com/sipping/meets/ietf63/notes/p2p-ad-hoc- > sipping-ietf63.txt > http://www.softarmor.com/sipping/meets/ietf64/notes/minutes-p2p- > sipping-ietf64.txt > > Historically, the level of interest in this work gas been very high, > with more than 50 people attending the ad-hoc sessions despite their > unusual scheduling. There are existing drafts for use cases, > requirements, and two different solution approaches in the IETF > repository at the time of this request. Some of these documents have > been revised several times and are beginning to mature. > > The most significant challenge the constituency has faced is > narrowing its focus to a scope that is manageable in an IETF working > group. We believe the following draft charter addresses that focus > and has strong consensus in the community. > > > Draft Charter > ------------------ > > > Peer-to-Peer Session Initiation Protocol (P2PSIP) > > Chairs: > TBD > > Transport Area Director(s): > Allison Mankin > Jon Peterson > > Transport Area Advisor: > TBD > > 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 of > using a hierarchy of proxies where the mapping of users to proxies is > determined by a combination of out-of-band and geographic mechanisms. > > 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. > > 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 SIP-based communications. > > 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 _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From dbarrett at quinthar.com Fri Jan 20 02:45:00 2006 From: dbarrett at quinthar.com (David Barrett) Date: Thu, 19 Jan 2006 23:45:00 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <784AC829-0BC8-4771-A120-739DCF24BFAA@magma.ca> Message-ID: <200601200748.k0K7j0KF019339@cs.columbia.edu> > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews at magma.ca] > > Indeed, I think it unlikely there will *ever* be a deployment where > > each and > > every node is behind its own unique NAT. > > Again, I disagree. What about a group of friends with phones at their > homes > who want their own private P2P network? > Or a small company where everyone works from a home office? Ok, good point. I was thinking of global internet-based networks, or tiny non-internet networks. I hadn't considered very tiny internet-based networks like this. -david From dean.willis at softarmor.com Fri Jan 20 13:27:44 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Fri, 20 Jan 2006 12:27:44 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <200601200748.k0K7j0KF019339@cs.columbia.edu> References: <200601200748.k0K7j0KF019339@cs.columbia.edu> Message-ID: <256DB979-21C5-4F18-88C9-DDD7B5CE16E1@softarmor.com> On Jan 20, 2006, at 1:45 AM, David Barrett wrote: >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews at magma.ca] >>> Indeed, I think it unlikely there will *ever* be a deployment where >>> each and >>> every node is behind its own unique NAT. >> >> Again, I disagree. What about a group of friends with phones at their >> homes >> who want their own private P2P network? >> Or a small company where everyone works from a home office? > > Ok, good point. I was thinking of global internet-based networks, > or tiny > non-internet networks. I hadn't considered very tiny internet-based > networks like this. Of course, there may be nothing we can actually DO for people who are all behind separate non-cooperative NATs that doesn't require having at least one node somewhere actually publicly visible somehow. This is kind of like the question "If tress fall in several different woods scattered around the planet and nobody is there to hear them, does this make the sounds of the percussion section of an orchestra?" -- Dean From philip_matthews at magma.ca Fri Jan 20 14:51:54 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 20 Jan 2006 14:51:54 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <256DB979-21C5-4F18-88C9-DDD7B5CE16E1@softarmor.com> References: <200601200748.k0K7j0KF019339@cs.columbia.edu> <256DB979-21C5-4F18-88C9-DDD7B5CE16E1@softarmor.com> Message-ID: On 20-Jan-06, at 13:27 , Dean Willis wrote: > > On Jan 20, 2006, at 1:45 AM, David Barrett wrote: > >>> -----Original Message----- >>> From: Philip Matthews [mailto:philip_matthews at magma.ca] >>>> Indeed, I think it unlikely there will *ever* be a deployment where >>>> each and >>>> every node is behind its own unique NAT. >>> >>> Again, I disagree. What about a group of friends with phones at >>> their >>> homes >>> who want their own private P2P network? >>> Or a small company where everyone works from a home office? >> >> Ok, good point. I was thinking of global internet-based networks, >> or tiny >> non-internet networks. I hadn't considered very tiny internet-based >> networks like this. > > Of course, there may be nothing we can actually DO for people who > are all behind separate non-cooperative NATs that doesn't require > having at least one node somewhere actually publicly visible somehow. > > This is kind of like the question "If tress fall in several > different woods scattered around the planet and nobody is there to > hear them, does this make the sounds of the percussion section of > an orchestra?" > > -- > Dean If: 1) The peers are behind NATs with the "Endpoint Independent mapping" behavior (to use the terminology of the BEHAVE UDP draft); AND 2) There is a Rendezvous server with a public IP address (either static or with a DNS entry) which can remember the mapped address and port of ONE peer in the P2P network that the new node X wishes to join then it is possible to solve the problem. Briefly, things work as follows. Here we assume there is just one Rendezvous Server that supports all the P2P-SIP networks, but this could be easily generalized to allow different servers for different networks. 1) A P2P-SIP network elects one peer P to maintain a connection to the Rendezvous server. The server remembers (a) the name of the network (b) a password (if access to the network is restricted) and (c) both the private and the mapped address and port of P. Peer P refreshes its info with the server frequently to keep the pinhole in its NAT open. 2) A node X which wishes to join the network contacts the server. Node X provides (a) the name of the network it wishes to join, and (b) the password (if required). 3) The server responds with both the private and mapped address and port of P. 4) At the same time, the server sends a message to P telling it the private and mapped address and port of X. 5) Node X and peer P now try to establish a connection (either TCP or UDP) using a method vaguely similar to that used in ICE (i.e., try all possible address combinations). Provided that both are behind NATs with the "Endpoint Independent mapping" behavior and assuming the NAT topology isn't too crazy (and/or the NATs in question support hairpinning) then things should work. At this point, node X can talk to peer P, and can use P to establish connections with other peers. There are situations where a Rendezvous server is not required, and techniques like multicast, buddy lists, or manual configuration work. However, a Rendezvous server is the most general solution. What I see us (the P2P-SIP group) doing is specifying the protocol used between the Rendezvous Server, peer P, and node X. Then some P2P-SIP networks may decide to use one server, and other networks may decide to use another server. Node X will then have to know (a) which server to contact, (b) the name of the P2P-SIP network it wishes to join, and (c) the password (if any) to join. - Philip From srisuresh at yahoo.com Fri Jan 20 16:24:59 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Fri, 20 Jan 2006 13:24:59 -0800 (PST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: Message-ID: <20060120212459.32970.qmail@web33301.mail.mud.yahoo.com> Philip is right. If all NATs are BEHAVE compliant, P2P conenctivity could be established directly even with the end nodes behind NAT devices. However, if a NAT is not behave compliant, the end nodes behind that NAT could still get P2P connectivity through a relay service from the super node. Clearly, intervention of a super node in the data path is not desirable from perfromance perspecective. cheers, suresh --- Philip Matthews wrote: > > On 20-Jan-06, at 13:27 , Dean Willis wrote: > > > > > On Jan 20, 2006, at 1:45 AM, David Barrett wrote: > > > >>> -----Original Message----- > >>> From: Philip Matthews [mailto:philip_matthews at magma.ca] > >>>> Indeed, I think it unlikely there will *ever* be a deployment where > >>>> each and > >>>> every node is behind its own unique NAT. > >>> > >>> Again, I disagree. What about a group of friends with phones at > >>> their > >>> homes > >>> who want their own private P2P network? > >>> Or a small company where everyone works from a home office? > >> > >> Ok, good point. I was thinking of global internet-based networks, > >> or tiny > >> non-internet networks. I hadn't considered very tiny internet-based > >> networks like this. > > > > Of course, there may be nothing we can actually DO for people who > > are all behind separate non-cooperative NATs that doesn't require > > having at least one node somewhere actually publicly visible somehow. > > > > This is kind of like the question "If tress fall in several > > different woods scattered around the planet and nobody is there to > > hear them, does this make the sounds of the percussion section of > > an orchestra?" > > > > -- > > Dean > > > If: > 1) The peers are behind NATs with the "Endpoint Independent mapping" > behavior > (to use the terminology of the BEHAVE UDP draft); AND > 2) There is a Rendezvous server with a public IP address (either > static or with a DNS entry) > which can remember the mapped address and port of ONE peer in > the P2P network > that the new node X wishes to join > then it is possible to solve the problem. > > Briefly, things work as follows. > Here we assume there is just one Rendezvous Server that supports all > the P2P-SIP networks, > but this could be easily generalized to allow different servers for > different networks. > 1) A P2P-SIP network elects one peer P to maintain a connection to > the Rendezvous server. > The server remembers (a) the name of the network (b) a password > (if access to the network is restricted) > and (c) both the private and the mapped address and port of P. > Peer P refreshes its info with the server frequently to keep > the pinhole in its NAT open. > 2) A node X which wishes to join the network contacts the server. > Node X provides (a) the name of the network > it wishes to join, and (b) the password (if required). > 3) The server responds with both the private and mapped address and > port of P. > 4) At the same time, the server sends a message to P telling it the > private and mapped address and port of X. > 5) Node X and peer P now try to establish a connection (either TCP or > UDP) using a method vaguely > similar to that used in ICE (i.e., try all possible address > combinations). > Provided that both are behind NATs with the "Endpoint > Independent mapping" behavior > and assuming the NAT topology isn't too crazy (and/or the NATs > in question support hairpinning) > then things should work. > > At this point, node X can talk to peer P, and can use P to establish > connections with other peers. > > There are situations where a Rendezvous server is not required, and > techniques like multicast, > buddy lists, or manual configuration work. However, a Rendezvous > server is the most general solution. > > What I see us (the P2P-SIP group) doing is specifying the protocol > used between the Rendezvous Server, > peer P, and node X. Then some P2P-SIP networks may decide to use one > server, and other networks > may decide to use another server. Node X will then have to know (a) > which server to contact, (b) the name > of the P2P-SIP network it wishes to join, and (c) the password (if > any) to join. > > - Philip > > > _______________________________________________ > 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 Fri Jan 20 17:54:26 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 20 Jan 2006 17:54:26 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <20060120212459.32970.qmail@web33301.mail.mud.yahoo.com> References: <20060120212459.32970.qmail@web33301.mail.mud.yahoo.com> Message-ID: In fact, Suresh and a couple of others wrote a nice paper that describes this technique in detail with an analysis of when it does and does not work. "Peer-to-Peer Communication Across Network Address Translators" http://www.brynosaurus.com/pub/net/p2pnat/ - Philip On 20-Jan-06, at 16:24 , Pyda Srisuresh wrote: > Philip is right. If all NATs are BEHAVE compliant, P2P conenctivity > could be > established directly even with the end nodes behind NAT devices. > However, if a > NAT is not behave compliant, the end nodes behind that NAT could > still get P2P > connectivity through a relay service from the super node. Clearly, > intervention > of a super node in the data path is not desirable from perfromance > perspecective. > > cheers, > suresh > > > --- Philip Matthews wrote: > >> >> On 20-Jan-06, at 13:27 , Dean Willis wrote: >> >>> >>> On Jan 20, 2006, at 1:45 AM, David Barrett wrote: >>> >>>>> -----Original Message----- >>>>> From: Philip Matthews [mailto:philip_matthews at magma.ca] >>>>>> Indeed, I think it unlikely there will *ever* be a deployment >>>>>> where >>>>>> each and >>>>>> every node is behind its own unique NAT. >>>>> >>>>> Again, I disagree. What about a group of friends with phones at >>>>> their >>>>> homes >>>>> who want their own private P2P network? >>>>> Or a small company where everyone works from a home office? >>>> >>>> Ok, good point. I was thinking of global internet-based networks, >>>> or tiny >>>> non-internet networks. I hadn't considered very tiny internet- >>>> based >>>> networks like this. >>> >>> Of course, there may be nothing we can actually DO for people who >>> are all behind separate non-cooperative NATs that doesn't require >>> having at least one node somewhere actually publicly visible >>> somehow. >>> >>> This is kind of like the question "If tress fall in several >>> different woods scattered around the planet and nobody is there to >>> hear them, does this make the sounds of the percussion section of >>> an orchestra?" >>> >>> -- >>> Dean >> >> >> If: >> 1) The peers are behind NATs with the "Endpoint Independent mapping" >> behavior >> (to use the terminology of the BEHAVE UDP draft); AND >> 2) There is a Rendezvous server with a public IP address (either >> static or with a DNS entry) >> which can remember the mapped address and port of ONE peer in >> the P2P network >> that the new node X wishes to join >> then it is possible to solve the problem. >> >> Briefly, things work as follows. >> Here we assume there is just one Rendezvous Server that supports all >> the P2P-SIP networks, >> but this could be easily generalized to allow different servers for >> different networks. >> 1) A P2P-SIP network elects one peer P to maintain a connection to >> the Rendezvous server. >> The server remembers (a) the name of the network (b) a password >> (if access to the network is restricted) >> and (c) both the private and the mapped address and port of P. >> Peer P refreshes its info with the server frequently to keep >> the pinhole in its NAT open. >> 2) A node X which wishes to join the network contacts the server. >> Node X provides (a) the name of the network >> it wishes to join, and (b) the password (if required). >> 3) The server responds with both the private and mapped address and >> port of P. >> 4) At the same time, the server sends a message to P telling it the >> private and mapped address and port of X. >> 5) Node X and peer P now try to establish a connection (either TCP or >> UDP) using a method vaguely >> similar to that used in ICE (i.e., try all possible address >> combinations). >> Provided that both are behind NATs with the "Endpoint >> Independent mapping" behavior >> and assuming the NAT topology isn't too crazy (and/or the NATs >> in question support hairpinning) >> then things should work. >> >> At this point, node X can talk to peer P, and can use P to establish >> connections with other peers. >> >> There are situations where a Rendezvous server is not required, and >> techniques like multicast, >> buddy lists, or manual configuration work. However, a Rendezvous >> server is the most general solution. >> >> What I see us (the P2P-SIP group) doing is specifying the protocol >> used between the Rendezvous Server, >> peer P, and node X. Then some P2P-SIP networks may decide to use one >> server, and other networks >> may decide to use another server. Node X will then have to know (a) >> which server to contact, (b) the name >> of the P2P-SIP network it wishes to join, and (c) the password (if >> any) to join. >> >> - Philip >> >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> > > > From dbarrett at quinthar.com Fri Jan 20 18:50:55 2006 From: dbarrett at quinthar.com (David Barrett) Date: Fri, 20 Jan 2006 15:50:55 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: Message-ID: <200601202351.k0KNoxKF009296@cs.columbia.edu> > -----Original Message----- > From: Philip Matthews > > What I see us (the P2P-SIP group) doing is specifying the protocol > used between the Rendezvous Server, > peer P, and node X. Then some P2P-SIP networks may decide to use one > server, and other networks > may decide to use another server. Node X will then have to know (a) > which server to contact, (b) the name > of the P2P-SIP network it wishes to join, and (c) the password (if > any) to join. I think I agree with this, but I'm unclear what you are specifically proposing. Are you suggesting the P2P-SIP group: a) Adjust SIP to implicitly solve the NAT penetration issues, thereby making every SIP proxy naturally serve as a "rendezvous server", ultimately doing away with STUN, TURN, and ICE entirely? - (Incidentally, I think this is the right course.) b) Create a new protocol that replaces STUN, TURN, and ICE, then implement this new protocol in a new "rendezvous server" that is separate from the SIP proxy, and then find a way to bridge SIP and this new server? c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new protocol that somehow simplifies the NAT penetration issue? Which of these is the closest? -david From srisuresh at yahoo.com Fri Jan 20 19:55:28 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Fri, 20 Jan 2006 16:55:28 -0800 (PST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <200601202351.k0KNoxKF009296@cs.columbia.edu> Message-ID: <20060121005528.19744.qmail@web33312.mail.mud.yahoo.com> I am in favor of option b). Create a new protocol that ultimately replaces STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol. The "rendezvous server" or "super node" that runs the protocol need not be a SIP proxy. cheers, suresh --- David Barrett wrote: > > -----Original Message----- > > From: Philip Matthews > > > > What I see us (the P2P-SIP group) doing is specifying the protocol > > used between the Rendezvous Server, > > peer P, and node X. Then some P2P-SIP networks may decide to use one > > server, and other networks > > may decide to use another server. Node X will then have to know (a) > > which server to contact, (b) the name > > of the P2P-SIP network it wishes to join, and (c) the password (if > > any) to join. > > I think I agree with this, but I'm unclear what you are specifically > proposing. Are you suggesting the P2P-SIP group: > > a) Adjust SIP to implicitly solve the NAT penetration issues, thereby making > every SIP proxy naturally serve as a "rendezvous server", ultimately doing > away with STUN, TURN, and ICE entirely? > - (Incidentally, I think this is the right course.) > > b) Create a new protocol that replaces STUN, TURN, and ICE, then implement > this new protocol in a new "rendezvous server" that is separate from the SIP > proxy, and then find a way to bridge SIP and this new server? > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > protocol that somehow simplifies the NAT penetration issue? > > Which of these is the closest? > > -david > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From hgs at cs.columbia.edu Fri Jan 20 20:25:26 2006 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Fri, 20 Jan 2006 20:25:26 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: References: <20060120212459.32970.qmail@web33301.mail.mud.yahoo.com> Message-ID: <5246D929-2E8D-491F-8541-E3219D0622FE@cs.columbia.edu> This seems conceptually similar to the ICE approach, except that ICE uses out-of-band mechanisms to test the possible address bindings, rather than in-band ones. Or is there some other fundamental difference? On Jan 20, 2006, at 5:54 PM, Philip Matthews wrote: > In fact, Suresh and a couple of others wrote a nice paper that > describes this technique in detail > with an analysis of when it does and does not work. > "Peer-to-Peer Communication Across Network Address Translators" > http://www.brynosaurus.com/pub/net/p2pnat/ > > - Philip > From dbarrett at quinthar.com Fri Jan 20 21:01:29 2006 From: dbarrett at quinthar.com (David Barrett) Date: Fri, 20 Jan 2006 18:01:29 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <20060121005528.19744.qmail@web33312.mail.mud.yahoo.com> Message-ID: <200601210201.k0L21iKF007730@cs.columbia.edu> I understand. Thanks. I totally, 100% support a unified STUN/TURN/ICE replacement. And I completely endorse a single specification for the total functionality of a rendezvous service. However, I'd go one step further and suggest that we can accomplish this with minor alterations to SIP itself, and with minor additions to the SIP proxy. Thus I think we can do this without creating a new protocol or server from scratch. My reasoning (possibly not fully thought through) is that virtually all SIP deployments will occur over the internet, and thus will require a NAT-penetrating rendezvous service. The SIP proxy seems a natural place to do this (as it is virtually always publicly accessible), and it'd be great if P2P-SIP-compliant clients "just worked" across NATs without major changes to the overall syntax and state machines that have been refined with SIP. Specifically, I think the existing SIP protocol and proxies already do 90% of what is necessary to pierce NATs. The particular message flow I'd recommend is: - All user agents use a STUN-like protocol on the SIP proxy to find both public and private (ip:port) tuples. - All user agents REGISTER both (ip:port) tuples with the SIP proxy. - All clients maintain a punched UDP hole (or persistent TCP connection) to one or more SIP proxies, thereby ensuring proxies can contact clients at will. - User agent A sends INVITE to the SIP proxy, as always. - The proxy gives A a provisional response to the INVITE with a "300 Multiple Choices" (instead of "200 OK"), listing the (ip:port) tuples associated with user agent B. - The proxy forwards A's INVITE to B, appending A's (ip:port) tuples. - A, on receiving the "300 Multiple Choices" begins punching holes to both (ip:port) tuples of user agent B, thereby ensuring B can contact A. - B, on receiving the forwarded "INVITE" request from the proxy, begins responding "200 OK" to A along both of A's (ip:port) tuples, implicitly punching holes to A and ensuring it can contact B. - Eventually, A and B have each punched holes to each others' public and private (ip:port) tuples. Whichever (A(ip:port),B(ip:port)) route along with A receives "200 OK" first is used for P2P communication. In summary, I suggest: - SIP be expanded with a STUN command that proxies MUST implement - User agents REGISTER multiple (ip:port) tuples with the proxy - Proxies respond "300 Multiple Choices" to INVITE, to which UA's holepunch - Proxies append all of A's (ip:port) tuples when forwarding to B - B replies "200 OK" direct to all of A's (ip:port) tuples Obviously there are more minor issues (TURN integration, symmetric NAT piercing, etc), but this is the core algorithm. And this *works today* in iGlance (www.iglance.com), so it's not an abstract proposal. The relevant logic is implemented here (though obviously it won't make much sense without the context of the rest of the architecture): http://svn.iglance.com/svn/trunk/iglance/client/GBuddySession.cpp The benefit is: - You don't need a separate syntax/grammar for STUN/TURN (in SIP) - You don't need a separate STUN/TURN server (in the proxy) - You don't need ICE at all (implicit in message flow) - Clients needn't implement STUN servers (as ICE requires) - Client state machines are vastly reduced in complexity over ICE Furthermore, this is *entirely* compatible (indeed, orthogonal) to a decentralized SIP proxy. By combining NAT rendezvous service with the SIP proxy service, the same supernode structure can be used for proxying as for NAT penetration (potentially even TURN relaying). Basically, NAT penetration isn't really that hard, and SIP *almost* already does it. It'd be a shame to create a whole new layer of protocol complexity to solve such a minor, universal problem as this when very slight adjustments to SIP itself can make the problem go away. -david > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > Sent: Friday, January 20, 2006 4:55 PM > To: David Barrett; 'Philip Matthews'; 'Dean Willis' > Cc: 'P2P-SIP' > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > I am in favor of option b). Create a new protocol that ultimately replaces > STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol. > The > "rendezvous server" or "super node" that runs the protocol need not be a > SIP > proxy. > > cheers, > suresh > > --- David Barrett wrote: > > > > -----Original Message----- > > > From: Philip Matthews > > > > > > What I see us (the P2P-SIP group) doing is specifying the protocol > > > used between the Rendezvous Server, > > > peer P, and node X. Then some P2P-SIP networks may decide to use one > > > server, and other networks > > > may decide to use another server. Node X will then have to know (a) > > > which server to contact, (b) the name > > > of the P2P-SIP network it wishes to join, and (c) the password (if > > > any) to join. > > > > I think I agree with this, but I'm unclear what you are specifically > > proposing. Are you suggesting the P2P-SIP group: > > > > a) Adjust SIP to implicitly solve the NAT penetration issues, thereby > making > > every SIP proxy naturally serve as a "rendezvous server", ultimately > doing > > away with STUN, TURN, and ICE entirely? > > - (Incidentally, I think this is the right course.) > > > > b) Create a new protocol that replaces STUN, TURN, and ICE, then > implement > > this new protocol in a new "rendezvous server" that is separate from the > SIP > > proxy, and then find a way to bridge SIP and this new server? > > > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > > protocol that somehow simplifies the NAT penetration issue? > > > > Which of these is the closest? > > > > -david > > > > _______________________________________________ > > p2p-sip mailing list > > p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From jack at atosc.org Mon Jan 9 15:43:21 2006 From: jack at atosc.org (Aymeric Moizard) Date: Mon, 9 Jan 2006 21:43:21 +0100 (CET) Subject: [p2p-sip] OpenWengo In-Reply-To: <43C2405F.2000606@tilab.com> References: <43BE77F4.5030105@cs.columbia.edu> <43C2405F.2000606@tilab.com> Message-ID: On Mon, 9 Jan 2006, Enrico Marocco wrote: > Henning Schulzrinne wrote: >> Another SIP client, but open source: http://www.openwengo.com/ > > It looks very skypish :-) and based on deprecated source of eXosip... >> Does not appear to run in p2p mode, but might be a basis for experiments >> in that space, given the GPL license. > > I completely agree that an open source approach would be great for both > supporting the specification and facilitating its adoption. However, I > think it would be most useful (and maybe easyer) to implement the p2p > support on an existing open source stack; in this way, test applications > will be simple and won't have to care about complex gui stuff, while the > (as minimal as possible) effort to add p2p features to existing programs > using that stack, can be made by official developers. > > Is anyone interested in such a kind of project? I maintain the eXosip stack. (http://www.antisip.com/download/) It's wriiten in C, portable, simple to use, simple to extend and it's GPL code. I would (and will anyway) personally help much for adding p2p support in it. Aymeric > Among available stacks, my preference would go to nokia's sofia-sip > (http://sofia-sip.sourceforge.net/), which is pretty modular and well > documented. > > Cheers > Enrico > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin at tilab.com. Thank you > ==================================================================== > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From srisuresh at yahoo.com Sat Jan 21 10:18:40 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Sat, 21 Jan 2006 07:18:40 -0800 (PST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <5246D929-2E8D-491F-8541-E3219D0622FE@cs.columbia.edu> Message-ID: <20060121151840.17100.qmail@web33301.mail.mud.yahoo.com> You are right, conceptually they have similarity, but there are differences. Both casess seek the aid of super nodes (ex: STUN/TURN nodes in the case of ICE). Below are a couple of differences between ICE and P2PNAT proposals. 1. ICE focus is on UDP based media connenctions. ICE also does not address how the signalling (ex: SIP) agents themselves connect from behind NAT devices. The P2PNAT proposal is not specific to SIP or media flow and is applicable to all types of P2P sessions, including TCP or UDP based on-line games, file transfers, signalling and multimedia-sessions. 2. ICE tries all possible connection scenarios between candidate endpoints to see which of them would click. For example, if node-L and node-R need to setup a connection and each had a list of candidate endpoints to peer with, each candidate goes through exhaustive connectivity trials, until one of them succeeds. The connection that succeeds first (say, TURN-to-TURN connection) need not be the most optimal connection. With the P2PNAT proposal, the connectivity trials are less chaotic, and the most optimal connectivity is attempted first. For example, if each of Node-L ad node-R is behind a Cone NAT, a direct end-to-end conenction is setup without a relay node in between, using the simultaneous hole punch techniqiue. cheers, suresh --- Henning Schulzrinne wrote: > This seems conceptually similar to the ICE approach, except that ICE > uses out-of-band mechanisms to test the possible address bindings, > rather than in-band ones. Or is there some other fundamental difference? > > On Jan 20, 2006, at 5:54 PM, Philip Matthews wrote: > > > In fact, Suresh and a couple of others wrote a nice paper that > > describes this technique in detail > > with an analysis of when it does and does not work. > > "Peer-to-Peer Communication Across Network Address Translators" > > http://www.brynosaurus.com/pub/net/p2pnat/ > > > > - Philip > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From afisk at speedymail.org Sat Jan 21 13:57:43 2006 From: afisk at speedymail.org (Adam Fisk) Date: Sat, 21 Jan 2006 13:57:43 -0500 Subject: [p2p-sip] DHT deployed in a large scale In-Reply-To: <43A33ED1.9080603@research.panasonic.com> References: <43A33ED1.9080603@research.panasonic.com> Message-ID: <43D28427.70600@speedymail.org> The eMule/eDonkey (eMule calls theirs "Kad") networks are by far the largest DHT deployments out there. Azureus also uses a Kademlia network for trackerless torrents. That's undoubtedly quite large as well. -Adam Eunsoo Shim wrote: >Hi, > >I noticed that Kademlia (a DHT) is being used for a p2p filesharing >network called Kad Network in which the number of concurrent network >users is 3.5 - 5.1 million according to Wikipedia. > >http://en.wikipedia.org/wiki/Kademlia >http://en.wikipedia.org/wiki/Kad_Network > >It is impressive. >Does anyone know any other large scale DHT deployments? >Thanks. > >Eunsoo >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > From huang-ming.pan at comcast.net Sat Jan 21 14:59:08 2006 From: huang-ming.pan at comcast.net (PP) Date: Sat, 21 Jan 2006 11:59:08 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG References: <200601210201.k0L21iKF007730@cs.columbia.edu> Message-ID: <001a01c61ec5$250eb7f0$6400a8c0@ao.lop.com> Quoted: " (1). Clients needn't implement STUN servers (as ICE requires) (2). By combining NAT rendezvous service with the SIP proxy service, the same supernode structure can be used for proxying as for NAT penetration (potentially even TURN relaying). " It sounds that the terms "clients" and "supernode" referred to two different types (implementations/functionalities) of p2p-sip nodes. Questions of mine are: Q1: how to know in advance during software build/release or hardware manufacture phase that a node will be running as "a client only" or as a supernode? Q2: when a node (soft or hard phone) is "made" to be working specifically as a supernode, won't the scenario become another flavor of client/server deployment? I thought what p2p-sip working group would plan to propose is a "ultimate utopia" where all nodes (soft/hard) are "homegenerous" in implementation, functionality and deployment aspects, and what we (:either poor implementors or lucky architect:) were going to benefit is to "DO ONE THING ONCE FOR ALL AND EVER". It seems I might have thought wrong and the thing seem moving back toward some kind of client/server ugliness. peter ----- Original Message ----- From: "David Barrett" To: "'Pyda Srisuresh'" ; "'Philip Matthews'" ; "'Dean Willis'" Cc: "'P2P-SIP'" Sent: Friday, January 20, 2006 6:01 PM Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > I understand. Thanks. > > I totally, 100% support a unified STUN/TURN/ICE replacement. And I > completely endorse a single specification for the total functionality of a > rendezvous service. > > However, I'd go one step further and suggest that we can accomplish this > with minor alterations to SIP itself, and with minor additions to the SIP > proxy. Thus I think we can do this without creating a new protocol or > server from scratch. > > My reasoning (possibly not fully thought through) is that virtually all SIP > deployments will occur over the internet, and thus will require a > NAT-penetrating rendezvous service. The SIP proxy seems a natural place to > do this (as it is virtually always publicly accessible), and it'd be great > if P2P-SIP-compliant clients "just worked" across NATs without major changes > to the overall syntax and state machines that have been refined with SIP. > > > Specifically, I think the existing SIP protocol and proxies already do 90% > of what is necessary to pierce NATs. The particular message flow I'd > recommend is: > > - All user agents use a STUN-like protocol on the SIP proxy to find both > public and private (ip:port) tuples. > > - All user agents REGISTER both (ip:port) tuples with the SIP proxy. > > - All clients maintain a punched UDP hole (or persistent TCP connection) to > one or more SIP proxies, thereby ensuring proxies can contact clients at > will. > > - User agent A sends INVITE to the SIP proxy, as always. > > - The proxy gives A a provisional response to the INVITE with a "300 > Multiple Choices" (instead of "200 OK"), listing the (ip:port) tuples > associated with user agent B. > > - The proxy forwards A's INVITE to B, appending A's (ip:port) tuples. > > - A, on receiving the "300 Multiple Choices" begins punching holes to both > (ip:port) tuples of user agent B, thereby ensuring B can contact A. > > - B, on receiving the forwarded "INVITE" request from the proxy, begins > responding "200 OK" to A along both of A's (ip:port) tuples, implicitly > punching holes to A and ensuring it can contact B. > > - Eventually, A and B have each punched holes to each others' public and > private (ip:port) tuples. Whichever (A(ip:port),B(ip:port)) route along > with A receives "200 OK" first is used for P2P communication. > > > In summary, I suggest: > - SIP be expanded with a STUN command that proxies MUST implement > - User agents REGISTER multiple (ip:port) tuples with the proxy > - Proxies respond "300 Multiple Choices" to INVITE, to which UA's holepunch > - Proxies append all of A's (ip:port) tuples when forwarding to B > - B replies "200 OK" direct to all of A's (ip:port) tuples > > Obviously there are more minor issues (TURN integration, symmetric NAT > piercing, etc), but this is the core algorithm. And this *works today* in > iGlance (www.iglance.com), so it's not an abstract proposal. The relevant > logic is implemented here (though obviously it won't make much sense without > the context of the rest of the architecture): > > http://svn.iglance.com/svn/trunk/iglance/client/GBuddySession.cpp > > The benefit is: > - You don't need a separate syntax/grammar for STUN/TURN (in SIP) > - You don't need a separate STUN/TURN server (in the proxy) > - You don't need ICE at all (implicit in message flow) > - Clients needn't implement STUN servers (as ICE requires) > - Client state machines are vastly reduced in complexity over ICE > > Furthermore, this is *entirely* compatible (indeed, orthogonal) to a > decentralized SIP proxy. By combining NAT rendezvous service with the SIP > proxy service, the same supernode structure can be used for proxying as for > NAT penetration (potentially even TURN relaying). > > > Basically, NAT penetration isn't really that hard, and SIP *almost* already > does it. It'd be a shame to create a whole new layer of protocol complexity > to solve such a minor, universal problem as this when very slight > adjustments to SIP itself can make the problem go away. > > -david > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > Sent: Friday, January 20, 2006 4:55 PM > > To: David Barrett; 'Philip Matthews'; 'Dean Willis' > > Cc: 'P2P-SIP' > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > I am in favor of option b). Create a new protocol that ultimately replaces > > STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol. > > The > > "rendezvous server" or "super node" that runs the protocol need not be a > > SIP > > proxy. > > > > cheers, > > suresh > > > > --- David Barrett wrote: > > > > > > -----Original Message----- > > > > From: Philip Matthews > > > > > > > > What I see us (the P2P-SIP group) doing is specifying the protocol > > > > used between the Rendezvous Server, > > > > peer P, and node X. Then some P2P-SIP networks may decide to use one > > > > server, and other networks > > > > may decide to use another server. Node X will then have to know (a) > > > > which server to contact, (b) the name > > > > of the P2P-SIP network it wishes to join, and (c) the password (if > > > > any) to join. > > > > > > I think I agree with this, but I'm unclear what you are specifically > > > proposing. Are you suggesting the P2P-SIP group: > > > > > > a) Adjust SIP to implicitly solve the NAT penetration issues, thereby > > making > > > every SIP proxy naturally serve as a "rendezvous server", ultimately > > doing > > > away with STUN, TURN, and ICE entirely? > > > - (Incidentally, I think this is the right course.) > > > > > > b) Create a new protocol that replaces STUN, TURN, and ICE, then > > implement > > > this new protocol in a new "rendezvous server" that is separate from the > > SIP > > > proxy, and then find a way to bridge SIP and this new server? > > > > > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > > > protocol that somehow simplifies the NAT penetration issue? > > > > > > Which of these is the closest? > > > > > > -david > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > From dbarrett at quinthar.com Sat Jan 21 21:59:39 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat, 21 Jan 2006 18:59:39 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <001a01c61ec5$250eb7f0$6400a8c0@ao.lop.com> Message-ID: <200601220300.k0M2xlKF022158@cs.columbia.edu> > -----Original Message----- > From: PP [mailto:huang-ming.pan at comcast.net] > > It sounds that the terms "clients" and "supernode" referred to two > different types (implementations/functionalities) of p2p-sip nodes. "client" and "supernode" functionality is certainly different. It's possible that a single node is able to do one, the other, or both. The ideal P2P deployment would have every node capable of performing both roles, and some algorithm exists for promoting normal nodes into supernodes as befits the network. Today's SIP has "supernode" functionality firmly in the realm of the proxy, and "client" functionality firmly in the user agent. However, there's no reason to prevent a user agent from behaving like a proxy. But then again, there's no reason to mandate that it do so, either. The protocol should support both, and then leave it up to the programmer to decide how far a given node will go. > Q1: how to know in advance during software build/release or hardware > manufacture phase that a node will be running as "a client only" or as a > supernode? Ideally, any node that can act as both should act as both. However, not all nodes *can* implement both functions. For example, some very trim device might not have the computational resources to act as a supernode, but should still be capable of acting as a normal client. > > Q2: when a node (soft or hard phone) is "made" to be working specifically > as > a supernode, won't the scenario become another flavor of client/server > deployment? Yes, just as an implementer should have the option of making a pure client, he should have the option of making a pure server. But again, the protocol should allow a single node to act in either or both supernode and client capacities. Does this answer your questions? -david From dean.willis at softarmor.com Sat Jan 21 23:30:18 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Sat, 21 Jan 2006 22:30:18 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: References: <200601200748.k0K7j0KF019339@cs.columbia.edu> <256DB979-21C5-4F18-88C9-DDD7B5CE16E1@softarmor.com> Message-ID: <82A2A593-1568-43F5-B076-7033C25C8B2B@softarmor.com> On Jan 20, 2006, at 1:51 PM, Philip Matthews wrote: > > On 20-Jan-06, at 13:27 , Dean Willis wrote: > >> Of course, there may be nothing we can actually DO for people who >> are all behind separate non-cooperative NATs that doesn't require >> having at least one node somewhere actually publicly visible somehow. > > If: > 1) The peers are behind NATs with the "Endpoint Independent > mapping" behavior > (to use the terminology of the BEHAVE UDP draft); AND > 2) There is a Rendezvous server with a public IP address (either > static or with a DNS entry) > which can remember the mapped address and port of ONE peer in > the P2P network > that the new node X wishes to join > then it is possible to solve the problem. I fail to see how the requirement of #2 "A rendezvous server with a public IP address" is not "at least one node somewhere actually publicly visible". -- Dean From royrr at us.saic.com Sun Jan 22 10:13:06 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Sun, 22 Jan 2006 10:13:06 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F62340D@0591-its-exmp01.us.saic.com> David: If I understand correctly, it appears that P2P-SIP protocol itself will be such that it will assume all functionalities will be available in each peer (e.g., node, supernode, client-server node) without distinguishing between UA and proxy. In this way, it simplifies the protocol development because all peers are equally capable. So, the suggestion is this: Let us not differentiate by saying node, supernode, or client-server node or otherwise. Let us call it simply a "P2P-SIP Node" from P2P-SIP protocol point of view. Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of David Barrett Sent: Sat 1/21/2006 9:59 PM To: 'PP'; 'Pyda Srisuresh'; 'Philip Matthews'; 'Dean Willis' Cc: 'P2P-SIP' Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > -----Original Message----- > From: PP [mailto:huang-ming.pan at comcast.net ] > > It sounds that the terms "clients" and "supernode" referred to two > different types (implementations/functionalities) of p2p-sip nodes. "client" and "supernode" functionality is certainly different. It's possible that a single node is able to do one, the other, or both. The ideal P2P deployment would have every node capable of performing both roles, and some algorithm exists for promoting normal nodes into supernodes as befits the network. Today's SIP has "supernode" functionality firmly in the realm of the proxy, and "client" functionality firmly in the user agent. However, there's no reason to prevent a user agent from behaving like a proxy. But then again, there's no reason to mandate that it do so, either. The protocol should support both, and then leave it up to the programmer to decide how far a given node will go. > Q1: how to know in advance during software build/release or hardware > manufacture phase that a node will be running as "a client only" or as a > supernode? Ideally, any node that can act as both should act as both. However, not all nodes *can* implement both functions. For example, some very trim device might not have the computational resources to act as a supernode, but should still be capable of acting as a normal client. > > Q2: when a node (soft or hard phone) is "made" to be working specifically > as > a supernode, won't the scenario become another flavor of client/server > deployment? Yes, just as an implementer should have the option of making a pure client, he should have the option of making a pure server. But again, the protocol should allow a single node to act in either or both supernode and client capacities. Does this answer your questions? -david _______________________________________________ p2p-sip mailing list p2p-sip at cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From huang-ming.pan at comcast.net Sun Jan 22 12:37:23 2006 From: huang-ming.pan at comcast.net (PP) Date: Sun, 22 Jan 2006 09:37:23 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <001201c61f7a$82666e60$6400a8c0@ao.lop.com> Thanks a lot for the answers, David. Yes or no. Personally I prefer all nodes born equal though they can change configuration automatically per their working environments (eg. NAT and bandwidth). All p2p nodes MUST do the best to help the network and community, instead of being manually and intentionally configured to exist as either slim or super. For example, a smart phone may only be a slim node while it is on 2.5G wireless network but should (even MUST) turn itself automatically to become supernode (at least help routing if it cannot help distribute vociemail) when moving to LAN behind a full-cone NAT. Smart p2p phone makers MUST NOT intentionally build their phones to be slim nodes only, eg. for cost saving. Imagine two websites allowing free download of soft phones based on final release (if any) of p2p-sip open-source code, one of which is built to be supernode capable and another of which is slim nodes only. Which of them would you guess will be the favorite download by the public? Homogenerity, autonomy, standardization as well as unselfishness should be essences of the p2p-sip "sharing" community. peter ----- Original Message ----- From: "David Barrett" To: "'PP'" ; "'Pyda Srisuresh'" ; "'Philip Matthews'" ; "'Dean Willis'" Cc: "'P2P-SIP'" Sent: Saturday, January 21, 2006 6:59 PM Subject: RE: [p2p-sip] Draft charter for possible P2PSIP WG > > -----Original Message----- > > From: PP [mailto:huang-ming.pan at comcast.net] > > > > It sounds that the terms "clients" and "supernode" referred to two > > different types (implementations/functionalities) of p2p-sip nodes. > > "client" and "supernode" functionality is certainly different. It's > possible that a single node is able to do one, the other, or both. The > ideal P2P deployment would have every node capable of performing both roles, > and some algorithm exists for promoting normal nodes into supernodes as > befits the network. > > Today's SIP has "supernode" functionality firmly in the realm of the proxy, > and "client" functionality firmly in the user agent. However, there's no > reason to prevent a user agent from behaving like a proxy. But then again, > there's no reason to mandate that it do so, either. The protocol should > support both, and then leave it up to the programmer to decide how far a > given node will go. > > > > Q1: how to know in advance during software build/release or hardware > > manufacture phase that a node will be running as "a client only" or as a > > supernode? > > Ideally, any node that can act as both should act as both. However, not all > nodes *can* implement both functions. For example, some very trim device > might not have the computational resources to act as a supernode, but should > still be capable of acting as a normal client. > > > > > Q2: when a node (soft or hard phone) is "made" to be working specifically > > as > > a supernode, won't the scenario become another flavor of client/server > > deployment? > > Yes, just as an implementer should have the option of making a pure client, > he should have the option of making a pure server. But again, the protocol > should allow a single node to act in either or both supernode and client > capacities. > > Does this answer your questions? > > -david > From bryan at ethernot.org Sun Jan 22 18:12:56 2006 From: bryan at ethernot.org (David A. Bryan) Date: Sun, 22 Jan 2006 18:12:56 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <001201c61f7a$82666e60$6400a8c0@ao.lop.com> References: <001201c61f7a$82666e60$6400a8c0@ao.lop.com> Message-ID: <8b2769930601221512o6c556ad0l94a6f04577e6735a@mail.gmail.com> The only way to 100% ensure this sort of behavior could be enforced is if the protocol itself were somehow designed to require you be all of the above when possible. If you can build your device to not be anything but a "slim" peer, all the draft MUSTs in the world won't keep vendor from making their phones slim if there is a market for that. I'm not sure that designing the protocol that way is really a path we want to go down, so not sure we will be able to enforce it. Back in the bad old days when file swapping was the only thing people looked at P2P for, there were hacked versions of clients around that always claimed the user had no files to share, and free loading phones seem likely in the particular deployment scenario I think you are talking about (global public network of devices, rather than say a corporate P2P device network, where policy could be used to control this). In the corporate environments, on the other hand, I can actually imagine that some peers might be deliberately super-peers, ensuring that traffic between offices, lets say, was done using one of a specific set of nodes set up for this purpose, so the argument could be made that at times, having "non-equal" nodes may be desirable. Of course it is possible that a particular overlay group in a global public network of devices could devise some other policy mechanism for this somehow, possibly with a distributed accounting mechanism. David On 1/22/06, PP wrote: > Thanks a lot for the answers, David. > > Yes or no. Personally I prefer all nodes born equal though they can change > configuration automatically per their working environments (eg. NAT and > bandwidth). All p2p nodes MUST do the best to help the network and > community, instead of being manually and intentionally configured to exist > as either slim or super. > > For example, a smart phone may only be a slim node while it is on 2.5G > wireless network but should (even MUST) turn itself automatically to become > supernode (at least help routing if it cannot help distribute vociemail) > when moving to LAN behind a full-cone NAT. Smart p2p phone makers MUST NOT > intentionally build their phones to be slim nodes only, eg. for cost saving. > > Imagine two websites allowing free download of soft phones based on final > release (if any) of p2p-sip open-source code, one of which is built to be > supernode capable and another of which is slim nodes only. Which of them > would you guess will be the favorite download by the public? > > Homogenerity, autonomy, standardization as well as unselfishness should be > essences of the p2p-sip "sharing" community. > > peter > ----- Original Message ----- > From: "David Barrett" > To: "'PP'" ; "'Pyda Srisuresh'" > ; "'Philip Matthews'" ; > "'Dean Willis'" > Cc: "'P2P-SIP'" > Sent: Saturday, January 21, 2006 6:59 PM > Subject: RE: [p2p-sip] Draft charter for possible P2PSIP WG > > > > > -----Original Message----- > > > From: PP [mailto:huang-ming.pan at comcast.net] > > > > > > It sounds that the terms "clients" and "supernode" referred to two > > > different types (implementations/functionalities) of p2p-sip nodes. > > > > "client" and "supernode" functionality is certainly different. It's > > possible that a single node is able to do one, the other, or both. The > > ideal P2P deployment would have every node capable of performing both > roles, > > and some algorithm exists for promoting normal nodes into supernodes as > > befits the network. > > > > Today's SIP has "supernode" functionality firmly in the realm of the > proxy, > > and "client" functionality firmly in the user agent. However, there's no > > reason to prevent a user agent from behaving like a proxy. But then > again, > > there's no reason to mandate that it do so, either. The protocol should > > support both, and then leave it up to the programmer to decide how far a > > given node will go. > > > > > > > Q1: how to know in advance during software build/release or hardware > > > manufacture phase that a node will be running as "a client only" or as a > > > supernode? > > > > Ideally, any node that can act as both should act as both. However, not > all > > nodes *can* implement both functions. For example, some very trim device > > might not have the computational resources to act as a supernode, but > should > > still be capable of acting as a normal client. > > > > > > > > Q2: when a node (soft or hard phone) is "made" to be working > specifically > > > as > > > a supernode, won't the scenario become another flavor of client/server > > > deployment? > > > > Yes, just as an implementer should have the option of making a pure > client, > > he should have the option of making a pure server. But again, the > protocol > > should allow a single node to act in either or both supernode and client > > capacities. > > > > Does this answer your questions? > > > > -david > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From royrr at us.saic.com Sun Jan 22 22:11:18 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Sun, 22 Jan 2006 22:11:18 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F62340E@0591-its-exmp01.us.saic.com> David and PP: Let me interject into this discussion. If we take the example of P2P-SIP, we see that this protocol will not distinguish between UA and proxy as every peer will have all the capabilities and may be termed as "peer Node" (instead of super-node, slim-node, etc.). So, the idea of the p2p-SIP protocol development will be how a peer-node can satisfy the needs for p2p communications without being subordinate of other nodes. In the past, we have seen simple dump device like POTS in the PEST world, client and sever communications protocol in the IP network, UA and Proxy entities in the case of non-p2p-SIP protocol, and others. As you have seen that we are now taking the approach of the path to make SIP protocol completely P2P. Definitely, it will have more functionalities as no peer wants to be subordinate compare to others. Consequently, we have to develop the basic protocol that works as p2p-SIP without assuming that some peer nodes will have super-node capabilities and some are not. Once we develop the basic structure of the p2p-SIP protocol, we may then see whether some kinds of hierarchical architecture of p2p configurations are necessary or not, but definitely we MUST not bog down to this right now. Any comments? Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of David A. Bryan Sent: Sun 1/22/2006 6:12 PM To: PP Cc: P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG The only way to 100% ensure this sort of behavior could be enforced is if the protocol itself were somehow designed to require you be all of the above when possible. If you can build your device to not be anything but a "slim" peer, all the draft MUSTs in the world won't keep vendor from making their phones slim if there is a market for that. I'm not sure that designing the protocol that way is really a path we want to go down, so not sure we will be able to enforce it. Back in the bad old days when file swapping was the only thing people looked at P2P for, there were hacked versions of clients around that always claimed the user had no files to share, and free loading phones seem likely in the particular deployment scenario I think you are talking about (global public network of devices, rather than say a corporate P2P device network, where policy could be used to control this). In the corporate environments, on the other hand, I can actually imagine that some peers might be deliberately super-peers, ensuring that traffic between offices, lets say, was done using one of a specific set of nodes set up for this purpose, so the argument could be made that at times, having "non-equal" nodes may be desirable. Of course it is possible that a particular overlay group in a global public network of devices could devise some other policy mechanism for this somehow, possibly with a distributed accounting mechanism. David From bryan at ethernot.org Mon Jan 23 09:15:50 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 23 Jan 2006 09:15:50 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F62340E@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F62340E@0591-its-exmp01.us.saic.com> Message-ID: <8b2769930601230615i20433316y209186d7c6b34d0e@mail.gmail.com> I don't think I agree it is clear the all features for all nodes behavior is what we want, or that it is an issue that can be assumed desirable until we see need for different behaviors. I think it is open until we are clear what the services of a node are. For example, I don't think that is true if we have TURN type media relay as a service. I guess I had two points in my earlier email: 1) If we decide we want all nodes always equal it would need to be somehow explicit in the design, or in the end devices won't implement them all. If for example, we design a basic protocol for resource location and signalling, and one of those resource's a node can advertise is it is willing to be a media relay (this could be one way that nodes are defined as "slim" or "not slim" to use PP's terms), there is no way to enforce which nodes advertise they have the service and which don't. Any service we do decide should always be implemented must be part of the protocol. If we wanted relay, we would need to make it discovered in the protocol, not just advertised. 2) My second point was I can already see some cases -- the corporate deployments I mentioned in the last email being one -- where they may wish to control services like media relay. For managed deployments where P2P is a way for an organization to reduce capex and opex, as opposed to the Skype type-deployment, having different node types may be desirable. If we ignore it at this stage, we in effect decide implicitly by what we design. For me it isn't obvious yet that making every node have all capabilities is desirable for all the use cases I have seen. I think that both types of uses (managed/unmanaged) are interesting and should be kept in mind. --David On 1/22/06, Roy, Radhika R. wrote: > David and PP: > > Let me interject into this discussion. > > If we take the example of P2P-SIP, we see that this protocol will not > distinguish between UA and proxy as every peer will have all the > capabilities and may be termed as "peer Node" (instead of super-node, > slim-node, etc.). > > So, the idea of the p2p-SIP protocol development will be how a peer-node can > satisfy the needs for p2p communications without being subordinate of other > nodes. > > In the past, we have seen simple dump device like POTS in the PEST world, > client and sever communications protocol in the IP network, UA and Proxy > entities in the case of non-p2p-SIP protocol, and others. > > As you have seen that we are now taking the approach of the path to make SIP > protocol completely P2P. Definitely, it will have more functionalities as no > peer wants to be subordinate compare to others. > > Consequently, we have to develop the basic protocol that works as p2p-SIP > without assuming that some peer nodes will have super-node capabilities and > some are not. > > Once we develop the basic structure of the p2p-SIP protocol, we may then see > whether some kinds of hierarchical architecture of p2p configurations are > necessary or not, but definitely we MUST not bog down to this right now. > > Any comments? > > Best regards, > Radhika > > _____ > > From: p2p-sip-bounces at cs.columbia.edu on behalf of David A. Bryan > Sent: Sun 1/22/2006 6:12 PM > To: PP > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > The only way to 100% ensure this sort of behavior could be enforced is > if the protocol itself were somehow designed to require you be all of > the above when possible. If you can build your device to not be > anything but a "slim" peer, all the draft MUSTs in the world won't > keep vendor from making their phones slim if there is a market for > that. I'm not sure that designing the protocol that way is really a > path we want to go down, so not sure we will be able to enforce it. > > Back in the bad old days when file swapping was the only thing people > looked at P2P for, there were hacked versions of clients around that > always claimed the user had no files to share, and free loading phones > seem likely in the particular deployment scenario I think you are > talking about (global public network of devices, rather than say a > corporate P2P device network, where policy could be used to control > this). In the corporate environments, on the other hand, I can > actually imagine that some peers might be deliberately super-peers, > ensuring that traffic between offices, lets say, was done using one of > a specific set of nodes set up for this purpose, so the argument could > be made that at times, having "non-equal" nodes may be desirable. > > Of course it is possible that a particular overlay group in a global > public network of devices could devise some other policy mechanism for > this somehow, possibly with a distributed accounting mechanism. > > David > > From srisuresh at yahoo.com Mon Jan 23 09:39:29 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Mon, 23 Jan 2006 06:39:29 -0800 (PST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <20060123143929.71784.qmail@web33315.mail.mud.yahoo.com> Hi David, Thank you for the comments. Please see my responses in line below. regards, suresh --- David Barrett wrote: > I understand. Thanks. > > I totally, 100% support a unified STUN/TURN/ICE replacement. And I > completely endorse a single specification for the total functionality of a > rendezvous service. > [suresh] Great. Glad to hear this. > However, I'd go one step further and suggest that we can accomplish this > with minor alterations to SIP itself, and with minor additions to the SIP > proxy. Thus I think we can do this without creating a new protocol or > server from scratch. > > My reasoning (possibly not fully thought through) is that virtually all SIP > deployments will occur over the internet, and thus will require a > NAT-penetrating rendezvous service. [suresh] OK. However, several P2P applications that do not use SIP will also need NAT-penetration service. > The SIP proxy seems a natural place to > do this (as it is virtually always publicly accessible), and it'd be great > if P2P-SIP-compliant clients "just worked" across NATs without major changes > to the overall syntax and state machines that have been refined with SIP. > [suresh] Right, I see what you mean. > > Specifically, I think the existing SIP protocol and proxies already do 90% > of what is necessary to pierce NATs. The particular message flow I'd > recommend is: > > - All user agents use a STUN-like protocol on the SIP proxy to find both > public and private (ip:port) tuples. > > - All user agents REGISTER both (ip:port) tuples with the SIP proxy. > > - All clients maintain a punched UDP hole (or persistent TCP connection) to > one or more SIP proxies, thereby ensuring proxies can contact clients at > will. > > - User agent A sends INVITE to the SIP proxy, as always. > > - The proxy gives A a provisional response to the INVITE with a "300 > Multiple Choices" (instead of "200 OK"), listing the (ip:port) tuples > associated with user agent B. > > - The proxy forwards A's INVITE to B, appending A's (ip:port) tuples. > > - A, on receiving the "300 Multiple Choices" begins punching holes to both > (ip:port) tuples of user agent B, thereby ensuring B can contact A. > > - B, on receiving the forwarded "INVITE" request from the proxy, begins > responding "200 OK" to A along both of A's (ip:port) tuples, implicitly > punching holes to A and ensuring it can contact B. > > - Eventually, A and B have each punched holes to each others' public and > private (ip:port) tuples. Whichever (A(ip:port),B(ip:port)) route along > with A receives "200 OK" first is used for P2P communication. > > > In summary, I suggest: > - SIP be expanded with a STUN command that proxies MUST implement > - User agents REGISTER multiple (ip:port) tuples with the proxy > - Proxies respond "300 Multiple Choices" to INVITE, to which UA's holepunch > - Proxies append all of A's (ip:port) tuples when forwarding to B > - B replies "200 OK" direct to all of A's (ip:port) tuples > > Obviously there are more minor issues (TURN integration, symmetric NAT > piercing, etc), but this is the core algorithm. And this *works today* in > iGlance (www.iglance.com), so it's not an abstract proposal. The relevant > logic is implemented here (though obviously it won't make much sense without > the context of the rest of the architecture): > [suresh] Your proposal sounds good. I do like it. This extends the SIP protocol and mandates the SIP proxy to be the rendezvous server. However, I am uncomfortable with requiring that a SIP proxy (and only the SIP proxy) should support rendezvous service. This is because Rendezvous service can be quite bandwidth intensive, especially as it supports TURN service. Rendezvous service may also be used by non-SIP applications. Why not use a SIP-like protocol, but not tie the protocol to SIP and not tie the end nodes to SIP UA or SIP-Proxy. I havent looked up iglance.com. I will take a look. Thanks. > http://svn.iglance.com/svn/trunk/iglance/client/GBuddySession.cpp > > The benefit is: > - You don't need a separate syntax/grammar for STUN/TURN (in SIP) > - You don't need a separate STUN/TURN server (in the proxy) > - You don't need ICE at all (implicit in message flow) > - Clients needn't implement STUN servers (as ICE requires) > - Client state machines are vastly reduced in complexity over ICE > [suresh] Agree with most of the assessment. I certainly can appreciate clients not having to implement STUN server. See my comment above about the benefit (or not) of requiring the SIP Proxy to be rendezvous server :-) As for eliminating ICE, I do believe, you will need additional connection setup mechanisms, even if they differ from ICE. For instance, the proposal needs extensions to support relay service and TCP transport. > Furthermore, this is *entirely* compatible (indeed, orthogonal) to a > decentralized SIP proxy. By combining NAT rendezvous service with the SIP > proxy service, the same supernode structure can be used for proxying as for > NAT penetration (potentially even TURN relaying). > > > Basically, NAT penetration isn't really that hard, and SIP *almost* already > does it. It'd be a shame to create a whole new layer of protocol complexity > to solve such a minor, universal problem as this when very slight > adjustments to SIP itself can make the problem go away. > [suresh] Well, NAT penetration is not easy. There are many P2P applications that seek NAT penetration. SIP based applications is one such group of apps. When the NAT penetraton is addressed as an independent problem, SIP can be extented to support that solution. regards, suresh > -david > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > Sent: Friday, January 20, 2006 4:55 PM > > To: David Barrett; 'Philip Matthews'; 'Dean Willis' > > Cc: 'P2P-SIP' > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > I am in favor of option b). Create a new protocol that ultimately replaces > > STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol. > > The > > "rendezvous server" or "super node" that runs the protocol need not be a > > SIP > > proxy. > > > > cheers, > > suresh > > > > --- David Barrett wrote: > > > > > > -----Original Message----- > > > > From: Philip Matthews > > > > > > > > What I see us (the P2P-SIP group) doing is specifying the protocol > > > > used between the Rendezvous Server, > > > > peer P, and node X. Then some P2P-SIP networks may decide to use one > > > > server, and other networks > > > > may decide to use another server. Node X will then have to know (a) > > > > which server to contact, (b) the name > > > > of the P2P-SIP network it wishes to join, and (c) the password (if > > > > any) to join. > > > > > > I think I agree with this, but I'm unclear what you are specifically > > > proposing. Are you suggesting the P2P-SIP group: > > > > > > a) Adjust SIP to implicitly solve the NAT penetration issues, thereby > > making > > > every SIP proxy naturally serve as a "rendezvous server", ultimately > > doing > > > away with STUN, TURN, and ICE entirely? > > > - (Incidentally, I think this is the right course.) > > > > > > b) Create a new protocol that replaces STUN, TURN, and ICE, then > > implement > > > this new protocol in a new "rendezvous server" that is separate from the > > SIP > > > proxy, and then find a way to bridge SIP and this new server? > > > > > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > > > protocol that somehow simplifies the NAT penetration issue? > > > > > > Which of these is the closest? > > > > > > -david > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > From srisuresh at yahoo.com Mon Jan 23 10:01:44 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Mon, 23 Jan 2006 07:01:44 -0800 (PST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <8b2769930601230615i20433316y209186d7c6b34d0e@mail.gmail.com> Message-ID: <20060123150144.67236.qmail@web33303.mail.mud.yahoo.com> I fully agree with David' comments. For example, there are topological requirements on a "rendezvous" server for NAT penetration. Unlike an end node (which can be behind NAT devices), a rendezvous server is required to be on the public Internet. We do need to be open and review the distinct roles and serrvices as they are, without requiring all roles and services on all nodes. cheers, suresh --- "David A. Bryan" wrote: > I don't think I agree it is clear the all features for all nodes > behavior is what we want, or that it is an issue that can be assumed > desirable until we see need for different behaviors. I think it is > open until we are clear what the services of a node are. For example, > I don't think that is true if we have TURN type media relay as a > service. > > I guess I had two points in my earlier email: > > 1) If we decide we want all nodes always equal it would need to be > somehow explicit in the design, or in the end devices won't implement > them all. If for example, we design a basic protocol for resource > location and signalling, and one of those resource's a node can > advertise is it is willing to be a media relay (this could be one way > that nodes are defined as "slim" or "not slim" to use PP's terms), > there is no way to enforce which nodes advertise they have the service > and which don't. Any service we do decide should always be implemented > must be part of the protocol. If we wanted relay, we would need to > make it discovered in the protocol, not just advertised. > > 2) My second point was I can already see some cases -- the corporate > deployments I mentioned in the last email being one -- where they may > wish to control services like media relay. For managed deployments > where P2P is a way for an organization to reduce capex and opex, as > opposed to the Skype type-deployment, having different node types may > be desirable. > > If we ignore it at this stage, we in effect decide implicitly by what > we design. For me it isn't obvious yet that making every node have all > capabilities is desirable for all the use cases I have seen. I think > that both types of uses (managed/unmanaged) are interesting and should > be kept in mind. > > --David > > > On 1/22/06, Roy, Radhika R. wrote: > > David and PP: > > > > Let me interject into this discussion. > > > > If we take the example of P2P-SIP, we see that this protocol will not > > distinguish between UA and proxy as every peer will have all the > > capabilities and may be termed as "peer Node" (instead of super-node, > > slim-node, etc.). > > > > So, the idea of the p2p-SIP protocol development will be how a peer-node > can > > satisfy the needs for p2p communications without being subordinate of other > > nodes. > > > > In the past, we have seen simple dump device like POTS in the PEST world, > > client and sever communications protocol in the IP network, UA and Proxy > > entities in the case of non-p2p-SIP protocol, and others. > > > > As you have seen that we are now taking the approach of the path to make > SIP > > protocol completely P2P. Definitely, it will have more functionalities as > no > > peer wants to be subordinate compare to others. > > > > Consequently, we have to develop the basic protocol that works as p2p-SIP > > without assuming that some peer nodes will have super-node capabilities and > > some are not. > > > > Once we develop the basic structure of the p2p-SIP protocol, we may then > see > > whether some kinds of hierarchical architecture of p2p configurations are > > necessary or not, but definitely we MUST not bog down to this right now. > > > > Any comments? > > > > Best regards, > > Radhika > > > > _____ > > > > From: p2p-sip-bounces at cs.columbia.edu on behalf of David A. Bryan > > Sent: Sun 1/22/2006 6:12 PM > > To: PP > > Cc: P2P-SIP > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > > > > > The only way to 100% ensure this sort of behavior could be enforced is > > if the protocol itself were somehow designed to require you be all of > > the above when possible. If you can build your device to not be > > anything but a "slim" peer, all the draft MUSTs in the world won't > > keep vendor from making their phones slim if there is a market for > > that. I'm not sure that designing the protocol that way is really a > > path we want to go down, so not sure we will be able to enforce it. > > > > Back in the bad old days when file swapping was the only thing people > > looked at P2P for, there were hacked versions of clients around that > > always claimed the user had no files to share, and free loading phones > > seem likely in the particular deployment scenario I think you are > > talking about (global public network of devices, rather than say a > > corporate P2P device network, where policy could be used to control > > this). In the corporate environments, on the other hand, I can > > actually imagine that some peers might be deliberately super-peers, > > ensuring that traffic between offices, lets say, was done using one of > > a specific set of nodes set up for this purpose, so the argument could > > be made that at times, having "non-equal" nodes may be desirable. > > > > Of course it is possible that a particular overlay group in a global > > public network of devices could devise some other policy mechanism for > > this somehow, possibly with a distributed accounting mechanism. > > > > David > > > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From henry at pulver.com Mon Jan 23 10:22:47 2006 From: henry at pulver.com (Henry Sinnreich) Date: Mon, 23 Jan 2006 09:22:47 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <20060123143929.71784.qmail@web33315.mail.mud.yahoo.com> Message-ID: <200601231526.k0NFMlKG011649@cs.columbia.edu> Pyda, I have followed your discussion on this trail, have read your I-D and would suggest we limit the scope here to: 1. SIP only, 2. ICE/TURN/STUN since they solve 100% NAT traversal for SIP and RTP. Other protocols (non-SIP) and NAT traversal solutions that do not solve 100% of NAT scenarios should be out of scope. > with minor alterations to SIP itself, Out of scope, unless they accomplish 100% NAT traversal and ICE/TURN/STUN is proven to be broken. My two cents, Henry -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] Sent: Monday, January 23, 2006 8:39 AM To: David Barrett; 'Philip Matthews'; 'Dean Willis' Cc: 'P2P-SIP' Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG Hi David, Thank you for the comments. Please see my responses in line below. regards, suresh --- David Barrett wrote: > I understand. Thanks. > > I totally, 100% support a unified STUN/TURN/ICE replacement. And I > completely endorse a single specification for the total functionality of a > rendezvous service. > [suresh] Great. Glad to hear this. > However, I'd go one step further and suggest that we can accomplish this > with minor alterations to SIP itself, and with minor additions to the SIP > proxy. Thus I think we can do this without creating a new protocol or > server from scratch. > > My reasoning (possibly not fully thought through) is that virtually all SIP > deployments will occur over the internet, and thus will require a > NAT-penetrating rendezvous service. [suresh] OK. However, several P2P applications that do not use SIP will also need NAT-penetration service. > The SIP proxy seems a natural place to > do this (as it is virtually always publicly accessible), and it'd be great > if P2P-SIP-compliant clients "just worked" across NATs without major changes > to the overall syntax and state machines that have been refined with SIP. > [suresh] Right, I see what you mean. > > Specifically, I think the existing SIP protocol and proxies already do 90% > of what is necessary to pierce NATs. The particular message flow I'd > recommend is: > > - All user agents use a STUN-like protocol on the SIP proxy to find both > public and private (ip:port) tuples. > > - All user agents REGISTER both (ip:port) tuples with the SIP proxy. > > - All clients maintain a punched UDP hole (or persistent TCP connection) to > one or more SIP proxies, thereby ensuring proxies can contact clients at > will. > > - User agent A sends INVITE to the SIP proxy, as always. > > - The proxy gives A a provisional response to the INVITE with a "300 > Multiple Choices" (instead of "200 OK"), listing the (ip:port) tuples > associated with user agent B. > > - The proxy forwards A's INVITE to B, appending A's (ip:port) tuples. > > - A, on receiving the "300 Multiple Choices" begins punching holes to both > (ip:port) tuples of user agent B, thereby ensuring B can contact A. > > - B, on receiving the forwarded "INVITE" request from the proxy, begins > responding "200 OK" to A along both of A's (ip:port) tuples, implicitly > punching holes to A and ensuring it can contact B. > > - Eventually, A and B have each punched holes to each others' public and > private (ip:port) tuples. Whichever (A(ip:port),B(ip:port)) route along > with A receives "200 OK" first is used for P2P communication. > > > In summary, I suggest: > - SIP be expanded with a STUN command that proxies MUST implement > - User agents REGISTER multiple (ip:port) tuples with the proxy > - Proxies respond "300 Multiple Choices" to INVITE, to which UA's holepunch > - Proxies append all of A's (ip:port) tuples when forwarding to B > - B replies "200 OK" direct to all of A's (ip:port) tuples > > Obviously there are more minor issues (TURN integration, symmetric NAT > piercing, etc), but this is the core algorithm. And this *works today* in > iGlance (www.iglance.com), so it's not an abstract proposal. The relevant > logic is implemented here (though obviously it won't make much sense without > the context of the rest of the architecture): > [suresh] Your proposal sounds good. I do like it. This extends the SIP protocol and mandates the SIP proxy to be the rendezvous server. However, I am uncomfortable with requiring that a SIP proxy (and only the SIP proxy) should support rendezvous service. This is because Rendezvous service can be quite bandwidth intensive, especially as it supports TURN service. Rendezvous service may also be used by non-SIP applications. Why not use a SIP-like protocol, but not tie the protocol to SIP and not tie the end nodes to SIP UA or SIP-Proxy. I havent looked up iglance.com. I will take a look. Thanks. > http://svn.iglance.com/svn/trunk/iglance/client/GBuddySession.cpp > > The benefit is: > - You don't need a separate syntax/grammar for STUN/TURN (in SIP) > - You don't need a separate STUN/TURN server (in the proxy) > - You don't need ICE at all (implicit in message flow) > - Clients needn't implement STUN servers (as ICE requires) > - Client state machines are vastly reduced in complexity over ICE > [suresh] Agree with most of the assessment. I certainly can appreciate clients not having to implement STUN server. See my comment above about the benefit (or not) of requiring the SIP Proxy to be rendezvous server :-) As for eliminating ICE, I do believe, you will need additional connection setup mechanisms, even if they differ from ICE. For instance, the proposal needs extensions to support relay service and TCP transport. > Furthermore, this is *entirely* compatible (indeed, orthogonal) to a > decentralized SIP proxy. By combining NAT rendezvous service with the SIP > proxy service, the same supernode structure can be used for proxying as for > NAT penetration (potentially even TURN relaying). > > > Basically, NAT penetration isn't really that hard, and SIP *almost* already > does it. It'd be a shame to create a whole new layer of protocol complexity > to solve such a minor, universal problem as this when very slight > adjustments to SIP itself can make the problem go away. > [suresh] Well, NAT penetration is not easy. There are many P2P applications that seek NAT penetration. SIP based applications is one such group of apps. When the NAT penetraton is addressed as an independent problem, SIP can be extented to support that solution. regards, suresh > -david > > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > Sent: Friday, January 20, 2006 4:55 PM > > To: David Barrett; 'Philip Matthews'; 'Dean Willis' > > Cc: 'P2P-SIP' > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > I am in favor of option b). Create a new protocol that ultimately replaces > > STUN, TURN, and ICE. Adjust SIP to take advantage of this new protocol. > > The > > "rendezvous server" or "super node" that runs the protocol need not be a > > SIP > > proxy. > > > > cheers, > > suresh > > > > --- David Barrett wrote: > > > > > > -----Original Message----- > > > > From: Philip Matthews > > > > > > > > What I see us (the P2P-SIP group) doing is specifying the protocol > > > > used between the Rendezvous Server, > > > > peer P, and node X. Then some P2P-SIP networks may decide to use one > > > > server, and other networks > > > > may decide to use another server. Node X will then have to know (a) > > > > which server to contact, (b) the name > > > > of the P2P-SIP network it wishes to join, and (c) the password (if > > > > any) to join. > > > > > > I think I agree with this, but I'm unclear what you are specifically > > > proposing. Are you suggesting the P2P-SIP group: > > > > > > a) Adjust SIP to implicitly solve the NAT penetration issues, thereby > > making > > > every SIP proxy naturally serve as a "rendezvous server", ultimately > > doing > > > away with STUN, TURN, and ICE entirely? > > > - (Incidentally, I think this is the right course.) > > > > > > b) Create a new protocol that replaces STUN, TURN, and ICE, then > > implement > > > this new protocol in a new "rendezvous server" that is separate from the > > SIP > > > proxy, and then find a way to bridge SIP and this new server? > > > > > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > > > protocol that somehow simplifies the NAT penetration issue? > > > > > > Which of these is the closest? > > > > > > -david > > > > > > _______________________________________________ > > > p2p-sip mailing list > > > p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > From philip_matthews at magma.ca Mon Jan 23 10:46:33 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Mon, 23 Jan 2006 10:46:33 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <200601202351.k0KNp0Hj029511@in2.magma.ca> References: <200601202351.k0KNp0Hj029511@in2.magma.ca> Message-ID: <4A24FF0D-FB8A-4E5C-B3D8-1958345BDA1F@magma.ca> On 20-Jan-06, at 18:50 , David Barrett wrote: >> -----Original Message----- >> From: Philip Matthews >> >> What I see us (the P2P-SIP group) doing is specifying the protocol >> used between the Rendezvous Server, >> peer P, and node X. Then some P2P-SIP networks may decide to use one >> server, and other networks >> may decide to use another server. Node X will then have to know (a) >> which server to contact, (b) the name >> of the P2P-SIP network it wishes to join, and (c) the password (if >> any) to join. > > I think I agree with this, but I'm unclear what you are specifically > proposing. Are you suggesting the P2P-SIP group: > > a) Adjust SIP to implicitly solve the NAT penetration issues, > thereby making > every SIP proxy naturally serve as a "rendezvous server", > ultimately doing > away with STUN, TURN, and ICE entirely? > - (Incidentally, I think this is the right course.) > > b) Create a new protocol that replaces STUN, TURN, and ICE, then > implement > this new protocol in a new "rendezvous server" that is separate > from the SIP > proxy, and then find a way to bridge SIP and this new server? > > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > protocol that somehow simplifies the NAT penetration issue? > > Which of these is the closest? > > -david > My proposal is closest to (c). The protocol that I was talking about was a protocol for a peer to use when talking with a Rendezvous Server. It is a protocol that a node X, which wants to join some P2P SIP network N but doesn't know anyone currently in the network, can use to communicate with a Rendezvous Server and create a communication channel with some random peer P in the P2P SIP network. One could call it an "initial introduction protocol". Once node X can communicate with peer P, it can then learn about other peers in the P2P SIP network and fully join the overlay. This protocol is NOT a replacement for ICE. ICE is a protocol for creating a communication channel for the media stream between two phones. A P2P SIP system still needs ICE (or something equivalent). - Philip From huang-ming.pan at comcast.net Mon Jan 23 11:20:12 2006 From: huang-ming.pan at comcast.net (PP) Date: Mon, 23 Jan 2006 08:20:12 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG References: <84E5D7F15F52D34DA84C9C90ACE6554F62340E@0591-its-exmp01.us.saic.com> <8b2769930601230615i20433316y209186d7c6b34d0e@mail.gmail.com> Message-ID: <000b01c62038$e6e7b4c0$6400a8c0@ao.lop.com> Still very confused. When there are "explicit" supernodes and slimnodes, what are the difference and advantage of the p2p-sip system from contemporary well-deployed (ie. load balanced and redundant) client-server systems? Why would you think corporates, deployments of which are usually in small scale, will prefer a "client-server alike" p2p-sip system instead of Microsoft Live Communication Server (plus MSN IM) or any open SIP proxies (eg. Yahoo!IM, teltel, Xten, headcall, free world, ...) that not only provide free on-net calls but also provide off-net calls? I still think why quite a few people come together attracted by the wonderful p2p-sip initiative, seeing (:and envying:) great success and true advantages of Skype, is to look for a "standardize" solution in SIP industry that can compete with the proprietary giant. Certainly, should p2p-sip finally come out with a buffet that compiles to have 14+MB code and needs 22+MB at runtime, "it is clear the all features for all nodes behavior is" NOT "what we want" :) "Corporate", "Hierarchy", "Rendezvous", ... why make the thing so complicated? Please first come out with something compact and "simplex", the latter of which I always think to be the art of computer programming. peter ----- Original Message ----- From: "David A. Bryan" To: "Roy, Radhika R." Cc: "PP" ; "P2P-SIP" Sent: Monday, January 23, 2006 6:15 AM Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG I don't think I agree it is clear the all features for all nodes behavior is what we want, or that it is an issue that can be assumed desirable until we see need for different behaviors. I think it is open until we are clear what the services of a node are. For example, I don't think that is true if we have TURN type media relay as a service. I guess I had two points in my earlier email: 1) If we decide we want all nodes always equal it would need to be somehow explicit in the design, or in the end devices won't implement them all. If for example, we design a basic protocol for resource location and signalling, and one of those resource's a node can advertise is it is willing to be a media relay (this could be one way that nodes are defined as "slim" or "not slim" to use PP's terms), there is no way to enforce which nodes advertise they have the service and which don't. Any service we do decide should always be implemented must be part of the protocol. If we wanted relay, we would need to make it discovered in the protocol, not just advertised. 2) My second point was I can already see some cases -- the corporate deployments I mentioned in the last email being one -- where they may wish to control services like media relay. For managed deployments where P2P is a way for an organization to reduce capex and opex, as opposed to the Skype type-deployment, having different node types may be desirable. If we ignore it at this stage, we in effect decide implicitly by what we design. For me it isn't obvious yet that making every node have all capabilities is desirable for all the use cases I have seen. I think that both types of uses (managed/unmanaged) are interesting and should be kept in mind. --David On 1/22/06, Roy, Radhika R. wrote: > David and PP: > > Let me interject into this discussion. > > If we take the example of P2P-SIP, we see that this protocol will not > distinguish between UA and proxy as every peer will have all the > capabilities and may be termed as "peer Node" (instead of super-node, > slim-node, etc.). > > So, the idea of the p2p-SIP protocol development will be how a peer-node can > satisfy the needs for p2p communications without being subordinate of other > nodes. > > In the past, we have seen simple dump device like POTS in the PEST world, > client and sever communications protocol in the IP network, UA and Proxy > entities in the case of non-p2p-SIP protocol, and others. > > As you have seen that we are now taking the approach of the path to make SIP > protocol completely P2P. Definitely, it will have more functionalities as no > peer wants to be subordinate compare to others. > > Consequently, we have to develop the basic protocol that works as p2p-SIP > without assuming that some peer nodes will have super-node capabilities and > some are not. > > Once we develop the basic structure of the p2p-SIP protocol, we may then see > whether some kinds of hierarchical architecture of p2p configurations are > necessary or not, but definitely we MUST not bog down to this right now. > > Any comments? > > Best regards, > Radhika > > _____ > > From: p2p-sip-bounces at cs.columbia.edu on behalf of David A. Bryan > Sent: Sun 1/22/2006 6:12 PM > To: PP > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > The only way to 100% ensure this sort of behavior could be enforced is > if the protocol itself were somehow designed to require you be all of > the above when possible. If you can build your device to not be > anything but a "slim" peer, all the draft MUSTs in the world won't > keep vendor from making their phones slim if there is a market for > that. I'm not sure that designing the protocol that way is really a > path we want to go down, so not sure we will be able to enforce it. > > Back in the bad old days when file swapping was the only thing people > looked at P2P for, there were hacked versions of clients around that > always claimed the user had no files to share, and free loading phones > seem likely in the particular deployment scenario I think you are > talking about (global public network of devices, rather than say a > corporate P2P device network, where policy could be used to control > this). In the corporate environments, on the other hand, I can > actually imagine that some peers might be deliberately super-peers, > ensuring that traffic between offices, lets say, was done using one of > a specific set of nodes set up for this purpose, so the argument could > be made that at times, having "non-equal" nodes may be desirable. > > Of course it is possible that a particular overlay group in a global > public network of devices could devise some other policy mechanism for > this somehow, possibly with a distributed accounting mechanism. > > David > > From royrr at us.saic.com Mon Jan 23 11:31:23 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Mon, 23 Jan 2006 11:31:23 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F622C4E@0591-its-exmp01.us.saic.com> David: I understand your point. However, I think that the general principles for the p2p-SIP protocol will be as follows: 1. Base protocol will assume that all peers are equally capable. 2. If all peers are NOT equally capable, let us see which functionalities need to be available as a common denominator from p2p point of view. Then the separate protocol/service mechanisms need to be define for any functions that are not available in any peers (an analogy of this can be SIP Registrar, SIP proxy, SIP Redirect server functionalities that were NOT a part of SIP UA capabilities). However, these mechanisms still need to obey the principles of the p2p protocol. Kindly see more inline [RRR]. Best regards, Radhika -----Original Message----- From: davidbryan at gmail.com [mailto:davidbryan at gmail.com ] On Behalf Of David A. Bryan Sent: Monday, January 23, 2006 9:16 AM To: Roy, Radhika R. Cc: PP; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG I don't think I agree it is clear the all features for all nodes behavior is what we want, or that it is an issue that can be assumed desirable until we see need for different behaviors. I think it is open until we are clear what the services of a node are. For example, I don't think that is true if we have TURN type media relay as a service. [RRR] Kindly see the points that have been made as stated above. I believe that we can meet this requirement as well if we follow the above approach. I guess I had two points in my earlier email: 1) If we decide we want all nodes always equal it would need to be somehow explicit in the design, or in the end devices won't implement them all. If for example, we design a basic protocol for resource location and signalling, and one of those resource's a node can advertise is it is willing to be a media relay (this could be one way that nodes are defined as "slim" or "not slim" to use PP's terms), there is no way to enforce which nodes advertise they have the service and which don't. Any service we do decide should always be implemented must be part of the protocol. If we wanted relay, we would need to make it discovered in the protocol, not just advertised. [RRR] Agree, but still we need to be careful that the p2p protocol properties are maintained. 2) My second point was I can already see some cases -- the corporate deployments I mentioned in the last email being one -- where they may wish to control services like media relay. For managed deployments where P2P is a way for an organization to reduce capex and opex, as opposed to the Skype type-deployment, having different node types may be desirable. [RRR] Let us focus on p2p Public Internet first. Then, let us NOT worry now how we can meet the requirements of the limited view of the p2p-corporate schemes (it may be some especial cases or sub-sets of the p2p-public Internet). By the way, no matter we do in the IETF, the corporate folks will find their ways how to protect their interests (they may even create some forums to make some special standards). If we ignore it at this stage, we in effect decide implicitly by what we design. For me it isn't obvious yet that making every node have all capabilities is desirable for all the use cases I have seen. I think that both types of uses (managed/unmanaged) are interesting and should be kept in mind. [RRR] As clarified above, let us develop the base p2p-SIP protocol first with minimum common functionalities of all peers as indicated above. Then we will have to step back to see what other things that we need to do to make it real if anything is missing. Probably, we have to go forward step-by-step (may be a learning curve). My proposal will be as follows: Not to make the base p2p-SIP protocol a handicap just thinking some limited special implementations. --David On 1/22/06, Roy, Radhika R. wrote: > David and PP: > > Let me interject into this discussion. > > If we take the example of P2P-SIP, we see that this protocol will not > distinguish between UA and proxy as every peer will have all the > capabilities and may be termed as "peer Node" (instead of super-node, > slim-node, etc.). > > So, the idea of the p2p-SIP protocol development will be how a peer-node can > satisfy the needs for p2p communications without being subordinate of other > nodes. > > In the past, we have seen simple dump device like POTS in the PEST world, > client and sever communications protocol in the IP network, UA and Proxy > entities in the case of non-p2p-SIP protocol, and others. > > As you have seen that we are now taking the approach of the path to make SIP > protocol completely P2P. Definitely, it will have more functionalities as no > peer wants to be subordinate compare to others. > > Consequently, we have to develop the basic protocol that works as p2p-SIP > without assuming that some peer nodes will have super-node capabilities and > some are not. > > Once we develop the basic structure of the p2p-SIP protocol, we may then see > whether some kinds of hierarchical architecture of p2p configurations are > necessary or not, but definitely we MUST not bog down to this right now. > > Any comments? > > Best regards, > Radhika > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/141d61a6/attachment.html From dbarrett at quinthar.com Mon Jan 23 12:16:39 2006 From: dbarrett at quinthar.com (David Barrett) Date: Mon, 23 Jan 2006 09:16:39 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <20060123143929.71784.qmail@web33315.mail.mud.yahoo.com> Message-ID: <200601231716.k0NHGqKF008235@cs.columbia.edu> > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > [suresh] OK. However, several P2P applications that do not use SIP will > also > need NAT-penetration service. No doubt. But I'm afraid attempting to satisfy everyone by abstracting out a new, general purpose NAT-traversal algorithm might end up satisfying nobody. (ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't help.) Our primary audience is the SIP community, so we MUST satisfy them. We CAN satisfy others, but needn't. As such, I recommend we make SIP "just work" across NATs, and then encourage anyone who wants NAT traversal to use SIP (even if not a VoIP application). > [suresh] Your proposal sounds good. I do like it. This extends the SIP > protocol > and mandates the SIP proxy to be the rendezvous server. However, I am > uncomfortable with requiring that a SIP proxy (and only the SIP proxy) > should > support rendezvous service. > This is because Rendezvous service can be > quite > bandwidth intensive, especially as it supports TURN service. Thanks! But I'm sorry, I didn't mean to imply that. I think a rendezvous service can be offered by anyone, user agents and proxies alike. However, I would say that proxies MUST implement it, while user agents only SHOULD. > Rendezvous > service > may also be used by non-SIP applications. Again, it's my view that by trying to solve the general case for all applications, we risk not solving the specific case for any application. SIP is hard enough by itself (and has a large enough userbase) that a SIP-specific solution seems justified. The flip side of focusing on what's important is *not* focusing on what's *not* important. In my view -- which is only one of many -- SIP applications are important to the P2P-SIP group, and non-SIP applications are not important. Thus I think we should focus on SIP, and *not* focus on *non-SIP*. > As for eliminating ICE, I do believe, you will need additional connection > setup > mechanisms, even if they differ from ICE. For instance, the proposal needs > extensions to support relay service and TCP transport. Well, ICE, STUN, and TURN comprise hundreds of pages, while I've only given one -- I certainly agree even more could be accomplished with more pages. However, I do believe that the sum of all that functionality can be done in a much simpler fashion (in far less than hundreds of pages) by just leveraging the existing syntax and components of SIP rather than starting over from scratch. > [suresh] Well, NAT penetration is not easy. There are many P2P > applications > that seek NAT penetration. SIP based applications is one such group of > apps. True. But SIP is all that matters to me. We've had enough trouble trying to standardize VoIP around SIP; trying to further standardize all NAT-penetrating P2P apps around an entirely new protocol sounds like a hard problem that doesn't need solving right now. -david From royrr at us.saic.com Mon Jan 23 13:41:26 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Mon, 23 Jan 2006 13:41:26 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F622C4F@0591-its-exmp01.us.saic.com> David and Suresh: I agree with David that our focus should be p2p-SIP and hence we will work first how SIP can traverse FWs/NATs to provide VoIP services because p2p-SIP is also not a general purpose protocol. Best regards, Radhika -----Original Message----- From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-bounces at cs.columbia.edu ] On Behalf Of David Barrett Sent: Monday, January 23, 2006 12:17 PM To: Pyda Srisuresh; Philip Matthews; Dean Willis Cc: P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com ] > > [suresh] OK. However, several P2P applications that do not use SIP will > also > need NAT-penetration service. No doubt. But I'm afraid attempting to satisfy everyone by abstracting out a new, general purpose NAT-traversal algorithm might end up satisfying nobody. (ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't help.) Our primary audience is the SIP community, so we MUST satisfy them. We CAN satisfy others, but needn't. As such, I recommend we make SIP "just work" across NATs, and then encourage anyone who wants NAT traversal to use SIP (even if not a VoIP application). -david -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/5ef74849/attachment.html From dean.willis at softarmor.com Mon Jan 23 15:22:06 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 23 Jan 2006 14:22:06 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622C4F@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C4F@0591-its-exmp01.us.saic.com> Message-ID: If I may: 1) Getting SIP to work across NAT boundaries is not our problem here. It's a real problem, but one for another working group. 2) If we're not actually talking about the scope of the dra t charter, let;'s change the thread title, as this title is misleading. -- Dean On Jan 23, 2006, at 12:41 PM, Roy, Radhika R. wrote: > David and Suresh: > > I agree with David that our focus should be p2p-SIP and hence we > will work first how SIP can traverse FWs/NATs to provide VoIP > services because p2p-SIP is also not a general purpose protocol. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Monday, January 23, 2006 12:17 PM > To: Pyda Srisuresh; Philip Matthews; Dean Willis > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > > > > > [suresh] OK. However, several P2P applications that do not use > SIP will > > > also > > > need NAT-penetration service. > > No doubt. But I'm afraid attempting to satisfy everyone by > abstracting out > > a new, general purpose NAT-traversal algorithm might end up satisfying > > nobody. > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes > don't help.) > > Our primary audience is the SIP community, so we MUST satisfy > them. We CAN > > satisfy others, but needn't. As such, I recommend we make SIP > "just work" > > across NATs, and then encourage anyone who wants NAT traversal to > use SIP > > (even if not a VoIP application). > > > > -david > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From royrr at us.saic.com Mon Jan 23 15:35:14 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Mon, 23 Jan 2006 15:35:14 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F622C54@0591-its-exmp01.us.saic.com> It is now becoming confusing. People thought that p2p-SIP will address the FW/NAT crossing as well for VoIP services, and a lot of people spent energies discussing this. Is there any WG in the IETF that is working on solving problems using p2p model per se? Will the magic of p2p-SIP not work here? If not, why not? What are the items of the charter of p2p-SIP then? David, do you like to provide inputs on this? BR/Radhika -----Original Message----- From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com ] Sent: Monday, January 23, 2006 3:22 PM To: Roy, Radhika R. Cc: David Barrett; Pyda Srisuresh; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG If I may: 1) Getting SIP to work across NAT boundaries is not our problem here. It's a real problem, but one for another working group. 2) If we're not actually talking about the scope of the dra t charter, let;'s change the thread title, as this title is misleading. -- Dean On Jan 23, 2006, at 12:41 PM, Roy, Radhika R. wrote: > David and Suresh: > > I agree with David that our focus should be p2p-SIP and hence we > will work first how SIP can traverse FWs/NATs to provide VoIP > services because p2p-SIP is also not a general purpose protocol. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Monday, January 23, 2006 12:17 PM > To: Pyda Srisuresh; Philip Matthews; Dean Willis > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com ] > > > > > > [suresh] OK. However, several P2P applications that do not use > SIP will > > > also > > > need NAT-penetration service. > > No doubt. But I'm afraid attempting to satisfy everyone by > abstracting out > > a new, general purpose NAT-traversal algorithm might end up satisfying > > nobody. > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes > don't help.) > > Our primary audience is the SIP community, so we MUST satisfy > them. We CAN > > satisfy others, but needn't. As such, I recommend we make SIP > "just work" > > across NATs, and then encourage anyone who wants NAT traversal to > use SIP > > (even if not a VoIP application). > > > > -david -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/34584249/attachment-0001.html From srisuresh at yahoo.com Mon Jan 23 15:51:56 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Mon, 23 Jan 2006 12:51:56 -0800 (PST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622C4F@0591-its-exmp01.us.saic.com> Message-ID: <20060123205156.85568.qmail@web33313.mail.mud.yahoo.com> I understand. It is a reasonable approach. cheers, suresh --- "Roy, Radhika R." wrote: > David and Suresh: > > I agree with David that our focus should be p2p-SIP and hence we will work > first how SIP can traverse FWs/NATs to provide VoIP services because p2p-SIP > is also not a general purpose protocol. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu > ] On Behalf Of David Barrett > Sent: Monday, January 23, 2006 12:17 PM > To: Pyda Srisuresh; Philip Matthews; Dean Willis > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com > ] > > > > > > [suresh] OK. However, several P2P applications that do not use SIP will > > > also > > > need NAT-penetration service. > > No doubt. But I'm afraid attempting to satisfy everyone by abstracting out > > a new, general purpose NAT-traversal algorithm might end up satisfying > > nobody. > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't help.) > > Our primary audience is the SIP community, so we MUST satisfy them. We CAN > > satisfy others, but needn't. As such, I recommend we make SIP "just work" > > across NATs, and then encourage anyone who wants NAT traversal to use SIP > > (even if not a VoIP application). > > > > -david > > From slavitch at gmail.com Mon Jan 23 16:20:33 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Mon, 23 Jan 2006 16:20:33 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <20060123205156.85568.qmail@web33313.mail.mud.yahoo.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C4F@0591-its-exmp01.us.saic.com> <20060123205156.85568.qmail@web33313.mail.mud.yahoo.com> Message-ID: <1fc32c8f0601231320o5e0ea3fs@mail.gmail.com> If P2P SIP doesn't include methods for dealing with NAT traversal then P2P SIP is a pointless effort and best left to proprietary techniques led by commercial vendors, vendors that are actually interested in deploying real solutions in the real world. Whether it's native to the protocol or begged, borrowed or stolen from somewhere or something else doesn't matter, it just needs to be done and accounted for and a mandatory part of P2PSIP support. It has to just work for all implementations. It cannot be abstracted away. The SIP standardization community ignored NAT traversal partially due to a lingering ethic in the IETF that idealizes a so-called "end-to-end" world, and partially because "it wasn't in our mandate". We are still struggling with that that error, despite attempts to correct it with ICE, which in any event are still in development, not common deployment as a part of the protocol. After all these years the solution isn't firmly in place. It is finally part of the SIP mandate more as a patch and repair effort than an originating design. And that effort seems reluctant at best and not a top priority at all. If an effective solution is part of the P2P SIP mandate from day one the P2P SIP implementations will offer a distinct advantage over their classic SIP cousins, which will have to deal with a history of mistakes and balkanized implementations. Learn from the mistakes of the past. Passing the buck has had real negative impact, and P2P SIP cannot fall in that same trap. Regards Michael On 23/01/06, Pyda Srisuresh wrote: > > I understand. It is a reasonable approach. > > cheers, > suresh > > --- "Roy, Radhika R." wrote: > > > David and Suresh: > > > > I agree with David that our focus should be p2p-SIP and hence we will > work > > first how SIP can traverse FWs/NATs to provide VoIP services because > p2p-SIP > > is also not a general purpose protocol. > > > > Best regards, > > > > Radhika > > > > -----Original Message----- > > From: p2p-sip-bounces at cs.columbia.edu > > [mailto:p2p-sip-bounces at cs.columbia.edu > > ] On Behalf Of David Barrett > > Sent: Monday, January 23, 2006 12:17 PM > > To: Pyda Srisuresh; Philip Matthews; Dean Willis > > Cc: P2P-SIP > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > > -----Original Message----- > > > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com > > ] > > > > > > > > > > [suresh] OK. However, several P2P applications that do not use SIP > will > > > > > also > > > > > need NAT-penetration service. > > > > No doubt. But I'm afraid attempting to satisfy everyone by abstracting > out > > > > a new, general purpose NAT-traversal algorithm might end up satisfying > > > > nobody. > > > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't > help.) > > > > Our primary audience is the SIP community, so we MUST satisfy them. We > CAN > > > > satisfy others, but needn't. As such, I recommend we make SIP "just > work" > > > > across NATs, and then encourage anyone who wants NAT traversal to use > SIP > > > > (even if not a VoIP application). > > > > > > > > -david > > > > > > > > _______________________________________________ > 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/20060123/601cc465/attachment.html From royrr at us.saic.com Mon Jan 23 16:35:12 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Mon, 23 Jan 2006 16:35:12 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F622C59@0591-its-exmp01.us.saic.com> Michael: I agree with you because this is one of the magic that p2p-SIP is bringing on the table adding tremendous values. In fact, SIP implementations are faltering because of FW/NAT crossing problems. If the power of p2p-SIP is so great that it can solve the most complex problems of VoIP communications like FW/NAT crossing, why should we object to it instead of welcoming? Best regards, Radhika _____ From: Michael Slavitch [mailto:slavitch at gmail.com] Sent: Monday, January 23, 2006 4:21 PM To: Pyda Srisuresh Cc: Roy, Radhika R.; David Barrett; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG If P2P SIP doesn't include methods for dealing with NAT traversal then P2P SIP is a pointless effort and best left to proprietary techniques led by commercial vendors, vendors that are actually interested in deploying real solutions in the real world. Whether it's native to the protocol or begged, borrowed or stolen from somewhere or something else doesn't matter, it just needs to be done and accounted for and a mandatory part of P2PSIP support. It has to just work for all implementations. It cannot be abstracted away. The SIP standardization community ignored NAT traversal partially due to a lingering ethic in the IETF that idealizes a so-called "end-to-end" world, and partially because "it wasn't in our mandate". We are still struggling with that that error, despite attempts to correct it with ICE, which in any event are still in development, not common deployment as a part of the protocol. After all these years the solution isn't firmly in place. It is finally part of the SIP mandate more as a patch and repair effort than an originating design. And that effort seems reluctant at best and not a top priority at all. If an effective solution is part of the P2P SIP mandate from day one the P2P SIP implementations will offer a distinct advantage over their classic SIP cousins, which will have to deal with a history of mistakes and balkanized implementations. Learn from the mistakes of the past. Passing the buck has had real negative impact, and P2P SIP cannot fall in that same trap. Regards Michael On 23/01/06, Pyda Srisuresh > wrote: I understand. It is a reasonable approach. cheers, suresh --- "Roy, Radhika R." > wrote: > David and Suresh: > > I agree with David that our focus should be p2p-SIP and hence we will work > first how SIP can traverse FWs/NATs to provide VoIP services because p2p-SIP > is also not a general purpose protocol. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu > p2p-sip-bounces at cs.columbia.edu> ] On Behalf Of David Barrett > Sent: Monday, January 23, 2006 12:17 PM > To: Pyda Srisuresh; Philip Matthews; Dean Willis > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com > > ] > > > > > > [suresh] OK. However, several P2P applications that do not use SIP will > > > also > > > need NAT-penetration service. > > No doubt. But I'm afraid attempting to satisfy everyone by abstracting out > > a new, general purpose NAT-traversal algorithm might end up satisfying > > nobody. > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't help.) > > Our primary audience is the SIP community, so we MUST satisfy them. We CAN > > satisfy others, but needn't. As such, I recommend we make SIP "just work" > > across NATs, and then encourage anyone who wants NAT traversal to use SIP > > (even if not a VoIP application). > > > > -david > > _______________________________________________ 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/20060123/e904b714/attachment-0001.html From henry at pulver.com Mon Jan 23 18:44:27 2006 From: henry at pulver.com (Henry Sinnreich) Date: Mon, 23 Jan 2006 17:44:27 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622C54@0591-its-exmp01.us.saic.com> Message-ID: <200601232344.k0NNicKG011401@cs.columbia.edu> > Is there any WG in the IETF that is working on solving problems using p2p model per se? Excellent question! http://www.cs.umd.edu/projects/p2prg/ Thanks, Henry _____ From: Roy, Radhika R. [mailto:royrr at us.saic.com] Sent: Monday, January 23, 2006 2:35 PM To: dean.willis at softarmor.com Cc: P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG It is now becoming confusing. People thought that p2p-SIP will address the FW/NAT crossing as well for VoIP services, and a lot of people spent energies discussing this. Is there any WG in the IETF that is working on solving problems using p2p model per se? Will the magic of p2p-SIP not work here? If not, why not? What are the items of the charter of p2p-SIP then? David, do you like to provide inputs on this? BR/Radhika -----Original Message----- From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com] Sent: Monday, January 23, 2006 3:22 PM To: Roy, Radhika R. Cc: David Barrett; Pyda Srisuresh; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG If I may: 1) Getting SIP to work across NAT boundaries is not our problem here. It's a real problem, but one for another working group. 2) If we're not actually talking about the scope of the dra t charter, let;'s change the thread title, as this title is misleading. -- Dean On Jan 23, 2006, at 12:41 PM, Roy, Radhika R. wrote: > David and Suresh: > > I agree with David that our focus should be p2p-SIP and hence we > will work first how SIP can traverse FWs/NATs to provide VoIP > services because p2p-SIP is also not a general purpose protocol. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Monday, January 23, 2006 12:17 PM > To: Pyda Srisuresh; Philip Matthews; Dean Willis > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com] > > > > > > [suresh] OK. However, several P2P applications that do not use > SIP will > > > also > > > need NAT-penetration service. > > No doubt. But I'm afraid attempting to satisfy everyone by > abstracting out > > a new, general purpose NAT-traversal algorithm might end up satisfying > > nobody. > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes > don't help.) > > Our primary audience is the SIP community, so we MUST satisfy > them. We CAN > > satisfy others, but needn't. As such, I recommend we make SIP > "just work" > > across NATs, and then encourage anyone who wants NAT traversal to > use SIP > > (even if not a VoIP application). > > > > -david -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/98ee1b9c/attachment.html From royrr at us.saic.com Mon Jan 23 20:58:30 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Mon, 23 Jan 2006 20:58:30 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F623417@0591-its-exmp01.us.saic.com> We understand this that this p2p research group is addressing the problems of p2p "research" protocol in general and not targeted for any kinds of commercial works focusing only FW/NAT crossing for VoIP/SIP applications. They may NOT even look anything specific to SIP or VoIP. Thanks, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Henry Sinnreich Sent: Mon 1/23/2006 6:44 PM To: Roy, Radhika R.; dean.willis at softarmor.com Cc: P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > Is there any WG in the IETF that is working on solving problems using p2p model per se? Excellent question! http://www.cs.umd.edu/projects/p2prg/ Thanks, Henry _____ From: Roy, Radhika R. [mailto:royrr at us.saic.com] Sent: Monday, January 23, 2006 2:35 PM To: dean.willis at softarmor.com Cc: P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG It is now becoming confusing. People thought that p2p-SIP will address the FW/NAT crossing as well for VoIP services, and a lot of people spent energies discussing this. Is there any WG in the IETF that is working on solving problems using p2p model per se? Will the magic of p2p-SIP not work here? If not, why not? What are the items of the charter of p2p-SIP then? David, do you like to provide inputs on this? BR/Radhika -----Original Message----- From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com ] Sent: Monday, January 23, 2006 3:22 PM To: Roy, Radhika R. Cc: David Barrett; Pyda Srisuresh; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG If I may: 1) Getting SIP to work across NAT boundaries is not our problem here. It's a real problem, but one for another working group. 2) If we're not actually talking about the scope of the dra t charter, let;'s change the thread title, as this title is misleading. -- Dean On Jan 23, 2006, at 12:41 PM, Roy, Radhika R. wrote: > David and Suresh: > > I agree with David that our focus should be p2p-SIP and hence we > will work first how SIP can traverse FWs/NATs to provide VoIP > services because p2p-SIP is also not a general purpose protocol. > > Best regards, > > Radhika > > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- > bounces at cs.columbia.edu] On Behalf Of David Barrett > Sent: Monday, January 23, 2006 12:17 PM > To: Pyda Srisuresh; Philip Matthews; Dean Willis > Cc: P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > -----Original Message----- > > > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com ] > > > > > > [suresh] OK. However, several P2P applications that do not use > SIP will > > > also > > > need NAT-penetration service. > > No doubt. But I'm afraid attempting to satisfy everyone by > abstracting out > > a new, general purpose NAT-traversal algorithm might end up satisfying > > nobody. > > (ie, if everyone has either size 4 or size 8 feet, size 6 shoes > don't help.) > > Our primary audience is the SIP community, so we MUST satisfy > them. We CAN > > satisfy others, but needn't. As such, I recommend we make SIP > "just work" > > across NATs, and then encourage anyone who wants NAT traversal to > use SIP > > (even if not a VoIP application). > > > > -david From dean.willis at softarmor.com Tue Jan 24 00:00:53 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 23 Jan 2006 23:00:53 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622C54@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C54@0591-its-exmp01.us.saic.com> Message-ID: On Jan 23, 2006, at 2:35 PM, Roy, Radhika R. wrote: > It is now becoming confusing. > > People thought that p2p-SIP will address the FW/NAT crossing as > well for VoIP services, and a lot of people spent energies > discussing this. Is there any WG in the IETF that is working on > solving problems using p2p model per se? > Will the magic of p2p-SIP not work here? If not, why not? What magic are you talking about? > What are the items of the charter of p2p-SIP then? David, do you > like to provide inputs on this? If there's something special that''s needed to get the "P2P aspects" of what we're doing (insertion into a P2P "cloud" or discovery of a correspondent from a P2p "cloud") across a NAT boundary, I think that's within our scope. Using P2P techniques for correspondent and resource discovery to specifically discover the resources like NAT and STUN servers that allow us to get SIP across a NAT is within scope. But OTHER WORKING GROUPS are responsible for defining mechanisms to get SIP across NATs. I don't believe changing the way SIP crosses NAT boundaries is within our scope. And solving the NAT problem in a general way is CLEARLY outside the scope of a "P2P-SIP" group. -- Dean From dean.willis at softarmor.com Tue Jan 24 00:06:11 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 23 Jan 2006 23:06:11 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601231320o5e0ea3fs@mail.gmail.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C4F@0591-its-exmp01.us.saic.com> <20060123205156.85568.qmail@web33313.mail.mud.yahoo.com> <1fc32c8f0601231320o5e0ea3fs@mail.gmail.com> Message-ID: <301F9A5A-D028-41F7-89ED-FF7D79F5AC34@softarmor.com> On Jan 23, 2006, at 3:20 PM, Michael Slavitch wrote: > If P2P SIP doesn't include methods for dealing with NAT traversal > then P2P SIP is a pointless effort and best left to proprietary > techniques led by commercial vendors, vendors that are actually > interested in deploying real solutions in the real world. > If you're interested in defining solutions that can't be deployed in the real world, then you need to do that work in something besides an IETF working group. The IETF is NOT a research organization. > Whether it's native to the protocol or begged, borrowed or stolen > from somewhere or something else doesn't matter, it just needs to > be done and accounted for and a mandatory part of P2PSIP support. > It has to just work for all implementations. It cannot be > abstracted away. I expect P2P-SIP to work when some or all of its nodes are behind NATs. This is NOT the same thing as inventing a new way to get SIP across NATS. We already AHVE ways to get SIP across NATs, and those are defined in other working groups. > The SIP standardization community ignored NAT traversal partially > due to a lingering ethic in the IETF that idealizes a so-called > "end-to-end" world, and partially because "it wasn't in our > mandate". We are still struggling with that that error, despite > attempts to correct it with ICE, which in any event are still in > development, not common deployment as a part of the protocol. After > all these years the solution isn't firmly in place. > I don't disagree. > It is finally part of the SIP mandate more as a patch and repair > effort than an originating design. And that effort seems reluctant > at best and not a top priority at all. > Arguable. > > If an effective solution is part of the P2P SIP mandate from day > one the P2P SIP implementations will offer a distinct advantage > over their classic SIP cousins, which will have to deal with a > history of mistakes and balkanized implementations. > > Learn from the mistakes of the past. Passing the buck has had real > negative impact, and P2P SIP cannot fall in that same trap. So make it work using the mechanisms available. If we really CAN'T make it work using those mechanisms, then we need to push new requirements into the other working groups that are or will be chartered to do that work. We need to stop trying to boil the entire ocean of everything that might possibly be done in a new and exciting way using P2P techniques and concentrate on a tightly-scoped set of deliverables if we want to have an IETF working group. -- Dean From dean.willis at softarmor.com Tue Jan 24 00:18:42 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 23 Jan 2006 23:18:42 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622C59@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C59@0591-its-exmp01.us.saic.com> Message-ID: <172FC5F5-4701-4BA9-B577-9B950B8070CF@softarmor.com> On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > Michael: > > > > I agree with you because this is one of the magic that p2p-SIP is > bringing on the table adding tremendous values. In fact, SIP > implementations are faltering because of FW/NAT crossing problems. > > > > If the power of p2p-SIP is so great that it can solve the most > complex problems of VoIP communications like FW/NAT crossing, why > should we object to it instead of welcoming? > > Radhika, Peer to peer techniques have no "magic" way of making NATs an easy-to- solve problem. NATs are ugly, complex, nasty, and highly differentiated beasties, and there are myriad techniques for getting across different sorts of NATs. P2P-SIP is about enabling P2P-SIP nodes to find and communicate with other P2P-SIP nodes. We know that some of these nodes will be behind NATs. We know that if ALL nodes are behind unique NATs (including the "rendezvous function or server"), then there is no known solution to be had using P2P techniques. That said, we need to be able to answer a couple of questions in order to get things talking. We hope that P2P techniques will give us a better way to answer these questions than client-server techniques didm but they're pretty much the same question. These include: 1) Where shall I send an offer in order to reach my correspondent, and how can the response to that offer reach me? 2) How can I inform my potential correspondents as to where they should send offers if they want to reach me? 3) If I or my correspondent is behind a particularly nasty relay element (firewall, NAT, etc.), what intermediate shall I use to attempt to reach (or be made reachable to) my correspondent, and how shall I communicate with that correspondent? Are there intermediate nodes that I can solicit for assistance with this task? Notice that all of these questions fall roughly into the category of "resource discovery". -- Dean From royrr at us.saic.com Tue Jan 24 08:34:57 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Tue, 24 Jan 2006 08:34:57 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic.com> Dean: I think that the way you framed your reply seems to be that we are in agreement from the broader context. Couple of things are as follows: 1. We are looking for p2p context of FW/NAT crossing by SIP. No other IETF WGs are doing this work. The research p2p WG is doing p2p works, but they are not focused for FW/NAT crossing by SIP per se, and, moreover, p2p-SIP is looking for commercial solutions, NOT for any research works. 2. People are proposing solutions for FW/NAT crossing using p2p-SIP protocol. Some drafts are already there. So, let us work on those drafts and/or proposals. 3. P2P-SIP WG should be open to all proposals that help SIP to solve all problems in p2p mode. So, the focus should be p2p, not any non-p2p aspects of solutions because our charter is to make p2p-SIP protocol in the context of the p2p public Internet. So, let us be OPEN to all suggestions for p2p-SIP without limiting that some items are here or some items are other groups. For example, even people may say items like "discovery," "registrar," "proxy," or other services also do NOT belong to p2p-SIP. Hope this helps. Best regards, Radhika -----Original Message----- From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com ] Sent: Tuesday, January 24, 2006 12:19 AM To: Roy, Radhika R. Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > Michael: > > > > I agree with you because this is one of the magic that p2p-SIP is > bringing on the table adding tremendous values. In fact, SIP > implementations are faltering because of FW/NAT crossing problems. > > > > If the power of p2p-SIP is so great that it can solve the most > complex problems of VoIP communications like FW/NAT crossing, why > should we object to it instead of welcoming? > > Radhika, Peer to peer techniques have no "magic" way of making NATs an easy-to- solve problem. NATs are ugly, complex, nasty, and highly differentiated beasties, and there are myriad techniques for getting across different sorts of NATs. P2P-SIP is about enabling P2P-SIP nodes to find and communicate with other P2P-SIP nodes. We know that some of these nodes will be behind NATs. We know that if ALL nodes are behind unique NATs (including the "rendezvous function or server"), then there is no known solution to be had using P2P techniques. That said, we need to be able to answer a couple of questions in order to get things talking. We hope that P2P techniques will give us a better way to answer these questions than client-server techniques didm but they're pretty much the same question. These include: 1) Where shall I send an offer in order to reach my correspondent, and how can the response to that offer reach me? 2) How can I inform my potential correspondents as to where they should send offers if they want to reach me? 3) If I or my correspondent is behind a particularly nasty relay element (firewall, NAT, etc.), what intermediate shall I use to attempt to reach (or be made reachable to) my correspondent, and how shall I communicate with that correspondent? Are there intermediate nodes that I can solicit for assistance with this task? Notice that all of these questions fall roughly into the category of "resource discovery". -- Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060124/534fd5ef/attachment.html From slavitch at gmail.com Tue Jan 24 11:11:11 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Tue, 24 Jan 2006 11:11:11 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic.com> Message-ID: <1fc32c8f0601240811k1567c980q@mail.gmail.com> Dean, Roy, et al. I agree. Let us beg, borrow and steal the methods that exist. Does ICE yet exist other than in continually changing draft development form? It has been in development for several years now and in my opinion there is some lack of urgency in coming to a finalized solution, although Microsoft's announced support may ultimately give ICE the kick in the pants that is needed. If that is the case P2P SIP should get on the ICE bandwagon, at least for media sessions. But what if ICE languishes? What then? Do we wait for an external dependency or do we pick up our socks and run with it and perhaps use something else? And good points on resource discovery. IMHO not only should resource discovery exist, it should be largely automatic and the services should be self-advertising, without requiring (but certainly not excluding) centralized configuration, registrars, or rules. On 24/01/06, Roy, Radhika R. wrote: > > Dean: > > I think that the way you framed your reply seems to be that we are in > agreement from the broader context. > > Couple of things are as follows: > > 1. We are looking for p2p context of FW/NAT crossing by SIP. No other > IETF WGs are doing this work. The research p2p WG is doing p2p works, but > they are not focused for FW/NAT crossing by SIP per se, and, moreover, > p2p-SIP is looking for commercial solutions, NOT for any research works. > > 2. People are proposing solutions for FW/NAT crossing using p2p-SIP > protocol. Some drafts are already there. So, let us work on those drafts > and/or proposals. > > 3. P2P-SIP WG should be open to all proposals that help SIP to solve > all problems in p2p mode. So, the focus should be p2p, not any non-p2p > aspects of solutions because our charter is to make p2p-SIP protocol in the > context of the p2p public Internet. > > So, let us be OPEN to all suggestions for p2p-SIP without limiting thatsome items are here or some items are other groups. For example, even people > may say items like "discovery," "registrar," "proxy," or other services > also do NOT belong to p2p-SIP. > > Hope this helps. > > Best regards, > > Radhika > > -----Original Message----- > From: dean.willis at softarmor.com [mailto:dean.willis at softarmor.com > ] > Sent: Tuesday, January 24, 2006 12:19 AM > To: Roy, Radhika R. > Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > > > Michael: > > > > > > > > > > > > I agree with you because this is one of the magic that p2p-SIP is > > > bringing on the table adding tremendous values. In fact, SIP > > > implementations are faltering because of FW/NAT crossing problems. > > > > > > > > > > > > If the power of p2p-SIP is so great that it can solve the most > > > complex problems of VoIP communications like FW/NAT crossing, why > > > should we object to it instead of welcoming? > > > > > > > > Radhika, > > Peer to peer techniques have no "magic" way of making NATs an easy-to- > > solve problem. NATs are ugly, complex, nasty, and highly > > differentiated beasties, and there are myriad techniques for getting > > across different sorts of NATs. > > P2P-SIP is about enabling P2P-SIP nodes to find and communicate with > > other P2P-SIP nodes. We know that some of these nodes will be behind > > NATs. We know that if ALL nodes are behind unique NATs (including the > > "rendezvous function or server"), then there is no known solution to > > be had using P2P techniques. > > That said, we need to be able to answer a couple of questions in > > order to get things talking. We hope that P2P techniques will give us > > a better way to answer these questions than client-server techniques > > didm but they're pretty much the same question. > > These include: > > 1) Where shall I send an offer in order to reach my correspondent, > > and how can the response to that offer reach me? > > 2) How can I inform my potential correspondents as to where they > > should send offers if they want to reach me? > > 3) If I or my correspondent is behind a particularly nasty relay > > element (firewall, NAT, etc.), what intermediate shall I use to > > attempt to reach (or be made reachable to) my correspondent, and how > > shall I communicate with that correspondent? Are there intermediate > > nodes that I can solicit for assistance with this task? > > Notice that all of these questions fall roughly into the category of > > "resource discovery". > > -- > > Dean > > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060124/ba5a17cb/attachment-0001.html From jose at netlab.hut.fi Tue Jan 24 11:41:50 2006 From: jose at netlab.hut.fi (jose@netlab.hut.fi) Date: Tue, 24 Jan 2006 18:41:50 +0200 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601240811k1567c980q@mail.gmail.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic.com> <1fc32c8f0601240811k1567c980q@mail.gmail.com> Message-ID: <1138120910.43d658ce588ce@www.netlab.hut.fi> Hello, I tend to agree with the statement of taking existing mechanisms for NAT-FW, etc but IMO as already stated the critical issue for the P2P SIP is the resource discovery. We need to find where are the SIP entities, either Registrar, Proxy or the UAs if any, we might also want to know where are the DNS server if we want to use the URI of the SIP endpoint, etc. For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the resource discovery has to be done automatically and in a scalable manner with and without centralised support. Therefore, the resource discovery would be one of the corner stones in the proposed P2P SIP architecture. Rgds Jose IMO the critical issue is on the resource discovery > Dean, Roy, et al. > > I agree. Let us beg, borrow and steal the methods that exist. Does ICE yet > exist other than in continually changing draft development form? It has > been in development for several years now and in my opinion there is some > lack of urgency in coming to a finalized solution, although Microsoft's > announced support may ultimately give ICE the kick in the pants that is > needed. If that is the case P2P SIP should get on the ICE bandwagon, at > least for media sessions. But what if ICE languishes? What then? Do we > wait for an external dependency or do we pick up our socks and run with it > and perhaps use something else? > > And good points on resource discovery. IMHO not only should resource > discovery exist, it should be largely automatic and the services should be > self-advertising, without requiring (but certainly not excluding) > centralized configuration, registrars, or rules. > > > > > > On 24/01/06, Roy, Radhika R. wrote: > > > > Dean: > > > > I think that the way you framed your reply seems to be that we are in > > agreement from the broader context. > > > > Couple of things are as follows: > > > > 1. We are looking for p2p context of FW/NAT crossing by SIP. No other > > IETF WGs are doing this work. The research p2p WG is doing p2p works, but > > they are not focused for FW/NAT crossing by SIP per se, and, moreover, > > p2p-SIP is looking for commercial solutions, NOT for any research works. > > > > 2. People are proposing solutions for FW/NAT crossing using p2p-SIP > > protocol. Some drafts are already there. So, let us work on those drafts > > and/or proposals. > > > > 3. P2P-SIP WG should be open to all proposals that help SIP to solve > > all problems in p2p mode. So, the focus should be p2p, not any non-p2p > > aspects of solutions because our charter is to make p2p-SIP protocol in the > > context of the p2p public Internet. > > > > So, let us be OPEN to all suggestions for p2p-SIP without limiting thatsome > items are here or some items are other groups. For example, even people > > may say items like "discovery," "registrar," "proxy," or other services > > also do NOT belong to p2p-SIP. > > > > Hope this helps. > > > > Best regards, > > > > Radhika > > > > -----Original Message----- > > From: dean.willis at softarmor.com > [mailto:dean.willis at softarmor.com > > ] > > Sent: Tuesday, January 24, 2006 12:19 AM > > To: Roy, Radhika R. > > Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > > > > > Michael: > > > > > > > > > > > > > > > > > > > > I agree with you because this is one of the magic that p2p-SIP is > > > > > bringing on the table adding tremendous values. In fact, SIP > > > > > implementations are faltering because of FW/NAT crossing problems. > > > > > > > > > > > > > > > > > > > > If the power of p2p-SIP is so great that it can solve the most > > > > > complex problems of VoIP communications like FW/NAT crossing, why > > > > > should we object to it instead of welcoming? > > > > > > > > > > > > > > Radhika, > > > > Peer to peer techniques have no "magic" way of making NATs an easy-to- > > > > solve problem. NATs are ugly, complex, nasty, and highly > > > > differentiated beasties, and there are myriad techniques for getting > > > > across different sorts of NATs. > > > > P2P-SIP is about enabling P2P-SIP nodes to find and communicate with > > > > other P2P-SIP nodes. We know that some of these nodes will be behind > > > > NATs. We know that if ALL nodes are behind unique NATs (including the > > > > "rendezvous function or server"), then there is no known solution to > > > > be had using P2P techniques. > > > > That said, we need to be able to answer a couple of questions in > > > > order to get things talking. We hope that P2P techniques will give us > > > > a better way to answer these questions than client-server techniques > > > > didm but they're pretty much the same question. > > > > These include: > > > > 1) Where shall I send an offer in order to reach my correspondent, > > > > and how can the response to that offer reach me? > > > > 2) How can I inform my potential correspondents as to where they > > > > should send offers if they want to reach me? > > > > 3) If I or my correspondent is behind a particularly nasty relay > > > > element (firewall, NAT, etc.), what intermediate shall I use to > > > > attempt to reach (or be made reachable to) my correspondent, and how > > > > shall I communicate with that correspondent? Are there intermediate > > > > nodes that I can solicit for assistance with this task? > > > > Notice that all of these questions fall roughly into the category of > > > > "resource discovery". > > > > -- > > > > Dean > > > > > > > -- > Michael Slavitch > Ottawa, Ontario Canada > From henry at pulver.com Tue Jan 24 12:12:17 2006 From: henry at pulver.com (Henry Sinnreich) Date: Tue, 24 Jan 2006 11:12:17 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1138120910.43d658ce588ce@www.netlab.hut.fi> Message-ID: <200601241712.k0OHCJKG021465@cs.columbia.edu> Folks, Just in case you may not have read previous emails: Right now, please focus ONLY on making the BOF! Unless we get an approved plan for the BOF, all technical discussions are in vain. There will be plenty opportunity to discuss P2P technical topics AFTER the WG has been approved. Thanks, Henry -----Original Message----- From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] Sent: Tuesday, January 24, 2006 10:42 AM To: Michael Slavitch Cc: Roy, Radhika R.; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG Hello, I tend to agree with the statement of taking existing mechanisms for NAT-FW, etc but IMO as already stated the critical issue for the P2P SIP is the resource discovery. We need to find where are the SIP entities, either Registrar, Proxy or the UAs if any, we might also want to know where are the DNS server if we want to use the URI of the SIP endpoint, etc. For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the resource discovery has to be done automatically and in a scalable manner with and without centralised support. Therefore, the resource discovery would be one of the corner stones in the proposed P2P SIP architecture. Rgds Jose IMO the critical issue is on the resource discovery > Dean, Roy, et al. > > I agree. Let us beg, borrow and steal the methods that exist. Does ICE yet > exist other than in continually changing draft development form? It has > been in development for several years now and in my opinion there is some > lack of urgency in coming to a finalized solution, although Microsoft's > announced support may ultimately give ICE the kick in the pants that is > needed. If that is the case P2P SIP should get on the ICE bandwagon, at > least for media sessions. But what if ICE languishes? What then? Do we > wait for an external dependency or do we pick up our socks and run with it > and perhaps use something else? > > And good points on resource discovery. IMHO not only should resource > discovery exist, it should be largely automatic and the services should be > self-advertising, without requiring (but certainly not excluding) > centralized configuration, registrars, or rules. > > > > > > On 24/01/06, Roy, Radhika R. wrote: > > > > Dean: > > > > I think that the way you framed your reply seems to be that we are in > > agreement from the broader context. > > > > Couple of things are as follows: > > > > 1. We are looking for p2p context of FW/NAT crossing by SIP. No other > > IETF WGs are doing this work. The research p2p WG is doing p2p works, but > > they are not focused for FW/NAT crossing by SIP per se, and, moreover, > > p2p-SIP is looking for commercial solutions, NOT for any research works. > > > > 2. People are proposing solutions for FW/NAT crossing using p2p-SIP > > protocol. Some drafts are already there. So, let us work on those drafts > > and/or proposals. > > > > 3. P2P-SIP WG should be open to all proposals that help SIP to solve > > all problems in p2p mode. So, the focus should be p2p, not any non-p2p > > aspects of solutions because our charter is to make p2p-SIP protocol in the > > context of the p2p public Internet. > > > > So, let us be OPEN to all suggestions for p2p-SIP without limiting thatsome > items are here or some items are other groups. For example, even people > > may say items like "discovery," "registrar," "proxy," or other services > > also do NOT belong to p2p-SIP. > > > > Hope this helps. > > > > Best regards, > > > > Radhika > > > > -----Original Message----- > > From: dean.willis at softarmor.com > [mailto:dean.willis at softarmor.com > > ] > > Sent: Tuesday, January 24, 2006 12:19 AM > > To: Roy, Radhika R. > > Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP > > Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > > > > > Michael: > > > > > > > > > > > > > > > > > > > > I agree with you because this is one of the magic that p2p-SIP is > > > > > bringing on the table adding tremendous values. In fact, SIP > > > > > implementations are faltering because of FW/NAT crossing problems. > > > > > > > > > > > > > > > > > > > > If the power of p2p-SIP is so great that it can solve the most > > > > > complex problems of VoIP communications like FW/NAT crossing, why > > > > > should we object to it instead of welcoming? > > > > > > > > > > > > > > Radhika, > > > > Peer to peer techniques have no "magic" way of making NATs an easy-to- > > > > solve problem. NATs are ugly, complex, nasty, and highly > > > > differentiated beasties, and there are myriad techniques for getting > > > > across different sorts of NATs. > > > > P2P-SIP is about enabling P2P-SIP nodes to find and communicate with > > > > other P2P-SIP nodes. We know that some of these nodes will be behind > > > > NATs. We know that if ALL nodes are behind unique NATs (including the > > > > "rendezvous function or server"), then there is no known solution to > > > > be had using P2P techniques. > > > > That said, we need to be able to answer a couple of questions in > > > > order to get things talking. We hope that P2P techniques will give us > > > > a better way to answer these questions than client-server techniques > > > > didm but they're pretty much the same question. > > > > These include: > > > > 1) Where shall I send an offer in order to reach my correspondent, > > > > and how can the response to that offer reach me? > > > > 2) How can I inform my potential correspondents as to where they > > > > should send offers if they want to reach me? > > > > 3) If I or my correspondent is behind a particularly nasty relay > > > > element (firewall, NAT, etc.), what intermediate shall I use to > > > > attempt to reach (or be made reachable to) my correspondent, and how > > > > shall I communicate with that correspondent? Are there intermediate > > > > nodes that I can solicit for assistance with this task? > > > > Notice that all of these questions fall roughly into the category of > > > > "resource discovery". > > > > -- > > > > Dean > > > > > > > -- > Michael Slavitch > Ottawa, Ontario Canada > From enrico.marocco at TILAB.COM Tue Jan 24 12:17:48 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Tue, 24 Jan 2006 18:17:48 +0100 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601240811k1567c980q@mail.gmail.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic.com> <1fc32c8f0601240811k1567c980q@mail.gmail.com> Message-ID: <43D6613C.7060205@tilab.com> Michael Slavitch wrote: > I agree. Let us beg, borrow and steal the methods that exist. Does ICE > yet exist other than in continually changing draft development form? It > has been in development for several years now and in my opinion there is > some lack of urgency in coming to a finalized solution, although > Microsoft's announced support may ultimately give ICE the kick in the > pants that is needed. If that is the case P2P SIP should get on the ICE > bandwagon, at least for media sessions. But what if ICE languishes? > What then? Do we wait for an external dependency or do we pick up our > socks and run with it and perhaps use something else? If "something else" means "something we'll build", the latter doesn't reconcile with the last phrase of the draft charter: "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." Since without such statement the charter wouldn't be accepted, we MUST look for solutions for hindrance avoidance and multiparty media session control in behave and mmusic IETF working groups. Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From eunsoo at research.panasonic.com Tue Jan 24 12:44:18 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 24 Jan 2006 12:44:18 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <200601241712.k0OHCJKG021465@cs.columbia.edu> References: <200601241712.k0OHCJKG021465@cs.columbia.edu> Message-ID: <43D66772.9070200@research.panasonic.com> Henry made an important point. What we need to talk about urgently is whether the proposed charter is fine and, if not, what should be improved and how. Thanks. Eunsoo Henry Sinnreich wrote: >Folks, > >Just in case you may not have read previous emails: > >Right now, please focus ONLY on making the BOF! > >Unless we get an approved plan for the BOF, all technical discussions are in >vain. There will be plenty opportunity to discuss P2P technical topics AFTER >the WG has been approved. > >Thanks, Henry > > > >-----Original Message----- >From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] >Sent: Tuesday, January 24, 2006 10:42 AM >To: Michael Slavitch >Cc: Roy, Radhika R.; P2P-SIP >Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > >Hello, > >I tend to agree with the statement of taking existing mechanisms for NAT-FW, >etc >but IMO as already stated the critical issue for the P2P SIP is the resource >discovery. We need to find where are the SIP entities, either Registrar, >Proxy >or the UAs if any, we might also want to know where are the DNS server if we >want to use the URI of the SIP endpoint, etc. > >For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the >resource discovery has to be done automatically and in a scalable manner >with >and without centralised support. > >Therefore, the resource discovery would be one of the corner stones in the >proposed P2P SIP architecture. >Rgds >Jose > >IMO the critical issue is on the resource discovery > > >>Dean, Roy, et al. >> >>I agree. Let us beg, borrow and steal the methods that exist. Does ICE >> >> >yet > > >>exist other than in continually changing draft development form? It has >>been in development for several years now and in my opinion there is some >>lack of urgency in coming to a finalized solution, although Microsoft's >>announced support may ultimately give ICE the kick in the pants that is >>needed. If that is the case P2P SIP should get on the ICE bandwagon, at >>least for media sessions. But what if ICE languishes? What then? Do we >>wait for an external dependency or do we pick up our socks and run with it >>and perhaps use something else? >> >>And good points on resource discovery. IMHO not only should resource >>discovery exist, it should be largely automatic and the services should be >>self-advertising, without requiring (but certainly not excluding) >>centralized configuration, registrars, or rules. >> >> >> >> >> >>On 24/01/06, Roy, Radhika R. wrote: >> >> >>>Dean: >>> >>>I think that the way you framed your reply seems to be that we are in >>>agreement from the broader context. >>> >>>Couple of things are as follows: >>> >>>1. We are looking for p2p context of FW/NAT crossing by SIP. No >>> >>> >other > > >>>IETF WGs are doing this work. The research p2p WG is doing p2p works, >>> >>> >but > > >>>they are not focused for FW/NAT crossing by SIP per se, and, moreover, >>>p2p-SIP is looking for commercial solutions, NOT for any research works. >>> >>>2. People are proposing solutions for FW/NAT crossing using p2p-SIP >>>protocol. Some drafts are already there. So, let us work on those drafts >>>and/or proposals. >>> >>>3. P2P-SIP WG should be open to all proposals that help SIP to >>> >>> >solve > > >>>all problems in p2p mode. So, the focus should be p2p, not any non-p2p >>>aspects of solutions because our charter is to make p2p-SIP protocol in >>> >>> >the > > >>>context of the p2p public Internet. >>> >>>So, let us be OPEN to all suggestions for p2p-SIP without limiting >>> >>> >thatsome > > >>items are here or some items are other groups. For example, even people >> >> >>>may say items like "discovery," "registrar," "proxy," or other services >>>also do NOT belong to p2p-SIP. >>> >>>Hope this helps. >>> >>>Best regards, >>> >>>Radhika >>> >>>-----Original Message----- >>>From: dean.willis at softarmor.com >>> >>> >>[mailto:dean.willis at softarmor.com >> >> >>>] >>>Sent: Tuesday, January 24, 2006 12:19 AM >>>To: Roy, Radhika R. >>>Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP >>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG >>> >>>On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: >>> >>> >>> >>>>Michael: >>>> >>>> >>>>I agree with you because this is one of the magic that p2p-SIP is >>>> >>>> >>>>bringing on the table adding tremendous values. In fact, SIP >>>> >>>> >>>>implementations are faltering because of FW/NAT crossing problems. >>>> >>>> >>>>If the power of p2p-SIP is so great that it can solve the most >>>> >>>> >>>>complex problems of VoIP communications like FW/NAT crossing, why >>>> >>>> >>>>should we object to it instead of welcoming? >>>> >>>> >>>Radhika, >>> >>>Peer to peer techniques have no "magic" way of making NATs an easy-to- >>> >>>solve problem. NATs are ugly, complex, nasty, and highly >>> >>>differentiated beasties, and there are myriad techniques for getting >>> >>>across different sorts of NATs. >>> >>>P2P-SIP is about enabling P2P-SIP nodes to find and communicate with >>> >>>other P2P-SIP nodes. We know that some of these nodes will be behind >>> >>>NATs. We know that if ALL nodes are behind unique NATs (including the >>> >>>"rendezvous function or server"), then there is no known solution to >>> >>>be had using P2P techniques. >>> >>>That said, we need to be able to answer a couple of questions in >>> >>>order to get things talking. We hope that P2P techniques will give us >>> >>>a better way to answer these questions than client-server techniques >>> >>>didm but they're pretty much the same question. >>> >>>These include: >>> >>>1) Where shall I send an offer in order to reach my correspondent, >>> >>>and how can the response to that offer reach me? >>> >>>2) How can I inform my potential correspondents as to where they >>> >>>should send offers if they want to reach me? >>> >>>3) If I or my correspondent is behind a particularly nasty relay >>> >>>element (firewall, NAT, etc.), what intermediate shall I use to >>> >>>attempt to reach (or be made reachable to) my correspondent, and how >>> >>>shall I communicate with that correspondent? Are there intermediate >>> >>>nodes that I can solicit for assistance with this task? >>> >>>Notice that all of these questions fall roughly into the category of >>> >>>"resource discovery". >>> >>>-- >>> >>>Dean >>> >>> >>> >>> >>-- >>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 Tue Jan 24 17:01:21 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Tue, 24 Jan 2006 17:01:21 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43D6613C.7060205@tilab.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic.com> <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6613C.7060205@tilab.com> Message-ID: <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> You state that we MUST refer to BEHAVE and MMUSIC to provide a solution for hindrance avoidance and multiparty media sessions. That is true. I fully agree. The corollary of this statement is that it is incumbent on BEHAVE and MMUSIC to provide a solution that is reasonable and effective for P2PSIP and to do so in a timely manner. This places an onus on these groups to deliver an answer, otherwise there is a disconnect that has much larger implications. Solutions must be finalized and finalized promptly. If BEHAVE and MMUSIC has a solution in place that meets the needs of P2PSIP by all means use it. As of today it does not. Proposed solutions exist in Internet-Draft form only. They are still in development. Given that, what does P2PSIP working group do if there is no solution firmly in place? Do we wait? How long? More to the point, what does the P2PSIP community do? Can it wait? How long? The question that arises is "Can the P2PSIP WG go forward and meet its stated goals when there is no NAT traversal solution firmly in place?" My answer to that would be a firm no, because the lack of a solution influences the resulting activities of the working group. I argue that such solutions must be fully defined and in be place as a core competency of P2PSIP communications. If these solutions are not in place by a certain date the goals and milestones of the P2PSIP working group cannot be fully met, as a huge protocol hole exists, one that can't be waved away as a "not my department" issue. This means that the success of P2PSIP depends on the BEHAVE and MMUSIC working groups delivering a solution in reasonably short order. The rate of progress to date does not inspire confidence or reflect any sense of urgency. This is a risk that must be addressed. Given that risk I propose that the the P2PSIP WG should adopt the following recourse, just in case: If by a certain date BEHAVE and MMUSIC has not finalized a solution that meets the early milestone needs of the P2PSIP charter then the P2PSIP charter must include a provision that permits the WG to propose a solution to BEHAVE and MMUSIC in the form of one or more Internet Drafts. In the absense of any other active or in place solutions the P2PSIP WG should then request that these Internet Drafts be considered as a potential solution by BEHAVE and MMUSIC for hindrance avoidance and multiparty media for P2PSIP sessions. In accordance with IETF guidelines these drafts, once fully finalized and reviewed, would then be submitted for elevation to full RFC status. The P2PSIP WG should always refer to appropriate prior solutions finalized by BEHAVE and MMUSIC, whenever they exist. The goal is not to replace the work of these working groups but instead provide alternate proposals in cases where a finalized solution is for whatever reason not forthcoming. On 24/01/06, Enrico Marocco wrote: > > If "something else" means "something we'll build", the latter doesn't > reconcile with the last phrase of the draft charter: "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." > > Since without such statement the charter wouldn't be accepted, we MUST > look for solutions for hindrance avoidance and multiparty media session > control in behave and mmusic IETF working groups. > -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060124/60988552/attachment-0001.html From sathya at research.panasonic.com Tue Jan 24 18:04:39 2006 From: sathya at research.panasonic.com (Sathya Narayanan) Date: Tue, 24 Jan 2006 18:04:39 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> References: <84E5D7F15F52D34DA84C9C90ACE6554F622C5B@0591-its-exmp01.us.saic. com> <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> Message-ID: <43D6B287.3070800@Research.Panasonic.COM> Michael Slavitch wrote: > > If by a certain date BEHAVE and MMUSIC has not finalized a solution > that meets the early milestone needs of the P2PSIP charter then the > P2PSIP charter must include a provision that permits the WG to propose > a solution to BEHAVE and MMUSIC in the form of one or more Internet > Drafts. I don't understand what you mean by "the WG to propose a solution to ...". AFAIK, there is no need for any provision in the charter for *participants* of P2PSIP WG to submit IDs to the BEHAVE or MMUSIC WG. As Dean mentioned earlier, if we don't believe the existing solutions are satisfactory, we (as individual IETF participants) should drive new requirements into the appropriate working group along with any proposed solutions. I don't see any reason to add a new provision to the proposed P2PSIP charter. - Sathya > In the absense of any other active or in place solutions the P2PSIP WG > should then request that these Internet Drafts be considered as a > potential solution by BEHAVE and MMUSIC for hindrance avoidance and > multiparty media for P2PSIP sessions. In accordance with IETF > guidelines these drafts, once fully finalized and reviewed, would then > be submitted for elevation to full RFC status. > > The P2PSIP WG should always refer to appropriate prior solutions > finalized by BEHAVE and MMUSIC, whenever they exist. The goal is not > to replace the work of these working groups but instead provide > alternate proposals in cases where a finalized solution is for > whatever reason not forthcoming. > > > On 24/01/06, *Enrico Marocco* > wrote: > > > If "something else" means "something we'll build", the latter doesn't > reconcile with the last phrase of the draft charter: "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." > > Since without such statement the charter wouldn't be accepted, we > MUST > look for solutions for hindrance avoidance and multiparty media > session > control in behave and mmusic IETF working groups. > >------------------------------------------------------------------------ > >_______________________________________________ >p2p-sip mailing list >p2p-sip at cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > From slavitch at gmail.com Wed Jan 25 00:23:27 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 25 Jan 2006 00:23:27 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43D6B287.3070800@Research.Panasonic.COM> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> Message-ID: <1fc32c8f0601242123y27649335o@mail.gmail.com> "We (as individual IETF participants) should drive new requirements into the appropriate working group along with any proposed solutions." Absolutely, we should indeed. The formal legalese earlier may have been a little over the top but I have been a veteran of far too many standards battles over the years (not just IETF, although the IETF is catching up in this department) where the real value of an initiative is scuttled, intentionally or not, through inertia and delay by someone successfully arguing that critical components are "not a part of the core mandate" and hence letting them sit as unattended unsolved orphans. This is why key components of P2PSIP must be articulated well enough in advance to ensure that a common consensus and possibly a formal agreement exists on how to deal with these issues as they arise. It is my opinion that the WG must have milestones in place for implementing public NAT traversal protocols including a real fixed date for having such protocols fully described. The P2PSIP WG will first define the specific requirements that will be met by these protocols and deliver these requirements in an early milestone. Given that the WG charter must then reflect that these are issues under the mandate of the WG. To date there is no formal RFC protocol that deals with NAT traversal for SIP signalling or RTP multimedia. What exists today is an Internet-draft that describes a set of methodologies that details related connection techniques while offering example call flows. It is still a tutorial that describes techniques. It has not to date been coalesced into a specific signalling protocol. This must change, and the sooner it is formalized the better. Changing this may require some effort on the part of the P2PSIP community. Unless a formalized broad protocol appears in the near term it appears that members of the P2PSIP community will have no choice but to begin the task of formalizing existing best practises into protocol descriptions that best meet specific P2PSIP requirements. This may result in a patchwork of standards that differ between classic SIP and P2P SIP. In any case a patchwork of formal standards is still better than no standards at all. Regards Michael On 24/01/06, Sathya Narayanan wrote: > > Michael Slavitch wrote: > > > > > If by a certain date BEHAVE and MMUSIC has not finalized a solution > > that meets the early milestone needs of the P2PSIP charter then the > > P2PSIP charter must include a provision that permits the WG to propose > > a solution to BEHAVE and MMUSIC in the form of one or more Internet > > Drafts. > > I don't understand what you mean by "the WG to propose a solution to > ...". AFAIK, there is no need for any provision in the charter for > *participants* of P2PSIP WG to submit IDs to the BEHAVE or MMUSIC WG. > As Dean mentioned earlier, if we don't believe the existing solutions > are satisfactory, we (as individual IETF participants) should drive new > requirements into the appropriate working group along with any proposed > solutions. I don't see any reason to add a new provision to the proposed > P2PSIP charter. > > - Sathya > > > In the absense of any other active or in place solutions the P2PSIP WG > > should then request that these Internet Drafts be considered as a > > potential solution by BEHAVE and MMUSIC for hindrance avoidance and > > multiparty media for P2PSIP sessions. In accordance with IETF > > guidelines these drafts, once fully finalized and reviewed, would then > > be submitted for elevation to full RFC status. > > > > > > The P2PSIP WG should always refer to appropriate prior solutions > > finalized by BEHAVE and MMUSIC, whenever they exist. The goal is not > > to replace the work of these working groups but instead provide > > alternate proposals in cases where a finalized solution is for > > whatever reason not forthcoming. > > > > > > On 24/01/06, *Enrico Marocco* > > wrote: > > > > > > If "something else" means "something we'll build", the latter > doesn't > > reconcile with the last phrase of the draft charter: "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." > > > > Since without such statement the charter wouldn't be accepted, we > > MUST > > look for solutions for hindrance avoidance and multiparty media > > session > > control in behave and mmusic IETF working groups. > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >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/20060125/6a75b5df/attachment.html From dean.willis at softarmor.com Wed Jan 25 01:51:38 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Wed, 25 Jan 2006 00:51:38 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601242123y27649335o@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> Message-ID: On Jan 24, 2006, at 11:23 PM, Michael Slavitch wrote: > To date there is no formal RFC protocol that deals with NAT > traversal for SIP signalling or RTP multimedia. What exists today > is an Internet-draft that describes a set of methodologies that > details related connection techniques while offering example call > flows. It is still a tutorial that describes techniques. It has > not to date been coalesced into a specific signalling protocol. > This must change, and the sooner it is formalized the better. Ok, I may not know all your history here. But I do know a little bit about the history of NAT traversal and SIP. There are actually several key drafts, colloquially referred to as STUN, TURN, ICE, and "outbound". STUN is actually a reasonably widely implemented discrete protocol. TURN is not far behind. Outbound is a signaling extension to SIP for providing persistent through-NAT reflexive signaling. ICE is, as you describe it, a methodology for combining the other techniques. There's a high level of urgency -- I sat through the almost overnight ICE ad-hoc in Vancouver as the key players worked through issue after issue. Sure, there's more work to be done. But issuing an ultimatum from another working group isn't going to make it go faster. And even if there were total agreement on every detail of these specifications, and the drafts were completely final and blessed by the working groups, IESG, and greater IETF, we'd still be over a year from having a referable RFC. That's just the nature of IETF work right now. The other problem is that there is no specific, formalized behavior of NATs to write a "signalling protcocol" against. There are many different sorts of NATs with a broad range of characteristics. We have an entire group (BEHAVE) dedicated to sorting these characteristics out. We have seen no evidence of any single traversal protocol that works on all of them all the time. Sometimes you need a relay element, sometimes you don't. Sometimes, about all you can do is squeeze a tunnel through to a correspondent node that fronts all the protocols for you. STUN helps us discover what we look like to the outside world. TURN gives us a media relay. Outbound gives us a back-channel for signaling, so that we can receive requests. ICE gives us a methodology for bringing this all together in a way that, if not perfect, is at least probably going to work. How does this relate to P2P-SIP? In a world without dedicated servers, how do we find something to run STUN against so we can find out if we're NATed? How do we find and make use of a peer that offers TURN relay services? How do we build persistent signaling relationships with peers outside our NATs so that they can get messages back to us, and how do our other peers discover and re-use those relationships? These are the correspondent and service discovery questions that have to be addressed so that SIP can be made to do something useful in the P2P environments we seem to agree are our targets. -- Dean From fluffy at cisco.com Wed Jan 25 02:26:24 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 24 Jan 2006 23:26:24 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> Message-ID: Like all WG in the IETF there is nothing stopping you from going and helping in any WG. If you feel the BEHAVE work is moving too slowly, go to that WG and help accelerate it. If you think the approach they are using is wrong, go to that WG and get it changed. However, if you think the charter of a P2P-SIP WG should say that this WG is charted to do work that another WG such as BEHAVE or MMUSIC is already charted to do ... well that I would heavily objectless to that proposal. I suspect most people would object to that and I view the odds of it happening to be so low that is barely worth discussing. I do think that most people (myself included) think that a P2P-SIP system would need to work with many nodes behind NATs. I suspect I can prove that if all the nodes participating in the system are behind a symmetric NAT, then it is impossible for any of them to every communicate with any other node. Because of this I think there will have to be some relaxed requirements about some of them at least being behind full cone NATs. If the the P2P protocol was defined over UDP, then everything you need from any other group for NAT traversal may already be done. I'm not suggesting that it is a good idea to use UDP. TCP might have much better firewall traversal properties and the odds are good you would want to look at something such as the STUNT work in BEHAVE. Cullen On 1/24/06 2:01 PM, "Michael Slavitch" wrote: > You state that we MUST refer to BEHAVE and MMUSIC to provide a solution for > hindrance avoidance and multiparty media sessions. > That is true. I fully agree. The corollary of this statement is that it is > incumbent on BEHAVE and MMUSIC to provide a solution that is reasonable and > effective for P2PSIP and to do so in a timely manner. This places an onus on > these groups to deliver an answer, otherwise there is a disconnect that has > much larger implications. Solutions must be finalized and finalized promptly. > > If BEHAVE and MMUSIC has a solution in place that meets the needs of P2PSIP by > all means use it. > As of today it does not. Proposed solutions exist in Internet-Draft form only. > They are still in development. > Given that, what does P2PSIP working group do if there is no solution firmly > in place? Do we wait? How long? > More to the point, what does the P2PSIP community do? Can it wait? How > long? > > The question that arises is "Can the P2PSIP WG go forward and meet its stated > goals when there is no NAT traversal solution firmly in place?" My answer to > that would be a firm no, because the lack of a solution influences the > resulting activities of the working group. > > I argue that such solutions must be fully defined and in be place as a core > competency of P2PSIP communications. If these solutions are not in place by a > certain date the goals and milestones of the P2PSIP working group cannot be > fully met, as a huge protocol hole exists, one that can't be waved away as a > "not my department" issue. This means that the success of P2PSIP depends on > the BEHAVE and MMUSIC working groups delivering a solution in reasonably short > order. > > The rate of progress to date does not inspire confidence or reflect any sense > of urgency. This is a risk that must be addressed. > > Given that risk I propose that the the P2PSIP WG should adopt the following > recourse, just in case: > > If by a certain date BEHAVE and MMUSIC has not finalized a solution that > meets the early milestone needs of the P2PSIP charter then the P2PSIP charter > must include a provision that permits the WG to propose a solution to BEHAVE > and MMUSIC in the form of one or more Internet Drafts. In the absense of any > other active or in place solutions the P2PSIP WG should then request that > these Internet Drafts be considered as a potential solution by BEHAVE and > MMUSIC for hindrance avoidance and multiparty media for P2PSIP sessions. In > accordance with IETF guidelines these drafts, once fully finalized and > reviewed, would then be submitted for elevation to full RFC status. > > The P2PSIP WG should always refer to appropriate prior solutions finalized by > BEHAVE and MMUSIC, whenever they exist. The goal is not to replace the work > of these working groups but instead provide alternate proposals in cases where > a finalized solution is for whatever reason not forthcoming. > > > On 24/01/06, Enrico Marocco wrote: >> >> If "something else" means "something we'll build", the latter doesn't >> reconcile with the last phrase of the draft charter: "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." >> >> Since without such statement the charter wouldn't be accepted, we MUST >> look for solutions for hindrance avoidance and multiparty media session >> control in behave and mmusic IETF working groups. > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060125/f2ff8adf/attachment-0001.html From fluffy at cisco.com Wed Jan 25 02:35:56 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 24 Jan 2006 23:35:56 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: Message-ID: I like this work and think it is the right path for us but I consider it to architecturally be the same as STUN (for UDP) and STUNT (for TCP). On 1/20/06 2:54 PM, "Philip Matthews" wrote: > In fact, Suresh and a couple of others wrote a nice paper that > describes this technique in detail > with an analysis of when it does and does not work. > "Peer-to-Peer Communication Across Network Address Translators" > http://www.brynosaurus.com/pub/net/p2pnat/ > > - Philip > > > On 20-Jan-06, at 16:24 , Pyda Srisuresh wrote: > >> Philip is right. If all NATs are BEHAVE compliant, P2P conenctivity >> could be >> established directly even with the end nodes behind NAT devices. >> However, if a >> NAT is not behave compliant, the end nodes behind that NAT could >> still get P2P >> connectivity through a relay service from the super node. Clearly, >> intervention >> of a super node in the data path is not desirable from perfromance >> perspecective. >> >> cheers, >> suresh >> >> >> --- Philip Matthews wrote: >> >>> >>> On 20-Jan-06, at 13:27 , Dean Willis wrote: >>> >>>> >>>> On Jan 20, 2006, at 1:45 AM, David Barrett wrote: >>>> >>>>>> -----Original Message----- >>>>>> From: Philip Matthews [mailto:philip_matthews at magma.ca] >>>>>>> Indeed, I think it unlikely there will *ever* be a deployment >>>>>>> where >>>>>>> each and >>>>>>> every node is behind its own unique NAT. >>>>>> >>>>>> Again, I disagree. What about a group of friends with phones at >>>>>> their >>>>>> homes >>>>>> who want their own private P2P network? >>>>>> Or a small company where everyone works from a home office? >>>>> >>>>> Ok, good point. I was thinking of global internet-based networks, >>>>> or tiny >>>>> non-internet networks. I hadn't considered very tiny internet- >>>>> based >>>>> networks like this. >>>> >>>> Of course, there may be nothing we can actually DO for people who >>>> are all behind separate non-cooperative NATs that doesn't require >>>> having at least one node somewhere actually publicly visible >>>> somehow. >>>> >>>> This is kind of like the question "If tress fall in several >>>> different woods scattered around the planet and nobody is there to >>>> hear them, does this make the sounds of the percussion section of >>>> an orchestra?" >>>> >>>> -- >>>> Dean >>> >>> >>> If: >>> 1) The peers are behind NATs with the "Endpoint Independent mapping" >>> behavior >>> (to use the terminology of the BEHAVE UDP draft); AND >>> 2) There is a Rendezvous server with a public IP address (either >>> static or with a DNS entry) >>> which can remember the mapped address and port of ONE peer in >>> the P2P network >>> that the new node X wishes to join >>> then it is possible to solve the problem. >>> >>> Briefly, things work as follows. >>> Here we assume there is just one Rendezvous Server that supports all >>> the P2P-SIP networks, >>> but this could be easily generalized to allow different servers for >>> different networks. >>> 1) A P2P-SIP network elects one peer P to maintain a connection to >>> the Rendezvous server. >>> The server remembers (a) the name of the network (b) a password >>> (if access to the network is restricted) >>> and (c) both the private and the mapped address and port of P. >>> Peer P refreshes its info with the server frequently to keep >>> the pinhole in its NAT open. >>> 2) A node X which wishes to join the network contacts the server. >>> Node X provides (a) the name of the network >>> it wishes to join, and (b) the password (if required). >>> 3) The server responds with both the private and mapped address and >>> port of P. >>> 4) At the same time, the server sends a message to P telling it the >>> private and mapped address and port of X. >>> 5) Node X and peer P now try to establish a connection (either TCP or >>> UDP) using a method vaguely >>> similar to that used in ICE (i.e., try all possible address >>> combinations). >>> Provided that both are behind NATs with the "Endpoint >>> Independent mapping" behavior >>> and assuming the NAT topology isn't too crazy (and/or the NATs >>> in question support hairpinning) >>> then things should work. >>> >>> At this point, node X can talk to peer P, and can use P to establish >>> connections with other peers. >>> >>> There are situations where a Rendezvous server is not required, and >>> techniques like multicast, >>> buddy lists, or manual configuration work. However, a Rendezvous >>> server is the most general solution. >>> >>> What I see us (the P2P-SIP group) doing is specifying the protocol >>> used between the Rendezvous Server, >>> peer P, and node X. Then some P2P-SIP networks may decide to use one >>> server, and other networks >>> may decide to use another server. Node X will then have to know (a) >>> which server to contact, (b) the name >>> of the P2P-SIP network it wishes to join, and (c) the password (if >>> any) to join. >>> >>> - Philip >>> >>> >>> _______________________________________________ >>> p2p-sip mailing list >>> p2p-sip at cs.columbia.edu >>> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >>> >> >> >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From fluffy at cisco.com Wed Jan 25 02:36:12 2006 From: fluffy at cisco.com (Cullen Jennings) Date: Tue, 24 Jan 2006 23:36:12 -0800 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <200601202351.k0KNoxKF009296@cs.columbia.edu> Message-ID: On 1/20/06 3:50 PM, "David Barrett" wrote: > c) Keep STUN, TURN, ICE, and SIP they way they are, but create a new > protocol that somehow simplifies the NAT penetration issue? I have not heard a concrete proposal for something that solves and is not isomorphic to ICE. (Actually there is one proposal that I do hear and that is the port prediction but other WG rejected it as not working). If there is a good concrete alternative that is better, let's take it to the appropriate WG and get them to use it. From jose at netlab.hut.fi Wed Jan 25 02:47:37 2006 From: jose at netlab.hut.fi (jose@netlab.hut.fi) Date: Wed, 25 Jan 2006 09:47:37 +0200 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43D66772.9070200@research.panasonic.com> References: <200601241712.k0OHCJKG021465@cs.columbia.edu> <43D66772.9070200@research.panasonic.com> Message-ID: <1138175257.43d72d19882f2@www.netlab.hut.fi> Hi, Fully agree! So far it seems the consensus is around two items: - P2P Resource discovery. - Distributed NAT/FW traversal. The former, as far as I know there is no WG dealing with that issue but on the latter I guess we have a lengthy discussion whether we should tackle that issue or rely on the work from other WGs. IMO we should not forget the problem since NAT/FW is an important factor but we should limit the scope of this WG to the issues within P2P architecture that no other WG is handling like the resource discovery. We should limit the scope to something achievable within certain timeframe. Thus, the charter should reflect the two issues but the focus should be on the P2P resource discovery. Rgds Jose > Henry made an important point. > What we need to talk about urgently is whether the proposed charter is > fine and, if not, what should be improved and how. > Thanks. > > Eunsoo > > Henry Sinnreich wrote: > > >Folks, > > > >Just in case you may not have read previous emails: > > > >Right now, please focus ONLY on making the BOF! > > > >Unless we get an approved plan for the BOF, all technical discussions are in > >vain. There will be plenty opportunity to discuss P2P technical topics AFTER > >the WG has been approved. > > > >Thanks, Henry > > > > > > > >-----Original Message----- > >From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] > >Sent: Tuesday, January 24, 2006 10:42 AM > >To: Michael Slavitch > >Cc: Roy, Radhika R.; P2P-SIP > >Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > >Hello, > > > >I tend to agree with the statement of taking existing mechanisms for NAT-FW, > >etc > >but IMO as already stated the critical issue for the P2P SIP is the resource > >discovery. We need to find where are the SIP entities, either Registrar, > >Proxy > >or the UAs if any, we might also want to know where are the DNS server if we > >want to use the URI of the SIP endpoint, etc. > > > >For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the > >resource discovery has to be done automatically and in a scalable manner > >with > >and without centralised support. > > > >Therefore, the resource discovery would be one of the corner stones in the > >proposed P2P SIP architecture. > >Rgds > >Jose > > > >IMO the critical issue is on the resource discovery > > > > > >>Dean, Roy, et al. > >> > >>I agree. Let us beg, borrow and steal the methods that exist. Does ICE > >> > >> > >yet > > > > > >>exist other than in continually changing draft development form? It has > >>been in development for several years now and in my opinion there is some > >>lack of urgency in coming to a finalized solution, although Microsoft's > >>announced support may ultimately give ICE the kick in the pants that is > >>needed. If that is the case P2P SIP should get on the ICE bandwagon, at > >>least for media sessions. But what if ICE languishes? What then? Do we > >>wait for an external dependency or do we pick up our socks and run with it > >>and perhaps use something else? > >> > >>And good points on resource discovery. IMHO not only should resource > >>discovery exist, it should be largely automatic and the services should be > >>self-advertising, without requiring (but certainly not excluding) > >>centralized configuration, registrars, or rules. > >> > >> > >> > >> > >> > >>On 24/01/06, Roy, Radhika R. wrote: > >> > >> > >>>Dean: > >>> > >>>I think that the way you framed your reply seems to be that we are in > >>>agreement from the broader context. > >>> > >>>Couple of things are as follows: > >>> > >>>1. We are looking for p2p context of FW/NAT crossing by SIP. No > >>> > >>> > >other > > > > > >>>IETF WGs are doing this work. The research p2p WG is doing p2p works, > >>> > >>> > >but > > > > > >>>they are not focused for FW/NAT crossing by SIP per se, and, moreover, > >>>p2p-SIP is looking for commercial solutions, NOT for any research works. > >>> > >>>2. People are proposing solutions for FW/NAT crossing using p2p-SIP > >>>protocol. Some drafts are already there. So, let us work on those drafts > >>>and/or proposals. > >>> > >>>3. P2P-SIP WG should be open to all proposals that help SIP to > >>> > >>> > >solve > > > > > >>>all problems in p2p mode. So, the focus should be p2p, not any non-p2p > >>>aspects of solutions because our charter is to make p2p-SIP protocol in > >>> > >>> > >the > > > > > >>>context of the p2p public Internet. > >>> > >>>So, let us be OPEN to all suggestions for p2p-SIP without limiting > >>> > >>> > >thatsome > > > > > >>items are here or some items are other groups. For example, even people > >> > >> > >>>may say items like "discovery," "registrar," "proxy," or other services > >>>also do NOT belong to p2p-SIP. > >>> > >>>Hope this helps. > >>> > >>>Best regards, > >>> > >>>Radhika > >>> > >>>-----Original Message----- > >>>From: dean.willis at softarmor.com > >>> > >>> > >>[mailto:dean.willis at softarmor.com > >> > >> > >>>] > >>>Sent: Tuesday, January 24, 2006 12:19 AM > >>>To: Roy, Radhika R. > >>>Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP > >>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > >>> > >>>On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > >>> > >>> > >>> > >>>>Michael: > >>>> > >>>> > >>>>I agree with you because this is one of the magic that p2p-SIP is > >>>> > >>>> > >>>>bringing on the table adding tremendous values. In fact, SIP > >>>> > >>>> > >>>>implementations are faltering because of FW/NAT crossing problems. > >>>> > >>>> > >>>>If the power of p2p-SIP is so great that it can solve the most > >>>> > >>>> > >>>>complex problems of VoIP communications like FW/NAT crossing, why > >>>> > >>>> > >>>>should we object to it instead of welcoming? > >>>> > >>>> > >>>Radhika, > >>> > >>>Peer to peer techniques have no "magic" way of making NATs an easy-to- > >>> > >>>solve problem. NATs are ugly, complex, nasty, and highly > >>> > >>>differentiated beasties, and there are myriad techniques for getting > >>> > >>>across different sorts of NATs. > >>> > >>>P2P-SIP is about enabling P2P-SIP nodes to find and communicate with > >>> > >>>other P2P-SIP nodes. We know that some of these nodes will be behind > >>> > >>>NATs. We know that if ALL nodes are behind unique NATs (including the > >>> > >>>"rendezvous function or server"), then there is no known solution to > >>> > >>>be had using P2P techniques. > >>> > >>>That said, we need to be able to answer a couple of questions in > >>> > >>>order to get things talking. We hope that P2P techniques will give us > >>> > >>>a better way to answer these questions than client-server techniques > >>> > >>>didm but they're pretty much the same question. > >>> > >>>These include: > >>> > >>>1) Where shall I send an offer in order to reach my correspondent, > >>> > >>>and how can the response to that offer reach me? > >>> > >>>2) How can I inform my potential correspondents as to where they > >>> > >>>should send offers if they want to reach me? > >>> > >>>3) If I or my correspondent is behind a particularly nasty relay > >>> > >>>element (firewall, NAT, etc.), what intermediate shall I use to > >>> > >>>attempt to reach (or be made reachable to) my correspondent, and how > >>> > >>>shall I communicate with that correspondent? Are there intermediate > >>> > >>>nodes that I can solicit for assistance with this task? > >>> > >>>Notice that all of these questions fall roughly into the category of > >>> > >>>"resource discovery". > >>> > >>>-- > >>> > >>>Dean > >>> > >>> > >>> > >>> > >>-- > >>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 royrr at us.saic.com Wed Jan 25 10:12:58 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Wed, 25 Jan 2006 10:12:58 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: Michael: You are right. It has been misunderstood by many. P2P-SIP WG will work within the framework IETF norms and principles. It means this WG will coordinate its activities with all other IETF WGs. For that matter, it will also look around the world what other folks are doing so that we should NOT re-invent the wheel for P2P communications. Our focus is P2P-SIP protocol development, and it includes all the things that it takes to make SIP as P2P Protocol: FW/NAT crossing, Session Establishments for real-time communications, Discovery, Routing, Resources Management, QoS support for media (audio/video/data), Mobility Management, etc. In doing so, P2P-SIP protocol development will NOT violate any norms or principles of the IETF focusing on P2P communications. Best regards, Radhika _____ From: Michael Slavitch [mailto:slavitch at gmail.com] Sent: Tuesday, January 24, 2006 5:01 PM To: Enrico Marocco Cc: Roy, Radhika R.; P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG You state that we MUST refer to BEHAVE and MMUSIC to provide a solution for hindrance avoidance and multiparty media sessions. That is true. I fully agree. The corollary of this statement is that it is incumbent on BEHAVE and MMUSIC to provide a solution that is reasonable and effective for P2PSIP and to do so in a timely manner. This places an onus on these groups to deliver an answer, otherwise there is a disconnect that has much larger implications. Solutions must be finalized and finalized promptly. If BEHAVE and MMUSIC has a solution in place that meets the needs of P2PSIP by all means use it. As of today it does not. Proposed solutions exist in Internet-Draft form only. They are still in development. Given that, what does P2PSIP working group do if there is no solution firmly in place? Do we wait? How long? More to the point, what does the P2PSIP community do? Can it wait? How long? The question that arises is "Can the P2PSIP WG go forward and meet its stated goals when there is no NAT traversal solution firmly in place?" My answer to that would be a firm no, because the lack of a solution influences the resulting activities of the working group. I argue that such solutions must be fully defined and in be place as a core competency of P2PSIP communications. If these solutions are not in place by a certain date the goals and milestones of the P2PSIP working group cannot be fully met, as a huge protocol hole exists, one that can't be waved away as a "not my department" issue. This means that the success of P2PSIP depends on the BEHAVE and MMUSIC working groups delivering a solution in reasonably short order. The rate of progress to date does not inspire confidence or reflect any sense of urgency. This is a risk that must be addressed. Given that risk I propose that the the P2PSIP WG should adopt the following recourse, just in case: If by a certain date BEHAVE and MMUSIC has not finalized a solution that meets the early milestone needs of the P2PSIP charter then the P2PSIP charter must include a provision that permits the WG to propose a solution to BEHAVE and MMUSIC in the form of one or more Internet Drafts. In the absense of any other active or in place solutions the P2PSIP WG should then request that these Internet Drafts be considered as a potential solution by BEHAVE and MMUSIC for hindrance avoidance and multiparty media for P2PSIP sessions. In accordance with IETF guidelines these drafts, once fully finalized and reviewed, would then be submitted for elevation to full RFC status. The P2PSIP WG should always refer to appropriate prior solutions finalized by BEHAVE and MMUSIC, whenever they exist. The goal is not to replace the work of these working groups but instead provide alternate proposals in cases where a finalized solution is for whatever reason not forthcoming. On 24/01/06, Enrico Marocco > wrote: If "something else" means "something we'll build", the latter doesn't reconcile with the last phrase of the draft charter: "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." Since without such statement the charter wouldn't be accepted, we MUST look for solutions for hindrance avoidance and multiparty media session control in behave and mmusic IETF working groups. -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060125/658d70a8/attachment-0001.html From eunsoo at research.panasonic.com Wed Jan 25 10:13:43 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Wed, 25 Jan 2006 10:13:43 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1138175257.43d72d19882f2@www.netlab.hut.fi> References: <200601241712.k0OHCJKG021465@cs.columbia.edu> <43D66772.9070200@research.panasonic.com> <1138175257.43d72d19882f2@www.netlab.hut.fi> Message-ID: <43D795A7.4040803@research.panasonic.com> jose at netlab.hut.fi wrote: >Hi, > >Fully agree! >So far it seems the consensus is around two items: >- P2P Resource discovery. >- Distributed NAT/FW traversal. > >The former, as far as I know there is no WG dealing with that issue but on the >latter I guess we have a lengthy discussion whether we should tackle that issue >or rely on the work from other WGs. >IMO we should not forget the problem since NAT/FW is an important factor but we >should limit the scope of this WG to the issues within P2P architecture that no >other WG is handling like the resource discovery. > >We should limit the scope to something achievable within certain timeframe. >Thus, the charter should reflect the two issues but the focus should be on the >P2P resource discovery. > > The draft charter includes the following statement. "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." Doesn't this statement satisfy what you wrote above? What do you think? Regards, Eunsoo > > > >>Henry made an important point. >>What we need to talk about urgently is whether the proposed charter is >>fine and, if not, what should be improved and how. >>Thanks. >> >>Eunsoo >> >>Henry Sinnreich wrote: >> >> >> >>>Folks, >>> >>>Just in case you may not have read previous emails: >>> >>>Right now, please focus ONLY on making the BOF! >>> >>>Unless we get an approved plan for the BOF, all technical discussions are in >>>vain. There will be plenty opportunity to discuss P2P technical topics AFTER >>>the WG has been approved. >>> >>>Thanks, Henry >>> >>> >>> >>>-----Original Message----- >>>From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] >>>Sent: Tuesday, January 24, 2006 10:42 AM >>>To: Michael Slavitch >>>Cc: Roy, Radhika R.; P2P-SIP >>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG >>> >>>Hello, >>> >>>I tend to agree with the statement of taking existing mechanisms for NAT-FW, >>>etc >>>but IMO as already stated the critical issue for the P2P SIP is the resource >>>discovery. We need to find where are the SIP entities, either Registrar, >>>Proxy >>>or the UAs if any, we might also want to know where are the DNS server if we >>>want to use the URI of the SIP endpoint, etc. >>> >>>For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the >>>resource discovery has to be done automatically and in a scalable manner >>>with >>>and without centralised support. >>> >>>Therefore, the resource discovery would be one of the corner stones in the >>>proposed P2P SIP architecture. >>>Rgds >>>Jose >>> >>>IMO the critical issue is on the resource discovery >>> >>> >>> >>> >>>>Dean, Roy, et al. >>>> >>>>I agree. Let us beg, borrow and steal the methods that exist. Does ICE >>>> >>>> >>>> >>>> >>>yet >>> >>> >>> >>> >>>>exist other than in continually changing draft development form? It has >>>>been in development for several years now and in my opinion there is some >>>>lack of urgency in coming to a finalized solution, although Microsoft's >>>>announced support may ultimately give ICE the kick in the pants that is >>>>needed. If that is the case P2P SIP should get on the ICE bandwagon, at >>>>least for media sessions. But what if ICE languishes? What then? Do we >>>>wait for an external dependency or do we pick up our socks and run with it >>>>and perhaps use something else? >>>> >>>>And good points on resource discovery. IMHO not only should resource >>>>discovery exist, it should be largely automatic and the services should be >>>>self-advertising, without requiring (but certainly not excluding) >>>>centralized configuration, registrars, or rules. >>>> >>>> >>>> >>>> >>>> >>>>On 24/01/06, Roy, Radhika R. wrote: >>>> >>>> >>>> >>>> >>>>>Dean: >>>>> >>>>>I think that the way you framed your reply seems to be that we are in >>>>>agreement from the broader context. >>>>> >>>>>Couple of things are as follows: >>>>> >>>>>1. We are looking for p2p context of FW/NAT crossing by SIP. No >>>>> >>>>> >>>>> >>>>> >>>other >>> >>> >>> >>> >>>>>IETF WGs are doing this work. The research p2p WG is doing p2p works, >>>>> >>>>> >>>>> >>>>> >>>but >>> >>> >>> >>> >>>>>they are not focused for FW/NAT crossing by SIP per se, and, moreover, >>>>>p2p-SIP is looking for commercial solutions, NOT for any research works. >>>>> >>>>>2. People are proposing solutions for FW/NAT crossing using p2p-SIP >>>>>protocol. Some drafts are already there. So, let us work on those drafts >>>>>and/or proposals. >>>>> >>>>>3. P2P-SIP WG should be open to all proposals that help SIP to >>>>> >>>>> >>>>> >>>>> >>>solve >>> >>> >>> >>> >>>>>all problems in p2p mode. So, the focus should be p2p, not any non-p2p >>>>>aspects of solutions because our charter is to make p2p-SIP protocol in >>>>> >>>>> >>>>> >>>>> >>>the >>> >>> >>> >>> >>>>>context of the p2p public Internet. >>>>> >>>>>So, let us be OPEN to all suggestions for p2p-SIP without limiting >>>>> >>>>> >>>>> >>>>> >>>thatsome >>> >>> >>> >>> >>>>items are here or some items are other groups. For example, even people >>>> >>>> >>>> >>>> >>>>>may say items like "discovery," "registrar," "proxy," or other services >>>>>also do NOT belong to p2p-SIP. >>>>> >>>>>Hope this helps. >>>>> >>>>>Best regards, >>>>> >>>>>Radhika >>>>> >>>>>-----Original Message----- >>>>>From: dean.willis at softarmor.com >>>>> >>>>> >>>>> >>>>> >>>>[mailto:dean.willis at softarmor.com >>>> >>>> >>>> >>>> >>>>>] >>>>>Sent: Tuesday, January 24, 2006 12:19 AM >>>>>To: Roy, Radhika R. >>>>>Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP >>>>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG >>>>> >>>>>On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Michael: >>>>>> >>>>>> >>>>>>I agree with you because this is one of the magic that p2p-SIP is >>>>>> >>>>>> >>>>>>bringing on the table adding tremendous values. In fact, SIP >>>>>> >>>>>> >>>>>>implementations are faltering because of FW/NAT crossing problems. >>>>>> >>>>>> >>>>>>If the power of p2p-SIP is so great that it can solve the most >>>>>> >>>>>> >>>>>>complex problems of VoIP communications like FW/NAT crossing, why >>>>>> >>>>>> >>>>>>should we object to it instead of welcoming? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Radhika, >>>>> >>>>>Peer to peer techniques have no "magic" way of making NATs an easy-to- >>>>> >>>>>solve problem. NATs are ugly, complex, nasty, and highly >>>>> >>>>>differentiated beasties, and there are myriad techniques for getting >>>>> >>>>>across different sorts of NATs. >>>>> >>>>>P2P-SIP is about enabling P2P-SIP nodes to find and communicate with >>>>> >>>>>other P2P-SIP nodes. We know that some of these nodes will be behind >>>>> >>>>>NATs. We know that if ALL nodes are behind unique NATs (including the >>>>> >>>>>"rendezvous function or server"), then there is no known solution to >>>>> >>>>>be had using P2P techniques. >>>>> >>>>>That said, we need to be able to answer a couple of questions in >>>>> >>>>>order to get things talking. We hope that P2P techniques will give us >>>>> >>>>>a better way to answer these questions than client-server techniques >>>>> >>>>>didm but they're pretty much the same question. >>>>> >>>>>These include: >>>>> >>>>>1) Where shall I send an offer in order to reach my correspondent, >>>>> >>>>>and how can the response to that offer reach me? >>>>> >>>>>2) How can I inform my potential correspondents as to where they >>>>> >>>>>should send offers if they want to reach me? >>>>> >>>>>3) If I or my correspondent is behind a particularly nasty relay >>>>> >>>>>element (firewall, NAT, etc.), what intermediate shall I use to >>>>> >>>>>attempt to reach (or be made reachable to) my correspondent, and how >>>>> >>>>>shall I communicate with that correspondent? Are there intermediate >>>>> >>>>>nodes that I can solicit for assistance with this task? >>>>> >>>>>Notice that all of these questions fall roughly into the category of >>>>> >>>>>"resource discovery". >>>>> >>>>>-- >>>>> >>>>>Dean >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>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 jose at netlab.hut.fi Wed Jan 25 10:56:10 2006 From: jose at netlab.hut.fi (jose@netlab.hut.fi) Date: Wed, 25 Jan 2006 17:56:10 +0200 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43D795A7.4040803@research.panasonic.com> References: <200601241712.k0OHCJKG021465@cs.columbia.edu> <43D66772.9070200@research.panasonic.com> <1138175257.43d72d19882f2@www.netlab.hut.fi> <43D795A7.4040803@research.panasonic.com> Message-ID: <1138204570.43d79f9a333fc@www.netlab.hut.fi> Hi Eunsoo, Yep, the NAT/FW traversal is included there. Is the resource discovery mentioned also in the charter? Rgds Jose > > jose at netlab.hut.fi wrote: > > >Hi, > > > >Fully agree! > >So far it seems the consensus is around two items: > >- P2P Resource discovery. > >- Distributed NAT/FW traversal. > > > >The former, as far as I know there is no WG dealing with that issue but on > the > >latter I guess we have a lengthy discussion whether we should tackle that > issue > >or rely on the work from other WGs. > >IMO we should not forget the problem since NAT/FW is an important factor but > we > >should limit the scope of this WG to the issues within P2P architecture that > no > >other WG is handling like the resource discovery. > > > >We should limit the scope to something achievable within certain timeframe. > >Thus, the charter should reflect the two issues but the focus should be on > the > >P2P resource discovery. > > > > > The draft charter includes the following statement. > > "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." > > Doesn't this statement satisfy what you wrote above? What do you think? > > Regards, > > Eunsoo > > > > > > > > > > >>Henry made an important point. > >>What we need to talk about urgently is whether the proposed charter is > >>fine and, if not, what should be improved and how. > >>Thanks. > >> > >>Eunsoo > >> > >>Henry Sinnreich wrote: > >> > >> > >> > >>>Folks, > >>> > >>>Just in case you may not have read previous emails: > >>> > >>>Right now, please focus ONLY on making the BOF! > >>> > >>>Unless we get an approved plan for the BOF, all technical discussions are > in > >>>vain. There will be plenty opportunity to discuss P2P technical topics > AFTER > >>>the WG has been approved. > >>> > >>>Thanks, Henry > >>> > >>> > >>> > >>>-----Original Message----- > >>>From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] > >>>Sent: Tuesday, January 24, 2006 10:42 AM > >>>To: Michael Slavitch > >>>Cc: Roy, Radhika R.; P2P-SIP > >>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > >>> > >>>Hello, > >>> > >>>I tend to agree with the statement of taking existing mechanisms for > NAT-FW, > >>>etc > >>>but IMO as already stated the critical issue for the P2P SIP is the > resource > >>>discovery. We need to find where are the SIP entities, either Registrar, > >>>Proxy > >>>or the UAs if any, we might also want to know where are the DNS server if > we > >>>want to use the URI of the SIP endpoint, etc. > >>> > >>>For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the > >>>resource discovery has to be done automatically and in a scalable manner > >>>with > >>>and without centralised support. > >>> > >>>Therefore, the resource discovery would be one of the corner stones in the > >>>proposed P2P SIP architecture. > >>>Rgds > >>>Jose > >>> > >>>IMO the critical issue is on the resource discovery > >>> > >>> > >>> > >>> > >>>>Dean, Roy, et al. > >>>> > >>>>I agree. Let us beg, borrow and steal the methods that exist. Does ICE > >>>> > >>>> > >>>> > >>>> > >>>yet > >>> > >>> > >>> > >>> > >>>>exist other than in continually changing draft development form? It has > >>>>been in development for several years now and in my opinion there is some > >>>>lack of urgency in coming to a finalized solution, although Microsoft's > >>>>announced support may ultimately give ICE the kick in the pants that is > >>>>needed. If that is the case P2P SIP should get on the ICE bandwagon, at > >>>>least for media sessions. But what if ICE languishes? What then? Do we > >>>>wait for an external dependency or do we pick up our socks and run with > it > >>>>and perhaps use something else? > >>>> > >>>>And good points on resource discovery. IMHO not only should resource > >>>>discovery exist, it should be largely automatic and the services should > be > >>>>self-advertising, without requiring (but certainly not excluding) > >>>>centralized configuration, registrars, or rules. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>On 24/01/06, Roy, Radhika R. wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>Dean: > >>>>> > >>>>>I think that the way you framed your reply seems to be that we are in > >>>>>agreement from the broader context. > >>>>> > >>>>>Couple of things are as follows: > >>>>> > >>>>>1. We are looking for p2p context of FW/NAT crossing by SIP. No > >>>>> > >>>>> > >>>>> > >>>>> > >>>other > >>> > >>> > >>> > >>> > >>>>>IETF WGs are doing this work. The research p2p WG is doing p2p works, > >>>>> > >>>>> > >>>>> > >>>>> > >>>but > >>> > >>> > >>> > >>> > >>>>>they are not focused for FW/NAT crossing by SIP per se, and, moreover, > >>>>>p2p-SIP is looking for commercial solutions, NOT for any research works. > >>>>> > >>>>>2. People are proposing solutions for FW/NAT crossing using p2p-SIP > >>>>>protocol. Some drafts are already there. So, let us work on those drafts > >>>>>and/or proposals. > >>>>> > >>>>>3. P2P-SIP WG should be open to all proposals that help SIP to > >>>>> > >>>>> > >>>>> > >>>>> > >>>solve > >>> > >>> > >>> > >>> > >>>>>all problems in p2p mode. So, the focus should be p2p, not any non-p2p > >>>>>aspects of solutions because our charter is to make p2p-SIP protocol in > >>>>> > >>>>> > >>>>> > >>>>> > >>>the > >>> > >>> > >>> > >>> > >>>>>context of the p2p public Internet. > >>>>> > >>>>>So, let us be OPEN to all suggestions for p2p-SIP without limiting > >>>>> > >>>>> > >>>>> > >>>>> > >>>thatsome > >>> > >>> > >>> > >>> > >>>>items are here or some items are other groups. For example, even people > >>>> > >>>> > >>>> > >>>> > >>>>>may say items like "discovery," "registrar," "proxy," or other services > >>>>>also do NOT belong to p2p-SIP. > >>>>> > >>>>>Hope this helps. > >>>>> > >>>>>Best regards, > >>>>> > >>>>>Radhika > >>>>> > >>>>>-----Original Message----- > >>>>>From: dean.willis at softarmor.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>[mailto:dean.willis at softarmor.com > >>>> > >>>> > >>>> > >>>> > >>>>>] > >>>>>Sent: Tuesday, January 24, 2006 12:19 AM > >>>>>To: Roy, Radhika R. > >>>>>Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP > >>>>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > >>>>> > >>>>>On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Michael: > >>>>>> > >>>>>> > >>>>>>I agree with you because this is one of the magic that p2p-SIP is > >>>>>> > >>>>>> > >>>>>>bringing on the table adding tremendous values. In fact, SIP > >>>>>> > >>>>>> > >>>>>>implementations are faltering because of FW/NAT crossing problems. > >>>>>> > >>>>>> > >>>>>>If the power of p2p-SIP is so great that it can solve the most > >>>>>> > >>>>>> > >>>>>>complex problems of VoIP communications like FW/NAT crossing, why > >>>>>> > >>>>>> > >>>>>>should we object to it instead of welcoming? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>Radhika, > >>>>> > >>>>>Peer to peer techniques have no "magic" way of making NATs an easy-to- > >>>>> > >>>>>solve problem. NATs are ugly, complex, nasty, and highly > >>>>> > >>>>>differentiated beasties, and there are myriad techniques for getting > >>>>> > >>>>>across different sorts of NATs. > >>>>> > >>>>>P2P-SIP is about enabling P2P-SIP nodes to find and communicate with > >>>>> > >>>>>other P2P-SIP nodes. We know that some of these nodes will be behind > >>>>> > >>>>>NATs. We know that if ALL nodes are behind unique NATs (including the > >>>>> > >>>>>"rendezvous function or server"), then there is no known solution to > >>>>> > >>>>>be had using P2P techniques. > >>>>> > >>>>>That said, we need to be able to answer a couple of questions in > >>>>> > >>>>>order to get things talking. We hope that P2P techniques will give us > >>>>> > >>>>>a better way to answer these questions than client-server techniques > >>>>> > >>>>>didm but they're pretty much the same question. > >>>>> > >>>>>These include: > >>>>> > >>>>>1) Where shall I send an offer in order to reach my correspondent, > >>>>> > >>>>>and how can the response to that offer reach me? > >>>>> > >>>>>2) How can I inform my potential correspondents as to where they > >>>>> > >>>>>should send offers if they want to reach me? > >>>>> > >>>>>3) If I or my correspondent is behind a particularly nasty relay > >>>>> > >>>>>element (firewall, NAT, etc.), what intermediate shall I use to > >>>>> > >>>>>attempt to reach (or be made reachable to) my correspondent, and how > >>>>> > >>>>>shall I communicate with that correspondent? Are there intermediate > >>>>> > >>>>>nodes that I can solicit for assistance with this task? > >>>>> > >>>>>Notice that all of these questions fall roughly into the category of > >>>>> > >>>>>"resource discovery". > >>>>> > >>>>>-- > >>>>> > >>>>>Dean > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>-- > >>>>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 sathya at research.panasonic.com Wed Jan 25 11:29:19 2006 From: sathya at research.panasonic.com (Sathya Narayanan) Date: Wed, 25 Jan 2006 11:29:19 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601242123y27649335o@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> Message-ID: <43D7A75F.2000700@Research.Panasonic.COM> Michael Slavitch wrote: > "We (as individual IETF participants) should drive new requirements > into the appropriate working group along with any proposed solutions." > > Absolutely, we should indeed. The formal legalese earlier may have > been a little over the top but I have been a veteran of far too many > standards battles over the years (not just IETF, although the IETF is > catching up in this department) where the real value of an initiative > is scuttled, intentionally or not, through inertia and delay by > someone successfully arguing that critical components are "not a part > of the core mandate" and hence letting them sit as unattended unsolved > orphans. This is why key components of P2PSIP must be articulated > well enough in advance to ensure that a common consensus and possibly > a formal agreement exists on how to deal with these issues as they arise. Ofcourse, I agree that the key components of P2PSIP must be articulated - but I think it should be done in a ID. > It is my opinion that the WG must have milestones in place for > implementing public NAT traversal protocols including a real fixed > date for having such protocols fully described. The P2PSIP WG will > first define the specific requirements that will be met by these > protocols and deliver these requirements in an early milestone. This sounds to me like again trying to mandate things from another working group. As was mentioned many times earlier, this is not possible in IETF. > > Given that the WG charter must then reflect that these are issues > under the mandate of the WG. Please suggest the changes you think is needed. I don't think it is possible to word your suggestions in a formal charter for a WG. regards, Sathya > > To date there is no formal RFC protocol that deals with NAT traversal > for SIP signalling or RTP multimedia. What exists today is an > Internet-draft that describes a set of methodologies that details > related connection techniques while offering example call flows. It > is still a tutorial that describes techniques. It has not to date > been coalesced into a specific signalling protocol. This must change, > and the sooner it is formalized the better. > > Changing this may require some effort on the part of the P2PSIP > community. Unless a formalized broad protocol appears in the near > term it appears that members of the P2PSIP community will have no > choice but to begin the task of formalizing existing best practises > into protocol descriptions that best meet specific P2PSIP > requirements. This may result in a patchwork of standards that differ > between classic SIP and P2P SIP. In any case a patchwork of formal > standards is still better than no standards at all. > > > Regards > > Michael > > > On 24/01/06, *Sathya Narayanan* > wrote: > > Michael Slavitch wrote: > > > > > If by a certain date BEHAVE and MMUSIC has not finalized a > solution > > that meets the early milestone needs of the P2PSIP charter then the > > P2PSIP charter must include a provision that permits the WG to > propose > > a solution to BEHAVE and MMUSIC in the form of one or more Internet > > Drafts. > > I don't understand what you mean by "the WG to propose a solution to > ...". AFAIK, there is no need for any provision in the charter for > *participants* of P2PSIP WG to submit IDs to the BEHAVE or MMUSIC WG. > As Dean mentioned earlier, if we don't believe the existing solutions > are satisfactory, we (as individual IETF participants) should > drive new > requirements into the appropriate working group along with any > proposed > solutions. I don't see any reason to add a new provision to the > proposed > P2PSIP charter. > > - Sathya > > > In the absense of any other active or in place solutions the > P2PSIP WG > > should then request that these Internet Drafts be considered as a > > potential solution by BEHAVE and MMUSIC for hindrance avoidance and > > multiparty media for P2PSIP sessions. In accordance with IETF > > guidelines these drafts, once fully finalized and reviewed, > would then > > be submitted for elevation to full RFC status. > > > > > > The P2PSIP WG should always refer to appropriate prior solutions > > finalized by BEHAVE and MMUSIC, whenever they exist. The goal > is not > > to replace the work of these working groups but instead provide > > alternate proposals in cases where a finalized solution is for > > whatever reason not forthcoming. > > > > > > On 24/01/06, *Enrico Marocco* < enrico.marocco at tilab.com > > > >> wrote: > > > > > > If "something else" means "something we'll build", the > latter doesn't > > reconcile with the last phrase of the draft charter: > "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." > > > > Since without such statement the charter wouldn't be > accepted, we > > MUST > > look for solutions for hindrance avoidance and multiparty media > > session > > control in behave and mmusic IETF working groups. > > > >------------------------------------------------------------------------ > > > > >_______________________________________________ > >p2p-sip mailing list > >p2p-sip at cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > -- > Michael Slavitch > Ottawa, Ontario Canada From bryan at ethernot.org Wed Jan 25 11:36:58 2006 From: bryan at ethernot.org (David A. Bryan) Date: Wed, 25 Jan 2006 11:36:58 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1138204570.43d79f9a333fc@www.netlab.hut.fi> References: <200601241712.k0OHCJKG021465@cs.columbia.edu> <43D66772.9070200@research.panasonic.com> <1138175257.43d72d19882f2@www.netlab.hut.fi> <43D795A7.4040803@research.panasonic.com> <1138204570.43d79f9a333fc@www.netlab.hut.fi> Message-ID: <8b2769930601250836m23b998c5l408e3fa986bc3821@mail.gmail.com> I think we have that covered in the sense that we mention some of the future work might include locating resources rather than users as needed for particular SIP communications based purposes. We mention lookup schemes for user location as a current working item, and VM and services such as distributed media relay as possible future items (which would of course require locating a resource), and in the list of what we exclude, we say: 1. Issues specific to applications other than locating users and resources for SIP-based communications. So as sort of a corollary -- "it isn't out so if needed for P2P SIP items it is in" -- we include locating resources as needed for SIP-based communication, if that is required for services we do after recharters (things like locating vm message, relays, storing a UA config file, or other SIP communications service specific things). On the other hand, a *general* resource location mechanism outside of real time SIP based communication (so for example, general file sharing/location stuff that isn't intended for use in SIP based communications) is obviously out of scope for this group, since the item above rules them out explicitly. David On 1/25/06, jose at netlab.hut.fi wrote: > Hi Eunsoo, > > Yep, the NAT/FW traversal is included there. > Is the resource discovery mentioned also in the charter? > Rgds > Jose > > > > > jose at netlab.hut.fi wrote: > > > > >Hi, > > > > > >Fully agree! > > >So far it seems the consensus is around two items: > > >- P2P Resource discovery. > > >- Distributed NAT/FW traversal. > > > > > >The former, as far as I know there is no WG dealing with that issue but on > > the > > >latter I guess we have a lengthy discussion whether we should tackle that > > issue > > >or rely on the work from other WGs. > > >IMO we should not forget the problem since NAT/FW is an important factor but > > we > > >should limit the scope of this WG to the issues within P2P architecture that > > no > > >other WG is handling like the resource discovery. > > > > > >We should limit the scope to something achievable within certain timeframe. > > >Thus, the charter should reflect the two issues but the focus should be on > > the > > >P2P resource discovery. > > > > > > > > The draft charter includes the following statement. > > > > "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." > > > > Doesn't this statement satisfy what you wrote above? What do you think? > > > > Regards, > > > > Eunsoo > > > > > > > > > > > > > > > > > >>Henry made an important point. > > >>What we need to talk about urgently is whether the proposed charter is > > >>fine and, if not, what should be improved and how. > > >>Thanks. > > >> > > >>Eunsoo > > >> > > >>Henry Sinnreich wrote: > > >> > > >> > > >> > > >>>Folks, > > >>> > > >>>Just in case you may not have read previous emails: > > >>> > > >>>Right now, please focus ONLY on making the BOF! > > >>> > > >>>Unless we get an approved plan for the BOF, all technical discussions are > > in > > >>>vain. There will be plenty opportunity to discuss P2P technical topics > > AFTER > > >>>the WG has been approved. > > >>> > > >>>Thanks, Henry > > >>> > > >>> > > >>> > > >>>-----Original Message----- > > >>>From: jose at netlab.hut.fi [mailto:jose at netlab.hut.fi] > > >>>Sent: Tuesday, January 24, 2006 10:42 AM > > >>>To: Michael Slavitch > > >>>Cc: Roy, Radhika R.; P2P-SIP > > >>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > >>> > > >>>Hello, > > >>> > > >>>I tend to agree with the statement of taking existing mechanisms for > > NAT-FW, > > >>>etc > > >>>but IMO as already stated the critical issue for the P2P SIP is the > > resource > > >>>discovery. We need to find where are the SIP entities, either Registrar, > > >>>Proxy > > >>>or the UAs if any, we might also want to know where are the DNS server if > > we > > >>>want to use the URI of the SIP endpoint, etc. > > >>> > > >>>For this we also have several options (e.g. Chord, SLP, UPnP, etc) but the > > >>>resource discovery has to be done automatically and in a scalable manner > > >>>with > > >>>and without centralised support. > > >>> > > >>>Therefore, the resource discovery would be one of the corner stones in the > > >>>proposed P2P SIP architecture. > > >>>Rgds > > >>>Jose > > >>> > > >>>IMO the critical issue is on the resource discovery > > >>> > > >>> > > >>> > > >>> > > >>>>Dean, Roy, et al. > > >>>> > > >>>>I agree. Let us beg, borrow and steal the methods that exist. Does ICE > > >>>> > > >>>> > > >>>> > > >>>> > > >>>yet > > >>> > > >>> > > >>> > > >>> > > >>>>exist other than in continually changing draft development form? It has > > >>>>been in development for several years now and in my opinion there is some > > >>>>lack of urgency in coming to a finalized solution, although Microsoft's > > >>>>announced support may ultimately give ICE the kick in the pants that is > > >>>>needed. If that is the case P2P SIP should get on the ICE bandwagon, at > > >>>>least for media sessions. But what if ICE languishes? What then? Do we > > >>>>wait for an external dependency or do we pick up our socks and run with > > it > > >>>>and perhaps use something else? > > >>>> > > >>>>And good points on resource discovery. IMHO not only should resource > > >>>>discovery exist, it should be largely automatic and the services should > > be > > >>>>self-advertising, without requiring (but certainly not excluding) > > >>>>centralized configuration, registrars, or rules. > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>On 24/01/06, Roy, Radhika R. wrote: > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>>Dean: > > >>>>> > > >>>>>I think that the way you framed your reply seems to be that we are in > > >>>>>agreement from the broader context. > > >>>>> > > >>>>>Couple of things are as follows: > > >>>>> > > >>>>>1. We are looking for p2p context of FW/NAT crossing by SIP. No > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>other > > >>> > > >>> > > >>> > > >>> > > >>>>>IETF WGs are doing this work. The research p2p WG is doing p2p works, > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>but > > >>> > > >>> > > >>> > > >>> > > >>>>>they are not focused for FW/NAT crossing by SIP per se, and, moreover, > > >>>>>p2p-SIP is looking for commercial solutions, NOT for any research works. > > >>>>> > > >>>>>2. People are proposing solutions for FW/NAT crossing using p2p-SIP > > >>>>>protocol. Some drafts are already there. So, let us work on those drafts > > >>>>>and/or proposals. > > >>>>> > > >>>>>3. P2P-SIP WG should be open to all proposals that help SIP to > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>solve > > >>> > > >>> > > >>> > > >>> > > >>>>>all problems in p2p mode. So, the focus should be p2p, not any non-p2p > > >>>>>aspects of solutions because our charter is to make p2p-SIP protocol in > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>the > > >>> > > >>> > > >>> > > >>> > > >>>>>context of the p2p public Internet. > > >>>>> > > >>>>>So, let us be OPEN to all suggestions for p2p-SIP without limiting > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>thatsome > > >>> > > >>> > > >>> > > >>> > > >>>>items are here or some items are other groups. For example, even people > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>>may say items like "discovery," "registrar," "proxy," or other services > > >>>>>also do NOT belong to p2p-SIP. > > >>>>> > > >>>>>Hope this helps. > > >>>>> > > >>>>>Best regards, > > >>>>> > > >>>>>Radhika > > >>>>> > > >>>>>-----Original Message----- > > >>>>>From: dean.willis at softarmor.com > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>[mailto:dean.willis at softarmor.com > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>>] > > >>>>>Sent: Tuesday, January 24, 2006 12:19 AM > > >>>>>To: Roy, Radhika R. > > >>>>>Cc: Michael Slavitch; Pyda Srisuresh; P2P-SIP > > >>>>>Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG > > >>>>> > > >>>>>On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Michael: > > >>>>>> > > >>>>>> > > >>>>>>I agree with you because this is one of the magic that p2p-SIP is > > >>>>>> > > >>>>>> > > >>>>>>bringing on the table adding tremendous values. In fact, SIP > > >>>>>> > > >>>>>> > > >>>>>>implementations are faltering because of FW/NAT crossing problems. > > >>>>>> > > >>>>>> > > >>>>>>If the power of p2p-SIP is so great that it can solve the most > > >>>>>> > > >>>>>> > > >>>>>>complex problems of VoIP communications like FW/NAT crossing, why > > >>>>>> > > >>>>>> > > >>>>>>should we object to it instead of welcoming? > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>Radhika, > > >>>>> > > >>>>>Peer to peer techniques have no "magic" way of making NATs an easy-to- > > >>>>> > > >>>>>solve problem. NATs are ugly, complex, nasty, and highly > > >>>>> > > >>>>>differentiated beasties, and there are myriad techniques for getting > > >>>>> > > >>>>>across different sorts of NATs. > > >>>>> > > >>>>>P2P-SIP is about enabling P2P-SIP nodes to find and communicate with > > >>>>> > > >>>>>other P2P-SIP nodes. We know that some of these nodes will be behind > > >>>>> > > >>>>>NATs. We know that if ALL nodes are behind unique NATs (including the > > >>>>> > > >>>>>"rendezvous function or server"), then there is no known solution to > > >>>>> > > >>>>>be had using P2P techniques. > > >>>>> > > >>>>>That said, we need to be able to answer a couple of questions in > > >>>>> > > >>>>>order to get things talking. We hope that P2P techniques will give us > > >>>>> > > >>>>>a better way to answer these questions than client-server techniques > > >>>>> > > >>>>>didm but they're pretty much the same question. > > >>>>> > > >>>>>These include: > > >>>>> > > >>>>>1) Where shall I send an offer in order to reach my correspondent, > > >>>>> > > >>>>>and how can the response to that offer reach me? > > >>>>> > > >>>>>2) How can I inform my potential correspondents as to where they > > >>>>> > > >>>>>should send offers if they want to reach me? > > >>>>> > > >>>>>3) If I or my correspondent is behind a particularly nasty relay > > >>>>> > > >>>>>element (firewall, NAT, etc.), what intermediate shall I use to > > >>>>> > > >>>>>attempt to reach (or be made reachable to) my correspondent, and how > > >>>>> > > >>>>>shall I communicate with that correspondent? Are there intermediate > > >>>>> > > >>>>>nodes that I can solicit for assistance with this task? > > >>>>> > > >>>>>Notice that all of these questions fall roughly into the category of > > >>>>> > > >>>>>"resource discovery". > > >>>>> > > >>>>>-- > > >>>>> > > >>>>>Dean > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>-- > > >>>>Michael Slavitch > > >>>>Ottawa, Ontario Canada > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>>_______________________________________________ > > >>>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 henry at pulver.com Wed Jan 25 12:32:59 2006 From: henry at pulver.com (Henry Sinnreich) Date: Wed, 25 Jan 2006 11:32:59 -0600 Subject: [p2p-sip] Using results from the IRTF P2P Research Group In-Reply-To: <8b2769930601250836m23b998c5l408e3fa986bc3821@mail.gmail.com> Message-ID: <200601251733.k0PHX0KG019527@cs.columbia.edu> I suggest to add to the charter text something like this: The P2P SIP WG will use, where applicable, the insights and the results from the work of the P2P IRTF Group for such topics as generic requirements for P2P and P2P resource and service discovery protocols, see http://www.irtf.org/charter.php Thanks, Henry From slavitch at gmail.com Wed Jan 25 12:56:56 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 25 Jan 2006 12:56:56 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: References: Message-ID: <1fc32c8f0601250956r1978e1b8r@mail.gmail.com> I fully support Radhika's statement below. I assert the following: 1. a finite statement similar to Radhika's should be part of the P2PSIP charter. ("etc." may sound too open ended for the comfort of some.) 2. The WG must then develop milestones for deliverables that meet these charter goals. 3. These deliverables must include precise definitions of the functional requirements for core P2P components, including, for example, NAT traversal. 4. The deliverables must include references to specific definitions of the solutions that have been accepted by the WG. 4. In the event of an absence of specific protocol definitions for solutions that meet these requirements, these requirements should be then be used as the basis for solution proposals that would then be presented to other working groups, in accordance with IETF principles. The goal would be to produce one or more specific protocol definition that would satisfy the requirements of the P2PWG. If P2PSIP is to be widely adopted and widely interoperable the WG must deliver or reference protocols that give completely diverse and independent groups operating under the same set of specifications all the means needed to create fully interoperable implementations, without relying on negotiation, permission, license or co-ordination of what is accepted as best practice. To do this P2PSIP needs to produce or refer to formal specifications. The danger of relying on descriptions of best practices is that they are open to interpretation, suasion and argument. It forces implementers to be part of a club, and that club may well be exclusive. Proprietary implementations could easily claim to be P2PSIP compliant when in fact they are following private interpretations of best practices. This is already a common practice for many actors even with well-established and well-defined formal protocol standards such as HTTP. Such efforts tend to end up being limited to whatever wiggle room the standards definitions allow. The better the protocol the less room there is for wiggling. One frequently-used technique for turning so-called standards-compliant implementations into proprietary solutions involves burying critical items in protocol elements that are tagged with the dreaded OPTIONAL or SHOULD clauses. The word SHOULD isn't a specification, it's an opinion. The defining characteristic of the IETF is that its protocol standards are inclusive, open and interoperable. This is a social contract. A well defined formal protocol is a good and fair contract. Such protocols clearly describe steps for all known interactions and describe these steps using unambiguous terms such as MUST, MUST NOT and SHALL wherever possible. Terms like SHOULD, MAY and especially OPTIONAL are red flags and are used only when there are truly compelling reasons to do so. A document full of SHOULD, MAY and OPTIONAL statements isn't a contract, it's a recommendation. Overuse of the three words SHOULD, MAY and OPTIONAL has been a consistentsource of peril for implementer of IETF standards. This is my plea that there be a commitment to avoiding such peril in P2PSIP. This commitment starts with an assertion that *all *the components that as a whole will constitute what will be commonly called *P2PSIP *MUST be fully described as a set of well-defined protocols that are in turn defined as RFC standards track documents, and that in the event that such documents do not exist, *they will be created*. Core capabilities MUST NEVER be abstracted away. Regards, Michael On 25/01/06, Roy, Radhika R. wrote: > > Michael: > > > > You are right. It has been misunderstood by many. > > > > P2P-SIP WG will work within the framework IETF norms and principles. It > means this WG will coordinate its activities with all other IETF WGs. For > that matter, it will also look around the world what other folks are doing > so that we should NOT re-invent the wheel for P2P communications. > > > > Our focus is P2P-SIP protocol development, and it includes all the things > that it takes to make SIP as P2P Protocol: FW/NAT crossing, Session > Establishments for real-time communications, Discovery, Routing, Resources > Management, QoS support for media (audio/video/data), Mobility Management, > etc. > > > > In doing so, P2P-SIP protocol development will NOT violate any norms or > principles of the IETF focusing on P2P communications. > > > > Best regards, > > Radhika > > > ------------------------------ > > *From:* Michael Slavitch [mailto:slavitch at gmail.com] > *Sent:* Tuesday, January 24, 2006 5:01 PM > *To:* Enrico Marocco > *Cc:* Roy, Radhika R.; P2P-SIP > *Subject:* Re: [p2p-sip] Draft charter for possible P2PSIP WG > > > > You state that we MUST refer to BEHAVE and MMUSIC to provide a solution > for hindrance avoidance and multiparty media sessions. > That is true. I fully agree. The corollary of this statement is that it > is incumbent on BEHAVE and MMUSIC to provide a solution that is reasonable > and effective for P2PSIP *and to do so in a timely manne*r. This places an > onus on these groups to deliver an answer, otherwise there is a disconnect > that has much larger implications. Solutions must be finalized and > finalized promptly. > > If BEHAVE and MMUSIC has a solution in place that meets the needs of > P2PSIP by all means use it. > As of today it does not. Proposed solutions exist in Internet-Draft form > only. They are still in development. > Given that, what does P2PSIP working group do if there is no solution > firmly in place? Do we wait? How long? > More to the point, what does the P2PSIP community do? Can it wait? How > long? > > The question that arises is "Can the P2PSIP WG go forward and meet its > stated goals when there is no NAT traversal solution firmly in place?" My > answer to that would be a firm no, because the lack of a solution influences > the resulting activities of the working group. > > I argue that such solutions must be fully defined and in be place as a > core competency of P2PSIP communications. If these solutions are not in > place by a certain date the goals and milestones of the P2PSIP working group > cannot be fully met, as a huge protocol hole exists, one that can't be waved > away as a "not my department" issue. This means that the success of P2PSIP > depends on the BEHAVE and MMUSIC working groups delivering a solution in > reasonably short order. > > The rate of progress to date does not inspire confidence or reflect any > sense of urgency. This is a risk that must be addressed. > > Given that risk I propose that the the P2PSIP WG should adopt the > following recourse, just in case: > > If by a certain date BEHAVE and MMUSIC has not finalized a solution that > meets the early milestone needs of the P2PSIP charter then the P2PSIP > charter must include a provision that permits the WG to propose a solution > to BEHAVE and MMUSIC in the form of one or more Internet Drafts. In the > absense of any other active or in place solutions the P2PSIP WG should then > request that these Internet Drafts be considered as a potential solution by > BEHAVE and MMUSIC for hindrance avoidance and multiparty media for P2PSIP > sessions. In accordance with IETF guidelines these drafts, once fully > finalized and reviewed, would then be submitted for elevation to full RFC > status. > > The P2PSIP WG should always refer to appropriate prior solutions finalized > by BEHAVE and MMUSIC, whenever they exist. The goal is not to replace the > work of these working groups but instead provide alternate proposals in > cases where a finalized solution is for whatever reason not forthcoming. > > On 24/01/06, *Enrico Marocco* wrote: > > > If "something else" means "something we'll build", the latter doesn't > reconcile with the last phrase of the draft charter: "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." > > Since without such statement the charter wouldn't be accepted, we MUST > look for solutions for hindrance avoidance and multiparty media session > control in behave and mmusic IETF working groups. > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060125/18d3c345/attachment.html From slavitch at gmail.com Wed Jan 25 13:46:31 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 25 Jan 2006 13:46:31 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43D7A75F.2000700@Research.Panasonic.COM> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> <43D7A75F.2000700@Research.Panasonic.COM> Message-ID: <1fc32c8f0601251046u2f72b41fx@mail.gmail.com> On 25/01/06, Sathya Narayanan wrote: This sounds to me like again trying to mandate things from another > working group. As was mentioned many times earlier, this is not possible > in IETF. So what happens when the results of other WG's are either absent, incomplete, or do not meet the requirements of the WG? Does the WG sit on its hands? > > > Given that the WG charter must then reflect that these are issues > > under the mandate of the WG. > > Please suggest the changes you think is needed. I don't think it is > possible to word your suggestions in a formal charter for a WG. > > regards, > Sathya > > > > > To date there is no formal RFC protocol that deals with NAT traversal > > for SIP signalling or RTP multimedia. What exists today is an > > Internet-draft that describes a set of methodologies that details > > related connection techniques while offering example call flows. It > > is still a tutorial that describes techniques. It has not to date > > been coalesced into a specific signalling protocol. This must change, > > and the sooner it is formalized the better. > > > > Changing this may require some effort on the part of the P2PSIP > > community. Unless a formalized broad protocol appears in the near > > term it appears that members of the P2PSIP community will have no > > choice but to begin the task of formalizing existing best practises > > into protocol descriptions that best meet specific P2PSIP > > requirements. This may result in a patchwork of standards that differ > > between classic SIP and P2P SIP. In any case a patchwork of formal > > standards is still better than no standards at all. > > > > > > Regards > > > > Michael > > > > > > On 24/01/06, *Sathya Narayanan* > > wrote: > > > > Michael Slavitch wrote: > > > > > > > > If by a certain date BEHAVE and MMUSIC has not finalized a > > solution > > > that meets the early milestone needs of the P2PSIP charter then > the > > > P2PSIP charter must include a provision that permits the WG to > > propose > > > a solution to BEHAVE and MMUSIC in the form of one or more > Internet > > > Drafts. > > > > I don't understand what you mean by "the WG to propose a solution to > > ...". AFAIK, there is no need for any provision in the charter for > > *participants* of P2PSIP WG to submit IDs to the BEHAVE or MMUSIC > WG. > > As Dean mentioned earlier, if we don't believe the existing > solutions > > are satisfactory, we (as individual IETF participants) should > > drive new > > requirements into the appropriate working group along with any > > proposed > > solutions. I don't see any reason to add a new provision to the > > proposed > > P2PSIP charter. > > > > - Sathya > > > > > In the absense of any other active or in place solutions the > > P2PSIP WG > > > should then request that these Internet Drafts be considered as a > > > potential solution by BEHAVE and MMUSIC for hindrance avoidance > and > > > multiparty media for P2PSIP sessions. In accordance with IETF > > > guidelines these drafts, once fully finalized and reviewed, > > would then > > > be submitted for elevation to full RFC status. > > > > > > > > > > The P2PSIP WG should always refer to appropriate prior solutions > > > finalized by BEHAVE and MMUSIC, whenever they exist. The goal > > is not > > > to replace the work of these working groups but instead provide > > > alternate proposals in cases where a finalized solution is for > > > whatever reason not forthcoming. > > > > > > > > > On 24/01/06, *Enrico Marocco* < enrico.marocco at tilab.com > > > > > > >> wrote: > > > > > > > > > If "something else" means "something we'll build", the > > latter doesn't > > > reconcile with the last phrase of the draft charter: > > "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." > > > > > > Since without such statement the charter wouldn't be > > accepted, we > > > MUST > > > look for solutions for hindrance avoidance and multiparty > media > > > session > > > control in behave and mmusic IETF working groups. > > > > > > >------------------------------------------------------------------------ > > > > > > > >_______________________________________________ > > >p2p-sip mailing list > > >p2p-sip at cs.columbia.edu > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > > > > > > > > -- > > Michael Slavitch > > Ottawa, Ontario Canada > > > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060125/1b5ca73b/attachment-0001.html From salman at cs.columbia.edu Wed Jan 25 15:28:14 2006 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Wed, 25 Jan 2006 15:28:14 -0500 (EST) Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> Message-ID: For a global SIP p2p/overlay network, STUN solves all the NAT problems until symmetric or UDP blocking NATs come in the picture. In those cases, relays are required and TURN can be used to get a public IP address from a well known TURN server. The P2P-SIP helps to discover those relays. The P2P-SIP relay discovery mechanism, IMO, must be explicitly described in the P2P-SIP draft. Relay discovery comes under the general problem of resource discovery; however it is important enough to be explicitly stated. The implementation requirement for relay discovery will perhaps be a MAY or SHOULD rather than MUST to cater for corporate fully natted scenarios. A UDP blocking NAT (which is very rare) requires media to travel over TCP. In corporates, only HTTP is typically allowed. I do not think that folks in IETF want to have NAT or firewall traversal over HTTP. There is a draft on 'Best Current Practices for NAT Traversal for SIP' available at: http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-03.txt Regards, Salman On Wed, 25 Jan 2006, Dean Willis wrote: > > On Jan 24, 2006, at 11:23 PM, Michael Slavitch wrote: > > > To date there is no formal RFC protocol that deals with NAT > > traversal for SIP signalling or RTP multimedia. What exists today > > is an Internet-draft that describes a set of methodologies that > > details related connection techniques while offering example call > > flows. It is still a tutorial that describes techniques. It has > > not to date been coalesced into a specific signalling protocol. > > This must change, and the sooner it is formalized the better. > > Ok, I may not know all your history here. > > But I do know a little bit about the history of NAT traversal and SIP. > > There are actually several key drafts, colloquially referred to as > STUN, TURN, ICE, and "outbound". STUN is actually a reasonably widely > implemented discrete protocol. TURN is not far behind. Outbound is a > signaling extension to SIP for providing persistent through-NAT > reflexive signaling. ICE is, as you describe it, a methodology for > combining the other techniques. There's a high level of urgency -- I > sat through the almost overnight ICE ad-hoc in Vancouver as the key > players worked through issue after issue. Sure, there's more work to > be done. But issuing an ultimatum from another working group isn't > going to make it go faster. > > And even if there were total agreement on every detail of these > specifications, and the drafts were completely final and blessed by > the working groups, IESG, and greater IETF, we'd still be over a year > from having a referable RFC. That's just the nature of IETF work > right now. > > The other problem is that there is no specific, formalized behavior > of NATs to write a "signalling protcocol" against. There are many > different sorts of NATs with a broad range of characteristics. We > have an entire group (BEHAVE) dedicated to sorting these > characteristics out. We have seen no evidence of any single traversal > protocol that works on all of them all the time. Sometimes you need a > relay element, sometimes you don't. Sometimes, about all you can do > is squeeze a tunnel through to a correspondent node that fronts all > the protocols for you. > > STUN helps us discover what we look like to the outside world. TURN > gives us a media relay. Outbound gives us a back-channel for > signaling, so that we can receive requests. ICE gives us a > methodology for bringing this all together in a way that, if not > perfect, is at least probably going to work. > > How does this relate to P2P-SIP? > > In a world without dedicated servers, how do we find something to run > STUN against so we can find out if we're NATed? How do we find and > make use of a peer that offers TURN relay services? How do we build > persistent signaling relationships with peers outside our NATs so > that they can get messages back to us, and how do our other peers > discover and re-use those relationships? These are the correspondent > and service discovery questions that have to be addressed so that SIP > can be made to do something useful in the P2P environments we seem to > agree are our targets. > > -- > Dean > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From aki.niemi at nokia.com Wed Jan 25 16:49:37 2006 From: aki.niemi at nokia.com (Aki Niemi) Date: Wed, 25 Jan 2006 23:49:37 +0200 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> Message-ID: <43D7F271.8070106@nokia.com> A few comments on the draft charter text. ext David A. Bryan wrote: > 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 of > using a hierarchy of proxies where the mapping of users to proxies is > determined by a combination of out-of-band and geographic mechanisms. The last sentence is a bit too sophisticated to efficiently communicate the message. How about simply saying that the conventional SIP approach 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. I find this a little hard to understand. I guess the meaning is to still use a username at domain construct for user ids, and that each domain's name is rooted in the DNS? If so, why not just say that? > 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. This isn't either or; perhaps it could also be mentioned that peers can very well sometimes be in disconnected mode, while other times in connected mode. In such cases, the names should have global scope in both modes. Maybe say that names should always have global scope? > 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 3262: > "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. I've come to dislike "architecture" or "framework" documents, but if they must be done, they must be done... > 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. > > While ensuring: > > 1. Security is addressed in these systems. > 2. Interoperability with existing client-server (CS) SIP and the PSTN. Mentioning the PSTN makes me uneasy, isn't "traditional" SIP enough here? Sounds like a draft about ISUP to P2PSIP mapping is otherwise sure follow ;) > 3. The solutions proposed will function even with 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. Hmm.. I understand this in terms of the charter being scoped to SIP only (initially), but this seems like cutting out a major part of where distributing or sharing resources actually is a big benefit. After all, running a SIP proxy is quite cheap; disk and cpu are cheap and SIP doesn't consume that much bandwidth. Running a TURN server then again is another thing entirely. I can't see a system that has distributed rendezvous having to resort to centralized media relays. Shouldn't this rather be included in the first iteration already? > 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 SIP-based communications. See my previous point. Otherwise sounds good. Cheers, Aki From slavitch at gmail.com Wed Jan 25 17:34:30 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Wed, 25 Jan 2006 17:34:30 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> Message-ID: <1fc32c8f0601251434p74999cf0j@mail.gmail.com> On 25/01/06, Dean Willis wrote: (snip) There's a high level of urgency -- I > sat through the almost overnight ICE ad-hoc in Vancouver as the key > players worked through issue after issue. Sure, there's more work to > be done. But issuing an ultimatum from another working group isn't > going to make it go faster. I agree. Ultimatums are never useful. But real milestones are. Delivery targets and milestones do matter and are very useful. Working towards an actual deadline and a real targeted date for delivery has implications that will influence the decisions and the milestones of several working groups. It doesn't matter if the actual deadline is missed. What matters is that exists a reasonable expectation that some solution will be at hand in a reasonable timeframes. And even if there were total agreement on every detail of these > specifications, and the drafts were completely final and blessed by > the working groups, IESG, and greater IETF, we'd still be over a year > from having a referable RFC. That's just the nature of IETF work > right now. Ok, that's the anticipated wg acceptance milestone date plus one year. Good. Now we're getting somewhere. Given that, what agreed-n date can anyone offer as a reasonable date for reaching a consensus? Is it in 2006? Is it in 2007? Is there any deadline or milestone at all, or can this discussion go on forever? I argue that a real deadline will force the issue enough such that consensus can be reached, and that this is for the general good. The other problem is that there is no specific, formalized behavior > of NATs to write a "signalling protcocol" against. There are many > different sorts of NATs with a broad range of characteristics. We > have an entire group (BEHAVE) dedicated to sorting these > characteristics out. We have seen no evidence of any single traversal > protocol that works on all of them all the time. Sometimes you need a > relay element, sometimes you don't. Sometimes, about all you can do > is squeeze a tunnel through to a correspondent node that fronts all > the protocols for you. The perfect is often the enemy of the good, and this appears to be one of those cases. Why can't there be individual responses to specific characteristics? Why can't these responses be defined as individual algorithms implemented as small, tractable RFC's? Why must we wait for one grand unification protocol that solves every case when solutions that work within specific boundries are well known and at hand, and are already implemented in a variety of proprietary solutions that are in wide use? How can it be that Skype is so smart and the IETF is so stuck? How can the IETF consider this to be intractable and ignore the obvious? Any more delay and the IETF effort won't matter at all, as the world will line up pretty please and pay happily for proprietary solutions from a variety of vendors, be they Skype or Damaka or Google or Microsoft. These solutions aren't perfect, but they exist and they are now setting the agenda from the perspective that matters, which is users and subsequently vendors. Inaction cannot be ignored away, and a real failure scenario, one where open standards get replaced by closed proprietary impementations, is a real and present danger. This will happen if the current pace continues. The world isn't waiting for the IETF to come up with a perfect solution. It may be fully satisfied by a Google API. How does the IETF respond to this? One way would be to start providing solutions that reduce the problem, and offer a plan for the future. With a timeline. For example the STUN discovery protocol is relatively simple. It spits back one of a fixed set of responses (if it can respond at all). The set of responses is thus finite, a simple state machine. This allows solutions to be catagorized. If solutions can be catagorized they can be externalized and the problem reduced. Why can't NAT traversal reference different solutions for different circumnstances, like here?: Case A: Local NAT type A, Remote NAT type B see RFC XXXA (negotiation) Case B: Local NAT type B, Remote NAT type A see RFC XXXB (negotiation) Case C: Local NAT type C, Remote NAT type D,see RFC XXXC (negotiation) Case D: Local NAT type D, Remote NAT type D,see RFC XXXD (relay) Case E: Local NAT type E, Remote NAT type Y; solution not there yet but on the way. fail. Case X: Local NAT type BAD. Remote NAT type don't care. Exception. No can do. Fail. Case Z: No answer to STUN request. Fail. Sorry. Assume that this is implemented in a product called 'foo' Implementation 'foo" supports NAT types A,B,C,D as described in RFC XXXX, XXXA, XXXB, XXXC, XXXD.. This summary is what would go on a data sheet. It sets reasonable expectations. Customers and vendors are happy enough that they avoid doing something else, something like a closed solution from a single vendor. Why can't a NAT traversal solution based on a relatively simple well formed NAT discovery technique (using STUN, either in line or not) reference one or more outside algorithm as the appropriate response? Such output may not offer a perfect answer, but it is a partial solution that can be delivered in short order, and as additional solutions come along they can be added to the list. It solves most of the problems that we face today, it describes failure modes accurately, users will live with it until improvements come along. It also stands a much better chance of being implemented by engineers. They need a basic specification to work from. Remember that ICE may be implemented in simple commodity hardware that has restricted capabilities. Parsing XML may not be one of them. Even if it takes a year just to get to consensus it still offers a deliverable that will forestall a purely proprietary world for which the IETF currently has no answer. I agree that the BEHAVE group has no solution for all cases. But it has solutions for MOST cases. Why aren't these being put forward in the meantime as a set of NAT traversal standards for which there are solutions and leave the art of the perfect for later? > STUN helps us discover what we look like to the outside world. TURN > gives us a media relay. Outbound gives us a back-channel for > signaling, so that we can receive requests. ICE gives us a > methodology for bringing this all together in a way that, if not > perfect, is at least probably going to work. See above. I agree. What I propose is that this be made as deterministic as is possible using protocols that are as simple as is possible, continually reducing the problem domain. In a world without dedicated servers, how do we find something to run STUN against so we can find out if we're NATed? How do we find and > make use of a peer that offers TURN relay services? How do we build > persistent signaling relationships with peers outside our NATs so > that they can get messages back to us, and how do our other peers > discover and re-use those relationships? These are the correspondent > and service discovery questions that have to be addressed so that SIP > can be made to do something useful in the P2P environments we seem to > agree are our targets. Good question. What is above is a my 2c example of an answer. The outside state machine could be modified for a P2P SIP world (perhaps using some kind of base certificate-obtained "seed", but that's not for now) where discovery processes replace value parameters. In most cases it would invoke the same RFCs as for regular SIP, but (as an example) relay cases the algorithm could then point to a peer discovery algorithm, possibly defined as another RFC, that returns a resulting value, instead of immediately using a relay based on some present known value. It would then get the ball rolling with that relay in the same way that regular SIP does. The big difference between classic SIP and P2PSIP could then be largely one of using known fixed values vs using the results of discovery processes that meet some rule criteria. SIP has "use relay x" where X is a scalar value. P2PSIP could have "discover relays and use the one that meets certain rules", where the rules are such things as: "Only use peers, never dedicated hosts" "never from canonically Evil Vendor M, maybe from usually Good Vendor G but not if it is in France" and finally "please use first good result unless congested otherwise choose randomly from first ten results". I wonder if someone from Google is watching this discussion. They could offer good input. The SIP of today sees parameters such as hosts as values while P2PSIP may see these as references to one or more discovery processes. The underlying NAT traversal solutions for individual NAT cases would then be unchanged and reused, as they reflect the connection not the connecting entities. Most of SIP could then be reused, replacing value parameters with discovery processes and rule definitions. Given this scenario P2PSIP would ultimately behave just like regular ol' SIP given the right circumstances, in cases where discovery algorithms return known values. No reinventing the wheel. Now that would be interesting. Regards Michael -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060125/00e32a88/attachment-0001.html From sathya at research.panasonic.com Thu Jan 26 10:29:08 2006 From: sathya at research.panasonic.com (Sathya Narayanan) Date: Thu, 26 Jan 2006 10:29:08 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601251046u2f72b41fx@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> <43D7A75F.2000700@Research.Panasonic.COM> <1fc32c8f0601251046u2f72b41fx@mail.gmail.com> Message-ID: <43D8EAC4.20204@Research.Panasonic.COM> Michael Slavitch wrote: > > > On 25/01/06, *Sathya Narayanan* > wrote: > > > > This sounds to me like again trying to mandate things from another > working group. As was mentioned many times earlier, this is not > possible > in IETF. > > > > So what happens when the results of other WG's are either absent, > incomplete, or do not meet the requirements of the WG? > > Does the WG sit on its hands? No. As was mentioned many times before, individual participants from the P2PSIP WG should participate and drive the requirements through the other WG. > > > > > > > Given that the WG charter must then reflect that these are issues > > under the mandate of the WG. > > Please suggest the changes you think is needed. I don't think it is > possible to word your suggestions in a formal charter for a WG. > > regards, > Sathya > > > > > To date there is no formal RFC protocol that deals with NAT > traversal > > for SIP signalling or RTP multimedia. What exists today is an > > Internet-draft that describes a set of methodologies that details > > related connection techniques while offering example call flows. It > > is still a tutorial that describes techniques. It has not to date > > been coalesced into a specific signalling protocol. This must > change, > > and the sooner it is formalized the better. > > > > Changing this may require some effort on the part of the P2PSIP > > community. Unless a formalized broad protocol appears in the near > > term it appears that members of the P2PSIP community will have no > > choice but to begin the task of formalizing existing best practises > > into protocol descriptions that best meet specific P2PSIP > > requirements. This may result in a patchwork of standards that > differ > > between classic SIP and P2P SIP. In any case a patchwork of formal > > standards is still better than no standards at all. > > > > > > Regards > > > > Michael > > > > > > On 24/01/06, *Sathya Narayanan* < sathya at research.panasonic.com > > > > > wrote: > > > > Michael Slavitch wrote: > > > > > > > > If by a certain date BEHAVE and MMUSIC has not finalized a > > solution > > > that meets the early milestone needs of the P2PSIP charter > then the > > > P2PSIP charter must include a provision that permits the WG to > > propose > > > a solution to BEHAVE and MMUSIC in the form of one or more > Internet > > > Drafts. > > > > I don't understand what you mean by "the WG to propose a > solution to > > ...". AFAIK, there is no need for any provision in the > charter for > > *participants* of P2PSIP WG to submit IDs to the BEHAVE or > MMUSIC WG. > > As Dean mentioned earlier, if we don't believe the existing > solutions > > are satisfactory, we (as individual IETF participants) should > > drive new > > requirements into the appropriate working group along with any > > proposed > > solutions. I don't see any reason to add a new provision to the > > proposed > > P2PSIP charter. > > > > - Sathya > > > > > In the absense of any other active or in place solutions the > > P2PSIP WG > > > should then request that these Internet Drafts be > considered as a > > > potential solution by BEHAVE and MMUSIC for hindrance > avoidance and > > > multiparty media for P2PSIP sessions. In accordance with > IETF > > > guidelines these drafts, once fully finalized and reviewed, > > would then > > > be submitted for elevation to full RFC status. > > > > > > > > > > The P2PSIP WG should always refer to appropriate prior > solutions > > > finalized by BEHAVE and MMUSIC, whenever they exist. The goal > > is not > > > to replace the work of these working groups but instead > provide > > > alternate proposals in cases where a finalized solution is > for > > > whatever reason not forthcoming. > > > > > > > > > On 24/01/06, *Enrico Marocco* < enrico.marocco at tilab.com > > > > > > > > > >>> wrote: > > > > > > > > > If "something else" means "something we'll build", the > > latter doesn't > > > reconcile with the last phrase of the draft charter: > > "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." > > > > > > Since without such statement the charter wouldn't be > > accepted, we > > > MUST > > > look for solutions for hindrance avoidance and > multiparty media > > > session > > > control in behave and mmusic IETF working groups. > > > > > > >------------------------------------------------------------------------ > > > > > > > >_______________________________________________ > > >p2p-sip mailing list > > >p2p-sip at cs.columbia.edu > > > > > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > > > > > > > > > > > > > > > > -- > > Michael Slavitch > > Ottawa, Ontario Canada > > > > > > -- > Michael Slavitch > Ottawa, Ontario Canada From philip_matthews at magma.ca Thu Jan 26 14:23:30 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 26 Jan 2006 14:23:30 -0500 Subject: [p2p-sip] Using results from the IRTF P2P Research Group In-Reply-To: <200601251733.k0PHX0KG019527@cs.columbia.edu> References: <200601251733.k0PHX0KG019527@cs.columbia.edu> Message-ID: Henry: The current charter draft (as posted by David) has the text "The working group will operate in close cooperation with the SIP, SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF." Is this sufficient? I am thinking that, since the P2P SIP WG will also need to use the insights and results of other working groups (such as the insights and results of the BEHAVE group on NAT traversal), singling out the P2PRG more explicitly with a longer statement might be out-of-place. What do you think? - Philip On 25-Jan-06, at 12:32 , Henry Sinnreich wrote: > I suggest to add to the charter text something like this: > > The P2P SIP WG will use, where applicable, the insights and the > results from > the work of the P2P IRTF Group for such topics as generic > requirements for > P2P and P2P resource and service discovery protocols, see > http://www.irtf.org/charter.php > > Thanks, Henry > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From henry at pulver.com Thu Jan 26 14:37:59 2006 From: henry at pulver.com (Henry Sinnreich) Date: Thu, 26 Jan 2006 13:37:59 -0600 Subject: [p2p-sip] Using results from the IRTF P2P Research Group In-Reply-To: Message-ID: <200601261938.k0QJc2KG019320@cs.columbia.edu> "The working group will operate in close cooperation with the SIP, SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF." Yes, this is sufficient. Thanks, Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews at magma.ca] Sent: Thursday, January 26, 2006 1:23 PM To: henry at pulver.com Cc: David A. Bryan; P2P-SIP Subject: Re: [p2p-sip] Using results from the IRTF P2P Research Group Henry: The current charter draft (as posted by David) has the text "The working group will operate in close cooperation with the SIP, SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF." Is this sufficient? I am thinking that, since the P2P SIP WG will also need to use the insights and results of other working groups (such as the insights and results of the BEHAVE group on NAT traversal), singling out the P2PRG more explicitly with a longer statement might be out-of-place. What do you think? - Philip On 25-Jan-06, at 12:32 , Henry Sinnreich wrote: > I suggest to add to the charter text something like this: > > The P2P SIP WG will use, where applicable, the insights and the > results from > the work of the P2P IRTF Group for such topics as generic > requirements for > P2P and P2P resource and service discovery protocols, see > http://www.irtf.org/charter.php > > Thanks, Henry > > _______________________________________________ > 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 Thu Jan 26 14:39:05 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 26 Jan 2006 14:39:05 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601251434p74999cf0j@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> Message-ID: Michael: It is not clear to me what you are proposing. In the draft charter that David Bryan posted, there are some concrete deliverables listed, and the milestones section proposes some concrete dates. I had a hand in suggesting these deliverables and dates, and I feel they are reasonable and achievable. Do you have some proposals for text modifications that would reflect your concerns? - Philip On 25-Jan-06, at 17:34 , Michael Slavitch wrote: > On 25/01/06, Dean Willis wrote: > > (snip) > > > There's a high level of urgency -- I > sat through the almost overnight ICE ad-hoc in Vancouver as the key > players worked through issue after issue. Sure, there's more work to > be done. But issuing an ultimatum from another working group isn't > going to make it go faster. > > > I agree. Ultimatums are never useful. But real milestones are. > > Delivery targets and milestones do matter and are very useful. > Working towards an actual deadline and a real targeted date for > delivery has implications that will influence the decisions and the > milestones of several working groups. It doesn't matter if the > actual deadline is missed. What matters is that exists a > reasonable expectation that some solution will be at hand in a > reasonable timeframes. > > > And even if there were total agreement on every detail of these > specifications, and the drafts were completely final and blessed by > the working groups, IESG, and greater IETF, we'd still be over a year > from having a referable RFC. That's just the nature of IETF work > right now. > > Ok, that's the anticipated wg acceptance milestone date plus one > year. Good. Now we're getting somewhere. Given that, what agreed- > n date can anyone offer as a reasonable date for reaching a > consensus? Is it in 2006? Is it in 2007? Is there any deadline or > milestone at all, or can this discussion go on forever? I argue > that a real deadline will force the issue enough such that > consensus can be reached, and that this is for the general good. > > > The other problem is that there is no specific, formalized behavior > of NATs to write a "signalling protcocol" against. There are many > different sorts of NATs with a broad range of characteristics. We > have an entire group (BEHAVE) dedicated to sorting these > characteristics out. We have seen no evidence of any single traversal > protocol that works on all of them all the time. Sometimes you need a > relay element, sometimes you don't. Sometimes, about all you can do > is squeeze a tunnel through to a correspondent node that fronts all > the protocols for you. > > > The perfect is often the enemy of the good, and this appears to be > one of those cases. > > Why can't there be individual responses to specific > characteristics? Why can't these responses be defined as > individual algorithms implemented as small, tractable RFC's? Why > must we wait for one grand unification protocol that solves every > case when solutions that work within specific boundries are well > known and at hand, and are already implemented in a variety of > proprietary solutions that are in wide use? > > How can it be that Skype is so smart and the IETF is so stuck? How > can the IETF consider this to be intractable and ignore the obvious? > Any more delay and the IETF effort won't matter at all, as the > world will line up pretty please and pay happily for proprietary > solutions from a variety of vendors, be they Skype or Damaka or > Google or Microsoft. These solutions aren't perfect, but they > exist and they are now setting the agenda from the perspective that > matters, which is users and subsequently vendors. Inaction cannot > be ignored away, and a real failure scenario, one where open > standards get replaced by closed proprietary impementations, is a > real and present danger. This will happen if the current pace > continues. The world isn't waiting for the IETF to come up with a > perfect solution. It may be fully satisfied by a Google API. > > How does the IETF respond to this? One way would be to start > providing solutions that reduce the problem, and offer a plan for > the future. > With a timeline. > > For example the STUN discovery protocol is relatively simple. > It spits back one of a fixed set of responses (if it can respond at > all). > The set of responses is thus finite, a simple state machine. > > This allows solutions to be catagorized. If solutions can be > catagorized they can be externalized and the problem reduced. > > Why can't NAT traversal reference different solutions for different > circumnstances, like here?: > > Case A: Local NAT type A, Remote NAT type B see RFC XXXA (negotiation) > Case B: Local NAT type B, Remote NAT type A see RFC XXXB (negotiation) > Case C: Local NAT type C, Remote NAT type D,see RFC XXXC (negotiation) > Case D: Local NAT type D, Remote NAT type D,see RFC XXXD (relay) > Case E: Local NAT type E, Remote NAT type Y; solution not there yet > but on the way. fail. > Case X: Local NAT type BAD. Remote NAT type don't care. Exception. > No can do. Fail. > Case Z: No answer to STUN request. Fail. Sorry. > > Assume that this is implemented in a product called 'foo' > > Implementation 'foo" supports NAT types A,B,C,D as described in RFC > XXXX, XXXA, XXXB, XXXC, XXXD.. > > This summary is what would go on a data sheet. It sets reasonable > expectations. Customers and vendors are happy enough that they > avoid doing something else, something like a closed solution from a > single vendor. > > Why can't a NAT traversal solution based on a relatively simple > well formed NAT discovery technique (using STUN, either in line or > not) reference one or more outside algorithm as the appropriate > response? Such output may not offer a perfect answer, but it is a > partial solution that can be delivered in short order, and as > additional solutions come along they can be added to the list. It > solves most of the problems that we face today, it describes > failure modes accurately, users will live with it until > improvements come along. It also stands a much better chance of > being implemented by engineers. They need a basic specification > to work from. Remember that ICE may be implemented in simple > commodity hardware that has restricted capabilities. Parsing XML > may not be one of them. > > Even if it takes a year just to get to consensus it still offers a > deliverable that will forestall a purely proprietary world for > which the IETF currently has no answer. > > I agree that the BEHAVE group has no solution for all cases. But > it has solutions for MOST cases. Why aren't these being put forward > in the meantime as a set of NAT traversal standards for which there > are solutions and leave the art of the perfect for later? > > STUN helps us discover what we look like to the outside world. TURN > gives us a media relay. Outbound gives us a back-channel for > signaling, so that we can receive requests. ICE gives us a > methodology for bringing this all together in a way that, if not > perfect, is at least probably going to work. > > > See above. I agree. What I propose is that this be made as > deterministic as is possible using protocols that are as simple as > is possible, > continually reducing the problem domain. > > > In a world without dedicated servers, how do we find something > to run > STUN against so we can find out if we're NATed? How do we find and > make use of a peer that offers TURN relay services? How do we build > persistent signaling relationships with peers outside our NATs so > that they can get messages back to us, and how do our other peers > discover and re-use those relationships? These are the correspondent > and service discovery questions that have to be addressed so that SIP > can be made to do something useful in the P2P environments we seem to > agree are our targets. > > > > > Good question. What is above is a my 2c example of an answer. The > outside state machine could be modified for a P2P SIP world > (perhaps using some kind of base certificate-obtained "seed", but > that's not for now) where discovery processes replace value > parameters. > > In most cases it would invoke the same RFCs as for regular SIP, but > (as an example) relay cases the algorithm could then point to a > peer discovery algorithm, possibly defined as another RFC, that > returns a resulting value, instead of immediately using a relay > based on some present known value. It would then get the ball > rolling with that relay in the same way that regular SIP does. > > The big difference between classic SIP and P2PSIP could then be > largely one of using known fixed values vs using the results of > discovery processes that meet some rule criteria. > > SIP has "use relay x" where X is a scalar value. > > P2PSIP could have "discover relays and use the one that meets > certain rules", > where the rules are such things as: > > "Only use peers, never dedicated hosts" > "never from canonically Evil Vendor M, maybe from usually Good > Vendor G but not if it is in France" and finally > "please use first good result unless congested otherwise choose > randomly from first ten results". > > I wonder if someone from Google is watching this discussion. They > could offer good input. > > The SIP of today sees parameters such as hosts as values while > P2PSIP may see these as references to one or more discovery > processes. The underlying NAT traversal solutions for individual > NAT cases would then be unchanged and reused, as they reflect the > connection not the connecting entities. Most of SIP could then be > reused, replacing value parameters with discovery processes and > rule definitions. > > Given this scenario P2PSIP would ultimately behave just like > regular ol' SIP given the right circumstances, in cases where > discovery algorithms return known values. No reinventing the > wheel. Now that would be interesting. > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060126/3357cd43/attachment-0001.html From philip_matthews at magma.ca Thu Jan 26 15:10:58 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Thu, 26 Jan 2006 15:10:58 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43D7F271.8070106@nokia.com> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> <43D7F271.8070106@nokia.com> Message-ID: <9A778D09-9FD6-4B0F-B618-D11C00366636@magma.ca> Aki: Thanks very much for your specific comments on the proposed charter text. As one of those who worked on the draft text, having specific comments like this is very helpful. See comments inline. - Philip On 25-Jan-06, at 16:49 , Aki Niemi wrote: > A few comments on the draft charter text. > > ext David A. Bryan wrote: >> 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 of >> using a hierarchy of proxies where the mapping of users to proxies is >> determined by a combination of out-of-band and geographic mechanisms. > > The last sentence is a bit too sophisticated to efficiently > communicate > the message. How about simply saying that the conventional SIP > approach > relies on service provider hosted proxies to which users get > assigned by > out-of-band means, usually based on geography, association or business > reasons. If I understand your proposal, then you are suggesting that the last sentence be replaced with "This is an alternative to the conventional SIP approach of relying of service provider hosted proxies to which users get assigned by out-of-band means, usually based on geography, association or business reasons." I don't personally object to the proposed rewording, though I am not sure this is really better. > >> 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. > > I find this a little hard to understand. I guess the meaning is to > still > use a username at domain construct for user ids, and that each domain's > name is rooted in the DNS? If so, why not just say that? > >> 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. > > This isn't either or; perhaps it could also be mentioned that peers > can > very well sometimes be in disconnected mode, while other times in > connected mode. In such cases, the names should have global scope in > both modes. > > Maybe say that names should always have global scope? I would personally be reluctant to say in the charter that names must always have global scope until I better understood the implications of that statement. Currently, I suspect that having user and resource names which are unique only within a specific P2P-SIP network are much more realistic. > >> 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 3262: >> "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. > > I've come to dislike "architecture" or "framework" documents, but if > they must be done, they must be done... In this case, I think that it is essential that the working group work on such document(s). However, it may be that we do not need to publish them as RFCs. (Personally, I think it would be good to have them as RFCs, but I can see the arguments for not doing so). > >> 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. >> >> While ensuring: >> >> 1. Security is addressed in these systems. >> 2. Interoperability with existing client-server (CS) SIP and the >> PSTN. > > Mentioning the PSTN makes me uneasy, isn't "traditional" SIP enough > here? Sounds like a draft about ISUP to P2PSIP mapping is otherwise > sure > follow ;) This is a good point. I would be happy if moved PSTN interoperability to the "after a possible rechartering" section. > >> 3. The solutions proposed will function even with 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. > > Hmm.. I understand this in terms of the charter being scoped to SIP > only > (initially), but this seems like cutting out a major part of where > distributing or sharing resources actually is a big benefit. > > After all, running a SIP proxy is quite cheap; disk and cpu are cheap > and SIP doesn't consume that much bandwidth. Running a TURN server > then > again is another thing entirely. I can't see a system that has > distributed rendezvous having to resort to centralized media relays. > > Shouldn't this rather be included in the first iteration already? I believe that we really need to have a small set of deliverables for the initial charter, otherwise the charter won't get past the IESG. In my opinion, only really essential stuff should be part of the first set of deliverables. So, for example, I am personally very interested in item 3 below (voicemail), but I am not objecting to leaving it for after a re-charter because I don't consider it "essential". In my opinion, item 1 (distributed media relays) are also not essential and should wait until after a re-charter. Does this make sense? Do you agree? > >> 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 SIP-based communications. > > See my previous point. > > Otherwise sounds good. > > Cheers, > Aki > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip From aki.niemi at nokia.com Thu Jan 26 17:12:10 2006 From: aki.niemi at nokia.com (Aki Niemi) Date: Fri, 27 Jan 2006 00:12:10 +0200 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <9A778D09-9FD6-4B0F-B618-D11C00366636@magma.ca> References: <8b2769930601162130q44de8ac7x960d275b1534b199@mail.gmail.com> <43D7F271.8070106@nokia.com> <9A778D09-9FD6-4B0F-B618-D11C00366636@magma.ca> Message-ID: <43D9493A.9050608@nokia.com> Inline. ext Philip Matthews wrote: >> The last sentence is a bit too sophisticated to efficiently communicate >> the message. How about simply saying that the conventional SIP approach >> relies on service provider hosted proxies to which users get assigned by >> out-of-band means, usually based on geography, association or business >> reasons. > > If I understand your proposal, then you are suggesting that the last > sentence be replaced with > "This is an alternative to the conventional SIP approach of > relying of service provider hosted proxies to which users get assigned by s/of/on > out-of-band means, usually based on geography, association or business > reasons." Yes. > I don't personally object to the proposed rewording, though I am not > sure this is really better. Well, I think it is clearer this way. >>> 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. >> >> I find this a little hard to understand. I guess the meaning is to still >> use a username at domain construct for user ids, and that each domain's >> name is rooted in the DNS? If so, why not just say that? >> >>> 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. >> >> This isn't either or; perhaps it could also be mentioned that peers can >> very well sometimes be in disconnected mode, while other times in >> connected mode. In such cases, the names should have global scope in >> both modes. >> >> Maybe say that names should always have global scope? > > I would personally be reluctant to say in the charter that names must > always have global > scope until I better understood the implications of that statement. > Currently, > I suspect that having user and resource names which are unique only within > a specific P2P-SIP network are much more realistic. My point is that nodes can move around and be part of both disconnected and connected overlays. It probably makes sense for that node to use the same name in each scenario, and that name to not collide with other names. >> Hmm.. I understand this in terms of the charter being scoped to SIP only >> (initially), but this seems like cutting out a major part of where >> distributing or sharing resources actually is a big benefit. >> >> After all, running a SIP proxy is quite cheap; disk and cpu are cheap >> and SIP doesn't consume that much bandwidth. Running a TURN server then >> again is another thing entirely. I can't see a system that has >> distributed rendezvous having to resort to centralized media relays. >> >> Shouldn't this rather be included in the first iteration already? > > I believe that we really need to have a small set of deliverables for > the initial charter, > otherwise the charter won't get past the IESG. In my opinion, only > really essential stuff > should be part of the first set of deliverables. So, for example, I am > personally very interested > in item 3 below (voicemail), but I am not objecting to leaving it for > after a re-charter > because I don't consider it "essential". > > In my opinion, item 1 (distributed media relays) are also not essential and > should wait until after a re-charter. > > Does this make sense? Do you agree? Voicemail is hardly an essential feature. But media relays are needed to get around the most difficult middleboxes. What fraction of nodes are we expecting to live behind such boxes, and by not counting those in does it represent a complete enough solution? Because I just can't see a P2PSIP that requires centralized media relays to work properly getting off the ground (any better than traditional SIP). Cheers, Aki From slavitch at gmail.com Thu Jan 26 23:32:09 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Thu, 26 Jan 2006 23:32:09 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> Message-ID: <1fc32c8f0601262032u9521d1et@mail.gmail.com> The existing statement, as written, works very well for the protocols defined by the SIP, SIPPING, and SIMPLE working groups. In those cases the P2PSIP WG will exploit methods that either already exist in broad use as public protocols, are enhancements that exploit or extend existing protocols, or are in such an early stage that their absence will not impact core P2PSIP WG charter goals. Any remaining open questions are either part of the basic P2PSIP WG scope or can be deferred without jeopardy P2PSIP has a dependency on SIP standards, but a broad enough SIP ecosystem already exists such that P2PSIP can meet its goals using methods already defined by that ecosystem with minimal enhancements and changes. P2PSIP likely can't exist without SIP, but SIP already exists so this is not an issue. This is not true in the case of NAT traversal. The ability to do NAT traversal is a core requirement for P2PSIP entities. Its absence jeopardizes the ability of the WG to meet one of its key pressing goals. Nothing else matters if peers can't communicate through NAT firewalls. The success of P2PSIP largely depends on an item that is largely not within its own mandate for which there is no current public standards based solution, no matter how partial or interim. This not about extensions or changes. You cannot extend or change something that does yet not exist. What the WG can do is investigate how NAT traversal is used by P2PSIP, when, and describe its implementation requirements. The requirements for NAT traversal that the MMUSIC WG has set for itself may be very different than the requirements needed to meet the basic charter goals for P2PSIP. The MMUSIC and BEHAVE working groups are working on developing a general solution for NAT traversal that ideally works in all cases. The problem itself may well be intractable, there may be no general solution. This is not known yet. A general solution is still an open research topic, something that is normally out of the scope of the IETF. Like someone said earlier, the IETF is not about research, it is about developing solutions and practises that can be defined as implementable and interoperable standard protocols. The absence of a a general solution for a problem should not prevent partial solutions from being developed and defined in the meantime, especially if the partial solution does not preclude the inclusion of a general solution if and when such a solution becomes available. MMUSIC has done excellent work in describing methodologies that perform NAT traversal. The P2PSIP WG should investigate how best to exploit them and define the acceptable practical limits of any proposed solution. Any enhancements or changes that result from this would be offered to the affected working groups for their consideration. I believe that this issue is so important that an investigation into how NAT traversal techniques are to be implemented by P2PSIP entities should become part of the basic scope of the WG charter and one of the initial activities of the group. Naturally in keeping with the principles of the IETF this investigation will be based on existing MMUSIC work. This investigation should produce a deliverable with a milestone of August 2006 that specifies the basic functional NAT traversal requirements for P2PSIP that are in keeping with the concurrent use-case document. These requirements would then be passed on to the MMUSIC WG for their consideration, as well as any other affected groups. At that time individuals may choose to contribute proposed implementations that meet these requirements to the affected groups. Given the above, I would add this line to the statement of activities (after item 4, an equivalent item regarding SIP Extensions) 5. Investigate how NAT traversal techniques as described by MMUSIC are to be implemented by P2PSIP. Define requirements for enhancements, protocols, or partial interim solutions for submission to all affected IETF working groups. And add the following milestone, concurrent with the use-case document. Aug 2006 Submit Preliminary Functional Requirements For Meeting Proposed Use Cases to affected IETF working groups for their consideration. These changes would give the underlying NAT problem the attention it deserves. Regards, Michael On 26/01/06, Philip Matthews wrote: > > Michael: > It is not clear to me what you are proposing. > > In the draft charter that David Bryan posted, there are some concrete > deliverables > listed, and the milestones section proposes some concrete dates. > I had a hand in suggesting these deliverables and dates, and I feel they > are reasonable and achievable. > > Do you have some proposals for text modifications that would reflect your > concerns? > > - Philip > > > > > On 25-Jan-06, at 17:34 , Michael Slavitch wrote: > > On 25/01/06, Dean Willis wrote: > > (snip) > > > There's a high level of urgency -- I > > sat through the almost overnight ICE ad-hoc in Vancouver as the key > > players worked through issue after issue. Sure, there's more work to > > be done. But issuing an ultimatum from another working group isn't > > going to make it go faster. > > > > I agree. Ultimatums are never useful. But real milestones are. > > Delivery targets and milestones do matter and are very useful. Working > towards an actual deadline and a real targeted date for delivery has > implications that will influence the decisions and the milestones of several > working groups. It doesn't matter if the actual deadline is missed. What > matters is that exists a reasonable expectation that some solution will be > at hand in a reasonable timeframes. > > > And even if there were total agreement on every detail of these > > specifications, and the drafts were completely final and blessed by > > the working groups, IESG, and greater IETF, we'd still be over a year > > from having a referable RFC. That's just the nature of IETF work > > right now. > > > Ok, that's the anticipated wg acceptance milestone date plus one year. > Good. Now we're getting somewhere. Given that, what agreed-n date can > anyone offer as a reasonable date for reaching a consensus? Is it in 2006? > Is it in 2007? Is there any deadline or milestone at all, or can this > discussion go on forever? I argue that a real deadline will force the issue > enough such that consensus can be reached, and that this is for the general > good. > > > The other problem is that there is no specific, formalized behavior > > of NATs to write a "signalling protcocol" against. There are many > > different sorts of NATs with a broad range of characteristics. We > > have an entire group (BEHAVE) dedicated to sorting these > > characteristics out. We have seen no evidence of any single traversal > > protocol that works on all of them all the time. Sometimes you need a > > relay element, sometimes you don't. Sometimes, about all you can do > > is squeeze a tunnel through to a correspondent node that fronts all > > the protocols for you. > > > > The perfect is often the enemy of the good, and this appears to be one of > those cases. > > Why can't there be individual responses to specific characteristics? Why > can't these responses be defined as individual algorithms implemented as > small, tractable RFC's? Why must we wait for one grand unification protocol > that solves every case when solutions that work within specific boundries > are well known and at hand, and are already implemented in a variety of > proprietary solutions that are in wide use? > > How can it be that Skype is so smart and the IETF is so stuck? How can > the IETF consider this to be intractable and ignore the obvious? > Any more delay and the IETF effort won't matter at all, as the world will > line up pretty please and pay happily for proprietary solutions from a > variety of vendors, be they Skype or Damaka or Google or Microsoft. These > solutions aren't perfect, but they exist and they are now setting the agenda > from the perspective that matters, which is users and subsequently vendors. > Inaction cannot be ignored away, and a real failure scenario, one where open > standards get replaced by closed proprietary impementations, is a real and > present danger. This will happen if the current pace continues. The world > isn't waiting for the IETF to come up with a perfect solution. It may be > fully satisfied by a Google API. > > How does the IETF respond to this? One way would be to start providing > solutions that reduce the problem, and offer a plan for the future. > With a timeline. > > For example the STUN discovery protocol is relatively simple. > It spits back one of a fixed set of responses (if it can respond at all). > The set of responses is thus finite, a simple state machine. > > This allows solutions to be catagorized. If solutions can be catagorized > they can be externalized and the problem reduced. > > Why can't NAT traversal reference different solutions for different > circumnstances, like here?: > > Case A: Local NAT type A, Remote NAT type B see RFC XXXA (negotiation) > Case B: Local NAT type B, Remote NAT type A see RFC XXXB (negotiation) > Case C: Local NAT type C, Remote NAT type D,see RFC XXXC (negotiation) > Case D: Local NAT type D, Remote NAT type D,see RFC XXXD (relay) > Case E: Local NAT type E, Remote NAT type Y; solution not there yet but on > the way. fail. > Case X: Local NAT type BAD. Remote NAT type don't care. Exception. No can > do. Fail. > Case Z: No answer to STUN request. Fail. Sorry. > > Assume that this is implemented in a product called 'foo' > > Implementation 'foo" supports NAT types A,B,C,D as described in RFC XXXX, > XXXA, XXXB, XXXC, XXXD.. > > This summary is what would go on a data sheet. It sets reasonable > expectations. Customers and vendors are happy enough that they avoid doing > something else, something like a closed solution from a single vendor. > > Why can't a NAT traversal solution based on a relatively simple well > formed NAT discovery technique (using STUN, either in line or not) > reference one or more outside algorithm as the appropriate response? Such > output may not offer a perfect answer, but it is a partial solution that can > be delivered in short order, and as additional solutions come along they can > be added to the list. It solves most of the problems that we face today, > it describes failure modes accurately, users will live with it until > improvements come along. It also stands a much better chance of being > implemented by engineers. They need a basic specification to work from. > Remember that ICE may be implemented in simple commodity hardware that has > restricted capabilities. Parsing XML may not be one of them. > > Even if it takes a year just to get to consensus it still offers a > deliverable that will forestall a purely proprietary world for which the > IETF currently has no answer. > > I agree that the BEHAVE group has no solution for all cases. But it has > solutions for MOST cases. Why aren't these being put forward in the meantime > as a set of NAT traversal standards for which there are solutions and leave > the art of the perfect for later? > > > > STUN helps us discover what we look like to the outside world. TURN > > gives us a media relay. Outbound gives us a back-channel for > > signaling, so that we can receive requests. ICE gives us a > > methodology for bringing this all together in a way that, if not > > perfect, is at least probably going to work. > > > > See above. I agree. What I propose is that this be made as deterministic > as is possible using protocols that are as simple as is possible, > continually reducing the problem domain. > > > In a world without dedicated servers, how do we find something to run > STUN against so we can find out if we're NATed? How do we find and > > > make use of a peer that offers TURN relay services? How do we build > > persistent signaling relationships with peers outside our NATs so > > that they can get messages back to us, and how do our other peers > > discover and re-use those relationships? These are the correspondent > > and service discovery questions that have to be addressed so that SIP > > can be made to do something useful in the P2P environments we seem to > > agree are our targets. > > > > > > Good question. What is above is a my 2c example of an answer. The outside > state machine could be modified for a P2P SIP world (perhaps using some kind > of base certificate-obtained "seed", but that's not for now) where discovery > processes replace value parameters. > > In most cases it would invoke the same RFCs as for regular SIP, but (as an > example) relay cases the algorithm could then point to a peer discovery > algorithm, possibly defined as another RFC, that returns a resulting value, > instead of immediately using a relay based on some present known value. It > would then get the ball rolling with that relay in the same way that regular > SIP does. > > The big difference between classic SIP and P2PSIP could then be largely > one of using known fixed values vs using the results of discovery processes > that meet some rule criteria. > > SIP has "use relay x" where X is a scalar value. > > P2PSIP could have "discover relays and use the one that meets certain > rules", > where the rules are such things as: > > "Only use peers, never dedicated hosts" > "never from canonically Evil Vendor M, maybe from usually Good Vendor G > but not if it is in France" and finally > "please use first good result unless congested otherwise choose randomly > from first ten results". > > I wonder if someone from Google is watching this discussion. They could > offer good input. > > The SIP of today sees parameters such as hosts as values while P2PSIP may > see these as references to one or more discovery processes. The underlying > NAT traversal solutions for individual NAT cases would then be unchanged and > reused, as they reflect the connection not the connecting entities. Most > of SIP could then be reused, replacing value parameters with discovery > processes and rule definitions. > > Given this scenario P2PSIP would ultimately behave just like regular ol' > SIP given the right circumstances, in cases where discovery algorithms > return known values. No reinventing the wheel. Now that would be > interesting. > > 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/20060126/ab451bc1/attachment-0001.html From henry at pulver.com Fri Jan 27 09:49:07 2006 From: henry at pulver.com (Henry Sinnreich) Date: Fri, 27 Jan 2006 08:49:07 -0600 Subject: [p2p-sip] P2P SIP SPAM In-Reply-To: <43D9493A.9050608@nokia.com> Message-ID: <200601271452.k0REnBKG027536@cs.columbia.edu> Folks, As mentioned, please focus on _short_ contributions to the charter text. Unless we make it to the BOF and WG, all of this here addressed to the whole list is turning into an unexpected P2P SIP result: Email SPAM. Most respectfully, your Henry From eunsoo at research.panasonic.com Fri Jan 27 09:55:54 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Fri, 27 Jan 2006 09:55:54 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601262032u9521d1et@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <"1fc32c8f0601241401 l2d7662a4y"@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <"1fc32c8 f0601242123y27649335o"@mail.gmail.com> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <"E9E9201E-70B9-4 72E-9EED-37CB672E00B9"@magma.ca> <1fc32c8f0601262032u9521d1et@mail.gmail.com> Message-ID: <43DA347A.1080205@research.panasonic.com> Michael Slavitch wrote: > (snip) I appreciate your stressing the importance of NAT traversal problem for P2P SIP and I believe at least most of the group are aware of its importance and have been paying attention to it. The draft charter says "The solutions proposed will function even with some or many nodes located behind NATs or firewalls." It seems to me this is sufficient but it seems also OK to add the proposed text (with some modifications) below. > Given the above, I would add this line to the statement of activities > (after item 4, an equivalent item regarding SIP Extensions) > > 5. Investigate how NAT traversal techniques as described by MMUSIC > are to be implemented by P2PSIP. > Define requirements for enhancements, protocols, or partial > interim solutions for submission to all affected IETF working groups. I'd like to propose a slight rewording. "Investigate how existing firewall/NAT traversal techniques are to be incorporated for P2P SIP. If necessary, define requirements for enhancements of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any other affected IETF working group." > > And add the following milestone, concurrent with the use-case document. > > Aug 2006 Submit Preliminary Functional Requirements For Meeting > Proposed Use Cases to affected IETF working groups for their > consideration. > As you see in the draft charter, there is no milestone for defining requirements of SIP extensions because it is not clear yet whether any SIP extensions are necessary. I think it is the same for NAT traversal. So we can leave the milestones for defining those requirements open like the draft charter. What do you think? > > These changes would give the underlying NAT problem the attention it > deserves. > Regards, Eunsoo > > > On 26/01/06, *Philip Matthews * > wrote: > > Michael: > > It is not clear to me what you are proposing. > > In the draft charter that David Bryan posted, there are some > concrete deliverables > listed, and the milestones section proposes some concrete dates. > I had a hand in suggesting these deliverables and dates, and I > feel they are reasonable and achievable. > > Do you have some proposals for text modifications that would > reflect your concerns? > > - Philip > > > > > On 25-Jan-06, at 17:34 , Michael Slavitch wrote: > >> On 25/01/06, *Dean Willis* < dean.willis at softarmor.com >> > wrote: >> >> (snip) >> >> >> There's a high level of urgency -- I >> sat through the almost overnight ICE ad-hoc in Vancouver as >> the key >> players worked through issue after issue. Sure, there's more >> work to >> be done. But issuing an ultimatum from another working group >> isn't >> going to make it go faster. >> >> >> >> I agree. Ultimatums are never useful. But real milestones are. >> >> Delivery targets and milestones do matter and are very useful. >> Working towards an actual deadline and a real targeted date for >> delivery has implications that will influence the decisions and >> the milestones of several working groups. It doesn't matter if >> the actual deadline is missed. What matters is that exists a >> reasonable expectation that some solution will be at hand in a >> reasonable timeframes. >> >> >> And even if there were total agreement on every detail of these >> specifications, and the drafts were completely final and >> blessed by >> the working groups, IESG, and greater IETF, we'd still be >> over a year >> from having a referable RFC. That's just the nature of IETF work >> right now. >> >> >> Ok, that's the anticipated wg acceptance milestone date plus one >> year. Good. Now we're getting somewhere. Given that, what >> agreed-n date can anyone offer as a reasonable date for reaching >> a consensus? Is it in 2006? Is it in 2007? Is there any >> deadline or milestone at all, or can this discussion go on >> forever? I argue that a real deadline will force the issue enough >> such that consensus can be reached, and that this is for the >> general good. >> >> >> The other problem is that there is no specific, formalized >> behavior >> of NATs to write a "signalling protcocol" against. There are >> many >> different sorts of NATs with a broad range of >> characteristics. We >> have an entire group (BEHAVE) dedicated to sorting these >> characteristics out. We have seen no evidence of any single >> traversal >> protocol that works on all of them all the time. Sometimes >> you need a >> relay element, sometimes you don't. Sometimes, about all you >> can do >> is squeeze a tunnel through to a correspondent node that >> fronts all >> the protocols for you. >> >> >> >> The perfect is often the enemy of the good, and this appears to >> be one of those cases. >> >> Why can't there be individual responses to specific >> characteristics? Why can't these responses be defined as >> individual algorithms implemented as small, tractable RFC's? Why >> must we wait for one grand unification protocol that solves every >> case when solutions that work within specific boundries are well >> known and at hand, and are already implemented in a variety of >> proprietary solutions that are in wide use? >> >> How can it be that Skype is so smart and the IETF is so stuck? >> How can the IETF consider this to be intractable and ignore the >> obvious? >> Any more delay and the IETF effort won't matter at all, as the >> world will line up pretty please and pay happily for proprietary >> solutions from a variety of vendors, be they Skype or Damaka or >> Google or Microsoft. These solutions aren't perfect, but they >> exist and they are now setting the agenda from the perspective >> that matters, which is users and subsequently vendors. Inaction >> cannot be ignored away, and a real failure scenario, one where >> open standards get replaced by closed proprietary impementations, >> is a real and present danger. This will happen if the current >> pace continues. The world isn't waiting for the IETF to come up >> with a perfect solution. It may be fully satisfied by a Google API. >> >> How does the IETF respond to this? One way would be to start >> providing solutions that reduce the problem, and offer a plan for >> the future. >> With a timeline. >> >> For example the STUN discovery protocol is relatively simple. >> It spits back one of a fixed set of responses (if it can respond >> at all). >> The set of responses is thus finite, a simple state machine. >> >> This allows solutions to be catagorized. If solutions can be >> catagorized they can be externalized and the problem reduced. >> >> Why can't NAT traversal reference different solutions for >> different circumnstances, like here?: >> >> Case A: Local NAT type A, Remote NAT type B see RFC XXXA >> (negotiation) >> Case B: Local NAT type B, Remote NAT type A see RFC XXXB >> (negotiation) >> Case C: Local NAT type C, Remote NAT type D,see RFC XXXC >> (negotiation) >> Case D: Local NAT type D, Remote NAT type D,see RFC XXXD (relay) >> Case E: Local NAT type E, Remote NAT type Y; solution not there >> yet but on the way. fail. >> Case X: Local NAT type BAD. Remote NAT type don't care. >> Exception. No can do. Fail. >> Case Z: No answer to STUN request. Fail. Sorry. >> >> Assume that this is implemented in a product called 'foo' >> >> Implementation 'foo" supports NAT types A,B,C,D as described in >> RFC XXXX, XXXA, XXXB, XXXC, XXXD.. >> >> This summary is what would go on a data sheet. It sets >> reasonable expectations. Customers and vendors are happy enough >> that they avoid doing something else, something like a closed >> solution from a single vendor. >> >> Why can't a NAT traversal solution based on a relatively simple >> well formed NAT discovery technique (using STUN, either in line >> or not) reference one or more outside algorithm as the >> appropriate response? Such output may not offer a perfect >> answer, but it is a partial solution that can be delivered in >> short order, and as additional solutions come along they can be >> added to the list. It solves most of the problems that we face >> today, it describes failure modes accurately, users will live >> with it until improvements come along. It also stands a much >> better chance of being implemented by engineers. They need a >> basic specification to work from. Remember that ICE may be >> implemented in simple commodity hardware that has restricted >> capabilities. Parsing XML may not be one of them. >> >> Even if it takes a year just to get to consensus it still offers >> a deliverable that will forestall a purely proprietary world for >> which the IETF currently has no answer. >> >> I agree that the BEHAVE group has no solution for all cases. But >> it has solutions for MOST cases. Why aren't these being put >> forward in the meantime as a set of NAT traversal standards for >> which there are solutions and leave the art of the perfect for >> later? >> >> >> STUN helps us discover what we look like to the outside >> world. TURN >> gives us a media relay. Outbound gives us a back-channel for >> signaling, so that we can receive requests. ICE gives us a >> methodology for bringing this all together in a way that, if not >> perfect, is at least probably going to work. >> >> >> >> See above. I agree. What I propose is that this be made as >> deterministic as is possible using protocols that are as simple >> as is possible, >> continually reducing the problem domain. >> >> >> In a world without dedicated servers, how do we find >> something to run >> STUN against so we can find out if we're NATed? How do we >> find and >> >> make use of a peer that offers TURN relay services? How do we >> build >> persistent signaling relationships with peers outside our >> NATs so >> that they can get messages back to us, and how do our other peers >> discover and re-use those relationships? These are the >> correspondent >> and service discovery questions that have to be addressed so >> that SIP >> can be made to do something useful in the P2P environments we >> seem to >> agree are our targets. >> >> >> >> >> >> Good question. What is above is a my 2c example of an answer. >> The outside state machine could be modified for a P2P SIP world >> (perhaps using some kind of base certificate-obtained "seed", but >> that's not for now) where discovery processes replace value >> parameters. >> >> In most cases it would invoke the same RFCs as for regular SIP, >> but (as an example) relay cases the algorithm could then point to >> a peer discovery algorithm, possibly defined as another RFC, that >> returns a resulting value, instead of immediately using a relay >> based on some present known value. It would then get the ball >> rolling with that relay in the same way that regular SIP does. >> >> The big difference between classic SIP and P2PSIP could then be >> largely one of using known fixed values vs using the results of >> discovery processes that meet some rule criteria. >> >> SIP has "use relay x" where X is a scalar value. >> >> P2PSIP could have "discover relays and use the one that meets >> certain rules", >> where the rules are such things as: >> >> "Only use peers, never dedicated hosts" >> "never from canonically Evil Vendor M, maybe from usually Good >> Vendor G but not if it is in France" and finally >> "please use first good result unless congested otherwise choose >> randomly from first ten results". >> >> I wonder if someone from Google is watching this discussion. They >> could offer good input. >> >> The SIP of today sees parameters such as hosts as values while >> P2PSIP may see these as references to one or more discovery >> processes. The underlying NAT traversal solutions for individual >> NAT cases would then be unchanged and reused, as they reflect >> the connection not the connecting entities. Most of SIP could >> then be reused, replacing value parameters with discovery >> processes and rule definitions. >> >> Given this scenario P2PSIP would ultimately behave just like >> regular ol' SIP given the right circumstances, in cases where >> discovery algorithms return known values. No reinventing the >> wheel. Now that would be interesting. >> >> 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 > >------------------------------------------------------------------------ > >_______________________________________________ >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 Jan 27 10:34:12 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Fri, 27 Jan 2006 10:34:12 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <43DA347A.1080205@research.panasonic.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <1fc32c8f0601262032u9521d1et@mail.gmail.com> <43DA347A.1080205@research.panasonic.com> Message-ID: <1fc32c8f0601270734v643267b5n@mail.gmail.com> In keeping with Henry's request, I ask that Eunsoo Shim < eunsoo at research.panasonic.com>'s wording:* * "5. Investigate how existing firewall/NAT traversal techniques are to be incorporated for P2P SIP. If necessary, define requirements for enhancements of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any other affected IETF working group." be added to the charter following similar wording for SIP. Apart from that the charter seems fine by me. Regards Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060127/46a0b03a/attachment.html From royrr at us.saic.com Fri Jan 27 10:48:55 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Fri, 27 Jan 2006 10:48:55 -0500 Subject: [p2p-sip] Draft charter for possible P2PSIP WG Message-ID: Hi, all: I agree with Michael's proposal. Let us close this item now, and focus on BoF for forming the P2P-SIP WG. Best regards, Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Michael Slavitch Sent: Fri 1/27/2006 10:34 AM To: Eunsoo Shim Cc: P2P-SIP Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG In keeping with Henry's request, I ask that Eunsoo Shim >'s wording: "5. Investigate how existing firewall/NAT traversal techniques are to be incorporated for P2P SIP. If necessary, define requirements for enhancements of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any other affected IETF working group." be added to the charter following similar wording for SIP. Apart from that the charter seems fine by me. Regards Michael From philip_matthews at magma.ca Fri Jan 27 11:19:15 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 27 Jan 2006 11:19:15 -0500 Subject: [p2p-sip] Issues in Draft Charter of 17 Jan 2006 Message-ID: <2314A853-0483-4C98-8A87-5A1BE17BEAAE@magma.ca> Folks: To try to bring some focus into our draft charter discussions, I have stolen an idea I saw used very effectively in the BGP WG and created a document that tracks the issues in the draft charter. Hopefully this will allow us to identify the issues and bring them to a resolution. I have reproduced this document below (it is just a text file). For issue #1, raised by Henry, I have marked it tentatively resolved because Henry has said he is happy with the existing text. Speak up on the mailing list if you disagree. The other issues are still open. I have tried to list all the issues that people have raised. If I have missed something, just sent me an e-mail with a pointer to the message and I will add it to the document. Going forward, I plan to add issues as I see them appear on the mailing list (again, if I miss something, just let me know) I will try to include an abbreviated version of the discussion in the document. By necessity, this abbreviation will be subjective, and people will need to look at the mailing list for the full discussion. However, if you feel your points have been misrepresented, then let me know. - Philip --------------------- Issues in proposed P2P-SIP charter draft (in the version posted by David Bryan on 17 Jan 2006) Summary: - 6 issues in total - 1 tentatively closed (pending confirmation by group) - 5 still open Issue 1: Reference to P2PRG Existing Text: The working group will operate in close cooperation with the SIP, SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF. Proposed Text: (Unclear) Proposed by: Henry Sinnreich Discussion: Henry is now happy with the existing text. No one else has indicated that he/she would like to see a change. Resolution: CLOSED? Issue 2: Description of conventional SIP. Existing Text: This is an alternative to the conventional SIP approach of using a hierarchy of proxies where the mapping of users to proxies is determined by a combination of out-of-band and geographic mechanisms. Proposed Text: This is an alternative to the conventional SIP approach of relying on service provider hosted proxies to which users get assigned by out-of-band means, usually based on geography, association or business reasons. Proposed by: Aki Niemi Discussion: [Aki Niemi] The [original] sentence is a bit too sophisticated to efficiently communicate the message. How about simply saying that the conventional SIP approach relies on service provider hosted proxies to which users get assigned by out-of-band means, usually based on geography, association or business reasons. Resolution: OPEN Issue 3: Namespace Existing Text: 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. Proposed Text: (Nothing proposed yet) Proposed by Aki Niemi Related issues: #4 Discussion: [Aki Niemi] I find this a little hard to understand. I guess the meaning is to still use a username at domain construct for user ids, and that each domain's name is rooted in the DNS? If so, why not just say that? Resolution: OPEN Issue 4: Namespace again Existing Text: 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. Proposed Text: (Nothing proposed yet) Proposed by: Aki Niemi Related issues: #3 Discussion: [Aki Niemi] This isn't either or; perhaps it could also be mentioned that peers can very well sometimes be in disconnected mode, while other times in connected mode. In such cases, the names should have global scope in both modes. Maybe say that names should always have global scope? [Philip Matthews] I would personally be reluctant to say in the charter that names must always have global scope until I better understood the implications of that statement. Currently, I suspect that having user and resource names which are unique only within a specific P2P-SIP network are much more realistic. [Aki Niemi] My point is that nodes can move around and be part of both disconnected and connected overlays. It probably makes sense for that node to use the same name in each scenario, and that name to not collide with other names. Resolution: OPEN Issue 5: Should Distributed Media Relays be part of the first set of deliverables? Existing Text: [In the section with the heading "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. Proposed Text: (Nothing proposed yet) Discussion: [Aki Niemi] Hmm.. I understand this in terms of the charter being scoped to SIP only (initially), but this seems like cutting out a major part of where distributing or sharing resources actually is a big benefit. After all, running a SIP proxy is quite cheap; disk and cpu are cheap and SIP doesn't consume that much bandwidth. Running a TURN server then again is another thing entirely. I can't see a system that has distributed rendezvous having to resort to centralized media relays. Shouldn't this rather be included in the first iteration already? [Philip Matthews] I believe that we really need to have a small set of deliverables for the initial charter, otherwise the charter won't get past the IESG. In my opinion, only really essential stuff should be part of the first set of deliverables. So, for example, I am personally very interested in item 3 below (voicemail), but I am not objecting to leaving it for after a re-charter because I don't consider it "essential". In my opinion, item 1 (distributed media relays) are also not essential and should wait until after a re-charter. Does this make sense? Do you agree? [Aki Niemi] Voicemail is hardly an essential feature. But media relays are needed to get around the most difficult middleboxes. What fraction of nodes are we expecting to live behind such boxes, and by not counting those in does it represent a complete enough solution? Because I just can't see a P2PSIP that requires centralized media relays to work properly getting off the ground (any better than traditional SIP). Resolution: OPEN Issue 6: NAT Traversal milestone Existing Text: (None) Proposed Text: [In the section with the heading "Specifically, the working group will:"] 5. Investigate how NAT traversal techniques as described by MMUSIC are to be implemented by P2PSIP. Define requirements for enhancements, protocols, or partial interim solutions for submission to all affected IETF working groups. [In the Milestones section] Aug 2006 Submit Preliminary Functional Requirements For Meeting Proposed Use Cases to affected IETF working groups for their consideration. Proposed by: Michael Slavitch Discussion: [Michael Slavitch] (brief excerpts -- see e-mails for complete text) ... The ability to do NAT traversal is a core requirement for P2PSIP entities. Its absence jeopardizes the ability of the WG to meet one of its key pressing goals. Nothing else matters if peers can't communicate through NAT firewalls. The success of P2PSIP largely depends on an item that is largely not within its own mandate for which there is no current public standards based solution, no matter how partial or interim. ... ...The absence of a a general solution for a problem should not prevent partial solutions from being developed and defined in the meantime, especially if the partial solution does not preclude the inclusion of a general solution if and when such a solution becomes available. ... ... I believe that this issue is so important that an investigation into how NAT traversal techniques are to be implemented by P2PSIP entities should become part of the basic scope of the WG charter and one of the initial activities of the group. Naturally in keeping with the principles of the IETF this investigation will be based on existing MMUSIC work. ... Resolution: OPEN From royrr at us.saic.com Fri Jan 27 11:29:46 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Fri, 27 Jan 2006 11:29:46 -0500 Subject: [p2p-sip] Issues in Draft Charter of 17 Jan 2006 Message-ID: Kindly take care of the FW/NAT issue as Michael pointed out. BR/Radhika _____ From: p2p-sip-bounces at cs.columbia.edu on behalf of Philip Matthews Sent: Fri 1/27/2006 11:19 AM To: P2P-SIP Subject: [p2p-sip] Issues in Draft Charter of 17 Jan 2006 Folks: To try to bring some focus into our draft charter discussions, I have stolen an idea I saw used very effectively in the BGP WG and created a document that tracks the issues in the draft charter. Hopefully this will allow us to identify the issues and bring them to a resolution. I have reproduced this document below (it is just a text file). For issue #1, raised by Henry, I have marked it tentatively resolved because Henry has said he is happy with the existing text. Speak up on the mailing list if you disagree. The other issues are still open. I have tried to list all the issues that people have raised. If I have missed something, just sent me an e-mail with a pointer to the message and I will add it to the document. Going forward, I plan to add issues as I see them appear on the mailing list (again, if I miss something, just let me know) I will try to include an abbreviated version of the discussion in the document. By necessity, this abbreviation will be subjective, and people will need to look at the mailing list for the full discussion. However, if you feel your points have been misrepresented, then let me know. - Philip --------------------- Issues in proposed P2P-SIP charter draft (in the version posted by David Bryan on 17 Jan 2006) Summary: - 6 issues in total - 1 tentatively closed (pending confirmation by group) - 5 still open Issue 1: Reference to P2PRG Existing Text: The working group will operate in close cooperation with the SIP, SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the IRTF. Proposed Text: (Unclear) Proposed by: Henry Sinnreich Discussion: Henry is now happy with the existing text. No one else has indicated that he/she would like to see a change. Resolution: CLOSED? Issue 2: Description of conventional SIP. Existing Text: This is an alternative to the conventional SIP approach of using a hierarchy of proxies where the mapping of users to proxies is determined by a combination of out-of-band and geographic mechanisms. Proposed Text: This is an alternative to the conventional SIP approach of relying on service provider hosted proxies to which users get assigned by out-of-band means, usually based on geography, association or business reasons. Proposed by: Aki Niemi Discussion: [Aki Niemi] The [original] sentence is a bit too sophisticated to efficiently communicate the message. How about simply saying that the conventional SIP approach relies on service provider hosted proxies to which users get assigned by out-of-band means, usually based on geography, association or business reasons. Resolution: OPEN Issue 3: Namespace Existing Text: 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. Proposed Text: (Nothing proposed yet) Proposed by Aki Niemi Related issues: #4 Discussion: [Aki Niemi] I find this a little hard to understand. I guess the meaning is to still use a username at domain construct for user ids, and that each domain's name is rooted in the DNS? If so, why not just say that? Resolution: OPEN Issue 4: Namespace again Existing Text: 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. Proposed Text: (Nothing proposed yet) Proposed by: Aki Niemi Related issues: #3 Discussion: [Aki Niemi] This isn't either or; perhaps it could also be mentioned that peers can very well sometimes be in disconnected mode, while other times in connected mode. In such cases, the names should have global scope in both modes. Maybe say that names should always have global scope? [Philip Matthews] I would personally be reluctant to say in the charter that names must always have global scope until I better understood the implications of that statement. Currently, I suspect that having user and resource names which are unique only within a specific P2P-SIP network are much more realistic. [Aki Niemi] My point is that nodes can move around and be part of both disconnected and connected overlays. It probably makes sense for that node to use the same name in each scenario, and that name to not collide with other names. Resolution: OPEN Issue 5: Should Distributed Media Relays be part of the first set of deliverables? Existing Text: [In the section with the heading "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. Proposed Text: (Nothing proposed yet) Discussion: [Aki Niemi] Hmm.. I understand this in terms of the charter being scoped to SIP only (initially), but this seems like cutting out a major part of where distributing or sharing resources actually is a big benefit. After all, running a SIP proxy is quite cheap; disk and cpu are cheap and SIP doesn't consume that much bandwidth. Running a TURN server then again is another thing entirely. I can't see a system that has distributed rendezvous having to resort to centralized media relays. Shouldn't this rather be included in the first iteration already? [Philip Matthews] I believe that we really need to have a small set of deliverables for the initial charter, otherwise the charter won't get past the IESG. In my opinion, only really essential stuff should be part of the first set of deliverables. So, for example, I am personally very interested in item 3 below (voicemail), but I am not objecting to leaving it for after a re-charter because I don't consider it "essential". In my opinion, item 1 (distributed media relays) are also not essential and should wait until after a re-charter. Does this make sense? Do you agree? [Aki Niemi] Voicemail is hardly an essential feature. But media relays are needed to get around the most difficult middleboxes. What fraction of nodes are we expecting to live behind such boxes, and by not counting those in does it represent a complete enough solution? Because I just can't see a P2PSIP that requires centralized media relays to work properly getting off the ground (any better than traditional SIP). Resolution: OPEN Issue 6: NAT Traversal milestone Existing Text: (None) Proposed Text: [In the section with the heading "Specifically, the working group will:"] 5. Investigate how NAT traversal techniques as described by MMUSIC are to be implemented by P2PSIP. Define requirements for enhancements, protocols, or partial interim solutions for submission to all affected IETF working groups. [In the Milestones section] Aug 2006 Submit Preliminary Functional Requirements For Meeting Proposed Use Cases to affected IETF working groups for their consideration. Proposed by: Michael Slavitch Discussion: [Michael Slavitch] (brief excerpts -- see e-mails for complete text) ... The ability to do NAT traversal is a core requirement for P2PSIP entities. Its absence jeopardizes the ability of the WG to meet one of its key pressing goals. Nothing else matters if peers can't communicate through NAT firewalls. The success of P2PSIP largely depends on an item that is largely not within its own mandate for which there is no current public standards based solution, no matter how partial or interim. ... ...The absence of a a general solution for a problem should not prevent partial solutions from being developed and defined in the meantime, especially if the partial solution does not preclude the inclusion of a general solution if and when such a solution becomes available. ... ... I believe that this issue is so important that an investigation into how NAT traversal techniques are to be implemented by P2PSIP entities should become part of the basic scope of the WG charter and one of the initial activities of the group. Naturally in keeping with the principles of the IETF this investigation will be based on existing MMUSIC work. ... Resolution: OPEN _______________________________________________ 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 Fri Jan 27 12:25:32 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Fri, 27 Jan 2006 12:25:32 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone (was: Draft charter for possible P2PSIP WG) In-Reply-To: <1fc32c8f0601270734v643267b5n@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <1fc32c8f0601262032u9521d1et@mail.gmail.com> <43DA347A.1080205@research.panasonic.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> Message-ID: <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> On 27-Jan-06, at 10:34 , Michael Slavitch wrote: > In keeping with Henry's request, I ask that Eunsoo Shim > 's wording: > > "5. Investigate how existing firewall/NAT traversal techniques are > to be incorporated for P2P SIP. If necessary, define requirements > for enhancements of existing techniques to be acted on by the > MMUSIC, the BEHAVE, and any other affected IETF working group." > > be added to the charter following similar wording for SIP. Apart > from that the charter seems fine by me. > > Regards > > Michael [Adding Radhika to the CC, since he has expressed interest in this topic.] I have a few concerns about this proposed change. First of all, the existing charter draft says: 3. The solutions proposed will function even with many nodes located behind NATs or firewalls. and 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. In my opinion, it would be a mistake to remove the existing text, and the proposed additional text doesn't add anything new that the existing sentences don't already say. The proposed new text does emphasis these a bit more, but as long as the words are in the charter somewhere, then the real emphasis in a WG comes from the actions of its participants and not from the words in the charter. In other words, I don't really see what we gain by the additional text. Second, assuming that other feel strongly that new words should be added, I would suggest the following rewording of Eunsoo's proposal: 5. Investigate firewall/NAT traversal techniques for P2P SIP. If appropriate, submit requirements in this area to other working groups, such as MMUSIC and BEHAVE. Here I have generalized the first sentence, because existing techniques might not be sufficient. (In fact, I think there WILL be cases where existing techniques are not sufficient). And I have reworded the second sentence to make it clear that we are simply making suggestions to other working groups for what we would like to see. Comments? - Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060127/51b54e5d/attachment.html From slavitch at gmail.com Fri Jan 27 12:46:39 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Fri, 27 Jan 2006 12:46:39 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone (was: Draft charter for possible P2PSIP WG) In-Reply-To: <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <1fc32c8f0601262032u9521d1et@mail.gmail.com> <43DA347A.1080205@research.panasonic.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> Message-ID: <1fc32c8f0601270946t47da57d2l@mail.gmail.com> My opinion is that 5, regarding NAT traversal, is as needed as is 4. regarding SIP. NAT is as important an enabler to the P2P part of P2PSIP as much as URI and TCP/UDP/RTP are to the SIP part of P2PSIP. It has to be a core issue. On 27/01/06, Philip Matthews wrote: > > On 27-Jan-06, at 10:34 , Michael Slavitch wrote: > > In keeping with Henry's request, I ask that Eunsoo Shim < > eunsoo at research.panasonic.com>'s wording: * > * > "5. Investigate how existing firewall/NAT traversal techniques are to be > incorporated for P2P SIP. If necessary, define requirements for enhancements > of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any > other affected IETF working group." > > be added to the charter following similar wording for SIP. Apart from > that the charter seems fine by me. > > Regards > > Michael > > > [Adding Radhika to the CC, since he has expressed interest in this topic.] > > I have a few concerns about this proposed change. > > First of all, the existing charter draft says: > 3. The solutions proposed will function even with many nodes > located behind NATs or firewalls. > and > 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. > In my opinion, it would be a mistake to remove the existing text, and > the proposed additional text doesn't add anything new that the existing > sentences don't already say. > The proposed new text does emphasis these a bit more, but as long as the > words are in the charter > somewhere, then the real emphasis in a WG comes from the actions of its > participants and not from the words > in the charter. > In other words, I don't really see what we gain by the additional text. > > Second, assuming that other feel strongly that new words should be added, > I would suggest the following > rewording of Eunsoo's proposal: > 5. Investigate firewall/NAT traversal techniques for P2P SIP. > If appropriate, submit requirements in this area to other working > groups, such as MMUSIC and BEHAVE. > Here I have generalized the first sentence, because existing techniques > might not be sufficient. (In fact, I think > there WILL be cases where existing techniques are not sufficient). > And I have reworded the second sentence to make it clear that we are > simply making suggestions to > other working groups for what we would like to see. > > Comments? > > > - Philip > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060127/30774e58/attachment.html From dean.willis at softarmor.com Sun Jan 29 22:38:55 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Sun, 29 Jan 2006 21:38:55 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601251046u2f72b41fx@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601241401l2d7662a4y@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601242123y27649335o@mail.gmail.com> <43D7A75F.2000700@Research.Panasonic.COM> <1fc32c8f0601251046u2f72b41fx@mail.gmail.com> Message-ID: On Jan 25, 2006, at 12:46 PM, Michael Slavitch wrote: > > > On 25/01/06, Sathya Narayanan wrote: > > > > This sounds to me like again trying to mandate things from another > working group. As was mentioned many times earlier, this is not > possible > in IETF. > > > So what happens when the results of other WG's are either absent, > incomplete, or do not meet the requirements of the WG? > > Does the WG sit on its hands? > This is the IETF. You're not restricted to participated in only one working group. If another working group is supposed to be doing something that we need and they aren't doing it, we either go to the other working group and get the job done, or we get the IESG to scrap the working group that isn't getting the job done and recharter the work elsewhere. What we do NOT do is independently try to standardize Yet Another Solution to the same problem. -- Dean From dean.willis at softarmor.com Sun Jan 29 22:41:51 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Sun, 29 Jan 2006 21:41:51 -0600 Subject: [p2p-sip] Draft charter for possible P2PSIP WG In-Reply-To: <1fc32c8f0601270734v643267b5n@mail.gmail.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <1fc32c8f0601262032u9521d1et@mail.gmail.com> <43DA347A.1080205@research.panasonic.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> Message-ID: On Jan 27, 2006, at 9:34 AM, Michael Slavitch wrote: > In keeping with Henry's request, I ask that Eunsoo Shim > 's wording: > > "5. Investigate how existing firewall/NAT traversal techniques are > to be incorporated for P2P SIP. If necessary, define requirements > for enhancements of existing techniques to be acted on by the > MMUSIC, the BEHAVE, and any other affected IETF working group." > > be added to the charter following similar wording for SIP. Apart > from that the charter seems fine by me. > I think this works OK for me too. -- Dean From srisuresh at yahoo.com Mon Jan 30 00:49:42 2006 From: srisuresh at yahoo.com (Pyda Srisuresh) Date: Sun, 29 Jan 2006 21:49:42 -0800 (PST) Subject: [p2p-sip] Issue #6 NAT Traversal milestone (was: Draft charter for possible P2PSIP WG) In-Reply-To: <1fc32c8f0601270946t47da57d2l@mail.gmail.com> Message-ID: <20060130054942.13763.qmail@web33312.mail.mud.yahoo.com> I fully agree with Michael. cheers, suresh --- Michael Slavitch wrote: > My opinion is that 5, regarding NAT traversal, is as needed as is 4. > regarding SIP. > > NAT is as important an enabler to the P2P part of P2PSIP as much as URI and > TCP/UDP/RTP are to the SIP part of P2PSIP. > > It has to be a core issue. > > > On 27/01/06, Philip Matthews wrote: > > > > On 27-Jan-06, at 10:34 , Michael Slavitch wrote: > > > > In keeping with Henry's request, I ask that Eunsoo Shim < > > eunsoo at research.panasonic.com>'s wording: * > > * > > "5. Investigate how existing firewall/NAT traversal techniques are to be > > incorporated for P2P SIP. If necessary, define requirements for > enhancements > > of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any > > other affected IETF working group." > > > > be added to the charter following similar wording for SIP. Apart from > > that the charter seems fine by me. > > > > Regards > > > > Michael > > > > > > [Adding Radhika to the CC, since he has expressed interest in this topic.] > > > > I have a few concerns about this proposed change. > > > > First of all, the existing charter draft says: > > 3. The solutions proposed will function even with many nodes > > located behind NATs or firewalls. > > and > > 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. > > In my opinion, it would be a mistake to remove the existing text, and > > the proposed additional text doesn't add anything new that the existing > > sentences don't already say. > > The proposed new text does emphasis these a bit more, but as long as the > > words are in the charter > > somewhere, then the real emphasis in a WG comes from the actions of its > > participants and not from the words > > in the charter. > > In other words, I don't really see what we gain by the additional text. > > > > Second, assuming that other feel strongly that new words should be added, > > I would suggest the following > > rewording of Eunsoo's proposal: > > 5. Investigate firewall/NAT traversal techniques for P2P SIP. > > If appropriate, submit requirements in this area to other working > > groups, such as MMUSIC and BEHAVE. > > Here I have generalized the first sentence, because existing techniques > > might not be sufficient. (In fact, I think > > there WILL be cases where existing techniques are not sufficient). > > And I have reworded the second sentence to make it clear that we are > > simply making suggestions to > > other working groups for what we would like to see. > > > > Comments? > > > > > > - Philip > > > > > > -- > 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 quittek at netlab.nec.de Mon Jan 30 08:47:38 2006 From: quittek at netlab.nec.de (Juergen Quittek) Date: Mon, 30 Jan 2006 14:47:38 +0100 Subject: [p2p-sip] Issue #6 NAT Traversal milestone (was: Draft charter for possible P2PSIP WG) In-Reply-To: <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <1fc32c8f0601262032u9521d1et@mail.gmail.com> <43DA347A.1080205@research.panasonic.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> Message-ID: <77CBDAAA3086997E5DB82FCE@[10.1.1.171]> Dear all, I also see firewall and NAT traversal as one of the key components of a P2P SIP solution. So far, we have three suggestions for phrasing of a charter work item: Michael: 5. Investigate how NAT traversal techniques as described by MMUSIC are to be implemented by P2PSIP. Define requirements for enhancements, protocols, or partial interim solutions for submission to all affected IETF working groups. Comments - This version put focus on "how NAT traversal techniques ... to be implemented...". This is too weak. It is not just implementation but also a _selection_ of methods and a well designed _integration_ with P2P SIP required. How to implement should not be a major problem for the P2PSIP WG. Eunsoo: 5. Investigate how existing firewall/NAT traversal techniques are to be incorporated for P2P SIP. If necessary, define requirements for enhancements of existing techniques to be acted on by the MMUSIC, the BEHAVE, and any other affected IETF working group. Comments - What means "incorporated" in the first sentence different than implemented? Again, selection and integration of existing techniques are the problems to be solved. - There are more WGs working on related techniques, such as NSIS and MIDCOM. I would suggest not to mention particular WGs for this work item. To which WG a request needs to be directed should either be obvious anyway, or the target WG should be discussed when details of the request are clear. Philip: 5. Investigate firewall/NAT traversal techniques for P2P SIP. If appropriate, submit requirements in this area to other working groups, such as MMUSIC and BEHAVE. Comments - Also this alternative is a little bit weak. We should not investigating techniques is the challenge (they are well known and we already have practical experiences with many of them), but how to use which ones is the point. In summary: neither the _investigation_ in FW/NAT traversal techniques, nor their _implementation_ is the core work for us, but the steps in between: selecting the right one(s) and integrating them with the P2P SIP solution that we will be working on. Consequently, here is suggestion #4: 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. Juergen -- Juergen Quittek quittek at netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de From royrr at us.saic.com Mon Jan 30 10:23:56 2006 From: royrr at us.saic.com (Roy, Radhika R.) Date: Mon, 30 Jan 2006 10:23:56 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone (was: Draft charte r for possible P2PSIP WG) Message-ID: Hi, all: I think that Juergen has done the better job in articulating the requirements. Let us accept this as stated by him. Best regards, Radhika --------- In summary: neither the _investigation_ in FW/NAT traversal techniques, nor their _implementation_ is the core work for us, but the steps in between: selecting the right one(s) and integrating them with the P2P SIP solution that we will be working on. Consequently, here is suggestion #4: 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. Juergen From dean.willis at softarmor.com Mon Jan 30 16:21:17 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Mon, 30 Jan 2006 15:21:17 -0600 Subject: [p2p-sip] Issue #6 NAT Traversal milestone (was: Draft charter for possible P2PSIP WG) In-Reply-To: <77CBDAAA3086997E5DB82FCE@[10.1.1.171]> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <43D6B287.3070800@Research.Panasonic.COM> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <1fc32c8f0601262032u9521d1et@mail.gmail.com> <43DA347A.1080205@research.panasonic.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> <77CBDAAA3086997E5DB82FCE@[10.1.1.171]> Message-ID: <5FC2D082-971E-4E90-BE62-4E6DC05E7C96@softarmor.com> On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: > > 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. This is also acceptable to me, and I think it might draw less fire from the IAB than the previous formulation. -- Dean From eunsoo at research.panasonic.com Mon Jan 30 16:37:48 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Mon, 30 Jan 2006 16:37:48 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: <5FC2D082-971E-4E90-BE62-4E6DC05E7C96@softarmor.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <"1fc3 2c8f0601262032u9521d1et"@mail.gmail.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> <77CBDAAA3086997E5DB82FCE@[10.1.1.171]> <5FC2D082-971E-4E90-BE62-4E6DC05E7C96@softarmor.com> Message-ID: <43DE872C.30009@research.panasonic.com> The wording by Juergen is OK with me, too. So far, no one objected to adding such a statement into the charter draft. Philip expressed a concern about it (saying it does not add anything new) but I see from his email that he is willing to accept the change. Philip, please correct me if I am wrong here. I believe we agree on what the statement should say and there are only subtle differences in wording. These subtle differences of wording should not prevent us from moving forward. Dean and David, if appropriate, would you mind integrating the proposed statement into the charter draft and posting the new revised draft? Thanks. Eunsoo Dean Willis wrote: > > On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: > > >> >> 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. > > > This is also acceptable to me, and I think it might draw less fire > from the IAB than the previous formulation. > > -- > Dean > From bryan at ethernot.org Mon Jan 30 18:06:47 2006 From: bryan at ethernot.org (David A. Bryan) Date: Mon, 30 Jan 2006 18:06:47 -0500 Subject: [p2p-sip] Revised Draft for possible WG charter Message-ID: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> 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) From enrico.marocco at TILAB.COM Tue Jan 31 03:20:01 2006 From: enrico.marocco at TILAB.COM (Enrico Marocco) Date: Tue, 31 Jan 2006 09:20:01 +0100 Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> References: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> Message-ID: <43DF1DB1.2020902@tilab.com> David A. Bryan wrote: > 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). My worries were about being unable to integrate something like the "reg" event package, which would be essential for implementing a presence service without central servers. Now it's ok: thanks. Enrico Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin at tilab.com. Thank you ==================================================================== From philip_matthews at magma.ca Tue Jan 31 07:05:53 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 31 Jan 2006 07:05:53 -0500 Subject: [p2p-sip] Revised Draft for possible WG charter In-Reply-To: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> References: <8b2769930601301506s10a7c31cg9e134e895ce2a190@mail.gmail.com> Message-ID: See comments on the draft charter inline. - Philip On 30-Jan-06, at 18:06 , David A. Bryan wrote: > 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. "Disconnected or partly-connected topologies" --- I don't understand what the above is saying. Do you mean that these nodes are connected to each other by a private network, but not connected to the Internet? How can something be only partly connected to the Internet (or partly connected to another node)? > > 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. I would like to see a fourth scenario added: 4. Systems of (potentially many) phones or other communications equipment, interconnected by the Internet or a private network, where there is little or no central equipment for cost or other reasons. I think this covers both the Enterprise PBX application that I am interested in, as well as the Consumer Telephony application that I believe others are interested in. > > 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. I want to second Aki Niemi's question about what the second sentence in the above item is supposed to mean. Perhaps we could just delete the second sentence? > > 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. In the above sentence, I would like to see the phrase ""some or many nodes" replaced by "some to (nearly) all nodes". > > 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 philip_matthews at magma.ca Tue Jan 31 06:32:00 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 31 Jan 2006 06:32:00 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: <43DE872C.30009@research.panasonic.com> References: <1fc32c8f0601240811k1567c980q@mail.gmail.com> <1fc32c8f0601251434p74999cf0j@mail.gmail.com> <"1fc3 2c8f0601262032u9521d1et"@mail.gmail.com> <1fc32c8f0601270734v643267b5n@mail.gmail.com> <6DC24772-38C2-48E4-97BB-540E48B9245C@magma.ca> <77CBDAAA3086997E5DB82FCE@[10.1.1.171]> <5FC2D082-971E-4E90-BE62-4E6DC05E7C96@softarmor.com> <43DE872C.30009@research.panasonic.com> Message-ID: <8A356C2B-848D-45DC-A826-A9E20F3D8CC3@magma.ca> I am OK with this wording. Why don't we wait a day to see if anyone has any objections, and, if not, declare consensus on this resolution to the issue? - Philip On 30-Jan-06, at 16:37 , Eunsoo Shim wrote: > The wording by Juergen is OK with me, too. > So far, no one objected to adding such a statement into the charter > draft. > Philip expressed a concern about it (saying it does not add > anything new) but I see from his email that he is willing to accept > the change. Philip, please correct me if I am wrong here. > I believe we agree on what the statement should say and there are > only subtle differences in wording. > These subtle differences of wording should not prevent us from > moving forward. > > Dean and David, if appropriate, would you mind integrating the > proposed statement into the charter draft and posting the new > revised draft? > Thanks. > > Eunsoo > > Dean Willis wrote: > >> >> On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: >> >> >>> >>> 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. >> >> >> This is also acceptable to me, and I think it might draw less >> fire from the IAB than the previous formulation. >> >> -- >> Dean >> > From dromasca at avaya.com Tue Jan 31 07:44:32 2006 From: dromasca at avaya.com (Romascanu, Dan (Dan)) Date: Tue, 31 Jan 2006 14:44:32 +0200 Subject: [p2p-sip] Issue #6 NAT Traversal milestone Message-ID: So, if there will be a need to 'define requirements for enhancements of existing techniques to be acted on by other working groups', how will this be convened? Probably by an Internet-Draft. It may be good to mention this explicitly as a deliverable. Regards, Dan > -----Original Message----- > From: p2p-sip-bounces at cs.columbia.edu > [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews > Sent: Tuesday, January 31, 2006 1:32 PM > To: Eunsoo Shim; Dean Willis; Juergen Quittek; Michael > Slavitch; Roy, Radhika R. > Cc: P2P-SIP > Subject: Re: [p2p-sip] Issue #6 NAT Traversal milestone > > > I am OK with this wording. > > > Why don't we wait a day to see if anyone has any objections, > and, if not, declare consensus on this resolution to the issue? > > > - Philip > > > > On 30-Jan-06, at 16:37 , Eunsoo Shim wrote: > > > The wording by Juergen is OK with me, too. > > So far, no one objected to adding such a statement into the charter > > draft. > > Philip expressed a concern about it (saying it does not add > anything > > new) but I see from his email that he is willing to accept > the change. > > Philip, please correct me if I am wrong here. > > I believe we agree on what the statement should say and > there are only > > subtle differences in wording. > > These subtle differences of wording should not prevent us > from moving > > forward. > > > > Dean and David, if appropriate, would you mind integrating the > > proposed statement into the charter draft and posting the > new revised > > draft? > > Thanks. > > > > Eunsoo > > > > Dean Willis wrote: > > > >> > >> On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: > >> > >> > >>> > >>> 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. > >> > >> > >> This is also acceptable to me, and I think it might draw > less fire > >> from the IAB than the previous formulation. > >> > >> -- > >> Dean > >> > > > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > From stiemerling at netlab.nec.de Tue Jan 31 09:36:41 2006 From: stiemerling at netlab.nec.de (Martin Stiemerling) Date: Tue, 31 Jan 2006 15:36:41 +0100 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: References: Message-ID: <1D893513-4C32-414C-B1C8-BBE98E149261@netlab.nec.de> I'm fine with Juergen's wording as well. More inline. Am 31.01.2006 um 13:44 schrieb Romascanu, Dan (Dan): > So, if there will be a need to 'define requirements for > enhancements of > existing techniques to be acted on by other working groups', how will > this be convened? Probably by an Internet-Draft. It may be good to > mention this explicitly as a deliverable. An Internet draft is probably one way, another one is talking to the right people. Therefore the wording should be OK as long as it says there is some sort of communication with other WGs. Regards, Martin > > Regards, > > Dan > > > > > >> -----Original Message----- >> From: p2p-sip-bounces at cs.columbia.edu >> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews >> Sent: Tuesday, January 31, 2006 1:32 PM >> To: Eunsoo Shim; Dean Willis; Juergen Quittek; Michael >> Slavitch; Roy, Radhika R. >> Cc: P2P-SIP >> Subject: Re: [p2p-sip] Issue #6 NAT Traversal milestone >> >> >> I am OK with this wording. >> >> >> Why don't we wait a day to see if anyone has any objections, >> and, if not, declare consensus on this resolution to the issue? >> >> >> - Philip >> >> >> >> On 30-Jan-06, at 16:37 , Eunsoo Shim wrote: >> >>> The wording by Juergen is OK with me, too. >>> So far, no one objected to adding such a statement into the charter >>> draft. >>> Philip expressed a concern about it (saying it does not add >> anything >>> new) but I see from his email that he is willing to accept >> the change. >>> Philip, please correct me if I am wrong here. >>> I believe we agree on what the statement should say and >> there are only >>> subtle differences in wording. >>> These subtle differences of wording should not prevent us >> from moving >>> forward. >>> >>> Dean and David, if appropriate, would you mind integrating the >>> proposed statement into the charter draft and posting the >> new revised >>> draft? >>> Thanks. >>> >>> Eunsoo >>> >>> Dean Willis wrote: >>> >>>> >>>> On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: >>>> >>>> >>>>> >>>>> 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. >>>> >>>> >>>> This is also acceptable to me, and I think it might draw >> less fire >>>> from the IAB than the previous formulation. >>>> >>>> -- >>>> Dean >>>> >>> >> >> _______________________________________________ >> p2p-sip mailing list >> p2p-sip at cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> > > _______________________________________________ > p2p-sip mailing list > p2p-sip at cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2414 bytes Desc: not available Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060131/f0ec17eb/smime.bin From eunsoo at research.panasonic.com Tue Jan 31 09:53:06 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 31 Jan 2006 09:53:06 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: References: Message-ID: <43DF79D2.4010904@research.panasonic.com> A deliverable for that was not listed because we are not sure yet about the need. The same logic was applied to requirements for SIP extensions. If we need to define such requirements, I think writing a draft would be a good way as you said. But wouldn't it be OK to leave the deliverables open in the current situation? What do you think? Thanks. Eunsoo Romascanu, Dan (Dan) wrote: >So, if there will be a need to 'define requirements for enhancements of >existing techniques to be acted on by other working groups', how will >this be convened? Probably by an Internet-Draft. It may be good to >mention this explicitly as a deliverable. > >Regards, > >Dan > > > > > > > >>-----Original Message----- >>From: p2p-sip-bounces at cs.columbia.edu >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Philip Matthews >>Sent: Tuesday, January 31, 2006 1:32 PM >>To: Eunsoo Shim; Dean Willis; Juergen Quittek; Michael >>Slavitch; Roy, Radhika R. >>Cc: P2P-SIP >>Subject: Re: [p2p-sip] Issue #6 NAT Traversal milestone >> >> >>I am OK with this wording. >> >> >>Why don't we wait a day to see if anyone has any objections, >>and, if not, declare consensus on this resolution to the issue? >> >> >>- Philip >> >> >> >>On 30-Jan-06, at 16:37 , Eunsoo Shim wrote: >> >> >> >>>The wording by Juergen is OK with me, too. >>>So far, no one objected to adding such a statement into the charter >>>draft. >>>Philip expressed a concern about it (saying it does not add >>> >>> >>anything >> >> >>>new) but I see from his email that he is willing to accept >>> >>> >>the change. >> >> >>>Philip, please correct me if I am wrong here. >>>I believe we agree on what the statement should say and >>> >>> >>there are only >> >> >>>subtle differences in wording. >>>These subtle differences of wording should not prevent us >>> >>> >>from moving >> >> >>>forward. >>> >>>Dean and David, if appropriate, would you mind integrating the >>>proposed statement into the charter draft and posting the >>> >>> >>new revised >> >> >>>draft? >>>Thanks. >>> >>>Eunsoo >>> >>>Dean Willis wrote: >>> >>> >>> >>>>On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: >>>> >>>> >>>> >>>> >>>>>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. >>>>> >>>>> >>>>This is also acceptable to me, and I think it might draw >>>> >>>> >>less fire >> >> >>>>from the IAB than the previous formulation. >>>> >>>>-- >>>>Dean >>>> >>>> >>>> >>_______________________________________________ >>p2p-sip mailing list >>p2p-sip at cs.columbia.edu >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip >> >> >> From dromasca at avaya.com Tue Jan 31 09:58:13 2006 From: dromasca at avaya.com (Romascanu, Dan (Dan)) Date: Tue, 31 Jan 2006 16:58:13 +0200 Subject: [p2p-sip] Issue #6 NAT Traversal milestone Message-ID: Personally I prefer to list the deliverables and mention in brackets (if needed), so that we have a clear idea what and when to do this if the situation asks. Regards, Dan > -----Original Message----- > From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] > Sent: Tuesday, January 31, 2006 4:53 PM > To: Romascanu, Dan (Dan) > Cc: Philip Matthews; Dean Willis; Juergen Quittek; Michael > Slavitch; Roy, Radhika R.; P2P-SIP > Subject: Re: [p2p-sip] Issue #6 NAT Traversal milestone > > A deliverable for that was not listed because we are not sure > yet about the need. > The same logic was applied to requirements for SIP extensions. > If we need to define such requirements, I think writing a > draft would be a good way as you said. > But wouldn't it be OK to leave the deliverables open in the > current situation? > What do you think? > Thanks. > > Eunsoo > > Romascanu, Dan (Dan) wrote: > > >So, if there will be a need to 'define requirements for > enhancements of > >existing techniques to be acted on by other working groups', > how will > >this be convened? Probably by an Internet-Draft. It may be good to > >mention this explicitly as a deliverable. > > > >Regards, > > > >Dan > > > > > > > > > > > > > > > >>-----Original Message----- > >>From: p2p-sip-bounces at cs.columbia.edu > >>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of > Philip Matthews > >>Sent: Tuesday, January 31, 2006 1:32 PM > >>To: Eunsoo Shim; Dean Willis; Juergen Quittek; Michael > Slavitch; Roy, > >>Radhika R. > >>Cc: P2P-SIP > >>Subject: Re: [p2p-sip] Issue #6 NAT Traversal milestone > >> > >> > >>I am OK with this wording. > >> > >> > >>Why don't we wait a day to see if anyone has any > objections, and, if > >>not, declare consensus on this resolution to the issue? > >> > >> > >>- Philip > >> > >> > >> > >>On 30-Jan-06, at 16:37 , Eunsoo Shim wrote: > >> > >> > >> > >>>The wording by Juergen is OK with me, too. > >>>So far, no one objected to adding such a statement into > the charter > >>>draft. > >>>Philip expressed a concern about it (saying it does not add > >>> > >>> > >>anything > >> > >> > >>>new) but I see from his email that he is willing to accept > >>> > >>> > >>the change. > >> > >> > >>>Philip, please correct me if I am wrong here. > >>>I believe we agree on what the statement should say and > >>> > >>> > >>there are only > >> > >> > >>>subtle differences in wording. > >>>These subtle differences of wording should not prevent us > >>> > >>> > >>from moving > >> > >> > >>>forward. > >>> > >>>Dean and David, if appropriate, would you mind integrating the > >>>proposed statement into the charter draft and posting the > >>> > >>> > >>new revised > >> > >> > >>>draft? > >>>Thanks. > >>> > >>>Eunsoo > >>> > >>>Dean Willis wrote: > >>> > >>> > >>> > >>>>On Jan 30, 2006, at 7:47 AM, Juergen Quittek wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>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. > >>>>> > >>>>> > >>>>This is also acceptable to me, and I think it might draw > >>>> > >>>> > >>less fire > >> > >> > >>>>from the IAB than the previous formulation. > >>>> > >>>>-- > >>>>Dean > >>>> > >>>> > >>>> > >>_______________________________________________ > >>p2p-sip mailing list > >>p2p-sip at cs.columbia.edu > >>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip > >> > >> > >> > > From dean.willis at softarmor.com Tue Jan 31 13:10:32 2006 From: dean.willis at softarmor.com (Dean Willis) Date: Tue, 31 Jan 2006 12:10:32 -0600 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: References: Message-ID: <5EECA7C0-D917-4D0E-9E8C-D0362E1E01BB@softarmor.com> On Jan 31, 2006, at 8:58 AM, Romascanu, Dan ((Dan)) wrote: > Personally I prefer to list the deliverables and mention in > brackets (if > needed), so that we have a clear idea what and when to do this if the > situation asks. Regards, Dan Of course, the problem is that we don't yet know exactly what extensions we will need to propose or request. Therefore, it's hard to build specific deliverables and milestones into the charter. We could explicitly describe the work process around this, something like: 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? -- Dean From dromasca at avaya.com Tue Jan 31 13:17:58 2006 From: dromasca at avaya.com (Romascanu, Dan (Dan)) Date: Tue, 31 Jan 2006 20:17:58 +0200 Subject: [p2p-sip] Issue #6 NAT Traversal milestone Message-ID: This sounds reasonable to me. Regards, Dan > -----Original Message----- > From: Dean Willis [mailto:dean.willis at softarmor.com] > Sent: Tuesday, January 31, 2006 8:11 PM > To: Romascanu, Dan (Dan) > Cc: Eunsoo Shim; Philip Matthews; Juergen Quittek; Michael > Slavitch; Roy, Radhika R.; P2P-SIP > Subject: Re: [p2p-sip] Issue #6 NAT Traversal milestone > > > On Jan 31, 2006, at 8:58 AM, Romascanu, Dan ((Dan)) wrote: > > > Personally I prefer to list the deliverables and mention in > brackets > > (if needed), so that we have a clear idea what and when to > do this if > > the situation asks. Regards, Dan > > Of course, the problem is that we don't yet know exactly what > extensions we will need to propose or request. Therefore, > it's hard to build specific deliverables and milestones into > the charter. > > We could explicitly describe the work process around this, something > like: > > 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? > > -- > Dean > From philip_matthews at magma.ca Tue Jan 31 13:40:59 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Tue, 31 Jan 2006 13:40:59 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: <5EECA7C0-D917-4D0E-9E8C-D0362E1E01BB@softarmor.com> References: <5EECA7C0-D917-4D0E-9E8C-D0362E1E01BB@softarmor.com> Message-ID: <9A5DAB02-5EF7-4BCF-85C7-1D1F4DDAE1C5@magma.ca> Dean: Where would you put this paragraph? How do you feel about the following? OLD: 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. 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. Does this work? - Philip On 31-Jan-06, at 13:10 , Dean Willis wrote: > > On Jan 31, 2006, at 8:58 AM, Romascanu, Dan ((Dan)) wrote: > >> Personally I prefer to list the deliverables and mention in >> brackets (if >> needed), so that we have a clear idea what and when to do this if the >> situation asks. Regards, Dan > > Of course, the problem is that we don't yet know exactly what > extensions we will need to propose or request. Therefore, it's hard > to build specific deliverables and milestones into the charter. > > We could explicitly describe the work process around this, > something like: > > 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? > > -- > Dean From slavitch at gmail.com Tue Jan 31 15:16:05 2006 From: slavitch at gmail.com (Michael Slavitch) Date: Tue, 31 Jan 2006 15:16:05 -0500 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: <1fc32c8f0601311216g65ba5c77t@mail.gmail.com> It does indeed. Thank you. On 31/01/06, Philip Matthews wrote: > > Dean: > > Where would you put this paragraph? > > How do you feel about the following? > > OLD: > > 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. > > 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. > > Does this work? > > - Philip > > > > On 31-Jan-06, at 13:10 , Dean Willis wrote: > > > > > On Jan 31, 2006, at 8:58 AM, Romascanu, Dan ((Dan)) wrote: > > > >> Personally I prefer to list the deliverables and mention in > >> brackets (if > >> needed), so that we have a clear idea what and when to do this if the > >> situation asks. Regards, Dan > > > > Of course, the problem is that we don't yet know exactly what > > extensions we will need to propose or request. Therefore, it's hard > > to build specific deliverables and milestones into the charter. > > > > We could explicitly describe the work process around this, > > something like: > > > > 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? > > > > -- > > Dean > > -- Michael Slavitch Ottawa, Ontario Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060131/c0fe25c5/attachment.html From eunsoo at research.panasonic.com Tue Jan 31 16:36:19 2006 From: eunsoo at research.panasonic.com (Eunsoo Shim) Date: Tue, 31 Jan 2006 16:36:19 -0500 Subject: [p2p-sip] Issue #6 NAT Traversal milestone In-Reply-To: <1fc32c8f0601311216g65ba5c77t@mail.gmail.com> References: <5EECA7C0-D917-4D0E-9E8C-D0362E1E01BB@softarmor.com> <9A5DAB02-5EF7-4BCF-85C7-1D1F4DDAE1C5@magma.ca> <1fc32c8f0601311216g65ba5c77t@mail.gmail.com> Message-ID: <43DFD853.7050505@research.panasonic.com> It looks good to me, as well. Eunsoo Michael Slavitch wrote: > It does indeed. Thank you. > > On 31/01/06, *Philip Matthews* > wrote: > > Dean: > > Where would you put this paragraph? > > How do you feel about the following? > > OLD: > > 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. > > 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. > > Does this work? > > - Philip > > > > On 31-Jan-06, at 13:10 , Dean Willis wrote: > > > > > On Jan 31, 2006, at 8:58 AM, Romascanu, Dan ((Dan)) wrote: > > > >> Personally I prefer to list the deliverables and mention in > >> brackets (if > >> needed), so that we have a clear idea what and when to do this > if the > >> situation asks. Regards, Dan > > > > Of course, the problem is that we don't yet know exactly what > > extensions we will need to propose or request. Therefore, it's hard > > to build specific deliverables and milestones into the charter. > > > > We could explicitly describe the work process around this, > > something like: > > > > 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? > > > > -- > > Dean > > > > > -- > Michael Slavitch > Ottawa, Ontario Canada