From p2psip-bounces@ietf.org Sun Apr 01 03:48:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXunB-0002i1-6S; Sun, 01 Apr 2007 03:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXunA-0002hw-1Z for p2psip@ietf.org; Sun, 01 Apr 2007 03:48:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXun5-00080I-LA for p2psip@ietf.org; Sun, 01 Apr 2007 03:48:00 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2007 00:47:55 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l317lsvL022958; Sun, 1 Apr 2007 00:47:54 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l317lswo028041; Sun, 1 Apr 2007 07:47:54 GMT In-Reply-To: <3BB64C2D-74B1-4483-AB2D-FE33E8823128@magma.ca> References: <24CCCC428EFEA2469BF046DB3C7A8D2252751E@namail5.corp.adobe.com> <20d2bdfb0703071227pd939889ue734de3cf469ff1e@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D22579AB1@namail5.corp.adobe.com> <45F05DFD.4090507@telecomitalia.it> <24CCCC428EFEA2469BF046DB3C7A8D22579CE5@namail5.corp.adobe.com> <3BB64C2D-74B1-4483-AB2D-FE33E8823128@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <780D6F9D-A7AD-447D-82AF-E57570EFAF04@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Design decisions Date: Sun, 1 Apr 2007 00:47:27 -0700 To: Henry Sinnreich , Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3471; t=1175413675; x=1176277675; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Design=20decisions |Sender:=20; bh=wIzgAuO5hNdzvPS7OKP679Evrx+yVD0gbNfoaGZWQ5Q=; b=uK7YYNPPytehCmSJ1/7wQ5D39Ovj/lWhTo6lQZ9OEYAk4GMwmczSjxUfjZ5TGRIo3hLHuGW4 YbnjrC3v+YyhHuxWR8Rz0rbOsPRsn2UGO9MYG6g8sfQXIQfQooUqGRQ5; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This might be slightly inappropriate for this list but I wanted to point researchers interested in the questions Henry poised at a potential source of funding: http://www.cisco.com/web/about/ac50/ac207/crc/rfp07006.html (And yes, I 100% agree with Henry and others on this thread) On Mar 9, 2007, at 8:05 AM, Philip Matthews wrote: > I totally agree with Henry that a comparison document would be very > helpful. > > - Philip > > On 8-Mar-07, at 21:08 , Henry Sinnreich wrote: > >> Yes, having running code + open source has made most of the de facto >> standards, while the lack of such as hindered the deployment of some >> IETF standards. >> It is not a sufficient condition for success, but a necessary one. >> >> Talking of CAN, Chord, Bamboo, etc.; it would be helpful to have a >> comparison based on some features and metrics, such as >> >> - Usability for search (find you by last name), app layer >> multicast for >> conferencing, etc. >> >> - number of messages (iterative, recursive), >> >> - size of routing tables, >> >> - how do the leafs work?, >> >> - neighbor proximity selection by delay, >> >> - additional routing tables (cashed neighbors), >> >> - stabilization efficiency, >> >> - Can the code be inspected? Footprint, etc. >> >> Sorry for rattling these off on the fly, but we need a document that >> states the meaningful comparison criteria and then makes >> recommendations >> what features are required for the DHT for P2P SIP. >> >> Henry >> >> >> -----Original Message----- >> From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] >> Sent: Thursday, March 08, 2007 1:03 PM >> To: Henry Sinnreich >> Cc: lowekamp@gmail.com; p2p-sip@cs.columbia.edu; p2psip@ietf.org >> Subject: Re: [P2PSIP] Design decisions >> >> Henry Sinnreich wrote: >>> Well written I-Ds cannot replace running code for peers over the >>> Internet - that's my main concern and source of reservations. >>> Until we >>> have our own running code (open source too) over the network, we can >> at >>> least use Bamboo as a starting point, unless we have something else, >>> proven as well. >> >> I fully agree about the running code part, but I'd point out jxta.org >> research section (http://www.jxta.org/research/) as a great source of >> information too. JXTA, btw, implements also the CAN algorithm, >> which, >> even if isn't the preferred DHT on this list, seems particularly well >> suited for environments full of NATs. >> >> -- >> Ciao, >> Enrico >> >> Ahem.. Sorry, the notice below is not my fault :-( >> -------------------------------------------------------------------- >> >> CONFIDENTIALITY NOTICE >> >> This message and its attachments are addressed solely to the persons >> above and may contain confidential information. If you have >> received the >> message in error, be informed that any use of the content hereof is >> prohibited. Please return it immediately to the sender and delete the >> message. Should you have any questions, please contact us by >> replying to >> webmaster@telecomitalia.it. >> >> Thank you >> >> www.telecomitalia.it >> >> -------------------------------------------------------------------- >> >> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 01 09:21:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzzI-00089Y-VQ; Sun, 01 Apr 2007 09:20:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXzzI-00089T-JP for p2psip@ietf.org; Sun, 01 Apr 2007 09:20:52 -0400 Received: from tapal.aricent.com ([203.145.155.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXzzG-0005qf-AG for p2psip@ietf.org; Sun, 01 Apr 2007 09:20:52 -0400 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l31DKUZ2011980 for ; Sun, 1 Apr 2007 18:50:30 +0530 Received: from pragati.blr.hss.hns.com (pragati.blr.hss.hns.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l31DKTOi011974for ; Sun, 1 Apr 2007 18:50:30 +0530 Importance: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 From: anuroop.r@aricent.com To: p2psip@ietf.org Date: Sun, 1 Apr 2007 18:50:10 +0530 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.5 November 30, 2005 X-MIMETrack: Serialize by Notes Server on Prudent/BLR/HSS(Release 6.5.5|November 30, 2005) at04/01/2007 06:50:10 PM, Serialize complete at 04/01/2007 06:50:10 PM, Itemize by Notes Server on Prudent/BLR/HSS(Release 6.5.5|November 30, 2005) at04/01/2007 06:50:10 PM, Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at04/01/2007 06:48:32 PM,Serialize complete at 04/01/2007 06:48:32 PM MIME-Version: 1.0 X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.9781 TC:1F TRN:91 TV:3.6.1039(15086.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.5 (+) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Subject: [P2PSIP] Comments on draft-baset-p2psip-p2pcommon-01 Attn: Baset/Schulzrinne X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1116718424==" Errors-To: p2psip-bounces@ietf.org --===============1116718424== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Comments=20on=20draft-baset-p2psip-p2pcommon-0= 1
-----------------------------------------------
1.=20I=20had=20go= ne=20through=20this=20draft=20and=20currently=20implementing=20the=20same= .
  =20It=20covers=20most=20of=20the=20aspect=20except=20tha= t=20there=20are=20some=20more=20methods
  =20to=20be=20defin= ed=20and=20some=20corrected=20as=20given=20below.
  =20
&= nbsp; =20
  =20Comments=20on=20the=20draft
 &nb= sp;=20-----------------------------
  =20
  =20=
  =20i)=20On=20Peer-Lookup,=20it=20is=20stated=20that=20"A= =20peer=20MAY=20send=20a=20Peer=20lookup=20message
   &= nbsp; =20to=20update=20its=20routing=20or=20neighbor=20table=20entri= es".
     =20
    &nbs= p;=20From=20the=20above=20statement,=20i=20understand=20that=20a=20Peer= =20P1=20issues =20Peer-Lookup
     =20me= ssage=20to=20another=20Peer=20P2.=20On=20receiving=20the=20Peer-Lookup=20= response=20from=20P2,
     =20P1=20updates=20= its=20routing/table=20based=20on=20the=20Peer-Lookup=20response.
 = ;    =20Is=20the=20above=20understanding=20correct?     =20
     =20T= here=20is=20also=20an=20Update=20message=20defined.=20"It=20states=20that= =20A=20peer=20sends=20an
     =20update=20req= uest=20to=20another=20peer=20to=20request=20a=20copy=20of=20its=20neighbo= r=20or=20routing
     =20table=20peers".
&= nbsp;    =20
     =20What= =20is=20the=20significance=20of=20this=20method?.=20Peer-Lookup=20method= =20serves=20the
     =20same=20purpose.
&n= bsp; =20
     =20Clear=20differentiation= =20between=20Peer-Lookup=20and=20Update=20is=20not=20made.
  = ;   =20Both=20Peer-Lookup=20and=20Update=20message=20is=20= sent=20to=20obtain=20details =20
     = =20of=20a=20Peer's=20routing/neighbour=20table.=20
   &= nbsp; =20
  =20ii)=20The=20Update=20request=20and=20res= ponse=20[Page=2029]=20parameters=20does=20not=20match=20with=20the=20
=       =20call=20flows=20provided.=20In=20th= e=20call=20flow=20[Page=2069]=20Update=20request=20contains=20routing=20t= able
      =20where=20as=20Update=20resp= onse=20does=20not=20contain=20routing=20table=20in=20contrast=20to=20the<= BR>      =20description=20and=20parameters= =20provided=20in=20Page=2029.
      =20<= BR>      =20So=20i=20guess,=20Update=20requ= est=20is=20to=20indicate=20another=20Peer=20to=20update=20its=20routing= =20table.
      =20i.e.,=20P1=20send=20U= pdate=20request=20to=20P2,=20so=20that=20P2=20updates=20its=20routing=20t= able.
      =20The=20description=20and= =20parameters=20on=20page=2029=20has=20to=20be=20corrected.
 &nbs= p;    =20
      =20<= BR>      =20
   =20Enhanc= ements=20required=20to=20the=20protocol
   =20---------= ----------------------------
   =20
  &nbs= p;=20Considering=20an=20implementatin=20of=20Chord=20as=20DHT,=20there=20= are=20not=20sufficient=20or=20efficient=20messages
   = =20to=20achive=20overlay=20management.=20For=20example,=20consider=20the= =20case=20that=20P2=20wants=20to=20join=20an=20overlay
  &nb= sp;=20and=20P1=20is=20the=20only=20node=20currently=20in=20the=20overlay.= =20(P1=20is=20both=20bootstrap=20and=20admitting=20node
  &n= bsp;=20for=20P2).
   =20
   =20The=20= sequence=20of=20actions=20are=20as=20follows=20(P2=20joins=20P1=20overlay= ).
   =20
   =20P2=20sends=20join=20r= equest=20to=20P1=20(=20to=20join=20the=20overlay).
   = =20P1=20accepts=20and=20sends=20join=20resp=20to=20P2.
  &nb= sp;=20P2=20has=20to=20update=20its=20routing=20table.=20For=20this=20it= =20queries=20P1=20and=20constructs=20its=20routing=20table.
 &nbs= p; =20P2=20indicates=20other=20node=20that=20it=20has=20joined=20the= =20overlay.
   =20P2=20has=20to=20share=20some=20of=20t= he=20resources=20of=20P1.
   =20
   = =20One=20of=20the=20call=20flow=20scenario=20to=20achieve=20the=20same=20= is=20that
   =20
   =20(a)=20Lets=20s= ay=20P2=20has=20to=20construct=20its=20finger=20table.=20While=20doing=20= so=20P2=20has=20to=20repeatedly=20send
   =20P1=20Peer-= Lookup=20as=20it=20wants=20to=20know=20the=20successor=20of=20each=20key= =20of=20its=20finger=20table.
   =20The=20number=20of= =20rows=20depends=20on=20the=20hash-key=20size=20bits=20used=20and=20henc= e=20lot=20of=20Peer-Lookup
   =20messages=20has=20to=20= be=20sent.
   =20
   =20(b)=20As=20pa= rt=20of=20resource=20sharing,=20P2=20wants=20to=20take=20some=20of=20the= =20resources=20of=20P1.=20There=20is=20no
    &nbs= p;  =20method=20directly=20to=20take=20some=20resources=20from= =20P1=20by=20P2.=20
       =20Curre= ntly=20the=20Resource-Replicate=20is=20to=20be=20used.=20However=20in=20t= his=20case,=20resources=20shall
      &n= bsp;=20be=20replicated=20and=20will=20not=20be=20removed.=20A=20separated= =20Remove=20request=20has=20to=20be=20sent.
    &n= bsp;  =20
    =20
   &= nbsp;=20A=20simple=20joining=20mechanism=20would=20result=20in=20lot=20of= =20P2PP=20messages=20exchanged=20between=20joining
   &= nbsp;=20and=20bootstrap/admitting=20node.=20
    = =20
    =20We=20are=20on=20the=20design=20of=20a= =20prototype=20of=20P2PSIP=20overlay=20node=20based=20on=20the=20architec= ture
    =20provided=20by=20draft-hautakorpi-struc= ture-of-p2psip-node-00.=20If=20you=20are=20interested=20i=20can
 =    =20send=20the=20call=20flows=20for=20overlay=20manageme= nt.=20Might=20be=20when=20this=20protocol=20was=20written,=20the
 = ;   =20intent=20of=20a=20method=20was=20different=20from= =20what=20is=20being=20currently=20used=20in=20the=20draft.=20If=20so
=     =20this=20can=20be=20corrected,=20please=20let=20= me=20can=20i=20share=20this=20call=20flow.
    =20=
       =20
   = =20Another=20thing=20to=20be=20considered=20is=20whether=20to=20use=20TCP= /UDP=20and=20iterative/recursive=20routing.
   =20This= =20draft=20fails=20to=20analyse=20the=20pros=20and=20cons=20of=20this.=20= It=20used=20both=20TCP/UDP=20simulataneously
   =20base= d=20on=20message=20size.=20This=20is=20not=20a=20good=20approach.
&nbs= p;  =20
   =20For=20e.g,=20lets=20say=20recur= sive=20routing=20is=20used=20in=20TCP,=20in=20this=20case,=20P1=20sends= =20message=20to=20P2,=20P2=20sends
   =20to=20P3..=20an= d=20so=20on...=20and=20the=20response=20would=20reach=20P1=20after=20trav= ersing=20P3,=20P2=20etc.=20The=20transction
   =20would= =20have=20timed=20out=20at=20P1,=20but=20still=20the=20message=20goes=20o= n=20with=20in=20the=20overlay=20until=20TTL=20is=20zero.
  &= nbsp;=20
   =20
 =20We=20are=20almost=20done=20= with=20the=20implementation=20of=20this=20protocol=20which=20we=20are=20p= lanning=20to=20use=20for
 =20our=20prototype=20of=20SIP=20overlay= =20node.=20If=20interested=20i=20can=20share=20the=20source=20code=20too.=
 
 
Thanks=20&=20Regards,
Anuroop.

*****Aricent-Unclassified=20*****=3D=0D= =0A
"DISCL=
AIMER:=20This=20message=20is=20proprietary=20to=20Aricent=20and=20is=20in=
tended=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20whom=
=20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20confiden=
tial=20information=20and=20should=20not=20be=20=0Acirculated=20or=20used=
=20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20intended.=
=20If=20you=20have=20received=20this=20message=20in=20error,=20=0Aplease=
=20notify=20the=20originator=20immediately.=20If=20you=20are=20not=20the=
=20intended=20recipient,=20you=20are=20notified=20that=20you=20are=20stri=
ctly=0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disclosin=
g=20the=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20resp=
onsibility=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20o=
f=20the=20information=20transmitted=20by=20this=20email=20including=20dam=
age=20from=20virus."=0A
--===============1116718424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1116718424==-- From p2psip-bounces@ietf.org Sun Apr 01 13:04:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3Ti-0007XD-3a; Sun, 01 Apr 2007 13:04:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3Tf-0007Tr-Rs; Sun, 01 Apr 2007 13:04:27 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HY3Tb-0001Xz-S8; Sun, 01 Apr 2007 13:04:27 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 01 Apr 2007 10:04:17 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l31H3kD1008108; Sun, 1 Apr 2007 10:03:50 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l31H4CI9010282; Sun, 1 Apr 2007 10:04:12 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 10:04:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Apr 2007 09:59:22 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> In-Reply-To: <460D9D9C.1040304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: AcdzI3OuuvqnstaoRUubQmppvBh64gBWJEqw References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <072C5B76F7CEAB488172C6F64B30B5E302C88E1B@xmb-rtp-20b.amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC5@namail5.corp.adobe.com> <4603929D.4070604@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC8@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> From: "Henry Sinnreich" To: "Paul Kyzivat" , "Eunsoo Shim" X-OriginalArrivalTime: 01 Apr 2007 17:04:11.0191 (UTC) FILETIME=[C4A11C70:01C7747F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Paul, > I more or less agree with the final conclusion below. This is good starting point to discuss some usage scenarios. Putting on my former hat as an employee for a carrier, I cannot overlook the following: P2P SIP implemented correctly in the residential access box or cable set-top box indeed is a good or better replacement for the entire VoIP network infrastructure (cost, operations, new services, etc).=20 Integrated access devices for the enterprise can probably play a similar role, not to mention existing P2P PBX products (please refer to all the advantages of P2P that need not repeated here). What do people think of these three usage scenarios for P2P SIP: - SIP peer in the DSL access device, - SIP peer in the cable access device, - SIP peer in enterprise network integrated access device (IAD). Note that these examples imply very low churn for the peers and add the data retention resilience of P2P (geographic diversity is native and mobile, etc.). Incidentally, NAT traversal may also not be a problem, or at least an easier problem. What do you all think? I have taken the liberty to copy the P2P SIP list, since the low churn scenarios are of interest for the DHT selection. Or just pick the same DHT for all scenarios anyway? I don't think so. Thanks, Henry -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, March 30, 2007 6:31 PM To: Eunsoo Shim Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario I more or less agree with the final conclusion below. My main point here is that P2P and C/S need not be enemies. Nor is a=20 total C/S system necessarily evil. What is most evil is *bundling* of=20 services that prevents freedom of choice. I think I would be quite happy with a SP that provides a registrar/proxy and allows me to provide all other features as I see fit - by taking=20 them ala carte from the SP, or subscribing to them from one or more=20 other SPs, or by providing them myself via appliances I own. If that=20 registrar/proxy was replaced by a P2P sip community, the differences, if any, would hopefully be more a function of the implementation and the=20 business models of those involved than the architecture. (I gather the general assumption is that a P2P setup will be *free*. But I have a hard time believing that. If most of the usage is by mobile=20 devices that can't be peers, then somebody will have to pay for enough=20 peers to support them. If it isn't free, then how is it better than a=20 well engineered C/S system?) So I think the key thing here is that some features will require getting some help from another node. There ought to be the option to pick a=20 different source for each helper you require, and an ability for it all=20 to play together. Paul Eunsoo Shim wrote: > Please see my inline comment. >=20 > On 3/30/07, *Paul Kyzivat* > wrote: >=20 >=20 >=20 > Henry Sinnreich wrote: > > David Oran wrote (with regard to voice mail): > > > >> I'm not saying this can't be made to work, only that it isn't > > immediately >obvious that it has advantages over a classic > application > > server >approach. > > > > The answer for VM is "it depends": > > >=20 >=20 > I agree. It really depends. Certainly there are tradeoffs. >=20 > > There are several commercial P2P IP PBX solutions without any > server for > > VM or anything else. No doubt the IT organization appreciates just > > having to plug in the IP phones and GWY to the PSTN without any > > configuration ever for VM or any other PBX feature. >=20 > I don't understand. Are you saying they don't have VM, or that they > don't have a *server* for VM? >=20 >=20 > I guess they don't have a *server* for VM. >=20 > > For public P2P SIP networks there are two more scenarios where VM can > > reside (and without ever spending one cent on VM servers + IT > systems): > > > > - In Cable and DSL service provider networks: The residential > router can > > act as a voice recorder >=20 > That is simply an example of the user having an appliance of his own > that provides VM service. >=20 > > and P2P can cover the not too frequent cases, > > where the router is not in operation, so the data is backed up in > other > > peer residential gateways (encrypted). >=20 > I guess I just need to have more info about how this would work before I > will be convinced it is feasible and trustworthy. >=20 >=20 > Well, 'trustworthy' could be considered in many angles. > If it is about privacy of the message, a public key based encryption=20 > would provide acceptable privacy. > If it is about reliability of the message delivery, well, a P2P based=20 > asynchronous message delivery (like VM) is most likely less reliable=20 > than a well managed server based system. > However, my experience with Skype's asynchronous message delivery was=20 > not bad. Actually I don't see any significant difference between it and=20 > my cellular service provider's VM service. :-) > Reliability is always a challenge for P2P, for sure. But, I believe it > is feasible to build a P2P system for VM acceptable for many scenarios. >=20 > > - In mobile networks: The VM can reside in quite stable peers > inside the > > wireless base station network. The peers in the base station network > > need no configuration, etc. >=20 > I don't understand. I guess that could be true if the peers are willing > to store an arbitrary amount of VM indefinitely for anybody. Is that > believable? >=20 >=20 > It depends. > In a very nice environment where all the peers are willing to cooperate=20 > at their best, the peers will store as much as they can. In a tough=20 > environment, the situation will be different. >=20 > This seems to translate to a model where it is assumed that those nodes > that are on most of the time will be willing to provide VM storage for > those nodes that aren't on most of the time. >=20 >=20 > This is again related to reliability of P2P systems or topics like free=20 > riders and reputation. > A P2P system is a community or society. To be simple, if many of the=20 > members are bad, the community won't work well. If the majority of the > members are good, the community will work well or reasonably. >=20 > > Add to this the conferencing capability coming from p2p application > > layer multicast, the SIP e2e control capabilities (for such as > > auto-attendant, agent workstation, etc.) and one has to wonder why IT > > networks, public VoIP networks and end users should support the huge > > cost of hand engineering, testing, monitoring, maintaining server > based > > VoIP networks. P2P self configuration is nothing less that automation > > applied to VoIP, plus the shifting of computing to the endpoints, > where > > there is an abundance of unused CPU, storage, bandwidth and > electricity. > > > > Eric Burger also notes IM changes completely the usage for VM and may > > make unnecessary to place calls on VM in the first place. >=20 > I find this more promising. >=20 > =20 >=20 >=20 > In overall, are we discussing if P2P systems based VM can work? I think=20 > it can work. Just it depends on many things. > If it is not super-reliable, should we disregard it? I would say no. >=20 > On the other hand, do we have to abandon client server based VM and=20 > switch to P2P system based VM? It is upto each of us. > Client server based VM systems are already there. > So why don't we work on P2P based VM now? > =20 > Thanks. >=20 > Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 01 22:37:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCPg-0001fQ-1h; Sun, 01 Apr 2007 22:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCPd-0001fC-Ro for p2psip@ietf.org; Sun, 01 Apr 2007 22:36:53 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYCPa-0000j4-Vk for p2psip@ietf.org; Sun, 01 Apr 2007 22:36:53 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFU003DDN87P6@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 02 Apr 2007 10:36:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFU00IH2N87SY@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 02 Apr 2007 10:36:07 +0800 (CST) Received: from j36340 ([10.164.5.25]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFU007BON81MC@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 02 Apr 2007 10:36:07 +0800 (CST) Date: Mon, 02 Apr 2007 10:36:01 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Peer definition in Concept draft In-reply-to: <7b683f3f0703310606m31e796ebuaf3b4a37626a4e2a@mail.gmail.com> To: 'Eunsoo Shim' Message-id: <000a01c774cf$a79d1390$1905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcdzlWl1rphf4e6kQ2aJS6xvUwEKygBOJr8g X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'Philip Matthews' , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Eunsoo: I agree with you that Peers and SIP entities are two independent roles = in the VoIP applications. Peers are organized collectively to provide distributed location service whereas SIP entities use SIP protocol to establish sessions. Since nodes who behave as peers in P2P perspective may not speak SIP, I = have two questions arising from it: 1) How do the peers who could not recognize SIP messages use SIP to = deliver P2P message? 2) How do the non-peer nodes put/get resource information into/from the overlay only by using SIP message if the peers who the non-peer nodes contact with could not speak SIP?=20 Regards! -- Jiang XingFeng ________________________________________ From: Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: Saturday, March 31, 2007 9:06 PM To: JiangXingFeng Cc: Philip Matthews; p2psip@ietf.org Subject: Re: [P2PSIP] Peer definition in Concept draft A peer may not be coupled to any SIP entity. If we assume the Peer Protocol is not based on SIP, the above means that = a peer may not have to speak SIP. Actually we should say that it is not = the peer but the SIP entity that speaks SIP.=20 A peer MUST be able to speak the Peer Protocol. Thanks. Eunsoo On 3/31/07, JiangXingFeng < jiang.x.f@huawei.com> wrote: Hi, Philips: I have noticed that there are minor differences between version 03 and=20 version 04.=A0=A0I list them as follows: Version 3: Each P2PSIP Peer may or may not (NOT) be coupled to one or more P2PSIP = User Agents. Version 4: Each P2PSIP Peer may be coupled to one or more SIP entities.=20 By comparing the difference, could we come to a conclusion that all = peers should speak SIP in the version 04? Regards! -- Jiang XingFeng _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 01 23:48:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYDWf-0007We-5T; Sun, 01 Apr 2007 23:48:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYDWe-0007WT-Ad for p2psip@ietf.org; Sun, 01 Apr 2007 23:48:12 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYDWb-0002Z7-PE for p2psip@ietf.org; Sun, 01 Apr 2007 23:48:12 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFU00MEBQIXFW@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 02 Apr 2007 11:47:22 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFU0048DQIXN5@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 02 Apr 2007 11:47:21 +0800 (CST) Received: from x18916 ([10.85.204.175]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFU00HT6QITAV@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 02 Apr 2007 11:47:21 +0800 (CST) Date: Mon, 02 Apr 2007 11:47:17 +0800 From: Peili Xu Subject: RE: [P2PSIP] Peer definition in Concept draft In-reply-to: <000a01c774cf$a79d1390$1905a40a@china.huawei.com> To: 'JiangXingFeng' , 'Eunsoo Shim' Message-id: <010e01c774d9$9be6fc00$afcc550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcdzlWl1rphf4e6kQ2aJS6xvUwEKygBOJr8gAAKrGZA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: 'Philip Matthews' , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Xingfeng see inline -----Original Message----- From: JiangXingFeng [mailto:jiang.x.f@huawei.com]=20 Sent: Monday, April 02, 2007 10:36 AM To: 'Eunsoo Shim' Cc: 'Philip Matthews'; p2psip@ietf.org Subject: RE: [P2PSIP] Peer definition in Concept draft Hi, Eunsoo: I agree with you that Peers and SIP entities are two independent roles in the VoIP applications. Peers are organized collectively to provide distributed location service whereas SIP entities use SIP protocol to establish sessions. Since nodes who behave as peers in P2P perspective may not speak SIP, I have two questions arising from it: 1) How do the peers who could not recognize SIP messages use SIP to deliver P2P message? [xpl] there is no assumption that SIP is used to deliver P2P message. 2) How do the non-peer nodes put/get resource information into/from the overlay only by using SIP message if the peers who the non-peer nodes contact with could not speak SIP?=20 [xpl] Not all peer must speak SIP doesn't mean a peer can not speek SIP.=20 In the case u mentioned, the peer who get/put resource info in to the DHT unbehalf of a non-peer SIP entity can speak SIP if the interface between non-peer and peer is only SIP. [xpl] But, it is still uncertain for interfaces and protocol requirements for entities before the protocol selection was made. Regards! -- Jiang XingFeng ________________________________________ From: Eunsoo Shim [mailto:eunsooshim@gmail.com] Sent: Saturday, March 31, 2007 9:06 PM To: JiangXingFeng Cc: Philip Matthews; p2psip@ietf.org Subject: Re: [P2PSIP] Peer definition in Concept draft A peer may not be coupled to any SIP entity. If we assume the Peer Protocol is not based on SIP, the above means that a peer may not have to speak SIP. Actually we should say that it is not the peer but the SIP entity that speaks SIP.=20 A peer MUST be able to speak the Peer Protocol. Thanks. Eunsoo On 3/31/07, JiangXingFeng < jiang.x.f@huawei.com> wrote: Hi, Philips: I have noticed that there are minor differences between version 03 and version 04.=A0=A0I list them as follows: Version 3: Each P2PSIP Peer may or may not (NOT) be coupled to one or more P2PSIP User Agents. Version 4: Each P2PSIP Peer may be coupled to one or more SIP entities.=20 By comparing the difference, could we come to a conclusion that all peers should speak SIP in the version 04? Regards! -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 09:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMJl-0003x3-2f; Mon, 02 Apr 2007 09:11:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY56L-00075O-5D for p2psip@ietf.org; Sun, 01 Apr 2007 14:48:29 -0400 Received: from smtp3.versatel.nl ([62.58.50.90]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY56A-0001RU-2W for p2psip@ietf.org; Sun, 01 Apr 2007 14:48:27 -0400 Received: (qmail 14759 invoked by uid 0); 1 Apr 2007 18:47:54 -0000 Received: from ip198-11-212-87.adsl2.versatel.nl (HELO BEMBUSTER) ([87.212.11.198]) (envelope-sender ) by smtp3.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Apr 2007 18:47:54 -0000 Message-ID: <00b201c7748e$33067df0$0601a8c0@BEMBUSTER> From: "Jeroen van Bemmel" To: "Henry Sinnreich" , "Paul Kyzivat" , "Eunsoo Shim" References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <072C5B76F7CEAB488172C6F64B30B5E302C88E1B@xmb-rtp-20b.amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC5@namail5.corp.adobe.com> <4603929D.4070604@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC8@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com><7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com><460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> Date: Sun, 1 Apr 2007 20:47:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 X-Mailman-Approved-At: Mon, 02 Apr 2007 09:11:27 -0400 Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry, Aren't you confusing "usage scenarios" with "deployment scenarios" here? Why restrict P2P SIP to only certain types of devices? And if you insist on that, why not mobile devices? Regards, Jeroen Henry Sinnreich wrote: > Paul, > >> I more or less agree with the final conclusion below. > > This is good starting point to discuss some usage scenarios. > > Putting on my former hat as an employee for a carrier, I cannot > overlook the following: > > P2P SIP implemented correctly in the residential access box or cable > set-top box indeed is a good or better replacement for the entire VoIP > network infrastructure (cost, operations, new services, etc). > Integrated access devices for the enterprise can probably play a > similar role, not to mention existing P2P PBX products (please refer > to all the advantages of P2P that need not repeated here). > > What do people think of these three usage scenarios for P2P SIP: > - SIP peer in the DSL access device, > - SIP peer in the cable access device, > - SIP peer in enterprise network integrated access device (IAD). > > Note that these examples imply very low churn for the peers and add > the data retention resilience of P2P (geographic diversity is native > and mobile, etc.). Incidentally, NAT traversal may also not be a > problem, or at least an easier problem. > > What do you all think? > > I have taken the liberty to copy the P2P SIP list, since the low churn > scenarios are of interest for the DHT selection. Or just pick the same > DHT for all scenarios anyway? I don't think so. > > Thanks, Henry > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, March 30, 2007 6:31 PM > To: Eunsoo Shim > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; > p2prg@ietf.org; sipping@ietf.org; zhuxian > Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > I more or less agree with the final conclusion below. > > My main point here is that P2P and C/S need not be enemies. Nor is a > total C/S system necessarily evil. What is most evil is *bundling* of > services that prevents freedom of choice. > > I think I would be quite happy with a SP that provides a > registrar/proxy > > and allows me to provide all other features as I see fit - by taking > them ala carte from the SP, or subscribing to them from one or more > other SPs, or by providing them myself via appliances I own. If that > registrar/proxy was replaced by a P2P sip community, the differences, > if > > any, would hopefully be more a function of the implementation and the > business models of those involved than the architecture. > > (I gather the general assumption is that a P2P setup will be *free*. > But > > I have a hard time believing that. If most of the usage is by mobile > devices that can't be peers, then somebody will have to pay for enough > peers to support them. If it isn't free, then how is it better than a > well engineered C/S system?) > > So I think the key thing here is that some features will require > getting > > some help from another node. There ought to be the option to pick a > different source for each helper you require, and an ability for it > all to play together. > > Paul > > Eunsoo Shim wrote: >> Please see my inline comment. >> >> On 3/30/07, *Paul Kyzivat* > > wrote: >> >> >> >> Henry Sinnreich wrote: >> > David Oran wrote (with regard to voice mail): >> > >> >> I'm not saying this can't be made to work, only that it isn't >> > immediately >obvious that it has advantages over a classic >> application >> > server >approach. >> > >> > The answer for VM is "it depends": >> > >> >> >> I agree. It really depends. Certainly there are tradeoffs. >> >> > There are several commercial P2P IP PBX solutions without any >> server for >> > VM or anything else. No doubt the IT organization appreciates >> just > having to plug in the IP phones and GWY to the PSTN >> without any > configuration ever for VM or any other PBX >> feature. >> >> I don't understand. Are you saying they don't have VM, or that >> they don't have a *server* for VM? >> >> >> I guess they don't have a *server* for VM. >> >> > For public P2P SIP networks there are two more scenarios >> where VM can > reside (and without ever spending one cent on VM >> servers + IT systems): >> > >> > - In Cable and DSL service provider networks: The residential >> router can >> > act as a voice recorder >> >> That is simply an example of the user having an appliance of his >> own that provides VM service. >> >> > and P2P can cover the not too frequent cases, >> > where the router is not in operation, so the data is backed >> up in other >> > peer residential gateways (encrypted). >> >> I guess I just need to have more info about how this would work >> before I will be convinced it is feasible and trustworthy. >> >> >> Well, 'trustworthy' could be considered in many angles. >> If it is about privacy of the message, a public key based encryption >> would provide acceptable privacy. >> If it is about reliability of the message delivery, well, a P2P based >> asynchronous message delivery (like VM) is most likely less reliable >> than a well managed server based system. >> However, my experience with Skype's asynchronous message delivery was >> not bad. Actually I don't see any significant difference between it >> and my cellular service provider's VM service. :-) >> Reliability is always a challenge for P2P, for sure. But, I believe >> it > >> is feasible to build a P2P system for VM acceptable for many >> scenarios. >> >> > - In mobile networks: The VM can reside in quite stable peers >> inside the >> > wireless base station network. The peers in the base station >> network > need no configuration, etc. >> >> I don't understand. I guess that could be true if the peers are >> willing to store an arbitrary amount of VM indefinitely for >> anybody. Is that believable? >> >> >> It depends. >> In a very nice environment where all the peers are willing to >> cooperate at their best, the peers will store as much as they can. >> In a tough environment, the situation will be different. >> >> This seems to translate to a model where it is assumed that >> those nodes that are on most of the time will be willing to >> provide VM storage for those nodes that aren't on most of the >> time. >> >> >> This is again related to reliability of P2P systems or topics like >> free riders and reputation. >> A P2P system is a community or society. To be simple, if many of the >> members are bad, the community won't work well. If the majority of >> the > >> members are good, the community will work well or reasonably. >> >> > Add to this the conferencing capability coming from p2p >> application > layer multicast, the SIP e2e control capabilities >> (for such as > auto-attendant, agent workstation, etc.) and one >> has to wonder why IT > networks, public VoIP networks and end >> users should support the huge > cost of hand engineering, >> testing, monitoring, maintaining server based >> > VoIP networks. P2P self configuration is nothing less that >> automation > applied to VoIP, plus the shifting of computing to >> the endpoints, where >> > there is an abundance of unused CPU, storage, bandwidth and >> electricity. >> > >> > Eric Burger also notes IM changes completely the usage for VM >> and may > make unnecessary to place calls on VM in the first >> place. >> >> I find this more promising. >> >> >> >> >> In overall, are we discussing if P2P systems based VM can work? I >> think it can work. Just it depends on many things. >> If it is not super-reliable, should we disregard it? I would say no. >> >> On the other hand, do we have to abandon client server based VM and >> switch to P2P system based VM? It is upto each of us. >> Client server based VM systems are already there. >> So why don't we work on P2P based VM now? >> >> Thanks. >> >> Eunsoo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 09:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMe9-0001Jq-9j; Mon, 02 Apr 2007 09:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMe8-0001Jh-Nn for p2psip@ietf.org; Mon, 02 Apr 2007 09:32:32 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMe7-0005LA-0V for p2psip@ietf.org; Mon, 02 Apr 2007 09:32:32 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1461316ugd for ; Mon, 02 Apr 2007 06:32:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=WfK1xBlUD9udSdbnbz299lIwb/lpdECIs3xIWBIBW/t7oxC2Gv9V5n8IJiWf2imAuxvbNugtqBhNlsCtpFAtELnLxTwegmrM8oykMT20oxYji8fE8xosj1N6P7Nc9CoPOKEPIP3E+StWPM9bSSAsDowYLkbez5SdVg6Lz7wvH34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=a1TjbeIG7aTLhyoE+RG1kLGkJ1ItJW2kQ11VjfUuBRkIvZNjpHg5CUZCNAzsfT04NGFHt/GsiVOZcX18eWiIrElNPSGq6Ir+zXcA7ZHksqzGibC2eTXTzKhIjrm8JyLxFukeirj8iPE4cvF3pApvQyD1AMrR9sA5drqe0tT5gX8= Received: by 10.82.154.2 with SMTP id b2mr1461004bue.1175520748792; Mon, 02 Apr 2007 06:32:28 -0700 (PDT) Received: by 10.82.127.17 with HTTP; Mon, 2 Apr 2007 06:32:28 -0700 (PDT) Message-ID: <4d4304a00704020632r71315532s1be1df106c4f426a@mail.gmail.com> Date: Mon, 2 Apr 2007 09:32:28 -0400 From: "David A. Bryan" To: "Jeroen van Bemmel" Subject: Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario In-Reply-To: <00b201c7748e$33067df0$0601a8c0@BEMBUSTER> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> <00b201c7748e$33067df0$0601a8c0@BEMBUSTER> X-Google-Sender-Auth: d7b6568599097134 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , Henry Sinnreich , p2prg@ietf.org, sipping@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I don't think Henry was saying only there -- just that that might be another deployment we haven't thought about. I am pretty sure he is very much in favor of having them in wireless devices. Personally, I think that putting P2PSIP peers in edge devices would be a good place to do it for home wireline users -- as Henry points out, it avoids the NAT issue, among other things. Of course I would also want to see them in UAs, softphones, wireless devices, maybe even consumer devices, etc. (and I am sure Henry wants to see P2PSIP peers everywhere too!) David On 4/1/07, Jeroen van Bemmel wrote: > Henry, > > Aren't you confusing "usage scenarios" with "deployment scenarios" here? Why > restrict P2P SIP to only certain types of devices? And if you insist on > that, why not mobile devices? > > Regards, > Jeroen > > Henry Sinnreich wrote: > > Paul, > > > >> I more or less agree with the final conclusion below. > > > > This is good starting point to discuss some usage scenarios. > > > > Putting on my former hat as an employee for a carrier, I cannot > > overlook the following: > > > > P2P SIP implemented correctly in the residential access box or cable > > set-top box indeed is a good or better replacement for the entire VoIP > > network infrastructure (cost, operations, new services, etc). > > Integrated access devices for the enterprise can probably play a > > similar role, not to mention existing P2P PBX products (please refer > > to all the advantages of P2P that need not repeated here). > > > > What do people think of these three usage scenarios for P2P SIP: > > - SIP peer in the DSL access device, > > - SIP peer in the cable access device, > > - SIP peer in enterprise network integrated access device (IAD). > > > > Note that these examples imply very low churn for the peers and add > > the data retention resilience of P2P (geographic diversity is native > > and mobile, etc.). Incidentally, NAT traversal may also not be a > > problem, or at least an easier problem. > > > > What do you all think? > > > > I have taken the liberty to copy the P2P SIP list, since the low churn > > scenarios are of interest for the DHT selection. Or just pick the same > > DHT for all scenarios anyway? I don't think so. > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, March 30, 2007 6:31 PM > > To: Eunsoo Shim > > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; > > p2prg@ietf.org; sipping@ietf.org; zhuxian > > Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > > > I more or less agree with the final conclusion below. > > > > My main point here is that P2P and C/S need not be enemies. Nor is a > > total C/S system necessarily evil. What is most evil is *bundling* of > > services that prevents freedom of choice. > > > > I think I would be quite happy with a SP that provides a > > registrar/proxy > > > > and allows me to provide all other features as I see fit - by taking > > them ala carte from the SP, or subscribing to them from one or more > > other SPs, or by providing them myself via appliances I own. If that > > registrar/proxy was replaced by a P2P sip community, the differences, > > if > > > > any, would hopefully be more a function of the implementation and the > > business models of those involved than the architecture. > > > > (I gather the general assumption is that a P2P setup will be *free*. > > But > > > > I have a hard time believing that. If most of the usage is by mobile > > devices that can't be peers, then somebody will have to pay for enough > > peers to support them. If it isn't free, then how is it better than a > > well engineered C/S system?) > > > > So I think the key thing here is that some features will require > > getting > > > > some help from another node. There ought to be the option to pick a > > different source for each helper you require, and an ability for it > > all to play together. > > > > Paul > > > > Eunsoo Shim wrote: > >> Please see my inline comment. > >> > >> On 3/30/07, *Paul Kyzivat* >> > wrote: > >> > >> > >> > >> Henry Sinnreich wrote: > >> > David Oran wrote (with regard to voice mail): > >> > > >> >> I'm not saying this can't be made to work, only that it isn't > >> > immediately >obvious that it has advantages over a classic > >> application > >> > server >approach. > >> > > >> > The answer for VM is "it depends": > >> > > >> > >> > >> I agree. It really depends. Certainly there are tradeoffs. > >> > >> > There are several commercial P2P IP PBX solutions without any > >> server for > >> > VM or anything else. No doubt the IT organization appreciates > >> just > having to plug in the IP phones and GWY to the PSTN > >> without any > configuration ever for VM or any other PBX > >> feature. > >> > >> I don't understand. Are you saying they don't have VM, or that > >> they don't have a *server* for VM? > >> > >> > >> I guess they don't have a *server* for VM. > >> > >> > For public P2P SIP networks there are two more scenarios > >> where VM can > reside (and without ever spending one cent on VM > >> servers + IT systems): > >> > > >> > - In Cable and DSL service provider networks: The residential > >> router can > >> > act as a voice recorder > >> > >> That is simply an example of the user having an appliance of his > >> own that provides VM service. > >> > >> > and P2P can cover the not too frequent cases, > >> > where the router is not in operation, so the data is backed > >> up in other > >> > peer residential gateways (encrypted). > >> > >> I guess I just need to have more info about how this would work > >> before I will be convinced it is feasible and trustworthy. > >> > >> > >> Well, 'trustworthy' could be considered in many angles. > >> If it is about privacy of the message, a public key based encryption > >> would provide acceptable privacy. > >> If it is about reliability of the message delivery, well, a P2P based > >> asynchronous message delivery (like VM) is most likely less reliable > >> than a well managed server based system. > >> However, my experience with Skype's asynchronous message delivery was > >> not bad. Actually I don't see any significant difference between it > >> and my cellular service provider's VM service. :-) > >> Reliability is always a challenge for P2P, for sure. But, I believe > >> it > > > >> is feasible to build a P2P system for VM acceptable for many > >> scenarios. > >> > >> > - In mobile networks: The VM can reside in quite stable peers > >> inside the > >> > wireless base station network. The peers in the base station > >> network > need no configuration, etc. > >> > >> I don't understand. I guess that could be true if the peers are > >> willing to store an arbitrary amount of VM indefinitely for > >> anybody. Is that believable? > >> > >> > >> It depends. > >> In a very nice environment where all the peers are willing to > >> cooperate at their best, the peers will store as much as they can. > >> In a tough environment, the situation will be different. > >> > >> This seems to translate to a model where it is assumed that > >> those nodes that are on most of the time will be willing to > >> provide VM storage for those nodes that aren't on most of the > >> time. > >> > >> > >> This is again related to reliability of P2P systems or topics like > >> free riders and reputation. > >> A P2P system is a community or society. To be simple, if many of the > >> members are bad, the community won't work well. If the majority of > >> the > > > >> members are good, the community will work well or reasonably. > >> > >> > Add to this the conferencing capability coming from p2p > >> application > layer multicast, the SIP e2e control capabilities > >> (for such as > auto-attendant, agent workstation, etc.) and one > >> has to wonder why IT > networks, public VoIP networks and end > >> users should support the huge > cost of hand engineering, > >> testing, monitoring, maintaining server based > >> > VoIP networks. P2P self configuration is nothing less that > >> automation > applied to VoIP, plus the shifting of computing to > >> the endpoints, where > >> > there is an abundance of unused CPU, storage, bandwidth and > >> electricity. > >> > > >> > Eric Burger also notes IM changes completely the usage for VM > >> and may > make unnecessary to place calls on VM in the first > >> place. > >> > >> I find this more promising. > >> > >> > >> > >> > >> In overall, are we discussing if P2P systems based VM can work? I > >> think it can work. Just it depends on many things. > >> If it is not super-reliable, should we disregard it? I would say no. > >> > >> On the other hand, do we have to abandon client server based VM and > >> switch to P2P system based VM? It is upto each of us. > >> Client server based VM systems are already there. > >> So why don't we work on P2P based VM now? > >> > >> Thanks. > >> > >> Eunsoo > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 13:17:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ9j-0001Pr-Lg; Mon, 02 Apr 2007 13:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ9j-0001Pg-7C; Mon, 02 Apr 2007 13:17:23 -0400 Received: from bay0-omc1-s36.bay0.hotmail.com ([65.54.246.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQ9f-0002SY-TS; Mon, 02 Apr 2007 13:17:23 -0400 Received: from bayc1-pasmtp06.bayc1.hotmail.com ([65.54.191.166]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 2 Apr 2007 10:17:19 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp06.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:22:03 -0700 Message-ID: <0be101c7754a$c424bc40$65500a0a@ronin> From: "Eric Cooper" To: "David A. Bryan" , "Jeroen van Bemmel" References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com><24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com><4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com><24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com><460D4825.2090800@cisco.com><7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com><460D9D9C.1040304@cisco.com><24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com><00b201c7748e$33067df0$0601a8c0@BEMBUSTER> <4d4304a00704020632r71315532s1be1df106c4f426a@mail.gmail.com> Subject: Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Mon, 2 Apr 2007 13:16:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 02 Apr 2007 17:22:03.0125 (UTC) FILETIME=[6DF70250:01C7754B] X-Spam-Score: 2.1 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , Henry Sinnreich , p2prg@ietf.org, sipping@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Personally, I think that putting P2PSIP peers in edge devices would be > a good place to do it for home wireline users -- as Henry points out, > it avoids the NAT issue, among other things.=20 Until some ISP NATs their networks. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 13:18:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQAK-0001mx-56; Mon, 02 Apr 2007 13:18:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQAJ-0001mk-Nf for p2psip@ietf.org; Mon, 02 Apr 2007 13:17:59 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQAI-0002V6-9q for p2psip@ietf.org; Mon, 02 Apr 2007 13:17:59 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l32HHbS5005370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Apr 2007 13:17:52 -0400 (EDT) Received: from play.cs.columbia.edu (localhost [127.0.0.1]) by play.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id l32HHbPd015384; Mon, 2 Apr 2007 13:17:37 -0400 (EDT) Received: from localhost (salman@localhost) by play.cs.columbia.edu (8.12.10/8.12.10/Submit) with ESMTP id l32HHWcG015381; Mon, 2 Apr 2007 13:17:32 -0400 (EDT) X-Authentication-Warning: play.cs.columbia.edu: salman owned process doing -bs Date: Mon, 2 Apr 2007 13:17:31 -0400 (EDT) From: Salman Abdul Baset To: anuroop.r@aricent.com Subject: Re: [P2PSIP] Comments on draft-baset-p2psip-p2pcommon-01 Attn: Baset/Schulzrinne In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Anuroop, Thanks for your comments. My responses inline: > Comments on the draft > ----------------------------- > > > i) On Peer-Lookup, it is stated that "A peer MAY send a Peer lookup message > to update its routing or neighbor table entries". > > From the above statement, i understand that a Peer P1 issues Peer-Lookup > message to another Peer P2. On receiving the Peer-Lookup response from P2, > P1 updates its routing/table based on the Peer-Lookup response. > Is the above understanding correct? > > There is also an Update message defined. "It states that A peer sends an > update request to another peer to request a copy of its neighbor or routing > table peers". > > What is the significance of this method?. Peer-Lookup method serves the > same purpose. > > Clear differentiation between Peer-Lookup and Update is not made. > Both Peer-Lookup and Update message is sent to obtain details > of a Peer's routing/neighbour table. Consider a DHT where a node may want to obtain routing table of its successor. This is accomplished using Update request. Peer-Lookup is not necessarily required in this scenario. In general, Update is used when the peer is already known. i.e., it does not need to be 'looked up'. > ii) The Update request and response [Page 29] parameters does not match with the > call flows provided. In the call flow [Page 69] Update request contains routing table > where as Update response does not contain routing table in contrast to the > description and parameters provided in Page 29. > > > So i guess, Update request is to indicate another Peer to update its routing table. > i.e., P1 send Update request to P2, so that P2 updates its routing table. > The description and parameters on page 29 has to be corrected. The reason there is no routing-table in Update response (message # 10) is because the join request had set request-routing-table and in-seperate-request flags in the Request-Options object. Nodes that receive a request with these flags set wait for a random period of time and then send a copy of their routing table to the node issuing the request. In the message flow, the in-seperate-flag is missing which I will add. Indeed, the Update message parameters should be updated. > > Enhancements required to the protocol > ------------------------------------- > > Considering an implementatin of Chord as DHT, there are not sufficient or efficient messages > to achive overlay management. For example, consider the case that P2 wants to join an overlay > and P1 is the only node currently in the overlay. (P1 is both bootstrap and admitting node > for P2). > > The sequence of actions are as follows (P2 joins P1 overlay). > > P2 sends join request to P1 ( to join the overlay). > P1 accepts and sends join resp to P2. > P2 has to update its routing table. For this it queries P1 and constructs its routing table. > P2 indicates other node that it has joined the overlay. > P2 has to share some of the resources of P1. > > One of the call flow scenario to achieve the same is that > > (a) Lets say P2 has to construct its finger table. While doing so P2 has to repeatedly send > P1 Peer-Lookup as it wants to know the successor of each key of its finger table. > The number of rows depends on the hash-key size bits used and hence lot of Peer-Lookup > messages has to be sent. This is where the Update message comes into play. P2 does not need to issue a per-row Peer-Lookup. Rather, it obtains a copy of neighbor and routing-table of P1 using Update. P2 then checks the neighbor-table and finds that P1's neighbor (successor) is P1 itself. Thus, P2 determines that there is no need to send a per-row Peer-Lookup since P1 has no successors. In Chord, a Peer-Lookup message finds a node which succeeds the ID specified in Peer-Lookup. If range [2^i, 2^(i+3)] does not contain any node, then rows i, i+1, i+2, i+3 can be filled with a node which was found when Peer-Lookup request was issued for ID i. In general, the use of some simple heuristics by the node attempting to fill its routing-table can greatly decrease the number of Peer-Lookup messages. > (b) As part of resource sharing, P2 wants to take some of the resources of P1. There is no > method directly to take some resources from P1 by P2. > Currently the Resource-Replicate is to be used. However in this case, resources shall > be replicated and will not be removed. A separated Remove request has to be sent. Agreed. A messasge should explicitly perform this function. Peer P1, however, may not immediately remove the resource-objects it is going to offload to P2. However, such a behavior is implementation specific. > A simple joining mechanism would result in lot of P2PP messages exchanged between joining > and bootstrap/admitting node. A join operation performs the following functions: 1) Locate the position in the overlay where a node will join. 2) Inform the neighbors that a new node is coming between them. 3) Obtain a copy of routing-tables from neighbor peers. 4) Take the responsibility for some resource-objects of its neighbors. It is not uncommon for nodes to exchange a lot of messages during join. Skype, for example, exchanges more than 20-30 messages with different nodes during join. This is not to say that we should be liberal in the number of messages exchanged but rather such an exchange is necessary for the functioning of a distributed system. > We are on the design of a prototype of P2PSIP overlay node based on the architecture > provided by draft-hautakorpi-structure-of-p2psip-node-00. If you are interested i can > send the call flows for overlay management. Might be when this protocol was written, the > intent of a method was different from what is being currently used in the draft. If so > this can be corrected, please let me can i share this call flow. > > > Another thing to be considered is whether to use TCP/UDP and iterative/recursive routing. > This draft fails to analyse the pros and cons of this. It used both TCP/UDP simulataneously > based on message size. This is not a good approach. The transport tradeoffs were highlighted in section 4.7 but they need to be further elaborated. You are right in pointing out that only message size should not dictate whether a request should be sent over TCP or UDP. Rather, it should depend on whether a node is using TCP or UDP for routing-table maintenance. If recursive routing is used and there is a TCP connection with the next hop, the request should be sent over it. Clearly, for iterative routing, establishing a per-hop TCP connection incurs a setup latency. This may be useful, if a node wants to update its routing-table from the lookup responses. > For e.g, lets say recursive routing is used in TCP, in this case, P1 sends message to P2, P2 > sends > to P3.. and so on... and the response would reach P1 after traversing P3, P2 etc. The > transction > would have timed out at P1, but still the message goes on with in the overlay until TTL is > zero. This is true. There is a tradeoff between maintaining additional timers for response processing or have a simple state machine which does not worry about late responses. I would argue on the side of simplicity but this is open to discussion. Regards, Salman > > We are almost done with the implementation of this protocol which we are planning to use for > our prototype of SIP overlay node. If interested i can share the source code too. > > > Thanks & Regards, > Anuroop. > > *****Aricent-Unclassified *****= > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of > the individual to whom it is addressed. It may contain privileged or confidential information and should not be > circulated or used for any purpose other than for what it is intended. If you have received this message in error, > please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for > loss or damage arising from the use of the information transmitted by this email including damage from virus." > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 14:16:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR4K-0001Vz-0Z; Mon, 02 Apr 2007 14:15:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR4J-0001R4-14 for p2psip@ietf.org; Mon, 02 Apr 2007 14:15:51 -0400 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYR4H-000397-Om for p2psip@ietf.org; Mon, 02 Apr 2007 14:15:51 -0400 Received: from mail2.magma.ca (mail2.internal.magma.ca [10.0.10.12]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l32IFLoj003700; Mon, 2 Apr 2007 14:15:21 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail2.magma.ca (Magma's Mail Server) with ESMTP id l32IFJSM024071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Apr 2007 14:15:21 -0400 In-Reply-To: <000201c7737b$33811e20$1905a40a@china.huawei.com> References: <000201c7737b$33811e20$1905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3FE64471-B2E2-47EE-A2EB-5B6090DEA82F@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 2 Apr 2007 14:15:47 -0400 To: JiangXingFeng X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: p2psip@ietf.org Subject: [P2PSIP] Re: Peer definition in Concept draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 31-Mar-07, at 05:58 , JiangXingFeng wrote: > I have noticed that there are minor differences between version 03 and > version 04. I list them as follows: > Version 3: > Each P2PSIP Peer may or may not (NOT) be coupled to one or more > P2PSIP User > Agents. > Version 4: > Each P2PSIP Peer may be coupled to one or more SIP entities. > > By comparing the difference, could we come to a conclusion that all > peers > should speak SIP in the version 04? No, that was not the intention. Perhaps the sentence should read: Each P2PSIP Peer may optionally be coupled to one or more SIP entities. Anyway, this is something that a peer may or may not do. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 14:36:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYROX-0000pP-Ea; Mon, 02 Apr 2007 14:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYROW-0000oP-47 for p2psip@ietf.org; Mon, 02 Apr 2007 14:36:44 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYROU-0002Ct-Po for p2psip@ietf.org; Mon, 02 Apr 2007 14:36:44 -0400 Received: from [171.70.229.153] (dhcp-171-70-229-153.cisco.com [171.70.229.153]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l32Hh41K022380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2007 12:43:05 -0500 In-Reply-To: <3FE64471-B2E2-47EE-A2EB-5B6090DEA82F@magma.ca> References: <000201c7737b$33811e20$1905a40a@china.huawei.com> <3FE64471-B2E2-47EE-A2EB-5B6090DEA82F@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <936DC6DB-77ED-4446-BABD-188142C68325@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Re: Peer definition in Concept draft Date: Mon, 2 Apr 2007 13:36:34 -0500 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 2, 2007, at 1:15 PM, Philip Matthews wrote: > > On 31-Mar-07, at 05:58 , JiangXingFeng wrote: >> I have noticed that there are minor differences between version 03 >> and >> version 04. I list them as follows: >> Version 3: >> Each P2PSIP Peer may or may not (NOT) be coupled to one or more >> P2PSIP User >> Agents. >> Version 4: >> Each P2PSIP Peer may be coupled to one or more SIP entities. >> >> By comparing the difference, could we come to a conclusion that >> all peers >> should speak SIP in the version 04? > > No, that was not the intention. > Perhaps the sentence should read: > > Each P2PSIP Peer may optionally be coupled to one or more SIP > entities. > > Anyway, this is something that a peer may or may not do. Another way to word this might be: "Each P2PSIP Peer is coupled to zero or more SIP entities". mathematics vs. english language conventions . . . we all lose. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 15:07:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRsV-0004sF-B5; Mon, 02 Apr 2007 15:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRsT-0004s3-DO; Mon, 02 Apr 2007 15:07:41 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYRsP-0001fq-LY; Mon, 02 Apr 2007 15:07:41 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Mon, 02 Apr 2007 12:07:27 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l32J7OSd005509; Mon, 2 Apr 2007 12:07:25 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l32J7KI9005252; Mon, 2 Apr 2007 12:07:20 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:07:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2007 12:07:09 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF29@namail5.corp.adobe.com> In-Reply-To: <00b201c7748e$33067df0$0601a8c0@BEMBUSTER> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd0jlEP0S2okoXWTMqTvEX9i1NkUwAyxCog References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <072C5B76F7CEAB488172C6F64B30B5E302C88E1B@xmb-rtp-20b.amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC5@namail5.corp.adobe.com> <4603929D.4070604@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC8@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com><7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com><460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> <00b201c7748e$33067df0$0601a8c0@BEMBUSTER> From: "Henry Sinnreich" To: "Jeroen van Bemmel" , "Paul Kyzivat" , "Eunsoo Shim" X-OriginalArrivalTime: 02 Apr 2007 19:07:19.0860 (UTC) FILETIME=[23084740:01C7755A] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jeroen, These are valid points. As David Bryan has mentioned, we would like to have P2P SIP in all = endpoints and in all devices. Mobile devices require however the client protocol and I hope we will = soon have a write-up to explain this. Na=EFve question: How do we distinguish here between deployment scenario = and usage scenario, unless we limit the usage scenario to the GUI = capability? Thanks, Henry -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl]=20 Sent: Sunday, April 01, 2007 1:47 PM To: Henry Sinnreich; Paul Kyzivat; Eunsoo Shim Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; = p2prg@ietf.org; sipping@ietf.org; zhuxian Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Henry, Aren't you confusing "usage scenarios" with "deployment scenarios" here? = Why=20 restrict P2P SIP to only certain types of devices? And if you insist on=20 that, why not mobile devices? Regards, Jeroen Henry Sinnreich wrote: > Paul, > >> I more or less agree with the final conclusion below. > > This is good starting point to discuss some usage scenarios. > > Putting on my former hat as an employee for a carrier, I cannot > overlook the following: > > P2P SIP implemented correctly in the residential access box or cable > set-top box indeed is a good or better replacement for the entire VoIP > network infrastructure (cost, operations, new services, etc). > Integrated access devices for the enterprise can probably play a > similar role, not to mention existing P2P PBX products (please refer > to all the advantages of P2P that need not repeated here). > > What do people think of these three usage scenarios for P2P SIP: > - SIP peer in the DSL access device, > - SIP peer in the cable access device, > - SIP peer in enterprise network integrated access device (IAD). > > Note that these examples imply very low churn for the peers and add > the data retention resilience of P2P (geographic diversity is native > and mobile, etc.). Incidentally, NAT traversal may also not be a > problem, or at least an easier problem. > > What do you all think? > > I have taken the liberty to copy the P2P SIP list, since the low churn > scenarios are of interest for the DHT selection. Or just pick the same > DHT for all scenarios anyway? I don't think so. > > Thanks, Henry > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, March 30, 2007 6:31 PM > To: Eunsoo Shim > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; > p2prg@ietf.org; sipping@ietf.org; zhuxian > Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > I more or less agree with the final conclusion below. > > My main point here is that P2P and C/S need not be enemies. Nor is a > total C/S system necessarily evil. What is most evil is *bundling* of > services that prevents freedom of choice. > > I think I would be quite happy with a SP that provides a > registrar/proxy > > and allows me to provide all other features as I see fit - by taking > them ala carte from the SP, or subscribing to them from one or more > other SPs, or by providing them myself via appliances I own. If that > registrar/proxy was replaced by a P2P sip community, the differences, > if > > any, would hopefully be more a function of the implementation and the > business models of those involved than the architecture. > > (I gather the general assumption is that a P2P setup will be *free*. > But > > I have a hard time believing that. If most of the usage is by mobile > devices that can't be peers, then somebody will have to pay for enough > peers to support them. If it isn't free, then how is it better than a > well engineered C/S system?) > > So I think the key thing here is that some features will require > getting > > some help from another node. There ought to be the option to pick a > different source for each helper you require, and an ability for it > all to play together. > > Paul > > Eunsoo Shim wrote: >> Please see my inline comment. >> >> On 3/30/07, *Paul Kyzivat* > > wrote: >> >> >> >> Henry Sinnreich wrote: >> > David Oran wrote (with regard to voice mail): >> > >> >> I'm not saying this can't be made to work, only that it isn't >> > immediately >obvious that it has advantages over a classic >> application >> > server >approach. >> > >> > The answer for VM is "it depends": >> > >> >> >> I agree. It really depends. Certainly there are tradeoffs. >> >> > There are several commercial P2P IP PBX solutions without any >> server for >> > VM or anything else. No doubt the IT organization appreciates >> just > having to plug in the IP phones and GWY to the PSTN >> without any > configuration ever for VM or any other PBX >> feature. >> >> I don't understand. Are you saying they don't have VM, or that >> they don't have a *server* for VM? >> >> >> I guess they don't have a *server* for VM. >> >> > For public P2P SIP networks there are two more scenarios >> where VM can > reside (and without ever spending one cent on VM >> servers + IT systems): >> > >> > - In Cable and DSL service provider networks: The residential >> router can >> > act as a voice recorder >> >> That is simply an example of the user having an appliance of his >> own that provides VM service. >> >> > and P2P can cover the not too frequent cases, >> > where the router is not in operation, so the data is backed >> up in other >> > peer residential gateways (encrypted). >> >> I guess I just need to have more info about how this would work >> before I will be convinced it is feasible and trustworthy. >> >> >> Well, 'trustworthy' could be considered in many angles. >> If it is about privacy of the message, a public key based encryption >> would provide acceptable privacy. >> If it is about reliability of the message delivery, well, a P2P based >> asynchronous message delivery (like VM) is most likely less reliable >> than a well managed server based system. >> However, my experience with Skype's asynchronous message delivery was >> not bad. Actually I don't see any significant difference between it >> and my cellular service provider's VM service. :-) >> Reliability is always a challenge for P2P, for sure. But, I believe >> it > >> is feasible to build a P2P system for VM acceptable for many >> scenarios. >> >> > - In mobile networks: The VM can reside in quite stable peers >> inside the >> > wireless base station network. The peers in the base station >> network > need no configuration, etc. >> >> I don't understand. I guess that could be true if the peers are >> willing to store an arbitrary amount of VM indefinitely for >> anybody. Is that believable? >> >> >> It depends. >> In a very nice environment where all the peers are willing to >> cooperate at their best, the peers will store as much as they can. >> In a tough environment, the situation will be different. >> >> This seems to translate to a model where it is assumed that >> those nodes that are on most of the time will be willing to >> provide VM storage for those nodes that aren't on most of the >> time. >> >> >> This is again related to reliability of P2P systems or topics like >> free riders and reputation. >> A P2P system is a community or society. To be simple, if many of the >> members are bad, the community won't work well. If the majority of >> the > >> members are good, the community will work well or reasonably. >> >> > Add to this the conferencing capability coming from p2p >> application > layer multicast, the SIP e2e control capabilities >> (for such as > auto-attendant, agent workstation, etc.) and one >> has to wonder why IT > networks, public VoIP networks and end >> users should support the huge > cost of hand engineering, >> testing, monitoring, maintaining server based >> > VoIP networks. P2P self configuration is nothing less that >> automation > applied to VoIP, plus the shifting of computing to >> the endpoints, where >> > there is an abundance of unused CPU, storage, bandwidth and >> electricity. >> > >> > Eric Burger also notes IM changes completely the usage for VM >> and may > make unnecessary to place calls on VM in the first >> place. >> >> I find this more promising. >> >> >> >> >> In overall, are we discussing if P2P systems based VM can work? I >> think it can work. Just it depends on many things. >> If it is not super-reliable, should we disregard it? I would say no. >> >> On the other hand, do we have to abandon client server based VM and >> switch to P2P system based VM? It is upto each of us. >> Client server based VM systems are already there. >> So why don't we work on P2P based VM now? >> >> Thanks. >> >> Eunsoo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 15:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSdG-00016D-QS; Mon, 02 Apr 2007 15:56:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSd7-0000wA-6X for p2psip@ietf.org; Mon, 02 Apr 2007 15:55:53 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYScW-0001vj-AT for p2psip@ietf.org; Mon, 02 Apr 2007 15:55:53 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l32Jsw0r002657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 2 Apr 2007 15:54:59 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Comments on draft-baset-p2psip-p2pcommon-01 Attn: Baset/Schulzrinne Date: Mon, 2 Apr 2007 15:55:42 -0400 To: Salman Abdul Baset X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > >> For e.g, lets say recursive routing is used in TCP, in this >> case, P1 sends message to P2, P2 >> sends >> to P3.. and so on... and the response would reach P1 after >> traversing P3, P2 etc. The >> transction >> would have timed out at P1, but still the message goes on with >> in the overlay until TTL is >> zero. > > This is true. There is a tradeoff between maintaining additional > timers > for response processing or have a simple state machine which does not > worry about late responses. I would argue on the side of simplicity > but > this is open to discussion. > For TCP, the timer is not really critical and serves a different function than in UDP. After all, transmission is (hop-by-hop) reliable, so you only have to deal with the somewhat less likely case of a node crashing just after it has received a message. Thus, the transaction timeout can be fairly long, and mainly prevents infinite waiting for a response that is unlikely to ever arrive. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 19:11:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVgX-0003Ku-H6; Mon, 02 Apr 2007 19:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVgU-0003Jo-E8; Mon, 02 Apr 2007 19:11:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYVgS-00032p-VB; Mon, 02 Apr 2007 19:11:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 19:11:33 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32NBWuQ022823; Mon, 2 Apr 2007 19:11:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l32NBSlI023686; Mon, 2 Apr 2007 23:11:32 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 19:11:28 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 19:11:28 -0400 Message-ID: <46118DA0.4070305@cisco.com> Date: Mon, 02 Apr 2007 19:11:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Henry Sinnreich References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <072C5B76F7CEAB488172C6F64B30B5E302C88E1B@xmb-rtp-20b.amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC5@namail5.corp.adobe.com> <4603929D.4070604@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADEC8@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Apr 2007 23:11:28.0358 (UTC) FILETIME=[3E37B060:01C7757C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8846; t=1175555492; x=1176419492; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2Prg]=20RE=3A=20[Sipping]=20Simple=20SIP=20usage=20 scenario |Sender:=20 |To:=20Henry=20Sinnreich=20; bh=nVRJsxrHKZvG+PMOZg7zoRES1kia/kZgTm8JH806kzo=; b=SdNIWWdklsVdEvCKtrYgm7JiCEZ/JGKRBiKuAc4qq/8edCckWYJeo7oamaP5BuSjKkXl8KRk /I0hVhIovnX4xTO0Qt2zKOd5hgDZFtwomCrtBUTaV5o1ztaBn0w7upgD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry Sinnreich wrote: > Paul, > >> I more or less agree with the final conclusion below. > > This is good starting point to discuss some usage scenarios. > > Putting on my former hat as an employee for a carrier, I cannot overlook > the following: > > P2P SIP implemented correctly in the residential access box or cable > set-top box indeed is a good or better replacement for the entire VoIP > network infrastructure (cost, operations, new services, etc). > Integrated access devices for the enterprise can probably play a similar > role, not to mention existing P2P PBX products (please refer to all the > advantages of P2P that need not repeated here). > > What do people think of these three usage scenarios for P2P SIP: > - SIP peer in the DSL access device, > - SIP peer in the cable access device, These seem quite reasonable, assuming that a device connected at this point is able to function properly as a peer. (I haven't been following what the assumptions are about required network capabilities of peers.) > - SIP peer in enterprise network integrated access device (IAD). I think this depends greatly on what expectations / contractual guarantees the enterprise has. Its unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees. Paul > Note that these examples imply very low churn for the peers and add the > data retention resilience of P2P (geographic diversity is native and > mobile, etc.). Incidentally, NAT traversal may also not be a problem, or > at least an easier problem. > > What do you all think? > > I have taken the liberty to copy the P2P SIP list, since the low churn > scenarios are of interest for the DHT selection. Or just pick the same > DHT for all scenarios anyway? I don't think so. > > Thanks, Henry > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, March 30, 2007 6:31 PM > To: Eunsoo Shim > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; > p2prg@ietf.org; sipping@ietf.org; zhuxian > Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > I more or less agree with the final conclusion below. > > My main point here is that P2P and C/S need not be enemies. Nor is a > total C/S system necessarily evil. What is most evil is *bundling* of > services that prevents freedom of choice. > > I think I would be quite happy with a SP that provides a registrar/proxy > > and allows me to provide all other features as I see fit - by taking > them ala carte from the SP, or subscribing to them from one or more > other SPs, or by providing them myself via appliances I own. If that > registrar/proxy was replaced by a P2P sip community, the differences, if > > any, would hopefully be more a function of the implementation and the > business models of those involved than the architecture. > > (I gather the general assumption is that a P2P setup will be *free*. But > > I have a hard time believing that. If most of the usage is by mobile > devices that can't be peers, then somebody will have to pay for enough > peers to support them. If it isn't free, then how is it better than a > well engineered C/S system?) > > So I think the key thing here is that some features will require getting > > some help from another node. There ought to be the option to pick a > different source for each helper you require, and an ability for it all > to play together. > > Paul > > Eunsoo Shim wrote: >> Please see my inline comment. >> >> On 3/30/07, *Paul Kyzivat* > > wrote: >> >> >> >> Henry Sinnreich wrote: >> > David Oran wrote (with regard to voice mail): >> > >> >> I'm not saying this can't be made to work, only that it isn't >> > immediately >obvious that it has advantages over a classic >> application >> > server >approach. >> > >> > The answer for VM is "it depends": >> > >> >> >> I agree. It really depends. Certainly there are tradeoffs. >> >> > There are several commercial P2P IP PBX solutions without any >> server for >> > VM or anything else. No doubt the IT organization appreciates > just >> > having to plug in the IP phones and GWY to the PSTN without any >> > configuration ever for VM or any other PBX feature. >> >> I don't understand. Are you saying they don't have VM, or that > they >> don't have a *server* for VM? >> >> >> I guess they don't have a *server* for VM. >> >> > For public P2P SIP networks there are two more scenarios where > VM can >> > reside (and without ever spending one cent on VM servers + IT >> systems): >> > >> > - In Cable and DSL service provider networks: The residential >> router can >> > act as a voice recorder >> >> That is simply an example of the user having an appliance of his > own >> that provides VM service. >> >> > and P2P can cover the not too frequent cases, >> > where the router is not in operation, so the data is backed up > in >> other >> > peer residential gateways (encrypted). >> >> I guess I just need to have more info about how this would work > before I >> will be convinced it is feasible and trustworthy. >> >> >> Well, 'trustworthy' could be considered in many angles. >> If it is about privacy of the message, a public key based encryption >> would provide acceptable privacy. >> If it is about reliability of the message delivery, well, a P2P based >> asynchronous message delivery (like VM) is most likely less reliable >> than a well managed server based system. >> However, my experience with Skype's asynchronous message delivery was >> not bad. Actually I don't see any significant difference between it > and >> my cellular service provider's VM service. :-) >> Reliability is always a challenge for P2P, for sure. But, I believe it > >> is feasible to build a P2P system for VM acceptable for many > scenarios. >> > - In mobile networks: The VM can reside in quite stable peers >> inside the >> > wireless base station network. The peers in the base station > network >> > need no configuration, etc. >> >> I don't understand. I guess that could be true if the peers are > willing >> to store an arbitrary amount of VM indefinitely for anybody. Is > that >> believable? >> >> >> It depends. >> In a very nice environment where all the peers are willing to > cooperate >> at their best, the peers will store as much as they can. In a tough >> environment, the situation will be different. >> >> This seems to translate to a model where it is assumed that those > nodes >> that are on most of the time will be willing to provide VM storage > for >> those nodes that aren't on most of the time. >> >> >> This is again related to reliability of P2P systems or topics like > free >> riders and reputation. >> A P2P system is a community or society. To be simple, if many of the >> members are bad, the community won't work well. If the majority of the > >> members are good, the community will work well or reasonably. >> >> > Add to this the conferencing capability coming from p2p > application >> > layer multicast, the SIP e2e control capabilities (for such as >> > auto-attendant, agent workstation, etc.) and one has to wonder > why IT >> > networks, public VoIP networks and end users should support the > huge >> > cost of hand engineering, testing, monitoring, maintaining > server >> based >> > VoIP networks. P2P self configuration is nothing less that > automation >> > applied to VoIP, plus the shifting of computing to the > endpoints, >> where >> > there is an abundance of unused CPU, storage, bandwidth and >> electricity. >> > >> > Eric Burger also notes IM changes completely the usage for VM > and may >> > make unnecessary to place calls on VM in the first place. >> >> I find this more promising. >> >> >> >> >> In overall, are we discussing if P2P systems based VM can work? I > think >> it can work. Just it depends on many things. >> If it is not super-reliable, should we disregard it? I would say no. >> >> On the other hand, do we have to abandon client server based VM and >> switch to P2P system based VM? It is upto each of us. >> Client server based VM systems are already there. >> So why don't we work on P2P based VM now? >> >> Thanks. >> >> Eunsoo > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 02 21:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXaN-0001TY-5Q; Mon, 02 Apr 2007 21:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXaL-0001TK-Q6 for p2psip@ietf.org; Mon, 02 Apr 2007 21:13:21 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXaJ-000057-RL for p2psip@ietf.org; Mon, 02 Apr 2007 21:13:21 -0400 Received: by ug-out-1314.google.com with SMTP id 72so113590ugd for ; Mon, 02 Apr 2007 18:13:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=IiOmAag5dY8mR6qM+R3QwXtRxcm9MN4Ptg0u1n9+53VouLlgTq2GUoELfc9rPhsK48XH4WhJ3p8GGV5UzykMETWJN/ekYngYRzBOENIFXalrqEgV5bao7sx537FWNLRTGgguwdO2v5PWer7dF1bMrQE8vrO3poIKfyi+hDRAg+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=f+smpEQdonjOCN6P9DXbwwaASeS3u4oR5y8suMj10pTDzFkIs5VU+0ufSpy9J6idxqJvE+2rT0ayNIwGUCf65TX9YEbkbtnpc7ij405/4pEpOTKya5Az8R/yyWVYQPYJ3tG1ZK17iL5ZnaQHIu1pMDjqcmxN84xxddmgT3Ut6ds= Received: by 10.78.83.15 with SMTP id g15mr1574802hub.1175562798363; Mon, 02 Apr 2007 18:13:18 -0700 (PDT) Received: by 10.78.144.6 with HTTP; Mon, 2 Apr 2007 18:13:18 -0700 (PDT) Message-ID: <1fc32c8f0704021813h4387c0c4uec60e7aa3f75606c@mail.gmail.com> Date: Mon, 2 Apr 2007 21:13:18 -0400 From: "Michael Slavitch" To: "Paul Kyzivat" , "Henry Sinnreich" In-Reply-To: <46118DA0.4070305@cisco.com> MIME-Version: 1.0 References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> <46118DA0.4070305@cisco.com> X-Google-Sender-Auth: d02fe10449386c3e X-Spam-Score: 0.3 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1864220531==" Errors-To: p2psip-bounces@ietf.org --===============1864220531== Content-Type: multipart/alternative; boundary="----=_Part_283_16317225.1175562798221" ------=_Part_283_16317225.1175562798221 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry for being late into this discussion, but client-server based VM isn't truly client-server anymore in anything but the smallest or most monolithic of enterprise networks, in fact the reality is that most if not all enterprise networks contain just peers and superpeers with the difference being partially a marketing decision by the vendors, as you can charge much more for the servers, and a policy decision made either automatically by a software deployment system or by IT staff which wants to place supernodes with data sinks on appropriate equipment. In a highly distributed environment there are potentially hundreds of possible data sinks for a given application, with the sink based on subnet or geographic location or balanced load, this can change rapidly over time and does. In the case of the Microsoft environment such policy is administered and published between supernodes, ie servers, by Active Directory. It is advertised to mere peers through DNS. There was much discussion a while ago about building service discovery environment using DNS instead of a P2P DHT. It can be argued that a case study of a P2P example done using DNS is any large Windows Server 2003 based Microsoft network with many servers and many more clients that also run applications themselves and are not just dumb terminals. This is almost certainly always the case in all enterprises. The big difference between C/S SIP and P2PSIP is automation. What is true is that the square peg in round hole of overloading DNS makes deployments clumsy and brittle within the enterprise domain and completely unmanageable and unpublishable outside the firewall which is why the buck stops there in current enterprise networking products. The difference between C/S and P2P is largely policy and semantics with the biggest difference being that the decisions and rules are highly distributed. Apart from that they are not just friends, they are fraternal twins. Regards Michael Slavitch [image: corp_2colour] 308 Legget Dr. Ottawa Ontario K2K 1Y6 Canada Michael Slavitch Lead, Technology Initiatives slavitch@objectworld.com PSTN: +1.888.398.9698 x225 Fax: +1.613.599.7457 Skype: Objectworld x225 ------=_Part_283_16317225.1175562798221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry for being late into this discussion, but client-server based VM isn't truly client-server anymore in anything but the smallest or most monolithic of enterprise networks, in fact the reality is that most if not all enterprise networks contain just peers and superpeers with the difference being partially a marketing decision by the vendors, as you can charge much more for the servers, and a policy decision made either automatically by a software deployment system or by IT staff which wants to place supernodes with data sinks on appropriate equipment. In a highly distributed environment there are potentially hundreds of possible data sinks for a given application, with the sink based on subnet or geographic location or balanced load, this can change rapidly over time and does.

In the case of the Microsoft environment such policy is administered and published between supernodes, ie servers, by Active Directory.  It is advertised to mere peers through DNS.  There was much discussion a while ago about building service discovery environment using DNS instead of a P2P DHT.  It can be argued that a case study of a P2P example done using DNS is any large Windows Server 2003 based Microsoft network with many servers and many more clients that also run applications themselves and are not just dumb terminals. This is almost certainly always the case in all enterprises. The big difference between C/S SIP and P2PSIP is automation. What is true is that the square peg in round hole of overloading DNS makes deployments clumsy and brittle within the enterprise domain and completely unmanageable and unpublishable outside the firewall which is why the buck stops there in current enterprise networking products.

The difference between C/S and P2P is largely policy and semantics with the biggest difference being that the decisions and rules are highly distributed.  Apart from that they are not just friends, they are fraternal twins.

Regards

Michael Slavitch

 

corp_2colour

 

308 Legget Dr.
Ottawa Ontario
K2K 1Y6 Canada

 

Michael Slavitch             

Lead, Technology Initiatives

slavitch@objectworld.com

PSTN: 

+1.888.398.9698

x225

Fax:

+1.613.599.7457

 

Skype:      

  Objectworld  

x225

 

 


------=_Part_283_16317225.1175562798221-- --===============1864220531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1864220531==-- From p2psip-bounces@ietf.org Mon Apr 02 22:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYZJ-00039i-Tq; Mon, 02 Apr 2007 22:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYZI-00039d-QC for p2psip@ietf.org; Mon, 02 Apr 2007 22:16:20 -0400 Received: from mu-out-0910.google.com ([209.85.134.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYZH-00045D-Gz for p2psip@ietf.org; Mon, 02 Apr 2007 22:16:20 -0400 Received: by mu-out-0910.google.com with SMTP id g7so1644128muf for ; Mon, 02 Apr 2007 19:16:18 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mvlJ2OEvWlkP5BjwEOze0rzDqfKaKYWtyMKizkRSizjit+Zxxl5cT0NvAz3Py49lhda7JjBNOnt6tyf/YNa4Q3qCWovdxwAcZ9OXhwSv7du8NcgCIWIfZ3woAUPT9fSKl7YRStSJdd+5nGR7pWxPOJlyGO/0HKOywMAlJNF1dUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=q3YK6YdKuvSW/aDh8P25/oWZsv+SN5ZXSVcNg8egcB7qIIOWUAyHpoH2hlVzrfnUes55BBeUYWnQ5Z1bHdKFIvFk8H82MB86bVgyW7EZ1aGYITFNzyOdzwLq4X3Pg5aUOyeZQlP9/HXXM6f8pY411JUX52WdTUrwlkXkzOwEcmA= Received: by 10.82.134.12 with SMTP id h12mr8904567bud.1175566578038; Mon, 02 Apr 2007 19:16:18 -0700 (PDT) Received: by 10.82.127.17 with HTTP; Mon, 2 Apr 2007 19:16:17 -0700 (PDT) Message-ID: <4d4304a00704021916t3c094318if2d852f07f0005f6@mail.gmail.com> Date: Mon, 2 Apr 2007 22:16:17 -0400 From: "David A. Bryan" To: "Eric Cooper" Subject: Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario In-Reply-To: <0be101c7754a$c424bc40$65500a0a@ronin> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> <00b201c7748e$33067df0$0601a8c0@BEMBUSTER> <4d4304a00704020632r71315532s1be1df106c4f426a@mail.gmail.com> <0be101c7754a$c424bc40$65500a0a@ronin> X-Google-Sender-Auth: 849af22e902f3999 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , Henry Sinnreich , Jeroen van Bemmel , p2prg@ietf.org, sipping@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Actually, already being done... Good point. ;) On 4/2/07, Eric Cooper wrote: > > Personally, I think that putting P2PSIP peers in edge devices would be > > a good place to do it for home wireline users -- as Henry points out, > > it avoids the NAT issue, among other things. > > Until some ISP NATs their networks. > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 04:07:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYe30-0006cz-AK; Tue, 03 Apr 2007 04:07:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYe2z-0006bX-3e for p2psip@ietf.org; Tue, 03 Apr 2007 04:07:21 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYe2x-0001Ik-KO for p2psip@ietf.org; Tue, 03 Apr 2007 04:07:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3386qus019661; Tue, 3 Apr 2007 11:07:15 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:07:13 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:07:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Consensus calls Date: Tue, 3 Apr 2007 11:07:29 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F040686ED@esebe102.NOE.Nokia.com> In-Reply-To: <460D1429.2090602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Consensus calls thread-index: Acdy0dMsGChBTNDqTKCVpCd40/JvXAC7ZCbw References: <4d4304a00703281250o750a5b8ah3a373458382d59fd@mail.gmail.com> <054a01c771ec$0030d7d0$6401a8c0@china.huawei.com><4d4304a00703290614r31a00db1x56c6acb5fdba2116@mail.gmail.com> <460D1429.2090602@cisco.com> From: To: , X-OriginalArrivalTime: 03 Apr 2007 08:07:13.0420 (UTC) FILETIME=[162AE4C0:01C775C7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Jonathan, I agree with the WG decision, at least for now. Every DHT algorithm has different properties, one requires less bandwith but does not work well in the case of high churn, another is resilient to frequent changes in network topology but is slow in lookups. DHTs are like codecs, there can be many available, each one suitable for a different deployment scenario. Besides, research on DHT algorithms is still ongoing. We may see better DHTs available in the future. I do not know what happened with the use cases for P2PSIP draft. I think we need to continue discussion on the use cases. At the same time we should analyze different DHT algorithms and see if we can choose one algorithm or if we need many. =20 I am actually not convinced that DHT is the best choice. Marcin =20 =20 >Jonathan Rosenberg wrote: > >In any case I agree with all three hums, but would prefer one=20 >DHT to be mandatory to implement, not more than one. > >-Jonathan R. >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 07:28:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhBm-0003Vy-0s; Tue, 03 Apr 2007 07:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhBk-0003Ve-0M for p2psip@ietf.org; Tue, 03 Apr 2007 07:28:36 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYhBf-00073u-OW for p2psip@ietf.org; Tue, 03 Apr 2007 07:28:35 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1691858wri for ; Tue, 03 Apr 2007 04:28:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DrHBRelkAxWGJRyvogTGcduaOiiqyvLPifvlik2PRwmVcfvF6a07S2bSGAolChddSFkuGXCR+hZKFHNQzSIhQ8luBqihOEG4MMGDO0JgPFkMz9PNyIauBTs/nZrF3S1Qz1yDRS7IR8NLeATVD3iItFezUJrrlpRs+z55JsRJkIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hqaM4euXXnsiO8gmmgB1GTEZuC5mpgDBWEQNxXUFBgTjdZlGpDQS5BJzp+f9p+Gk7JaNWiPBJGPzCAQ7EwR+Yw4DTi5fIbAfm6eeV7j2qR0S6v+mmtHzMnhhw/EB6skVIe+X/j6BEH4nY8G1OYgD6I68GpphaXA3kxdGTWED9NU= Received: by 10.114.182.1 with SMTP id e1mr2208202waf.1175599710893; Tue, 03 Apr 2007 04:28:30 -0700 (PDT) Received: by 10.114.197.10 with HTTP; Tue, 3 Apr 2007 04:28:30 -0700 (PDT) Message-ID: <9dc4a1670704030428g281eca20qa9851330c27a88de@mail.gmail.com> Date: Tue, 3 Apr 2007 07:28:30 -0400 From: EdPimentl To: "marcin.matuszewski@nokia.com" Subject: Re: [P2PSIP] Consensus calls In-Reply-To: <3F18E76823C95E4795181D74BAC7664F040686ED@esebe102.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00703281250o750a5b8ah3a373458382d59fd@mail.gmail.com> <054a01c771ec$0030d7d0$6401a8c0@china.huawei.com> <4d4304a00703290614r31a00db1x56c6acb5fdba2116@mail.gmail.com> <460D1429.2090602@cisco.com> <3F18E76823C95E4795181D74BAC7664F040686ED@esebe102.NOE.Nokia.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jonathan, With enough time and resources we can always find or develop a better solution. The objective at this time is to draw a line in the sand and avoid the analysis paralysis that we often see in TelCO projects that is like mating elephants and takes two years to produce results. While we speaking about endpoints, and the future. I am sure many of us would like the endpoints to be H.325 and P2P while at the same time being a WebServices(REST) node with generic binding to ip communications. For now I would happy with a concensus on what DHT to start with, what generic signaling to use on the wire, basic subset for joining the overlay, managing churn and basic sip and p2p interoperability/internetworking scenerios... This would allow us within the opensource project to get to work, while we monitor the progress of the WG and plan for whatever direction is taken/given by its members. my .02 cents O Thanks in advance and best regards, Ed Pimentel AgileCO Founder Mail: edpimentl[at]gmail.com IM: edpimentl [AOL | Jabber | Yahoo | MSN ] Voip: edpimentl [SKype | GoogleTalk ] Mobile Content Marketing/Management/Digital Delivery http://mobilecentral.ws Mobile ( Relevant, Ambient, Location ) based Social Network http://TagR.mobi (Alpha) Mobile Payment - P2P Payment http://agilepay.ws Sponsor of P2PSIP open source [viasip_ng] project Creating a standards base P2PSIP dSIP infrastructure https://sourceforge.net/projects/viasip/ Mailing List viasip_ng@freelists.org _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 07:57:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhdf-0006bX-GC; Tue, 03 Apr 2007 07:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhde-0006bH-6s for p2psip@ietf.org; Tue, 03 Apr 2007 07:57:26 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYhdc-0004n3-31 for p2psip@ietf.org; Tue, 03 Apr 2007 07:57:26 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFX00G9U7UAQ4@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 03 Apr 2007 19:56:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JFX00I9N7UAI2@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 03 Apr 2007 19:56:34 +0800 (CST) Received: from j36340 ([10.164.5.25]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFX003BV7U205@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 03 Apr 2007 19:56:34 +0800 (CST) Date: Tue, 03 Apr 2007 19:56:26 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Re: Peer definition in Concept draft In-reply-to: <936DC6DB-77ED-4446-BABD-188142C68325@softarmor.com> To: 'Dean Willis' , 'Philip Matthews' Message-id: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd1VdwtmX6Yaa2OSCqKwLPIGTQnRgAjThVw X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Dean and Philip: >From your responses, I learned that P2PSIP peer may be not coupled to any SIP entity. It also says that some P2PSIP peers will not recognize SIP message. Is my understanding right? If it is, I have some comments on the concept draft which are listed as follows: 1. In section 3, all peers in the reference model are coupled to SIP entities except gateway Peer. In my opinion, gateway peers also have SIP processing functionality because they should do translation between SIP signaling and PSTN signaling. Does the reference model imply that all peers have to speak SIP? If it is not the case, do we need add some peers which don't speak SIP? Comments? 2. In the second option of using distributed database in section 5.2, if Peer Z could not parse SIP message, how does the Peer Z proxy the INVITE message? If I don't make mistake, Peer Z at least rewrite the Request-URI of the message, so it have to be able to recognize and parse the SIP message. There are similar problems in option 3 and 4. Comments? 3. In the section 5.5, some possible client behaviors are proposed. In terms of third alternative, namely "a peer with bad memory", clients participate in DHT algorithms and do not store any resource record. Here, I have a question. For example, there is a chord overlay and there are a peer keyed 20, and a client keyed 19. If a resource keyed 18 want to be stored into the overlay, a peer keyed 20 is responsible for key 18 according to the third alternative. But if a normal chord algorithm is used, the client node keyed 19 should be the answer. IMHO, I think this alternative will break the underlying DHT algorithm. Comments? These are my individual ideas. If I miss something, please enlighten me! What I really hope is to make the P2PSIP WG work further and reach consensus as soon as possible? Regards! -- Jiang XingFeng > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, April 03, 2007 2:37 AM > To: Philip Matthews > Cc: JiangXingFeng; p2psip@ietf.org > Subject: Re: [P2PSIP] Re: Peer definition in Concept draft > > > On Apr 2, 2007, at 1:15 PM, Philip Matthews wrote: > > > > > On 31-Mar-07, at 05:58 , JiangXingFeng wrote: > >> I have noticed that there are minor differences between version 03 > >> and > >> version 04. I list them as follows: > >> Version 3: > >> Each P2PSIP Peer may or may not (NOT) be coupled to one or more > >> P2PSIP User > >> Agents. > >> Version 4: > >> Each P2PSIP Peer may be coupled to one or more SIP entities. > >> > >> By comparing the difference, could we come to a conclusion that > >> all peers > >> should speak SIP in the version 04? > > > > No, that was not the intention. > > Perhaps the sentence should read: > > > > Each P2PSIP Peer may optionally be coupled to one or more SIP > > entities. > > > > Anyway, this is something that a peer may or may not do. > > Another way to word this might be: > > "Each P2PSIP Peer is coupled to zero or more SIP entities". > > mathematics vs. english language conventions . . . we all lose. > > -- > Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 08:57:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiZq-0002eO-UH; Tue, 03 Apr 2007 08:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiZo-0002dQ-Up; Tue, 03 Apr 2007 08:57:32 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYiZm-0000UI-IR; Tue, 03 Apr 2007 08:57:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2007 08:57:31 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l33CvUH8028899; Tue, 3 Apr 2007 08:57:30 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l33CvUlG017038; Tue, 3 Apr 2007 12:57:30 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:57:30 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 08:57:29 -0400 Message-ID: <46124F38.7020005@cisco.com> Date: Tue, 03 Apr 2007 08:57:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Michael Slavitch References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> <46118DA0.4070305@cisco.com> <1fc32c8f0704021813h4387c0c4uec60e7aa3f75606c@mail.gmail.com> In-Reply-To: <1fc32c8f0704021813h4387c0c4uec60e7aa3f75606c@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2007 12:57:29.0766 (UTC) FILETIME=[A31E6460:01C775EF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3600; t=1175605050; x=1176469050; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2Prg]=20RE=3A=20[Sipping]=20Simple=20SIP=20usage=20 scenario |Sender:=20 |To:=20Michael=20Slavitch=20; bh=pD3W8Ltw24iJlP61MuCtDTPRtqK5p683XEhdmeXTmT0=; b=tMCV89EYFmht94ElXG06HwhR/pwwO2WT/h9l4SDB8L77KlJ4qsIJGTGEpYdbxVmQjkouZ8RA 8MDpE1iatCTW1hDeyZwM5NZ5aZQMQEKEWBJmqlRQ4+d+BfjW86Fitqf7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , Henry Sinnreich , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Michael Slavitch wrote: > Sorry for being late into this discussion, but client-server based VM > isn't truly client-server anymore in anything but the smallest or most > monolithic of enterprise networks, in fact the reality is that most if > not all enterprise networks contain just peers and superpeers with the > difference being partially a marketing decision by the vendors, as you > can charge much more for the servers, and a policy decision made either > automatically by a software deployment system or by IT staff which wants > to place supernodes with data sinks on appropriate equipment. I'm sorry, but I don't understand the point you are trying to make above. You are trying to draw some sort of distinction, but I don't get it. Can you try again. Thanks, Paul > In a > highly distributed environment there are potentially hundreds of > possible data sinks for a given application, with the sink based on > subnet or geographic location or balanced load, this can change rapidly > over time and does. > > In the case of the Microsoft environment such policy is administered and > published between supernodes, ie servers, by Active Directory. It is > advertised to mere peers through DNS. There was much discussion a while > ago about building service discovery environment using DNS instead of a > P2P DHT. It can be argued that a case study of a P2P example done using > DNS is any large Windows Server 2003 based Microsoft network with many > servers and many more clients that also run applications themselves and > are not just dumb terminals. This is almost certainly always the case in > all enterprises. The big difference between C/S SIP and P2PSIP is > automation. What is true is that the square peg in round hole of > overloading DNS makes deployments clumsy and brittle within the > enterprise domain and completely unmanageable and unpublishable outside > the firewall which is why the buck stops there in current enterprise > networking products. > > The difference between C/S and P2P is largely policy and semantics with > the biggest difference being that the decisions and rules are highly > distributed. Apart from that they are not just friends, they are > fraternal twins. > > Regards > > Michael Slavitch > > > > > corp_2colour > > > > > > > 308 Legget Dr. > Ottawa Ontario > K2K 1Y6 Canada > > > > > > > > > > Michael Slavitch > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > PSTN: > > > > +1.888.398.9698 > > > > x225 > > Fax: > > > > +1.613.599.7457 > > > > > > Skype: > > > > Objectworld > > > > > > x225 > > > > > > > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 09:17:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYisg-0000C5-3r; Tue, 03 Apr 2007 09:17:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYise-00006Y-Ph for p2psip@ietf.org; Tue, 03 Apr 2007 09:17:00 -0400 Received: from mx5-4.spamtrap.magma.ca ([209.217.78.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYikM-0002P9-VW for p2psip@ietf.org; Tue, 03 Apr 2007 09:08:29 -0400 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx5-4.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l33D87J3018371; Tue, 3 Apr 2007 09:08:07 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l33D86KF004209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Apr 2007 09:08:07 -0400 In-Reply-To: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B0D63EF-0C0E-47AC-833D-74E3B4905E29@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: Peer definition in Concept draft Date: Tue, 3 Apr 2007 09:08:36 -0400 To: JiangXingFeng X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org See in-line. - Philip On 3-Apr-07, at 07:56 , JiangXingFeng wrote: > Hi, Dean and Philip: > > From your responses, I learned that P2PSIP peer may be not coupled > to any > SIP entity. It also says that some P2PSIP peers will not recognize SIP > message. Is my understanding right? If it is, I have some comments > on the > concept draft which are listed as follows: > 1. In section 3, all peers in the reference model are coupled to SIP > entities except gateway Peer. In my opinion, gateway peers also > have SIP > processing functionality because they should do translation between > SIP > signaling and PSTN signaling. Does the reference model imply that > all peers > have to speak SIP? If it is not the case, do we need add some peers > which > don't speak SIP? > > Comments? We could do that. However, I think we need to decide on the rough format for the Peer Protocol first. If the Peer Protocol uses SIP, either entirely like the dSIP proposal, or partly like draft-matthews-p2psip-bootstrap-mechanisms-00 or draft-hautakorpi-p2psip-peer-protocol-00 then it might be reasonable to assume that all peers speak SIP. However, if the Peer Protocol is completely independent of SIP, then it is reasonable to assume that there are peers that do not speak SIP. This plays a bit into the question of what we are trying to do in P2PSIP. Are we working on a system which is independent of SIP, or does the fact that we are the "P2PSIP" group imply that we assume all peers support SIP? > > 2. In the second option of using distributed database in section > 5.2, if > Peer Z could not parse SIP message, how does the Peer Z proxy the > INVITE > message? If I don't make mistake, Peer Z at least rewrite the > Request-URI of > the message, so it have to be able to recognize and parse the SIP > message. > > There are similar problems in option 3 and 4. > > Comments? Why would peer Z be unable to parse the SIP message? > > 3. In the section 5.5, some possible client behaviors are proposed. > In terms > of third alternative, namely "a peer with bad memory", clients > participate > in DHT algorithms and do not store any resource record. Here, I have a > question. For example, there is a chord overlay and there are a > peer keyed > 20, and a client keyed 19. If a resource keyed 18 want to be stored > into the > overlay, a peer keyed 20 is responsible for key 18 according to the > third > alternative. But if a normal chord algorithm is used, the client > node keyed > 19 should be the answer. IMHO, I think this alternative will break the > underlying DHT algorithm. Comments? Clearly, the DHT algorithm would have to be designed so that clients are not expected to store data. One way this might work was described by Eric Rescorla as follows: 1. Clients understand the overlay network, they just don't store data. To take a concrete example from Chord, there's no reason you can't connect to a Chord node, suck down an appropriate finger/routing table and then send messages to other Chord nodes just as if you were a Peer. The only thing you don't do is *register* with the network. Other ways are probably possible. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 10:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkJT-0005RN-3t; Tue, 03 Apr 2007 10:48:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkJQ-0005R9-EW; Tue, 03 Apr 2007 10:48:44 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYkJA-00030Z-E4; Tue, 03 Apr 2007 10:48:44 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l33EmBGj022963; Tue, 3 Apr 2007 10:48:11 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2007 10:48:05 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A903F@photon.objectworld.com> In-Reply-To: <46124F38.7020005@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd176Ya+p6xqIGMQfSJrn6cLV80rgACgCmQ References: <24CCCC428EFEA2469BF046DB3C7A8D225274F4@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADECA@namail5.corp.adobe.com> <4FF5FA52-1B38-4964-87AE-72300CE89A1F@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADED9@namail5.corp.adobe.com> <460D4825.2090800@cisco.com> <7b683f3f0703301556j95f2c10sf12d666994dedf6f@mail.gmail.com> <460D9D9C.1040304@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF22@namail5.corp.adobe.com> <46118DA0.4070305@cisco.com> <1fc32c8f0704021813h4387c0c4uec60e7aa3f75606c@mail.gmail.com> <46124F38.7020005@cisco.com> From: "Michael Slavitch" To: "Paul Kyzivat" X-Spam-Score: 1.50 (*) [Tag at 20.00] EXTRA_MPART_TYPE, HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7323bea1d74976e0b97632725f4fc47a Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , Henry Sinnreich , p2prg@ietf.org, sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205255580==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1205255580== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C775FF.19CEFDE7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C775FF.19CEFDE7 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C775FF.19CEFDE7" ------_=_NextPart_002_01C775FF.19CEFDE7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Disposition: inline VGhlIHBvaW50IEkgYW0gbWFraW5nIGlzICB0aGF0IGluIHRoZSBlbnRlcnBy aXNlIHRoZSBhY3R1YWwgdG9wb2xvZ2ljYWwgZGVwbG95bWVudHMgb2YgU0lQ IGNsaWVudHMgYW5kIHNlcnZlcnMsIHdoZW4gaW1wbGVtZW50ZWQgYXMgc29m dHdhcmUgb24gZ2VuZXJpYyBjb21wdXRpbmcgcGxhdGZvcm1zLCBhcyB3ZWxs IGFzIHRoZSBtZWNoYW5pc21zIHRoYXQgbWFrZSB0aGF0IGRlcGxveW1lbnQg aGFwcGVuLCBhcmUgYWxyZWFkeSB2ZXJ5IGRpZmZlcmVudCB3b3JsZCB0aGFu IHRoZSBjYW5vbmljYWwgSU1TL0NTU0lQIG9uZSB3aGljaCAgYXNzdW1lcyBT SVAgYXMgY29yZSBtb25vbGl0aGljIHNlcnZlcnMsIGZpeGVkIGVudGVycHJp c2UgbmV0d29yayBpbnRlZ3JhdGVkIGFjY2VzcyBkZXZpY2VzIChJQUQpLCAg QjJCVUEgZGVtYXJrcywgbmV0d29yayBlbGVtZW50cywgYW5kIGR1bWIgZml4 ZWQgZW5kcG9pbnRzLiAgVGFraW5nIGEgbmV0d29yayBhcyBhIHdob2xlIGVu dGVycHJpc2UgYXBwbGljYXRpb24gc29mdHdhcmUgdXNpbmcgQy9TIFNJUCBw cm94aWVzIGFuZCBVQeKAmXMgYWxyZWFkeSBhcHByb3hpbWF0ZXMgc29tZXRo aW5nIHRoYXQgaXMgY2xvc2UgdG8gd2hhdCBpcyBiZWluZyBjYWxsZWQgUDJQ U0lQLCBvbmx5IGluIGEgbWFubmVyIHRoYXQgaXMgaGlnaGx5IHByb3ByaWV0 YXJ5LCBjbG9zZWQsIHNvbWV3aGF0IGJyaXR0bGUgYW5kIGJhcm9xdWUsIGxv Y2FsLCBhbmQgYWQtaG9jLCB3aXRoIGdhcGluZyB1Z2x5IGhvbGVzLiAgUDJQ IGhhcyB0aGUgcG90ZW50aWFsIHRvIHRyYW5zZm9ybSB0aGF0Lg0KDQogDQoN ClNvbWUgcG9pbnRzIEkgdGFrZSBmcm9tIHRoZSBwcmV2aW91cyBkaXNjdXNz aW9uOg0KDQoNCg0K4oCcdGhhdCBhIFAyUCBzZXR1cCB3aWxsIGJlICpmcmVl KuKAnQ0KDQogDQoNCi0gICAgICAgICAgIEEgUDJQIG5ldHdvcmsgbWF5IG5v dCBiZSBmcmVlLCBidXQgdGhlIHNldHVwIChwcm92aXNpb25pbmcpIHdpbGwg YmUgZnJlZSwgYW5kIGF1dG9tYXRpYy4gIFRoaXMgaXMgYSBtYWpvciBiZW5l Zml0IG9ubHkgcGFydGlhbGx5IGFjaGlldmVkIGluIGVudGVycHJpc2UgbmV0 d29ya3MsICBhIGJlbmVmaXQgb2YgZ3JlYXQgdmFsdWUgdG8gZW50ZXJwcmlz ZXMgdGhhdCBpcyB1bmRlcnNlcnZlZCBieSB2ZW5kb3JzLiAgVGhlcmUgaXMg bm8gYmVuZWZpdCBpbiByZXF1aXJpbmcgY29tcGxleCBkZXBsb3ltZW50cyB3 aGVyZSBhdXRvbWF0aW9uIGNhbiB0YWtlIGl0cyBwbGFjZS4gIERlcGxveW1l bnQgaXMgYWxtb3N0IGFsd2F5cyB0aGUgYmlnZ2VzdCBjb3N0IG9mIGVudGVy cHJpc2Ugc3lzdGVtcyBkd2FyZmluZyB0aGUgY29zdCBvZiB0aGUgc3lzdGVt cyB0aGVtc2VsdmVzLg0KDQogDQoNCuKAnEkgdGhpbmsgdGhpcyBkZXBlbmRz IGdyZWF0bHkgb24gd2hhdCBleHBlY3RhdGlvbnMgLyBjb250cmFjdHVhbCBn dWFyYW50ZWVzIHRoZSBlbnRlcnByaXNlIGhhcy4gSXTigJlzIHVuY2xlYXIg dG8gbWUgd2hhdCBndWFyYW50ZWVzIGNhbiBiZSBtYWRlIGFib3V0IGEgUDJQ U0lQIG5ldHdvcmsgd2lsbCBiZSBhYmxlIHRvIG1ha2UsIGFuZCBpdHMgdW5j bGVhciB3aGF0IGtpbmQgb2YgaW5mcmFzdHJ1Y3R1cmUgd291bGQgYmUgaW5z dGFsbGVkIGJ5L2ZvciBzb21lb25lIHdpbGxpbmcgdG8gbWFrZSBndWFyYW50 ZWVzLuKAnQ0KDQogDQoNCi0gICAgICAgICAgVGhhdCBpcyB3aHkg4oCYZXhw ZWN0YXRpb25zL2NvbnRyYWN0dWFsIGd1YXJhbnRlZXPigJkgbmVlZCB0byBi ZSBidWlsdCBpbnRvIHRoZSBhdXRvbWF0aW9uIHRoYXQgZXhpc3RzIGluIHRo ZSBQMlAgb3ZlcmxheS4gIFNlbGYtY2FsY3VsYXRpb24gb2Ygc3VjaCBwZXJm b3JtYW5jZSBtZXRyaWNzIGlzIGFscmVhZHkgdGhlcmUgaW4gYWxsIGVudGVy cHJpc2UgZGV2aWNlcywgdGhlIGRpZmZlcmVuY2UgYmVpbmcgdGhhdCB3aGls ZSBXTUkvU05NUCBkYXRhIGlzIG1lcmVseSBjb2xsZWN0ZWQgYSBQMlBTSVAg bmV0d29yayBjYW4gYWN0IGF1dG9tYXRpY2FsbHkgYmFzZWQgb24gdGhlIG1l dHJpY3Mgd2l0aGluIHRoZWlyIG93biBub2RlcywgdGhlcmUgaXMgYSBjb2xs ZWN0aXZlIOKAmGFoYeKAmSB0aGF0IGZvcmNlcyBiZWhhdmlvciBjaGFuZ2Ug YmFzZWQgb24gc3RyaWN0IGNvbnRyYWN0cywgYWthIHJ1bGVzLiAgQW4gU0xB IGlzIGVhc2llciB0byBtYWludGFpbiBpZiB0aGUgb2JqZWN0cyBjYW4gcmVh Y3QgYWNjb3JkaW5nbHksIGZvciBleGFtcGxlIGEgbm9kZSB3aXRoIGRlZ3Jh ZGluZyBzZXJ2aWNlIGNhbiBub3RpZnkgdGhhdCBpdCBpcyBvbiB0aGUgZGVj bGluZSBmb3JjaW5nIG90aGVycyB0byB0YWtlIG92ZXIuICANCg0KIA0KDQpU aGVyZSBpcyBhbiBvbGQgdHJhZmZpYyBlbmdpbmVlcmluZyBheGlvbSBhYm91 dCBzZXJ2aWNlIGd1YXJhbnRlZXM6IGl0IGNhbiBiZSBhY2hpZXZlZCB0aHJv dWdoIHR3byB3YXlzOiBvdmVyIGVuZ2luZWVyaW5nIG9yICBhdXRvbWF0aW9u LiAgUDJQU0lQIGFsbG93cyBmb3IgYXV0b21hdGlvbi4NCg0KIA0KDQogRGF2 aWQgT3JhbiB3cm90ZToNCg0KIA0KDQrigJxJJ20gbm90IHNheWluZyB0aGlz IGNhbid0IGJlIG1hZGUgdG8gd29yaywgb25seSB0aGF0IGl0IGlzbid0IGlt bWVkaWF0ZWx5IG9idmlvdXMgdGhhdCBpdCBoYXMgYWR2YW50YWdlcyBvdmVy IGEgY2xhc3NpYyBhcHBsaWNhdGlvbi9zZXJ2ZXIgYXBwcm9hY2gu4oCdDQoN CiANCg0KVGhlIGltbWVkaWF0ZWx5IG9idmlvdXMgYWR2YW50YWdlIHRvIG1l IGlzIHN0YW5kYXJkaXplZCBydWdnZWRpemVkIGF1dG9tYXRpb24gdGhhdCBo YXMgZWNvbm9taWVzIG9mIHNjYWxlIGFuZCBvcGVyYXRlcyBvdmVyIG11bHRp cGxlIGRvbWFpbnMsIGVsaW1pbmF0aW5nIHRoZSBuZWVkIGZvciBvdmVyLWVu Z2luZWVyaW5nLCAgZGV0YWlsZWQgZnVzc3kgcHJvdmlzaW9uaW5nLCAgYW5k IGFuIGFybXkgb2YgcGVvcGxlIGRvaW5nIGJhc2ljIG1vbml0b3JpbmcgYW5k IGNhcmUtYW5kLWZlZWRpbmcuICBBdXRvbWF0aW9uIGlzIHRoZSBrZXksIGEg ZHluYW1pYyBzdGF0aXN0aWNhbCBuZXR3b3JrIHZzLiBvbmUgdGhhdCBpcyBm aXhlZCBhbmQgYXNzdW1lZCBkZXRlcm1pbmlzdGljIHdpbGwgYWx3YXlzIHdp biBvdXQgb3ZlciB0aW1lIGdpdmVuIGEgZnJhY3RhbCBvcGVyYXRpbmcgZW52 aXJvbm1lbnQuICAgVGhpcyBpcyBiZWluZyBkb25lIGluIGZpdHMgYW5kIHN0 YXJ0cyBpbiB0aGUgZW50ZXJwcmlzZSBkYXRhIGNlbnRlci4gICBQMlBTSVAg bWFrZXMgaXQgbXVjaCBtb3JlIGNvbXByZWhlbnNpdmUuICAgUGVvcGxlIHdh bnQgdGhlIHdvcmxkIHRvIGJlIHByZWRpY3RhYmxlIGFuZCBkZXRlcm1pbmlz dGljLCAgYW5kIEMvUyBiYXNlZCBzeXN0ZW1zIHJlZmxlY3QgdGhhdC4gVGhh dCBpcyB0aGUgYmlnZ2VzdCBwcm9ibGVtIFAyUCBmYWNlcyBiZWNhdXNlIGl0 IGZsaWVzIGluIHRoZSBmYWNlIG9mIHRyYWRpdGlvbi4gICANCg0KIA0KDQpS ZWdhcmRzDQoNCiANCg0KTWljaGFlbCBTbGF2aXRjaA0KDQogDQoNCiANCg0K IA0KDQogDQoNCiANCg0KICA8aHR0cDovL3d3dy5vYmplY3R3b3JsZC5jb20v PiANCg0KIA0KDQozMDggTGVnZ2V0IERyLiANCk90dGF3YSBPbnRhcmlvIA0K SzJLIDFZNiBDYW5hZGENCg0KICA8aHR0cDovL21hcHMuZ29vZ2xlLmNhL21h cHM/Zj1xJmhsPWVuJnE9MzA4K0xlZ2dldCtEcml2ZStPdHRhd2ErT250YXJp bytLMksrMVk2JmxheWVyPSZzbGw9NDUuMzQxMDYxLC03NS45MDQ1NDEmc3Nw bj0wLjAwNzExOSwwLjAyMzgzOSZpZT1VVEY4Jno9MTgmbGw9NDUuMzQxMDYx LC03NS45MDQ1NDEmc3BuPTAuMDAxNzgsMC4wMDU5NiZ0PWgmb209MT4gDQoN CiAJIA0KTWljaGFlbCBTbGF2aXRjaCAgICAgICAgICAgICAgDQoNCkxlYWQs IFRlY2hub2xvZ3kgSW5pdGlhdGl2ZXMNCg0Kc2xhdml0Y2hAb2JqZWN0d29y bGQuY29tDQoNClBTVE46ICANCg0KKzEuODg4LjM5OC45Njk4DQoNCngyMjUN Cg0KRmF4Og0KDQorMS42MTMuNTk5Ljc0NTcNCg0KIA0KDQpTa3lwZTogICAg ICAgDQoNCiBPYmplY3R3b3JsZCAgIA0KDQp4MjI1DQoNCiAgPHNreXBlOk9i amVjdHdvcmxkPiANCg0KIAkgDQoNCiANCg0KIA0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5 eml2YXRAY2lzY28uY29tXSANClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDAzLCAy MDA3IDg6NTcgQU0NClRvOiBNaWNoYWVsIFNsYXZpdGNoDQpDYzogSGVucnkg U2lubnJlaWNoOyBQMlBTSVAgTWFpbGluZyBMaXN0OyBNaWNoYWVsIEhhbW1l ciAobWhhbW1lcik7IERhdmlkIFIgT3JhbjsgcDJwcmdAaWV0Zi5vcmc7IHNp cHBpbmdAaWV0Zi5vcmc7IHpodXhpYW4NClN1YmplY3Q6IFJlOiBbUDJQcmdd IFJFOiBbU2lwcGluZ10gU2ltcGxlIFNJUCB1c2FnZSBzY2VuYXJpbw0KDQog DQoNCiANCg0KIA0KDQpNaWNoYWVsIFNsYXZpdGNoIHdyb3RlOg0KDQo+IFNv cnJ5IGZvciBiZWluZyBsYXRlIGludG8gdGhpcyBkaXNjdXNzaW9uLCBidXQg Y2xpZW50LXNlcnZlciBiYXNlZCBWTSANCg0KPiBpc24ndCB0cnVseSBjbGll bnQtc2VydmVyIGFueW1vcmUgaW4gYW55dGhpbmcgYnV0IHRoZSBzbWFsbGVz dCBvciBtb3N0IA0KDQo+IG1vbm9saXRoaWMgb2YgZW50ZXJwcmlzZSBuZXR3 b3JrcywgaW4gZmFjdCB0aGUgcmVhbGl0eSBpcyB0aGF0IG1vc3QgaWYgDQoN Cj4gbm90IGFsbCBlbnRlcnByaXNlIG5ldHdvcmtzIGNvbnRhaW4ganVzdCBw ZWVycyBhbmQgc3VwZXJwZWVycyB3aXRoIHRoZSANCg0KPiBkaWZmZXJlbmNl IGJlaW5nIHBhcnRpYWxseSBhIG1hcmtldGluZyBkZWNpc2lvbiBieSB0aGUg dmVuZG9ycywgYXMgeW91IA0KDQo+IGNhbiBjaGFyZ2UgbXVjaCBtb3JlIGZv ciB0aGUgc2VydmVycywgYW5kIGEgcG9saWN5IGRlY2lzaW9uIG1hZGUgZWl0 aGVyIA0KDQo+IGF1dG9tYXRpY2FsbHkgYnkgYSBzb2Z0d2FyZSBkZXBsb3lt ZW50IHN5c3RlbSBvciBieSBJVCBzdGFmZiB3aGljaCB3YW50cyANCg0KPiB0 byBwbGFjZSBzdXBlcm5vZGVzIHdpdGggZGF0YSBzaW5rcyBvbiBhcHByb3By aWF0ZSBlcXVpcG1lbnQuDQoNCiANCg0KSSdtIHNvcnJ5LCBidXQgSSBkb24n dCB1bmRlcnN0YW5kIHRoZSBwb2ludCB5b3UgYXJlIHRyeWluZyB0byBtYWtl IA0KDQphYm92ZS4gWW91IGFyZSB0cnlpbmcgdG8gZHJhdyBzb21lIHNvcnQg b2YgZGlzdGluY3Rpb24sIGJ1dCBJIGRvbid0IGdldCANCg0KaXQuIENhbiB5 b3UgdHJ5IGFnYWluLg0KDQogDQoNCiAgICAgICAgICAgICAgICBUaGFua3Ms DQoNCiAgICAgICAgICAgICAgICBQYXVsDQoNCiANCg0KPiBJbiBhIA0KDQo+ IGhpZ2hseSBkaXN0cmlidXRlZCBlbnZpcm9ubWVudCB0aGVyZSBhcmUgcG90 ZW50aWFsbHkgaHVuZHJlZHMgb2YgDQoNCj4gcG9zc2libGUgZGF0YSBzaW5r cyBmb3IgYSBnaXZlbiBhcHBsaWNhdGlvbiwgd2l0aCB0aGUgc2luayBiYXNl ZCBvbiANCg0KPiBzdWJuZXQgb3IgZ2VvZ3JhcGhpYyBsb2NhdGlvbiBvciBi YWxhbmNlZCBsb2FkLCB0aGlzIGNhbiBjaGFuZ2UgcmFwaWRseSANCg0KPiBv dmVyIHRpbWUgYW5kIGRvZXMuDQoNCj4gDQoNCj4gSW4gdGhlIGNhc2Ugb2Yg dGhlIE1pY3Jvc29mdCBlbnZpcm9ubWVudCBzdWNoIHBvbGljeSBpcyBhZG1p bmlzdGVyZWQgYW5kIA0KDQo+IHB1Ymxpc2hlZCBiZXR3ZWVuIHN1cGVybm9k ZXMsIGllIHNlcnZlcnMsIGJ5IEFjdGl2ZSBEaXJlY3RvcnkuICBJdCBpcyAN Cg0KPiBhZHZlcnRpc2VkIHRvIG1lcmUgcGVlcnMgdGhyb3VnaCBETlMuICBU aGVyZSB3YXMgbXVjaCBkaXNjdXNzaW9uIGEgd2hpbGUgDQoNCj4gYWdvIGFi b3V0IGJ1aWxkaW5nIHNlcnZpY2UgZGlzY292ZXJ5IGVudmlyb25tZW50IHVz aW5nIEROUyBpbnN0ZWFkIG9mIGEgDQoNCj4gUDJQIERIVC4gIEl0IGNhbiBi ZSBhcmd1ZWQgdGhhdCBhIGNhc2Ugc3R1ZHkgb2YgYSBQMlAgZXhhbXBsZSBk b25lIHVzaW5nIA0KDQo+IEROUyBpcyBhbnkgbGFyZ2UgV2luZG93cyBTZXJ2 ZXIgMjAwMyBiYXNlZCBNaWNyb3NvZnQgbmV0d29yayB3aXRoIG1hbnkgDQoN Cj4gc2VydmVycyBhbmQgbWFueSBtb3JlIGNsaWVudHMgdGhhdCBhbHNvIHJ1 biBhcHBsaWNhdGlvbnMgdGhlbXNlbHZlcyBhbmQgDQoNCj4gYXJlIG5vdCBq dXN0IGR1bWIgdGVybWluYWxzLiBUaGlzIGlzIGFsbW9zdCBjZXJ0YWlubHkg YWx3YXlzIHRoZSBjYXNlIGluIA0KDQo+IGFsbCBlbnRlcnByaXNlcy4gVGhl IGJpZyBkaWZmZXJlbmNlIGJldHdlZW4gQy9TIFNJUCBhbmQgUDJQU0lQIGlz IA0KDQo+IGF1dG9tYXRpb24uIFdoYXQgaXMgdHJ1ZSBpcyB0aGF0IHRoZSBz cXVhcmUgcGVnIGluIHJvdW5kIGhvbGUgb2YgDQoNCj4gb3ZlcmxvYWRpbmcg RE5TIG1ha2VzIGRlcGxveW1lbnRzIGNsdW1zeSBhbmQgYnJpdHRsZSB3aXRo aW4gdGhlIA0KDQo+IGVudGVycHJpc2UgZG9tYWluIGFuZCBjb21wbGV0ZWx5 IHVubWFuYWdlYWJsZSBhbmQgdW5wdWJsaXNoYWJsZSBvdXRzaWRlIA0KDQo+ IHRoZSBmaXJld2FsbCB3aGljaCBpcyB3aHkgdGhlIGJ1Y2sgc3RvcHMgdGhl cmUgaW4gY3VycmVudCBlbnRlcnByaXNlIA0KDQo+IG5ldHdvcmtpbmcgcHJv ZHVjdHMuDQoNCj4gDQoNCj4gVGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBDL1Mg YW5kIFAyUCBpcyBsYXJnZWx5IHBvbGljeSBhbmQgc2VtYW50aWNzIHdpdGgg DQoNCj4gdGhlIGJpZ2dlc3QgZGlmZmVyZW5jZSBiZWluZyB0aGF0IHRoZSBk ZWNpc2lvbnMgYW5kIHJ1bGVzIGFyZSBoaWdobHkgDQoNCj4gZGlzdHJpYnV0 ZWQuICBBcGFydCBmcm9tIHRoYXQgdGhleSBhcmUgbm90IGp1c3QgZnJpZW5k cywgdGhleSBhcmUgDQoNCj4gZnJhdGVybmFsIHR3aW5zLg0KDQo+IA0KDQo+ IFJlZ2FyZHMNCg0KPiANCg0KPiBNaWNoYWVsIFNsYXZpdGNoDQoNCj4gDQoN Cj4gIA0KDQo+IA0KDQo+IA0KDQo+IGNvcnBfMmNvbG91ciANCg0KPiA8aHR0 cHM6Ly9maXJld2FsbC5vYmplY3R3b3JsZC5jb20vZXhjaHdlYi9iaW4vcmVk aXIuYXNwP1VSTD1odHRwOi8vd3d3Lm9iamVjdHdvcmxkLmNvbS8+DQoNCj4g DQoNCj4gIA0KDQo+IA0KDQo+ICAgICAgICAgICAgIA0KDQo+IA0KDQo+IDMw OCBMZWdnZXQgRHIuDQoNCj4gT3R0YXdhIE9udGFyaW8NCg0KPiBLMksgMVk2 IENhbmFkYQ0KDQo+IA0KDQo+ICAgICAgICAgICAgIA0KDQo+IA0KDQo+IDxo dHRwczovL2ZpcmV3YWxsLm9iamVjdHdvcmxkLmNvbS9leGNod2ViL2Jpbi9y ZWRpci5hc3A/VVJMPWh0dHA6Ly9tYXBzLmdvb2dsZS5jYS9tYXBzP2Y9cSUy NmhsPWVuJTI2cT0zMDglMkJMZWdnZXQlMkJEcml2ZSUyQk90dGF3YSUyQk9u dGFyaW8lMkJLMkslMkIxWTYlMjZsYXllcj0lMjZzbGw9NDUuMzQxMDYxLC03 NS45MDQ1NDElMjZzc3BuPTAuMDA3MTE5LDAuMDIzODM5JTI2aWU9VVRGOCUy Nno9MTglMjZsbD00NS4zNDEwNjEsLTc1LjkwNDU0MSUyNnNwbj0wLjAwMTc4 LDAuMDA1OTYlMjZ0PWglMjZvbT0xPg0KDQo+IA0KDQo+ICAgICAgICAgICAg IA0KDQo+IA0KDQo+ICANCg0KPiANCg0KPiBNaWNoYWVsIFNsYXZpdGNoICAg ICAgICAgICAgIA0KDQo+IA0KDQo+IExlYWQsIFRlY2hub2xvZ3kgSW5pdGlh dGl2ZXMNCg0KPiANCg0KPiBzbGF2aXRjaEBvYmplY3R3b3JsZC5jb20gPG1h aWx0bzpzbGF2aXRjaEBvYmplY3R3b3JsZC5jb20+DQoNCj4gDQoNCj4gICAg ICAgICAgICAgDQoNCj4gDQoNCj4gUFNUTjogDQoNCj4gDQoNCj4gICAgICAg ICAgICAgDQoNCj4gDQoNCj4gKzEuODg4LjM5OC45Njk4DQoNCj4gDQoNCj4g ICAgICAgICAgICAgDQoNCj4gDQoNCj4geDIyNQ0KDQo+IA0KDQo+IEZheDoN Cg0KPiANCg0KPiAgICAgICAgICAgICANCg0KPiANCg0KPiArMS42MTMuNTk5 Ljc0NTcNCg0KPiANCg0KPiAgICAgICAgICAgICANCg0KPiANCg0KPiAgDQoN Cj4gDQoNCj4gU2t5cGU6ICAgICAgDQoNCj4gDQoNCj4gICAgICAgICAgICAg DQoNCj4gDQoNCj4gICBPYmplY3R3b3JsZCANCg0KPiA8aHR0cHM6Ly9maXJl d2FsbC5vYmplY3R3b3JsZC5jb20vZXhjaGFuZ2Uvc2xhdml0Y2gvU2VudCUy MEl0ZW1zL05vcnRlbCwlMjBNU0ZUJTIwY2hhc2UlMjBjYXJyaWVycyUyMHdp dGglMjBuZXclMjBob3N0ZWQlMjBvZmZlcmluZyUyMGZvciUyMFNNRSUyMGFu ZCUyME1NRS5FTUwvPiAgIA0KDQo+IA0KDQo+IA0KDQo+ICAgICAgICAgICAg IA0KDQo+IA0KDQo+IHgyMjUNCg0KPiANCg0KPiAgICAgICAgICAgICANCg0K PiANCg0KPiA8aHR0cHM6Ly9maXJld2FsbC5vYmplY3R3b3JsZC5jb20vZXhj aGFuZ2Uvc2xhdml0Y2gvU2VudCUyMEl0ZW1zL05vcnRlbCwlMjBNU0ZUJTIw Y2hhc2UlMjBjYXJyaWVycyUyMHdpdGglMjBuZXclMjBob3N0ZWQlMjBvZmZl cmluZyUyMGZvciUyMFNNRSUyMGFuZCUyME1NRS5FTUwvPg0KDQo+IA0KDQo+ ICAgICAgICAgICAgIA0KDQo+IA0KDQo+ICANCg0KPiANCg0KPiAgDQoNCj4g DQoNCj4gDQoNCiANCg0KIA0KDQotLSANCg0KDQogDQoNCgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlz IHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2Vk IG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRo ZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmls ZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4g QW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2Us IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9u IG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50 cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiANCg0K QW55IHZpZXdzLCBvcGluaW9ucyBhbmQgY29udGVudCBwcmVzZW50ZWQgaW4g dGhpcyBlLW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFu ZCBtYXkgbm90IHJlcHJlc2VudCB0aG9zZSBvZiBPYmplY3R3b3JsZCBDb21t dW5pY2F0aW9ucyBDb3JwLiAK ------_=_NextPart_002_01C775FF.19CEFDE7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Disposition: inline PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v cmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29m dCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4N CjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6 NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5v c2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9 DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjg0Njg2NzE5NzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzOTgwNTAzOCAtMTcxNDc4MzQ4MiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMjA1MCIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8 Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxk aXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5U aGUgcG9pbnQgSSBhbSBtYWtpbmcgaXPCoCB0aGF0IGluIHRoZSBlbnRlcnBy aXNlIHRoZSBhY3R1YWwNCnRvcG9sb2dpY2FsIGRlcGxveW1lbnRzIG9mIFNJ UCBjbGllbnRzIGFuZCBzZXJ2ZXJzLCA8aT53aGVuIGltcGxlbWVudGVkIGFz IHNvZnR3YXJlDQpvbiBnZW5lcmljIGNvbXB1dGluZyBwbGF0Zm9ybXM8L2k+ LCBhcyB3ZWxsIGFzIHRoZSA8aT5tZWNoYW5pc21zIHRoYXQgbWFrZSB0aGF0 DQpkZXBsb3ltZW50IGhhcHBlbjwvaT4sIGFyZSBhbHJlYWR5IHZlcnkgZGlm ZmVyZW50IHdvcmxkIHRoYW4gdGhlIGNhbm9uaWNhbA0KSU1TL0NTU0lQIG9u ZSB3aGljaCDCoGFzc3VtZXMgU0lQIGFzIGNvcmUgbW9ub2xpdGhpYyBzZXJ2 ZXJzLCBmaXhlZCBlbnRlcnByaXNlDQpuZXR3b3JrIGludGVncmF0ZWQgYWNj ZXNzIGRldmljZXMgKElBRCksIMKgQjJCVUEgZGVtYXJrcywgbmV0d29yayBl bGVtZW50cywgYW5kIGR1bWINCmZpeGVkIGVuZHBvaW50cy7CoCBUYWtpbmcg YSBuZXR3b3JrIGFzIGEgd2hvbGUgZW50ZXJwcmlzZSBhcHBsaWNhdGlvbiBz b2Z0d2FyZSB1c2luZw0KQy9TIFNJUCBwcm94aWVzIGFuZCBVQeKAmXMgPGk+ YWxyZWFkeTwvaT4gYXBwcm94aW1hdGVzIHNvbWV0aGluZyB0aGF0IGlzIGNs b3NlIHRvDQp3aGF0IGlzIGJlaW5nIGNhbGxlZCBQMlBTSVAsIG9ubHkgaW4g YSBtYW5uZXIgdGhhdCBpcyBoaWdobHkgcHJvcHJpZXRhcnksDQpjbG9zZWQs IHNvbWV3aGF0IGJyaXR0bGUgYW5kIGJhcm9xdWUsIGxvY2FsLCBhbmQgYWQt aG9jLCB3aXRoIGdhcGluZyB1Z2x5IGhvbGVzLsKgDQpQMlAgaGFzIHRoZSBw b3RlbnRpYWwgdG8gdHJhbnNmb3JtIHRoYXQuPG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PlNvbWUgcG9pbnRzIEkgdGFrZSBm cm9tIHRoZSBwcmV2aW91cyBkaXNjdXNzaW9uOjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+4oCcdGhhdCBh IFAyUCBzZXR1cCB3aWxsIGJlICpmcmVlKuKAnTxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0nbWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuDQpzdHlsZT0nbXNvLWxp c3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5l dyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ wqBBIFAyUCBuZXR3b3JrIG1heSBub3QgYmUgZnJlZSwgYnV0IHRoZSBzZXR1 cCAocHJvdmlzaW9uaW5nKQ0Kd2lsbCBiZSBmcmVlLCBhbmQgYXV0b21hdGlj LsKgIFRoaXMgaXMgYSBtYWpvciBiZW5lZml0IG9ubHkgcGFydGlhbGx5IGFj aGlldmVkDQppbiBlbnRlcnByaXNlIG5ldHdvcmtzLMKgIGEgYmVuZWZpdCBv ZiBncmVhdCB2YWx1ZSB0byBlbnRlcnByaXNlcyB0aGF0IGlzDQp1bmRlcnNl cnZlZCBieSB2ZW5kb3JzLsKgIFRoZXJlIGlzIG5vIGJlbmVmaXQgaW4gcmVx dWlyaW5nIGNvbXBsZXggZGVwbG95bWVudHMNCndoZXJlIGF1dG9tYXRpb24g Y2FuIHRha2UgaXRzIHBsYWNlLsKgIERlcGxveW1lbnQgaXMgYWxtb3N0IGFs d2F5cyB0aGUgYmlnZ2VzdA0KY29zdCBvZiBlbnRlcnByaXNlIHN5c3RlbXMg ZHdhcmZpbmcgdGhlIGNvc3Qgb2YgdGhlIHN5c3RlbXMgdGhlbXNlbHZlcy48 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxl PSdtYXJnaW4tbGVmdDouMjVpbic+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD7igJxJIHRoaW5rIHRoaXMgZGVwZW5k cyBncmVhdGx5IG9uIHdoYXQgZXhwZWN0YXRpb25zIC8NCmNvbnRyYWN0dWFs IGd1YXJhbnRlZXMgdGhlIGVudGVycHJpc2UgaGFzLiBJdOKAmXMgdW5jbGVh ciB0byBtZSB3aGF0IGd1YXJhbnRlZXMNCmNhbiBiZSBtYWRlIGFib3V0IGEg UDJQU0lQIG5ldHdvcmsgd2lsbCBiZSBhYmxlIHRvIG1ha2UsIGFuZCBpdHMg dW5jbGVhciB3aGF0DQpraW5kIG9mIGluZnJhc3RydWN0dXJlIHdvdWxkIGJl IGluc3RhbGxlZCBieS9mb3Igc29tZW9uZSB3aWxsaW5nIHRvIG1ha2UNCmd1 YXJhbnRlZXMu4oCdPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0IHN0eWxlPSdtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4NCnN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3Bh biBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGF0IGlzIHdoeSDigJhl eHBlY3RhdGlvbnMvY29udHJhY3R1YWwgZ3VhcmFudGVlc+KAmSBuZWVkDQp0 byBiZSBidWlsdCBpbnRvIHRoZSBhdXRvbWF0aW9uIHRoYXQgZXhpc3RzIGlu IHRoZSBQMlAgb3ZlcmxheS7CoA0KU2VsZi1jYWxjdWxhdGlvbiBvZiBzdWNo IHBlcmZvcm1hbmNlIG1ldHJpY3MgaXMgYWxyZWFkeSB0aGVyZSBpbiBhbGwg ZW50ZXJwcmlzZQ0KZGV2aWNlcywgdGhlIGRpZmZlcmVuY2UgYmVpbmcgdGhh dCB3aGlsZSBXTUkvU05NUCBkYXRhIGlzIG1lcmVseSBjb2xsZWN0ZWQgYQ0K UDJQU0lQIG5ldHdvcmsgY2FuIGFjdCBhdXRvbWF0aWNhbGx5IGJhc2VkIG9u IHRoZSBtZXRyaWNzIHdpdGhpbiB0aGVpciBvd24gbm9kZXMsDQp0aGVyZSBp cyBhIGNvbGxlY3RpdmUg4oCYYWhh4oCZIHRoYXQgZm9yY2VzIGJlaGF2aW9y IGNoYW5nZSBiYXNlZCBvbiBzdHJpY3QNCmNvbnRyYWN0cywgYWthIHJ1bGVz LsKgIEFuIFNMQSBpcyBlYXNpZXIgdG8gbWFpbnRhaW4gaWYgdGhlIG9iamVj dHMgY2FuIHJlYWN0DQphY2NvcmRpbmdseSwgZm9yIGV4YW1wbGUgYSBub2Rl IHdpdGggZGVncmFkaW5nIHNlcnZpY2UgY2FuIG5vdGlmeSB0aGF0IGl0IGlz IG9uDQp0aGUgZGVjbGluZSBmb3JjaW5nIG90aGVycyB0byB0YWtlIG92ZXIu wqAgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dCBz dHlsZT0nbWFyZ2luLWxlZnQ6LjI1aW4nPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+VGhlcmUgaXMgYW4gb2xkIHRy YWZmaWMgZW5naW5lZXJpbmcgYXhpb20gYWJvdXQgc2VydmljZSBndWFyYW50 ZWVzOg0KaXQgY2FuIGJlIGFjaGlldmVkIHRocm91Z2ggdHdvIHdheXM6IG92 ZXIgZW5naW5lZXJpbmcgb3IgwqBhdXRvbWF0aW9uLsKgIFAyUFNJUCBhbGxv d3MNCmZvciBhdXRvbWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD7CoERhdmlkIE9yYW4gd3JvdGU6PG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PuKAnEknbSBub3Qg c2F5aW5nIHRoaXMgY2FuJ3QgYmUgbWFkZSB0byB3b3JrLCBvbmx5IHRoYXQg aXQNCmlzbid0IGltbWVkaWF0ZWx5IG9idmlvdXMgdGhhdCBpdCBoYXMgYWR2 YW50YWdlcyBvdmVyIGEgY2xhc3NpYyBhcHBsaWNhdGlvbi9zZXJ2ZXINCmFw cHJvYWNoLuKAnTxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD5UaGUgaW1tZWRpYXRlbHkgb2J2aW91cyBhZHZhbnRhZ2UgdG8g bWUgaXMgc3RhbmRhcmRpemVkDQpydWdnZWRpemVkIGF1dG9tYXRpb24gdGhh dCBoYXMgZWNvbm9taWVzIG9mIHNjYWxlIGFuZCBvcGVyYXRlcyBvdmVyIG11 bHRpcGxlDQpkb21haW5zLCBlbGltaW5hdGluZyB0aGUgbmVlZCBmb3Igb3Zl ci1lbmdpbmVlcmluZyzCoCBkZXRhaWxlZCBmdXNzeQ0KcHJvdmlzaW9uaW5n LMKgIGFuZCBhbiBhcm15IG9mIHBlb3BsZSBkb2luZyBiYXNpYyBtb25pdG9y aW5nIGFuZCBjYXJlLWFuZC1mZWVkaW5nLsKgDQpBdXRvbWF0aW9uIGlzIHRo ZSBrZXksIGEgZHluYW1pYyBzdGF0aXN0aWNhbCBuZXR3b3JrIHZzLiBvbmUg dGhhdCBpcyBmaXhlZCBhbmQNCmFzc3VtZWQgZGV0ZXJtaW5pc3RpYyB3aWxs IGFsd2F5cyB3aW4gb3V0IG92ZXIgdGltZSBnaXZlbiBhIGZyYWN0YWwgb3Bl cmF0aW5nDQplbnZpcm9ubWVudC7CoMKgIFRoaXMgaXMgYmVpbmcgZG9uZSBp biBmaXRzIGFuZCBzdGFydHMgaW4gdGhlIGVudGVycHJpc2UgZGF0YQ0KY2Vu dGVyLsKgwqAgUDJQU0lQIG1ha2VzIGl0IG11Y2ggbW9yZSBjb21wcmVoZW5z aXZlLsKgIMKgUGVvcGxlIHdhbnQgdGhlIHdvcmxkIHRvDQpiZSBwcmVkaWN0 YWJsZSBhbmQgZGV0ZXJtaW5pc3RpYyzCoCBhbmQgQy9TIGJhc2VkIHN5c3Rl bXMgcmVmbGVjdCB0aGF0LiBUaGF0IGlzDQp0aGUgYmlnZ2VzdCBwcm9ibGVt IFAyUCBmYWNlcyBiZWNhdXNlIGl0IGZsaWVzIGluIHRoZSBmYWNlIG9mIHRy YWRpdGlvbi4gwqDCoDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD5SZWdhcmRzPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNz PU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0Pk1pY2hhZWwgU2xhdml0Y2g8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD7CoDxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+wqA8bzpwPjwvbzpwPjwv cD4NCg0KPHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0xIGNl bGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD0iMTAwJSINCiBzdHls ZT0nd2lkdGg6MTAwLjAlO2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZTtib3Jk ZXI6bm9uZSc+DQogPHRyPg0KICA8dGQgd2lkdGg9NjM4IGNvbHNwYW49NCB2 YWxpZ249dG9wIHN0eWxlPSd3aWR0aDo2LjY1aW47Ym9yZGVyOm5vbmU7DQog IGJvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtiYWNrZ3JvdW5k OndoaXRlO3BhZGRpbmc6MGluIDUuNHB0IDBpbiA1LjRwdCc+DQogIDxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCiAgPC90ZD4N CiA8L3RyPg0KIDx0cj4NCiAgPHRkIHdpZHRoPTI4NiB2YWxpZ249dG9wIHN0 eWxlPSd3aWR0aDoyMTQuNTVwdDtib3JkZXI6bm9uZTtiYWNrZ3JvdW5kOndo aXRlOw0KICBwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+DQogIDxwIGNsYXNz PU1zb05vcm1hbD48YSBocmVmPSJodHRwOi8vd3d3Lm9iamVjdHdvcmxkLmNv bS8iDQogIHRpdGxlPSJPYmplY3R3b3JsZCBDb21tdW5pY2F0aW9ucyI+PHNw YW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOg0K ICBub25lJz48aW1nIGJvcmRlcj0wIHdpZHRoPTIzNyBoZWlnaHQ9NDIgaWQ9 IlBpY3R1cmVfeDAwMjBfMSINCiAgc3JjPSJjaWQ6aW1hZ2UwMDUuanBnQDAx Qzc3NURELjhGMUQ0MUYwIiBhbHQ9ImNvcnBfMmNvbG91ciI+PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9MjExIHZh bGlnbj10b3Agc3R5bGU9J3dpZHRoOjE1OC4wNXB0O2JvcmRlcjpub25lO2Jh Y2tncm91bmQ6d2hpdGU7DQogIHBhZGRpbmc6MGluIDBpbiAwaW4gMGluJz4N CiAgPHAgY2xhc3M9TXNvTm9ybWFsPjMwOCBMZWdnZXQgRHIuIDxicj4NCiAg T3R0YXdhIE9udGFyaW8gPGJyPg0KICBLMksgMVk2IENhbmFkYTxvOnA+PC9v OnA+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9MTM3IHZhbGlnbj10b3Ag c3R5bGU9J3dpZHRoOjEwMi42cHQ7Ym9yZGVyOm5vbmU7YmFja2dyb3VuZDp3 aGl0ZTsNCiAgcGFkZGluZzowaW4gMGluIDBpbiAwaW4nPg0KICA8cCBjbGFz cz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmln aHQnPjxhDQogIGhyZWY9Imh0dHA6Ly9tYXBzLmdvb2dsZS5jYS9tYXBzP2Y9 cSZhbXA7aGw9ZW4mYW1wO3E9MzA4K0xlZ2dldCtEcml2ZStPdHRhd2ErT250 YXJpbytLMksrMVk2JmFtcDtsYXllcj0mYW1wO3NsbD00NS4zNDEwNjEsLTc1 LjkwNDU0MSZhbXA7c3Nwbj0wLjAwNzExOSwwLjAyMzgzOSZhbXA7aWU9VVRG OCZhbXA7ej0xOCZhbXA7bGw9NDUuMzQxMDYxLC03NS45MDQ1NDEmYW1wO3Nw bj0wLjAwMTc4LDAuMDA1OTYmYW1wO3Q9aCZhbXA7b209MSINCiAgdGl0bGU9 IjMwOCBMZWdnZXQgRHJpdmUgT3R0YXdhIE9udGFyaW8gSzJLIDFZNiI+PHNw YW4gc3R5bGU9J2NvbG9yOndpbmRvd3RleHQ7DQogIHRleHQtZGVjb3JhdGlv bjpub25lJz48aW1nIGJvcmRlcj0wIHdpZHRoPTI5IGhlaWdodD0yOSBpZD0i UGljdHVyZV94MDAyMF82Ig0KICBzcmM9ImNpZDppbWFnZTAwMy5wbmdAMDFD Nzc1RDkuNzNDNTZEQTAiPjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQog IDwvdGQ+DQogIDx0ZCBzdHlsZT0nYm9yZGVyOm5vbmU7cGFkZGluZzowaW4g MGluIDBpbiAwaW4nIHdpZHRoPTU+PHAgY2xhc3M9J01zb05vcm1hbCc+Jm5i c3A7PC90ZD4NCiA8L3RyPg0KIDx0cj4NCiAgPHRkIHdpZHRoPTI4NiB2YWxp Z249dG9wIHN0eWxlPSd3aWR0aDoyMTQuNTVwdDtib3JkZXI6bm9uZTtiYWNr Z3JvdW5kOndoaXRlOw0KICBwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+DQog IDx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3Bh Y2luZz0wIGNlbGxwYWRkaW5nPTANCiAgIHN0eWxlPSdib3JkZXItY29sbGFw c2U6Y29sbGFwc2UnPg0KICAgPHRyPg0KICAgIDx0ZCB3aWR0aD0yNzggdmFs aWduPXRvcCBzdHlsZT0nd2lkdGg6MjA4LjRwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPk1pY2hhZWwNCiAg ICBTbGF2aXRjaCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO8KgwqDCoCA8bzpwPjwvbzpwPjwv cD4NCiAgICA8L3RkPg0KICAgPC90cj4NCiAgIDx0cj4NCiAgICA8dGQgd2lk dGg9Mjc4IHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjIwOC40cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiAwaW4nPg0KICAgIDxwIGNsYXNzPU1zb05vcm1hbD5M ZWFkLCBUZWNobm9sb2d5IEluaXRpYXRpdmVzPG86cD48L286cD48L3A+DQog ICAgPC90ZD4NCiAgIDwvdHI+DQogICA8dHI+DQogICAgPHRkIHdpZHRoPTI3 OCB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoyMDguNHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gMGluJz4NCiAgICA8cCBjbGFzcz1Nc29Ob3JtYWw+c2xhdml0 Y2hAb2JqZWN0d29ybGQuY29tPG86cD48L286cD48L3A+DQogICAgPC90ZD4N CiAgIDwvdHI+DQogIDwvdGFibGU+DQogIDwvdGQ+DQogIDx0ZCB3aWR0aD0y MTEgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MTU4LjA1cHQ7Ym9yZGVyOm5v bmU7YmFja2dyb3VuZDp3aGl0ZTsNCiAgcGFkZGluZzowaW4gMGluIDBpbiAw aW4nPg0KICA8dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAg Y2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTIwNA0KICAgc3R5 bGU9J3dpZHRoOjE1Mi44NXB0O2JvcmRlci1jb2xsYXBzZTpjb2xsYXBzZSc+ DQogICA8dHI+DQogICAgPHRkIHdpZHRoPTQyIHZhbGlnbj10b3Agc3R5bGU9 J3dpZHRoOjMxLjI1cHQ7cGFkZGluZzowaW4gMGluIDBpbiAwaW4nPg0KICAg IDxwIGNsYXNzPU1zb05vcm1hbD5QU1ROOsKgIDxvOnA+PC9vOnA+PC9wPg0K ICAgIDwvdGQ+DQogICAgPHRkIHdpZHRoPTEzMSB2YWxpZ249dG9wIHN0eWxl PSd3aWR0aDo5OC4wNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz4NCiAg ICA8cCBjbGFzcz1Nc29Ob3JtYWw+KzEuODg4LjM5OC45Njk4PG86cD48L286 cD48L3A+DQogICAgPC90ZD4NCiAgICA8dGQgd2lkdGg9MzEgdmFsaWduPXRv cCBzdHlsZT0nd2lkdGg6MjMuNTVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBp bic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPngyMjU8bzpwPjwvbzpwPjwv cD4NCiAgICA8L3RkPg0KICAgPC90cj4NCiAgIDx0cj4NCiAgICA8dGQgd2lk dGg9NDIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MzEuMjVwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDBpbic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPkZh eDo8bzpwPjwvbzpwPjwvcD4NCiAgICA8L3RkPg0KICAgIDx0ZCB3aWR0aD0x MzEgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6OTguMDVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDBpbic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPisxLjYx My41OTkuNzQ1NzxvOnA+PC9vOnA+PC9wPg0KICAgIDwvdGQ+DQogICAgPHRk IHdpZHRoPTMxIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjIzLjU1cHQ7cGFk ZGluZzowaW4gMGluIDBpbiAwaW4nPg0KICAgIDxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCiAgICA8L3RkPg0KICAgPC90cj4N CiAgIDx0cj4NCiAgICA8dGQgd2lkdGg9NDIgdmFsaWduPXRvcCBzdHlsZT0n d2lkdGg6MzEuMjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+DQogICAg PHAgY2xhc3M9TXNvTm9ybWFsPlNreXBlOsKgwqDCoMKgwqDCoCA8bzpwPjwv bzpwPjwvcD4NCiAgICA8L3RkPg0KICAgIDx0ZCB3aWR0aD0xMzEgdmFsaWdu PXRvcCBzdHlsZT0nd2lkdGg6OTguMDVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPsKgPGEgaHJlZj0iU2t5 cGU6T2JqZWN0d29ybGQiPk9iamVjdHdvcmxkPC9hPsKgwqAgPG86cD48L286 cD48L3A+DQogICAgPC90ZD4NCiAgICA8dGQgd2lkdGg9MzEgdmFsaWduPXRv cCBzdHlsZT0nd2lkdGg6MjMuNTVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBp bic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPngyMjU8bzpwPjwvbzpwPjwv cD4NCiAgICA8L3RkPg0KICAgPC90cj4NCiAgPC90YWJsZT4NCiAgPC90ZD4N CiAgPHRkIHdpZHRoPTEzNyB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoxMDIu NnB0O2JvcmRlcjpub25lO2JhY2tncm91bmQ6d2hpdGU7DQogIHBhZGRpbmc6 MGluIDBpbiAwaW4gMGluJz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWdu PXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48YQ0KICBocmVmPSJz a3lwZTpPYmplY3R3b3JsZCIgdGl0bGU9T2JqZWN0d29ybGQ+PHNwYW4gc3R5 bGU9J2NvbG9yOndpbmRvd3RleHQ7DQogIHRleHQtZGVjb3JhdGlvbjpub25l Jz48aW1nIGJvcmRlcj0wIHdpZHRoPTI2IGhlaWdodD0yNiBpZD0iUGljdHVy ZV94MDAyMF8zIg0KICBzcmM9ImNpZDppbWFnZTAwNC5wbmdAMDFDNzc1RDku NzNDNTZEQTAiPjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQogIDwvdGQ+ DQogIDx0ZCBzdHlsZT0nYm9yZGVyOm5vbmU7cGFkZGluZzowaW4gMGluIDBp biAwaW4nIHdpZHRoPTU+PHAgY2xhc3M9J01zb05vcm1hbCc+Jm5ic3A7PC90 ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFBhdWwg S3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbV0gPGJyPg0KU2Vu dDogVHVlc2RheSwgQXByaWwgMDMsIDIwMDcgODo1NyBBTTxicj4NClRvOiBN aWNoYWVsIFNsYXZpdGNoPGJyPg0KQ2M6IEhlbnJ5IFNpbm5yZWljaDsgUDJQ U0lQIE1haWxpbmcgTGlzdDsgTWljaGFlbCBIYW1tZXIgKG1oYW1tZXIpOyBE YXZpZCBSDQpPcmFuOyBwMnByZ0BpZXRmLm9yZzsgc2lwcGluZ0BpZXRmLm9y Zzsgemh1eGlhbjxicj4NClN1YmplY3Q6IFJlOiBbUDJQcmddIFJFOiBbU2lw cGluZ10gU2ltcGxlIFNJUCB1c2FnZSBzY2VuYXJpbzxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+TWljaGFlbCBTbGF2 aXRjaCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgU29ycnkgZm9yIGJlaW5nIGxhdGUgaW50byB0aGlzIGRp c2N1c3Npb24sIGJ1dA0KY2xpZW50LXNlcnZlciBiYXNlZCBWTSA8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgaXNuJ3Qg dHJ1bHkgY2xpZW50LXNlcnZlciBhbnltb3JlIGluIGFueXRoaW5nIGJ1dA0K dGhlIHNtYWxsZXN0IG9yIG1vc3QgPG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG1vbm9saXRoaWMgb2YgZW50ZXJwcmlz ZSBuZXR3b3JrcywgaW4gZmFjdCB0aGUNCnJlYWxpdHkgaXMgdGhhdCBtb3N0 IGlmIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyBub3QgYWxsIGVudGVycHJpc2UgbmV0d29ya3MgY29udGFpbiBqdXN0 IHBlZXJzIGFuZA0Kc3VwZXJwZWVycyB3aXRoIHRoZSA8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgZGlmZmVyZW5jZSBi ZWluZyBwYXJ0aWFsbHkgYSBtYXJrZXRpbmcgZGVjaXNpb24gYnkNCnRoZSB2 ZW5kb3JzLCBhcyB5b3UgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IGNhbiBjaGFyZ2UgbXVjaCBtb3JlIGZvciB0aGUg c2VydmVycywgYW5kIGEgcG9saWN5DQpkZWNpc2lvbiBtYWRlIGVpdGhlciA8 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg YXV0b21hdGljYWxseSBieSBhIHNvZnR3YXJlIGRlcGxveW1lbnQgc3lzdGVt IG9yIGJ5DQpJVCBzdGFmZiB3aGljaCB3YW50cyA8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgdG8gcGxhY2Ugc3VwZXJu b2RlcyB3aXRoIGRhdGEgc2lua3Mgb24gYXBwcm9wcmlhdGUNCmVxdWlwbWVu dC48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ SSdtIHNvcnJ5LCBidXQgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBwb2ludCB5 b3UgYXJlDQp0cnlpbmcgdG8gbWFrZSA8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PmFib3ZlLiBZb3UgYXJlIHRyeWluZyB0byBk cmF3IHNvbWUgc29ydCBvZiBkaXN0aW5jdGlvbiwNCmJ1dCBJIGRvbid0IGdl dCA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pml0 LiBDYW4geW91IHRyeSBhZ2Fpbi48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIFRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBQYXVsPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg SW4gYSA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgaGlnaGx5IGRpc3RyaWJ1dGVkIGVudmlyb25tZW50IHRoZXJlIGFy ZSBwb3RlbnRpYWxseQ0KaHVuZHJlZHMgb2YgPG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHBvc3NpYmxlIGRhdGEgc2lu a3MgZm9yIGEgZ2l2ZW4gYXBwbGljYXRpb24sIHdpdGgNCnRoZSBzaW5rIGJh c2VkIG9uIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRl eHQ+Jmd0OyBzdWJuZXQgb3IgZ2VvZ3JhcGhpYyBsb2NhdGlvbiBvciBiYWxh bmNlZCBsb2FkLCB0aGlzDQpjYW4gY2hhbmdlIHJhcGlkbHkgPG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IG92ZXIgdGlt ZSBhbmQgZG9lcy48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IEluIHRoZSBjYXNlIG9mIHRoZSBNaWNyb3NvZnQgZW52 aXJvbm1lbnQgc3VjaCBwb2xpY3kNCmlzIGFkbWluaXN0ZXJlZCBhbmQgPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHB1 Ymxpc2hlZCBiZXR3ZWVuIHN1cGVybm9kZXMsIGllIHNlcnZlcnMsIGJ5IEFj dGl2ZQ0KRGlyZWN0b3J5LsKgIEl0IGlzIDxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBhZHZlcnRpc2VkIHRvIG1lcmUg cGVlcnMgdGhyb3VnaCBETlMuwqAgVGhlcmUgd2FzDQptdWNoIGRpc2N1c3Np b24gYSB3aGlsZSA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgYWdvIGFib3V0IGJ1aWxkaW5nIHNlcnZpY2UgZGlzY292 ZXJ5IGVudmlyb25tZW50DQp1c2luZyBETlMgaW5zdGVhZCBvZiBhIDxvOnA+ PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBQMlAg REhULsKgIEl0IGNhbiBiZSBhcmd1ZWQgdGhhdCBhIGNhc2Ugc3R1ZHkgb2Yg YQ0KUDJQIGV4YW1wbGUgZG9uZSB1c2luZyA8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgRE5TIGlzIGFueSBsYXJnZSBX aW5kb3dzIFNlcnZlciAyMDAzIGJhc2VkIE1pY3Jvc29mdA0KbmV0d29yayB3 aXRoIG1hbnkgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IHNlcnZlcnMgYW5kIG1hbnkgbW9yZSBjbGllbnRzIHRoYXQg YWxzbyBydW4NCmFwcGxpY2F0aW9ucyB0aGVtc2VsdmVzIGFuZCA8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgYXJlIG5v dCBqdXN0IGR1bWIgdGVybWluYWxzLiBUaGlzIGlzIGFsbW9zdA0KY2VydGFp bmx5IGFsd2F5cyB0aGUgY2FzZSBpbiA8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgYWxsIGVudGVycHJpc2VzLiBUaGUg YmlnIGRpZmZlcmVuY2UgYmV0d2VlbiBDL1MgU0lQDQphbmQgUDJQU0lQIGlz IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyBhdXRvbWF0aW9uLiBXaGF0IGlzIHRydWUgaXMgdGhhdCB0aGUgc3F1YXJl IHBlZyBpbg0Kcm91bmQgaG9sZSBvZiA8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgb3ZlcmxvYWRpbmcgRE5TIG1ha2Vz IGRlcGxveW1lbnRzIGNsdW1zeSBhbmQgYnJpdHRsZQ0Kd2l0aGluIHRoZSA8 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg ZW50ZXJwcmlzZSBkb21haW4gYW5kIGNvbXBsZXRlbHkgdW5tYW5hZ2VhYmxl IGFuZA0KdW5wdWJsaXNoYWJsZSBvdXRzaWRlIDxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyB0aGUgZmlyZXdhbGwgd2hp Y2ggaXMgd2h5IHRoZSBidWNrIHN0b3BzIHRoZXJlIGluDQpjdXJyZW50IGVu dGVycHJpc2UgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IG5ldHdvcmtpbmcgcHJvZHVjdHMuPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBUaGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIEMvUyBhbmQgUDJQIGlzIGxhcmdlbHkgcG9saWN5DQphbmQg c2VtYW50aWNzIHdpdGggPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b1BsYWluVGV4dD4mZ3Q7IHRoZSBiaWdnZXN0IGRpZmZlcmVuY2UgYmVpbmcg dGhhdCB0aGUgZGVjaXNpb25zIGFuZA0KcnVsZXMgYXJlIGhpZ2hseSA8bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgZGlz dHJpYnV0ZWQuwqAgQXBhcnQgZnJvbSB0aGF0IHRoZXkgYXJlIG5vdCBqdXN0 DQpmcmllbmRzLCB0aGV5IGFyZSA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgZnJhdGVybmFsIHR3aW5zLjxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgUmVnYXJk czxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgTWljaGFlbCBTbGF2aXRjaDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDvCoCA8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBjb3JwXzJjb2xvdXIgPG86cD48 L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7ICZsdDto dHRwczovL2ZpcmV3YWxsLm9iamVjdHdvcmxkLmNvbS9leGNod2ViL2Jpbi9y ZWRpci5hc3A/VVJMPWh0dHA6Ly93d3cub2JqZWN0d29ybGQuY29tLyZndDs8 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 wqAgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgMzA4IExlZ2dldCBEci48 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg T3R0YXdhIE9udGFyaW88bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsgSzJLIDFZNiBDYW5hZGE8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0Ow0KJmx0O2h0dHBzOi8vZmlyZXdhbGwub2JqZWN0d29ybGQu Y29tL2V4Y2h3ZWIvYmluL3JlZGlyLmFzcD9VUkw9aHR0cDovL21hcHMuZ29v Z2xlLmNhL21hcHM/Zj1xJTI2aGw9ZW4lMjZxPTMwOCUyQkxlZ2dldCUyQkRy aXZlJTJCT3R0YXdhJTJCT250YXJpbyUyQksySyUyQjFZNiUyNmxheWVyPSUy NnNsbD00NS4zNDEwNjEsLTc1LjkwNDU0MSUyNnNzcG49MC4wMDcxMTksMC4w MjM4MzklMjZpZT1VVEY4JTI2ej0xOCUyNmxsPTQ1LjM0MTA2MSwtNzUuOTA0 NTQxJTI2c3BuPTAuMDAxNzgsMC4wMDU5NiUyNnQ9aCUyNm9tPTEmZ3Q7PG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvUGxhaW5UZXh0PiZndDvCoCA8bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IE1pY2hhZWwgU2xhdml0Y2jC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KDQo8 cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyBMZWFkLCBUZWNobm9sb2d5IElu aXRpYXRpdmVzPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFp blRleHQ+Jmd0OyBzbGF2aXRjaEBvYmplY3R3b3JsZC5jb20NCiZsdDttYWls dG86c2xhdml0Y2hAb2JqZWN0d29ybGQuY29tJmd0OzxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxh aW5UZXh0PiZndDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1Bs YWluVGV4dD4mZ3Q7IFBTVE46IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvUGxhaW5UZXh0PiZndDsgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsg PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7 ICsxLjg4OC4zOTguOTY5ODxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1N c29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9 TXNvUGxhaW5UZXh0PiZndDsgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86 cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IHgy MjU8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IEZheDo8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyArMS42MTMuNTk5 Ljc0NTc8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0 PiZndDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3A+ DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0O8KgIDxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgU2t5cGU6wqDC oMKgwqDCoCA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5U ZXh0PiZndDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD4mZ3Q7IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0O8KgwqAgT2JqZWN0 d29ybGQgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4 dD4mZ3Q7DQombHQ7aHR0cHM6Ly9maXJld2FsbC5vYmplY3R3b3JsZC5jb20v ZXhjaGFuZ2Uvc2xhdml0Y2gvU2VudCUyMEl0ZW1zL05vcnRlbCwlMjBNU0ZU JTIwY2hhc2UlMjBjYXJyaWVycyUyMHdpdGglMjBuZXclMjBob3N0ZWQlMjBv ZmZlcmluZyUyMGZvciUyMFNNRSUyMGFuZCUyME1NRS5FTUwvJmd0O8KgwqAN CjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0 OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZn dDsgPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyB4MjI1PG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Q bGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv UGxhaW5UZXh0PiZndDsNCiZsdDtodHRwczovL2ZpcmV3YWxsLm9iamVjdHdv cmxkLmNvbS9leGNoYW5nZS9zbGF2aXRjaC9TZW50JTIwSXRlbXMvTm9ydGVs LCUyME1TRlQlMjBjaGFzZSUyMGNhcnJpZXJzJTIwd2l0aCUyMG5ldyUyMGhv c3RlZCUyMG9mZmVyaW5nJTIwZm9yJTIwU01FJTIwYW5kJTIwTU1FLkVNTC8m Z3Q7PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+ Jmd0OyDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N Cg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDvCoCA8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PiZndDsgPG86cD48L286cD48 L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7wqAgPG86cD48L286 cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4mZ3Q7IDxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz cDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD4tLSA8bzpw PjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PkJFR0lOLUFO VElTUEFNLVZPVElORy1MSU5LUzxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29QbGFpblRleHQ+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvUGxhaW5UZXh0PlRlYWNoIENhbkl0IGlmIHRoaXMgbWFp bCAoSUQgNjU3ODA1KSBpcyBzcGFtOjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29QbGFpblRleHQ+U3BhbTrCoMKgwqDCoMKgwqDCoA0KaHR0cDov L2Nhbml0cHJvLWludC5vYmplY3R3b3JsZC5jb20vY2FuaXQvYi5waHA/aT02 NTc4MDUmYW1wO209MmViMWZkZWU1NWI3JmFtcDtjPXM8bzpwPjwvbzpwPjwv cD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pk5vdCBzcGFtOsKgwqDCoA0K aHR0cDovL2Nhbml0cHJvLWludC5vYmplY3R3b3JsZC5jb20vY2FuaXQvYi5w aHA/aT02NTc4MDUmYW1wO209MmViMWZkZWU1NWI3JmFtcDtjPW48bzpwPjwv bzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0PkZvcmdldCB2b3Rl OiBodHRwOi8vY2FuaXRwcm8taW50Lm9iamVjdHdvcmxkLmNvbS9jYW5pdC9i LnBocD9pPTY1NzgwNSZhbXA7bT0yZWIxZmRlZTU1YjcmYW1wO2M9ZjxvOnA+ PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD5FTkQt QU5USVNQQU0tVk9USU5HLUxJTktTPG86cD48L286cD48L3A+DQoNCjxwIGNs YXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxociB3aWR0aD0iMTAwJSI+DQo8Zm9udCBzaXplPSItMiI+PHA+ DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50 cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2 aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVk IGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUg cHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1h dGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBv dGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVt LiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVj aXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVs LjwvcD4NCg0KPHA+QW55IHZpZXdzLCBvcGluaW9ucyBhbmQgY29udGVudCBw cmVzZW50ZWQgaW4gdGhpcyBlLW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0 aGUgYXV0aG9yIGFuZCBtYXkgbm90IHJlcHJlc2VudCB0aG9zZSBvZiBPYmpl Y3R3b3JsZCBDb21tdW5pY2F0aW9ucyBDb3JwLjwvcD4NCjwvZm9udD4KPC9i b2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_002_01C775FF.19CEFDE7-- ------_=_NextPart_001_01C775FF.19CEFDE7 Content-Type: image/png; name="image003.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.png Content-Location: image003.png Content-Disposition: inline iVBORw0KGgoAAAANSUhEUgAAAB0AAAAdCAIAAADZ8fBYAAAAAXNSR0IArs4c 6QAABd1JREFUSEt1VklvHEUU7n2ZrT2Og2PHWRwnImLJIpEIIRkOHDgAQgoX Dkgc4IbIf0DcuXCKhMQv4A8gESlYxCQE4oCUjQSvM97G09PT02ttfDU9scdO KD3Z1d31vnr1ve+9GlUIobxoUC62IvrXRjq/lt7dSJpBPulZF444b0255444 h13d0FWMF/ripfo8LhfKakC/nW+tdMXscff8uD09atcsNcrZapAtbGY/L2Yn PfXq5ZGpmvV/6Adxo5z/sNCZW0k/fsWbPVEyVSWmKuUcIaREy5hyqKRYmvhl Jf7xfvDuSfuTV6sV29S0g4Hvw23F4rtbrbJtvzdT8Rytlwn2jKWYKA9abLMn KpY+4qpnRjVH59cXu5Tmn1+s1Us2KBmmZQ8XkX5zo3V6rHRuvIQAhOD0GfOG qmxEYskXo656YkTF9ssd4bnatCce7iTNTvzlpdqICydtF3qAy7n4+oaM9LWX yrqq7MSsauujzl4ERdyapmDS6LInvnyuO9pUTdxvJQpLv3qjalnWLrRWJPSn p70HLT7tuUs+m1smf2/xOw26FTEuBGHSIA8YnjuZCIlyqq6OV9TlgK4EAl53 NsRCI2RslzZF4hLKr93pvH2ish2LZshzxhnnnYxtRywmIuciYwPDI05zrKZW TKUd4yvHenjB99pCliQJ54CWR5G4txpJyqFGvRnSMKcZ431jqqYi3pxJI1wa JtBGRsVKlzaQM8GwHl7w3cz0+9sZIYT3xaOB2Zsr0bGa3U64n7GU8pRJyygL M54QRR5fiISIpQ77rZH+uU7ubpA/mnlMOT5hPbzgC4R7zV6e54gXA7hsfi1z Tb0V8zhnGeUZkYZdH+2Qe1vZZoi5mjPlaZs8bJHlDtnsUTA+WEmlF3yB8PuW gngxwARw+aNWisjbSZ4QLuPtG6gIUvq4lc+vxdcXo6UOcQxJ3E4MXJLQ/sn6 Bi/44tO9Fu+DYnDJb0wVENfL+nBDhkdkxk/5kza5u55ahnZ50j4+Yo5XzBEH FfYsAsrhCwSwAVyoQvKLf2OurH0KErE527OCaLxElUzW9LGSVrW1M4ess4fN ixPOpaNlaL2XU0m0EEA4Xh0UkuQX2C97IsyJqiHd4PegRYRiTdnUBFehM4gB lvZrEdtQBXMoRyKcrQzEMNDZ7FG9nTCIHkxJivcbxL4ZZbcb8VIgSRzIjkEn HIIpUg1fIFyYLKHeikLTdF0/P1n5t42vkIDM8m5CdieEKRu9/HEr8VNZUcBB VhshRQXHuYAXfIHwei0rQFH+En7GU9+fTPwcPCoZZP+c4Xg5B9EK0liU32pA fl3trvdyrkgv+AKhbgnTNBFov5NommkYV06pW0GMGjUAvV8VxSPI6WQEPQ8+ a0F+c6271SNoQlgPL/gCQUKZprxF5FTTbbSxo97VmR2/l6C9mpoKlJzuN8b9 hHZTFqbiiZ9thOgiAiuxHl7wnbBJqVQCbh9axqsahuG4pQ/Ojn5YbwZhD1lG k0Q3QC53Ow44RZmshvl6j7QiWaxYg5VYf2W08c5R07QdDLTKfrx9fg3DxKtS pfrZhfqnY0t+p6Pq+pRne7Ze3C9IYCEDIKK0bEOZGnGwBiux/qPTjm5a5XLZ dV0EW0hi0NcppVEUBRh++/Y/ze8XK0/Z4Wqt6lkqPiH7UJuuq46BrOhBLsJu OKNvfzHdOzdVN2ynXq/XajXg2rZT3HUDXJwLhQdo3/fDoBN0OnNr6dy62syd rl5NtCpTTV0Ql4c1Fk5a6eyEeHPCdFzXcVyAVioVxDt8X+zdb4BGdaM3I+hu txvHUZZlfphsxyyIElDhGJpXdg+5qudahgkRGdUqoqwhXQAtFHbwfiv0XEQN aIwwDBF+miZAZ5IH2U0kC7oG/SBMYAERA2EORzoojQO/S2SPQxXkOWgFepqm RUsd3AJ9hRYDqcYGfUSEue+S3+O32GR3FIEDC+iY4G+x/UDxmgYSihIYvtuH EV7wO2oYHWg4wIEzFQJ9PsZh3P8A9OAgCrvQHUQAAAAASUVORK5CYII= ------_=_NextPart_001_01C775FF.19CEFDE7 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.png Content-Location: image004.png Content-Disposition: inline iVBORw0KGgoAAAANSUhEUgAAABoAAAAaCAIAAAAmKNuZAAAAAXNSR0IArs4c 6QAAA0lJREFUSEutlVtIFFEYx3dm9uLu0qLrrlpmi0kpmilGJZRQQoTQS/kk JV0kCaoniQgiCro82UtvPQRSYC9dEay37pRFWGq0G2SKruyue9Hdud/6jyPj krOrgcuwzJxz5nf+3/f9vzOEqqqWtfuRa4fSSIShbiL99tX09Yn5dxgNePY2 l56vLjr0v5st4gAKpgYOVNz0FVQLSibO/noTvqVYZIKTkkRYUliPrbzYubW2 6HCjvzPPHhoOul5MXujY8oiWYqyUEGVGUNJ4Z14I62+KCpsRI3EuFGXGbJS7 bVNvLuEaru/nwZYNF51Wr8GSFYmTU7IqACTJHKfMiQqDR0Gm02J4lg02+U+1 BXqXy9RKgXx5HVWrYYkKTVooP1H1NXbvye8ucxxGJZXTY8yjCyxOnlM5nrGm 7aR7ZPZhMDnwD1FThzpGmNEVWTwdF6TMnspLokwLCo0XByd7THDwxIeZ2yRh N/LFSsnsfEEXWBDVWnGtztsOhNNaRJH2eX7q2+yDbKKmDmWCJ1L8HyQb4YC1 UAQt98ZSxWGBjXRWAVXosnphHdyPJR7/i9PczEn6qKoooOwo6cpmyaq4v/yq ztJ8ozKMlEAouI+yYyY4eFUfJUiSVNn1rsYm/0nYAhctRnaXnjWMNhy7nxEi uBAE1iNeExx8jzARBUXY+YVDYbOntcF3dDoz1Fx2ztAF1vPxM8v9YYwsHgFI BHZDvvCf5Mf1aVBO172vL+7QH01ZHsdGE3XoR2Rhih6Kc0FZ4SPsqL6o0BHI w8IUSmyCq/MeibMhZApZl1X+2Y8TBjGXLp0SoUeyzbwYbIPvGHob/SjIGZK3 ZKhEf6h9hhnOz8Isgv0YuWMIXDrvsMnT8W6voxIehPvhBpKw7SzpxtllJZ25 0u931kylP13ZpTUJfks4PKCrQ6nBMlc9QkZZDDPCwwRhNSVWuLZ9ifWb4/DC 4ETP93g/9oRpcikyxlEHLIuyo8drXpqo04cQNXpbUcUSZ63bVqpz0QPwc6Gj EsbUl9kpd6E98Dp8o72qL7CuJSdOn0Bvox9Rbt2GSDm0pPjJ7cUd6Bkb5UKP f47ebfR17iu/bFKKFUPThaOOxucJIEPXCupWQ1++Zo2/s38BXn9nvLoJMR4A AAAASUVORK5CYII= ------_=_NextPart_001_01C775FF.19CEFDE7 Content-Type: image/jpeg; name="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.jpg Content-Location: image005.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_001_01C775FF.19CEFDE7-- --===============1205255580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1205255580==-- From p2psip-bounces@ietf.org Tue Apr 03 13:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmTD-0000Lh-Vk; Tue, 03 Apr 2007 13:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmTC-0000Ch-3l; Tue, 03 Apr 2007 13:06:58 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmT7-0005gr-G6; Tue, 03 Apr 2007 13:06:58 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HYmSs-0007B4-Hs; Tue, 03 Apr 2007 12:06:43 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Paul Kyzivat'" Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Tue, 3 Apr 2007 13:06:38 -0400 Message-ID: <1bdd01c77612$7586dcd0$81238182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A903F@photon.objectworld.com> Thread-Index: Acd176Ya+p6xqIGMQfSJrn6cLV80rgACgCmQAAX8woA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: 485c16ccf4ca6ef309699ad6279bf354 Cc: 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" , 'David R Oran' , 'Henry Sinnreich' , p2prg@ietf.org, sipping@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0483108863==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0483108863== Content-Type: multipart/related; boundary="----=_NextPart_000_1BDE_01C775F0.EE753CD0" This is a multi-part message in MIME format. ------=_NextPart_000_1BDE_01C775F0.EE753CD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1BDF_01C775F0.EE82F870" ------=_NextPart_001_1BDF_01C775F0.EE82F870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think most enterprise "PBX" vendors will tell you that the things you can automate about provisioning have been automated, and you won't get much a win there. It's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. They didn't have to be (SIP was originally designed for smart endpoints). If we make P2PSIP endpoints more closely fit the smart endpoint model, then we make the peer that serves the UAs be the smart box in the middle of the network. Brian _____ From: Michael Slavitch [mailto:slavitch@objectworld.com] Sent: Tuesday, April 03, 2007 10:48 AM To: Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario The point I am making is that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as well as the mechanisms that make that deployment happen, are already very different world than the canonical IMS/CSSIP one which assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD), B2BUA demarks, network elements, and dumb fixed endpoints. Taking a network as a whole enterprise application software using C/S SIP proxies and UA's already approximates something that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, with gaping ugly holes. P2P has the potential to transform that. Some points I take from the previous discussion: "that a P2P setup will be *free*" - A P2P network may not be free, but the setup (provisioning) will be free, and automatic. This is a major benefit only partially achieved in enterprise networks, a benefit of great value to enterprises that is underserved by vendors. There is no benefit in requiring complex deployments where automation can take its place. Deployment is almost always the biggest cost of enterprise systems dwarfing the cost of the systems themselves. "I think this depends greatly on what expectations / contractual guarantees the enterprise has. It's unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees." - That is why 'expectations/contractual guarantees' need to be built into the automation that exists in the P2P overlay. Self-calculation of such performance metrics is already there in all enterprise devices, the difference being that while WMI/SNMP data is merely collected a P2PSIP network can act automatically based on the metrics within their own nodes, there is a collective 'aha' that forces behavior change based on strict contracts, aka rules. An SLA is easier to maintain if the objects can react accordingly, for example a node with degrading service can notify that it is on the decline forcing others to take over. There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or automation. P2PSIP allows for automation. David Oran wrote: "I'm not saying this can't be made to work, only that it isn't immediately obvious that it has advantages over a classic application/server approach." The immediately obvious advantage to me is standardized ruggedized automation that has economies of scale and operates over multiple domains, eliminating the need for over-engineering, detailed fussy provisioning, and an army of people doing basic monitoring and care-and-feeding. Automation is the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment. This is being done in fits and starts in the enterprise data center. P2PSIP makes it much more comprehensive. People want the world to be predictable and deterministic, and C/S based systems reflect that. That is the biggest problem P2P faces because it flies in the face of tradition. Regards Michael Slavitch corp_2colour 308 Legget Dr. Ottawa Ontario K2K 1Y6 Canada Michael Slavitch Lead, Technology Initiatives slavitch@objectworld.com PSTN: +1.888.398.9698 x225 Fax: +1.613.599.7457 Skype: Objectworld x225 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, April 03, 2007 8:57 AM To: Michael Slavitch Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Michael Slavitch wrote: > Sorry for being late into this discussion, but client-server based VM > isn't truly client-server anymore in anything but the smallest or most > monolithic of enterprise networks, in fact the reality is that most if > not all enterprise networks contain just peers and superpeers with the > difference being partially a marketing decision by the vendors, as you > can charge much more for the servers, and a policy decision made either > automatically by a software deployment system or by IT staff which wants > to place supernodes with data sinks on appropriate equipment. I'm sorry, but I don't understand the point you are trying to make above. You are trying to draw some sort of distinction, but I don't get it. Can you try again. Thanks, Paul > In a > highly distributed environment there are potentially hundreds of > possible data sinks for a given application, with the sink based on > subnet or geographic location or balanced load, this can change rapidly > over time and does. > > In the case of the Microsoft environment such policy is administered and > published between supernodes, ie servers, by Active Directory. It is > advertised to mere peers through DNS. There was much discussion a while > ago about building service discovery environment using DNS instead of a > P2P DHT. It can be argued that a case study of a P2P example done using > DNS is any large Windows Server 2003 based Microsoft network with many > servers and many more clients that also run applications themselves and > are not just dumb terminals. This is almost certainly always the case in > all enterprises. The big difference between C/S SIP and P2PSIP is > automation. What is true is that the square peg in round hole of > overloading DNS makes deployments clumsy and brittle within the > enterprise domain and completely unmanageable and unpublishable outside > the firewall which is why the buck stops there in current enterprise > networking products. > > The difference between C/S and P2P is largely policy and semantics with > the biggest difference being that the decisions and rules are highly > distributed. Apart from that they are not just friends, they are > fraternal twins. > > Regards > > Michael Slavitch > > > > > corp_2colour > > > > > > > 308 Legget Dr. > Ottawa Ontario > K2K 1Y6 Canada > > > > > > > > > > Michael Slavitch > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > PSTN: > > > > +1.888.398.9698 > > > > x225 > > Fax: > > > > +1.613.599.7457 > > > > > > Skype: > > > > Objectworld > > > > > > x225 > > > > > > > > > > > > -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 657805) is spam: Spam: http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=s Not spam: http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=n Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS _____ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ------=_NextPart_001_1BDF_01C775F0.EE82F870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think most enterprise = “PBX” vendors will tell you that the things you can automate about provisioning have been automated, and you won’t get much a win there.  It’s = things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, = and permissions, and feature enabling, etc, etc that dominate provisioning = of enterprise telephony systems.  P2P doesn’t help any of = that.

 

I worry, quite a bit, that = perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. =  They didn’t have to be (SIP was originally designed for smart endpoints).  If = we make P2PSIP endpoints more closely fit the smart endpoint model, then we make = the peer that serves the UAs be the smart box in the middle of the = network.

 

Brian

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 03, = 2007 10:48 AM
To: Paul Kyzivat
Cc: P2PSIP Mailing List; = Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org
Subject: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

The point I am making is  that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as = well as the mechanisms that make that = deployment happen, are already very different world than the canonical IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD),  B2BUA demarks, network elements, and dumb fixed endpoints.  Taking a network as a = whole enterprise application software using C/S SIP proxies and UA’s = already approximates something = that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, = with gaping ugly holes.  P2P has the potential to transform = that.

 

Some points I take from the previous = discussion:

“that a P2P setup will be *free*”

 

-       A P2P = network may not be free, but the setup (provisioning) will be free, and automatic.  This is a major benefit only partially achieved in = enterprise networks,  a benefit of great value to enterprises that is = underserved by vendors.  There is no benefit in requiring complex deployments = where automation can take its place.  Deployment is almost always the = biggest cost of enterprise systems dwarfing the cost of the systems = themselves.

 

“I think this depends greatly on what expectations / contractual guarantees = the enterprise has. It’s unclear to me what guarantees can be made = about a P2PSIP network will be able to make, and its unclear what kind of = infrastructure would be installed by/for someone willing to make = guarantees.”

 

-      That is why ‘expectations/contractual guarantees’ need to be built into = the automation that exists in the P2P overlay.  Self-calculation of such performance = metrics is already there in all enterprise devices, the difference being that = while WMI/SNMP data is merely collected a P2PSIP network can act automatically = based on the metrics within their own nodes, there is a collective = ‘aha’ that forces behavior change based on strict contracts, aka rules.  An = SLA is easier to maintain if the objects can = react accordingly, for example a node with degrading service can notify that = it is on the decline forcing others to take over. 

 

There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or  automation.  = P2PSIP allows for automation.

 

 David Oran wrote:

 

“I'm not saying this can't be made to work, only that it isn't immediately = obvious that it has advantages over a classic application/server = approach.”

 

The immediately obvious advantage to me is standardized ruggedized = automation that has economies of scale and operates over multiple domains, eliminating = the need for over-engineering,  detailed fussy provisioning,  and an = army of people doing basic monitoring and care-and-feeding.  Automation is = the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment.   This is being done in fits and starts in the enterprise data center.   P2PSIP makes it much more = comprehensive.   People want the world to be predictable and deterministic,  = and C/S based systems reflect that. That is the biggest problem P2P faces = because it flies in the face of tradition. =   

 

Regards

 

Michael Slavitch

 

 

 

 

 

3D"corp_2colour"

 

308 Legget = Dr.
Ottawa = Ontario
K2K 1Y6 Canada

<= /span>

 

Michael = Slavitch           = ;  

Lead, Technology Initiatives

slavitch@objectworld.com

PSTN: 

+1.888.398.9698

x225

Fax:

+1.613.599.7457

 

Skype:      

 Objectworld   =

x225

<= /span>

 

 

 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); = David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

 

 

Michael Slavitch wrote:

> Sorry for being late into this discussion, but client-server based VM =

> isn't truly client-server anymore in anything but the smallest or most =

> monolithic of enterprise networks, in fact the reality is that most if =

> not all enterprise networks contain just peers and superpeers with the =

> difference being partially a marketing decision by the vendors, as you =

> can charge much more for the servers, and a policy decision made either =

> automatically by a software deployment system or by IT staff which wants =

> to place supernodes with data sinks on appropriate = equipment.

 

I'm sorry, but I don't understand the point you are trying to make =

above. You are trying to draw some sort of distinction, but I don't get =

it. Can you try again.

 

       &nbs= p;        Thanks,

       &nbs= p;        Paul

 

> In a

> highly distributed environment there are potentially hundreds of =

> possible data sinks for a given application, with the sink based on =

> subnet or geographic location or balanced load, this can change rapidly =

> over time and does.

>

> In the case of the Microsoft environment such policy is administered and =

> published between supernodes, ie servers, by Active Directory.  It = is

> advertised to mere peers through DNS.  There was much discussion a = while

> ago about building service discovery environment using DNS instead of a =

> P2P DHT.  It can be argued that a case study of a P2P example done = using

> DNS is any large Windows Server 2003 based Microsoft network with many =

> servers and many more clients that also run applications themselves and =

> are not just dumb terminals. This is almost certainly always the case in =

> all enterprises. The big difference between C/S SIP and P2PSIP is =

> automation. What is true is that the square peg in round hole of =

> overloading DNS makes deployments clumsy and brittle within the =

> enterprise domain and completely unmanageable and unpublishable outside =

> the firewall which is why the buck stops there in current enterprise =

> networking products.

>

> The difference between C/S and P2P is largely policy and semantics with =

> the biggest difference being that the decisions and rules are highly =

> distributed.  Apart from that they are not just friends, they are =

> fraternal twins.

>

> Regards

>

> Michael Slavitch

>

> 

>

>

> corp_2colour

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://w= ww.objectworld.com/>

>

> 

>

>             =

>

> 308 Legget = Dr.

> Ottawa = Ontario

> K2K 1Y6 Canada

>

>             =

>

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://m= aps.google.ca/maps?f=3Dq%26hl=3Den%26q=3D308%2BLegget%2BDrive%2BOttawa%2B= Ontario%2BK2K%2B1Y6%26layer=3D%26sll=3D45.341061,-75.904541%26sspn=3D0.00= 7119,0.023839%26ie=3DUTF8%26z=3D18%26ll=3D45.341061,-75.904541%26spn=3D0.= 00178,0.00596%26t=3Dh%26om=3D1>

>

>             =

>

> 

>

> Michael Slavitch           = ; 

>

> Lead, Technology Initiatives

>

> slavitch@objectworld.com = <mailto:slavitch@objectworld.com>

>

>             =

>

> PSTN:

>

>             =

>

> +1.888.398.9698

>

>             =

>

> x225

>

> Fax:

>

>             =

>

> +1.613.599.7457

>

>             =

>

> 

>

> Skype:     

>

>             =

>

>   Objectworld

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Norte= l,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME= %20and%20MME.EML/>  

>

>

>             =

>

> x225

>

>             =

>

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Norte= l,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME= %20and%20MME.EML/>

>

>             =

>

> 

>

> 

>

>

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS<= /font>

----------------------------------------------= --------

 

Teach CanIt if this mail (ID 657805) is spam:

Spam:       = ; http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Ds

Not spam:    http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Dn

Forget vote: = http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Df

----------------------------------------------= --------

END-ANTISPAM-VOTING-LINKS

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of the = author and may not represent those of Objectworld Communications = Corp.

------=_NextPart_001_1BDF_01C775F0.EE82F870-- ------=_NextPart_000_1BDE_01C775F0.EE753CD0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6 +0EbNruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHExlWYK4wpGMhue leLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9clnAj17UWQKd3+kNjPb+tN/s+6bR 21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHN R/8AAlv8a9P8NWv/AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1U9W1W00TSrjU76Qx 29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GFE6eqnPpzXoHzp19FZniHXIPDmhXOr3Mc ksNsoZkjxuOSBxn61ieHPiLpniHVV0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc 3dpDNClvcvbMJQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq39uaT FqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jHGM/M3Psa2tC1uy8RaPb6 rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFreaPqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+ w3Vj5hYeRdJskXBxyKANGisRvFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6v RZpDhd+8n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA2fxg0W4n Tz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumtpPNA+Zh3GD0oA26KiuJltraW dgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPKt7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8 kKcE9M5IrD1H4h6Hpltazzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+ jtPI2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1LvgEhv5V4sNKivt c+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m1u7X7PGJ4vL+zRoFMe3J3YHY5x9a 1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej 3PAy/C1qWJTmmkt+vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLNd74l0OHxJ4evNInk MSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZrKOGLYFXGMse5wf/AK9ekfLl74p/8k31 j/rmv/oa1xfhqXUW+IHhl/E0MVuf7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5 C4YHp+Fc5oHgDVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu11WK/ m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYHA9OBQByXjWXV4fi9oj6F b29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRqZ0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xa WxgBkg8zqWycHjo1dFoNtq1ppaQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs 9CsdDjg8OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/gK2/CHhuL wn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ceFpvFmlWtlDdJbNBdpcFnUsCF B44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1 Lx54N/4TPT7K2FwsDWt0sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/ AJoeP+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6Wv+oH+7/SvnjT 59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrzofC+5XwYNFXUoReQ6l9vt7nyzhD6 YznpmgD0RFCIqDooArz34S/e8Uf9hmWvQk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2 gYsC2SMnOOOOKAO41X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689GHQ1lT+EdCuQBLYK2 CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgBumKworm4ESATyYCj+M0j3M5KZnk4bj5z Xjey97c+4WK/dr3e39bG/ChiiCEjIz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5 OW5+c+lCpbu45YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckxNyf9 9q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFAH//Z ------=_NextPart_000_1BDE_01C775F0.EE753CD0 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAdAB0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0/VNW WCU20cnllQPMkAyVz0A9/wCVUylrNEHWKOZjysk+XP5nmua1W8kXU7pZDg+e/wCW7A/TFPs9UmmU Wquq8fK3cf4168cNywTR5EsTzTakdDFqT2M20l2j6mMknI7lc8j6dK6GORJY1kjYMrDII7ivOruS eB0lklDljgHNdh4ald9Fi39iwX/dycfpiufFUVGKmjowtZyk4M5/xhoUzXDX9qhbf/rFA5z6j1rj o5pILhGIHytzzivZnRZFKsAQazptCspX3NGM/SnQx0qceWSuia+AjUnzxdmef2ttd61f5XcIQcBs cAe3qa9J0+1W0s44VGAqgAegotrC3th8ic+tWq56+IlWavokdFDDxop21b6n/9k= ------=_NextPart_000_1BDE_01C775F0.EE753CD0 Content-Type: image/jpeg; name="image004.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAaABoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1Ga7l kZ2SdokV2VQgXJwcEnIPcHpVSTW7uHqYHA7bCCfxz/Skuiv9qSwFtitMoA/3gMn8yab/AGWls8lx qTBbeE5HP+s/z6V4051nJ8j2ervov+AYty6GrpuqQ6lGxQFJE++hPT/EVdrjtEuvN8S+ZEuxJjIS Pbkj+Qrsa7MDiHXpcz3Tt6lwlzIyNa0hr7E8GPNAwy5xvHb8axbu31G6jSO6W5ZYRwPKbH1JAwTX Y0VFfAQqyck7X37MUqaZx2k6cf7QheCQMUcFipyFAPOfTjj8a7GiitcLhY4eLinuOMeVH//Z ------=_NextPart_000_1BDE_01C775F0.EE753CD0-- --===============0483108863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0483108863==-- From p2psip-bounces@ietf.org Tue Apr 03 13:58:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnH4-0005GB-Tf; Tue, 03 Apr 2007 13:58:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnH3-0005G0-05; Tue, 03 Apr 2007 13:58:29 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYnGt-00044l-6m; Tue, 03 Apr 2007 13:58:28 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l33Hw3KH026561; Tue, 3 Apr 2007 13:58:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 3 Apr 2007 13:58:02 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A907B@photon.objectworld.com> In-Reply-To: <1bdd01c77612$7586dcd0$81238182@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd176Ya+p6xqIGMQfSJrn6cLV80rgACgCmQAAX8woAAAZhX4A== References: <4E2DC1ACE541B94A946B8D8657E372C57A903F@photon.objectworld.com> <1bdd01c77612$7586dcd0$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Paul Kyzivat" X-Spam-Score: 1.50 (*) [Tag at 20.00] EXTRA_MPART_TYPE, HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.6 (/) X-Scan-Signature: e259f56175f28a8bef2b34d09ea68c34 Cc: P2PSIP Mailing List , "Michael Hammer \(mhammer\)" , David R Oran , Henry Sinnreich , p2prg@ietf.org, sipping@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1851873545==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1851873545== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C77619.9FFAEC5B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77619.9FFAEC5B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C77619.9FFAEC5B" ------_=_NextPart_002_01C77619.9FFAEC5B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline "vendors will tell you the things you can automate about provisioning have been automated." =20 The vendors will tell you this because the things that they automate can be summarized as: =20 1. "not much". 2. What we automate is our proprietary stuff, sod the rest. =20 t's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. =20 I strongly disagree with that. Look at the documentation for products from many of the major vendors, there are stacks of complex details regarding deployment, not very automatic at all, with many of them depending on crufty TFTP or FTP with fixed file locations for provisioning of endpoints. It's horrible. Secondly, "it doesn't help with any of that" is only true in a static fixed universe where you provision once and go away and limit functionality to very basic tasks. Even in that world the number of user change requests on a 2000 user system is on the order of .5%-1% of all endpoints per day on today's relatively static systems, 10 to 20 per day, and that's just basic stuff, done at gunpoint. Routers used to have only static routes too, and web pages were once coded by hand.=20=20= =20 =20 Regards =20 Michael =20 =20 =20 =20 =20 =09=09=20=09=20 Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com =09=09=20=09=20 =20 =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, April 03, 2007 1:07 PM To: Michael Slavitch; 'Paul Kyzivat' Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran'; 'Henry Sinnreich'; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 I think most enterprise "PBX" vendors will tell you that the things you can automate about provisioning have been automated, and you won't get much a win there. It's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. =20 I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. They didn't have to be (SIP was originally designed for smart endpoints). If we make P2PSIP endpoints more closely fit the smart endpoint model, then we make the peer that serves the UAs be the smart box in the middle of the network. =20 Brian =20 ________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Tuesday, April 03, 2007 10:48 AM To: Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 The point I am making is that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as well as the mechanisms that make that deployment happen, are already very different world than the canonical IMS/CSSIP one which assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD), B2BUA demarks, network elements, and dumb fixed endpoints. Taking a network as a whole enterprise application software using C/S SIP proxies and UA's already approximates something that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, with gaping ugly holes. P2P has the potential to transform that. =20 Some points I take from the previous discussion: "that a P2P setup will be *free*" =20 - A P2P network may not be free, but the setup (provisioning) will be free, and automatic. This is a major benefit only partially achieved in enterprise networks, a benefit of great value to enterprises that is underserved by vendors. There is no benefit in requiring complex deployments where automation can take its place. Deployment is almost always the biggest cost of enterprise systems dwarfing the cost of the systems themselves. =20 "I think this depends greatly on what expectations / contractual guarantees the enterprise has. It's unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees." =20 - That is why 'expectations/contractual guarantees' need to be built into the automation that exists in the P2P overlay. Self-calculation of such performance metrics is already there in all enterprise devices, the difference being that while WMI/SNMP data is merely collected a P2PSIP network can act automatically based on the metrics within their own nodes, there is a collective 'aha' that forces behavior change based on strict contracts, aka rules. An SLA is easier to maintain if the objects can react accordingly, for example a node with degrading service can notify that it is on the decline forcing others to take over.=20=20 =20 There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or automation. P2PSIP allows for automation. =20 David Oran wrote: =20 "I'm not saying this can't be made to work, only that it isn't immediately obvious that it has advantages over a classic application/server approach." =20 The immediately obvious advantage to me is standardized ruggedized automation that has economies of scale and operates over multiple domains, eliminating the need for over-engineering, detailed fussy provisioning, and an army of people doing basic monitoring and care-and-feeding. Automation is the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment. This is being done in fits and starts in the enterprise data center. P2PSIP makes it much more comprehensive. People want the world to be predictable and deterministic, and C/S based systems reflect that. That is the biggest problem P2P faces because it flies in the face of tradition.=20=20=20 =20 Regards =20 Michael Slavitch =20 =20 =20 =20 =20 =20 =20 308 Legget Dr.=20 Ottawa Ontario=20 K2K 1Y6 Canada =20 =20 =20 Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com PSTN:=20=20 +1.888.398.9698 x225 Fax: +1.613.599.7457 =20 Skype:=20=20=20=20=20=20=20 Objectworld=20=20=20 x225 =20 =20 =20 =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, April 03, 2007 8:57 AM To: Michael Slavitch Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 =20 =20 Michael Slavitch wrote: > Sorry for being late into this discussion, but client-server based VM=20 > isn't truly client-server anymore in anything but the smallest or most > monolithic of enterprise networks, in fact the reality is that most if > not all enterprise networks contain just peers and superpeers with the > difference being partially a marketing decision by the vendors, as you > can charge much more for the servers, and a policy decision made either=20 > automatically by a software deployment system or by IT staff which wants=20 > to place supernodes with data sinks on appropriate equipment. =20 I'm sorry, but I don't understand the point you are trying to make=20 above. You are trying to draw some sort of distinction, but I don't get=20 it. Can you try again. =20 Thanks, Paul =20 > In a=20 > highly distributed environment there are potentially hundreds of=20 > possible data sinks for a given application, with the sink based on=20 > subnet or geographic location or balanced load, this can change rapidly=20 > over time and does. >=20 > In the case of the Microsoft environment such policy is administered and=20 > published between supernodes, ie servers, by Active Directory. It is=20 > advertised to mere peers through DNS. There was much discussion a while=20 > ago about building service discovery environment using DNS instead of a=20 > P2P DHT. It can be argued that a case study of a P2P example done using=20 > DNS is any large Windows Server 2003 based Microsoft network with many > servers and many more clients that also run applications themselves and=20 > are not just dumb terminals. This is almost certainly always the case in=20 > all enterprises. The big difference between C/S SIP and P2PSIP is=20 > automation. What is true is that the square peg in round hole of=20 > overloading DNS makes deployments clumsy and brittle within the=20 > enterprise domain and completely unmanageable and unpublishable outside=20 > the firewall which is why the buck stops there in current enterprise=20 > networking products. >=20 > The difference between C/S and P2P is largely policy and semantics with=20 > the biggest difference being that the decisions and rules are highly=20 > distributed. Apart from that they are not just friends, they are=20 > fraternal twins. >=20 > Regards >=20 > Michael Slavitch >=20 >=20=20 >=20 >=20 > corp_2colour=20 > >=20 >=20=20 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > 308 Legget Dr. > Ottawa Ontario > K2K 1Y6 Canada >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 >=20=20 >=20 > Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > Lead, Technology Initiatives >=20 > slavitch@objectworld.com >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > PSTN:=20 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > +1.888.398.9698 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > x225 >=20 > Fax: >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > +1.613.599.7457 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 >=20=20 >=20 > Skype:=20=20=20=20=20=20 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > Objectworld=20 > =20=20=20 >=20 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > x225 >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > >=20 >=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 >=20=20 >=20 >=20=20 >=20 >=20 =20 =20 --=20 =20 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ________________________________ Spam =20 Not spam =20 Forget previous vote =20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_002_01C77619.9FFAEC5B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

“vendors will tell you t= he things you can automate about provisioning have been automated.”

 

The vendors will tell you = this because the things that they automate can be summarized as:

 

1.       “not much&= #8221;.

2.       What we automate= is our proprietary stuff, sod the rest.

 

t’s things like TN assignment, and dial plans, and gatewa= y routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems.  P2P doesn’t help any of that.

 

I strongly disagree with t= hat.   Look at the documentation for products from many of the major vendors, there are stacks of complex details regarding deployment,  not very automatic at= all, with many of them depending on crufty TFTP or FTP with fixed file locations= for provisioning of endpoints.  It’s horrible.

Secondly, “it doesn&= #8217;t help with any of that” is only true in a static fixed universe where you provis= ion once and go away and limit functionality to very basic tasks.   Even i= n that world the number of user change requests on a 2000 user system is on the order of .5%= -1% of all endpoints per day on today’s relatively static systems, 10 to = 20 per day, and that’s just basic stuff, done at gunpoint.  Routers use= d to have only static routes too, and web pages were once coded by hand.   <= /span>

 

Regards<= /p>

 

Michael<= /p>

 

 

 =

3D"corp_2colour"

 =

 

Michael Slavitch          &nb= sp;  

Lead, Technology Initi= atives

slavitch@objectworld.c= om

 

=  

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, April 03, 2007 1:07 PM
To: Michael Slavitch; 'Paul Kyzivat'
Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran= '; 'Henry Sinnreich'; p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

I think most enterprise “PBX” vendors will tell you= that the things you can automate about provisioning have been automated, and you won’= t get much a win there.  It’s things like TN assignment, and dial plans, an= d gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony syste= ms.  P2P doesn’t help any of that.

 

I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are ma= de now is that they are dumb endpoints.  They didn’t have to be (SI= P was originally designed for smart endpoints).  If we make P2PSIP endpoints more closely fit the smart endpoint model, then we make the peer that serves the UAs be the smart box in the middle of the network.

 

Brian

 

From: Michael Slavi= tch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 03, 2007 10:48 AM
To: Paul Kyzivat
Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Hen= ry Sinnreich; p2prg@ietf.org; sipping@ietf.org
Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenari= o

 

The point I am making is  that in the enterpri= se the actual topological deployments of SIP clients and servers, when implemen= ted as software on generic computing platforms, as well as the mechanisms that make that deployment happen, are already very different world than= the canonical IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD),  B2BUA demar= ks, network elements, and dumb fixed endpoints.  Taking a network as a who= le enterprise application software using C/S SIP proxies and UA’s alr= eady approximates something that is close to what is being called P2PSIP, only i= n a manner that is highly proprietary, closed, somewhat brittle and baroque, lo= cal, and ad-hoc, with gaping ugly holes.  P2P has the potential to transform that.

 

Some points I take f= rom the previous discussion:

“that a P2P setup will be *free*”<= /o:p>

 

-&nb= sp;          A P2P network may not be free, but the setup (provisioning) will be free, and automatic.  This is a major benefit o= nly partially achieved in enterprise networks,  a benefit of great value to enterprises that is underserved by vendors.  There is no benefit in requiring complex deployments where automation can take its place.  Deployment is almost always the biggest cost of enterprise systems dwarfing= the cost of the systems themselves.

 

“I think this depends greatly on what expecta= tions / contractual guarantees the enterprise has. It’s unclear to me what gu= arantees can be made about a P2PSIP network will be able to make, and its unclear wh= at kind of infrastructure would be installed by/for someone willing to make guarantees.”

 

-&nb= sp;         That is why ‘expectations/contractual guarant= ees’ need to be built into the automation that exists in the P2P overlay.  Self-calculation of such performance metrics is already there in all enterp= rise devices, the difference being that while WMI/SNMP data is merely collected a P2PSIP network can act automatically based on the metrics within their own nodes, there is a collective ‘aha’ that forces behavior change = based on strict contracts, aka rules.  An SLA is ea= sier to maintain if the objects can react accordingly, for example a node with degrading service can notify that it is on the decline forcing others to ta= ke over. 

 

There is an old traffic engineering axiom about ser= vice guarantees: it can be achieved through two ways: over engineering or  automation.  P2PSIP allows for automation.

 

 David Oran wrote:

 

“I'm not saying this can't be made to work, o= nly that it isn't immediately obvious that it has advantages over a classic application/server approach.”

 

The immediately obvious advantage to me is standard= ized ruggedized automation that has economies of scale and operates over multiple domains, eliminating the need for over-engineering,  detailed fussy provisioning,  and an army of people doing basic monitoring and care-and-feeding.  Automation is the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over ti= me given a fractal operating environment.   This is being done in fi= ts and starts in the enterprise data center.   P2PSIP makes it much = more comprehensive.   People want the world to be predictable and deterministic,  and C/S based systems reflect that. That is the biggest problem P2P faces because it flies in the face of tradition.   

 

Regards

 

Michael Slavitch

 

 

 

 

 

3D"corp_2colour"

 

308= Legget Dr.
Ottawa Ontario
K2K 1Y6 Canada

<= /span>

 

Michael Slavitch          &nb= sp;  

Lead, Technology Initiatives

slavitch@objectworld.com

PSTN: 

+1.888.398.9698

x225

Fax:

+1.613.599.7457

 

Skype:      

 Objectworld  

x225

<= /span>

 

 

 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian
Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

 

 

Michael Slavitch wrote:

> Sorry for being late into this discussion, but client-server based VM

> isn't truly client-server anymore in anything = but the smallest or most

> monolithic of enterprise networks, in fact the reality is that most if

> not all enterprise networks contain just peers= and superpeers with the

> difference being partially a marketing decisio= n by the vendors, as you

> can charge much more for the servers, and a po= licy decision made either

> automatically by a software deployment system = or by IT staff which wants

> to place supernodes with data sinks on appropr= iate equipment.

 

I'm sorry, but I don't understand the point you are trying to make

above. You are trying to draw some sort of distinct= ion, but I don't get

it. Can you try again.

 

        &nb= sp;       Thanks,

        &nb= sp;       Paul

 

> In a

> highly distributed environment there are poten= tially hundreds of

> possible data sinks for a given application, w= ith the sink based on

> subnet or geographic location or balanced load= , this can change rapidly

> over time and does.

>

> In the case of the Microsoft environment such = policy is administered and

> published between supernodes, ie servers, by A= ctive Directory.  It is

> advertised to mere peers through DNS.  Th= ere was much discussion a while

> ago about building service discovery environme= nt using DNS instead of a

> P2P DHT.  It can be argued that a case st= udy of a P2P example done using

> DNS is any large Windows Server 2003 based Mic= rosoft network with many

> servers and many more clients that also run applications themselves and

> are not just dumb terminals. This is almost certainly always the case in

> all enterprises. The big difference between C/= S SIP and P2PSIP is

> automation. What is true is that the square pe= g in round hole of

> overloading DNS makes deployments clumsy and b= rittle within the

> enterprise domain and completely unmanageable = and unpublishable outside

> the firewall which is why the buck stops there= in current enterprise

> networking products.

>

> The difference between C/S and P2P is largely = policy and semantics with

> the biggest difference being that the decision= s and rules are highly

> distributed.  Apart from that they are no= t just friends, they are

> fraternal twins.

>

> Regards

>

> Michael Slavitch

>

> 

>

>

> corp_2colour

> <https://firewall.objectworld.com/exchweb/b= in/redir.asp?URL=3Dhttp://www.objectworld.com/>

>

> 

>

>            

>

> 308 Legget Dr.

> O= ttawa Ontario

> K2K 1Y6 Canada

>

>            

>

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://map= s.google.ca/maps?f=3Dq%26hl=3Den%26q=3D308%2BLegget%2BDrive%2BOttawa%2BOnta= rio%2BK2K%2B1Y6%26layer=3D%26sll=3D45.341061,-75.904541%26sspn=3D0.007119,0= .023839%26ie=3DUTF8%26z=3D18%26ll=3D45.341061,-75.904541%26spn=3D0.00178,0.= 00596%26t=3Dh%26om=3D1>

>

>            

>

> 

>

> Michael Slavitch           &= nbsp;

>

> Lead, Technology Initiatives

>

> slavitch@objectworld.com <mailto:slavitch@objectworld.com>

>

>            

>

> PSTN:

>

>            

>

> +1.888.398.9698

>

>            

>

> x225

>

> Fax:

>

>            

>

> +1.613.599.7457

>

>        &nbs= p;   

>

> 

>

> Skype:     

>

>            

>

>   Objectworld

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,= %20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%20a= nd%20MME.EML/>  

>

>

>            

>

> x225

>

>            

>

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Nortel,= %20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME%20a= nd%20MME.EML/>

>

>            

>

> 

>

> 

>

>

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS

---------------------------------------------------= ---

 

Teach CanIt if this mail (ID 657805) is spam:<= /o:p>

Spam:        http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fdee= 55b7&c=3Ds

Not spam:    http://canitpro-int.obj= ectworld.com/canit/b.php?i=3D657805&m=3D2eb1fdee55b7&c=3Dn

Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fdee= 55b7&c=3Df

---------------------------------------------------= ---

END-ANTISPAM-VOTING-LINKS

 

This transmission (including any attachm= ents) may contain confidential information, privileged material (including materi= al protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone ot= her than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete th= is information from your system. Use, dissemination, distribution, or reproduc= tion of this transmission by unintended recipients is not authorized and may be unlawful.

Any views, opinions and content presente= d in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_002_01C77619.9FFAEC5B-- ------_=_NextPart_001_01C77619.9FFAEC5B Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_001_01C77619.9FFAEC5B Content-Type: image/jpeg; name="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.jpg Content-Location: image005.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_001_01C77619.9FFAEC5B Content-Type: image/jpeg; name="image006.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image006.jpg Content-Location: image006.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAdAB0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0/VNWWCU2 0cnllQPMkAyVz0A9/wCVUylrNEHWKOZjysk+XP5nmua1W8kXU7pZDg+e/wCW 7A/TFPs9UmmUWquq8fK3cf4168cNywTR5EsTzTakdDFqT2M20l2j6mMknI7l c8j6dK6GORJY1kjYMrDII7ivOruSeB0lklDljgHNdh4ald9Fi39iwX/dycfp iufFUVGKmjowtZyk4M5/xhoUzXDX9qhbf/rFA5z6j1rjo5pILhGIHytzzivZ nRZFKsAQazptCspX3NGM/SnQx0qceWSuia+AjUnzxdmef2ttd61f5XcIQcBs cAe3qa9J0+1W0s44VGAqgAegotrC3th8ic+tWq56+IlWavokdFDDxop21b6n /9k= ------_=_NextPart_001_01C77619.9FFAEC5B Content-Type: image/jpeg; name="image007.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image007.jpg Content-Location: image007.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAaABoDASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1Ga7lkZ2S dokV2VQgXJwcEnIPcHpVSTW7uHqYHA7bCCfxz/Skuiv9qSwFtitMoA/3gMn8 yab/AGWls8lxqTBbeE5HP+s/z6V4051nJ8j2ervov+AYty6GrpuqQ6lGxQFJ E++hPT/EVdrjtEuvN8S+ZEuxJjISPbkj+Qrsa7MDiHXpcz3Tt6lwlzIyNa0h r7E8GPNAwy5xvHb8axbu31G6jSO6W5ZYRwPKbH1JAwTXY0VFfAQqyck7X37M UqaZx2k6cf7QheCQMUcFipyFAPOfTjj8a7GiitcLhY4eLinuOMeVH//Z ------_=_NextPart_001_01C77619.9FFAEC5B-- --===============1851873545== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1851873545==-- From p2psip-bounces@ietf.org Tue Apr 03 17:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqwP-0004t7-BB; Tue, 03 Apr 2007 17:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqwO-0004sm-57; Tue, 03 Apr 2007 17:53:24 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYqwK-0005rF-MM; Tue, 03 Apr 2007 17:53:24 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 03 Apr 2007 14:53:10 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l33LqUD1021567; Tue, 3 Apr 2007 14:52:35 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l33Lqt0c028564; Tue, 3 Apr 2007 14:52:56 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 14:52:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Tue, 3 Apr 2007 14:52:47 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF2F@namail5.corp.adobe.com> In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A907B@photon.objectworld.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd176Ya+p6xqIGMQfSJrn6cLV80rgACgCmQAAX8woAAAZhX4AAHz3sg References: <4E2DC1ACE541B94A946B8D8657E372C57A903F@photon.objectworld.com> <1bdd01c77612$7586dcd0$81238182@cis.neustar.com> <4E2DC1ACE541B94A946B8D8657E372C57A907B@photon.objectworld.com> From: "Henry Sinnreich" To: "Michael Slavitch" , "Brian Rosen" , "Paul Kyzivat" X-OriginalArrivalTime: 03 Apr 2007 21:52:54.0858 (UTC) FILETIME=[6F2A6AA0:01C7763A] X-Spam-Score: 1.4 (+) X-Scan-Signature: b20610989b0325858c8c5a1f4b6a50a0 Cc: sipping@ietf.org, p2prg@ietf.org, David R Oran , P2PSIP Mailing List , "Michael Hammer \(mhammer\)" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0058665474==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0058665474== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7763A.6DADE46E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7763A.6DADE46E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7763A.6DADE46E" ------_=_NextPart_002_01C7763A.6DADE46E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Michael here. The voice-only PBX is pathetic as an enterprise communication and productivity platform (no presence, IM, no integration with apps, etc.) is also exactly the opposite of what self organizing systems provide. As for the usability of those tiny screens and remembering the various commands... Why not just use Skype PC clients or Skype phones instead? At least, they are WiFi and no configuration is required that cannot be done by the user. And they can be used on travel as well. =20 Just think what self organizing and usability means for the maintenance headcount and budget. Not to mention the associated IT systems. =20 P2P SIP in the enterprise is not a PBX replacement any more that SIP is a PSTN replacement, though many decisions makers have not given up :-) =20 Thanks, Henry =20 ________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Tuesday, April 03, 2007 12:58 PM To: Brian Rosen; Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 "vendors will tell you the things you can automate about provisioning have been automated." =20 The vendors will tell you this because the things that they automate can be summarized as: =20 1. "not much". 2. What we automate is our proprietary stuff, sod the rest. =20 t's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. =20 I strongly disagree with that. Look at the documentation for products from many of the major vendors, there are stacks of complex details regarding deployment, not very automatic at all, with many of them depending on crufty TFTP or FTP with fixed file locations for provisioning of endpoints. It's horrible. Secondly, "it doesn't help with any of that" is only true in a static fixed universe where you provision once and go away and limit functionality to very basic tasks. Even in that world the number of user change requests on a 2000 user system is on the order of .5%-1% of all endpoints per day on today's relatively static systems, 10 to 20 per day, and that's just basic stuff, done at gunpoint. Routers used to have only static routes too, and web pages were once coded by hand. =20 =20 Regards =20 Michael =20 =20 =20 =20 =20 =20 =20 =20 Michael Slavitch =20 Lead, Technology Initiatives slavitch@objectworld.com =20 =20 =20 =20 =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, April 03, 2007 1:07 PM To: Michael Slavitch; 'Paul Kyzivat' Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran'; 'Henry Sinnreich'; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 I think most enterprise "PBX" vendors will tell you that the things you can automate about provisioning have been automated, and you won't get much a win there. It's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. =20 I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. They didn't have to be (SIP was originally designed for smart endpoints). If we make P2PSIP endpoints more closely fit the smart endpoint model, then we make the peer that serves the UAs be the smart box in the middle of the network. =20 Brian =20 ________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Tuesday, April 03, 2007 10:48 AM To: Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 The point I am making is that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as well as the mechanisms that make that deployment happen, are already very different world than the canonical IMS/CSSIP one which assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD), B2BUA demarks, network elements, and dumb fixed endpoints. Taking a network as a whole enterprise application software using C/S SIP proxies and UA's already approximates something that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, with gaping ugly holes. P2P has the potential to transform that. =20 Some points I take from the previous discussion: "that a P2P setup will be *free*" =20 - A P2P network may not be free, but the setup (provisioning) will be free, and automatic. This is a major benefit only partially achieved in enterprise networks, a benefit of great value to enterprises that is underserved by vendors. There is no benefit in requiring complex deployments where automation can take its place. Deployment is almost always the biggest cost of enterprise systems dwarfing the cost of the systems themselves. =20 "I think this depends greatly on what expectations / contractual guarantees the enterprise has. It's unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees." =20 - That is why 'expectations/contractual guarantees' need to be built into the automation that exists in the P2P overlay. Self-calculation of such performance metrics is already there in all enterprise devices, the difference being that while WMI/SNMP data is merely collected a P2PSIP network can act automatically based on the metrics within their own nodes, there is a collective 'aha' that forces behavior change based on strict contracts, aka rules. An SLA is easier to maintain if the objects can react accordingly, for example a node with degrading service can notify that it is on the decline forcing others to take over. =20 =20 There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or automation. P2PSIP allows for automation. =20 David Oran wrote: =20 "I'm not saying this can't be made to work, only that it isn't immediately obvious that it has advantages over a classic application/server approach." =20 The immediately obvious advantage to me is standardized ruggedized automation that has economies of scale and operates over multiple domains, eliminating the need for over-engineering, detailed fussy provisioning, and an army of people doing basic monitoring and care-and-feeding. Automation is the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment. This is being done in fits and starts in the enterprise data center. P2PSIP makes it much more comprehensive. People want the world to be predictable and deterministic, and C/S based systems reflect that. That is the biggest problem P2P faces because it flies in the face of tradition. =20 =20 Regards =20 Michael Slavitch =20 =20 =20 =20 =20 =20 =20 308 Legget Dr.=20 Ottawa Ontario=20 K2K 1Y6 Canada =20 =20 =20 Michael Slavitch =20 Lead, Technology Initiatives slavitch@objectworld.com PSTN: =20 +1.888.398.9698 x225 Fax: +1.613.599.7457 =20 Skype: =20 Objectworld =20 x225 =20 =20 =20 =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, April 03, 2007 8:57 AM To: Michael Slavitch Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 =20 =20 Michael Slavitch wrote: > Sorry for being late into this discussion, but client-server based VM=20 > isn't truly client-server anymore in anything but the smallest or most > monolithic of enterprise networks, in fact the reality is that most if > not all enterprise networks contain just peers and superpeers with the > difference being partially a marketing decision by the vendors, as you > can charge much more for the servers, and a policy decision made either=20 > automatically by a software deployment system or by IT staff which wants=20 > to place supernodes with data sinks on appropriate equipment. =20 I'm sorry, but I don't understand the point you are trying to make=20 above. You are trying to draw some sort of distinction, but I don't get=20 it. Can you try again. =20 Thanks, Paul =20 > In a=20 > highly distributed environment there are potentially hundreds of=20 > possible data sinks for a given application, with the sink based on=20 > subnet or geographic location or balanced load, this can change rapidly=20 > over time and does. >=20 > In the case of the Microsoft environment such policy is administered and=20 > published between supernodes, ie servers, by Active Directory. It is=20 > advertised to mere peers through DNS. There was much discussion a while=20 > ago about building service discovery environment using DNS instead of a=20 > P2P DHT. It can be argued that a case study of a P2P example done using=20 > DNS is any large Windows Server 2003 based Microsoft network with many > servers and many more clients that also run applications themselves and=20 > are not just dumb terminals. This is almost certainly always the case in=20 > all enterprises. The big difference between C/S SIP and P2PSIP is=20 > automation. What is true is that the square peg in round hole of=20 > overloading DNS makes deployments clumsy and brittle within the=20 > enterprise domain and completely unmanageable and unpublishable outside=20 > the firewall which is why the buck stops there in current enterprise=20 > networking products. >=20 > The difference between C/S and P2P is largely policy and semantics with=20 > the biggest difference being that the decisions and rules are highly=20 > distributed. Apart from that they are not just friends, they are=20 > fraternal twins. >=20 > Regards >=20 > Michael Slavitch >=20 > =20 >=20 >=20 > corp_2colour=20 > >=20 > =20 >=20 > =20 >=20 > 308 Legget Dr. > Ottawa Ontario > K2K 1Y6 Canada >=20 > =20 >=20 > >=20 > =20 >=20 > =20 >=20 > Michael Slavitch =20 >=20 > Lead, Technology Initiatives >=20 > slavitch@objectworld.com >=20 > =20 >=20 > PSTN:=20 >=20 > =20 >=20 > +1.888.398.9698 >=20 > =20 >=20 > x225 >=20 > Fax: >=20 > =20 >=20 > +1.613.599.7457 >=20 > =20 >=20 > =20 >=20 > Skype: =20 >=20 > =20 >=20 > Objectworld=20 > =20 >=20 >=20 > =20 >=20 > x225 >=20 > =20 >=20 > >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 =20 =20 --=20 BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ =20 Teach CanIt if this mail (ID 657805) is spam: Spam: http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fdee55= b7& c=3Ds Not spam: http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fdee55= b7& c=3Dn Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fdee55= b7& c=3Df ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS =20 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ________________________________ Spam =20 Not spam =20 Forget previous vote =20 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ------_=_NextPart_002_01C7763A.6DADE46E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Michael here. The = voice-only PBX is pathetic as an enterprise communication and productivity platform = (no presence, IM, no integration with apps, etc.) is also exactly the = opposite of what self organizing = systems provide. As for the usability of those tiny screens and remembering the = various commands…

Why not just use Skype PC clients = or Skype phones instead? At least, they are WiFi and no configuration is required = that cannot be done by the user. And they can be used on travel as = well.

 

Just think what self = organizing and usability means for the = maintenance headcount and budget. Not to mention the associated IT = systems.

 

P2P SIP in the enterprise is not a = PBX replacement any more that SIP is a PSTN replacement, though many = decisions makers have not given up J

 

Thanks, = Henry

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 03, = 2007 12:58 PM
To: Brian Rosen; Paul Kyzivat
Cc: P2PSIP Mailing List; = Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

“vendors will tell you the things you can automate about provisioning have been automated.”

 

The vendors will tell you this = because the things that they automate can be summarized = as:

 

1.      = “not = much”.

2.      = What we automate is our = proprietary stuff, sod the rest.

 

t’s things like TN = assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems.  P2P = doesn’t help any of that.

 

I strongly disagree with that. =   Look at the documentation for products from many of the major vendors, there = are stacks of complex details regarding deployment,  not very automatic = at all, with many of them depending on crufty TFTP or FTP with fixed file locations for provisioning of endpoints.  It’s = horrible.

Secondly, “it doesn’t = help with any of that” is only true in a static fixed universe where = you provision once and go away and limit functionality to very basic = tasks.   Even in that world the number of user change requests on a 2000 user system = is on the order of .5%-1% of all endpoints per day on today’s relatively = static systems, 10 to 20 per day, and that’s just basic stuff, done at = gunpoint.  Routers used to have only static routes too, and web pages were once = coded by hand.  

 

Regards

 

Michael

 

 

 

3D"corp_2colour"

 

 

 

 

Michael = Slavitch           = ;  

Lead, Technology = Initiatives

slavitch@objectworld.com

 

 

 

 

 

From: = Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, April 03, = 2007 1:07 PM
To: Michael Slavitch; = 'Paul Kyzivat'
Cc: 'P2PSIP Mailing = List'; 'Michael Hammer (mhammer)'; 'David R Oran'; 'Henry Sinnreich'; = p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

I think most enterprise = “PBX” vendors will tell you that the things you can automate about = provisioning have been automated, and you won’t get much a win there. =  It’s things like TN assignment, and dial plans, and gateway routing, and = emergency call provisioning, and permissions, = and feature enabling, etc, etc that dominate provisioning of enterprise = telephony systems.  P2P doesn’t help any of = that.

 

I worry, quite a bit, that = perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. =  They didn’t have to be (SIP was originally designed for smart = endpoints).  If we make P2PSIP endpoints more closely fit the smart endpoint model, = then we make the peer that serves the UAs be the smart box in the middle of the network.

 

Brian

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 03, = 2007 10:48 AM
To: Paul Kyzivat
Cc: P2PSIP Mailing List; = Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org
Subject: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

The point I am making is  that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as = well as the mechanisms that make that = deployment happen, are already very different world than the canonical IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD),  B2BUA demarks, network elements, and dumb fixed endpoints.  Taking a network as a = whole enterprise application software using C/S SIP proxies and UA’s = already approximates something = that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, = with gaping ugly holes.  P2P has the potential to transform = that.

 

Some points I take from the previous = discussion:

“that a P2P setup will be *free*”

 

-       A P2P network may not = be free, but the setup (provisioning) will be free, and automatic.  = This is a major benefit only partially achieved in enterprise networks,  a = benefit of great value to enterprises that is underserved by vendors.  There = is no benefit in requiring complex deployments where automation can take its = place.  Deployment is almost always the biggest cost of enterprise systems = dwarfing the cost of the systems themselves.

 

“I think this depends greatly on what expectations / contractual guarantees = the enterprise has. It’s unclear to me what guarantees can be made = about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make = guarantees.”

 

-      That is why = ‘expectations/contractual guarantees’ need to be built into the automation that exists in = the P2P overlay.  Self-calculation of such performance metrics is already = there in all enterprise devices, the difference being that while WMI/SNMP data is = merely collected a P2PSIP network can act automatically based on the metrics = within their own nodes, there is a collective ‘aha’ that forces = behavior change based on strict contracts, aka rules.  An SLA is easier to maintain if the objects can react accordingly, for example = a node with degrading service can notify that it is on the decline forcing = others to take over. 

 

There is an old traffic engineering axiom about service guarantees: it can be = achieved through two ways: over engineering or  automation.  P2PSIP = allows for automation.

 

 David Oran wrote:

 

“I'm not saying this can't be made to work, only that it isn't immediately = obvious that it has advantages over a classic application/server = approach.”

 

The immediately obvious advantage to me is standardized ruggedized = automation that has economies of scale and operates over multiple domains, eliminating = the need for over-engineering,  detailed fussy provisioning,  and an = army of people doing basic monitoring and care-and-feeding.  Automation is = the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment.   This is being done in fits and starts in the enterprise data center.   P2PSIP makes it much more = comprehensive.   People want the world to be predictable and deterministic,  = and C/S based systems reflect that. That is the biggest problem P2P faces = because it flies in the face of tradition. =   

 

Regards

 

Michael Slavitch

 

 

 

 

 

3D"corp_2colour"

 

308 Legget = Dr.
Ottawa = Ontario
K2K 1Y6 Canada

<= /span>

 

Michael = Slavitch           = ;  

Lead, Technology Initiatives

slavitch@objectworld.com

PSTN: 

+1.888.398.9698

x225

Fax:

+1.613.599.7457

 

Skype:      

 Objectworld   =

x225

<= /span>

 

 

 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); = David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian
Subject: Re: [P2Prg] RE: = [Sipping] Simple SIP usage scenario

 

 

 

Michael Slavitch wrote:

> Sorry for being late into this discussion, but client-server based VM =

> isn't truly client-server anymore in anything but the smallest or most =

> monolithic of enterprise networks, in fact the reality is that most if =

> not all enterprise networks contain just peers and superpeers with the =

> difference being partially a marketing decision by the vendors, as you =

> can charge much more for = the servers, and a policy decision made either

> automatically by a software deployment system or by IT staff which wants =

> to place supernodes with data sinks on appropriate = equipment.

 

I'm sorry, but I don't understand the point you are trying to make =

above. You are trying to draw some sort of distinction, but I don't get =

it. Can you try again.

 

       &nbs= p;        Thanks,

       &nbs= p;        Paul

 

> In a

> highly distributed environment there are potentially hundreds of =

> possible data sinks for a given application, with the sink based on =

> subnet or geographic location or balanced load, this can change rapidly =

> over time and does.

>

> In the case of the Microsoft environment such policy is administered and =

> published between supernodes, ie servers, by Active Directory.  It = is

> advertised to mere peers through DNS.  There was much discussion a = while

> ago about building service discovery environment using DNS instead of a =

> P2P DHT.  It can be argued that a case study of a P2P example done using

> DNS is any large Windows = Server 2003 based Microsoft network with many

> servers and many more clients that also run applications themselves and =

> are not just dumb terminals. This is almost certainly always the case in =

> all enterprises. The big difference between C/S SIP and P2PSIP is =

> automation. What is true is that the square peg in round hole of =

> overloading DNS makes deployments clumsy and brittle within the =

> enterprise domain and completely unmanageable and unpublishable outside =

> the firewall which is why the buck stops there in current enterprise =

> networking products.

>

> The difference between C/S and P2P is largely policy and semantics with

> the biggest difference being that the decisions and rules are highly =

> distributed.  Apart from that they are not just friends, they are =

> fraternal twins.

>

> Regards

>

> Michael Slavitch

>

> 

>

>

> corp_2colour

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://w= ww.objectworld.com/>

>

> 

>

>             =

>

> 308 Legget = Dr.

> Ottawa = Ontario

> K2K 1Y6 Canada

>

>             =

>

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://m= aps.google.ca/maps?f=3Dq%26hl=3Den%26q=3D308%2BLegget%2BDrive%2BOttawa%2B= Ontario%2BK2K%2B1Y6%26layer=3D%26sll=3D45.341061,-75.904541%26sspn=3D0.00= 7119,0.023839%26ie=3DUTF8%26z=3D18%26ll=3D45.341061,-75.904541%26spn=3D0.= 00178,0.00596%26t=3Dh%26om=3D1>

>

>             =

>

> 

>

> Michael = Slavitch           = ; 

>

> Lead, Technology Initiatives

>

> slavitch@objectworld.com = <mailto:slavitch@objectworld.com>

>

>             =

>

> PSTN:

>

>             =

>

> +1.888.398.9698

>

>             =

>

> x225

>

> Fax:

>

>             =

>

> +1.613.599.7457

>

>             =

>

> 

>

> Skype:     

>

>             =

>

>   Objectworld

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Norte= l,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME= %20and%20MME.EML/>  

>

>

>             =

>

> x225

>

>             =

>

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Norte= l,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME= %20and%20MME.EML/>

>

>             =

>

> 

>

> 

>

>

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS<= /font>

----------------------------------------------= --------

 

Teach CanIt if this mail (ID 657805) is spam:

Spam:       = ; http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Ds

Not spam:    http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Dn

Forget vote: = http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Df

----------------------------------------------= --------

END-ANTISPAM-VOTING-LINKS

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of the = author and may not represent those of Objectworld Communications = Corp.

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of = the author and may not represent those of Objectworld Communications = Corp.

------_=_NextPart_002_01C7763A.6DADE46E-- ------_=_NextPart_001_01C7763A.6DADE46E Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6 +0EbNruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHExlWYK4wpGMhue leLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9clnAj17UWQKd3+kNjPb+tN/s+6bR 21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHN R/8AAlv8a9P8NWv/AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1U9W1W00TSrjU76Qx 29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GFE6eqnPpzXoHzp19FZniHXIPDmhXOr3Mc ksNsoZkjxuOSBxn61ieHPiLpniHVV0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc 3dpDNClvcvbMJQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq39uaT FqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jHGM/M3Psa2tC1uy8RaPb6 rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFreaPqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+ w3Vj5hYeRdJskXBxyKANGisRvFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6v RZpDhd+8n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA2fxg0W4n Tz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumtpPNA+Zh3GD0oA26KiuJltraW dgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPKt7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8 kKcE9M5IrD1H4h6Hpltazzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+ jtPI2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1LvgEhv5V4sNKivt c+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m1u7X7PGJ4vL+zRoFMe3J3YHY5x9a 1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej 3PAy/C1qWJTmmkt+vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLNd74l0OHxJ4evNInk MSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZrKOGLYFXGMse5wf/AK9ekfLl74p/8k31 j/rmv/oa1xfhqXUW+IHhl/E0MVuf7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5 C4YHp+Fc5oHgDVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu11WK/ m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYHA9OBQByXjWXV4fi9oj6F b29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRqZ0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xa WxgBkg8zqWycHjo1dFoNtq1ppaQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs 9CsdDjg8OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/gK2/CHhuL wn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ceFpvFmlWtlDdJbNBdpcFnUsCF B44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1 Lx54N/4TPT7K2FwsDWt0sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/ AJoeP+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6Wv+oH+7/SvnjT 59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrzofC+5XwYNFXUoReQ6l9vt7nyzhD6 YznpmgD0RFCIqDooArz34S/e8Uf9hmWvQk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2 gYsC2SMnOOOOKAO41X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689GHQ1lT+EdCuQBLYK2 CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgBumKworm4ESATyYCj+M0j3M5KZnk4bj5z Xjey97c+4WK/dr3e39bG/ChiiCEjIz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5 OW5+c+lCpbu45YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckxNyf9 9q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFAH//Z ------_=_NextPart_001_01C7763A.6DADE46E Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAdAB0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0/VNW WCU20cnllQPMkAyVz0A9/wCVUylrNEHWKOZjysk+XP5nmua1W8kXU7pZDg+e/wCW7A/TFPs9UmmU Wquq8fK3cf4168cNywTR5EsTzTakdDFqT2M20l2j6mMknI7lc8j6dK6GORJY1kjYMrDII7ivOruS eB0lklDljgHNdh4ald9Fi39iwX/dycfpiufFUVGKmjowtZyk4M5/xhoUzXDX9qhbf/rFA5z6j1rj o5pILhGIHytzzivZnRZFKsAQazptCspX3NGM/SnQx0qceWSuia+AjUnzxdmef2ttd61f5XcIQcBs cAe3qa9J0+1W0s44VGAqgAegotrC3th8ic+tWq56+IlWavokdFDDxop21b6n/9k= ------_=_NextPart_001_01C7763A.6DADE46E Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAaABoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1Ga7l kZ2SdokV2VQgXJwcEnIPcHpVSTW7uHqYHA7bCCfxz/Skuiv9qSwFtitMoA/3gMn8yab/AGWls8lx qTBbeE5HP+s/z6V4051nJ8j2ervov+AYty6GrpuqQ6lGxQFJE++hPT/EVdrjtEuvN8S+ZEuxJjIS Pbkj+Qrsa7MDiHXpcz3Tt6lwlzIyNa0hr7E8GPNAwy5xvHb8axbu31G6jSO6W5ZYRwPKbH1JAwTX Y0VFfAQqyck7X37MUqaZx2k6cf7QheCQMUcFipyFAPOfTjj8a7GiitcLhY4eLinuOMeVH//Z ------_=_NextPart_001_01C7763A.6DADE46E-- --===============0058665474== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0058665474==-- From p2psip-bounces@ietf.org Tue Apr 03 22:11:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuy5-00053d-SN; Tue, 03 Apr 2007 22:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuy4-00051C-CC for p2psip@ietf.org; Tue, 03 Apr 2007 22:11:24 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuy2-0005FT-Ni for p2psip@ietf.org; Tue, 03 Apr 2007 22:11:24 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFY00AHZBDNPJ@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 04 Apr 2007 10:10:35 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFY005UBBDM94@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 04 Apr 2007 10:10:35 +0800 (CST) Received: from j36340 ([10.164.5.25]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFY00CSOBDIFV@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 04 Apr 2007 10:10:34 +0800 (CST) Date: Wed, 04 Apr 2007 10:10:30 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Re: Peer definition in Concept draft In-reply-to: <8B0D63EF-0C0E-47AC-833D-74E3B4905E29@magma.ca> To: 'Philip Matthews' Message-id: <004501c7765e$6bf1a370$1905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acd18SrcHKhG9pDMRDaOMuGDcs3LKgAa6bvQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Please see inline. -- Jiang XingFeng -------------------------------------------------------------------- > > Hi, Dean and Philip: > > > > From your responses, I learned that P2PSIP peer may be not coupled > > to any > > SIP entity. It also says that some P2PSIP peers will not recognize SIP > > message. Is my understanding right? If it is, I have some comments > > on the > > concept draft which are listed as follows: > > 1. In section 3, all peers in the reference model are coupled to SIP > > entities except gateway Peer. In my opinion, gateway peers also > > have SIP > > processing functionality because they should do translation between > > SIP > > signaling and PSTN signaling. Does the reference model imply that > > all peers > > have to speak SIP? If it is not the case, do we need add some peers > > which > > don't speak SIP? > > > > Comments? > > We could do that. > However, I think we need to decide on the rough format for the Peer > Protocol first. > If the Peer Protocol uses SIP, either entirely like the dSIP proposal, > or partly like draft-matthews-p2psip-bootstrap-mechanisms-00 > or draft-hautakorpi-p2psip-peer-protocol-00 > then it might be reasonable to assume that all peers speak SIP. > > However, if the Peer Protocol is completely independent of SIP, > then it is reasonable to assume that there are peers that do not > speak SIP. > > This plays a bit into the question of what we are trying to do in > P2PSIP. > Are we working on a system which is independent of SIP, > or does the fact that we are the "P2PSIP" group imply that we assume > all peers support SIP? [JiangXingFeng] I also think this is a fundamental issue which will influence work in P2PSIP greatly. Philip, would you please make it as an open issue and ask for comments in the mailing list? > > > > 2. In the second option of using distributed database in section > > 5.2, if > > Peer Z could not parse SIP message, how does the Peer Z proxy the > > INVITE > > message? If I don't make mistake, Peer Z at least rewrite the > > Request-URI of > > the message, so it have to be able to recognize and parse the SIP > > message. > > > > There are similar problems in option 3 and 4. > > > > Comments? > > Why would peer Z be unable to parse the SIP message? [JiangXingFeng] I mean that Peer Z may not speak SIP, so it is unable to parse the SIP message. > > > > > 3. In the section 5.5, some possible client behaviors are proposed. > > In terms > > of third alternative, namely "a peer with bad memory", clients > > participate > > in DHT algorithms and do not store any resource record. Here, I have a > > question. For example, there is a chord overlay and there are a > > peer keyed > > 20, and a client keyed 19. If a resource keyed 18 want to be stored > > into the > > overlay, a peer keyed 20 is responsible for key 18 according to the > > third > > alternative. But if a normal chord algorithm is used, the client > > node keyed > > 19 should be the answer. IMHO, I think this alternative will break the > > underlying DHT algorithm. Comments? > > Clearly, the DHT algorithm would have to be designed so that clients > are not > expected to store data. > > One way this might work was described by Eric Rescorla as follows: > 1. Clients understand the overlay network, they just don't > store data. To take a concrete example from Chord, there's > no reason you can't connect to a Chord node, suck down an > appropriate finger/routing table and then send messages > to other Chord nodes just as if you were a Peer. The > only thing you don't do is *register* with the network. > Other ways are probably possible. [Jiang XingFeng] I figured out the Eric's idea which is to let the Clients know the topology of the overlay and at the same time Peers in the overlay do not know the clients' existence. So Clients could have routing table of the overlay to routing the message by themselves. Is my understanding right? > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 03 23:22:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYw4W-0005fM-8w; Tue, 03 Apr 2007 23:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYw4U-0005ci-45 for p2psip@ietf.org; Tue, 03 Apr 2007 23:22:06 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYw4R-0004th-Ez for p2psip@ietf.org; Tue, 03 Apr 2007 23:22:05 -0400 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 03 Apr 2007 20:21:57 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l343LtSd017697; Tue, 3 Apr 2007 20:21:56 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l343Ls0c025831; Tue, 3 Apr 2007 20:21:55 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 20:21:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: Peer definition in Concept draft Date: Tue, 3 Apr 2007 20:21:24 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF34@namail5.corp.adobe.com> In-Reply-To: <8B0D63EF-0C0E-47AC-833D-74E3B4905E29@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: Peer definition in Concept draft Thread-Index: Acd18njNen6KoMu6TUGFLcZlUoAxswAdSWAQ References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> <8B0D63EF-0C0E-47AC-833D-74E3B4905E29@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "JiangXingFeng" X-OriginalArrivalTime: 04 Apr 2007 03:21:53.0826 (UTC) FILETIME=[6481E820:01C77668] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >Are we working on a system which is independent of SIP, or does the fact >that we are the "P2PSIP" group imply that we assume all peers support >SIP? The numerous applications developed for the openDHT have proven the usefulness of having an overlay that can support more than one application (such as SIP only). The DHT without SIP is also useful for bootstrapping and maybe TURN relays. There is a good case for having an independent, multi-purpose DHT overlay with a set of powerful APIs that support more than one single application. Let's have some I-Ds on this before trying to finalize this decision on e-mail. Thanks, Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, April 03, 2007 8:09 AM To: JiangXingFeng Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Re: Peer definition in Concept draft See in-line. - Philip On 3-Apr-07, at 07:56 , JiangXingFeng wrote: > Hi, Dean and Philip: > > From your responses, I learned that P2PSIP peer may be not coupled =20 > to any > SIP entity. It also says that some P2PSIP peers will not recognize SIP > message. Is my understanding right? If it is, I have some comments =20 > on the > concept draft which are listed as follows: > 1. In section 3, all peers in the reference model are coupled to SIP > entities except gateway Peer. In my opinion, gateway peers also =20 > have SIP > processing functionality because they should do translation between =20 > SIP > signaling and PSTN signaling. Does the reference model imply that =20 > all peers > have to speak SIP? If it is not the case, do we need add some peers =20 > which > don't speak SIP? > > Comments? We could do that. However, I think we need to decide on the rough format for the Peer =20 Protocol first. If the Peer Protocol uses SIP, either entirely like the dSIP proposal, or partly like draft-matthews-p2psip-bootstrap-mechanisms-00 or draft-hautakorpi-p2psip-peer-protocol-00 then it might be reasonable to assume that all peers speak SIP. However, if the Peer Protocol is completely independent of SIP, then it is reasonable to assume that there are peers that do not =20 speak SIP. This plays a bit into the question of what we are trying to do in =20 P2PSIP. Are we working on a system which is independent of SIP, or does the fact that we are the "P2PSIP" group imply that we assume all peers support SIP? > > 2. In the second option of using distributed database in section =20 > 5.2, if > Peer Z could not parse SIP message, how does the Peer Z proxy the =20 > INVITE > message? If I don't make mistake, Peer Z at least rewrite the =20 > Request-URI of > the message, so it have to be able to recognize and parse the SIP =20 > message. > > There are similar problems in option 3 and 4. > > Comments? Why would peer Z be unable to parse the SIP message? > > 3. In the section 5.5, some possible client behaviors are proposed. =20 > In terms > of third alternative, namely "a peer with bad memory", clients =20 > participate > in DHT algorithms and do not store any resource record. Here, I have a > question. For example, there is a chord overlay and there are a =20 > peer keyed > 20, and a client keyed 19. If a resource keyed 18 want to be stored =20 > into the > overlay, a peer keyed 20 is responsible for key 18 according to the =20 > third > alternative. But if a normal chord algorithm is used, the client =20 > node keyed > 19 should be the answer. IMHO, I think this alternative will break the > underlying DHT algorithm. Comments? Clearly, the DHT algorithm would have to be designed so that clients =20 are not expected to store data. One way this might work was described by Eric Rescorla as follows: 1. Clients understand the overlay network, they just don't store data. To take a concrete example from Chord, there's no reason you can't connect to a Chord node, suck down an appropriate finger/routing table and then send messages to other Chord nodes just as if you were a Peer. The only thing you don't do is *register* with the network. Other ways are probably possible. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 01:40:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYyE2-000498-Sz; Wed, 04 Apr 2007 01:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYyE1-00048r-6y; Wed, 04 Apr 2007 01:40:05 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYyDz-0001Fa-4D; Wed, 04 Apr 2007 01:40:05 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id BD8B550E; Wed, 4 Apr 2007 07:39:54 +0200 (MEST) Received: from sat-relay1.telecom.ptt.nl (relay3.kpn-telecom.nl [145.7.200.29]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id 7A4CA51C; Wed, 4 Apr 2007 07:39:54 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay1.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l345drT06556; Wed, 4 Apr 2007 07:39:53 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 07:39:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 07:37:57 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd1fDvzIhowLornTwyehPLXZ9zr5AA/ypd/ From: To: , X-OriginalArrivalTime: 04 Apr 2007 05:39:00.0578 (UTC) FILETIME=[8C08A420:01C7767B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Cc: sipping@ietf.org, p2prg@ietf.org, oran@cisco.com, p2psip@ietf.org, mhammer@cisco.com X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0932658786==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0932658786== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7767B.8BBEF331" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7767B.8BBEF331 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVucnksDQoNCkkgbGlrZSB5b3VyIGlkZWEgb2YgZGVwbG95aW5nIHNpcCBwZWVycyBpbiBlZGdl IGRldmljZXMuIEhvd2V2ZXIsIGFzIGFuIGVtcGxveWVlIG9mIGEgY2FycmllciBJIHdvdWxkIGxp a2UgdG8gc2VlIGhvdyBhIGNhcnJpZXIgaXMgYWJsZSB0byBwcm92aWRlIHNlcnZpY2UgYXN1cmFu Y2UgdG8gYmUgYWJsZSB0byBwcm92aWRlIGNvbXBsaWFudCBoYW5kbGluZy4gTWFueSBvZiBvdXIg Y3VzdG9tZXJzIGRvIG5vdCB1bmRlcnN0YW5kIGhvdyB0byBpbnN0YWxsIHRoZXNlIGdhdGV3YXlz IHRoZW1zZWx2ZXMsIGxldCBhbG9uZSBob3cgdG8gdHJvdWJsZXNob290Lg0KDQpUaGlzIGlzIGV2 ZW4gbW9yZSBpbXBvcnRhbnQgZm9yIGVudGVycHJpc2VzLCB3aGljaCBvZnRlbiAgaW5zaXN0IG9u IFNMQXMgd2hpY2ggaW5jbHVkZSB0cm91Ymxlc2hvb3QgcmVzb2x1dGlvbiBsaW1pdHMuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAiUGF1bCBLeXppdmF0IiA8cGt5eml2YXRA Y2lzY28uY29tPg0KVG86ICJIZW5yeSBTaW5ucmVpY2giIDxoc2lubnJlaUBhZG9iZS5jb20+DQpD YzogIlAyUFNJUCBNYWlsaW5nIExpc3QiIDxwMnBzaXBAaWV0Zi5vcmc+OyAiTWljaGFlbCBIYW1t ZXIgKG1oYW1tZXIpIiA8bWhhbW1lckBjaXNjby5jb20+OyAiRGF2aWQgUiBPcmFuIiA8b3JhbkBj aXNjby5jb20+OyAicDJwcmdAaWV0Zi5vcmciIDxwMnByZ0BpZXRmLm9yZz47ICJzaXBwaW5nQGll dGYub3JnIiA8c2lwcGluZ0BpZXRmLm9yZz4NClNlbnQ6IDMtNC0wNyAwMToxMQ0KU3ViamVjdDog W1AyUFNJUF0gUmU6IFtQMlByZ10gUkU6IFtTaXBwaW5nXSBTaW1wbGUgU0lQIHVzYWdlIHNjZW5h cmlvDQoNCg0KDQpIZW5yeSBTaW5ucmVpY2ggd3JvdGU6DQo+IFBhdWwsDQo+IA0KPj4gSSBtb3Jl IG9yIGxlc3MgYWdyZWUgd2l0aCB0aGUgZmluYWwgY29uY2x1c2lvbiBiZWxvdy4NCj4gDQo+IFRo aXMgaXMgZ29vZCBzdGFydGluZyBwb2ludCB0byBkaXNjdXNzIHNvbWUgdXNhZ2Ugc2NlbmFyaW9z Lg0KPiANCj4gUHV0dGluZyBvbiBteSBmb3JtZXIgaGF0IGFzIGFuIGVtcGxveWVlIGZvciBhIGNh cnJpZXIsIEkgY2Fubm90IG92ZXJsb29rDQo+IHRoZSBmb2xsb3dpbmc6DQo+IA0KPiBQMlAgU0lQ IGltcGxlbWVudGVkIGNvcnJlY3RseSBpbiB0aGUgcmVzaWRlbnRpYWwgYWNjZXNzIGJveCBvciBj YWJsZQ0KPiBzZXQtdG9wIGJveCBpbmRlZWQgaXMgYSBnb29kIG9yIGJldHRlciByZXBsYWNlbWVu dCBmb3IgdGhlIGVudGlyZSBWb0lQDQo+IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgKGNvc3QsIG9w ZXJhdGlvbnMsIG5ldyBzZXJ2aWNlcywgZXRjKS4gDQo+IEludGVncmF0ZWQgYWNjZXNzIGRldmlj ZXMgZm9yIHRoZSBlbnRlcnByaXNlIGNhbiBwcm9iYWJseSBwbGF5IGEgc2ltaWxhcg0KPiByb2xl LCBub3QgdG8gbWVudGlvbiBleGlzdGluZyBQMlAgUEJYIHByb2R1Y3RzIChwbGVhc2UgcmVmZXIg dG8gYWxsIHRoZQ0KPiBhZHZhbnRhZ2VzIG9mIFAyUCB0aGF0IG5lZWQgbm90IHJlcGVhdGVkIGhl cmUpLg0KPiANCj4gV2hhdCBkbyBwZW9wbGUgdGhpbmsgb2YgdGhlc2UgdGhyZWUgdXNhZ2Ugc2Nl bmFyaW9zIGZvciBQMlAgU0lQOg0KPiAtIFNJUCBwZWVyIGluIHRoZSBEU0wgYWNjZXNzIGRldmlj ZSwNCj4gLSBTSVAgcGVlciBpbiB0aGUgY2FibGUgYWNjZXNzIGRldmljZSwNCg0KVGhlc2Ugc2Vl bSBxdWl0ZSByZWFzb25hYmxlLCBhc3N1bWluZyB0aGF0IGEgZGV2aWNlIGNvbm5lY3RlZCBhdCB0 aGlzIA0KcG9pbnQgaXMgYWJsZSB0byBmdW5jdGlvbiBwcm9wZXJseSBhcyBhIHBlZXIuIChJIGhh dmVuJ3QgYmVlbiBmb2xsb3dpbmcgDQp3aGF0IHRoZSBhc3N1bXB0aW9ucyBhcmUgYWJvdXQgcmVx dWlyZWQgbmV0d29yayBjYXBhYmlsaXRpZXMgb2YgcGVlcnMuKQ0KDQo+IC0gU0lQIHBlZXIgaW4g ZW50ZXJwcmlzZSBuZXR3b3JrIGludGVncmF0ZWQgYWNjZXNzIGRldmljZSAoSUFEKS4NCg0KSSB0 aGluayB0aGlzIGRlcGVuZHMgZ3JlYXRseSBvbiB3aGF0IGV4cGVjdGF0aW9ucyAvIGNvbnRyYWN0 dWFsIA0KZ3VhcmFudGVlcyB0aGUgZW50ZXJwcmlzZSBoYXMuIEl0cyB1bmNsZWFyIHRvIG1lIHdo YXQgZ3VhcmFudGVlcyBjYW4gYmUgDQptYWRlIGFib3V0IGEgUDJQU0lQIG5ldHdvcmsgd2lsbCBi ZSBhYmxlIHRvIG1ha2UsIGFuZCBpdHMgdW5jbGVhciB3aGF0IA0Ka2luZCBvZiBpbmZyYXN0cnVj dHVyZSB3b3VsZCBiZSBpbnN0YWxsZWQgYnkvZm9yIHNvbWVvbmUgd2lsbGluZyB0byBtYWtlIA0K Z3VhcmFudGVlcy4NCg0KCVBhdWwNCg0KPiBOb3RlIHRoYXQgdGhlc2UgZXhhbXBsZXMgaW1wbHkg dmVyeSBsb3cgY2h1cm4gZm9yIHRoZSBwZWVycyBhbmQgYWRkIHRoZQ0KPiBkYXRhIHJldGVudGlv biByZXNpbGllbmNlIG9mIFAyUCAoZ2VvZ3JhcGhpYyBkaXZlcnNpdHkgaXMgbmF0aXZlIGFuZA0K PiBtb2JpbGUsIGV0Yy4pLiBJbmNpZGVudGFsbHksIE5BVCB0cmF2ZXJzYWwgbWF5IGFsc28gbm90 IGJlIGEgcHJvYmxlbSwgb3INCj4gYXQgbGVhc3QgYW4gZWFzaWVyIHByb2JsZW0uDQo+IA0KPiBX aGF0IGRvIHlvdSBhbGwgdGhpbms/DQo+IA0KPiBJIGhhdmUgdGFrZW4gdGhlIGxpYmVydHkgdG8g Y29weSB0aGUgUDJQIFNJUCBsaXN0LCBzaW5jZSB0aGUgbG93IGNodXJuDQo+IHNjZW5hcmlvcyBh cmUgb2YgaW50ZXJlc3QgZm9yIHRoZSBESFQgc2VsZWN0aW9uLiBPciBqdXN0IHBpY2sgdGhlIHNh bWUNCj4gREhUIGZvciBhbGwgc2NlbmFyaW9zIGFueXdheT8gSSBkb24ndCB0aGluayBzby4NCj4g DQo+IFRoYW5rcywgSGVucnkNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21dIA0KPiBTZW50 OiBGcmlkYXksIE1hcmNoIDMwLCAyMDA3IDY6MzEgUE0NCj4gVG86IEV1bnNvbyBTaGltDQo+IENj OiBIZW5yeSBTaW5ucmVpY2g7IE1pY2hhZWwgSGFtbWVyIChtaGFtbWVyKTsgRGF2aWQgUiBPcmFu Ow0KPiBwMnByZ0BpZXRmLm9yZzsgc2lwcGluZ0BpZXRmLm9yZzsgemh1eGlhbg0KPiBTdWJqZWN0 OiBSZTogW1AyUHJnXSBSRTogW1NpcHBpbmddIFNpbXBsZSBTSVAgdXNhZ2Ugc2NlbmFyaW8NCj4g DQo+IEkgbW9yZSBvciBsZXNzIGFncmVlIHdpdGggdGhlIGZpbmFsIGNvbmNsdXNpb24gYmVsb3cu DQo+IA0KPiBNeSBtYWluIHBvaW50IGhlcmUgaXMgdGhhdCBQMlAgYW5kIEMvUyBuZWVkIG5vdCBi ZSBlbmVtaWVzLiBOb3IgaXMgYSANCj4gdG90YWwgQy9TIHN5c3RlbSBuZWNlc3NhcmlseSBldmls LiBXaGF0IGlzIG1vc3QgZXZpbCBpcyAqYnVuZGxpbmcqIG9mIA0KPiBzZXJ2aWNlcyB0aGF0IHBy ZXZlbnRzIGZyZWVkb20gb2YgY2hvaWNlLg0KPiANCj4gSSB0aGluayBJIHdvdWxkIGJlIHF1aXRl IGhhcHB5IHdpdGggYSBTUCB0aGF0IHByb3ZpZGVzIGEgcmVnaXN0cmFyL3Byb3h5DQo+IA0KPiBh bmQgYWxsb3dzIG1lIHRvIHByb3ZpZGUgYWxsIG90aGVyIGZlYXR1cmVzIGFzIEkgc2VlIGZpdCAt IGJ5IHRha2luZyANCj4gdGhlbSBhbGEgY2FydGUgZnJvbSB0aGUgU1AsIG9yIHN1YnNjcmliaW5n IHRvIHRoZW0gZnJvbSBvbmUgb3IgbW9yZSANCj4gb3RoZXIgU1BzLCBvciBieSBwcm92aWRpbmcg dGhlbSBteXNlbGYgdmlhIGFwcGxpYW5jZXMgSSBvd24uIElmIHRoYXQgDQo+IHJlZ2lzdHJhci9w cm94eSB3YXMgcmVwbGFjZWQgYnkgYSBQMlAgc2lwIGNvbW11bml0eSwgdGhlIGRpZmZlcmVuY2Vz LCBpZg0KPiANCj4gYW55LCB3b3VsZCBob3BlZnVsbHkgYmUgbW9yZSBhIGZ1bmN0aW9uIG9mIHRo ZSBpbXBsZW1lbnRhdGlvbiBhbmQgdGhlIA0KPiBidXNpbmVzcyBtb2RlbHMgb2YgdGhvc2UgaW52 b2x2ZWQgdGhhbiB0aGUgYXJjaGl0ZWN0dXJlLg0KPiANCj4gKEkgZ2F0aGVyIHRoZSBnZW5lcmFs IGFzc3VtcHRpb24gaXMgdGhhdCBhIFAyUCBzZXR1cCB3aWxsIGJlICpmcmVlKi4gQnV0DQo+IA0K PiBJIGhhdmUgYSBoYXJkIHRpbWUgYmVsaWV2aW5nIHRoYXQuIElmIG1vc3Qgb2YgdGhlIHVzYWdl IGlzIGJ5IG1vYmlsZSANCj4gZGV2aWNlcyB0aGF0IGNhbid0IGJlIHBlZXJzLCB0aGVuIHNvbWVi b2R5IHdpbGwgaGF2ZSB0byBwYXkgZm9yIGVub3VnaCANCj4gcGVlcnMgdG8gc3VwcG9ydCB0aGVt LiBJZiBpdCBpc24ndCBmcmVlLCB0aGVuIGhvdyBpcyBpdCBiZXR0ZXIgdGhhbiBhIA0KPiB3ZWxs IGVuZ2luZWVyZWQgQy9TIHN5c3RlbT8pDQo+IA0KPiBTbyBJIHRoaW5rIHRoZSBrZXkgdGhpbmcg aGVyZSBpcyB0aGF0IHNvbWUgZmVhdHVyZXMgd2lsbCByZXF1aXJlIGdldHRpbmcNCj4gDQo+IHNv bWUgaGVscCBmcm9tIGFub3RoZXIgbm9kZS4gVGhlcmUgb3VnaHQgdG8gYmUgdGhlIG9wdGlvbiB0 byBwaWNrIGEgDQo+IGRpZmZlcmVudCBzb3VyY2UgZm9yIGVhY2ggaGVscGVyIHlvdSByZXF1aXJl LCBhbmQgYW4gYWJpbGl0eSBmb3IgaXQgYWxsIA0KPiB0byBwbGF5IHRvZ2V0aGVyLg0KPiANCj4g CVBhdWwNCj4gDQo+IEV1bnNvbyBTaGltIHdyb3RlOg0KPj4gUGxlYXNlIHNlZSBteSBpbmxpbmUg Y29tbWVudC4NCj4+DQo+PiBPbiAzLzMwLzA3LCAqUGF1bCBLeXppdmF0KiA8cGt5eml2YXRAY2lz Y28uY29tIA0KPj4gPG1haWx0bzpwa3l6aXZhdEBjaXNjby5jb20+PiB3cm90ZToNCj4+DQo+Pg0K Pj4NCj4+ICAgICBIZW5yeSBTaW5ucmVpY2ggd3JvdGU6DQo+PiAgICAgID4gRGF2aWQgT3JhbiB3 cm90ZSAod2l0aCByZWdhcmQgdG8gdm9pY2UgbWFpbCk6DQo+PiAgICAgID4NCj4+ICAgICAgPj4g SSdtIG5vdCBzYXlpbmcgdGhpcyBjYW4ndCBiZSBtYWRlIHRvIHdvcmssIG9ubHkgdGhhdCBpdCBp c24ndA0KPj4gICAgICA+IGltbWVkaWF0ZWx5ID5vYnZpb3VzIHRoYXQgaXQgaGFzIGFkdmFudGFn ZXMgb3ZlciBhIGNsYXNzaWMNCj4+ICAgICBhcHBsaWNhdGlvbg0KPj4gICAgICA+IHNlcnZlciA+ YXBwcm9hY2guDQo+PiAgICAgID4NCj4+ICAgICAgPiBUaGUgYW5zd2VyIGZvciBWTSBpcyAiaXQg ZGVwZW5kcyI6DQo+PiAgICAgID4NCj4+DQo+Pg0KPj4gSSBhZ3JlZS4gSXQgcmVhbGx5IGRlcGVu ZHMuIENlcnRhaW5seSB0aGVyZSBhcmUgdHJhZGVvZmZzLg0KPj4NCj4+ICAgICAgPiBUaGVyZSBh cmUgc2V2ZXJhbCBjb21tZXJjaWFsIFAyUCBJUCBQQlggc29sdXRpb25zIHdpdGhvdXQgYW55DQo+ PiAgICAgc2VydmVyIGZvcg0KPj4gICAgICA+IFZNIG9yIGFueXRoaW5nIGVsc2UuIE5vIGRvdWJ0 IHRoZSBJVCBvcmdhbml6YXRpb24gYXBwcmVjaWF0ZXMNCj4ganVzdA0KPj4gICAgICA+IGhhdmlu ZyB0byBwbHVnIGluIHRoZSBJUCBwaG9uZXMgYW5kIEdXWSB0byB0aGUgUFNUTiB3aXRob3V0IGFu eQ0KPj4gICAgICA+IGNvbmZpZ3VyYXRpb24gZXZlciBmb3IgVk0gb3IgYW55IG90aGVyIFBCWCBm ZWF0dXJlLg0KPj4NCj4+ICAgICBJIGRvbid0IHVuZGVyc3RhbmQuIEFyZSB5b3Ugc2F5aW5nIHRo ZXkgZG9uJ3QgaGF2ZSBWTSwgb3IgdGhhdA0KPiB0aGV5DQo+PiAgICAgZG9uJ3QgaGF2ZSBhICpz ZXJ2ZXIqIGZvciBWTT8NCj4+DQo+Pg0KPj4gSSBndWVzcyB0aGV5IGRvbid0IGhhdmUgYSAgKnNl cnZlciogZm9yICBWTS4NCj4+DQo+PiAgICAgID4gRm9yIHB1YmxpYyBQMlAgU0lQIG5ldHdvcmtz IHRoZXJlIGFyZSB0d28gbW9yZSBzY2VuYXJpb3Mgd2hlcmUNCj4gVk0gY2FuDQo+PiAgICAgID4g cmVzaWRlIChhbmQgd2l0aG91dCBldmVyIHNwZW5kaW5nIG9uZSBjZW50IG9uIFZNIHNlcnZlcnMg KyBJVA0KPj4gICAgIHN5c3RlbXMpOg0KPj4gICAgICA+DQo+PiAgICAgID4gLSBJbiBDYWJsZSBh bmQgRFNMIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3M6IFRoZSByZXNpZGVudGlhbA0KPj4gICAg IHJvdXRlciBjYW4NCj4+ICAgICAgPiBhY3QgYXMgYSB2b2ljZSByZWNvcmRlcg0KPj4NCj4+ICAg ICBUaGF0IGlzIHNpbXBseSBhbiBleGFtcGxlIG9mIHRoZSB1c2VyIGhhdmluZyBhbiBhcHBsaWFu Y2Ugb2YgaGlzDQo+IG93bg0KPj4gICAgIHRoYXQgcHJvdmlkZXMgVk0gc2VydmljZS4NCj4+DQo+ PiAgICAgID4gYW5kIFAyUCBjYW4gY292ZXIgdGhlIG5vdCB0b28gZnJlcXVlbnQgY2FzZXMsDQo+ PiAgICAgID4gd2hlcmUgdGhlIHJvdXRlciBpcyBub3QgaW4gb3BlcmF0aW9uLCBzbyB0aGUgZGF0 YSBpcyBiYWNrZWQgdXANCj4gaW4NCj4+ICAgICBvdGhlcg0KPj4gICAgICA+IHBlZXIgcmVzaWRl bnRpYWwgZ2F0ZXdheXMgKGVuY3J5cHRlZCkuDQo+Pg0KPj4gICAgIEkgZ3Vlc3MgSSBqdXN0IG5l ZWQgdG8gaGF2ZSBtb3JlIGluZm8gYWJvdXQgaG93IHRoaXMgd291bGQgd29yaw0KPiBiZWZvcmUg SQ0KPj4gICAgIHdpbGwgYmUgY29udmluY2VkIGl0IGlzIGZlYXNpYmxlIGFuZCB0cnVzdHdvcnRo eS4NCj4+DQo+Pg0KPj4gV2VsbCwgJ3RydXN0d29ydGh5JyBjb3VsZCBiZSAgY29uc2lkZXJlZCBp biBtYW55IGFuZ2xlcy4NCj4+IElmIGl0IGlzIGFib3V0IHByaXZhY3kgb2YgdGhlIG1lc3NhZ2Us IGEgcHVibGljIGtleSBiYXNlZCBlbmNyeXB0aW9uIA0KPj4gd291bGQgcHJvdmlkZSBhY2NlcHRh YmxlIHByaXZhY3kuDQo+PiBJZiBpdCBpcyBhYm91dCByZWxpYWJpbGl0eSBvZiB0aGUgbWVzc2Fn ZSBkZWxpdmVyeSwgd2VsbCwgYSBQMlAgYmFzZWQgDQo+PiBhc3luY2hyb25vdXMgbWVzc2FnZSBk ZWxpdmVyeSAobGlrZSBWTSkgaXMgbW9zdCBsaWtlbHkgbGVzcyByZWxpYWJsZSANCj4+IHRoYW4g YSB3ZWxsIG1hbmFnZWQgc2VydmVyIGJhc2VkIHN5c3RlbS4NCj4+IEhvd2V2ZXIsIG15IGV4cGVy aWVuY2Ugd2l0aCBTa3lwZSdzIGFzeW5jaHJvbm91cyBtZXNzYWdlIGRlbGl2ZXJ5IHdhcyANCj4+ IG5vdCBiYWQuIEFjdHVhbGx5IEkgZG9uJ3Qgc2VlIGFueSBzaWduaWZpY2FudCBkaWZmZXJlbmNl IGJldHdlZW4gaXQNCj4gYW5kIA0KPj4gbXkgY2VsbHVsYXIgc2VydmljZSBwcm92aWRlcidzIFZN IHNlcnZpY2UuIDotKQ0KPj4gUmVsaWFiaWxpdHkgaXMgYWx3YXlzIGEgY2hhbGxlbmdlIGZvciBQ MlAsIGZvciBzdXJlLiBCdXQsIEkgYmVsaWV2ZSBpdA0KPiANCj4+IGlzIGZlYXNpYmxlIHRvIGJ1 aWxkIGEgUDJQIHN5c3RlbSBmb3IgVk0gYWNjZXB0YWJsZSBmb3IgbWFueQ0KPiBzY2VuYXJpb3Mu DQo+PiAgICAgID4gLSBJbiBtb2JpbGUgbmV0d29ya3M6IFRoZSBWTSBjYW4gcmVzaWRlIGluIHF1 aXRlIHN0YWJsZSBwZWVycw0KPj4gICAgIGluc2lkZSB0aGUNCj4+ICAgICAgPiB3aXJlbGVzcyBi YXNlIHN0YXRpb24gbmV0d29yay4gVGhlIHBlZXJzIGluIHRoZSBiYXNlIHN0YXRpb24NCj4gbmV0 d29yaw0KPj4gICAgICA+IG5lZWQgbm8gY29uZmlndXJhdGlvbiwgZXRjLg0KPj4NCj4+ICAgICBJ IGRvbid0IHVuZGVyc3RhbmQuIEkgZ3Vlc3MgdGhhdCBjb3VsZCBiZSB0cnVlIGlmIHRoZSBwZWVy cyBhcmUNCj4gd2lsbGluZw0KPj4gICAgIHRvIHN0b3JlIGFuIGFyYml0cmFyeSBhbW91bnQgb2Yg Vk0gaW5kZWZpbml0ZWx5IGZvciBhbnlib2R5LiBJcw0KPiB0aGF0DQo+PiAgICAgYmVsaWV2YWJs ZT8NCj4+DQo+Pg0KPj4gSXQgZGVwZW5kcy4NCj4+IEluIGEgdmVyeSBuaWNlIGVudmlyb25tZW50 IHdoZXJlIGFsbCB0aGUgcGVlcnMgYXJlIHdpbGxpbmcgdG8NCj4gY29vcGVyYXRlIA0KPj4gYXQg dGhlaXIgYmVzdCwgdGhlIHBlZXJzIHdpbGwgc3RvcmUgYXMgbXVjaCBhcyB0aGV5IGNhbi4gSW4g YSB0b3VnaCANCj4+IGVudmlyb25tZW50LCB0aGUgc2l0dWF0aW9uIHdpbGwgYmUgZGlmZmVyZW50 Lg0KPj4NCj4+ICAgICBUaGlzIHNlZW1zIHRvIHRyYW5zbGF0ZSB0byBhIG1vZGVsIHdoZXJlIGl0 IGlzIGFzc3VtZWQgdGhhdCB0aG9zZQ0KPiBub2Rlcw0KPj4gICAgIHRoYXQgYXJlIG9uIG1vc3Qg b2YgdGhlIHRpbWUgd2lsbCBiZSB3aWxsaW5nIHRvIHByb3ZpZGUgVk0gc3RvcmFnZQ0KPiBmb3IN Cj4+ICAgICB0aG9zZSBub2RlcyB0aGF0IGFyZW4ndCBvbiBtb3N0IG9mIHRoZSB0aW1lLg0KPj4N Cj4+DQo+PiBUaGlzIGlzIGFnYWluIHJlbGF0ZWQgdG8gcmVsaWFiaWxpdHkgb2YgUDJQIHN5c3Rl bXMgb3IgdG9waWNzIGxpa2UNCj4gZnJlZSANCj4+IHJpZGVycyBhbmQgcmVwdXRhdGlvbi4NCj4+ IEEgUDJQIHN5c3RlbSBpcyBhIGNvbW11bml0eSBvciBzb2NpZXR5LiBUbyBiZSBzaW1wbGUsIGlm IG1hbnkgb2YgdGhlIA0KPj4gbWVtYmVycyBhcmUgYmFkLCB0aGUgY29tbXVuaXR5IHdvbid0IHdv cmsgd2VsbC4gSWYgdGhlIG1ham9yaXR5IG9mIHRoZQ0KPiANCj4+IG1lbWJlcnMgYXJlIGdvb2Qs IHRoZSBjb21tdW5pdHkgd2lsbCB3b3JrIHdlbGwgb3IgcmVhc29uYWJseS4NCj4+DQo+PiAgICAg ID4gQWRkIHRvIHRoaXMgdGhlIGNvbmZlcmVuY2luZyBjYXBhYmlsaXR5IGNvbWluZyBmcm9tIHAy cA0KPiBhcHBsaWNhdGlvbg0KPj4gICAgICA+IGxheWVyIG11bHRpY2FzdCwgdGhlIFNJUCBlMmUg Y29udHJvbCBjYXBhYmlsaXRpZXMgKGZvciBzdWNoIGFzDQo+PiAgICAgID4gYXV0by1hdHRlbmRh bnQsIGFnZW50IHdvcmtzdGF0aW9uLCBldGMuKSBhbmQgb25lIGhhcyB0byB3b25kZXINCj4gd2h5 IElUDQo+PiAgICAgID4gbmV0d29ya3MsIHB1YmxpYyBWb0lQIG5ldHdvcmtzIGFuZCBlbmQgdXNl cnMgc2hvdWxkIHN1cHBvcnQgdGhlDQo+IGh1Z2UNCj4+ICAgICAgPiBjb3N0IG9mIGhhbmQgZW5n aW5lZXJpbmcsIHRlc3RpbmcsIG1vbml0b3JpbmcsIG1haW50YWluaW5nDQo+IHNlcnZlcg0KPj4g ICAgIGJhc2VkDQo+PiAgICAgID4gVm9JUCBuZXR3b3Jrcy4gUDJQIHNlbGYgY29uZmlndXJhdGlv biBpcyBub3RoaW5nIGxlc3MgdGhhdA0KPiBhdXRvbWF0aW9uDQo+PiAgICAgID4gYXBwbGllZCB0 byBWb0lQLCBwbHVzIHRoZSBzaGlmdGluZyBvZiBjb21wdXRpbmcgdG8gdGhlDQo+IGVuZHBvaW50 cywNCj4+ICAgICB3aGVyZQ0KPj4gICAgICA+IHRoZXJlIGlzIGFuIGFidW5kYW5jZSBvZiB1bnVz ZWQgQ1BVLCBzdG9yYWdlLCBiYW5kd2lkdGggYW5kDQo+PiAgICAgZWxlY3RyaWNpdHkuDQo+PiAg ICAgID4NCj4+ICAgICAgPiBFcmljIEJ1cmdlciBhbHNvIG5vdGVzIElNIGNoYW5nZXMgY29tcGxl dGVseSB0aGUgdXNhZ2UgZm9yIFZNDQo+IGFuZCBtYXkNCj4+ICAgICAgPiBtYWtlIHVubmVjZXNz YXJ5IHRvIHBsYWNlIGNhbGxzIG9uIFZNIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4+DQo+PiAgICAg SSBmaW5kIHRoaXMgbW9yZSBwcm9taXNpbmcuDQo+Pg0KPj4gICAgICAgICAgIA0KPj4NCj4+DQo+ PiBJbiBvdmVyYWxsLCBhcmUgd2UgZGlzY3Vzc2luZyBpZiBQMlAgc3lzdGVtcyBiYXNlZCBWTSBj YW4gd29yaz8gSQ0KPiB0aGluayANCj4+IGl0IGNhbiB3b3JrLiAgSnVzdCBpdCBkZXBlbmRzIG9u IG1hbnkgdGhpbmdzLg0KPj4gSWYgaXQgaXMgbm90IHN1cGVyLXJlbGlhYmxlLCBzaG91bGQgd2Ug ZGlzcmVnYXJkIGl0PyBJIHdvdWxkIHNheSBuby4NCj4+DQo+PiBPbiB0aGUgb3RoZXIgaGFuZCwg ZG8gd2UgaGF2ZSB0byBhYmFuZG9uIGNsaWVudCBzZXJ2ZXIgYmFzZWQgVk0gYW5kIA0KPj4gc3dp dGNoIHRvIFAyUCBzeXN0ZW0gYmFzZWQgVk0/IEl0IGlzIHVwdG8gZWFjaCBvZiB1cy4NCj4+IENs aWVudCBzZXJ2ZXIgYmFzZWQgVk0gc3lzdGVtcyBhcmUgYWxyZWFkeSB0aGVyZS4NCj4+IFNvIHdo eSBkb24ndCB3ZSB3b3JrIG9uIFAyUCBiYXNlZCBWTSBub3c/DQo+PiAgDQo+PiBUaGFua3MuDQo+ Pg0KPj4gRXVuc29vDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUDJQU0lQIG1haWxpbmcgbGlzdA0KUDJQU0lQQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg== ------_=_NextPart_001_01C7767B.8BBEF331 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTAuMjgiPg0KPFRJVExFPlJFOiBbUDJQU0lQ XSBSZTogW1AyUHJnXSBSRTogW1NpcHBpbmddIFNpbXBsZSBTSVAgdXNhZ2Ugc2NlbmFyaW88L1RJ VExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9y bWF0IC0tPg0KDQo8UD48Rk9OVCBTSVpFPTI+SGVucnksPEJSPg0KPEJSPg0KSSBsaWtlIHlvdXIg aWRlYSBvZiBkZXBsb3lpbmcgc2lwIHBlZXJzIGluIGVkZ2UgZGV2aWNlcy4gSG93ZXZlciwgYXMg YW4gZW1wbG95ZWUgb2YgYSBjYXJyaWVyIEkgd291bGQgbGlrZSB0byBzZWUgaG93IGEgY2Fycmll ciBpcyBhYmxlIHRvIHByb3ZpZGUgc2VydmljZSBhc3VyYW5jZSB0byBiZSBhYmxlIHRvIHByb3Zp ZGUgY29tcGxpYW50IGhhbmRsaW5nLiBNYW55IG9mIG91ciBjdXN0b21lcnMgZG8gbm90IHVuZGVy c3RhbmQgaG93IHRvIGluc3RhbGwgdGhlc2UgZ2F0ZXdheXMgdGhlbXNlbHZlcywgbGV0IGFsb25l IGhvdyB0byB0cm91Ymxlc2hvb3QuPEJSPg0KPEJSPg0KVGhpcyBpcyBldmVuIG1vcmUgaW1wb3J0 YW50IGZvciBlbnRlcnByaXNlcywgd2hpY2ggb2Z0ZW4mbmJzcDsgaW5zaXN0IG9uIFNMQXMgd2hp Y2ggaW5jbHVkZSB0cm91Ymxlc2hvb3QgcmVzb2x1dGlvbiBsaW1pdHMuPEJSPg0KPEJSPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQpGcm9tOiAmcXVvdDtQYXVsIEt5eml2YXQmcXVv dDsgJmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDs8QlI+DQpUbzogJnF1b3Q7SGVucnkgU2lubnJl aWNoJnF1b3Q7ICZsdDtoc2lubnJlaUBhZG9iZS5jb20mZ3Q7PEJSPg0KQ2M6ICZxdW90O1AyUFNJ UCBNYWlsaW5nIExpc3QmcXVvdDsgJmx0O3AycHNpcEBpZXRmLm9yZyZndDs7ICZxdW90O01pY2hh ZWwgSGFtbWVyIChtaGFtbWVyKSZxdW90OyAmbHQ7bWhhbW1lckBjaXNjby5jb20mZ3Q7OyAmcXVv dDtEYXZpZCBSIE9yYW4mcXVvdDsgJmx0O29yYW5AY2lzY28uY29tJmd0OzsgJnF1b3Q7cDJwcmdA aWV0Zi5vcmcmcXVvdDsgJmx0O3AycHJnQGlldGYub3JnJmd0OzsgJnF1b3Q7c2lwcGluZ0BpZXRm Lm9yZyZxdW90OyAmbHQ7c2lwcGluZ0BpZXRmLm9yZyZndDs8QlI+DQpTZW50OiAzLTQtMDcgMDE6 MTE8QlI+DQpTdWJqZWN0OiBbUDJQU0lQXSBSZTogW1AyUHJnXSBSRTogW1NpcHBpbmddIFNpbXBs ZSBTSVAgdXNhZ2Ugc2NlbmFyaW88QlI+DQo8QlI+DQo8QlI+DQo8QlI+DQpIZW5yeSBTaW5ucmVp Y2ggd3JvdGU6PEJSPg0KJmd0OyBQYXVsLDxCUj4NCiZndDs8QlI+DQomZ3Q7Jmd0OyBJIG1vcmUg b3IgbGVzcyBhZ3JlZSB3aXRoIHRoZSBmaW5hbCBjb25jbHVzaW9uIGJlbG93LjxCUj4NCiZndDs8 QlI+DQomZ3Q7IFRoaXMgaXMgZ29vZCBzdGFydGluZyBwb2ludCB0byBkaXNjdXNzIHNvbWUgdXNh Z2Ugc2NlbmFyaW9zLjxCUj4NCiZndDs8QlI+DQomZ3Q7IFB1dHRpbmcgb24gbXkgZm9ybWVyIGhh dCBhcyBhbiBlbXBsb3llZSBmb3IgYSBjYXJyaWVyLCBJIGNhbm5vdCBvdmVybG9vazxCUj4NCiZn dDsgdGhlIGZvbGxvd2luZzo8QlI+DQomZ3Q7PEJSPg0KJmd0OyBQMlAgU0lQIGltcGxlbWVudGVk IGNvcnJlY3RseSBpbiB0aGUgcmVzaWRlbnRpYWwgYWNjZXNzIGJveCBvciBjYWJsZTxCUj4NCiZn dDsgc2V0LXRvcCBib3ggaW5kZWVkIGlzIGEgZ29vZCBvciBiZXR0ZXIgcmVwbGFjZW1lbnQgZm9y IHRoZSBlbnRpcmUgVm9JUDxCUj4NCiZndDsgbmV0d29yayBpbmZyYXN0cnVjdHVyZSAoY29zdCwg b3BlcmF0aW9ucywgbmV3IHNlcnZpY2VzLCBldGMpLjxCUj4NCiZndDsgSW50ZWdyYXRlZCBhY2Nl c3MgZGV2aWNlcyBmb3IgdGhlIGVudGVycHJpc2UgY2FuIHByb2JhYmx5IHBsYXkgYSBzaW1pbGFy PEJSPg0KJmd0OyByb2xlLCBub3QgdG8gbWVudGlvbiBleGlzdGluZyBQMlAgUEJYIHByb2R1Y3Rz IChwbGVhc2UgcmVmZXIgdG8gYWxsIHRoZTxCUj4NCiZndDsgYWR2YW50YWdlcyBvZiBQMlAgdGhh dCBuZWVkIG5vdCByZXBlYXRlZCBoZXJlKS48QlI+DQomZ3Q7PEJSPg0KJmd0OyBXaGF0IGRvIHBl b3BsZSB0aGluayBvZiB0aGVzZSB0aHJlZSB1c2FnZSBzY2VuYXJpb3MgZm9yIFAyUCBTSVA6PEJS Pg0KJmd0OyAtIFNJUCBwZWVyIGluIHRoZSBEU0wgYWNjZXNzIGRldmljZSw8QlI+DQomZ3Q7IC0g U0lQIHBlZXIgaW4gdGhlIGNhYmxlIGFjY2VzcyBkZXZpY2UsPEJSPg0KPEJSPg0KVGhlc2Ugc2Vl bSBxdWl0ZSByZWFzb25hYmxlLCBhc3N1bWluZyB0aGF0IGEgZGV2aWNlIGNvbm5lY3RlZCBhdCB0 aGlzPEJSPg0KcG9pbnQgaXMgYWJsZSB0byBmdW5jdGlvbiBwcm9wZXJseSBhcyBhIHBlZXIuIChJ IGhhdmVuJ3QgYmVlbiBmb2xsb3dpbmc8QlI+DQp3aGF0IHRoZSBhc3N1bXB0aW9ucyBhcmUgYWJv dXQgcmVxdWlyZWQgbmV0d29yayBjYXBhYmlsaXRpZXMgb2YgcGVlcnMuKTxCUj4NCjxCUj4NCiZn dDsgLSBTSVAgcGVlciBpbiBlbnRlcnByaXNlIG5ldHdvcmsgaW50ZWdyYXRlZCBhY2Nlc3MgZGV2 aWNlIChJQUQpLjxCUj4NCjxCUj4NCkkgdGhpbmsgdGhpcyBkZXBlbmRzIGdyZWF0bHkgb24gd2hh dCBleHBlY3RhdGlvbnMgLyBjb250cmFjdHVhbDxCUj4NCmd1YXJhbnRlZXMgdGhlIGVudGVycHJp c2UgaGFzLiBJdHMgdW5jbGVhciB0byBtZSB3aGF0IGd1YXJhbnRlZXMgY2FuIGJlPEJSPg0KbWFk ZSBhYm91dCBhIFAyUFNJUCBuZXR3b3JrIHdpbGwgYmUgYWJsZSB0byBtYWtlLCBhbmQgaXRzIHVu Y2xlYXIgd2hhdDxCUj4NCmtpbmQgb2YgaW5mcmFzdHJ1Y3R1cmUgd291bGQgYmUgaW5zdGFsbGVk IGJ5L2ZvciBzb21lb25lIHdpbGxpbmcgdG8gbWFrZTxCUj4NCmd1YXJhbnRlZXMuPEJSPg0KPEJS Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8QlI+DQo8 QlI+DQomZ3Q7IE5vdGUgdGhhdCB0aGVzZSBleGFtcGxlcyBpbXBseSB2ZXJ5IGxvdyBjaHVybiBm b3IgdGhlIHBlZXJzIGFuZCBhZGQgdGhlPEJSPg0KJmd0OyBkYXRhIHJldGVudGlvbiByZXNpbGll bmNlIG9mIFAyUCAoZ2VvZ3JhcGhpYyBkaXZlcnNpdHkgaXMgbmF0aXZlIGFuZDxCUj4NCiZndDsg bW9iaWxlLCBldGMuKS4gSW5jaWRlbnRhbGx5LCBOQVQgdHJhdmVyc2FsIG1heSBhbHNvIG5vdCBi ZSBhIHByb2JsZW0sIG9yPEJSPg0KJmd0OyBhdCBsZWFzdCBhbiBlYXNpZXIgcHJvYmxlbS48QlI+ DQomZ3Q7PEJSPg0KJmd0OyBXaGF0IGRvIHlvdSBhbGwgdGhpbms/PEJSPg0KJmd0OzxCUj4NCiZn dDsgSSBoYXZlIHRha2VuIHRoZSBsaWJlcnR5IHRvIGNvcHkgdGhlIFAyUCBTSVAgbGlzdCwgc2lu Y2UgdGhlIGxvdyBjaHVybjxCUj4NCiZndDsgc2NlbmFyaW9zIGFyZSBvZiBpbnRlcmVzdCBmb3Ig dGhlIERIVCBzZWxlY3Rpb24uIE9yIGp1c3QgcGljayB0aGUgc2FtZTxCUj4NCiZndDsgREhUIGZv ciBhbGwgc2NlbmFyaW9zIGFueXdheT8gSSBkb24ndCB0aGluayBzby48QlI+DQomZ3Q7PEJSPg0K Jmd0OyBUaGFua3MsIEhlbnJ5PEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KJmd0OyBGcm9tOiBQYXVsIEt5eml2YXQgWzxBIEhSRUY9 Im1haWx0bzpwa3l6aXZhdEBjaXNjby5jb20iPm1haWx0bzpwa3l6aXZhdEBjaXNjby5jb208L0E+ XTxCUj4NCiZndDsgU2VudDogRnJpZGF5LCBNYXJjaCAzMCwgMjAwNyA2OjMxIFBNPEJSPg0KJmd0 OyBUbzogRXVuc29vIFNoaW08QlI+DQomZ3Q7IENjOiBIZW5yeSBTaW5ucmVpY2g7IE1pY2hhZWwg SGFtbWVyIChtaGFtbWVyKTsgRGF2aWQgUiBPcmFuOzxCUj4NCiZndDsgcDJwcmdAaWV0Zi5vcmc7 IHNpcHBpbmdAaWV0Zi5vcmc7IHpodXhpYW48QlI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbUDJQcmdd IFJFOiBbU2lwcGluZ10gU2ltcGxlIFNJUCB1c2FnZSBzY2VuYXJpbzxCUj4NCiZndDs8QlI+DQom Z3Q7IEkgbW9yZSBvciBsZXNzIGFncmVlIHdpdGggdGhlIGZpbmFsIGNvbmNsdXNpb24gYmVsb3cu PEJSPg0KJmd0OzxCUj4NCiZndDsgTXkgbWFpbiBwb2ludCBoZXJlIGlzIHRoYXQgUDJQIGFuZCBD L1MgbmVlZCBub3QgYmUgZW5lbWllcy4gTm9yIGlzIGE8QlI+DQomZ3Q7IHRvdGFsIEMvUyBzeXN0 ZW0gbmVjZXNzYXJpbHkgZXZpbC4gV2hhdCBpcyBtb3N0IGV2aWwgaXMgKmJ1bmRsaW5nKiBvZjxC Uj4NCiZndDsgc2VydmljZXMgdGhhdCBwcmV2ZW50cyBmcmVlZG9tIG9mIGNob2ljZS48QlI+DQom Z3Q7PEJSPg0KJmd0OyBJIHRoaW5rIEkgd291bGQgYmUgcXVpdGUgaGFwcHkgd2l0aCBhIFNQIHRo YXQgcHJvdmlkZXMgYSByZWdpc3RyYXIvcHJveHk8QlI+DQomZ3Q7PEJSPg0KJmd0OyBhbmQgYWxs b3dzIG1lIHRvIHByb3ZpZGUgYWxsIG90aGVyIGZlYXR1cmVzIGFzIEkgc2VlIGZpdCAtIGJ5IHRh a2luZzxCUj4NCiZndDsgdGhlbSBhbGEgY2FydGUgZnJvbSB0aGUgU1AsIG9yIHN1YnNjcmliaW5n IHRvIHRoZW0gZnJvbSBvbmUgb3IgbW9yZTxCUj4NCiZndDsgb3RoZXIgU1BzLCBvciBieSBwcm92 aWRpbmcgdGhlbSBteXNlbGYgdmlhIGFwcGxpYW5jZXMgSSBvd24uIElmIHRoYXQ8QlI+DQomZ3Q7 IHJlZ2lzdHJhci9wcm94eSB3YXMgcmVwbGFjZWQgYnkgYSBQMlAgc2lwIGNvbW11bml0eSwgdGhl IGRpZmZlcmVuY2VzLCBpZjxCUj4NCiZndDs8QlI+DQomZ3Q7IGFueSwgd291bGQgaG9wZWZ1bGx5 IGJlIG1vcmUgYSBmdW5jdGlvbiBvZiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIHRoZTxCUj4NCiZn dDsgYnVzaW5lc3MgbW9kZWxzIG9mIHRob3NlIGludm9sdmVkIHRoYW4gdGhlIGFyY2hpdGVjdHVy ZS48QlI+DQomZ3Q7PEJSPg0KJmd0OyAoSSBnYXRoZXIgdGhlIGdlbmVyYWwgYXNzdW1wdGlvbiBp cyB0aGF0IGEgUDJQIHNldHVwIHdpbGwgYmUgKmZyZWUqLiBCdXQ8QlI+DQomZ3Q7PEJSPg0KJmd0 OyBJIGhhdmUgYSBoYXJkIHRpbWUgYmVsaWV2aW5nIHRoYXQuIElmIG1vc3Qgb2YgdGhlIHVzYWdl IGlzIGJ5IG1vYmlsZTxCUj4NCiZndDsgZGV2aWNlcyB0aGF0IGNhbid0IGJlIHBlZXJzLCB0aGVu IHNvbWVib2R5IHdpbGwgaGF2ZSB0byBwYXkgZm9yIGVub3VnaDxCUj4NCiZndDsgcGVlcnMgdG8g c3VwcG9ydCB0aGVtLiBJZiBpdCBpc24ndCBmcmVlLCB0aGVuIGhvdyBpcyBpdCBiZXR0ZXIgdGhh biBhPEJSPg0KJmd0OyB3ZWxsIGVuZ2luZWVyZWQgQy9TIHN5c3RlbT8pPEJSPg0KJmd0OzxCUj4N CiZndDsgU28gSSB0aGluayB0aGUga2V5IHRoaW5nIGhlcmUgaXMgdGhhdCBzb21lIGZlYXR1cmVz IHdpbGwgcmVxdWlyZSBnZXR0aW5nPEJSPg0KJmd0OzxCUj4NCiZndDsgc29tZSBoZWxwIGZyb20g YW5vdGhlciBub2RlLiBUaGVyZSBvdWdodCB0byBiZSB0aGUgb3B0aW9uIHRvIHBpY2sgYTxCUj4N CiZndDsgZGlmZmVyZW50IHNvdXJjZSBmb3IgZWFjaCBoZWxwZXIgeW91IHJlcXVpcmUsIGFuZCBh biBhYmlsaXR5IGZvciBpdCBhbGw8QlI+DQomZ3Q7IHRvIHBsYXkgdG9nZXRoZXIuPEJSPg0KJmd0 OzxCUj4NCiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8QlI+DQomZ3Q7 PEJSPg0KJmd0OyBFdW5zb28gU2hpbSB3cm90ZTo8QlI+DQomZ3Q7Jmd0OyBQbGVhc2Ugc2VlIG15 IGlubGluZSBjb21tZW50LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgT24gMy8zMC8wNywg KlBhdWwgS3l6aXZhdCogJmx0O3BreXppdmF0QGNpc2NvLmNvbTxCUj4NCiZndDsmZ3Q7ICZsdDs8 QSBIUkVGPSJtYWlsdG86cGt5eml2YXRAY2lzY28uY29tIj5tYWlsdG86cGt5eml2YXRAY2lzY28u Y29tPC9BPiZndDsmZ3Q7IHdyb3RlOjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhlbnJ5IFNpbm5y ZWljaCB3cm90ZTo8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IERhdmlkIE9yYW4gd3JvdGUgKHdpdGggcmVnYXJkIHRvIHZvaWNlIG1haWwpOjxCUj4NCiZn dDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jmd0OyBJJ20gbm90IHNheWluZyB0aGlz IGNhbid0IGJlIG1hZGUgdG8gd29yaywgb25seSB0aGF0IGl0IGlzbid0PEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBpbW1lZGlhdGVseSAmZ3Q7b2J2aW91 cyB0aGF0IGl0IGhhcyBhZHZhbnRhZ2VzIG92ZXIgYSBjbGFzc2ljPEJSPg0KJmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRpb248QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHNlcnZlciAmZ3Q7YXBwcm9hY2guPEJSPg0KJmd0OyZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgVGhlIGFuc3dlciBmb3IgVk0gaXMgJnF1b3Q7 aXQgZGVwZW5kcyZxdW90Ozo8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IEkgYWdy ZWUuIEl0IHJlYWxseSBkZXBlbmRzLiBDZXJ0YWlubHkgdGhlcmUgYXJlIHRyYWRlb2Zmcy48QlI+ DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgVGhlcmUgYXJlIHNldmVyYWwgY29tbWVyY2lhbCBQMlAgSVAgUEJYIHNvbHV0aW9ucyB3aXRo b3V0IGFueTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZlciBmb3I8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFZNIG9yIGFu eXRoaW5nIGVsc2UuIE5vIGRvdWJ0IHRoZSBJVCBvcmdhbml6YXRpb24gYXBwcmVjaWF0ZXM8QlI+ DQomZ3Q7IGp1c3Q8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm Z3Q7IGhhdmluZyB0byBwbHVnIGluIHRoZSBJUCBwaG9uZXMgYW5kIEdXWSB0byB0aGUgUFNUTiB3 aXRob3V0IGFueTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgY29uZmlndXJhdGlvbiBldmVyIGZvciBWTSBvciBhbnkgb3RoZXIgUEJYIGZlYXR1cmUuPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGRvbid0 IHVuZGVyc3RhbmQuIEFyZSB5b3Ugc2F5aW5nIHRoZXkgZG9uJ3QgaGF2ZSBWTSwgb3IgdGhhdDxC Uj4NCiZndDsgdGhleTxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvbid0 IGhhdmUgYSAqc2VydmVyKiBmb3IgVk0/PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7IEkgZ3Vlc3MgdGhleSBkb24ndCBoYXZlIGEmbmJzcDsgKnNlcnZlciogZm9yJm5i c3A7IFZNLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJmd0OyBGb3IgcHVibGljIFAyUCBTSVAgbmV0d29ya3MgdGhlcmUgYXJlIHR3byBt b3JlIHNjZW5hcmlvcyB3aGVyZTxCUj4NCiZndDsgVk0gY2FuPEJSPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyByZXNpZGUgKGFuZCB3aXRob3V0IGV2ZXIgc3Bl bmRpbmcgb25lIGNlbnQgb24gVk0gc2VydmVycyArIElUPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgc3lzdGVtcyk6PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmd0OzxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgLSBJbiBDYWJsZSBhbmQgRFNMIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3M6IFRo ZSByZXNpZGVudGlhbDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJvdXRl ciBjYW48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFj dCBhcyBhIHZvaWNlIHJlY29yZGVyPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUaGF0IGlzIHNpbXBseSBhbiBleGFtcGxlIG9mIHRoZSB1c2VyIGhh dmluZyBhbiBhcHBsaWFuY2Ugb2YgaGlzPEJSPg0KJmd0OyBvd248QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IHByb3ZpZGVzIFZNIHNlcnZpY2UuPEJSPg0KJmd0OyZn dDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFuZCBQ MlAgY2FuIGNvdmVyIHRoZSBub3QgdG9vIGZyZXF1ZW50IGNhc2VzLDxCUj4NCiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgd2hlcmUgdGhlIHJvdXRlciBpcyBub3Qg aW4gb3BlcmF0aW9uLCBzbyB0aGUgZGF0YSBpcyBiYWNrZWQgdXA8QlI+DQomZ3Q7IGluPEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3RoZXI8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHBlZXIgcmVzaWRlbnRpYWwgZ2F0ZXdheXMg KGVuY3J5cHRlZCkuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBJIGd1ZXNzIEkganVzdCBuZWVkIHRvIGhhdmUgbW9yZSBpbmZvIGFib3V0IGhvdyB0 aGlzIHdvdWxkIHdvcms8QlI+DQomZ3Q7IGJlZm9yZSBJPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgd2lsbCBiZSBjb252aW5jZWQgaXQgaXMgZmVhc2libGUgYW5kIHRydXN0 d29ydGh5LjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBXZWxsLCAn dHJ1c3R3b3J0aHknIGNvdWxkIGJlJm5ic3A7IGNvbnNpZGVyZWQgaW4gbWFueSBhbmdsZXMuPEJS Pg0KJmd0OyZndDsgSWYgaXQgaXMgYWJvdXQgcHJpdmFjeSBvZiB0aGUgbWVzc2FnZSwgYSBwdWJs aWMga2V5IGJhc2VkIGVuY3J5cHRpb248QlI+DQomZ3Q7Jmd0OyB3b3VsZCBwcm92aWRlIGFjY2Vw dGFibGUgcHJpdmFjeS48QlI+DQomZ3Q7Jmd0OyBJZiBpdCBpcyBhYm91dCByZWxpYWJpbGl0eSBv ZiB0aGUgbWVzc2FnZSBkZWxpdmVyeSwgd2VsbCwgYSBQMlAgYmFzZWQ8QlI+DQomZ3Q7Jmd0OyBh c3luY2hyb25vdXMgbWVzc2FnZSBkZWxpdmVyeSAobGlrZSBWTSkgaXMgbW9zdCBsaWtlbHkgbGVz cyByZWxpYWJsZTxCUj4NCiZndDsmZ3Q7IHRoYW4gYSB3ZWxsIG1hbmFnZWQgc2VydmVyIGJhc2Vk IHN5c3RlbS48QlI+DQomZ3Q7Jmd0OyBIb3dldmVyLCBteSBleHBlcmllbmNlIHdpdGggU2t5cGUn cyBhc3luY2hyb25vdXMgbWVzc2FnZSBkZWxpdmVyeSB3YXM8QlI+DQomZ3Q7Jmd0OyBub3QgYmFk LiBBY3R1YWxseSBJIGRvbid0IHNlZSBhbnkgc2lnbmlmaWNhbnQgZGlmZmVyZW5jZSBiZXR3ZWVu IGl0PEJSPg0KJmd0OyBhbmQ8QlI+DQomZ3Q7Jmd0OyBteSBjZWxsdWxhciBzZXJ2aWNlIHByb3Zp ZGVyJ3MgVk0gc2VydmljZS4gOi0pPEJSPg0KJmd0OyZndDsgUmVsaWFiaWxpdHkgaXMgYWx3YXlz IGEgY2hhbGxlbmdlIGZvciBQMlAsIGZvciBzdXJlLiBCdXQsIEkgYmVsaWV2ZSBpdDxCUj4NCiZn dDs8QlI+DQomZ3Q7Jmd0OyBpcyBmZWFzaWJsZSB0byBidWlsZCBhIFAyUCBzeXN0ZW0gZm9yIFZN IGFjY2VwdGFibGUgZm9yIG1hbnk8QlI+DQomZ3Q7IHNjZW5hcmlvcy48QlI+DQomZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IC0gSW4gbW9iaWxlIG5ldHdvcmtzOiBU aGUgVk0gY2FuIHJlc2lkZSBpbiBxdWl0ZSBzdGFibGUgcGVlcnM8QlI+DQomZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnNpZGUgdGhlPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB3aXJlbGVzcyBiYXNlIHN0YXRpb24gbmV0d29yay4gVGhl IHBlZXJzIGluIHRoZSBiYXNlIHN0YXRpb248QlI+DQomZ3Q7IG5ldHdvcms8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG5lZWQgbm8gY29uZmlndXJhdGlv biwgZXRjLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgSSBkb24ndCB1bmRlcnN0YW5kLiBJIGd1ZXNzIHRoYXQgY291bGQgYmUgdHJ1ZSBpZiB0aGUg cGVlcnMgYXJlPEJSPg0KJmd0OyB3aWxsaW5nPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdG8gc3RvcmUgYW4gYXJiaXRyYXJ5IGFtb3VudCBvZiBWTSBpbmRlZmluaXRlbHkg Zm9yIGFueWJvZHkuIElzPEJSPg0KJmd0OyB0aGF0PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgYmVsaWV2YWJsZT88QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDsgSXQgZGVwZW5kcy48QlI+DQomZ3Q7Jmd0OyBJbiBhIHZlcnkgbmljZSBlbnZpcm9u bWVudCB3aGVyZSBhbGwgdGhlIHBlZXJzIGFyZSB3aWxsaW5nIHRvPEJSPg0KJmd0OyBjb29wZXJh dGU8QlI+DQomZ3Q7Jmd0OyBhdCB0aGVpciBiZXN0LCB0aGUgcGVlcnMgd2lsbCBzdG9yZSBhcyBt dWNoIGFzIHRoZXkgY2FuLiBJbiBhIHRvdWdoPEJSPg0KJmd0OyZndDsgZW52aXJvbm1lbnQsIHRo ZSBzaXR1YXRpb24gd2lsbCBiZSBkaWZmZXJlbnQuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIHNlZW1zIHRvIHRyYW5zbGF0ZSB0byBhIG1v ZGVsIHdoZXJlIGl0IGlzIGFzc3VtZWQgdGhhdCB0aG9zZTxCUj4NCiZndDsgbm9kZXM8QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGFyZSBvbiBtb3N0IG9mIHRoZSB0 aW1lIHdpbGwgYmUgd2lsbGluZyB0byBwcm92aWRlIFZNIHN0b3JhZ2U8QlI+DQomZ3Q7IGZvcjxC Uj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRob3NlIG5vZGVzIHRoYXQgYXJl bid0IG9uIG1vc3Qgb2YgdGhlIHRpbWUuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4N CiZndDsmZ3Q7IFRoaXMgaXMgYWdhaW4gcmVsYXRlZCB0byByZWxpYWJpbGl0eSBvZiBQMlAgc3lz dGVtcyBvciB0b3BpY3MgbGlrZTxCUj4NCiZndDsgZnJlZTxCUj4NCiZndDsmZ3Q7IHJpZGVycyBh bmQgcmVwdXRhdGlvbi48QlI+DQomZ3Q7Jmd0OyBBIFAyUCBzeXN0ZW0gaXMgYSBjb21tdW5pdHkg b3Igc29jaWV0eS4gVG8gYmUgc2ltcGxlLCBpZiBtYW55IG9mIHRoZTxCUj4NCiZndDsmZ3Q7IG1l bWJlcnMgYXJlIGJhZCwgdGhlIGNvbW11bml0eSB3b24ndCB3b3JrIHdlbGwuIElmIHRoZSBtYWpv cml0eSBvZiB0aGU8QlI+DQomZ3Q7PEJSPg0KJmd0OyZndDsgbWVtYmVycyBhcmUgZ29vZCwgdGhl IGNvbW11bml0eSB3aWxsIHdvcmsgd2VsbCBvciByZWFzb25hYmx5LjxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBBZGQgdG8gdGhp cyB0aGUgY29uZmVyZW5jaW5nIGNhcGFiaWxpdHkgY29taW5nIGZyb20gcDJwPEJSPg0KJmd0OyBh cHBsaWNhdGlvbjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZn dDsgbGF5ZXIgbXVsdGljYXN0LCB0aGUgU0lQIGUyZSBjb250cm9sIGNhcGFiaWxpdGllcyAoZm9y IHN1Y2ggYXM8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7 IGF1dG8tYXR0ZW5kYW50LCBhZ2VudCB3b3Jrc3RhdGlvbiwgZXRjLikgYW5kIG9uZSBoYXMgdG8g d29uZGVyPEJSPg0KJmd0OyB3aHkgSVQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmZ3Q7IG5ldHdvcmtzLCBwdWJsaWMgVm9JUCBuZXR3b3JrcyBhbmQgZW5kIHVz ZXJzIHNob3VsZCBzdXBwb3J0IHRoZTxCUj4NCiZndDsgaHVnZTxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgY29zdCBvZiBoYW5kIGVuZ2luZWVyaW5nLCB0 ZXN0aW5nLCBtb25pdG9yaW5nLCBtYWludGFpbmluZzxCUj4NCiZndDsgc2VydmVyPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmFzZWQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IFZvSVAgbmV0d29ya3MuIFAyUCBzZWxmIGNvbmZp Z3VyYXRpb24gaXMgbm90aGluZyBsZXNzIHRoYXQ8QlI+DQomZ3Q7IGF1dG9tYXRpb248QlI+DQom Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IGFwcGxpZWQgdG8gVm9J UCwgcGx1cyB0aGUgc2hpZnRpbmcgb2YgY29tcHV0aW5nIHRvIHRoZTxCUj4NCiZndDsgZW5kcG9p bnRzLDxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlPEJSPg0KJmd0 OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0aGVyZSBpcyBhbiBhYnVu ZGFuY2Ugb2YgdW51c2VkIENQVSwgc3RvcmFnZSwgYmFuZHdpZHRoIGFuZDxCUj4NCiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVsZWN0cmljaXR5LjxCUj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IEVyaWMgQnVyZ2VyIGFsc28gbm90ZXMgSU0gY2hhbmdlcyBj b21wbGV0ZWx5IHRoZSB1c2FnZSBmb3IgVk08QlI+DQomZ3Q7IGFuZCBtYXk8QlI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IG1ha2UgdW5uZWNlc3NhcnkgdG8g cGxhY2UgY2FsbHMgb24gVk0gaW4gdGhlIGZpcnN0IHBsYWNlLjxCUj4NCiZndDsmZ3Q7PEJSPg0K Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSBmaW5kIHRoaXMgbW9yZSBwcm9taXNp bmcuPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7Jmd0OyBJbiBvdmVyYWxsLCBhcmUgd2UgZGlzY3Vzc2luZyBpZiBQMlAg c3lzdGVtcyBiYXNlZCBWTSBjYW4gd29yaz8gSTxCUj4NCiZndDsgdGhpbms8QlI+DQomZ3Q7Jmd0 OyBpdCBjYW4gd29yay4mbmJzcDsgSnVzdCBpdCBkZXBlbmRzIG9uIG1hbnkgdGhpbmdzLjxCUj4N CiZndDsmZ3Q7IElmIGl0IGlzIG5vdCBzdXBlci1yZWxpYWJsZSwgc2hvdWxkIHdlIGRpc3JlZ2Fy ZCBpdD8gSSB3b3VsZCBzYXkgbm8uPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBPbiB0aGUg b3RoZXIgaGFuZCwgZG8gd2UgaGF2ZSB0byBhYmFuZG9uIGNsaWVudCBzZXJ2ZXIgYmFzZWQgVk0g YW5kPEJSPg0KJmd0OyZndDsgc3dpdGNoIHRvIFAyUCBzeXN0ZW0gYmFzZWQgVk0/IEl0IGlzIHVw dG8gZWFjaCBvZiB1cy48QlI+DQomZ3Q7Jmd0OyBDbGllbnQgc2VydmVyIGJhc2VkIFZNIHN5c3Rl bXMgYXJlIGFscmVhZHkgdGhlcmUuPEJSPg0KJmd0OyZndDsgU28gd2h5IGRvbid0IHdlIHdvcmsg b24gUDJQIGJhc2VkIFZNIG5vdz88QlI+DQomZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsmZ3Q7IFRo YW5rcy48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IEV1bnNvbzxCUj4NCiZndDs8QlI+DQo8 QlI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4N ClAyUFNJUCBtYWlsaW5nIGxpc3Q8QlI+DQpQMlBTSVBAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAiPmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcDwvQT48QlI+DQo8L0ZPTlQ+DQo8L1A+ DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C7767B.8BBEF331-- --===============0932658786== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0932658786==-- From p2psip-bounces@ietf.org Wed Apr 04 03:32:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYzyw-0003Aq-Kr; Wed, 04 Apr 2007 03:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYzyv-0003Af-2p; Wed, 04 Apr 2007 03:32:37 -0400 Received: from smtp-vbr9.xs4all.nl ([194.109.24.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYzyt-0007gL-QF; Wed, 04 Apr 2007 03:32:37 -0400 Received: from [192.168.0.6] (mit.xs4all.nl [213.84.95.205]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id l347WGjb017787; Wed, 4 Apr 2007 09:32:21 +0200 (CEST) (envelope-from ag@ag-projects.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <1D065707-A33E-48CC-887B-0C5D6F0708CF@ag-projects.com> From: Adrian Georgescu Subject: Re: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 09:32:13 +0200 To: "" X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Score: 0.5 (/) X-Scan-Signature: 9b281509fec590bb711c36d4c3ba4f74 Cc: p2psip@ietf.org, mhammer@cisco.com, oran@cisco.com, hsinnrei@adobe.com, p2prg@ietf.org, sipping@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1540406999==" Errors-To: p2psip-bounces@ietf.org --===============1540406999== Content-Type: multipart/alternative; boundary=Apple-Mail-10--203761590 --Apple-Mail-10--203761590 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Colin, With the right P2P software, the devices need no configuration at all, the configuration data can be derived from the "hardware id" and a preloaded X509 certificate while the mapping between services and the hardware can be done centralized and allow the business model the operator wishes with minimal opex. Adrian On Apr 4, 2007, at 7:37 AM, wrote: > Henry, > > I like your idea of deploying sip peers in edge devices. However, > as an employee of a carrier I would like to see how a carrier is > able to provide service asurance to be able to provide compliant > handling. Many of our customers do not understand how to install > these gateways themselves, let alone how to troubleshoot. > > This is even more important for enterprises, which often insist on > SLAs which include troubleshoot resolution limits. > > -----Original Message----- > From: "Paul Kyzivat" > To: "Henry Sinnreich" > Cc: "P2PSIP Mailing List" ; "Michael Hammer > (mhammer)" ; "David R Oran" ; > "p2prg@ietf.org" ; "sipping@ietf.org" > > Sent: 3-4-07 01:11 > Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > > > Henry Sinnreich wrote: > > Paul, > > > >> I more or less agree with the final conclusion below. > > > > This is good starting point to discuss some usage scenarios. > > > > Putting on my former hat as an employee for a carrier, I cannot > overlook > > the following: > > > > P2P SIP implemented correctly in the residential access box or cable > > set-top box indeed is a good or better replacement for the entire > VoIP > > network infrastructure (cost, operations, new services, etc). > > Integrated access devices for the enterprise can probably play a > similar > > role, not to mention existing P2P PBX products (please refer to > all the > > advantages of P2P that need not repeated here). > > > > What do people think of these three usage scenarios for P2P SIP: > > - SIP peer in the DSL access device, > > - SIP peer in the cable access device, > > These seem quite reasonable, assuming that a device connected at this > point is able to function properly as a peer. (I haven't been > following > what the assumptions are about required network capabilities of > peers.) > > > - SIP peer in enterprise network integrated access device (IAD). > > I think this depends greatly on what expectations / contractual > guarantees the enterprise has. Its unclear to me what guarantees > can be > made about a P2PSIP network will be able to make, and its unclear what > kind of infrastructure would be installed by/for someone willing to > make > guarantees. > > Paul > > > Note that these examples imply very low churn for the peers and > add the > > data retention resilience of P2P (geographic diversity is native and > > mobile, etc.). Incidentally, NAT traversal may also not be a > problem, or > > at least an easier problem. > > > > What do you all think? > > > > I have taken the liberty to copy the P2P SIP list, since the low > churn > > scenarios are of interest for the DHT selection. Or just pick the > same > > DHT for all scenarios anyway? I don't think so. > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, March 30, 2007 6:31 PM > > To: Eunsoo Shim > > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; > > p2prg@ietf.org; sipping@ietf.org; zhuxian > > Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > > > I more or less agree with the final conclusion below. > > > > My main point here is that P2P and C/S need not be enemies. Nor is a > > total C/S system necessarily evil. What is most evil is > *bundling* of > > services that prevents freedom of choice. > > > > I think I would be quite happy with a SP that provides a > registrar/proxy > > > > and allows me to provide all other features as I see fit - by taking > > them ala carte from the SP, or subscribing to them from one or more > > other SPs, or by providing them myself via appliances I own. If that > > registrar/proxy was replaced by a P2P sip community, the > differences, if > > > > any, would hopefully be more a function of the implementation and > the > > business models of those involved than the architecture. > > > > (I gather the general assumption is that a P2P setup will be > *free*. But > > > > I have a hard time believing that. If most of the usage is by mobile > > devices that can't be peers, then somebody will have to pay for > enough > > peers to support them. If it isn't free, then how is it better > than a > > well engineered C/S system?) > > > > So I think the key thing here is that some features will require > getting > > > > some help from another node. There ought to be the option to pick a > > different source for each helper you require, and an ability for > it all > > to play together. > > > > Paul > > > > Eunsoo Shim wrote: > >> Please see my inline comment. > >> > >> On 3/30/07, *Paul Kyzivat* >> > wrote: > >> > >> > >> > >> Henry Sinnreich wrote: > >> > David Oran wrote (with regard to voice mail): > >> > > >> >> I'm not saying this can't be made to work, only that it > isn't > >> > immediately >obvious that it has advantages over a classic > >> application > >> > server >approach. > >> > > >> > The answer for VM is "it depends": > >> > > >> > >> > >> I agree. It really depends. Certainly there are tradeoffs. > >> > >> > There are several commercial P2P IP PBX solutions without > any > >> server for > >> > VM or anything else. No doubt the IT organization > appreciates > > just > >> > having to plug in the IP phones and GWY to the PSTN > without any > >> > configuration ever for VM or any other PBX feature. > >> > >> I don't understand. Are you saying they don't have VM, or that > > they > >> don't have a *server* for VM? > >> > >> > >> I guess they don't have a *server* for VM. > >> > >> > For public P2P SIP networks there are two more scenarios > where > > VM can > >> > reside (and without ever spending one cent on VM servers > + IT > >> systems): > >> > > >> > - In Cable and DSL service provider networks: The > residential > >> router can > >> > act as a voice recorder > >> > >> That is simply an example of the user having an appliance of > his > > own > >> that provides VM service. > >> > >> > and P2P can cover the not too frequent cases, > >> > where the router is not in operation, so the data is > backed up > > in > >> other > >> > peer residential gateways (encrypted). > >> > >> I guess I just need to have more info about how this would work > > before I > >> will be convinced it is feasible and trustworthy. > >> > >> > >> Well, 'trustworthy' could be considered in many angles. > >> If it is about privacy of the message, a public key based > encryption > >> would provide acceptable privacy. > >> If it is about reliability of the message delivery, well, a P2P > based > >> asynchronous message delivery (like VM) is most likely less > reliable > >> than a well managed server based system. > >> However, my experience with Skype's asynchronous message > delivery was > >> not bad. Actually I don't see any significant difference between it > > and > >> my cellular service provider's VM service. :-) > >> Reliability is always a challenge for P2P, for sure. But, I > believe it > > > >> is feasible to build a P2P system for VM acceptable for many > > scenarios. > >> > - In mobile networks: The VM can reside in quite stable > peers > >> inside the > >> > wireless base station network. The peers in the base station > > network > >> > need no configuration, etc. > >> > >> I don't understand. I guess that could be true if the peers are > > willing > >> to store an arbitrary amount of VM indefinitely for anybody. Is > > that > >> believable? > >> > >> > >> It depends. > >> In a very nice environment where all the peers are willing to > > cooperate > >> at their best, the peers will store as much as they can. In a tough > >> environment, the situation will be different. > >> > >> This seems to translate to a model where it is assumed that > those > > nodes > >> that are on most of the time will be willing to provide VM > storage > > for > >> those nodes that aren't on most of the time. > >> > >> > >> This is again related to reliability of P2P systems or topics like > > free > >> riders and reputation. > >> A P2P system is a community or society. To be simple, if many of > the > >> members are bad, the community won't work well. If the majority > of the > > > >> members are good, the community will work well or reasonably. > >> > >> > Add to this the conferencing capability coming from p2p > > application > >> > layer multicast, the SIP e2e control capabilities (for > such as > >> > auto-attendant, agent workstation, etc.) and one has to > wonder > > why IT > >> > networks, public VoIP networks and end users should > support the > > huge > >> > cost of hand engineering, testing, monitoring, maintaining > > server > >> based > >> > VoIP networks. P2P self configuration is nothing less that > > automation > >> > applied to VoIP, plus the shifting of computing to the > > endpoints, > >> where > >> > there is an abundance of unused CPU, storage, bandwidth and > >> electricity. > >> > > >> > Eric Burger also notes IM changes completely the usage > for VM > > and may > >> > make unnecessary to place calls on VM in the first place. > >> > >> I find this more promising. > >> > >> > >> > >> > >> In overall, are we discussing if P2P systems based VM can work? I > > think > >> it can work. Just it depends on many things. > >> If it is not super-reliable, should we disregard it? I would say > no. > >> > >> On the other hand, do we have to abandon client server based VM and > >> switch to P2P system based VM? It is upto each of us. > >> Client server based VM systems are already there. > >> So why don't we work on P2P based VM now? > >> > >> Thanks. > >> > >> Eunsoo > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-10--203761590 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Colin,

With the right P2P = software, the devices need no configuration at all, the configuration = data can be derived from the "hardware id" and a preloaded X509 = certificate while the mapping between services and the hardware can be = done centralized and allow the business model the operator wishes with = minimal opex.

Adrian

On Apr 4, 2007, at 7:37 AM, <colin.pons@kpn.com> <colin.pons@kpn.com> = wrote:

Henry,

I like your idea of = deploying sip peers in edge devices. However, as an employee of a = carrier I would like to see how a carrier is able to provide service = asurance to be able to provide compliant handling. Many of our customers = do not understand how to install these gateways themselves, let alone = how to troubleshoot.

This is even more important for = enterprises, which often=A0 insist on SLAs which include troubleshoot = resolution limits.

-----Original Message-----
From: "Paul = Kyzivat" <pkyzivat@cisco.com>
To: = "Henry Sinnreich" <hsinnrei@adobe.com>
Cc: = "P2PSIP Mailing List" <p2psip@ietf.org>; "Michael Hammer = (mhammer)" <mhammer@cisco.com>; "David R = Oran" <oran@cisco.com>; "p2prg@ietf.org" <p2prg@ietf.org>; "sipping@ietf.org" <sipping@ietf.org>
Sent: = 3-4-07 01:11
Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP = usage scenario



Henry Sinnreich wrote:
> = Paul,
>
>> I more or less agree with the final = conclusion below.
>
> This is good starting point to = discuss some usage scenarios.
>
> Putting on my former hat = as an employee for a carrier, I cannot overlook
> the = following:
>
> P2P SIP implemented correctly in the = residential access box or cable
> set-top box indeed is a good or = better replacement for the entire VoIP
> network infrastructure = (cost, operations, new services, etc).
> Integrated access = devices for the enterprise can probably play a similar
> role, = not to mention existing P2P PBX products (please refer to all the
= > advantages of P2P that need not repeated here).
>
> = What do people think of these three usage scenarios for P2P SIP:
= > - SIP peer in the DSL access device,
> - SIP peer in the = cable access device,

These seem quite reasonable, assuming that = a device connected at this
point is able to function properly as a = peer. (I haven't been following
what the assumptions are about = required network capabilities of peers.)

> - SIP peer in = enterprise network integrated access device (IAD).

I think this = depends greatly on what expectations / contractual
guarantees the = enterprise has. Its unclear to me what guarantees can be
made about = a P2PSIP network will be able to make, and its unclear what
kind of = infrastructure would be installed by/for someone willing to make
= guarantees.

=A0=A0=A0=A0=A0=A0=A0 Paul

> Note that = these examples imply very low churn for the peers and add the
> = data retention resilience of P2P (geographic diversity is native and
= > mobile, etc.). Incidentally, NAT traversal may also not be a = problem, or
> at least an easier problem.
>
> What = do you all think?
>
> I have taken the liberty to copy the = P2P SIP list, since the low churn
> scenarios are of interest for = the DHT selection. Or just pick the same
> DHT for all scenarios = anyway? I don't think so.
>
> Thanks, Henry
>
= >
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
= > Sent: Friday, March 30, 2007 6:31 PM
> To: Eunsoo Shim
= > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran;
= > p2prg@ietf.org; sipping@ietf.org; zhuxian
> = Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario
= >
> I more or less agree with the final conclusion below.
= >
> My main point here is that P2P and C/S need not be = enemies. Nor is a
> total C/S system necessarily evil. What is = most evil is *bundling* of
> services that prevents freedom of = choice.
>
> I think I would be quite happy with a SP that = provides a registrar/proxy
>
> and allows me to provide = all other features as I see fit - by taking
> them ala carte from = the SP, or subscribing to them from one or more
> other SPs, or = by providing them myself via appliances I own. If that
> = registrar/proxy was replaced by a P2P sip community, the differences, = if
>
> any, would hopefully be more a function of the = implementation and the
> business models of those involved than = the architecture.
>
> (I gather the general assumption is = that a P2P setup will be *free*. But
>
> I have a hard = time believing that. If most of the usage is by mobile
> devices = that can't be peers, then somebody will have to pay for enough
> = peers to support them. If it isn't free, then how is it better than = a
> well engineered C/S system?)
>
> So I think the = key thing here is that some features will require getting
>
= > some help from another node. There ought to be the option to pick = a
> different source for each helper you require, and an ability = for it all
> to play together.
>
> =A0=A0=A0=A0=A0 = Paul
>
> Eunsoo Shim wrote:
>> Please see my = inline comment.
>>
>> On 3/30/07, *Paul Kyzivat* = <pkyzivat@cisco.com
= >> <mailto:pkyzivat@cisco.com>> = wrote:
>>
>>
>>
>>=A0=A0=A0=A0 = Henry Sinnreich wrote:
>>=A0=A0=A0=A0=A0 > David Oran wrote = (with regard to voice mail):
>>=A0=A0=A0=A0=A0 >
= >>=A0=A0=A0=A0=A0 >> I'm not saying this can't be made to = work, only that it isn't
>>=A0=A0=A0=A0=A0 > immediately = >obvious that it has advantages over a classic
>>=A0=A0=A0=A0= application
>>=A0=A0=A0=A0=A0 > server >approach.
= >>=A0=A0=A0=A0=A0 >
>>=A0=A0=A0=A0=A0 > The answer = for VM is "it depends":
>>=A0=A0=A0=A0=A0 >
= >>
>>
>> I agree. It really depends. Certainly = there are tradeoffs.
>>
>>=A0=A0=A0=A0=A0 > There = are several commercial P2P IP PBX solutions without any
>>=A0=A0= =A0=A0 server for
>>=A0=A0=A0=A0=A0 > VM or anything else. = No doubt the IT organization appreciates
> just
>>=A0=A0=A0= =A0=A0 > having to plug in the IP phones and GWY to the PSTN without = any
>>=A0=A0=A0=A0=A0 > configuration ever for VM or any = other PBX feature.
>>
>>=A0=A0=A0=A0 I don't = understand. Are you saying they don't have VM, or that
> they
= >>=A0=A0=A0=A0 don't have a *server* for VM?
>>
= >>
>> I guess they don't have a=A0 *server* for=A0 = VM.
>>
>>=A0=A0=A0=A0=A0 > For public P2P SIP = networks there are two more scenarios where
> VM can
= >>=A0=A0=A0=A0=A0 > reside (and without ever spending one cent = on VM servers + IT
>>=A0=A0=A0=A0 systems):
>>=A0=A0=A0= =A0=A0 >
>>=A0=A0=A0=A0=A0 > - In Cable and DSL service = provider networks: The residential
>>=A0=A0=A0=A0 router = can
>>=A0=A0=A0=A0=A0 > act as a voice recorder
= >>
>>=A0=A0=A0=A0 That is simply an example of the user = having an appliance of his
> own
>>=A0=A0=A0=A0 that = provides VM service.
>>
>>=A0=A0=A0=A0=A0 > and = P2P can cover the not too frequent cases,
>>=A0=A0=A0=A0=A0 = > where the router is not in operation, so the data is backed up
= > in
>>=A0=A0=A0=A0 other
>>=A0=A0=A0=A0=A0 > = peer residential gateways (encrypted).
>>
>>=A0=A0=A0=A0= I guess I just need to have more info about how this would work
= > before I
>>=A0=A0=A0=A0 will be convinced it is feasible = and trustworthy.
>>
>>
>> Well, = 'trustworthy' could be=A0 considered in many angles.
>> If it = is about privacy of the message, a public key based encryption
= >> would provide acceptable privacy.
>> If it is about = reliability of the message delivery, well, a P2P based
>> = asynchronous message delivery (like VM) is most likely less reliable
= >> than a well managed server based system.
>> However, = my experience with Skype's asynchronous message delivery was
= >> not bad. Actually I don't see any significant difference = between it
> and
>> my cellular service provider's VM = service. :-)
>> Reliability is always a challenge for P2P, for = sure. But, I believe it
>
>> is feasible to build a P2P = system for VM acceptable for many
> scenarios.
>>=A0=A0=A0= =A0=A0 > - In mobile networks: The VM can reside in quite stable = peers
>>=A0=A0=A0=A0 inside the
>>=A0=A0=A0=A0=A0 = > wireless base station network. The peers in the base station
= > network
>>=A0=A0=A0=A0=A0 > need no configuration, = etc.
>>
>>=A0=A0=A0=A0 I don't understand. I guess = that could be true if the peers are
> willing
>>=A0=A0=A0= =A0 to store an arbitrary amount of VM indefinitely for anybody. Is
= > that
>>=A0=A0=A0=A0 believable?
>>
= >>
>> It depends.
>> In a very nice = environment where all the peers are willing to
> cooperate
= >> at their best, the peers will store as much as they can. In a = tough
>> environment, the situation will be different.
= >>
>>=A0=A0=A0=A0 This seems to translate to a model = where it is assumed that those
> nodes
>>=A0=A0=A0=A0 = that are on most of the time will be willing to provide VM storage
= > for
>>=A0=A0=A0=A0 those nodes that aren't on most of the = time.
>>
>>
>> This is again related to = reliability of P2P systems or topics like
> free
>> = riders and reputation.
>> A P2P system is a community or = society. To be simple, if many of the
>> members are bad, the = community won't work well. If the majority of the
>
>> = members are good, the community will work well or reasonably.
= >>
>>=A0=A0=A0=A0=A0 > Add to this the conferencing = capability coming from p2p
> application
>>=A0=A0=A0=A0=A0= > layer multicast, the SIP e2e control capabilities (for such as
= >>=A0=A0=A0=A0=A0 > auto-attendant, agent workstation, etc.) = and one has to wonder
> why IT
>>=A0=A0=A0=A0=A0 > = networks, public VoIP networks and end users should support the
> = huge
>>=A0=A0=A0=A0=A0 > cost of hand engineering, testing, = monitoring, maintaining
> server
>>=A0=A0=A0=A0 = based
>>=A0=A0=A0=A0=A0 > VoIP networks. P2P self = configuration is nothing less that
> automation
>>=A0=A0=A0= =A0=A0 > applied to VoIP, plus the shifting of computing to the
= > endpoints,
>>=A0=A0=A0=A0 where
>>=A0=A0=A0=A0=A0= > there is an abundance of unused CPU, storage, bandwidth and
= >>=A0=A0=A0=A0 electricity.
>>=A0=A0=A0=A0=A0 >
= >>=A0=A0=A0=A0=A0 > Eric Burger also notes IM changes = completely the usage for VM
> and may
>>=A0=A0=A0=A0=A0 = > make unnecessary to place calls on VM in the first place.
= >>
>>=A0=A0=A0=A0 I find this more promising.
= >>
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
>>
= >>
>> In overall, are we discussing if P2P systems based = VM can work? I
> think
>> it can work.=A0 Just it = depends on many things.
>> If it is not super-reliable, should = we disregard it? I would say no.
>>
>> On the other = hand, do we have to abandon client server based VM and
>> = switch to P2P system based VM? It is upto each of us.
>> = Client server based VM systems are already there.
>> So why = don't we work on P2P based VM now?
>>=A0
>> = Thanks.
>>
>> Eunsoo
>

= _______________________________________________
P2PSIP mailing = list
P2PSIP@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/p2psip

P2PSIP mailing list
=

= --Apple-Mail-10--203761590-- --===============1540406999== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1540406999==-- From p2psip-bounces@ietf.org Wed Apr 04 08:07:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4Ge-00047s-UE; Wed, 04 Apr 2007 08:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4Gd-00047K-RX for p2psip@ietf.org; Wed, 04 Apr 2007 08:07:11 -0400 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4GZ-0001Xl-JN for p2psip@ietf.org; Wed, 04 Apr 2007 08:07:11 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l34C6rPo008536; Wed, 4 Apr 2007 08:06:53 -0400 Received: from [10.0.1.3] ([24.139.16.154]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l34C6oFM017202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 08:06:52 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF34@namail5.corp.adobe.com> References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> <8B0D63EF-0C0E-47AC-833D-74E3B4905E29@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223ADF34@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: Peer definition in Concept draft Date: Wed, 4 Apr 2007 08:07:22 -0400 To: "Henry Sinnreich" X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 3-Apr-07, at 23:21 , Henry Sinnreich wrote: >> Are we working on a system which is independent of SIP, >> or does the fact that we are the "P2PSIP" group imply >> that we assume all peers support SIP? > > [snip] > > Let's have some I-Ds on this before trying to finalize this > decision on > e-mail. > > Thanks, Henry I agree with Henry. Let's see some I-Ds on how this might work before making a decision. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 09:59:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ61B-0007t1-6F; Wed, 04 Apr 2007 09:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ619-0007sq-3D; Wed, 04 Apr 2007 09:59:19 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ615-0001mS-KM; Wed, 04 Apr 2007 09:59:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ60h-0000rA-D1; Wed, 04 Apr 2007 08:58:56 -0500 From: "Brian Rosen" To: "'Henry Sinnreich'" , "'Michael Slavitch'" , "'Paul Kyzivat'" Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 09:59:04 -0400 Message-ID: <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF2F@namail5.corp.adobe.com> Thread-Index: Acd176Ya+p6xqIGMQfSJrn6cLV80rgACgCmQAAX8woAAAZhX4AAHz3sgACH445A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.1 (+) X-Scan-Signature: 6ddc52d7a0516c9ec326a2a741eefd1a Cc: sipping@ietf.org, p2prg@ietf.org, 'David R Oran' , 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2024221343==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2024221343== Content-Type: multipart/related; boundary="----=_NextPart_000_1E06_01C7769F.E4C51F70" This is a multi-part message in MIME format. ------=_NextPart_000_1E06_01C7769F.E4C51F70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_1E07_01C7769F.E4C51F70" ------=_NextPart_001_1E07_01C7769F.E4C51F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Have you actually ever built an enterprise telephony system? Maybe installed a recent one? Look, every product can be improved, and I do agree with Henry that the enterprise telephony folks haven't caught on (or haven't figured out how to make money on) presence and IM integration. I think there have been plenty of attempts to allow other app integration that have failed pretty much completely despite what we would have thought. My take on this is that enterprise IT (which now owns phones), demands the level of feature set the enterprise PBX guys give them, are pretty much afraid of doing any serious app interaction except in call centers, and would not see any inherent benefit in p2p. "Self Organizing" is not what we are talking about any more than current systems are self organizing. In current systems, except in the very largest systems, there is a server, you configure it, and plug the phones in. They self configure. The configuration on the server is complex, but it's not something that needs a large staff; in most enterprises I know, there is usually one guy (or sometimes one per site) who maintains the configuration part time. How much less do you think you could get, and what do you think you could simplify with p2p? Skype? In an enterprise? Try talking to YOUR staff about that idea and see how far you get. Skype does not provide the feature set enterprise wants. You can claim the staff doesn't know its business I suppose. Let's take one simple example: dial plans. Every enterprise has one. Does Skype? What would p2p do for dial plans that any current system can't do right now? What is the problem: dial plans are evil, we should get rid of them, or dial plans are useful, and SOMEONE has to use some kind of tool to configure them, and having done that, assign extension numbers within the dial plan? What would p2p do for us? D'you want users configuring their own extensions? I see many benefits to p2p, but significantly simplifying enterprise deployment isn't one of them. Brian _____ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Tuesday, April 03, 2007 5:53 PM To: Michael Slavitch; Brian Rosen; Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario I agree with Michael here. The voice-only PBX is pathetic as an enterprise communication and productivity platform (no presence, IM, no integration with apps, etc.) is also exactly the opposite of what self organizing systems provide. As for the usability of those tiny screens and remembering the various commands. Why not just use Skype PC clients or Skype phones instead? At least, they are WiFi and no configuration is required that cannot be done by the user. And they can be used on travel as well. Just think what self organizing and usability means for the maintenance headcount and budget. Not to mention the associated IT systems. P2P SIP in the enterprise is not a PBX replacement any more that SIP is a PSTN replacement, though many decisions makers have not given up :-) Thanks, Henry _____ From: Michael Slavitch [mailto:slavitch@objectworld.com] Sent: Tuesday, April 03, 2007 12:58 PM To: Brian Rosen; Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario "vendors will tell you the things you can automate about provisioning have been automated." The vendors will tell you this because the things that they automate can be summarized as: 1. "not much". 2. What we automate is our proprietary stuff, sod the rest. t's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. I strongly disagree with that. Look at the documentation for products from many of the major vendors, there are stacks of complex details regarding deployment, not very automatic at all, with many of them depending on crufty TFTP or FTP with fixed file locations for provisioning of endpoints. It's horrible. Secondly, "it doesn't help with any of that" is only true in a static fixed universe where you provision once and go away and limit functionality to very basic tasks. Even in that world the number of user change requests on a 2000 user system is on the order of .5%-1% of all endpoints per day on today's relatively static systems, 10 to 20 per day, and that's just basic stuff, done at gunpoint. Routers used to have only static routes too, and web pages were once coded by hand. Regards Michael corp_2colour Michael Slavitch Lead, Technology Initiatives slavitch@objectworld.com From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, April 03, 2007 1:07 PM To: Michael Slavitch; 'Paul Kyzivat' Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran'; 'Henry Sinnreich'; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario I think most enterprise "PBX" vendors will tell you that the things you can automate about provisioning have been automated, and you won't get much a win there. It's things like TN assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems. P2P doesn't help any of that. I worry, quite a bit, that perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. They didn't have to be (SIP was originally designed for smart endpoints). If we make P2PSIP endpoints more closely fit the smart endpoint model, then we make the peer that serves the UAs be the smart box in the middle of the network. Brian _____ From: Michael Slavitch [mailto:slavitch@objectworld.com] Sent: Tuesday, April 03, 2007 10:48 AM To: Paul Kyzivat Cc: P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario The point I am making is that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as well as the mechanisms that make that deployment happen, are already very different world than the canonical IMS/CSSIP one which assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD), B2BUA demarks, network elements, and dumb fixed endpoints. Taking a network as a whole enterprise application software using C/S SIP proxies and UA's already approximates something that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, with gaping ugly holes. P2P has the potential to transform that. Some points I take from the previous discussion: "that a P2P setup will be *free*" - A P2P network may not be free, but the setup (provisioning) will be free, and automatic. This is a major benefit only partially achieved in enterprise networks, a benefit of great value to enterprises that is underserved by vendors. There is no benefit in requiring complex deployments where automation can take its place. Deployment is almost always the biggest cost of enterprise systems dwarfing the cost of the systems themselves. "I think this depends greatly on what expectations / contractual guarantees the enterprise has. It's unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees." - That is why 'expectations/contractual guarantees' need to be built into the automation that exists in the P2P overlay. Self-calculation of such performance metrics is already there in all enterprise devices, the difference being that while WMI/SNMP data is merely collected a P2PSIP network can act automatically based on the metrics within their own nodes, there is a collective 'aha' that forces behavior change based on strict contracts, aka rules. An SLA is easier to maintain if the objects can react accordingly, for example a node with degrading service can notify that it is on the decline forcing others to take over. There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or automation. P2PSIP allows for automation. David Oran wrote: "I'm not saying this can't be made to work, only that it isn't immediately obvious that it has advantages over a classic application/server approach." The immediately obvious advantage to me is standardized ruggedized automation that has economies of scale and operates over multiple domains, eliminating the need for over-engineering, detailed fussy provisioning, and an army of people doing basic monitoring and care-and-feeding. Automation is the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment. This is being done in fits and starts in the enterprise data center. P2PSIP makes it much more comprehensive. People want the world to be predictable and deterministic, and C/S based systems reflect that. That is the biggest problem P2P faces because it flies in the face of tradition. Regards Michael Slavitch corp_2colour 308 Legget Dr. Ottawa Ontario K2K 1Y6 Canada Michael Slavitch Lead, Technology Initiatives slavitch@objectworld.com PSTN: +1.888.398.9698 x225 Fax: +1.613.599.7457 Skype: Objectworld x225 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, April 03, 2007 8:57 AM To: Michael Slavitch Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Michael Slavitch wrote: > Sorry for being late into this discussion, but client-server based VM > isn't truly client-server anymore in anything but the smallest or most > monolithic of enterprise networks, in fact the reality is that most if > not all enterprise networks contain just peers and superpeers with the > difference being partially a marketing decision by the vendors, as you > can charge much more for the servers, and a policy decision made either > automatically by a software deployment system or by IT staff which wants > to place supernodes with data sinks on appropriate equipment. I'm sorry, but I don't understand the point you are trying to make above. You are trying to draw some sort of distinction, but I don't get it. Can you try again. Thanks, Paul > In a > highly distributed environment there are potentially hundreds of > possible data sinks for a given application, with the sink based on > subnet or geographic location or balanced load, this can change rapidly > over time and does. > > In the case of the Microsoft environment such policy is administered and > published between supernodes, ie servers, by Active Directory. It is > advertised to mere peers through DNS. There was much discussion a while > ago about building service discovery environment using DNS instead of a > P2P DHT. It can be argued that a case study of a P2P example done using > DNS is any large Windows Server 2003 based Microsoft network with many > servers and many more clients that also run applications themselves and > are not just dumb terminals. This is almost certainly always the case in > all enterprises. The big difference between C/S SIP and P2PSIP is > automation. What is true is that the square peg in round hole of > overloading DNS makes deployments clumsy and brittle within the > enterprise domain and completely unmanageable and unpublishable outside > the firewall which is why the buck stops there in current enterprise > networking products. > > The difference between C/S and P2P is largely policy and semantics with > the biggest difference being that the decisions and rules are highly > distributed. Apart from that they are not just friends, they are > fraternal twins. > > Regards > > Michael Slavitch > > > > > corp_2colour > > > > > > > 308 Legget Dr. > Ottawa Ontario > K2K 1Y6 Canada > > > > > > > > > > Michael Slavitch > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > PSTN: > > > > +1.888.398.9698 > > > > x225 > > Fax: > > > > +1.613.599.7457 > > > > > > Skype: > > > > Objectworld > > > > > > x225 > > > > > > > > > > > > -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach CanIt if this mail (ID 657805) is spam: Spam: http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=s Not spam: http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=n Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=657805&m=2eb1fdee55b7&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS _____ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. _____ Spam Not spam Forget previous vote _____ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ------=_NextPart_001_1E07_01C7769F.E4C51F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have you actually ever built an = enterprise telephony system?  Maybe installed a recent = one?

 

Look, every product can be = improved, and I do agree with Henry that the enterprise telephony folks haven’t = caught on (or haven’t figured out how to make money on) presence and IM integration.  I think there have been plenty of attempts to allow = other app integration that have failed pretty much completely despite what we = would have thought.

 

My take on this is that enterprise = IT (which now owns phones), demands the level of feature set the enterprise = PBX guys give them, are pretty much afraid of doing any serious app = interaction except in call centers, and would not see any inherent benefit in p2p.  = “Self Organizing” is not what we are talking about any more than current systems are self organizing.  In current systems, except in the = very largest systems, there is a server, you configure it, and plug the = phones in.  They self configure.  The configuration on the server is complex, but = it’s not something that needs a large staff; in most enterprises I know, = there is usually one guy (or sometimes one per site) who maintains the = configuration part time.  How much less do you think you could get, and what do = you think you could simplify with p2p?

 

Skype?  In an = enterprise?  Try talking to YOUR staff about that idea and see how far you get.  =  Skype does not provide the feature set enterprise wants.  You can claim = the staff doesn’t know its business I = suppose.

 

Let’s take one simple = example: dial plans.  Every enterprise has one.  Does Skype?  What = would p2p do for dial plans that any current system can’t do right = now?

 

What is the problem: dial plans are = evil, we should get rid of them, or dial plans are useful, and SOMEONE has to = use some kind of tool to configure them, and having done that, assign = extension numbers within the dial plan?  What would p2p do for us?  = D’you want users configuring their own extensions? =  

 

I see many benefits to p2p, but = significantly simplifying enterprise deployment isn’t one of = them.

 

Brian

 

From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Tuesday, April 03, = 2007 5:53 PM
To: Michael Slavitch; = Brian Rosen; Paul Kyzivat
Cc: P2PSIP Mailing List; = Michael Hammer (mhammer); David R Oran; p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

I agree with Michael here. The = voice-only PBX is pathetic as an enterprise communication and productivity platform (no presence, IM, no integration with apps, etc.) is also exactly the = opposite of what self organizing = systems provide. As for the usability of those tiny screens and remembering the = various commands…

Why not just use Skype PC clients = or Skype phones instead? At least, they are WiFi and no configuration is required = that cannot be done by the user. And they can be used on travel as = well.

 

Just think what self = organizing and usability means for the = maintenance headcount and budget. Not to mention the associated IT = systems.

 

P2P SIP in the enterprise is not a = PBX replacement any more that SIP is a PSTN replacement, though many = decisions makers have not given up J

 

Thanks, = Henry

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 03, = 2007 12:58 PM
To: Brian Rosen; Paul Kyzivat
Cc: P2PSIP Mailing List; = Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

“vendors will tell you the things you can automate about provisioning have been automated.”

 

The vendors will tell you this = because the things that they automate can be summarized = as:

 

1.   = “not = much”.

2.   = What we = automate is our proprietary stuff, sod the rest.

 

t’s things like TN = assignment, and dial plans, and gateway routing, and emergency call provisioning, and permissions, and feature enabling, etc, etc that dominate provisioning of enterprise telephony systems.  P2P = doesn’t help any of that.

 

I strongly disagree with that. =   Look at the documentation for products from many of the major vendors, there = are stacks of complex details regarding deployment,  not very automatic = at all, with many of them depending on crufty TFTP or FTP with fixed file locations for provisioning of endpoints.  It’s = horrible.

Secondly, “it doesn’t = help with any of that” is only true in a static fixed universe where = you provision once and go away and limit functionality to very basic = tasks.   Even in that world the number of user change requests on a 2000 user system = is on the order of .5%-1% of all endpoints per day on today’s relatively = static systems, 10 to 20 per day, and that’s just basic stuff, done at = gunpoint.  Routers used to have only static routes too, and web pages were once = coded by hand.  

 

Regards

 

Michael

 

 

 

3D"corp_2colour"

 

 

 

 

Michael = Slavitch           = ;  

Lead, Technology = Initiatives

slavitch@objectworld.com

 

 

 

 

 

From: = Brian Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, April 03, = 2007 1:07 PM
To: Michael Slavitch; = 'Paul Kyzivat'
Cc: 'P2PSIP Mailing = List'; 'Michael Hammer (mhammer)'; 'David R Oran'; 'Henry Sinnreich'; = p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

I think most enterprise = “PBX” vendors will tell you that the things you can automate about = provisioning have been automated, and you won’t get much a win there. =  It’s things like TN assignment, and dial plans, and gateway routing, and = emergency call provisioning, and permissions, = and feature enabling, etc, etc that dominate provisioning of enterprise = telephony systems.  P2P doesn’t help any of = that.

 

I worry, quite a bit, that = perpetuating SIP UAs (the SIP client) will perpetuate the dumb endpoint model, simply because the way they are made now is that they are dumb endpoints. =  They didn’t have to be (SIP was originally designed for smart endpoints).  If we make P2PSIP endpoints more closely fit the smart endpoint model, then we make the peer that serves the UAs be the smart = box in the middle of the network.

 

Brian

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 03, = 2007 10:48 AM
To: Paul Kyzivat
Cc: P2PSIP Mailing List; = Michael Hammer (mhammer); David R Oran; Henry Sinnreich; p2prg@ietf.org; sipping@ietf.org
Subject: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

The point I am making is  that in the enterprise the actual topological deployments of SIP clients and servers, when implemented as software on generic computing platforms, as = well as the mechanisms that make that = deployment happen, are already very different world than the canonical IMS/CSSIP one which  assumes SIP as core monolithic servers, fixed enterprise network integrated access devices (IAD),  B2BUA demarks, network elements, and dumb fixed endpoints.  Taking a network as a = whole enterprise application software using C/S SIP proxies and UA’s = already approximates something = that is close to what is being called P2PSIP, only in a manner that is highly proprietary, closed, somewhat brittle and baroque, local, and ad-hoc, = with gaping ugly holes.  P2P has the potential to transform = that.

 

Some points I take from the previous = discussion:

“that a P2P setup will be *free*”

 

-    A P2P = network may not be free, but the setup (provisioning) will be free, and = automatic.  This is a major benefit only partially achieved in enterprise = networks,  a benefit of great value to enterprises that is underserved by = vendors.  There is no benefit in requiring complex deployments where automation = can take its place.  Deployment is almost always the biggest cost of = enterprise systems dwarfing the cost of the systems = themselves.

 

“I think this depends greatly on what expectations / contractual guarantees = the enterprise has. It’s unclear to me what guarantees can be made = about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make = guarantees.”

 

-   That is why = ‘expectations/contractual guarantees’ need to be built into the automation that exists in = the P2P overlay.  Self-calculation of such performance metrics is already = there in all enterprise devices, the difference being that while WMI/SNMP data is = merely collected a P2PSIP network can act automatically based on the metrics = within their own nodes, there is a collective ‘aha’ that forces = behavior change based on strict contracts, aka rules.  An SLA is easier to maintain if the objects can react accordingly, for example = a node with degrading service can notify that it is on the decline forcing = others to take over. 

 

There is an old traffic engineering axiom about service guarantees: it can be achieved through two ways: over engineering or  automation.  = P2PSIP allows for automation.

 

 David Oran wrote:

 

“I'm not saying this can't be made to work, only that it isn't immediately = obvious that it has advantages over a classic application/server = approach.”

 

The immediately obvious advantage to me is standardized ruggedized = automation that has economies of scale and operates over multiple domains, eliminating = the need for over-engineering,  detailed fussy provisioning,  and an = army of people doing basic monitoring and care-and-feeding.  Automation is = the key, a dynamic statistical network vs. one that is fixed and assumed deterministic will always win out over time given a fractal operating environment.   This is being done in fits and starts in the enterprise data center.   P2PSIP makes it much more = comprehensive.   People want the world to be predictable and deterministic,  = and C/S based systems reflect that. That is the biggest problem P2P faces = because it flies in the face of tradition. =   

 

Regards

 

Michael Slavitch

 

 

 

 

 

3D"corp_2colour"

 

308 Legget = Dr.
Ottawa = Ontario
K2K 1Y6 Canada

<= /span>

 

Michael = Slavitch           = ;  

Lead, Technology Initiatives

slavitch@objectworld.com

PSTN: 

+1.888.398.9698

x225

Fax:

+1.613.599.7457

 

Skype:      

 Objectworld   =

x225

<= /span>

 

 

 

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Tuesday, April 03, 2007 8:57 AM
To: Michael Slavitch
Cc: Henry Sinnreich; P2PSIP Mailing List; Michael Hammer (mhammer); = David R Oran; p2prg@ietf.org; sipping@ietf.org; zhuxian
Subject: Re: [P2Prg] RE: = [Sipping] Simple SIP usage scenario

 

 

 

Michael Slavitch wrote:

> Sorry for being late into this discussion, but client-server based VM =

> isn't truly client-server anymore in anything but the smallest or most =

> monolithic of enterprise networks, in fact the reality is that most if =

> not all enterprise networks contain just peers and superpeers with the =

> difference being partially a marketing decision by the vendors, as you =

> can charge much more for = the servers, and a policy decision made either

> automatically by a software deployment system or by IT staff which wants =

> to place supernodes with data sinks on appropriate = equipment.

 

I'm sorry, but I don't understand the point you are trying to make =

above. You are trying to draw some sort of distinction, but I don't get =

it. Can you try again.

 

       &nbs= p;        Thanks,

       &nbs= p;        Paul

 

> In a

> highly distributed environment there are potentially hundreds of =

> possible data sinks for a given application, with the sink based on =

> subnet or geographic location or balanced load, this can change rapidly =

> over time and does.

>

> In the case of the Microsoft environment such policy is administered and =

> published between supernodes, ie servers, by Active Directory.  It = is

> advertised to mere peers through DNS.  There was much discussion a = while

> ago about building service discovery environment using DNS instead of a =

> P2P DHT.  It can be argued that a case study of a P2P example done using

> DNS is any large Windows = Server 2003 based Microsoft network with many

> servers and many more clients that also run applications themselves and =

> are not just dumb terminals. This is almost certainly always the case in =

> all enterprises. The big difference between C/S SIP and P2PSIP is =

> automation. What is true is that the square peg in round hole of =

> overloading DNS makes deployments clumsy and brittle within the =

> enterprise domain and completely unmanageable and unpublishable outside =

> the firewall which is why the buck stops there in current enterprise =

> networking products.

>

> The difference between C/S and P2P is largely policy and semantics with

> the biggest difference being that the decisions and rules are highly =

> distributed.  Apart from that they are not just friends, they are =

> fraternal twins.

>

> Regards

>

> Michael Slavitch

>

> 

>

>

> corp_2colour

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://w= ww.objectworld.com/>

>

> 

>

>             =

>

> 308 Legget = Dr.

> Ottawa = Ontario

> K2K 1Y6 Canada

>

>             =

>

> <https://firewall.objectworld.com/exchweb/bin/redir.asp?URL=3Dhttp://m= aps.google.ca/maps?f=3Dq%26hl=3Den%26q=3D308%2BLegget%2BDrive%2BOttawa%2B= Ontario%2BK2K%2B1Y6%26layer=3D%26sll=3D45.341061,-75.904541%26sspn=3D0.00= 7119,0.023839%26ie=3DUTF8%26z=3D18%26ll=3D45.341061,-75.904541%26spn=3D0.= 00178,0.00596%26t=3Dh%26om=3D1>

>

>             =

>

> 

>

> Michael = Slavitch           = ; 

>

> Lead, Technology Initiatives

>

> slavitch@objectworld.com = <mailto:slavitch@objectworld.com>

>

>             =

>

> PSTN:

>

>             =

>

> +1.888.398.9698

>

>             =

>

> x225

>

> Fax:

>

>             =

>

> +1.613.599.7457

>

>             =

>

> 

>

> Skype:     

>

>             =

>

>   Objectworld

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Norte= l,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME= %20and%20MME.EML/>  

>

>

>             =

>

> x225

>

>             =

>

> <https://firewall.objectworld.com/exchange/slavitch/Sent%20Items/Norte= l,%20MSFT%20chase%20carriers%20with%20new%20hosted%20offering%20for%20SME= %20and%20MME.EML/>

>

>             =

>

> 

>

> 

>

>

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS<= /font>

----------------------------------------------= --------

 

Teach CanIt if this mail (ID 657805) is spam:

Spam:       = ; http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Ds

Not spam:    http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Dn

Forget vote: = http://canitpro-int.objectworld.com/canit/b.php?i=3D657805&m=3D2eb1fd= ee55b7&c=3Df

----------------------------------------------= --------

END-ANTISPAM-VOTING-LINKS

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of the = author and may not represent those of Objectworld Communications = Corp.

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of = the author and may not represent those of Objectworld Communications = Corp.

------=_NextPart_001_1E07_01C7769F.E4C51F70-- ------=_NextPart_000_1E06_01C7769F.E4C51F70 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAaABoDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1Ga7l kZ2SdokV2VQgXJwcEnIPcHpVSTW7uHqYHA7bCCfxz/Skuiv9qSwFtitMoA/3gMn8yab/AGWls8lx qTBbeE5HP+s/z6V4051nJ8j2ervov+AYty6GrpuqQ6lGxQFJE++hPT/EVdrjtEuvN8S+ZEuxJjIS Pbkj+Qrsa7MDiHXpcz3Tt6lwlzIyNa0hr7E8GPNAwy5xvHb8axbu31G6jSO6W5ZYRwPKbH1JAwTX Y0VFfAQqyck7X37MUqaZx2k6cf7QheCQMUcFipyFAPOfTjj8a7GiitcLhY4eLinuOMeVH//Z ------=_NextPart_000_1E06_01C7769F.E4C51F70 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAdAB0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0/VNW WCU20cnllQPMkAyVz0A9/wCVUylrNEHWKOZjysk+XP5nmua1W8kXU7pZDg+e/wCW7A/TFPs9UmmU Wquq8fK3cf4168cNywTR5EsTzTakdDFqT2M20l2j6mMknI7lc8j6dK6GORJY1kjYMrDII7ivOruS eB0lklDljgHNdh4ald9Fi39iwX/dycfpiufFUVGKmjowtZyk4M5/xhoUzXDX9qhbf/rFA5z6j1rj o5pILhGIHytzzivZnRZFKsAQazptCspX3NGM/SnQx0qceWSuia+AjUnzxdmef2ttd61f5XcIQcBs cAe3qa9J0+1W0s44VGAqgAegotrC3th8ic+tWq56+IlWavokdFDDxop21b6n/9k= ------=_NextPart_000_1E06_01C7769F.E4C51F70 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6 +0EbNruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHExlWYK4wpGMhue leLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9clnAj17UWQKd3+kNjPb+tN/s+6bR 21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHN R/8AAlv8a9P8NWv/AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1U9W1W00TSrjU76Qx 29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GFE6eqnPpzXoHzp19FZniHXIPDmhXOr3Mc ksNsoZkjxuOSBxn61ieHPiLpniHVV0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc 3dpDNClvcvbMJQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq39uaT FqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jHGM/M3Psa2tC1uy8RaPb6 rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFreaPqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+ w3Vj5hYeRdJskXBxyKANGisRvFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6v RZpDhd+8n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA2fxg0W4n Tz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumtpPNA+Zh3GD0oA26KiuJltraW dgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPKt7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8 kKcE9M5IrD1H4h6Hpltazzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+ jtPI2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1LvgEhv5V4sNKivt c+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m1u7X7PGJ4vL+zRoFMe3J3YHY5x9a 1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej 3PAy/C1qWJTmmkt+vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLNd74l0OHxJ4evNInk MSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZrKOGLYFXGMse5wf/AK9ekfLl74p/8k31 j/rmv/oa1xfhqXUW+IHhl/E0MVuf7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5 C4YHp+Fc5oHgDVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu11WK/ m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYHA9OBQByXjWXV4fi9oj6F b29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRqZ0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xa WxgBkg8zqWycHjo1dFoNtq1ppaQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs 9CsdDjg8OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/gK2/CHhuL wn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ceFpvFmlWtlDdJbNBdpcFnUsCF B44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1 Lx54N/4TPT7K2FwsDWt0sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/ AJoeP+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6Wv+oH+7/SvnjT 59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrzofC+5XwYNFXUoReQ6l9vt7nyzhD6 YznpmgD0RFCIqDooArz34S/e8Uf9hmWvQk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2 gYsC2SMnOOOOKAO41X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689GHQ1lT+EdCuQBLYK2 CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgBumKworm4ESATyYCj+M0j3M5KZnk4bj5z Xjey97c+4WK/dr3e39bG/ChiiCEjIz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5 OW5+c+lCpbu45YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckxNyf9 9q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFAH//Z ------=_NextPart_000_1E06_01C7769F.E4C51F70-- --===============2024221343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2024221343==-- From p2psip-bounces@ietf.org Wed Apr 04 10:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6MQ-0008CA-KC; Wed, 04 Apr 2007 10:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6MP-00086x-06 for p2psip@ietf.org; Wed, 04 Apr 2007 10:21:17 -0400 Received: from bay0-omc2-s10.bay0.hotmail.com ([65.54.246.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6MM-0003Ul-M0 for p2psip@ietf.org; Wed, 04 Apr 2007 10:21:16 -0400 Received: from bayc1-pasmtp01.bayc1.hotmail.com ([65.54.191.161]) by bay0-omc2-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 4 Apr 2007 07:21:12 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp01.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 07:21:11 -0700 Message-ID: <001e01c776c4$7d7a40a0$65500a0a@ronin> From: "Eric Cooper" To: "Brian Rosen" , "'Henry Sinnreich'" , "'Michael Slavitch'" , "'Paul Kyzivat'" References: <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 10:20:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 04 Apr 2007 14:21:11.0728 (UTC) FILETIME=[7EDABB00:01C776C4] X-Spam-Score: 2.1 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'David R Oran' , 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Have you actually ever built an enterprise telephony system? Maybe > installed a recent one? >=20 > I see many benefits to p2p, but significantly simplifying enterprise > deployment isn't one of them. >=20 I know of a couple of major enterprise PBX vendors who offer 1 and 2 = week-long training courses so that their VARs can learn to install and = configure the PBX. Having had the training, it will generally take an = hour or two of configuration before the PBX gets to the point where two = extensions can call each other. On the other hand, there are P2P PBX systems emerging that can be = unboxed, plugged in and start making calls in under 2 minutes. So I'd = have to say that P2P does have a lot to offer in this area. Best Regards, Eric. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 10:37:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6cJ-0002Nm-N6; Wed, 04 Apr 2007 10:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6cI-0002Kn-22 for p2psip@ietf.org; Wed, 04 Apr 2007 10:37:42 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6cG-0002Zj-P5 for p2psip@ietf.org; Wed, 04 Apr 2007 10:37:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ6bx-0001QN-6f; Wed, 04 Apr 2007 09:37:22 -0500 From: "Brian Rosen" To: "'Eric Cooper'" , "'Henry Sinnreich'" , "'Michael Slavitch'" , "'Paul Kyzivat'" Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 10:37:34 -0400 Message-ID: <1e1a01c776c6$cb631920$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <001e01c776c4$7d7a40a0$65500a0a@ronin> Thread-Index: Acd2xHas6qFcwhrCSP6Luy1CYwTBjgAAHvgQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'David R Oran' , 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I know of a couple of major enterprise PBX vendors who offer 1 and 2 week- > long training courses so that their VARs can learn to install and > configure the PBX. Having had the training, it will generally take an > hour or two of configuration before the PBX gets to the point where two > extensions can call each other. > > On the other hand, there are P2P PBX systems emerging that can be unboxed, > plugged in and start making calls in under 2 minutes. So I'd have to say > that P2P does have a lot to offer in this area. With comparable feature sets? I know of IP PBXs that can be unboxed, plugged in, and start making calls in maybe 10 minutes. I'm not sure the difference between 2 and 10 is that significant. What does p2p have, inherently, that makes it easier? What makes the 2 minutes work that, say, Asterisk doesn't have? I'll bet you its features. If you have no features, everything is simple. If you support any fraction of the feature set in an IP PBX, you're where they are now. I once made a small wager with someone that if IP PBX vendors offered simpler systems at a lower price, they would make much more money: the idea being that the complexity of the feature set had driven up the price of the systems so far that buyers would trade simplicity for price. I thought if you gave them the "top 25" feature set, with roughly out-of-the-box functionality, that nearly all enterprises would be satisfied. He showed me a valid marketing study that showed, quite clearly, that I was wrong. Users DEMANDED the features. They simply wouldn't purchase systems that didn't have the features they wanted, and price wouldn't change their mind (at least in the range of reasonable price differences). Now, I'm not so sure if you asked the actual USERS of these systems if they agreed. But they don't make the purchase decisions. The ones that do want features. The guys that run the big IP PBX businesses are not dumb. They know their customers. If there was money to be made in 2 minute set up, they could provide that right now (you can find some out there, do a web search). But tell me anyways: what does p2p do that simplifies configuration for enterprise? Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 10:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6vb-0008Ru-Gm; Wed, 04 Apr 2007 10:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6va-0008Mm-7q for p2psip@ietf.org; Wed, 04 Apr 2007 10:57:38 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6nN-0007dB-W6 for p2psip@ietf.org; Wed, 04 Apr 2007 10:49:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ6mj-0004ft-Pp for p2psip@ietf.org; Wed, 04 Apr 2007 09:48:52 -0500 From: "Brian Rosen" To: "'P2PSIP Mailing List'" Date: Wed, 4 Apr 2007 10:48:43 -0400 Message-ID: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73Og== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org One of the things I think we blew big time on sip was that we didn't require some fundamental things in every sip device to differentiate them from existing technology. We have an opportunity to fix that with p2psip, and I think we should do it. Now, admittedly, what I'm talking about is somewhat a "marketing" issue, but it's a very real thing that we could do which I believe would be helpful. So, I propose: 1. We do not support any form of insecure signaling. We define the protocol to reject attempts to signal without TLS (or whatever). I'm assuming the protocols are TCP only. The overlay defines what credentials are needed (and supplies them). 2. We do not support any form of insecure media. It's always encrypted. This is the tough one, especially if we say we support SIP UAs. 3. All devices that support audio support wideband audio. 4. All devices support text (IM and real time interactive). 5. All devices support presence. We define a minimal set of presence characteristics that all devices publish. 6. We define a minimal feature set (something like unattended and attended transfer, call forward no answer, call forward busy, basic conferencing, ...) that every device supports the same way. 7. All devices work behind a given set of NAT configurations, given a specified set of ICE components (or whatever). 8. We define what constitutes a minimal configuration set; all of the above just work with this level of configuration (and credentials from an overlay). We of course define the configuration mechanism. I'm thinking that we do this by configuring the device with the credentials, and using the overlay to provide any other configuration (which could be influenced by, say, a website the overlay runs) automatically. All of these are designed to be minimum capabilities, but the idea is that ANY device, with credentials on an overlay, can expect to communicate with any other device on that overlay with ALL of the above. Finally, I propose we invent a phrase, something like "p2psip conformant" which means a device that does that. No protocol police, but the idea is that if you say you have a "p2psip conformant" device, it means all of the above. Perhaps we have a way to signal that. This is pretty much what Skype does. Why should we not do that, at least? Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 10:58:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6wW-0000q0-LN; Wed, 04 Apr 2007 10:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6wU-0000k7-F9; Wed, 04 Apr 2007 10:58:34 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ6jQ-0006Ms-J7; Wed, 04 Apr 2007 10:45:11 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 07:45:02 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34EiQD1028170; Wed, 4 Apr 2007 07:44:33 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34EinI9007073; Wed, 4 Apr 2007 07:44:49 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 07:44:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Apr 2007 07:44:08 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF38@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2P SIP service assurance (was Simple SIP usage scenario) Thread-Index: Acd1fDvzIhowLornTwyehPLXZ9zr5AA/ypd/ABGlquA= References: From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 04 Apr 2007 14:44:54.0268 (UTC) FILETIME=[CEC11BC0:01C776C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cc9f19007352bcbade9ec25b8f17862 Cc: sipping@ietf.org, p2prg@ietf.org, oran@cisco.com, p2psip@ietf.org, mhammer@cisco.com Subject: [P2PSIP] P2P SIP service assurance (was Simple SIP usage scenario) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1028348050==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1028348050== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776C7.CE6A1169" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776C7.CE6A1169 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colin, Paul, =20 Thanks for raising the valid issue about service assurance.=20 As engineers, we know the service assurance is more than a piece of legal paper and must be based on the following: =20 - Adequate bandwidth, - Geographic diversity, - Simplicity; so things can be managed, - Security that can be audited, - Safe data retention: Replication and the geographic diversity of peer nodes of the overlay, - Economy of scale: All peers have software with identical behavior, - No configuration is required or possible. The customer just plugs in the gateway box. This is real service automation. - Cost containment: P2P self configuration is unbeatable. Count all the savings in CAPEX and OPEX by not having any network based VoIP infrastructure. Save all that electricity and real estate in the data centers. - Flexibility for new applications: The API between SIP and the DHT overlay, - No lock-in from single source: The applications are in the endpoints. Buy them from anywhere. - Automatic updates from the application provider: This is current PC SW state of the art and works for both the (1) P2P software in the access device and (2) for the application software, such as presence, IM, voice, multimedia, etc. No or minimal is staff required. - Last but not least, besides SIP enabled communications, the overlay can also serve for many other applications for your users: Content distribution, application layer multicast for conferences, directory search, IM+A/V chat rooms, name services, etc. =20 All of the above can be easily implemented by porting well documented open source software into the residential access box or in the integrated access device (IAD) for enterprises. Just check out http://opendht.org/ and other similar sites. =20 Please don't take my word for it, just make for yourself a comparison table for your network. If you can't share the comparison with the list, can you share it with me in private? :-) =20 * as an employee of a carrier =20 I worked most of my career for carriers, so that's what prompted the above considerations. =20 Thanks, Henry =20 ________________________________ From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]=20 Sent: Wednesday, April 04, 2007 12:38 AM To: pkyzivat@cisco.com; Henry Sinnreich Cc: p2psip@ietf.org; mhammer@cisco.com; oran@cisco.com; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 Henry, I like your idea of deploying sip peers in edge devices. However, as an employee of a carrier I would like to see how a carrier is able to provide service asurance to be able to provide compliant handling. Many of our customers do not understand how to install these gateways themselves, let alone how to troubleshoot. This is even more important for enterprises, which often insist on SLAs which include troubleshoot resolution limits. -----Original Message----- From: "Paul Kyzivat" To: "Henry Sinnreich" Cc: "P2PSIP Mailing List" ; "Michael Hammer (mhammer)" ; "David R Oran" ; "p2prg@ietf.org" ; "sipping@ietf.org" Sent: 3-4-07 01:11 Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Henry Sinnreich wrote: > Paul, > >> I more or less agree with the final conclusion below. > > This is good starting point to discuss some usage scenarios. > > Putting on my former hat as an employee for a carrier, I cannot overlook > the following: > > P2P SIP implemented correctly in the residential access box or cable > set-top box indeed is a good or better replacement for the entire VoIP > network infrastructure (cost, operations, new services, etc). > Integrated access devices for the enterprise can probably play a similar > role, not to mention existing P2P PBX products (please refer to all the > advantages of P2P that need not repeated here). > > What do people think of these three usage scenarios for P2P SIP: > - SIP peer in the DSL access device, > - SIP peer in the cable access device, These seem quite reasonable, assuming that a device connected at this point is able to function properly as a peer. (I haven't been following what the assumptions are about required network capabilities of peers.) > - SIP peer in enterprise network integrated access device (IAD). I think this depends greatly on what expectations / contractual guarantees the enterprise has. Its unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees. Paul > Note that these examples imply very low churn for the peers and add the > data retention resilience of P2P (geographic diversity is native and > mobile, etc.). Incidentally, NAT traversal may also not be a problem, or > at least an easier problem. > > What do you all think? > > I have taken the liberty to copy the P2P SIP list, since the low churn > scenarios are of interest for the DHT selection. Or just pick the same > DHT for all scenarios anyway? I don't think so. > > Thanks, Henry > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, March 30, 2007 6:31 PM > To: Eunsoo Shim > Cc: Henry Sinnreich; Michael Hammer (mhammer); David R Oran; > p2prg@ietf.org; sipping@ietf.org; zhuxian > Subject: Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > I more or less agree with the final conclusion below. > > My main point here is that P2P and C/S need not be enemies. Nor is a > total C/S system necessarily evil. What is most evil is *bundling* of > services that prevents freedom of choice. > > I think I would be quite happy with a SP that provides a registrar/proxy > > and allows me to provide all other features as I see fit - by taking > them ala carte from the SP, or subscribing to them from one or more > other SPs, or by providing them myself via appliances I own. If that > registrar/proxy was replaced by a P2P sip community, the differences, if > > any, would hopefully be more a function of the implementation and the > business models of those involved than the architecture. > > (I gather the general assumption is that a P2P setup will be *free*. But > > I have a hard time believing that. If most of the usage is by mobile > devices that can't be peers, then somebody will have to pay for enough > peers to support them. If it isn't free, then how is it better than a > well engineered C/S system?) > > So I think the key thing here is that some features will require getting > > some help from another node. There ought to be the option to pick a > different source for each helper you require, and an ability for it all > to play together. > > Paul > > Eunsoo Shim wrote: >> Please see my inline comment. >> >> On 3/30/07, *Paul Kyzivat* > > wrote: >> >> >> >> Henry Sinnreich wrote: >> > David Oran wrote (with regard to voice mail): >> > >> >> I'm not saying this can't be made to work, only that it isn't >> > immediately >obvious that it has advantages over a classic >> application >> > server >approach. >> > >> > The answer for VM is "it depends": >> > >> >> >> I agree. It really depends. Certainly there are tradeoffs. >> >> > There are several commercial P2P IP PBX solutions without any >> server for >> > VM or anything else. No doubt the IT organization appreciates > just >> > having to plug in the IP phones and GWY to the PSTN without any >> > configuration ever for VM or any other PBX feature. >> >> I don't understand. Are you saying they don't have VM, or that > they >> don't have a *server* for VM? >> >> >> I guess they don't have a *server* for VM. >> >> > For public P2P SIP networks there are two more scenarios where > VM can >> > reside (and without ever spending one cent on VM servers + IT >> systems): >> > >> > - In Cable and DSL service provider networks: The residential >> router can >> > act as a voice recorder >> >> That is simply an example of the user having an appliance of his > own >> that provides VM service. >> >> > and P2P can cover the not too frequent cases, >> > where the router is not in operation, so the data is backed up > in >> other >> > peer residential gateways (encrypted). >> >> I guess I just need to have more info about how this would work > before I >> will be convinced it is feasible and trustworthy. >> >> >> Well, 'trustworthy' could be considered in many angles. >> If it is about privacy of the message, a public key based encryption >> would provide acceptable privacy. >> If it is about reliability of the message delivery, well, a P2P based >> asynchronous message delivery (like VM) is most likely less reliable >> than a well managed server based system. >> However, my experience with Skype's asynchronous message delivery was >> not bad. Actually I don't see any significant difference between it > and >> my cellular service provider's VM service. :-) >> Reliability is always a challenge for P2P, for sure. But, I believe it > >> is feasible to build a P2P system for VM acceptable for many > scenarios. >> > - In mobile networks: The VM can reside in quite stable peers >> inside the >> > wireless base station network. The peers in the base station > network >> > need no configuration, etc. >> >> I don't understand. I guess that could be true if the peers are > willing >> to store an arbitrary amount of VM indefinitely for anybody. Is > that >> believable? >> >> >> It depends. >> In a very nice environment where all the peers are willing to > cooperate >> at their best, the peers will store as much as they can. In a tough >> environment, the situation will be different. >> >> This seems to translate to a model where it is assumed that those > nodes >> that are on most of the time will be willing to provide VM storage > for >> those nodes that aren't on most of the time. >> >> >> This is again related to reliability of P2P systems or topics like > free >> riders and reputation. >> A P2P system is a community or society. To be simple, if many of the >> members are bad, the community won't work well. If the majority of the > >> members are good, the community will work well or reasonably. >> >> > Add to this the conferencing capability coming from p2p > application >> > layer multicast, the SIP e2e control capabilities (for such as >> > auto-attendant, agent workstation, etc.) and one has to wonder > why IT >> > networks, public VoIP networks and end users should support the > huge >> > cost of hand engineering, testing, monitoring, maintaining > server >> based >> > VoIP networks. P2P self configuration is nothing less that > automation >> > applied to VoIP, plus the shifting of computing to the > endpoints, >> where >> > there is an abundance of unused CPU, storage, bandwidth and >> electricity. >> > >> > Eric Burger also notes IM changes completely the usage for VM > and may >> > make unnecessary to place calls on VM in the first place. >> >> I find this more promising. >> >> =20 >> >> >> In overall, are we discussing if P2P systems based VM can work? I > think >> it can work. Just it depends on many things. >> If it is not super-reliable, should we disregard it? I would say no. >> >> On the other hand, do we have to abandon client server based VM and >> switch to P2P system based VM? It is upto each of us. >> Client server based VM systems are already there. >> So why don't we work on P2P based VM now? >>=20 >> Thanks. >> >> Eunsoo > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_001_01C776C7.CE6A1169 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage = scenario

Colin, = Paul,

 

Thanks for raising the valid issue = about service assurance.

As engineers, we know the service assurance is more than a piece of legal paper and must be based on the following:

 

-          Adequate bandwidth,

-          Geographic diversity,

-          Simplicity; so things can be managed,

-          Security that can be audited,

-          Safe data retention: Replication and the geographic diversity of peer nodes of the overlay,

-          Economy of scale: All peers have software with identical = behavior,

-          No configuration is required or possible. The customer just plugs in the = gateway box. This is real service automation.

-          Cost containment: P2P self configuration is unbeatable. Count all the savings = in CAPEX and OPEX by not having any network based VoIP infrastructure. Save = all that electricity and real estate in the data = centers.

-          Flexibility for new applications: The API between SIP and the DHT = overlay,

-          No lock-in from single source: The applications are in the endpoints. Buy = them from anywhere.

-          Automatic updates from the application provider: This is current PC SW state of = the art and works for both the (1) P2P software in the access device and (2) for = the application software, such as presence, IM, voice, multimedia, etc. No = or minimal is staff required.

-          Last but not least, besides SIP enabled communications, the overlay can also = serve for many other applications for your users: Content distribution, application = layer multicast for conferences, directory search, IM+A/V chat rooms, name = services, etc.

 

All of the above can be easily = implemented by porting well documented open source software into the residential = access box or in the integrated access device (IAD) for enterprises. Just check out = http://opendht.org/ and other similar = sites.

 

Please don’t take my word for = it, just make for yourself a comparison table for your network. If you = can’t share the comparison with the list, can you share it with me in private? = J

 

Ø       as an employee of a = carrier

 

I worked most of my career for carriers, so that’s what = prompted the above considerations.

 

Thanks, = Henry

 

From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]
Sent: Wednesday, April = 04, 2007 12:38 AM
To: pkyzivat@cisco.com; = Henry Sinnreich
Cc: = p2psip@ietf.org; mhammer@cisco.com; oran@cisco.com; = p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] Re: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

Henry,

I like your idea of deploying sip peers in edge devices. However, as an employee of a carrier I would like to see how a carrier is able to = provide service asurance to be able to provide compliant handling. Many of our customers do not understand how to install these gateways themselves, = let alone how to troubleshoot.

This is even more important for enterprises, which often  insist on = SLAs which include troubleshoot resolution limits.

-----Original Message-----
From: "Paul = Kyzivat" <pkyzivat@cisco.com>
To: "Henry Sinnreich" <hsinnrei@adobe.com>
Cc: "P2PSIP Mailing = List" <p2psip@ietf.org>; = "Michael Hammer (mhammer)" <mhammer@cisco.com>; "David R = Oran" <oran@cisco.com>; "p2prg@ietf.org" <p2prg@ietf.org>; = "sipping@ietf.org" <sipping@ietf.org>
Sent: 3-4-07 01:11
Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario



Henry Sinnreich wrote:
> Paul,
>
>> I more or less agree with the final conclusion below.
>
> This is good starting point to discuss some usage scenarios.
>
> Putting on my former hat as an employee for a carrier, I cannot = overlook
> the following:
>
> P2P SIP implemented correctly in the residential access box or = cable
> set-top box indeed is a good or better replacement for the entire = VoIP
> network infrastructure (cost, operations, new services, etc).
> Integrated access devices for the enterprise can probably play a = similar
> role, not to mention existing P2P PBX products (please refer to all = the
> advantages of P2P that need not repeated here).
>
> What do people think of these three usage scenarios for P2P = SIP:
> - SIP peer in the DSL access device,
> - SIP peer in the cable access device,

These seem quite reasonable, assuming that a device connected at = this
point is able to function properly as a peer. (I haven't been = following
what the assumptions are about required network capabilities of = peers.)

> - SIP peer in enterprise network integrated access device = (IAD).

I think this depends greatly on what expectations / contractual
guarantees the enterprise has. Its unclear to me what guarantees can = be
made about a P2PSIP network will be able to make, and its unclear = what
kind of infrastructure would be installed by/for someone willing to = make
guarantees.

        Paul

> Note that these examples imply very low churn for the peers and add = the
> data retention resilience of P2P (geographic diversity is native = and
> mobile, etc.). Incidentally, NAT traversal may also not be a = problem, or
> at least an easier problem.
>
> What do you all think?
>
> I have taken the liberty to copy the P2P SIP list, since the low = churn
> scenarios are of interest for the DHT selection. Or just pick the = same
> DHT for all scenarios anyway? I don't think so.
>
> Thanks, Henry
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, March 30, 2007 6:31 PM
> To: Eunsoo Shim
> Cc: Henry Sinnreich; Michael = Hammer (mhammer); David R = Oran;
> p2prg@ietf.org; sipping@ietf.org; zhuxian
> Subject: Re: [P2Prg] = RE: [Sipping] Simple SIP usage scenario
>
> I more or less agree with the final conclusion below.
>
> My main point here is that P2P and C/S need not be enemies. Nor is = a
> total C/S system necessarily evil. What is most evil is *bundling* = of
> services that prevents freedom of choice.
>
> I think I would be quite happy with a SP that provides a = registrar/proxy
>
> and allows me to provide all other features as I see fit - by = taking
> them ala carte from the SP, or subscribing to them from one or = more
> other SPs, or by providing them myself via appliances I own. If = that
> registrar/proxy was replaced by a P2P sip community, the = differences, if
>
> any, would hopefully be more a function of the implementation and = the
> business models of those involved than the architecture.
>
> (I gather the general assumption is that a P2P setup will be = *free*. But
>
> I have a hard time believing that. If most of the usage is by = mobile
> devices that can't be peers, then somebody will have to pay for = enough
> peers to support them. If it isn't free, then how is it better than = a
> well engineered C/S system?)
>
> So I think the key thing here is that some features will require = getting
>
> some help from another node. There ought to be the option to pick = a
> different source for each helper you require, and an ability for it = all
> to play together.
>
>       Paul
>
> Eunsoo Shim wrote:
>> Please see my inline comment.
>>
>> On 3/30/07, *Paul = Kyzivat* <pkyzivat@cisco.com
>> <mailto:pkyzivat@cisco.com>> wrote:
>>
>>
>>
>>     Henry Sinnreich wrote:
>>      > David Oran wrote (with = regard to voice mail):
>>      >
>>      >> I'm not saying this = can't be made to work, only that it isn't
>>      > immediately >obvious that = it has advantages over a classic
>>     application
>>      > server >approach.
>>      >
>>      > The answer for VM is = "it depends":
>>      >
>>
>>
>> I agree. It really depends. Certainly there are tradeoffs.
>>
>>      > There are several commercial = P2P IP PBX solutions without any
>>     server for
>>      > VM or anything else. No = doubt the IT organization = appreciates
> just
>>      > having to plug in the IP = phones and GWY to the PSTN without any
>>      > configuration ever for VM or = any other PBX feature.
>>
>>     I don't understand. Are you saying they = don't have VM, or that
> they
>>     don't have a *server* for VM?
>>
>>
>> I guess they don't have a  *server* for  VM.
>>
>>      > For public P2P SIP networks = there are two more scenarios where
> VM can
>>      > reside (and without ever = spending one cent on VM servers + IT
>>     systems):
>>      >
>>      > - In Cable and DSL service = provider networks: The residential
>>     router can
>>      > act as a voice recorder
>>
>>     That is simply an example of the user = having an appliance of his
> own
>>     that provides VM service.
>>
>>      > and P2P can cover the not = too frequent cases,
>>      > where the router is not in operation, so the data is backed up
> in
>>     other
>>      > peer residential gateways (encrypted).
>>
>>     I guess I just need to have more info = about how this would work
> before I
>>     will be convinced it is feasible and trustworthy.
>>
>>
>> Well, 'trustworthy' could be  considered in many = angles.
>> If it is about privacy of the message, a public key based = encryption
>> would provide acceptable privacy.
>> If it is about reliability of the message delivery, well, a P2P = based
>> asynchronous message delivery (like VM) is most likely less = reliable
>> than a well managed server based system.
>> However, my experience with Skype's asynchronous message = delivery was
>> not bad. Actually I don't see any significant difference = between it
> and
>> my cellular service provider's VM service. :-)
>> Reliability is always a challenge for P2P, for sure. But, I = believe it
>
>> is feasible to build a P2P system for VM acceptable for = many
> scenarios.
>>      > - In mobile networks: The VM = can reside in quite stable peers
>>     inside the
>>      > wireless base station = network. The peers in the base station
> network
>>      > need no configuration, = etc.
>>
>>     I don't understand. I guess that could = be true if the peers are
> willing
>>     to store an arbitrary amount of VM indefinitely for anybody. Is
> that
>>     believable?
>>
>>
>> It depends.
>> In a very nice environment where all the peers are willing = to
> cooperate
>> at their best, the peers will store as much as they can. In a = tough
>> environment, the situation will be different.
>>
>>     This seems to translate to a model = where it is assumed that those
> nodes
>>     that are on most of the time will be = willing to provide VM storage
> for
>>     those nodes that aren't on most of the = time.
>>
>>
>> This is again related to reliability of P2P systems or topics = like
> free
>> riders and reputation.
>> A P2P system is a community or society. To be simple, if many = of the
>> members are bad, the community won't work well. If the majority = of the
>
>> members are good, the community will work well or = reasonably.
>>
>>      > Add to this the conferencing capability coming from p2p
> application
>>      > layer multicast, the SIP e2e control capabilities (for such as
>>      > auto-attendant, agent = workstation, etc.) and one has to wonder
> why IT
>>      > networks, public VoIP = networks and end users should support the
> huge
>>      > cost of hand engineering, = testing, monitoring, maintaining
> server
>>     based
>>      > VoIP networks. P2P self configuration is nothing less that
> automation
>>      > applied to VoIP, plus the = shifting of computing to the
> endpoints,
>>     where
>>      > there is an abundance of = unused CPU, storage, bandwidth and
>>     electricity.
>>      >
>>      > Eric Burger also notes IM changes completely the usage for VM
> and may
>>      > make unnecessary to place = calls on VM in the first place.
>>
>>     I find this more promising.
>>
>>          
>>
>>
>> In overall, are we discussing if P2P systems based VM can work? = I
> think
>> it can work.  Just it depends on many things.
>> If it is not super-reliable, should we disregard it? I would = say no.
>>
>> On the other hand, do we have to abandon client server based VM = and
>> switch to P2P system based VM? It is upto each of us.
>> Client server based VM systems are already there.
>> So why don't we work on P2P based VM now?
>> 
>> Thanks.
>>
>> Eunsoo
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C776C7.CE6A1169-- --===============1028348050== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1028348050==-- From p2psip-bounces@ietf.org Wed Apr 04 11:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7Bv-00062Q-2a; Wed, 04 Apr 2007 11:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7Bt-00060T-Bw for p2psip@ietf.org; Wed, 04 Apr 2007 11:14:29 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ7Br-0008Cf-Sy for p2psip@ietf.org; Wed, 04 Apr 2007 11:14:29 -0400 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 08:14:23 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34FEMSd026037; Wed, 4 Apr 2007 08:14:22 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l34FEL0c016655; Wed, 4 Apr 2007 08:14:22 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 08:14:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 08:14:10 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> In-Reply-To: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqw References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> From: "Henry Sinnreich" To: "Brian Rosen" , "P2PSIP Mailing List" X-OriginalArrivalTime: 04 Apr 2007 15:14:20.0635 (UTC) FILETIME=[EB9752B0:01C776CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org These are good points and actually should copied to the SIPPING list since they apply to the simple SIP Toolkit :-) Excellent items are these here: >3. All devices that support audio support wideband audio. =20 >4. All devices support text (IM and real time interactive). >5. All devices support presence. We define a minimal set of presence >characteristics that all devices publish. I take exception here only to the legacy from the voice-only PBX: >6. We define a minimal feature set (something like unattended and >attended >transfer, call forward no answer, call forward busy, basic conferencing, >...) that every device supports the same way. Let's first look how presence and IM may affect user behavior and if this cannot be a special endpoint app, say for receptionists or agents. > This is pretty much what Skype does=20 I am using Skype now for several years for most long distance calls and for conferences, but have never transferred a call. May be my secretary would transfer a call, but I don't have one :-) Nor do 99.99% of consumers or most employees any more. One can IM the number... Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 9:49 AM To: 'P2PSIP Mailing List' Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? One of the things I think we blew big time on sip was that we didn't require some fundamental things in every sip device to differentiate them from existing technology. We have an opportunity to fix that with p2psip, and I think we should do it. Now, admittedly, what I'm talking about is somewhat a "marketing" issue, but it's a very real thing that we could do which I believe would be helpful. So, I propose: 1. We do not support any form of insecure signaling. We define the protocol to reject attempts to signal without TLS (or whatever). I'm assuming the protocols are TCP only. The overlay defines what credentials are needed (and supplies them). 2. We do not support any form of insecure media. It's always encrypted. This is the tough one, especially if we say we support SIP UAs. 3. All devices that support audio support wideband audio. =20 4. All devices support text (IM and real time interactive). 5. All devices support presence. We define a minimal set of presence characteristics that all devices publish. 6. We define a minimal feature set (something like unattended and attended transfer, call forward no answer, call forward busy, basic conferencing, ...) that every device supports the same way. 7. All devices work behind a given set of NAT configurations, given a specified set of ICE components (or whatever). 8. We define what constitutes a minimal configuration set; all of the above just work with this level of configuration (and credentials from an overlay). We of course define the configuration mechanism. I'm thinking that we do this by configuring the device with the credentials, and using the overlay to provide any other configuration (which could be influenced by, say, a website the overlay runs) automatically. All of these are designed to be minimum capabilities, but the idea is that ANY device, with credentials on an overlay, can expect to communicate with any other device on that overlay with ALL of the above. Finally, I propose we invent a phrase, something like "p2psip conformant" which means a device that does that. No protocol police, but the idea is that if you say you have a "p2psip conformant" device, it means all of the above. Perhaps we have a way to signal that. This is pretty much what Skype does. Why should we not do that, at least? Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 11:19:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7GY-0000jp-Hm; Wed, 04 Apr 2007 11:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7GV-0000iy-2j; Wed, 04 Apr 2007 11:19:15 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7GR-00011V-2H; Wed, 04 Apr 2007 11:19:15 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34FJ0P5013315; Wed, 4 Apr 2007 11:19:00 -0400 MIME-Version: 1.0 x-cr-hashedpuzzle: CXpr HeV3 IpEd JFuk QBsk RlEd d8ux loYF 2XQU 2XjS ACu5FA== ACwSaQ== AIV41Q== AIhHbA== AIvxIQ== AJauZA==; 8; YgByAEAAYgByAGkAYQBuAHIAbwBzAGUAbgAuAG4AZQB0ADsAaABzAGkAbgBuAHIAZQBpAEAAYQBkAG8AYgBlAC4AYwBvAG0AOwBtAGgAYQBtAG0AZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBvAHIAYQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBwADIAcAByAGcAQABpAGUAdABmAC4AbwByAGcAOwBwADIAcABzAGkAcABAAGkAZQB0AGYALgBvAHIAZwA7AHAAawB5AHoAaQB2AGEAdABAAGMAaQBzAGMAbwAuAGMAbwBtADsAcwBpAHAAcABpAG4AZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {AA783291-6F0C-47A3-AFFF-C0AB3DD8D50D}; cwBsAGEAdgBpAHQAYwBoAEAAbwBiAGoAZQBjAHQAdwBvAHIAbABkAC4AYwBvAG0A; Wed, 04 Apr 2007 15:18:22 GMT; UgBFADoAIABbAFAAMgBQAFMASQBQAF0AIABSAEUAOgAgAFsAUAAyAFAAcgBnAF0AIABSAEUAOgAgAFsAUwBpAHAAcABpAG4AZwBdACAAUwBpAG0AcABsAGUAIABTAEkAUAAgAHUAcwBhAGcAZQAgAHMAYwBlAG4AYQByAGkAbwA= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message x-cr-puzzleid: {AA783291-6F0C-47A3-AFFF-C0AB3DD8D50D} Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 11:18:22 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90BF@photon.objectworld.com> In-Reply-To: <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd176Ya+p6xqIGMQfSJrn6cLV80rgACgCmQAAX8woAAAZhX4AAHz3sgACH445AAAJ5BUA== References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF2F@namail5.corp.adobe.com> <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Henry Sinnreich" , "Paul Kyzivat" X-Spam-Score: 1.50 (*) [Tag at 20.00] EXTRA_MPART_TYPE, HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.2 (/) X-Scan-Signature: 97b8643c8d9cc60b17ea5996f3e435cb Cc: sipping@ietf.org, p2prg@ietf.org, David R Oran , P2PSIP Mailing List , "Michael Hammer \(mhammer\)" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1611860298==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1611860298== Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C776CC.922B3E63" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C776CC.922B3E63 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C776CC.922B3E63" ------_=_NextPart_002_01C776CC.922B3E63 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline A response to troll rant inline. Only for the curious. Apologies in advance. =20 =20 =20 =20 =09=09=20 Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com =09=09=20 =20 =20 From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 9:59 AM To: 'Henry Sinnreich'; Michael Slavitch; 'Paul Kyzivat' Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran'; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 Have you actually ever built an enterprise telephony system? Maybe installed a recent one? =20 [MNS> ] Rather than being 'who do you think you are' condescending, you might instead consider Google as your friend, Brian. Since you asked, you might consider clicking on the logo in my signature. Going way back I built the IP stack on the Mitel SX-2000 in the late 1980's. Back then it was considered novel to have provisioning over something called 'telnet' . On the provisioning side things haven't progressed much since then, but at least I got to prove my thesis advisor wrong as indeed voice over packet won. Apparently they are using the IP same stack today, hopefully with all my bugs fixed.=20 =20 Look, every product can be improved, and I do agree with Henry that the enterprise telephony folks haven't caught on (or haven't figured out how to make money on) presence and IM integration. I think there have been plenty of attempts to allow other app integration that have failed pretty much completely despite what we would have thought. =20 My take on this is that enterprise IT (which now owns phones), demands the level of feature set the enterprise PBX guys give them, are pretty much afraid of doing any serious app interaction except in call centers, and would not see any inherent benefit in p2p. "Self Organizing" is not what we are talking about any more than current systems are self organizing. =20 [MNS> ] PBX vendors are afraid because it is too complicated and applications are not in their DNA. They push boxes. Applications are fully in the DNA of others, however, especially enterprise IT departments because applications are what they do. Enterprise IT departments are not afraid of building applications. They are afraid of touching brittle PBX systems with limited badly documented interfaces from incompetent PBX vendors that want to charge a mint for basic CTI that doesn't even work. Want a reference? I have several. BTW: Have you been reading the trade press lately? For the record: My interest is not in improving PBX products. My interest is eliminating them and replacing them with software without forcing changes in end-user behavior. =20 In current systems, except in the very largest systems, there is a server, you configure it, and plug the phones in. They self configure. The configuration on the server is complex, but it's not something that needs a large staff; in most enterprises I know, there is usually one guy (or sometimes one per site) who maintains the configuration part time. How much less do you think you could get, and what do you think you could simplify with p2p? =20 [MNS> ] Well, that's true, at least in the press releases. Reality does differ. I actually have real numbers: A cost reduction of at least 90% when moving from traditional PBX to well-automated C/S SIP, which is what my employer currently does, and a further cost reduction of 90% between C/S SIP and P2P SIP. In the incumbent PBX case the biggest cost of a deployment is almost always configuration and installation and on-going maintenance. In the last case the biggest cost of deployment Want a reference? =20 Skype? In an enterprise? Try talking to YOUR staff about that idea and see how far you get. Skype does not provide the feature set enterprise wants. You can claim the staff doesn't know its business I suppose. =20 [MNS> ] Oracle? Selling SIP servers? Try talking to IT staff and see how far you get. Skype? Supporting one-click monetization and settlement with millions of customers over voice and other media? Why would a business want that ? Why would someone like me put a Skype address in his signature? =20 Let's take one simple example: dial plans. Every enterprise has one. Does Skype? What would p2p do for dial plans that any current system can't do right now? =20 [MNS> ] I'd love to get into that but that would be under NDA and the IETF has strict rules about disclosure, sorry. =20 What is the problem: dial plans are evil, we should get rid of them, or dial plans are useful, and SOMEONE has to use some kind of tool to configure them, and having done that, assign extension numbers within the dial plan? What would p2p do for us? D'you want users configuring their own extensions?=20=20 =20 [MNS> ] NDA again and rules about disclosure. Sorry. This is after all a competitive industry. =20 I see many benefits to p2p, but significantly simplifying enterprise deployment isn't one of them. =20 [MNS> ] Excellent! You must understand that in my line of work this is considered a very positive development and confirmation. Money in the bank. Thanks. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_002_01C776CC.922B3E63 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

A  response to troll = rant inline.  Only for the curious.  Apologies in advance.

 

 =

3D"corp_2colour"

 =

 

Michael Slavitch          &nb= sp;  

Lead, Technology Initi= atives

slavitch@objectworld.com

 

=  

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, April 04, 2007 9:59 AM
To: 'Henry Sinnreich'; Michael Slavitch; 'Paul Kyzivat'
Cc: 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)'; 'David R Oran= '; p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

Have you actually ever built an enterprise telephony system?  Maybe installed a recent one?

 

[MNS>  ]  = Rather than being ‘who do you think you are’ condescending, you might instead consider Google as your friend,  Brian.  Since you asked,= you might consider clicking on the logo in my signature.  Going way back I built the IP stack on the Mitel SX-2000 in the late 1980’s. Back then= it was considered novel to have provisioning over something called ‘teln= et’ . On the provisioning side things haven’t progressed much since then,= but at least I got to prove my thesis advisor wrong as indeed voice over packet= won.  Apparently they are using the IP same stack today, hopefully with all my bu= gs fixed.

 

Look, every product can be improved, and I do agree with Henry = that the enterprise telephony folks haven’t caught on (or haven’t figured out how to make money on) presence and IM integration.  I think there have been plenty of attempts to allow other app integration that have failed pretty much completely despite what we would have thought.

 

My take on this is that enterprise IT (which now owns phones), demands the level of feature set the enterprise PBX guys give them, are pre= tty much afraid of doing any serious app interaction except in call centers, and would not see any inherent benefit in p2p.  “Self OrganizingR= 21; is not what we are talking about any more than current systems are self organizing.

 

[MNS>  ] PBX ve= ndors are afraid because it is too complicated and applications are not in their DNA.  They push boxes. Applications are fully in the DNA of others, however, especially enterprise IT departments because applications are what they do.  Enterprise IT departments are not afraid of building applications.&nb= sp; They are afraid of touching brittle PBX systems with limited badly document= ed interfaces from incompetent PBX vendors that want to charge a mint for basic CTI that doesn’t even work. Want a reference? I have several.  B= TW: Have you been reading the trade press lately?  For the record: My interest = is not in improving PBX products. My interest is eliminating them and replacing them with software without forcing changes in end-user behavior.=

 

In current systems, except in the very largest systems, there i= s a server, you configure it, and plug the phones in.  They self configure.  The configuration on the server is complex, but it’s= not something that needs a large staff; in most enterprises I know, there is usually one guy (or sometimes one per site) who maintains the configuration part time.  How much less do you think you could get, and what do you think you could simplify with p2p?

 

[MNS>  ] Well, = that’s true, at least in the press releases.  Reality does differ.  I actually have real numbers: A cost reduction of at least 90% when moving fr= om traditional PBX to well-automated C/S SIP, which is what my employer curren= tly does, and a further cost reduction of 90% between C/S SIP and P2P SIP. &nbs= p;In the incumbent PBX case the biggest cost of a deployment is almost always co= nfiguration and installation and on-going maintenance.  In the last case the bigge= st cost of deployment  Want a reference?

 

Skype?  In an enterprise?  Try talking to YOUR staff about that idea and see how far you get.   Skype does not provide= the feature set enterprise wants.  You can claim the staff doesn’t k= now its business I suppose.

 

[MNS>  ]  = Oracle? Selling SIP servers? Try talking to IT staff  and see how far you get.  Skype? Supporting one-click monetization and settlement with millions of customers over voice and other media? Why would a business= want that? Why would someone like me put a Skype address in his signature?

 

Let’s take one simple example: dial plans.  Every enterprise has one.  Does Skype?  What would p2p do for dial plans that any current system can’t do right now?

 

[MNS>  ] I̵= 7;d love to get into that but that would be under NDA and the IETF has strict rules about disclosure, sorry.

 

What is the problem: dial plans are evil, we should get rid of them, or dial plans are useful, and SOMEONE has to use some kind of tool to configure them, and having done that, assign extension numbers within the d= ial plan?  What would p2p do for us?  D’you want users configur= ing their own extensions?  

 

[MNS>  ] NDA ag= ain and rules about disclosure. Sorry.   This is after all a competitive industry.

 

I see many benefits to p2p, but significantly simplifying enterprise deployment isn’t one of them.

 

[MNS>  ] Excellent!  You must understand that in my line of work this is consid= ered a very positive development and confirmation. Money in the bank. Thanks.

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_002_01C776CC.922B3E63-- ------_=_NextPart_001_01C776CC.922B3E63 Content-Type: image/jpeg; name="image004.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.jpg Content-Location: image004.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_001_01C776CC.922B3E63-- --===============1611860298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1611860298==-- From p2psip-bounces@ietf.org Wed Apr 04 11:25:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7MP-0007RL-IP; Wed, 04 Apr 2007 11:25:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7MO-0007Qo-3D for p2psip@ietf.org; Wed, 04 Apr 2007 11:25:20 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7MK-00033w-8a for p2psip@ietf.org; Wed, 04 Apr 2007 11:25:20 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ7Lx-0001z8-TR; Wed, 04 Apr 2007 10:24:58 -0500 From: "Brian Rosen" To: "'Henry Sinnreich'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 11:25:08 -0400 Message-ID: <1e2701c776cd$72299710$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I REALLY wish I could transfer a call from Skype to my mobile and vice versa. I wish I could transfer it to my hardline when, for whatever reason, the bandwidth gods are not smiling on me. And then there is conferencing. Depending on exactly how conferencing is implemented, you may need to transfer to a bridge. I really think transfer is an absolute minimal requirement. I do think that a rich presence system might obviate the Call forward issues. I've never seen it done, so I've never been able to try, but I could see how it might. Conferencing is something that just has to work. We need to go down the list of service examples and decide which ones are MUST HAVE. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, April 04, 2007 11:14 AM > To: Brian Rosen; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? > > These are good points and actually should copied to the SIPPING list > since they apply to the simple SIP Toolkit :-) > > Excellent items are these here: > > >3. All devices that support audio support wideband audio. > > >4. All devices support text (IM and real time interactive). > > >5. All devices support presence. We define a minimal set of presence > >characteristics that all devices publish. > > I take exception here only to the legacy from the voice-only PBX: > > >6. We define a minimal feature set (something like unattended and > >attended > >transfer, call forward no answer, call forward busy, basic > conferencing, > >...) that every device supports the same way. > > Let's first look how presence and IM may affect user behavior and if > this cannot be a special endpoint app, say for receptionists or agents. > > > This is pretty much what Skype does > > I am using Skype now for several years for most long distance calls and > for conferences, but have never transferred a call. May be my secretary > would transfer a call, but I don't have one :-) > Nor do 99.99% of consumers or most employees any more. One can IM the > number... > > Thanks, Henry > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 9:49 AM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? > > One of the things I think we blew big time on sip was that we didn't > require > some fundamental things in every sip device to differentiate them from > existing technology. We have an opportunity to fix that with p2psip, > and I > think we should do it. > > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > but > it's a very real thing that we could do which I believe would be > helpful. > > So, I propose: > 1. We do not support any form of insecure signaling. We define the > protocol > to reject attempts to signal without TLS (or whatever). I'm assuming > the > protocols are TCP only. The overlay defines what credentials are needed > (and supplies them). > > 2. We do not support any form of insecure media. It's always encrypted. > This is the tough one, especially if we say we support SIP UAs. > > 3. All devices that support audio support wideband audio. > > 4. All devices support text (IM and real time interactive). > > 5. All devices support presence. We define a minimal set of presence > characteristics that all devices publish. > > 6. We define a minimal feature set (something like unattended and > attended > transfer, call forward no answer, call forward busy, basic conferencing, > ...) that every device supports the same way. > > 7. All devices work behind a given set of NAT configurations, given a > specified set of ICE components (or whatever). > > 8. We define what constitutes a minimal configuration set; all of the > above > just work with this level of configuration (and credentials from an > overlay). We of course define the configuration mechanism. I'm > thinking > that we do this by configuring the device with the credentials, and > using > the overlay to provide any other configuration (which could be > influenced > by, say, a website the overlay runs) automatically. > > All of these are designed to be minimum capabilities, but the idea is > that > ANY device, with credentials on an overlay, can expect to communicate > with > any other device on that overlay with ALL of the above. > > Finally, I propose we invent a phrase, something like "p2psip > conformant" > which means a device that does that. No protocol police, but the idea > is > that if you say you have a "p2psip conformant" device, it means all of > the > above. Perhaps we have a way to signal that. > > This is pretty much what Skype does. Why should we not do that, at > least? > > Brian > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 11:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7RV-0003Lq-BT; Wed, 04 Apr 2007 11:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7RU-0003Iw-HU for p2psip@ietf.org; Wed, 04 Apr 2007 11:30:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7RP-0005Lt-Mb for p2psip@ietf.org; Wed, 04 Apr 2007 11:30:36 -0400 Received: by ug-out-1314.google.com with SMTP id 72so672999ugd for ; Wed, 04 Apr 2007 08:30:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UkuBmS+kOztQm8C+8nUhXbxaTzT7e6lkz+nEBuABp5I0w/dXEK9/9iBE/2vo9MF3GZUyATIVm0EWrRdAX2oCa8pLHOXsyFtT38s5HYaXJY7ltPZYAUzEytp9/gKSOrNWsIozn0Y3BcyZdhsPa23yW9zWyju6DzYd6sUV4FGAnNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OTp8PkgaHwklAY1IR15uCaDtrXE/s9p/wuhUEdUX28HFxW4Nwk2ONBxj7DCA/Xj1OJqjgKXg7Jmz0ctfqDMBp0Bzb8q4INqbZKpK1coC1cGyvo47+/CTmSGMzTsfif/9K/sipOVM3zmH1W5PehoMOmM34GoXOEtRTcORpLvVumQ= Received: by 10.82.163.13 with SMTP id l13mr919538bue.1175700626197; Wed, 04 Apr 2007 08:30:26 -0700 (PDT) Received: by 10.82.127.17 with HTTP; Wed, 4 Apr 2007 08:30:26 -0700 (PDT) Message-ID: <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> Date: Wed, 4 Apr 2007 11:30:26 -0400 From: "David A. Bryan" To: "Brian Rosen" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? In-Reply-To: <1e2701c776cd$72299710$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> <1e2701c776cd$72299710$81238182@cis.neustar.com> X-Google-Sender-Auth: 23d46f871545c3ad X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Tend to agree with most of this, but we also need to keep in mind non-telephony P2PSIP applications (say IPTV, voice add-on to gaming etc.) and make sure we don't write things in such a way these capabilities are required for these services as well. David On 4/4/07, Brian Rosen wrote: > I REALLY wish I could transfer a call from Skype to my mobile and vice > versa. > > I wish I could transfer it to my hardline when, for whatever reason, the > bandwidth gods are not smiling on me. > > And then there is conferencing. Depending on exactly how conferencing is > implemented, you may need to transfer to a bridge. > > I really think transfer is an absolute minimal requirement. > > I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might. > > Conferencing is something that just has to work. > > We need to go down the list of service examples and decide which ones are > MUST HAVE. > > Brian > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Wednesday, April 04, 2007 11:14 AM > > To: Brian Rosen; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > think? > > > > These are good points and actually should copied to the SIPPING list > > since they apply to the simple SIP Toolkit :-) > > > > Excellent items are these here: > > > > >3. All devices that support audio support wideband audio. > > > > >4. All devices support text (IM and real time interactive). > > > > >5. All devices support presence. We define a minimal set of presence > > >characteristics that all devices publish. > > > > I take exception here only to the legacy from the voice-only PBX: > > > > >6. We define a minimal feature set (something like unattended and > > >attended > > >transfer, call forward no answer, call forward busy, basic > > conferencing, > > >...) that every device supports the same way. > > > > Let's first look how presence and IM may affect user behavior and if > > this cannot be a special endpoint app, say for receptionists or agents. > > > > > This is pretty much what Skype does > > > > I am using Skype now for several years for most long distance calls and > > for conferences, but have never transferred a call. May be my secretary > > would transfer a call, but I don't have one :-) > > Nor do 99.99% of consumers or most employees any more. One can IM the > > number... > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 9:49 AM > > To: 'P2PSIP Mailing List' > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > think? > > > > One of the things I think we blew big time on sip was that we didn't > > require > > some fundamental things in every sip device to differentiate them from > > existing technology. We have an opportunity to fix that with p2psip, > > and I > > think we should do it. > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > > but > > it's a very real thing that we could do which I believe would be > > helpful. > > > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > > protocol > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > protocols are TCP only. The overlay defines what credentials are needed > > (and supplies them). > > > > 2. We do not support any form of insecure media. It's always encrypted. > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive). > > > > 5. All devices support presence. We define a minimal set of presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and > > attended > > transfer, call forward no answer, call forward busy, basic conferencing, > > ...) that every device supports the same way. > > > > 7. All devices work behind a given set of NAT configurations, given a > > specified set of ICE components (or whatever). > > > > 8. We define what constitutes a minimal configuration set; all of the > > above > > just work with this level of configuration (and credentials from an > > overlay). We of course define the configuration mechanism. I'm > > thinking > > that we do this by configuring the device with the credentials, and > > using > > the overlay to provide any other configuration (which could be > > influenced > > by, say, a website the overlay runs) automatically. > > > > All of these are designed to be minimum capabilities, but the idea is > > that > > ANY device, with credentials on an overlay, can expect to communicate > > with > > any other device on that overlay with ALL of the above. > > > > Finally, I propose we invent a phrase, something like "p2psip > > conformant" > > which means a device that does that. No protocol police, but the idea > > is > > that if you say you have a "p2psip conformant" device, it means all of > > the > > above. Perhaps we have a way to signal that. > > > > This is pretty much what Skype does. Why should we not do that, at > > least? > > > > Brian > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 11:35:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7W1-0003wl-0T; Wed, 04 Apr 2007 11:35:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7W0-0003we-2V for p2psip@ietf.org; Wed, 04 Apr 2007 11:35:16 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZ7Vv-0002uZ-F3 for p2psip@ietf.org; Wed, 04 Apr 2007 11:35:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZ7Vb-0003VN-Hv; Wed, 04 Apr 2007 10:34:51 -0500 From: "Brian Rosen" To: "'David A. Bryan'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 11:35:05 -0400 Message-ID: <1e2b01c776ce$d3b9d3e0$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> Thread-Index: Acd2ziRvTwrFvyHWS/CKOBg5PKpARwAAIrQQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Sure. We can define these as "telephony devices". Some, of course (like signaling and media security) might apply across the board. Brian > -----Original Message----- > From: amelampus@gmail.com [mailto:amelampus@gmail.com] On Behalf Of David > A. Bryan > Sent: Wednesday, April 04, 2007 11:30 AM > To: Brian Rosen > Cc: Henry Sinnreich; P2PSIP Mailing List > Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? > > Tend to agree with most of this, but we also need to keep in mind > non-telephony P2PSIP applications (say IPTV, voice add-on to gaming > etc.) and make sure we don't write things in such a way these > capabilities are required for these services as well. > > David > > On 4/4/07, Brian Rosen wrote: > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > versa. > > > > I wish I could transfer it to my hardline when, for whatever reason, the > > bandwidth gods are not smiling on me. > > > > And then there is conferencing. Depending on exactly how conferencing > is > > implemented, you may need to transfer to a bridge. > > > > I really think transfer is an absolute minimal requirement. > > > > I do think that a rich presence system might obviate the Call forward > > issues. I've never seen it done, so I've never been able to try, but I > > could see how it might. > > > > Conferencing is something that just has to work. > > > > We need to go down the list of service examples and decide which ones > are > > MUST HAVE. > > > > Brian > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > To: Brian Rosen; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > > think? > > > > > > These are good points and actually should copied to the SIPPING list > > > since they apply to the simple SIP Toolkit :-) > > > > > > Excellent items are these here: > > > > > > >3. All devices that support audio support wideband audio. > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > >5. All devices support presence. We define a minimal set of presence > > > >characteristics that all devices publish. > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > >6. We define a minimal feature set (something like unattended and > > > >attended > > > >transfer, call forward no answer, call forward busy, basic > > > conferencing, > > > >...) that every device supports the same way. > > > > > > Let's first look how presence and IM may affect user behavior and if > > > this cannot be a special endpoint app, say for receptionists or > agents. > > > > > > > This is pretty much what Skype does > > > > > > I am using Skype now for several years for most long distance calls > and > > > for conferences, but have never transferred a call. May be my > secretary > > > would transfer a call, but I don't have one :-) > > > Nor do 99.99% of consumers or most employees any more. One can IM the > > > number... > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > To: 'P2PSIP Mailing List' > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > > think? > > > > > > One of the things I think we blew big time on sip was that we didn't > > > require > > > some fundamental things in every sip device to differentiate them from > > > existing technology. We have an opportunity to fix that with p2psip, > > > and I > > > think we should do it. > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > > > but > > > it's a very real thing that we could do which I believe would be > > > helpful. > > > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > > > 8. We define what constitutes a minimal configuration set; all of the > > > above > > > just work with this level of configuration (and credentials from an > > > overlay). We of course define the configuration mechanism. I'm > > > thinking > > > that we do this by configuring the device with the credentials, and > > > using > > > the overlay to provide any other configuration (which could be > > > influenced > > > by, say, a website the overlay runs) automatically. > > > > > > All of these are designed to be minimum capabilities, but the idea is > > > that > > > ANY device, with credentials on an overlay, can expect to communicate > > > with > > > any other device on that overlay with ALL of the above. > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > conformant" > > > which means a device that does that. No protocol police, but the idea > > > is > > > that if you say you have a "p2psip conformant" device, it means all of > > > the > > > above. Perhaps we have a way to signal that. > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > least? > > > > > > Brian > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 11:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7d9-0003yu-1V; Wed, 04 Apr 2007 11:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7d7-0003yo-9U for p2psip@ietf.org; Wed, 04 Apr 2007 11:42:37 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7d1-0003BZ-Ci for p2psip@ietf.org; Wed, 04 Apr 2007 11:42:37 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 17:42:29 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 17:42:28 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 17:42:28 +0200 Message-ID: <4613C76C.2060901@telecomitalia.it> Date: Wed, 04 Apr 2007 17:42:36 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> In-Reply-To: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 04 Apr 2007 15:42:28.0170 (UTC) FILETIME=[D970BAA0:01C776CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1390225759==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1390225759== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040309060200050000060505" This is a cryptographically signed message in MIME format. --------------ms040309060200050000060505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian Rosen wrote: > So, I propose: > 1. We do not support any form of insecure signaling. We define the protocol > to reject attempts to signal without TLS (or whatever). I'm assuming the > protocols are TCP only. The overlay defines what credentials are needed > (and supplies them). We haven't chosen the transport for the peer protocol, have we? As far as I remember, during the last meeting we deferred the issue... -- Ciao, Enrico Ahem.. Sorry, the notice below is not my fault :-( --------------ms040309060200050000060505 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDA0MTU0MjM2WjAjBgkqhkiG9w0BCQQxFgQUQTP3nd7E OQZZCajAlQedOeXvW2cwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBACmwmHtQZlgQQC9z32YyND1z9itz/0Zq6pufu55YQyHMHpDdnCWAuMoh oGE0fnIy7UbU126UzfSFwANcS4znCFcBAKl17ZlRnBfB6nJ4iBSc/TxIGa3OWYafL8q/YH9+ Qp5KBe4nIfFVP3C6gtIsgNY4bdxdcVPfe9pMy7wgVgxvaRyCD6H1qVA3xS11RLjAzv4IOQr9 LCAKGK3J0Ea22aBHeYJaUGeJR1zK4xwnFCxF5e+c5sVyY7n9MbTs2z7LXDqhyMOC4oetYlJN R77pP37oSnztwVrIQKtIbh1umfNTwNaeglJcjyLZP0DQhGR9m+KnoDZZ3an5QjIN1lu3CO0A AAAAAAA= --------------ms040309060200050000060505-- --===============1390225759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1390225759==-- From p2psip-bounces@ietf.org Wed Apr 04 11:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7eQ-0004Kd-HI; Wed, 04 Apr 2007 11:43:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7eP-0004KX-QC for p2psip@ietf.org; Wed, 04 Apr 2007 11:43:57 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7eO-0003O6-Ih for p2psip@ietf.org; Wed, 04 Apr 2007 11:43:57 -0400 Received: by py-out-1112.google.com with SMTP id f31so75679pyh for ; Wed, 04 Apr 2007 08:43:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=AoCPu3kX45QyrkqqCtX1W+JzPiDoqMihXw3MSqOSE9PMMZuAsF9eFn6yCmDeMxYMP+100wr4FZBOzXld4n95/OJqUgA+mbceQkoCjg3x7Us+YV8DkGgVG4kH2orYD599Jj9Pg6rA2Qjlh4hX4+9fMIs/pFRLu3sUkwX2ESWNw80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=V34bWFbzLv5S0d7NaGNUnpoa1v2rAmSWBdHSXtjldGiUj5WAoQVsv19qXkY8cvBCCxv9ByWpLqQ5wo6PRntKaLAeFsljdnC05cPX17fGaLVcgaNToVahE/6a1ubFcbb9yA/yLqsoCSqoSJjJUh3Ueuyd1Yvnq7kW/Av/8bcEZVs= Received: by 10.35.58.8 with SMTP id l8mr1355858pyk.1175701436179; Wed, 04 Apr 2007 08:43:56 -0700 (PDT) Received: by 10.35.107.10 with HTTP; Wed, 4 Apr 2007 08:43:56 -0700 (PDT) Message-ID: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> Date: Wed, 4 Apr 2007 11:43:56 -0400 From: "Bruce Lowekamp" To: "Brian Rosen" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? In-Reply-To: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> X-Google-Sender-Auth: d05761a072c4840a X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 4/4/07, Brian Rosen wrote: > So, I propose: > 1. We do not support any form of insecure signaling. We define the protocol > to reject attempts to signal without TLS (or whatever). I'm assuming the > protocols are TCP only. The overlay defines what credentials are needed > (and supplies them). > Requiring securing the protocol seems like a good goal. We need to have a scheme that secures ad-hoc networks and one that works with NATs, so TLS over TCP certainly can't be our only option. > 2. We do not support any form of insecure media. It's always encrypted. > This is the tough one, especially if we say we support SIP UAs. > > 3. All devices that support audio support wideband audio. > > 4. All devices support text (IM and real time interactive). > > 5. All devices support presence. We define a minimal set of presence > characteristics that all devices publish. > > 6. We define a minimal feature set (something like unattended and attended > transfer, call forward no answer, call forward busy, basic conferencing, > ...) that every device supports the same way. All of these assume a particular type of device that I don't think we can (or should) assume for P2PSIP. Where we get into the particular calling features for telephony devices, hopefully we can just point at BLISS. > > 7. All devices work behind a given set of NAT configurations, given a > specified set of ICE components (or whatever). agreed, although defining the exact configurations that we can support is quite difficult. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 11:47:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7hL-00050t-M0; Wed, 04 Apr 2007 11:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7hK-00050o-FM for p2psip@ietf.org; Wed, 04 Apr 2007 11:46:58 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7hJ-0004G1-Uf for p2psip@ietf.org; Wed, 04 Apr 2007 11:46:58 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34FkoPC013784 for ; Wed, 4 Apr 2007 11:46:50 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 11:46:43 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90C2@photon.objectworld.com> In-Reply-To: <1e2701c776cd$72299710$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYA== References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> <1e2701c776cd$72299710$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Henry Sinnreich" , "P2PSIP Mailing List" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org " I do think that a rich presence system might obviate the Call forward issues. I've never seen it done, so I've never been able to try, but I could see how it might." It does. For example, I don't have call forward, I have on my personal ag= ent right now (a shameless plug for my employer, sorry) 'always call forwar= d for identities that I really don't want to talk to or refuse to identify = themselves, call forward when busy for most people, call forward for even = fewer people when DND, and even when I set my presence to DND flash my cal= l and interrupt me if it's a call from my kid's school, my doctor, my wife,= my boss, and a few people on this list, just not too loud.'=20=20 This is done using client-server SIP server talking to another client-serve= r SIP server and perhaps sometimes a third SIP server from another much lar= ger vendor who doesn't care if they got things wrong along with a fourth SI= P server that's a message store from two vendors and a fifth SIP server tha= t might do 3rd party call control if our customers buy it, (whew!), all exc= hanging messages in a complex energetic manner that makes life harder for o= ur developers than it has to be.=20=20 The underlying mechanisms are an order of magnitude more complex than they = have to be and I have proof that the amount of code needed if standard tech= iques existed* to interact with 3rd parties from low-end endpoints to big s= uper-duper-supernodes** would be 1/10th the amount of code needed to do the= equivalent in the C/S world. A 1.5M code-line project becomes a 150K cod= e-line project, which as any person who has ever put together a project pla= n knows carries enormous implications for probability of failure and succes= s, the kind of products that result, and the kind of sales needed to justif= y them.=20=20 P2P enables long-tail economics in communications systems products in the s= ame way that you don't have to be a 3270 forms developer to develop web con= tent. Vendors that participate in long-tail environments such as eBay are = wise to develop on such a platform. There are others vendors, including em= ployers of people reading this message, that are beneficiaries of long-tail= markets. Including mine. Regards Michael *Which is the only way to get people to bother as the pull in the C/S direc= tion is very hard. **Which is really what a 'server' is, albeit with a much les silly name. Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 11:25 AM To: 'Henry Sinnreich'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? I REALLY wish I could transfer a call from Skype to my mobile and vice versa. I wish I could transfer it to my hardline when, for whatever reason, the bandwidth gods are not smiling on me. And then there is conferencing. Depending on exactly how conferencing is implemented, you may need to transfer to a bridge. I really think transfer is an absolute minimal requirement. I do think that a rich presence system might obviate the Call forward issues. I've never seen it done, so I've never been able to try, but I could see how it might. Conferencing is something that just has to work. We need to go down the list of service examples and decide which ones are MUST HAVE.=20=20 Brian > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, April 04, 2007 11:14 AM > To: Brian Rosen; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? >=20 > These are good points and actually should copied to the SIPPING list > since they apply to the simple SIP Toolkit :-) >=20 > Excellent items are these here: >=20 > >3. All devices that support audio support wideband audio. >=20 > >4. All devices support text (IM and real time interactive). >=20 > >5. All devices support presence. We define a minimal set of presence > >characteristics that all devices publish. >=20 > I take exception here only to the legacy from the voice-only PBX: >=20 > >6. We define a minimal feature set (something like unattended and > >attended > >transfer, call forward no answer, call forward busy, basic > conferencing, > >...) that every device supports the same way. >=20 > Let's first look how presence and IM may affect user behavior and if > this cannot be a special endpoint app, say for receptionists or agents. >=20 > > This is pretty much what Skype does >=20 > I am using Skype now for several years for most long distance calls and > for conferences, but have never transferred a call. May be my secretary > would transfer a call, but I don't have one :-) > Nor do 99.99% of consumers or most employees any more. One can IM the > number... >=20 > Thanks, Henry >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 9:49 AM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? >=20 > One of the things I think we blew big time on sip was that we didn't > require > some fundamental things in every sip device to differentiate them from > existing technology. We have an opportunity to fix that with p2psip, > and I > think we should do it. >=20 > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > but > it's a very real thing that we could do which I believe would be > helpful. >=20 > So, I propose: > 1. We do not support any form of insecure signaling. We define the > protocol > to reject attempts to signal without TLS (or whatever). I'm assuming > the > protocols are TCP only. The overlay defines what credentials are needed > (and supplies them). >=20 > 2. We do not support any form of insecure media. It's always encrypted. > This is the tough one, especially if we say we support SIP UAs. >=20 > 3. All devices that support audio support wideband audio. >=20 > 4. All devices support text (IM and real time interactive). >=20 > 5. All devices support presence. We define a minimal set of presence > characteristics that all devices publish. >=20 > 6. We define a minimal feature set (something like unattended and > attended > transfer, call forward no answer, call forward busy, basic conferencing, > ...) that every device supports the same way. >=20 > 7. All devices work behind a given set of NAT configurations, given a > specified set of ICE components (or whatever). >=20 > 8. We define what constitutes a minimal configuration set; all of the > above > just work with this level of configuration (and credentials from an > overlay). We of course define the configuration mechanism. I'm > thinking > that we do this by configuring the device with the credentials, and > using > the overlay to provide any other configuration (which could be > influenced > by, say, a website the overlay runs) automatically. >=20 > All of these are designed to be minimum capabilities, but the idea is > that > ANY device, with credentials on an overlay, can expect to communicate > with > any other device on that overlay with ALL of the above. >=20 > Finally, I propose we invent a phrase, something like "p2psip > conformant" > which means a device that does that. No protocol police, but the idea > is > that if you say you have a "p2psip conformant" device, it means all of > the > above. Perhaps we have a way to signal that. >=20 > This is pretty much what Skype does. Why should we not do that, at > least? >=20 > Brian >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 11:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7qo-0006Cy-8i; Wed, 04 Apr 2007 11:56:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7qn-0006Cm-5x for p2psip@ietf.org; Wed, 04 Apr 2007 11:56:45 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7ql-0008Oq-Rh for p2psip@ietf.org; Wed, 04 Apr 2007 11:56:45 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34Fueqf014003 for ; Wed, 4 Apr 2007 11:56:40 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 11:56:31 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90C4@photon.objectworld.com> In-Reply-To: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgACU4HQ References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "P2PSIP Mailing List" X-Spam-Score: 0.70 () [Tag at 20.00] HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0615097153==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0615097153== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776D1.D53E25FD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776D1.D53E25FD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Brian: Finally, I propose we invent a phrase, something like "p2psip conformant" =20 Backed up by a test suite. Please. Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com =20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_001_01C776D1.D53E25FD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Brian: Finally, I propose we invent a phrase, something like "p2psip conformant"

 

Backed up by a test suite.   Please.=

Michael Slavitch           &= nbsp; 

Lead, Technology Initiatives

slavitch@objectworld.com

 

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_001_01C776D1.D53E25FD-- --===============0615097153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0615097153==-- From p2psip-bounces@ietf.org Wed Apr 04 11:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7r7-0006KA-Vr; Wed, 04 Apr 2007 11:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7r6-0006HJ-Am for p2psip@ietf.org; Wed, 04 Apr 2007 11:57:04 -0400 Received: from bay0-omc1-s23.bay0.hotmail.com ([65.54.246.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ7r4-000055-Uc for p2psip@ietf.org; Wed, 04 Apr 2007 11:57:04 -0400 Received: from bayc1-pasmtp04.bayc1.hotmail.com ([65.54.191.164]) by bay0-omc1-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 4 Apr 2007 08:57:02 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp04.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 08:57:01 -0700 Message-ID: <005d01c776d1$e0d6e290$65500a0a@ronin> From: "Eric Cooper" To: "Brian Rosen" , "'Henry Sinnreich'" , "'Michael Slavitch'" , "'Paul Kyzivat'" References: <1e1a01c776c6$cb631920$81238182@cis.neustar.com> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 11:56:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 04 Apr 2007 15:57:02.0020 (UTC) FILETIME=[E24BA840:01C776D1] X-Spam-Score: 2.1 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 'David R Oran' , 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org One small example: P2P systems are fault-tolerant, so there's no need = to configure the addresses of the 'fail-over' servers. More to the general point, and this is just my opinion of course...I = think centralized systems could approach the ease of configuration that = is inherent in P2P systems, but in general they don't. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's = a necessity for P2P systems. Best Regards, Eric. ----- Original Message -----=20 From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" = ; "'Michael Slavitch'" ; = "'Paul Kyzivat'" Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" = ; "'Michael Hammer (mhammer)'" Sent: Wednesday, April 04, 2007 10:37 AM Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario >> I know of a couple of major enterprise PBX vendors who offer 1 and 2 = week- >> long training courses so that their VARs can learn to install and >> configure the PBX. Having had the training, it will generally take = an >> hour or two of configuration before the PBX gets to the point where = two >> extensions can call each other. >>=20 >> On the other hand, there are P2P PBX systems emerging that can be = unboxed, >> plugged in and start making calls in under 2 minutes. So I'd have to = say >> that P2P does have a lot to offer in this area. > With comparable feature sets? >=20 > I know of IP PBXs that can be unboxed, plugged in, and start making = calls in > maybe 10 minutes. I'm not sure the difference between 2 and 10 is = that > significant. >=20 > What does p2p have, inherently, that makes it easier? What makes the = 2 > minutes work that, say, Asterisk doesn't have? >=20 > I'll bet you its features. If you have no features, everything is = simple. > If you support any fraction of the feature set in an IP PBX, you're = where > they are now. >=20 > I once made a small wager with someone that if IP PBX vendors offered > simpler systems at a lower price, they would make much more money: the = idea > being that the complexity of the feature set had driven up the price = of the > systems so far that buyers would trade simplicity for price. I = thought if > you gave them the "top 25" feature set, with roughly out-of-the-box > functionality, that nearly all enterprises would be satisfied. >=20 > He showed me a valid marketing study that showed, quite clearly, that = I was > wrong. Users DEMANDED the features. They simply wouldn't purchase = systems > that didn't have the features they wanted, and price wouldn't change = their > mind (at least in the range of reasonable price differences). >=20 > Now, I'm not so sure if you asked the actual USERS of these systems if = they > agreed. But they don't make the purchase decisions. The ones that do = want > features. >=20 > The guys that run the big IP PBX businesses are not dumb. They know = their > customers. If there was money to be made in 2 minute set up, they = could > provide that right now (you can find some out there, do a web search). >=20 > But tell me anyways: what does p2p do that simplifies configuration = for > enterprise? >=20 > Brian > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 12:25:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8I9-0002aq-Uz; Wed, 04 Apr 2007 12:25:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8I9-0002ai-Ea; Wed, 04 Apr 2007 12:25:01 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ8I6-0000Sn-CI; Wed, 04 Apr 2007 12:25:01 -0400 Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 09:24:50 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34GOgSd010990; Wed, 4 Apr 2007 09:24:47 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34GOaI9002310; Wed, 4 Apr 2007 09:24:36 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 09:24:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Apr 2007 09:24:35 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3E@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2P SIP service assurance (was Simple SIP usage scenario) - shortened Thread-Index: Acd1fDvzIhowLornTwyehPLXZ9zr5AA/ypd/ABGlquA= References: From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 04 Apr 2007 16:24:40.0606 (UTC) FILETIME=[BEE3CBE0:01C776D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 813368b10167e7c87c318e91999bcea9 Cc: sipping@ietf.org, oran@cisco.com, p2psip@ietf.org, mhammer@cisco.com Subject: [P2PSIP] P2P SIP service assurance (was Simple SIP usage scenario) - shortened X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0226106854==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0226106854== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776D5.BE640658" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776D5.BE640658 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Colin, Paul, =20 Thanks for raising the valid issue about service assurance.=20 As engineers, we know the service assurance is more than a piece of legal paper and must be based on the following: =20 - Adequate bandwidth, - Geographic diversity, - Simplicity; so things can be managed, - Security that can be audited, - Safe data retention: Replication and the geographic diversity of peer nodes of the overlay, - Economy of scale: All peers have software with identical behavior, - No configuration is required or possible. The customer just plugs in the gateway box. This is real service automation. - Cost containment: P2P self configuration is unbeatable. Count all the savings in CAPEX and OPEX by not having any network based VoIP infrastructure. Save all that electricity and real estate in the data centers. - Flexibility for new applications: The API between SIP and the DHT overlay, - No lock-in from single source: The applications are in the endpoints. Buy them from anywhere. - Automatic updates from the application provider: This is current PC SW state of the art and works for both the (1) P2P software in the access device and (2) for the application software, such as presence, IM, voice, multimedia, etc. No or minimal is staff required. - Last but not least, besides SIP enabled communications, the overlay can also serve for many other applications for your users: Content distribution, application layer multicast for conferences, directory search, IM+A/V chat rooms, name services, etc. =20 All of the above can be easily implemented by porting well documented open source software into the residential access box or in the integrated access device (IAD) for enterprises. Just check out http://opendht.org/ and other similar sites. =20 Please don't take my word for it, just make for yourself a comparison table for your network. If you can't share the comparison with the list, can you share it with me in private? :-) =20 * as an employee of a carrier =20 I worked most of my career for carriers, so that's what prompted the above considerations. =20 Thanks, Henry =20 ________________________________ From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]=20 Sent: Wednesday, April 04, 2007 12:38 AM To: pkyzivat@cisco.com; Henry Sinnreich Cc: p2psip@ietf.org; mhammer@cisco.com; oran@cisco.com; p2prg@ietf.org; sipping@ietf.org Subject: RE: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 Henry, I like your idea of deploying sip peers in edge devices. However, as an employee of a carrier I would like to see how a carrier is able to provide service asurance to be able to provide compliant handling. Many of our customers do not understand how to install these gateways themselves, let alone how to troubleshoot. This is even more important for enterprises, which often insist on SLAs which include troubleshoot resolution limits. -----Original Message----- From: "Paul Kyzivat" To: "Henry Sinnreich" Cc: "P2PSIP Mailing List" ; "Michael Hammer (mhammer)" ; "David R Oran" ; "p2prg@ietf.org" ; "sipping@ietf.org" Sent: 3-4-07 01:11 Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario Henry Sinnreich wrote: > Paul, > >> I more or less agree with the final conclusion below. > > This is good starting point to discuss some usage scenarios. > > Putting on my former hat as an employee for a carrier, I cannot overlook > the following: > > P2P SIP implemented correctly in the residential access box or cable > set-top box indeed is a good or better replacement for the entire VoIP > network infrastructure (cost, operations, new services, etc). > Integrated access devices for the enterprise can probably play a similar > role, not to mention existing P2P PBX products (please refer to all the > advantages of P2P that need not repeated here). > > What do people think of these three usage scenarios for P2P SIP: > - SIP peer in the DSL access device, > - SIP peer in the cable access device, These seem quite reasonable, assuming that a device connected at this point is able to function properly as a peer. (I haven't been following what the assumptions are about required network capabilities of peers.) > - SIP peer in enterprise network integrated access device (IAD). I think this depends greatly on what expectations / contractual guarantees the enterprise has. Its unclear to me what guarantees can be made about a P2PSIP network will be able to make, and its unclear what kind of infrastructure would be installed by/for someone willing to make guarantees. Paul https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_001_01C776D5.BE640658 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage = scenario

Colin, = Paul,

 

Thanks for raising the valid issue = about service assurance.

As engineers, we know the service assurance is more than a piece of legal paper and must be based on the following:

 

-          Adequate bandwidth,

-          Geographic diversity,

-          Simplicity; so things can be managed,

-          Security that can be audited,

-          Safe data retention: Replication and the geographic diversity of peer nodes = of the overlay,

-          Economy of scale: All peers have software with identical = behavior,

-          No configuration is required or possible. The customer just plugs in the = gateway box. This is real service automation.

-          Cost containment: P2P self configuration is unbeatable. Count all the savings = in CAPEX and OPEX by not having any network based VoIP infrastructure. Save = all that electricity and real estate in the data = centers.

-          Flexibility for new applications: The API between SIP and the DHT = overlay,

-          No lock-in from single source: The applications are in the endpoints. Buy = them from anywhere.

-          Automatic updates from the application provider: This is current PC SW state of = the art and works for both the (1) P2P software in the access device and (2) for = the application software, such as presence, IM, voice, multimedia, etc. No = or minimal is staff required.

-          Last but not least, besides SIP enabled communications, the overlay can also = serve for many other applications for your users: Content distribution, = application layer multicast for conferences, directory search, IM+A/V chat rooms, name = services, etc.

 

All of the above can be easily = implemented by porting well documented open source software into the residential = access box or in the integrated access device (IAD) for enterprises. Just check out = http://opendht.org/ and other similar = sites.

 

Please don’t take my word for = it, just make for yourself a comparison table for your network. If you = can’t share the comparison with the list, can you share it with me in private? = J

 

Ø       as an employee of a = carrier

 

I worked most of my career for carriers, so that’s what = prompted the above considerations.

 

Thanks, = Henry

 

From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]
Sent: Wednesday, April = 04, 2007 12:38 AM
To: pkyzivat@cisco.com; = Henry Sinnreich
Cc: = p2psip@ietf.org; mhammer@cisco.com; oran@cisco.com; = p2prg@ietf.org; sipping@ietf.org
Subject: RE: [P2PSIP] Re: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

Henry,

I like your idea of deploying sip peers in edge devices. However, as an employee of a carrier I would like to see how a carrier is able to = provide service asurance to be able to provide compliant handling. Many of our customers do not understand how to install these gateways themselves, = let alone how to troubleshoot.

This is even more important for enterprises, which often  insist on = SLAs which include troubleshoot resolution limits.

-----Original Message-----
From: "Paul = Kyzivat" <pkyzivat@cisco.com>
To: "Henry Sinnreich" <hsinnrei@adobe.com>
Cc: "P2PSIP Mailing = List" <p2psip@ietf.org>; = "Michael Hammer (mhammer)" <mhammer@cisco.com>; "David R = Oran" <oran@cisco.com>; "p2prg@ietf.org" <p2prg@ietf.org>; = "sipping@ietf.org" <sipping@ietf.org>
Sent: 3-4-07 01:11
Subject: [P2PSIP] Re: [P2Prg] RE: [Sipping] Simple SIP usage scenario



Henry Sinnreich wrote:
> Paul,
>
>> I more or less agree with the final conclusion below.
>
> This is good starting point to discuss some usage scenarios.
>
> Putting on my former hat as an employee for a carrier, I cannot = overlook
> the following:
>
> P2P SIP implemented correctly in the residential access box or = cable
> set-top box indeed is a good or better replacement for the entire = VoIP
> network infrastructure (cost, operations, new services, etc).
> Integrated access devices for the enterprise can probably play a = similar
> role, not to mention existing P2P PBX products (please refer to all = the
> advantages of P2P that need not repeated here).
>
> What do people think of these three usage scenarios for P2P = SIP:
> - SIP peer in the DSL access device,
> - SIP peer in the cable access device,

These seem quite reasonable, assuming that a device connected at = this
point is able to function properly as a peer. (I haven't been = following
what the assumptions are about required network capabilities of = peers.)

> - SIP peer in enterprise network integrated access device = (IAD).

I think this depends greatly on what expectations / contractual
guarantees the enterprise has. Its unclear to me what guarantees can = be
made about a P2PSIP network will be able to make, and its unclear = what
kind of infrastructure would be installed by/for someone willing to = make
guarantees.

        Paul

https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C776D5.BE640658-- --===============0226106854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0226106854==-- From p2psip-bounces@ietf.org Wed Apr 04 12:33:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8QI-0001ov-2N; Wed, 04 Apr 2007 12:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8QG-0001om-FU for p2psip@ietf.org; Wed, 04 Apr 2007 12:33:24 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ8Q7-0002x6-KC for p2psip@ietf.org; Wed, 04 Apr 2007 12:33:24 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34GX3QP014775 for ; Wed, 4 Apr 2007 12:33:03 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 12:33:02 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90C8@photon.objectworld.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd20wdvkDv6UnlRSHCc9k3sNEP35AAAAHcQ References: <1e1a01c776c6$cb631920$81238182@cis.neustar.com> <005d01c776d1$e0d6e290$65500a0a@ronin> From: "Michael Slavitch" To: , , , X-Spam-Score: 0.70 () [Tag at 20.00] HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.1 (/) X-Scan-Signature: be1e5ad20f6e15b349a42c2dfbdd71ac Cc: oran@cisco.com, p2psip@ietf.org, mhammer@cisco.com X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1487125654==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1487125654== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776D6.EA69593D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776D6.EA69593D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Eric Cooper eric_d_cooper@sympatico.ca said something I consider rather key. My comments are inline. =20 "P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers. =20 More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't. =20 MNS> They can be (they better be, that's what I do for a living) but doing so is much harder than people think especially with existing multivendor product with multiple slightly different to be totally incompatible flavours of largely the same thing. Look at how hard it is for Microsoft to automate plug-and-play components.=20 =20 Given x units of work to produce a 'must have' feature that somebody WILL buy and 10x units of work to produce ease of configuration that a lot of people MAY buy guess which gets priority unless 'ease of use' is a core value of the organization or it is forced down their throats by customers. I still know engineers who think the iPod is stupid because it is too simple and doesn't have enough buttons or widgets. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems." =20 All it takes is a good sales team to turn "nice to have" into "RFP Mandatory", especially when the "nice to have" becomes "former OPEX budget gets used for my other CAPEX/OPEX stuff". Oracle's entire sales strategy is to pay for increased Oracle CAPEX/OPEX out of reduced telecom/noc CAPEX/OPEX. The Oracle IT guys in a company hit the PBX guys with an ugly club, take over their OPEX/CAPEX budget delivering the same capabilities, and buy Oracle stuff with what's left, which is exactly how Cisco has sold VOIP to the NOC for the past several years. Both Oracle and Cisco salespeople are REALLY good at explaining how to get away with budget murder, and until recently each company seemed content at picking at the weaklings before turning on each other, as they're both getting ready for a fight with Big Redmond Bill. The same battles apply even with little fish down to the SME, but as you go down the food chain automation and ease of deployment become increasingly important as you can't bury deployment costs in professional services. When it comes down to it, the big battle isn't about technology but budget. =20 If you want a very diplomatically worded description of OPEX Budget Murder the above please see my employer's website for a customer case study or send me an email and I'll give you a PDF copy. =20 Regards =20 Michael Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com =20 =20 -----Original Message----- From: michael.slavitch@e2exchange.com [mailto:michael.slavitch@e2exchange.com] On Behalf Of Michael Slavitch Sent: Wednesday, April 04, 2007 12:05 PM To: Michael Slavitch Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 ---------- Forwarded message ---------- FromDate: Apr 4, 2007 11:56 AM Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario To: Brian Rosen , Henry Sinnreich , Michael Slavitch , Paul Kyzivat Cc: David R Oran , P2PSIP Mailing List , "Michael Hammer (mhammer)" =20 =20 One small example: P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers. =20 More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems. =20 Best Regards, =20 Eric. =20 ----- Original Message ----- From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" ; "'Michael Slavitch'" ; "'Paul Kyzivat'" Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" ; "'Michael Hammer (mhammer)'" Sent: Wednesday, April 04, 2007 10:37 AM Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 =20 >> I know of a couple of major enterprise PBX vendors who offer 1 and 2 week- >> long training courses so that their VARs can learn to install and >> configure the PBX. Having had the training, it will generally take an >> hour or two of configuration before the PBX gets to the point where two >> extensions can call each other. >>=20 >> On the other hand, there are P2P PBX systems emerging that can be unboxed, >> plugged in and start making calls in under 2 minutes. So I'd have to say >> that P2P does have a lot to offer in this area. > With comparable feature sets? >=20 > I know of IP PBXs that can be unboxed, plugged in, and start making calls in > maybe 10 minutes. I'm not sure the difference between 2 and 10 is that > significant. >=20 > What does p2p have, inherently, that makes it easier? What makes the 2 > minutes work that, say, Asterisk doesn't have? >=20 > I'll bet you its features. If you have no features, everything is simple. > If you support any fraction of the feature set in an IP PBX, you're where > they are now. >=20 > I once made a small wager with someone that if IP PBX vendors offered > simpler systems at a lower price, they would make much more money: the idea > being that the complexity of the feature set had driven up the price of the > systems so far that buyers would trade simplicity for price. I thought if > you gave them the "top 25" feature set, with roughly out-of-the-box > functionality, that nearly all enterprises would be satisfied. >=20 > He showed me a valid marketing study that showed, quite clearly, that I was > wrong. Users DEMANDED the features. They simply wouldn't purchase systems > that didn't have the features they wanted, and price wouldn't change their > mind (at least in the range of reasonable price differences). >=20 > Now, I'm not so sure if you asked the actual USERS of these systems if they > agreed. But they don't make the purchase decisions. The ones that do want > features. >=20 > The guys that run the big IP PBX businesses are not dumb. They know their > customers. If there was money to be made in 2 minute set up, they could > provide that right now (you can find some out there, do a web search). >=20 > But tell me anyways: what does p2p do that simplifies configuration for > enterprise? >=20 > Brian >=20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 --=20 =20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_001_01C776D6.EA69593D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Eric Cooper eric_d_cooper@sympatico.ca said something I consider rather key.   My comments are inline.

 

"P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers.

 

More to the general p= oint, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't.

 

MNS> They can be (they better be, that’s w= hat I do for a living) but doing so is much harder than people think especially w= ith existing multivendor product with multiple slightly different to be totally incompatible flavours of largely the same thing.   Look at how ha= rd it is for Microsoft to automate plug-and-play components.

 

 Given x units of work to produce a ‘mus= t have’ feature that somebody WILL buy and 10x units of work to produce ease of con= figuration that a lot of people MAY buy guess which gets priority unless ‘ease of use’ is a core value of the organization or it is forced down their throats by customers.   I still know engineers who think the iPod= is stupid because it is too simple and doesn’t have enough buttons or widgets.

 

Easy configuration is= a 'nice-to-have' for centralized systems, but it's a necessity for P2P system= s."

 

All it takes is a good sales team to turn “ni= ce to have” into “RFP Mandatory”, especially when the “ni= ce to have” becomes “former OPEX budget gets used for my other CAP= EX/OPEX stuff”.    Oracle’s entire sales strategy is to = pay for increased Oracle CAPEX/OPEX out of reduced telecom/noc CAPEX/OPEX. = ; The Oracle IT guys in a company hit the PBX guys with an ugly club, take over t= heir OPEX/CAPEX budget delivering the same capabilities, and buy Oracle stuff wi= th what’s left, which is exactly how Cisco has sold VOIP to the NOC for = the past several years.  Both Oracle and Cisco salespeople are REALLY good= at explaining how to get away with budget murder, and until recently each comp= any seemed content at picking at the weaklings before turning on each other, as they’re both getting ready for a fight with Big Redmond Bill. &n= bsp; The same battles apply even with little fish down to the SME, but as you go down the food chain automation and ease of deployment become increasingly important as you can’t bury deployment costs in professional services= .  When it comes down to it, the big battle isn’t about technology but budget.

 

If you want a very diplomatically worded descriptio= n of OPEX Budget Murder the above please see my employer’s website for a custom= er case study or send me an email and I’ll give you a PDF copy.

 

Regards

 

Michael

Michael Slavitch           &= nbsp; 

Lead, Technology Initiatives

slavitch@objectworld.com

 

 

-----Original Message-----
From: michael.slavitch@e2exchange.com [mailto:michael.slavitch@e2exchange.c= om] On Behalf Of Michael Slavitch
Sent: Wednesday, April 04, 2007 12:05 PM
To: Michael Slavitch
Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario<= o:p>

 

---------- Forwarded message ----------<= /p>

FromDate: Apr 4, 2007 11:56 AM

Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Sim= ple SIP usage scenario

To: Brian Rosen <br@brianrosen.net>, Henry Si= nnreich

<hsinnrei@adobe.com>, Michael Slavitch <slavitch@objectworld.com>,

Paul Kyzivat <pkyzivat@cisco.com><= /p>

Cc: David R Oran <oran@cisco.com>, P2PSIP Mai= ling List

<p2psip@ietf.org>, "Michael Hammer (mhammer)" <mhammer@cisco.com>

 

 

One small example:  P2P systems are fault-tole= rant, so there's no need

to configure the addresses of the 'fail-over' serve= rs.

 

More to the general point, and this is just my opin= ion of course...I

think centralized systems could approach the ease of configuration

that is inherent in P2P systems, but in general they don't.

 

Easy configuration is a 'nice-to-have' for centrali= zed systems, but

it's a necessity for P2P systems.

 

Best Regards,

 

Eric.

 

----- Original Message -----

From: "Brian Rosen" <br@brianrosen.net= >

To: "'Eric Cooper'" <eric_d_cooper@sympatico.ca>; "'Henry Sinnreich'"

<hsinnrei@adobe.com>; "'Michael Slavitch'" <slavitch@objectworld.com>;

"'Paul Kyzivat'" <pkyzivat@cisco.com&g= t;

Cc: "'David R Oran'" <oran@cisco.com&g= t;; "'P2PSIP Mailing List'"

<p2psip@ietf.org>; "'Michael Hammer (mhammer)'" <mhammer@cisco.com>

Sent: Wednesday, April 04, 2007 10:37 AM=

Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Sim= ple SIP usage scenario

 

 

>> I know of a couple of major enterprise PBX vendors who offer 1 and 2 week-

>> long training courses so that their VARs c= an learn to install and

>> configure the PBX.  Having had the training, it will generally take an

>> hour or two of configuration before the PB= X gets to the point where two

>> extensions can call each other.=

>> 

>> On the other hand, there are P2P PBX syste= ms emerging that can be unboxed,

>> plugged in and start making calls in under= 2 minutes.  So I'd have to say

>> that P2P does have a lot to offer in this = area.

> With comparable feature sets?

> 

> I know of IP PBXs that can be unboxed, plugged= in, and start making calls in

> maybe 10 minutes.  I'm not sure the diffe= rence between 2 and 10 is that

> significant.

> 

> What does p2p have, inherently, that makes it easier?  What makes the 2

> minutes work that, say, Asterisk doesn't have?=

> 

> I'll bet you its features.  If you have no features, everything is simple.

> If you support any fraction of the feature set= in an IP PBX, you're where

> they are now.

> 

> I once made a small wager with someone that if= IP PBX vendors offered

> simpler systems at a lower price, they would m= ake much more money: the idea

> being that the complexity of the feature set h= ad driven up the price of the

> systems so far that buyers would trade simplic= ity for price.  I thought if

> you gave them the "top 25" feature s= et, with roughly out-of-the-box

> functionality, that nearly all enterprises wou= ld be satisfied.

> 

> He showed me a valid marketing study that show= ed, quite clearly, that I was

> wrong.  Users DEMANDED the features. = ; They simply wouldn't purchase systems

> that didn't have the features they wanted, and= price wouldn't change their

> mind (at least in the range of reasonable price differences).

> 

> Now, I'm not so sure if you asked the actual U= SERS of these systems if they

> agreed.  But they don't make the purchase decisions.  The ones that do want

> features.

> 

> The guys that run the big IP PBX businesses ar= e not dumb.  They know their

> customers.  If there was money to be made= in 2 minute set up, they could

> provide that right now (you can find some out = there, do a web search).

> 

> But tell me anyways: what does p2p do that simplifies configuration for

> enterprise?

> 

> Brian

> 

 

_______________________________________________

P2PSIP mailing list

P2PSIP@ietf.org

https://www1.ietf.org/mailman/listinfo/p2psip<= /o:p>

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS

---------------------------------------------------= ---

 

Teach CanIt if this mail (ID 658457) is spam:<= /o:p>

Spam:        http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc54= 03d2&c=3Ds

Not spam:    http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc54= 03d2&c=3Dn

Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc54= 03d2&c=3Df

---------------------------------------------------= ---

END-ANTISPAM-VOTING-LINKS

 

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_001_01C776D6.EA69593D-- --===============1487125654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1487125654==-- From p2psip-bounces@ietf.org Wed Apr 04 13:20:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ99S-0002ky-Oz; Wed, 04 Apr 2007 13:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ99R-0002km-H2 for p2psip@ietf.org; Wed, 04 Apr 2007 13:20:05 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZ99P-0004Mn-0b for p2psip@ietf.org; Wed, 04 Apr 2007 13:20:05 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 10:19:56 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34HJOD1027624; Wed, 4 Apr 2007 10:19:24 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34HJaIB015584; Wed, 4 Apr 2007 10:19:36 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 10:19:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 10:19:32 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3F@namail5.corp.adobe.com> In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90C8@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd20wdvkDv6UnlRSHCc9k3sNEP35AAAAHcQAAJ09+A= References: <1e1a01c776c6$cb631920$81238182@cis.neustar.com> <005d01c776d1$e0d6e290$65500a0a@ronin> <4E2DC1ACE541B94A946B8D8657E372C57A90C8@photon.objectworld.com> From: "Henry Sinnreich" To: "Michael Slavitch" , , , X-OriginalArrivalTime: 04 Apr 2007 17:19:41.0324 (UTC) FILETIME=[6E4564C0:01C776DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92223e791a86c0e8c238fc6d8c729a6 Cc: oran@cisco.com, p2psip@ietf.org, mhammer@cisco.com X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1470540663==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1470540663== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776DD.6D599C0A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776DD.6D599C0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can we just replace the MUST have with MAY have? Or just avoid the murders by skilled sales organizations "sales team to turn "nice to have" into "RFP Mandatory" And specify MUST NOT have PBX features? =20 I prefer the GPS on the Blackberry to any PBX features any time! =20 Thanks, Henry =20 ________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Wednesday, April 04, 2007 11:33 AM To: eric_d_cooper@sympatico.ca; br@brianrosen.net; Henry Sinnreich; pkyzivat@cisco.com Cc: oran@cisco.com; p2psip@ietf.org; mhammer@cisco.com Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 Eric Cooper eric_d_cooper@sympatico.ca said something I consider rather key. My comments are inline. =20 "P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers. =20 More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't. =20 MNS> They can be (they better be, that's what I do for a living) but doing so is much harder than people think especially with existing multivendor product with multiple slightly different to be totally incompatible flavours of largely the same thing. Look at how hard it is for Microsoft to automate plug-and-play components.=20 =20 Given x units of work to produce a 'must have' feature that somebody WILL buy and 10x units of work to produce ease of configuration that a lot of people MAY buy guess which gets priority unless 'ease of use' is a core value of the organization or it is forced down their throats by customers. I still know engineers who think the iPod is stupid because it is too simple and doesn't have enough buttons or widgets. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems." =20 All it takes is a good sales team to turn "nice to have" into "RFP Mandatory", especially when the "nice to have" becomes "former OPEX budget gets used for my other CAPEX/OPEX stuff". Oracle's entire sales strategy is to pay for increased Oracle CAPEX/OPEX out of reduced telecom/noc CAPEX/OPEX. The Oracle IT guys in a company hit the PBX guys with an ugly club, take over their OPEX/CAPEX budget delivering the same capabilities, and buy Oracle stuff with what's left, which is exactly how Cisco has sold VOIP to the NOC for the past several years. Both Oracle and Cisco salespeople are REALLY good at explaining how to get away with budget murder, and until recently each company seemed content at picking at the weaklings before turning on each other, as they're both getting ready for a fight with Big Redmond Bill. The same battles apply even with little fish down to the SME, but as you go down the food chain automation and ease of deployment become increasingly important as you can't bury deployment costs in professional services. When it comes down to it, the big battle isn't about technology but budget. =20 If you want a very diplomatically worded description of OPEX Budget Murder the above please see my employer's website for a customer case study or send me an email and I'll give you a PDF copy. =20 Regards =20 Michael =20 Michael Slavitch =20 Lead, Technology Initiatives slavitch@objectworld.com =20 =20 =20 =20 =20 =20 -----Original Message----- From: michael.slavitch@e2exchange.com [mailto:michael.slavitch@e2exchange.com] On Behalf Of Michael Slavitch Sent: Wednesday, April 04, 2007 12:05 PM To: Michael Slavitch Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 ---------- Forwarded message ---------- FromDate: Apr 4, 2007 11:56 AM Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario To: Brian Rosen , Henry Sinnreich , Michael Slavitch , Paul Kyzivat Cc: David R Oran , P2PSIP Mailing List , "Michael Hammer (mhammer)" =20 =20 One small example: P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers. =20 More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems. =20 Best Regards, =20 Eric. =20 ----- Original Message ----- From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" ; "'Michael Slavitch'" ; "'Paul Kyzivat'" Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" ; "'Michael Hammer (mhammer)'" Sent: Wednesday, April 04, 2007 10:37 AM Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 =20 >> I know of a couple of major enterprise PBX vendors who offer 1 and 2 week- >> long training courses so that their VARs can learn to install and >> configure the PBX. Having had the training, it will generally take an >> hour or two of configuration before the PBX gets to the point where two >> extensions can call each other. >>=20 >> On the other hand, there are P2P PBX systems emerging that can be unboxed, >> plugged in and start making calls in under 2 minutes. So I'd have to say >> that P2P does have a lot to offer in this area. > With comparable feature sets? >=20 > I know of IP PBXs that can be unboxed, plugged in, and start making calls in > maybe 10 minutes. I'm not sure the difference between 2 and 10 is that > significant. >=20 > What does p2p have, inherently, that makes it easier? What makes the 2 > minutes work that, say, Asterisk doesn't have? >=20 > I'll bet you its features. If you have no features, everything is simple. > If you support any fraction of the feature set in an IP PBX, you're where > they are now. >=20 > I once made a small wager with someone that if IP PBX vendors offered > simpler systems at a lower price, they would make much more money: the idea > being that the complexity of the feature set had driven up the price of the > systems so far that buyers would trade simplicity for price. I thought if > you gave them the "top 25" feature set, with roughly out-of-the-box > functionality, that nearly all enterprises would be satisfied. >=20 > He showed me a valid marketing study that showed, quite clearly, that I was > wrong. Users DEMANDED the features. They simply wouldn't purchase systems > that didn't have the features they wanted, and price wouldn't change their > mind (at least in the range of reasonable price differences). >=20 > Now, I'm not so sure if you asked the actual USERS of these systems if they > agreed. But they don't make the purchase decisions. The ones that do want > features. >=20 > The guys that run the big IP PBX businesses are not dumb. They know their > customers. If there was money to be made in 2 minute set up, they could > provide that right now (you can find some out there, do a web search). >=20 > But tell me anyways: what does p2p do that simplifies configuration for > enterprise? >=20 > Brian >=20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 --=20 BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ =20 Teach CanIt if this mail (ID 658457) is spam: Spam: http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc5403= d2& c=3Ds Not spam: http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc5403= d2& c=3Dn Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc5403= d2& c=3Df ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS =20 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ------_=_NextPart_001_01C776DD.6D599C0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can we just replace the MUST have = with MAY have?

Or just avoid the murders by = skilled sales organizations = “sales team to turn “nice to have” into “RFP = Mandatory”

And specify MUST NOT have PBX = features?

 

I prefer the GPS on the Blackberry = to any PBX features any time!

 

Thanks, = Henry

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Wednesday, April = 04, 2007 11:33 AM
To: = eric_d_cooper@sympatico.ca; br@brianrosen.net; Henry Sinnreich; pkyzivat@cisco.com
Cc: oran@cisco.com; = p2psip@ietf.org; mhammer@cisco.com
Subject: RE: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

Eric Cooper = eric_d_cooper@sympatico.ca= said something I consider rather key.   My comments are = inline.

 

"P2P systems are = fault-tolerant, so there's no need to configure the addresses of the 'fail-over' = servers.

 <= /p>

More to the general point, and = this is just my opinion of course...I think centralized systems could approach = the ease of configuration that is inherent in P2P systems, but in general they = don't.

 

MNS> They can be (they better be, that’s what I do for a living) but = doing so is much harder than people think especially with existing multivendor = product with multiple slightly different to be totally incompatible flavours of = largely the same thing.   Look at = how hard it is for Microsoft to automate plug-and-play components. =

 

 Given x units of work to produce a ‘must have’ feature that = somebody WILL buy and 10x units of work to produce ease of configuration that a lot of = people MAY buy guess which gets priority unless ‘ease of use’ is a = core value of the organization = or it is forced down their throats by customers.   I still know = engineers who think the iPod is stupid because it is too simple and doesn’t have = enough buttons or widgets.

 <= /p>

Easy configuration is a = 'nice-to-have' for centralized systems, but it's a necessity for P2P = systems."

 <= /p>

All it takes is a good sales team to turn “nice to have” into = “RFP Mandatory”, especially when the “nice to have” becomes = “former OPEX budget gets used for my other CAPEX/OPEX stuff”.  =   Oracle’s entire sales strategy is to pay for increased Oracle CAPEX/OPEX out of = reduced telecom/noc CAPEX/OPEX.  The Oracle IT guys in a company hit the = PBX guys with an ugly club, take over their OPEX/CAPEX budget delivering the same capabilities, and buy Oracle stuff with what’s left, which is = exactly how Cisco has sold VOIP to the NOC for the past several years.  Both = Oracle and Cisco salespeople are REALLY good at explaining how to get away with = budget murder, and until recently each company seemed content at picking at the weaklings before turning on each other, as they’re both getting = ready for a fight with Big Redmond Bill.   The same battles apply even = with little fish down to the SME, but as you go down the food chain = automation and ease of deployment become increasingly important as you can’t bury deployment costs in professional services.  When it comes down to = it, the big battle isn’t about technology but = budget.

 

If you want a very diplomatically worded description of OPEX Budget Murder = the above please see my employer’s website for a customer case study = or send me an email and I’ll give you a PDF = copy.

 

Regards

 

Michael

 

Michael Slavitch           = ;  

Lead, Technology Initiatives

slavitch@objectworld.com

 

 

 

 

 

 

-----Original Message-----
From: michael.slavitch@e2exchange.com = [mailto:michael.slavitch@e2exchange.com] On Behalf Of Michael Slavitch
Sent: Wednesday, April 04, 2007 12:05 PM
To: Michael Slavitch
Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

---------- Forwarded message ----------

FromDate: Apr 4, 2007 11:56 AM

Subject: Re: [P2PSIP] RE: [P2Prg] = RE: [Sipping] Simple SIP usage scenario

To: Brian Rosen <br@brianrosen.net>, Henry Sinnreich

<hsinnrei@adobe.com>, Michael Slavitch = <slavitch@objectworld.com>,

Paul Kyzivat <pkyzivat@cisco.com>

Cc: David R Oran = <oran@cisco.com>, P2PSIP Mailing = List

<p2psip@ietf.org>, "Michael Hammer (mhammer)" = <mhammer@cisco.com>

 

 

One small example:  P2P systems are fault-tolerant, so there's no = need

to configure the addresses of the 'fail-over' = servers.

 

More to the general point, and this is just my opinion of = course...I

think centralized systems could approach the ease of = configuration

that is inherent in P2P systems, but in general they = don't.

 

Easy configuration is a 'nice-to-have' for centralized systems, = but

it's a necessity for P2P systems.

 

Best Regards,

 

Eric.

 

----- Original Message -----

From: "Brian Rosen" <br@brianrosen.net>

To: "'Eric Cooper'" <eric_d_cooper@sympatico.ca>; "'Henry = Sinnreich'"

<hsinnrei@adobe.com>; "'Michael = Slavitch'" <slavitch@objectworld.com>;

"'Paul Kyzivat'" = <pkyzivat@cisco.com>

Cc: "'David R Oran'" <oran@cisco.com>; "'P2PSIP = Mailing List'"

<p2psip@ietf.org>; "'Michael Hammer (mhammer)'" = <mhammer@cisco.com>

Sent: Wednesday, April 04, 2007 10:37 AM

Subject: RE: [P2PSIP] RE: [P2Prg] = RE: [Sipping] Simple SIP usage scenario

 

 

>> I know of a couple of major enterprise PBX vendors who offer 1 and 2 = week-

>> long training courses so that their VARs can learn to install = and

>> configure the PBX.  Having had the training, it will generally take = an

>> hour or two of configuration before the PBX gets to the point where = two

>> extensions can call each other.

>> 

>> On the other hand, there are P2P PBX systems emerging that can be unboxed,

>> plugged in and start making calls in under 2 minutes.  So I'd have = to say

>> that P2P does have a lot to offer in this = area.

> With comparable feature sets?

> 

> I know of IP PBXs that can be unboxed, plugged in, and start making = calls in

> maybe 10 minutes.  I'm not sure the difference between 2 and 10 is = that

> significant.

> 

> What does p2p have, inherently, that makes it easier?  What makes = the 2

> minutes work that, say, Asterisk doesn't = have?

> 

> I'll bet you its features.  If you have no features, everything is = simple.

> If you support any fraction of the feature set in an IP PBX, you're = where

> they are now.

> 

> I once made a small wager with someone that if IP PBX vendors = offered

> simpler systems at a lower price, they would make much more money: the = idea

> being that the complexity of the feature set had driven up the price of = the

> systems so far that buyers would trade simplicity for price.  I = thought if

> you gave them the "top 25" feature set, with roughly = out-of-the-box

> functionality, that nearly all enterprises would be = satisfied.

> 

> He showed me a valid marketing study that showed, quite clearly, that I = was

> wrong.  Users DEMANDED the features.  They simply wouldn't = purchase systems

> that didn't have the features they wanted, and price wouldn't change = their

> mind (at least in the range of reasonable price = differences).

> 

> Now, I'm not so sure if you asked the actual USERS of these systems if = they

> agreed.  But they don't make the purchase decisions.  The ones = that do want

> features.

> 

> The guys that run the big IP PBX businesses are not dumb.  They = know their

> customers.  If there was money to be made in 2 minute set up, they = could

> provide that right now (you can find some out there, do a web = search).

> 

> But tell me anyways: what does p2p do that simplifies configuration = for

> enterprise?

> 

> Brian

> 

 

______________________________________________= _

P2PSIP mailing list

P2PSIP@ietf.org

https://www1.ietf.org/mailman/listinfo/p2psip=

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS<= /font>

----------------------------------------------= --------

 

Teach CanIt if this mail (ID 658457) is spam:

Spam:       = ; http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc= 5403d2&c=3Ds

Not spam:    = http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc= 5403d2&c=3Dn

Forget vote: http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc= 5403d2&c=3Df

----------------------------------------------= --------

END-ANTISPAM-VOTING-LINKS

 

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of the = author and may not represent those of Objectworld Communications = Corp.

------_=_NextPart_001_01C776DD.6D599C0A-- --===============1470540663== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1470540663==-- From p2psip-bounces@ietf.org Wed Apr 04 14:23:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZA8m-0007YA-Sj; Wed, 04 Apr 2007 14:23:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZA8l-0007Y5-NF for p2psip@ietf.org; Wed, 04 Apr 2007 14:23:27 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZA8j-00059F-6N for p2psip@ietf.org; Wed, 04 Apr 2007 14:23:27 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34IN6iD016678 for ; Wed, 4 Apr 2007 14:23:06 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 14:23:05 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90DB@photon.objectworld.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3F@namail5.corp.adobe.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd20wdvkDv6UnlRSHCc9k3sNEP35AAAAHcQAAJ09+AAAahnUA== References: <1e1a01c776c6$cb631920$81238182@cis.neustar.com> <005d01c776d1$e0d6e290$65500a0a@ronin> <4E2DC1ACE541B94A946B8D8657E372C57A90C8@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF3F@namail5.corp.adobe.com> From: "Michael Slavitch" To: "Henry Sinnreich" , , , X-Spam-Score: 4.50 (****) [Tag at 20.00] EXTRA_MPART_TYPE, HTML_MESSAGE, J_BACKHAIR_12, J_BACKHAIR_22, J_BACKHAIR_23, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.2 (/) X-Scan-Signature: 99f473fda9635c21a2e5fa5cc4ac13ac Cc: oran@cisco.com, p2psip@ietf.org, mhammer@cisco.com X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1645077992==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1645077992== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C776E6.4A6DD54B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776E6.4A6DD54B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C776E6.4A6DD54B" ------_=_NextPart_002_01C776E6.4A6DD54B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I believe that it should be as follows: =20 A P2PSIP nodye MAY have features. //no need to get specific on what features it MAY have. Another word for feature is SERVICE. A feature MUST BE a logical representation of a repeatable communications function that has a specified outcome or result.=20 A feature MUST BE self-contained. A feature MAY BE composed of other features. Features are environment-specific - they are constrained or enabled by context and must be described within that context.=20 A feature MUST be a black box to users of the feature. A feature MUST conform to strong governance regarding service representation and implementation. ALL features MUST be FULLY ADVERTISED to P2P members that have global credentials (ie, I won't sign you if you have seekrit features). (ALL features MUST be signed* by P2P members that have appropriate credentials)* // Boss node knows all features and decides which get used. ALL feature interfaces MUST be FULLY DESCRIBED with a machine readable definition as per definition RFCXXXX (BNF/XML?). A feature must offer a "Litmus Test", which determines a service guarantee as per RFCXXXX. //takes care of service guarantees. This looks a lot like the Open Group definition of SOA. We will all get much better paying jobs renaming P2PSIP as SOASIP. Regards M =20 =20 =20 =20 =20 =20 =09=09=20=09=20 Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com =09=09=20=09=20 =20 =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, April 04, 2007 1:20 PM To: Michael Slavitch; eric_d_cooper@sympatico.ca; br@brianrosen.net; pkyzivat@cisco.com Cc: oran@cisco.com; p2psip@ietf.org; mhammer@cisco.com Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 Can we just replace the MUST have with MAY have? Or just avoid the murders by skilled sales organizations "sales team to turn "nice to have" into "RFP Mandatory" And specify MUST NOT have PBX features? =20 I prefer the GPS on the Blackberry to any PBX features any time! =20 Thanks, Henry =20 ________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Wednesday, April 04, 2007 11:33 AM To: eric_d_cooper@sympatico.ca; br@brianrosen.net; Henry Sinnreich; pkyzivat@cisco.com Cc: oran@cisco.com; p2psip@ietf.org; mhammer@cisco.com Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 Eric Cooper eric_d_cooper@sympatico.ca said something I consider rather key. My comments are inline. =20 "P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers. =20 More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't. =20 MNS> They can be (they better be, that's what I do for a living) but doing so is much harder than people think especially with existing multivendor product with multiple slightly different to be totally incompatible flavours of largely the same thing. Look at how hard it is for Microsoft to automate plug-and-play components.=20 =20 Given x units of work to produce a 'must have' feature that somebody WILL buy and 10x units of work to produce ease of configuration that a lot of people MAY buy guess which gets priority unless 'ease of use' is a core value of the organization or it is forced down their throats by customers. I still know engineers who think the iPod is stupid because it is too simple and doesn't have enough buttons or widgets. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems." =20 All it takes is a good sales team to turn "nice to have" into "RFP Mandatory", especially when the "nice to have" becomes "former OPEX budget gets used for my other CAPEX/OPEX stuff". Oracle's entire sales strategy is to pay for increased Oracle CAPEX/OPEX out of reduced telecom/noc CAPEX/OPEX. The Oracle IT guys in a company hit the PBX guys with an ugly club, take over their OPEX/CAPEX budget delivering the same capabilities, and buy Oracle stuff with what's left, which is exactly how Cisco has sold VOIP to the NOC for the past several years. Both Oracle and Cisco salespeople are REALLY good at explaining how to get away with budget murder, and until recently each company seemed content at picking at the weaklings before turning on each other, as they're both getting ready for a fight with Big Redmond Bill. The same battles apply even with little fish down to the SME, but as you go down the food chain automation and ease of deployment become increasingly important as you can't bury deployment costs in professional services. When it comes down to it, the big battle isn't about technology but budget. =20 If you want a very diplomatically worded description of OPEX Budget Murder the above please see my employer's website for a customer case study or send me an email and I'll give you a PDF copy. =20 Regards =20 Michael =20 Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com =20 =20 =20 =20 =20 =20 -----Original Message----- From: michael.slavitch@e2exchange.com [mailto:michael.slavitch@e2exchange.com] On Behalf Of Michael Slavitch Sent: Wednesday, April 04, 2007 12:05 PM To: Michael Slavitch Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 ---------- Forwarded message ---------- FromDate: Apr 4, 2007 11:56 AM Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario To: Brian Rosen , Henry Sinnreich , Michael Slavitch , Paul Kyzivat Cc: David R Oran , P2PSIP Mailing List , "Michael Hammer (mhammer)" =20 =20 One small example: P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers. =20 More to the general point, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't. =20 Easy configuration is a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems. =20 Best Regards, =20 Eric. =20 ----- Original Message ----- From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" ; "'Michael Slavitch'" ; "'Paul Kyzivat'" Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" ; "'Michael Hammer (mhammer)'" Sent: Wednesday, April 04, 2007 10:37 AM Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 =20 >> I know of a couple of major enterprise PBX vendors who offer 1 and 2 week- >> long training courses so that their VARs can learn to install and >> configure the PBX. Having had the training, it will generally take an >> hour or two of configuration before the PBX gets to the point where two >> extensions can call each other. >>=20 >> On the other hand, there are P2P PBX systems emerging that can be unboxed, >> plugged in and start making calls in under 2 minutes. So I'd have to say >> that P2P does have a lot to offer in this area. > With comparable feature sets? >=20 > I know of IP PBXs that can be unboxed, plugged in, and start making calls in > maybe 10 minutes. I'm not sure the difference between 2 and 10 is that > significant. >=20 > What does p2p have, inherently, that makes it easier? What makes the 2 > minutes work that, say, Asterisk doesn't have? >=20 > I'll bet you its features. If you have no features, everything is simple. > If you support any fraction of the feature set in an IP PBX, you're where > they are now. >=20 > I once made a small wager with someone that if IP PBX vendors offered > simpler systems at a lower price, they would make much more money: the idea > being that the complexity of the feature set had driven up the price of the > systems so far that buyers would trade simplicity for price. I thought if > you gave them the "top 25" feature set, with roughly out-of-the-box > functionality, that nearly all enterprises would be satisfied. >=20 > He showed me a valid marketing study that showed, quite clearly, that I was > wrong. Users DEMANDED the features. They simply wouldn't purchase systems > that didn't have the features they wanted, and price wouldn't change their > mind (at least in the range of reasonable price differences). >=20 > Now, I'm not so sure if you asked the actual USERS of these systems if they > agreed. But they don't make the purchase decisions. The ones that do want > features. >=20 > The guys that run the big IP PBX businesses are not dumb. They know their > customers. If there was money to be made in 2 minute set up, they could > provide that right now (you can find some out there, do a web search). >=20 > But tell me anyways: what does p2p do that simplifies configuration for > enterprise? >=20 > Brian >=20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 --=20 =20 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_002_01C776E6.4A6DD54B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

I believe that it should b= e as follows:

 

A P2PSIP nodye MAY have fe= atures.      //no need to get specific on what features it MAY have.  Another word = for feature is SERVICE.

A feature MUST BE  a logical representation of a repeatable communications function that has a specified outcome or result.

A feature MUST BE self-contained.

A feature MAY BE composed of other features.

Features are environment-specific – they are con= strained or enabled by context and must be described within that context.

A feature MUST be a black box to users of the feature.=

A feature MUST conf= orm to strong governance regarding service representation and implementation.=

     A= LL features MUST be FULLY ADVERTISED to P2P members that have global credentials (ie,&n= bsp; I won’t sign you if you have seekrit features). 

    (ALL fe= atures MUST be signed* by P2P members that have appropriate credentials)*  // Boss node knows all features and decides which get used.

     ALL feature interfaces MUST b= e FULLY DESCRIBED with a machine readable definition as per definition RFCXXXX (BNF/XML?).

     A feature must offer a “= ;Litmus Test", which determines a service guarantee as per RFCXXXX.  //ta= kes care of service guarantees.

This looks a lot like the Open Group definition of SOA.   We will all = get much better paying jobs renaming P2PSIP as SOASIP.

Regards<= /p>

M

 

 

 

 =

3D"corp_2colour"

 =

 

Michael Slavitch          &nb= sp;  

Lead, Technology Initi= atives

slavitch@objectworld.c= om

 

=  

 

From: Henry Sinnrei= ch [mailto:hsinnrei@adobe.com]
Sent: Wednesday, April 04, 2007 1:20 PM
To: Michael Slavitch; eric_d_cooper@sympatico.ca; br@brianrosen.net; pkyzivat@cisco.com
Cc: oran@cisco.com; p2psip@ietf.org; mhammer@cisco.com
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

Can we just replace the MUST have with MAY have?

Or just avoid the murders by skilled sales organizations “sales team to turn “nice to have” into “RFP Mandatory”

And specify MUST NOT have PBX features?

 

I prefer the GPS on the Blackberry to any PBX fea= tures any time!

 

Thanks, Henry

 

From: Michael Slavi= tch [mailto:slavitch@objectworld.com]
Sent: Wednesday, April 04, 2007 11:33 AM
To: eric_d_cooper@sympatico.ca; br@brianrosen.net; Henry Sinnreich; pkyzivat@cisco.com
Cc: oran@cisco.com; p2psip@ietf.org; mhammer@cisco.com
Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

Eric Cooper eric_d_cooper@sympatico.ca s= aid something I consider rather key.   My comments are inline.

 

"P2P systems are fault-tolerant, so there's no need to configure the addresses of the 'fail-over' servers.

 

More to the general p= oint, and this is just my opinion of course...I think centralized systems could approach the ease of configuration that is inherent in P2P systems, but in general they don't.

 

MNS> They can be (they better be, that’s w= hat I do for a living) but doing so is much harder than people think especially w= ith existing multivendor product with multiple slightly different to be totally incompatible flavours of large= ly the same thing.   Look at how hard it is for Microsoft to automate plug-and-play components.

 

 Given x units of work to produce a ‘must have’ feature that somebody WILL b= uy and 10x units of work to produce ease of configuration that a lot of people MAY= buy guess which gets priority unless ‘ease of use’ is a core value = of the organization or it is forc= ed down their throats by customers.   I still know engineers who thi= nk the iPod is stupid because it is too simple and doesn’t have enough buttons or widgets.

 

Easy configuration is= a 'nice-to-have' for centralized systems, but it's a necessity for P2P systems."

 

All it takes is a good sales team to turn “ni= ce to have” into “RFP Mandatory”, especially when the “ni= ce to have” becomes “former OPEX budget gets used for my other CAPEX/OPEX stuff”.    Oracle’s entire sales stra= tegy is to pay for increased Oracle CAPEX/OPEX out of reduced telecom/noc CAPEX/OPEX.  The Oracle IT guys in a company hit the PBX guys with an = ugly club, take over their OPEX/CAPEX budget delivering the same capabilities, a= nd buy Oracle stuff with what’s left, which is exactly how Cisco has sold VOIP to the NOC for the past several years.  Both Oracle and Cisco salespeople are REALLY good at explaining how to get away with budget murde= r, and until recently each company seemed content at picking at the weaklings before turning on each other, as they’re both getting ready for a fig= ht with Big Redmond Bill.   The same battles apply even with little = fish down to the SME, but as you go down the food chain automation and ease of deployment become increasingly important as you can’t bury deployment costs in professional services.  When it comes down to it, the big bat= tle isn’t about technology but budget.

 

If you want a very diplomatically worded descriptio= n of OPEX Budget Murder the above please see my employer’s website for a customer case study or send me an email and I’ll give you a PDF copy.=

 

Regards

 

Michael

 

Michael Slavitch           &= nbsp; 

Lead, Technology Initiatives

slavitch@objectworld.com

 

 

 

 

 

 

-----Original Message-----
From: michael.slavitch@e2exchange.com [mailto:michael.slavitch@e2exchange.c= om] On Behalf Of Michael Slavitch
Sent: Wednesday, April 04, 2007 12:05 PM
To: Michael Slavitch
Subject: Fwd: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

---------- Forwarded message ----------<= /p>

FromDate: Apr 4, 2007 11:56 AM

Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

To: Brian Rosen <br@brianrosen.net>, Henry Sinnreich

<hsinnrei@adobe.com>, Michael Slavitch <slavitch@objectworld.com>,

Paul Kyzivat <pkyzivat@cisco.com>

Cc: David R Oran <oran@cisco.com>, P2PSIP Mailing List

<p2psip@ietf.org>, "Michael Hammer (mhammer)= " <mhammer@cisco.com>

 

 

One small example:  P2P systems are fault-tole= rant, so there's no need

to configure the addresses of the 'fail-over' serve= rs.

 

More to the general point, and this is just my opin= ion of course...I

think centralized systems could approach the ease of configuration

that is inherent in P2P systems, but in general they don't.

 

Easy configuration is a 'nice-to-have' for centrali= zed systems, but

it's a necessity for P2P systems.

 

Best Regards,

 

Eric.

 

----- Original Message -----

From: "Brian Rosen= " <br@brianrosen.net>

To: "'Eric Cooper<= /st1:PersonName>'" <eric_d_cooper@sympatico.ca>; "'Henry Sinnreich'"

<hsinnrei@adobe.com>; "'Michael Slavitch'" <slavitch@objectworld.com>;

"'Paul Kyzivat'" <pkyzivat@cisco.com>

Cc: "'David R Oran= '" <oran@cisco.com>; "'P2PSIP Mailing L= ist'"

<p2psip@ietf.org>; "'Michael Hammer (mhammer)'" <mhammer@cisco.com>

Sent: Wednesday, April 04, 2007 10:37 AM=

Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario

 

 

>> I know of a couple of major enterprise PBX vendors who offer 1 and 2 week-

>> long training courses so that their VARs c= an learn to install and

>> configure the PBX.  Having had the tr= aining, it will generally take an

>> hour or two of configuration before the PB= X gets to the point where two

>> extensions can call each other.=

>> 

>> On the other hand, there are P2P PBX syste= ms emerging that can be unboxed,

>> plugged in and start making calls in under= 2 minutes.  So I'd have to say

>> that P2P does have a lot to offer in this = area.

> With comparable fe= ature sets?

> 

> I know of IP PBXs that can be unboxed, plugged= in, and start making calls in

> maybe 10 minutes.  I'm not sure the diffe= rence between 2 and 10 is that

> significant.

> 

> What does p2p have, inherently, that makes it easier?  What makes the 2

> minutes work that, say, Asterisk doesn't have?=

> 

> I'll bet you its f= eatures.  If you have no features, everything is s= imple.

> If you support any fraction of the feature set in an IP PBX, you're where

> they are now.

> 

> I once made a small wager with someone that if= IP PBX vendors offered

> simpler systems at a lower price, they would m= ake much more money: the idea

> being that the complexity of the feature set had driven up the price of the

> systems so far that buyers would trade simplic= ity for price.  I thought if

> you gave them the "top 25" feature set, with roughly out-of-the-box<= /o:p>

> functionality, that nearly all enterprises wou= ld be satisfied.

> 

> He showed me a valid marketing study that show= ed, quite clearly, that I was

> wrong.  Users DEMANDED the features.  They simply wouldn't purchase systems

> that didn't have the features they wanted, and price wouldn't change their

> mind (at least in the range of reasonable price differences).

> 

> Now, I'm not so sure if you asked the actual U= SERS of these systems if they

> agreed.  But they don't make the purchase decisions.  The ones that do want

> features.

> 

> The guys that run the big IP PBX businesses ar= e not dumb.  They know their

> customers.  If there was money to be made= in 2 minute set up, they could

> provide that right now (you can find some out = there, do a web search).

> 

> But tell me anyways: what does p2p do that simplifies configuration for

> enterprise?

> 

> Brian

> 

 

_______________________________________________

P2PSIP mailing list

P2PSIP@ietf.org

https://www1.ietf.org/mailman/listinfo/p2psip

 

 

--

BEGIN-ANTISPAM-VOTING-LINKS

---------------------------------------------------= ---

 

Teach CanIt if this mail (ID 658457) is spam:<= /o:p>

Spam:        http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc54= 03d2&c=3Ds

Not spam:    http://canitpro-int.obj= ectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc5403d2&c=3Dn

Forget= vote: http://canitpro-int.objectworld.com/canit/b.php?i=3D658457&m=3D1cd3bc54= 03d2&c=3Df

---------------------------------------------------= ---

END-ANTISPAM-VOTING-LINKS

 

This transmission (including any attachm= ents) may contain confidential information, privileged material (including materi= al protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone ot= her than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete th= is information from your system. Use, dissemination, distribution, or reproduc= tion of this transmission by unintended recipients is not authorized and may be unlawful.

Any views, opinions and content presente= d in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_002_01C776E6.4A6DD54B-- ------_=_NextPart_001_01C776E6.4A6DD54B Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_001_01C776E6.4A6DD54B-- --===============1645077992== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1645077992==-- From p2psip-bounces@ietf.org Wed Apr 04 16:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBtC-000068-98; Wed, 04 Apr 2007 16:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBtA-00005d-HP for p2psip@ietf.org; Wed, 04 Apr 2007 16:15:28 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBt8-0006kQ-T8 for p2psip@ietf.org; Wed, 04 Apr 2007 16:15:28 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34KFIoi018437 for ; Wed, 4 Apr 2007 16:15:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 16:15:18 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90E9@photon.objectworld.com> In-Reply-To: <1fa601c776f5$564b0290$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVA= References: <4E2DC1ACE541B94A946B8D8657E372C57A90C2@photon.objectworld.com> <1fa601c776f5$564b0290$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Henry Sinnreich" , "P2PSIP Mailing List" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian: I agree with you entirely. The point is that a DHT approach eliminates the need for such exhausting server integration if cumulative presence and cumulative inputs from many disparate sources is implicit within a DHT. Regards Michael Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 4:11 PM To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? I was talking about using standards based presence systems to control how calls are routed. It's not really "call forwarding", it's "calls from this class of callers when I'm in such-and-such presence state are routed to that device". I'm not sure the end user would understand the difference, but the implementation is quite a bit different. We have standards that would cover the inter-box interfaces for such systems. I think that those standards would work for p2psip with zero to small changes. Was that what you were thinking Henry? Do you see any need for what Michael is talking about if it's not presence based routing? Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 11:47 AM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > " I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might." >=20 > It does. For example, I don't have call forward, I have on my personal > agent right now (a shameless plug for my employer, sorry) 'always call > forward for identities that I really don't want to talk to or refuse to > identify themselves, call forward when busy for most people, call forward > for even fewer people when DND, and even when I set my presence to DND > flash my call and interrupt me if it's a call from my kid's school, my > doctor, my wife, my boss, and a few people on this list, just not too > loud.' >=20 > This is done using client-server SIP server talking to another client- > server SIP server and perhaps sometimes a third SIP server from another > much larger vendor who doesn't care if they got things wrong along with a > fourth SIP server that's a message store from two vendors and a fifth SIP > server that might do 3rd party call control if our customers buy it, > (whew!), all exchanging messages in a complex energetic manner that makes > life harder for our developers than it has to be. >=20 > The underlying mechanisms are an order of magnitude more complex than they > have to be and I have proof that the amount of code needed if standard > techiques existed* to interact with 3rd parties from low-end endpoints to > big super-duper-supernodes** would be 1/10th the amount of code needed to > do the equivalent in the C/S world. A 1.5M code-line project becomes a > 150K code-line project, which as any person who has ever put together a > project plan knows carries enormous implications for probability of > failure and success, the kind of products that result, and the kind of > sales needed to justify them. >=20 > P2P enables long-tail economics in communications systems products in the > same way that you don't have to be a 3270 forms developer to develop web > content. Vendors that participate in long-tail environments such as eBay > are wise to develop on such a platform. There are others vendors, > including employers of people reading this message, that are beneficiaries > of long-tail markets. Including mine. >=20 > Regards >=20 > Michael >=20 > *Which is the only way to get people to bother as the pull in the C/S > direction is very hard. >=20 > **Which is really what a 'server' is, albeit with a much les silly name. >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 11:25 AM > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I REALLY wish I could transfer a call from Skype to my mobile and vice > versa. >=20 > I wish I could transfer it to my hardline when, for whatever reason, the > bandwidth gods are not smiling on me. >=20 > And then there is conferencing. Depending on exactly how conferencing is > implemented, you may need to transfer to a bridge. >=20 > I really think transfer is an absolute minimal requirement. >=20 > I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might. >=20 > Conferencing is something that just has to work. >=20 > We need to go down the list of service examples and decide which ones are > MUST HAVE. >=20 > Brian >=20 > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Wednesday, April 04, 2007 11:14 AM > > To: Brian Rosen; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > think? > > > > These are good points and actually should copied to the SIPPING list > > since they apply to the simple SIP Toolkit :-) > > > > Excellent items are these here: > > > > >3. All devices that support audio support wideband audio. > > > > >4. All devices support text (IM and real time interactive). > > > > >5. All devices support presence. We define a minimal set of presence > > >characteristics that all devices publish. > > > > I take exception here only to the legacy from the voice-only PBX: > > > > >6. We define a minimal feature set (something like unattended and > > >attended > > >transfer, call forward no answer, call forward busy, basic > > conferencing, > > >...) that every device supports the same way. > > > > Let's first look how presence and IM may affect user behavior and if > > this cannot be a special endpoint app, say for receptionists or agents. > > > > > This is pretty much what Skype does > > > > I am using Skype now for several years for most long distance calls and > > for conferences, but have never transferred a call. May be my secretary > > would transfer a call, but I don't have one :-) > > Nor do 99.99% of consumers or most employees any more. One can IM the > > number... > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 9:49 AM > > To: 'P2PSIP Mailing List' > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > think? > > > > One of the things I think we blew big time on sip was that we didn't > > require > > some fundamental things in every sip device to differentiate them from > > existing technology. We have an opportunity to fix that with p2psip, > > and I > > think we should do it. > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > > but > > it's a very real thing that we could do which I believe would be > > helpful. > > > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > > protocol > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > protocols are TCP only. The overlay defines what credentials are needed > > (and supplies them). > > > > 2. We do not support any form of insecure media. It's always encrypted. > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive). > > > > 5. All devices support presence. We define a minimal set of presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and > > attended > > transfer, call forward no answer, call forward busy, basic conferencing, > > ...) that every device supports the same way. > > > > 7. All devices work behind a given set of NAT configurations, given a > > specified set of ICE components (or whatever). > > > > 8. We define what constitutes a minimal configuration set; all of the > > above > > just work with this level of configuration (and credentials from an > > overlay). We of course define the configuration mechanism. I'm > > thinking > > that we do this by configuring the device with the credentials, and > > using > > the overlay to provide any other configuration (which could be > > influenced > > by, say, a website the overlay runs) automatically. > > > > All of these are designed to be minimum capabilities, but the idea is > > that > > ANY device, with credentials on an overlay, can expect to communicate > > with > > any other device on that overlay with ALL of the above. > > > > Finally, I propose we invent a phrase, something like "p2psip > > conformant" > > which means a device that does that. No protocol police, but the idea > > is > > that if you say you have a "p2psip conformant" device, it means all of > > the > > above. Perhaps we have a way to signal that. > > > > This is pretty much what Skype does. Why should we not do that, at > > least? > > > > Brian > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > -- >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:27:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC4y-0004NS-D8; Wed, 04 Apr 2007 16:27:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC4x-0004Mk-OK for p2psip@ietf.org; Wed, 04 Apr 2007 16:27:39 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZC4w-0007H1-9U for p2psip@ietf.org; Wed, 04 Apr 2007 16:27:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZC4S-0004WP-Nc; Wed, 04 Apr 2007 15:27:09 -0500 From: "Brian Rosen" To: "'Eric Cooper'" , "'Henry Sinnreich'" , "'Michael Slavitch'" , "'Paul Kyzivat'" Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 16:27:25 -0400 Message-ID: <1fac01c776f7$aaf26340$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <005d01c776d1$e0d6e290$65500a0a@ronin> Thread-Index: Acd20dlXcbhN3/73SHmSqI6aoAJljQAI7c5Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: 'David R Oran' , 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org That doesn't seem to get you a very big win. Telling on server the hostname of another for fault tolerant purposes is pretty simple. Of course, we don't know how bootstrapping is going to work, but most systems depend on configuring more than one bootstrap server address in every peer. Isn't that the same thing? Of course, this also depends on your definition of "fault tolerant". The one I am used to goes like this: - Calls already up stay up and terminate normally - Calls in the process of being set up may fail the set-up, but a retry must work. The user should not be aware the fault occurred. - The next call placed after the failure occurs (and the fact of the failure communicated) completes normally. There can be no critical windows where calls fail to complete. Now, to be sure, in commercial systems, there is one more: call detail records must always complete for every completed or attempted call. Hopefully, what we design will do that. This one puzzles me more than a little: > More to the general point, and this is just my opinion of course...I think > centralized systems could approach the ease of configuration that is > inherent in P2P systems, but in general they don't. Right, so you are agreeing with my basic premise. There is nothing inherent in p2p that makes configuration easier. You are hopeful that we won't repeat the mistakes we made in designing generic SIP based systems when we had the TDM systems to see what they did wrong. When we design p2psip systems, we'll know better. Yeah, right. Actually, what we will have to work with is the really complex SIP configuration framework. We'll have a standardized way to do something that really is inherently complex. That will help some, but not a lot, because, ah, configuration of telephony is inherently complex. We know that, we just would rather believe p2psip is the Great Simplifying Principle. Brian > -----Original Message----- > From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] > Sent: Wednesday, April 04, 2007 11:57 AM > To: Brian Rosen; 'Henry Sinnreich'; 'Michael Slavitch'; 'Paul Kyzivat' > Cc: 'David R Oran'; 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)' > Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > One small example: P2P systems are fault-tolerant, so there's no need to > configure the addresses of the 'fail-over' servers. > > More to the general point, and this is just my opinion of course...I think > centralized systems could approach the ease of configuration that is > inherent in P2P systems, but in general they don't. > > Easy configuration is a 'nice-to-have' for centralized systems, but it's a > necessity for P2P systems. > > Best Regards, > > Eric. > > ----- Original Message ----- > From: "Brian Rosen" > To: "'Eric Cooper'" ; "'Henry Sinnreich'" > ; "'Michael Slavitch'" ; > "'Paul Kyzivat'" > Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" > ; "'Michael Hammer (mhammer)'" > Sent: Wednesday, April 04, 2007 10:37 AM > Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > > >> I know of a couple of major enterprise PBX vendors who offer 1 and 2 > week- > >> long training courses so that their VARs can learn to install and > >> configure the PBX. Having had the training, it will generally take an > >> hour or two of configuration before the PBX gets to the point where two > >> extensions can call each other. > >> > >> On the other hand, there are P2P PBX systems emerging that can be > unboxed, > >> plugged in and start making calls in under 2 minutes. So I'd have to > say > >> that P2P does have a lot to offer in this area. > > With comparable feature sets? > > > > I know of IP PBXs that can be unboxed, plugged in, and start making > calls in > > maybe 10 minutes. I'm not sure the difference between 2 and 10 is that > > significant. > > > > What does p2p have, inherently, that makes it easier? What makes the 2 > > minutes work that, say, Asterisk doesn't have? > > > > I'll bet you its features. If you have no features, everything is > simple. > > If you support any fraction of the feature set in an IP PBX, you're > where > > they are now. > > > > I once made a small wager with someone that if IP PBX vendors offered > > simpler systems at a lower price, they would make much more money: the > idea > > being that the complexity of the feature set had driven up the price of > the > > systems so far that buyers would trade simplicity for price. I thought > if > > you gave them the "top 25" feature set, with roughly out-of-the-box > > functionality, that nearly all enterprises would be satisfied. > > > > He showed me a valid marketing study that showed, quite clearly, that I > was > > wrong. Users DEMANDED the features. They simply wouldn't purchase > systems > > that didn't have the features they wanted, and price wouldn't change > their > > mind (at least in the range of reasonable price differences). > > > > Now, I'm not so sure if you asked the actual USERS of these systems if > they > > agreed. But they don't make the purchase decisions. The ones that do > want > > features. > > > > The guys that run the big IP PBX businesses are not dumb. They know > their > > customers. If there was money to be made in 2 minute set up, they could > > provide that right now (you can find some out there, do a web search). > > > > But tell me anyways: what does p2p do that simplifies configuration for > > enterprise? > > > > Brian > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC50-0004P8-Kh; Wed, 04 Apr 2007 16:27:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC4z-0004Od-Cd for p2psip@ietf.org; Wed, 04 Apr 2007 16:27:41 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZC4x-0007H1-OS for p2psip@ietf.org; Wed, 04 Apr 2007 16:27:41 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZBoH-0001fM-3M; Wed, 04 Apr 2007 15:10:29 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Henry Sinnreich'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 16:10:42 -0400 Message-ID: <1fa601c776f5$564b0290$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90C2@photon.objectworld.com> Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I was talking about using standards based presence systems to control how calls are routed. It's not really "call forwarding", it's "calls from this class of callers when I'm in such-and-such presence state are routed to that device". I'm not sure the end user would understand the difference, but the implementation is quite a bit different. We have standards that would cover the inter-box interfaces for such systems. I think that those standards would work for p2psip with zero to small changes. Was that what you were thinking Henry? Do you see any need for what Michael is talking about if it's not presence based routing? Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 11:47 AM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > " I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might." > > It does. For example, I don't have call forward, I have on my personal > agent right now (a shameless plug for my employer, sorry) 'always call > forward for identities that I really don't want to talk to or refuse to > identify themselves, call forward when busy for most people, call forward > for even fewer people when DND, and even when I set my presence to DND > flash my call and interrupt me if it's a call from my kid's school, my > doctor, my wife, my boss, and a few people on this list, just not too > loud.' > > This is done using client-server SIP server talking to another client- > server SIP server and perhaps sometimes a third SIP server from another > much larger vendor who doesn't care if they got things wrong along with a > fourth SIP server that's a message store from two vendors and a fifth SIP > server that might do 3rd party call control if our customers buy it, > (whew!), all exchanging messages in a complex energetic manner that makes > life harder for our developers than it has to be. > > The underlying mechanisms are an order of magnitude more complex than they > have to be and I have proof that the amount of code needed if standard > techiques existed* to interact with 3rd parties from low-end endpoints to > big super-duper-supernodes** would be 1/10th the amount of code needed to > do the equivalent in the C/S world. A 1.5M code-line project becomes a > 150K code-line project, which as any person who has ever put together a > project plan knows carries enormous implications for probability of > failure and success, the kind of products that result, and the kind of > sales needed to justify them. > > P2P enables long-tail economics in communications systems products in the > same way that you don't have to be a 3270 forms developer to develop web > content. Vendors that participate in long-tail environments such as eBay > are wise to develop on such a platform. There are others vendors, > including employers of people reading this message, that are beneficiaries > of long-tail markets. Including mine. > > Regards > > Michael > > *Which is the only way to get people to bother as the pull in the C/S > direction is very hard. > > **Which is really what a 'server' is, albeit with a much les silly name. > > > > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com > > > > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 11:25 AM > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > I REALLY wish I could transfer a call from Skype to my mobile and vice > versa. > > I wish I could transfer it to my hardline when, for whatever reason, the > bandwidth gods are not smiling on me. > > And then there is conferencing. Depending on exactly how conferencing is > implemented, you may need to transfer to a bridge. > > I really think transfer is an absolute minimal requirement. > > I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might. > > Conferencing is something that just has to work. > > We need to go down the list of service examples and decide which ones are > MUST HAVE. > > Brian > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Wednesday, April 04, 2007 11:14 AM > > To: Brian Rosen; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > think? > > > > These are good points and actually should copied to the SIPPING list > > since they apply to the simple SIP Toolkit :-) > > > > Excellent items are these here: > > > > >3. All devices that support audio support wideband audio. > > > > >4. All devices support text (IM and real time interactive). > > > > >5. All devices support presence. We define a minimal set of presence > > >characteristics that all devices publish. > > > > I take exception here only to the legacy from the voice-only PBX: > > > > >6. We define a minimal feature set (something like unattended and > > >attended > > >transfer, call forward no answer, call forward busy, basic > > conferencing, > > >...) that every device supports the same way. > > > > Let's first look how presence and IM may affect user behavior and if > > this cannot be a special endpoint app, say for receptionists or agents. > > > > > This is pretty much what Skype does > > > > I am using Skype now for several years for most long distance calls and > > for conferences, but have never transferred a call. May be my secretary > > would transfer a call, but I don't have one :-) > > Nor do 99.99% of consumers or most employees any more. One can IM the > > number... > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 9:49 AM > > To: 'P2PSIP Mailing List' > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > think? > > > > One of the things I think we blew big time on sip was that we didn't > > require > > some fundamental things in every sip device to differentiate them from > > existing technology. We have an opportunity to fix that with p2psip, > > and I > > think we should do it. > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > > but > > it's a very real thing that we could do which I believe would be > > helpful. > > > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > > protocol > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > protocols are TCP only. The overlay defines what credentials are needed > > (and supplies them). > > > > 2. We do not support any form of insecure media. It's always encrypted. > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive). > > > > 5. All devices support presence. We define a minimal set of presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and > > attended > > transfer, call forward no answer, call forward busy, basic conferencing, > > ...) that every device supports the same way. > > > > 7. All devices work behind a given set of NAT configurations, given a > > specified set of ICE components (or whatever). > > > > 8. We define what constitutes a minimal configuration set; all of the > > above > > just work with this level of configuration (and credentials from an > > overlay). We of course define the configuration mechanism. I'm > > thinking > > that we do this by configuring the device with the credentials, and > > using > > the overlay to provide any other configuration (which could be > > influenced > > by, say, a website the overlay runs) automatically. > > > > All of these are designed to be minimum capabilities, but the idea is > > that > > ANY device, with credentials on an overlay, can expect to communicate > > with > > any other device on that overlay with ALL of the above. > > > > Finally, I propose we invent a phrase, something like "p2psip > > conformant" > > which means a device that does that. No protocol police, but the idea > > is > > that if you say you have a "p2psip conformant" device, it means all of > > the > > above. Perhaps we have a way to signal that. > > > > This is pretty much what Skype does. Why should we not do that, at > > least? > > > > Brian > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > -- > > > ----------------------------------------------- > > > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > > > > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC52-0004Qu-0t; Wed, 04 Apr 2007 16:27:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC50-0004PQ-NH for p2psip@ietf.org; Wed, 04 Apr 2007 16:27:42 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZC4z-0007H1-Co for p2psip@ietf.org; Wed, 04 Apr 2007 16:27:42 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZBeJ-0007q6-Bx; Wed, 04 Apr 2007 15:00:07 -0500 From: "Brian Rosen" To: "'Bruce Lowekamp'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 16:00:24 -0400 Message-ID: <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> Thread-Index: Acd20AVy9ET+QupTSqiYGjOrN30/HAAIshIw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > protocol > > to reject attempts to signal without TLS (or whatever). I'm assuming > the > > protocols are TCP only. The overlay defines what credentials are needed > > (and supplies them). > > > > Requiring securing the protocol seems like a good goal. We need to > have a scheme that secures ad-hoc networks and one that works with > NATs, so TLS over TCP certainly can't be our only option. Why not? What is inherent in ad-hoc networks that would preclude TLS over TCP? What is hard about doing TLS over TCP in the presence of NAT? > > 2. We do not support any form of insecure media. It's always encrypted. > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive). > > > > 5. All devices support presence. We define a minimal set of presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and > attended > > transfer, call forward no answer, call forward busy, basic conferencing, > > ...) that every device supports the same way. > > All of these assume a particular type of device that I don't think we > can (or should) assume for P2PSIP. Where we get into the particular > calling features for telephony devices, hopefully we can just point at > BLISS. As with Henry, I agree that p2psip may be used with devices that aren't traditional telephone-like devices. We can use a term when we want to say how devices that purport to be telephony like devices work, without constraining interactive gaming devices. > > > > > 7. All devices work behind a given set of NAT configurations, given a > > specified set of ICE components (or whatever). > > agreed, although defining the exact configurations that we can support > is quite difficult. I'm not sure I'm following this. It does seem relatively easy to specify the characteristics of the most common NATs encountered in the wild and use that to define a solution that works with those. I agree that defining, for a given solution, which NATs work is hard. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:28:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC67-00059X-6H; Wed, 04 Apr 2007 16:28:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC65-00059A-RU for p2psip@ietf.org; Wed, 04 Apr 2007 16:28:49 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZC64-0007V6-Gl for p2psip@ietf.org; Wed, 04 Apr 2007 16:28:49 -0400 Received: by py-out-1112.google.com with SMTP id f31so110103pyh for ; Wed, 04 Apr 2007 13:28:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=PsiMVQctfMNouBhFXMBB2cVyLooiaPeOjP02w1R7F5riqgVV7yTS8tSu7SmwfmaG/L96YNm2+BnlLURqr4mnLz31zYz7C29CRGXRJTRscchOPDm+U9FF4gNn8qnkdefNUHtFAhk8sWl0IIhAWg/LyjlJMKlXm8oBVtASE16Uj/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=S7fAJZBl6eK70PrTl7XQPr51E4UprcoOS84W2QOM52PW6Og/IVGFU2HUWYbI9bWQBzdzb3TV3idpIbeS0hb5AxllTWRtArxLEEqdd+dZv1bYBkF7IXS6ENCZMnWktsEU0ENPxtGGV1sg2PObWTw4BjvREXiPDk3nPW2ktJcYLZU= Received: by 10.35.21.9 with SMTP id y9mr1788033pyi.1175718525314; Wed, 04 Apr 2007 13:28:45 -0700 (PDT) Received: by 10.35.107.10 with HTTP; Wed, 4 Apr 2007 13:28:45 -0700 (PDT) Message-ID: <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> Date: Wed, 4 Apr 2007 16:28:45 -0400 From: "Bruce Lowekamp" To: "Brian Rosen" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? In-Reply-To: <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> X-Google-Sender-Auth: cb345255d05814a2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 4/4/07, Brian Rosen wrote: > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > > protocols are TCP only. The overlay defines what credentials are needed > > > (and supplies them). > > > > > > > Requiring securing the protocol seems like a good goal. We need to > > have a scheme that secures ad-hoc networks and one that works with > > NATs, so TLS over TCP certainly can't be our only option. > > Why not? What is inherent in ad-hoc networks that would preclude TLS over > TCP? What is hard about doing TLS over TCP in the presence of NAT? > I'm not an expert on all the options, but my understanding of TLS is that a basic assumption is that each end has a certificate from a trusted CA that binds it to a domain name. In an ad hoc environment, you lack a stable domain name and a shared trusted CA that has preallocated a certificate, so you can't possibly use TLS. As far as TCP over NAT, not all NATs support TCP simultaneous open. There are many NATs where you will not be able to establish a TCP connection where you could a UDP connection. (And there are some where you can establish a TCP but not a UDP connection, although I think there are fewer of these.) > > > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > agreed, although defining the exact configurations that we can support > > is quite difficult. > I'm not sure I'm following this. It does seem relatively easy to specify > the characteristics of the most common NATs encountered in the wild and use > that to define a solution that works with those. I agree that defining, for > a given solution, which NATs work is hard. We can define which NATs will work with a given traversal technique. (more precisely, which behavior characteristics are needed.) For example, we can easily produce a protocol that works when peers are behind 4787-compliant NATs (after initial join) with endpoint-independent filtering. The problem is that it's possible to do much better than that, depending on how much work you're willing to do and how many of your peers are behind "evil" NATs. A little bit of work gets you to work with NATs that are 4787-compliant without endpoint-independent filtering, and a bit more will let you probabilistically work with most pairs of NATs without relaying. I can imagine that some overlays are going to be willing to invest more work to get each of their members connected than other overlays. I guess what I'm saying is: - I agree with you that we can specify a protocol that will work with peers behind NATs that meet certain characteristics. - What we would probably specify is based on 4787, and NATs that meet all of those characteristics are not now very common (they certainly aren't the majority). - We need to have a protocol that can work with a wider variety of NATs, but it's hard to make guarantees of exactly what combinations of NATs will succeed and what won't. Also, because there is no way to determine exactly what type of NAT you're behind, there is fundamentally no way of being sure whether your peer is behind a "compliant" NAT, so it's impossible to avoid the problem of best-effort NAT workarounds with some sort of ability to withdraw as a peer and become a client as a fallback. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC7G-0005Zj-Rg; Wed, 04 Apr 2007 16:30:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC7G-0005Z1-2M for p2psip@ietf.org; Wed, 04 Apr 2007 16:30:02 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZC7E-0007jV-LY for p2psip@ietf.org; Wed, 04 Apr 2007 16:30:01 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34KTqbs018771 for ; Wed, 4 Apr 2007 16:29:52 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 16:29:51 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com> In-Reply-To: <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd20AVy9ET+QupTSqiYGjOrN30/HAAIshIwAAFGyGA= References: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Bruce Lowekamp" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I am not sure why Datagram TLS is not an option given the benefits involve= d. Regards=20 Michael Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 4:00 PM To: 'Bruce Lowekamp' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > protocol > > to reject attempts to signal without TLS (or whatever). I'm assuming > the > > protocols are TCP only. The overlay defines what credentials are needed > > (and supplies them). > > >=20 > Requiring securing the protocol seems like a good goal. We need to > have a scheme that secures ad-hoc networks and one that works with > NATs, so TLS over TCP certainly can't be our only option. Why not? What is inherent in ad-hoc networks that would preclude TLS over TCP? What is hard about doing TLS over TCP in the presence of NAT? =20 > > 2. We do not support any form of insecure media. It's always encrypted. > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive). > > > > 5. All devices support presence. We define a minimal set of presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and > attended > > transfer, call forward no answer, call forward busy, basic conferencing, > > ...) that every device supports the same way. >=20 > All of these assume a particular type of device that I don't think we > can (or should) assume for P2PSIP. Where we get into the particular > calling features for telephony devices, hopefully we can just point at > BLISS. As with Henry, I agree that p2psip may be used with devices that aren't traditional telephone-like devices. We can use a term when we want to say how devices that purport to be telephony like devices work, without constraining interactive gaming devices. >=20 > > > > 7. All devices work behind a given set of NAT configurations, given a > > specified set of ICE components (or whatever). >=20 > agreed, although defining the exact configurations that we can support > is quite difficult. I'm not sure I'm following this. It does seem relatively easy to specify the characteristics of the most common NATs encountered in the wild and use that to define a solution that works with those. I agree that defining, for a given solution, which NATs work is hard. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:33:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCB1-0007Bs-J5; Wed, 04 Apr 2007 16:33:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCB0-0007BU-7W for p2psip@ietf.org; Wed, 04 Apr 2007 16:33:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZCAy-0008Kj-F9 for p2psip@ietf.org; Wed, 04 Apr 2007 16:33:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZCAc-0007On-VS; Wed, 04 Apr 2007 15:33:31 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Henry Sinnreich'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 16:33:48 -0400 Message-ID: <1fad01c776f8$8e509080$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90E9@photon.objectworld.com> Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVAAAJR+wA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ahh, common ground. I do think we need to consider what the box roles are in p2psip in relation to presence. What element is the "presence server"? That element routes calls to multiple devices. Nice, but what element in p2psip does that kind of routing? And, you are implying another layer of identifier. Normally, when we talk about p2psip identifiers, we are assuming some form of AoR. That is the address someone else uses to address communication to a peer. But what if you have multiple devices that join the overlay for the same AoR? Certainly allowed, but what is the unique address for such devices? Who gets the call to the AoR and chooses the device? However, if every peer MUST publish presence state, and every peer MUST have a presence client, we are getting somewhere you and I both want to get to. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:15 PM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > Brian: I agree with you entirely. The point is that a DHT approach > eliminates the need for such exhausting server integration if cumulative > presence and cumulative inputs from many disparate sources is implicit > within a DHT. > > Regards > > Michael > > > Lead, Technology Initiatives > slavitch@objectworld.com > > > > > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:11 PM > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > I was talking about using standards based presence systems to control > how > calls are routed. It's not really "call forwarding", it's "calls from > this > class of callers when I'm in such-and-such presence state are routed to > that > device". I'm not sure the end user would understand the difference, but > the > implementation is quite a bit different. We have standards that would > cover > the inter-box interfaces for such systems. I think that those standards > would work for p2psip with zero to small changes. > > Was that what you were thinking Henry? Do you see any need for what > Michael > is talking about if it's not presence based routing? > > Brian > > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 11:47 AM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > " I do think that a rich presence system might obviate the Call > forward > > issues. I've never seen it done, so I've never been able to try, but > I > > could see how it might." > > > > It does. For example, I don't have call forward, I have on my > personal > > agent right now (a shameless plug for my employer, sorry) 'always call > > forward for identities that I really don't want to talk to or refuse > to > > identify themselves, call forward when busy for most people, call > forward > > for even fewer people when DND, and even when I set my presence to DND > > flash my call and interrupt me if it's a call from my kid's school, my > > doctor, my wife, my boss, and a few people on this list, just not too > > loud.' > > > > This is done using client-server SIP server talking to another client- > > server SIP server and perhaps sometimes a third SIP server from > another > > much larger vendor who doesn't care if they got things wrong along > with a > > fourth SIP server that's a message store from two vendors and a fifth > SIP > > server that might do 3rd party call control if our customers buy it, > > (whew!), all exchanging messages in a complex energetic manner that > makes > > life harder for our developers than it has to be. > > > > The underlying mechanisms are an order of magnitude more complex than > they > > have to be and I have proof that the amount of code needed if standard > > techiques existed* to interact with 3rd parties from low-end endpoints > to > > big super-duper-supernodes** would be 1/10th the amount of code needed > to > > do the equivalent in the C/S world. A 1.5M code-line project becomes > a > > 150K code-line project, which as any person who has ever put together > a > > project plan knows carries enormous implications for probability of > > failure and success, the kind of products that result, and the kind of > > sales needed to justify them. > > > > P2P enables long-tail economics in communications systems products in > the > > same way that you don't have to be a 3270 forms developer to develop > web > > content. Vendors that participate in long-tail environments such as > eBay > > are wise to develop on such a platform. There are others vendors, > > including employers of people reading this message, that are > beneficiaries > > of long-tail markets. Including mine. > > > > Regards > > > > Michael > > > > *Which is the only way to get people to bother as the pull in the C/S > > direction is very hard. > > > > **Which is really what a 'server' is, albeit with a much les silly > name. > > > > > > > > Michael Slavitch > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 11:25 AM > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > versa. > > > > I wish I could transfer it to my hardline when, for whatever reason, > the > > bandwidth gods are not smiling on me. > > > > And then there is conferencing. Depending on exactly how conferencing > is > > implemented, you may need to transfer to a bridge. > > > > I really think transfer is an absolute minimal requirement. > > > > I do think that a rich presence system might obviate the Call forward > > issues. I've never seen it done, so I've never been able to try, but > I > > could see how it might. > > > > Conferencing is something that just has to work. > > > > We need to go down the list of service examples and decide which ones > are > > MUST HAVE. > > > > Brian > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > To: Brian Rosen; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > "consumers" > > to > > > think? > > > > > > These are good points and actually should copied to the SIPPING list > > > since they apply to the simple SIP Toolkit :-) > > > > > > Excellent items are these here: > > > > > > >3. All devices that support audio support wideband audio. > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > >5. All devices support presence. We define a minimal set of > presence > > > >characteristics that all devices publish. > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > >6. We define a minimal feature set (something like unattended and > > > >attended > > > >transfer, call forward no answer, call forward busy, basic > > > conferencing, > > > >...) that every device supports the same way. > > > > > > Let's first look how presence and IM may affect user behavior and if > > > this cannot be a special endpoint app, say for receptionists or > agents. > > > > > > > This is pretty much what Skype does > > > > > > I am using Skype now for several years for most long distance calls > and > > > for conferences, but have never transferred a call. May be my > secretary > > > would transfer a call, but I don't have one :-) > > > Nor do 99.99% of consumers or most employees any more. One can IM > the > > > number... > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > To: 'P2PSIP Mailing List' > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > > think? > > > > > > One of the things I think we blew big time on sip was that we didn't > > > require > > > some fundamental things in every sip device to differentiate them > from > > > existing technology. We have an opportunity to fix that with > p2psip, > > > and I > > > think we should do it. > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > > > but > > > it's a very real thing that we could do which I believe would be > > > helpful. > > > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm > assuming > > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of > presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > > > 7. All devices work behind a given set of NAT configurations, given > a > > > specified set of ICE components (or whatever). > > > > > > 8. We define what constitutes a minimal configuration set; all of > the > > > above > > > just work with this level of configuration (and credentials from an > > > overlay). We of course define the configuration mechanism. I'm > > > thinking > > > that we do this by configuring the device with the credentials, and > > > using > > > the overlay to provide any other configuration (which could be > > > influenced > > > by, say, a website the overlay runs) automatically. > > > > > > All of these are designed to be minimum capabilities, but the idea > is > > > that > > > ANY device, with credentials on an overlay, can expect to > communicate > > > with > > > any other device on that overlay with ALL of the above. > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > conformant" > > > which means a device that does that. No protocol police, but the > idea > > > is > > > that if you say you have a "p2psip conformant" device, it means all > of > > > the > > > above. Perhaps we have a way to signal that. > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > least? > > > > > > Brian > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information > from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld > Communications > > Corp. > > > ----------------------------------------------- > > > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > > > > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:45:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCLn-0005Do-CF; Wed, 04 Apr 2007 16:45:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCLm-0004dL-2A for p2psip@ietf.org; Wed, 04 Apr 2007 16:45:02 -0400 Received: from node06.dns-hosting.info ([83.149.75.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZCLb-0001ZI-Uf for p2psip@ietf.org; Wed, 04 Apr 2007 16:44:53 -0400 Received: from mit.xs4all.nl ([213.84.95.205]:53705 helo=[192.168.0.32]) by node06.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HZCLV-0004Yu-LZ; Wed, 04 Apr 2007 22:44:46 +0200 In-Reply-To: <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> References: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <17789D79-13FA-45EA-9B21-A8F8A535647C@ag-projects.com> Content-Transfer-Encoding: 7bit From: Adrian Georgescu Date: Wed, 4 Apr 2007 22:44:35 +0200 To: Bruce Lowekamp X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 213.84.95.205 X-SA-Exim-Mail-From: ag@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on node06.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? X-SA-Exim-Version: 4.2.1 (built Sun, 03 Dec 2006 00:39:09 +0000) X-SA-Exim-Scanned: Yes (on node06.dns-hosting.info) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> > Requiring securing the protocol seems like a good goal. We need to >> > have a scheme that secures ad-hoc networks and one that works with >> > NATs, so TLS over TCP certainly can't be our only option. >> >> Why not? What is inherent in ad-hoc networks that would preclude >> TLS over >> TCP? What is hard about doing TLS over TCP in the presence of NAT? >> > > I'm not an expert on all the options, but my understanding of TLS is > that a basic assumption is that each end has a certificate from a > trusted CA that binds it to a domain name. In an ad hoc environment, > you lack a stable domain name and a shared trusted CA that has > preallocated a certificate, so you can't possibly use TLS. A certificate is bound to any "common name", it does not have to be an Internet domain name. It could be Peer id, SIP URI or whatever you need to check against. TLS works just fine in disconnected environments as it does over public Internet. Adrian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCR6-0005Vl-VV; Wed, 04 Apr 2007 16:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCR5-0005Vg-TQ for p2psip@ietf.org; Wed, 04 Apr 2007 16:50:31 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCR3-0000Fh-Jh for p2psip@ietf.org; Wed, 04 Apr 2007 16:50:31 -0400 Received: by wr-out-0506.google.com with SMTP id 71so247063wri for ; Wed, 04 Apr 2007 13:50:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iZZ8whFdNAOdS/2tE1Jl+CEMjGvpPrx1ef6nQNH0jphBrlRG8knRd6J3sPgoLyc3bQentCP5BtORaHGk3V+deemKtIJjJ9DkDEB1Noe+8XhCdfKPIeD6vi0j0+aOaLBJKBx9uri3RILeNlmhi00dzfPdcauJ3WKB6FBmYvYNx4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=L4oW2p+i1vtNV/YFoQBP54/n3cGtwz0iyG1tuNJ+4aXoobAYshw1qRT+st/nhmP6Lk9EubqgEkd4QYVfl90AtdMB+CzzR5L9GnitrQwEDsvmlqKh572kh+AIX1EFSY4ZORW3RcFC3mUDWXRMDF2JQTAChj/GBQ6gRluIj/8k5rM= Received: by 10.114.14.1 with SMTP id 1mr427665wan.1175719828606; Wed, 04 Apr 2007 13:50:28 -0700 (PDT) Received: by 10.114.197.10 with HTTP; Wed, 4 Apr 2007 13:50:28 -0700 (PDT) Message-ID: <9dc4a1670704041350u10749155h96261ecfc0e9f247@mail.gmail.com> Date: Wed, 4 Apr 2007 16:50:28 -0400 From: EdPimentl To: "P2PSIP Mailing List" Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario In-Reply-To: <9dc4a1670704041349i1299e518sbe5f44de1d6d9a15@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005d01c776d1$e0d6e290$65500a0a@ronin> <1fac01c776f7$aaf26340$81238182@cis.neustar.com> <9dc4a1670704041349i1299e518sbe5f44de1d6d9a15@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Though it is true that Telecom Service is complex... (We are no longer tie to Tirks and WaffC) It does not have to be. Back in 1999 we fully automated OSS/BSS, and fully automated Pre-Ordering, Order Entry, Order Order Decomposioning, Order Management, Order WorkFlow, Jeopardies, FCAPS, Network Provisioning, Service Provisioning, Service Assurance, Billing and Customer Care. Later, we were the first company that tie OSSj to a XML WebServices SOA platform. using BPEL and ESB.. Much of what is being intimated here is part of OSS/BSS which can be expose as Webservices API into a robust commercial P2P Overlay and does not need to be built in into the Overlay. I would be glad to socialized this outside of this mailing list and then contribute the finding as a draft or a document for others to comment. Also there will be many cases where the above will be overkill and will be like lighting a cigarette with a torch. My .02 cents -E On 4/4/07, Brian Rosen wrote: > That doesn't seem to get you a very big win. Telling on server the hostname > of another for fault tolerant purposes is pretty simple. > > Of course, we don't know how bootstrapping is going to work, but most > systems depend on configuring more than one bootstrap server address in > every peer. Isn't that the same thing? > > Of course, this also depends on your definition of "fault tolerant". -- Thanks in advance and best regards, Ed Pimentel AgileCO Founder Mail: edpimentl[at]gmail.com sip: sip:2150112@truphone.com IM: edpimentl [AOL | Jabber | Yahoo | MSN ] Voip: edpimentl [SKype | GoogleTalk ] Mobile Content Marketing/Management/Digital Delivery http://mobilecentral.ws Mobile ( Relevant, Ambient, Location ) based Social Network http://TagR.mobi (Alpha) Mobile Payment - P2P Payment http://agilepay.ws Sponsor of P2PSIP open source [viasip_ng] project Creating a standards base P2PSIP dSIP infrastructure https://sourceforge.net/projects/viasip/ Mailing List viasip_ng@freelists.org _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCV4-0007Fc-FP; Wed, 04 Apr 2007 16:54:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCV3-0007EW-4K for p2psip@ietf.org; Wed, 04 Apr 2007 16:54:37 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCV1-0001L1-N8 for p2psip@ietf.org; Wed, 04 Apr 2007 16:54:37 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34KsQBW019184 for ; Wed, 4 Apr 2007 16:54:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 16:54:26 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90EC@photon.objectworld.com> In-Reply-To: <1fad01c776f8$8e509080$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVAAAJR+wAAAO/uw References: <4E2DC1ACE541B94A946B8D8657E372C57A90E9@photon.objectworld.com> <1fad01c776f8$8e509080$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Henry Sinnreich" , "P2PSIP Mailing List" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9aa22b77adc37e7d33e29644e4dc0b33 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I believe that good specs use MUST as much as possible and MAY only at gunp= oint, and even then only if the shooter is a good shot, so yes common groun= d. Given the sieve nature of a DHT presence data does not create a flood of da= ta, a DHT itself contains the presence database, each node contains only th= e data it needs, and with one writer per AOR and many readers publishing pr= esence is low-complexity DB stuff. Having multiple instances of the same A= OR is multi-writer multi-reader which is more complicated. 'Presense' in = that case is the cumulative set of presence for the set of AOR's for a sing= le higher-level identity, ie a person. My workplace may not want to know = the cumulative presence of my cottage PC, my home PC, my handheld along w= ith my work devices, but my kid might, and so might E911 for that matter. However this begs the question: How do you aggregate a set of AOR's for a = single abstract entity, ie me? Is this set of AOR's another nested DHT, a = DHT(me)? Might a nested recursive DHT that contains the cumulative set of objects de= fined for a higher-level object (an organization or a person) be the best w= ay to aggregate AOR's and hence presence? This would be an elegant way to = get the status for nested hierarchies. Here is what I mean: A DHT contains all the AOR's of Org.=20 A DHT within this DHT contains all the AOR's of Org.Marketing. A DHT within this DHT contains all the AOR's of Org.Marketing.Phil Phil's DHT contains all the objects of Phil.Home, Phil.Mobile, and Phil.= Work Or it could be just one AOR, for a P2P endpoint on Phil's cellphone. This concept scales very well. Each DHT itself has attributes including = cumulative presence, which is calculated by the members of the DHT based on= internal black box rules, and is arbitrary enough to be flexible without f= orgetting some basic rules regarding AOR.=20=20 Does this make sense, shouldn't we be using the recursive nature of DHT to= do this? Regards Michael Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 4:34 PM To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? Ahh, common ground. I do think we need to consider what the box roles are in p2psip in relation to presence. What element is the "presence server"? That element routes calls to multiple devices. Nice, but what element in p2psip does that kind of routing? And, you are implying another layer of identifier. Normally, when we talk about p2psip identifiers, we are assuming some form of AoR. That is the address someone else uses to address communication to a peer. But what if you have multiple devices that join the overlay for the same AoR? Certainly allowed, but what is the unique address for such devices? Who gets the call to the AoR and chooses the device? However, if every peer MUST publish presence state, and every peer MUST have a presence client, we are getting somewhere you and I both want to get to. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:15 PM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > Brian: I agree with you entirely. The point is that a DHT approach > eliminates the need for such exhausting server integration if cumulative > presence and cumulative inputs from many disparate sources is implicit > within a DHT. >=20 > Regards >=20 > Michael >=20 >=20 > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:11 PM > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I was talking about using standards based presence systems to control > how > calls are routed. It's not really "call forwarding", it's "calls from > this > class of callers when I'm in such-and-such presence state are routed to > that > device". I'm not sure the end user would understand the difference, but > the > implementation is quite a bit different. We have standards that would > cover > the inter-box interfaces for such systems. I think that those standards > would work for p2psip with zero to small changes. >=20 > Was that what you were thinking Henry? Do you see any need for what > Michael > is talking about if it's not presence based routing? >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 11:47 AM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > " I do think that a rich presence system might obviate the Call > forward > > issues. I've never seen it done, so I've never been able to try, but > I > > could see how it might." > > > > It does. For example, I don't have call forward, I have on my > personal > > agent right now (a shameless plug for my employer, sorry) 'always call > > forward for identities that I really don't want to talk to or refuse > to > > identify themselves, call forward when busy for most people, call > forward > > for even fewer people when DND, and even when I set my presence to DND > > flash my call and interrupt me if it's a call from my kid's school, my > > doctor, my wife, my boss, and a few people on this list, just not too > > loud.' > > > > This is done using client-server SIP server talking to another client- > > server SIP server and perhaps sometimes a third SIP server from > another > > much larger vendor who doesn't care if they got things wrong along > with a > > fourth SIP server that's a message store from two vendors and a fifth > SIP > > server that might do 3rd party call control if our customers buy it, > > (whew!), all exchanging messages in a complex energetic manner that > makes > > life harder for our developers than it has to be. > > > > The underlying mechanisms are an order of magnitude more complex than > they > > have to be and I have proof that the amount of code needed if standard > > techiques existed* to interact with 3rd parties from low-end endpoints > to > > big super-duper-supernodes** would be 1/10th the amount of code needed > to > > do the equivalent in the C/S world. A 1.5M code-line project becomes > a > > 150K code-line project, which as any person who has ever put together > a > > project plan knows carries enormous implications for probability of > > failure and success, the kind of products that result, and the kind of > > sales needed to justify them. > > > > P2P enables long-tail economics in communications systems products in > the > > same way that you don't have to be a 3270 forms developer to develop > web > > content. Vendors that participate in long-tail environments such as > eBay > > are wise to develop on such a platform. There are others vendors, > > including employers of people reading this message, that are > beneficiaries > > of long-tail markets. Including mine. > > > > Regards > > > > Michael > > > > *Which is the only way to get people to bother as the pull in the C/S > > direction is very hard. > > > > **Which is really what a 'server' is, albeit with a much les silly > name. > > > > > > > > Michael Slavitch > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 11:25 AM > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > versa. > > > > I wish I could transfer it to my hardline when, for whatever reason, > the > > bandwidth gods are not smiling on me. > > > > And then there is conferencing. Depending on exactly how conferencing > is > > implemented, you may need to transfer to a bridge. > > > > I really think transfer is an absolute minimal requirement. > > > > I do think that a rich presence system might obviate the Call forward > > issues. I've never seen it done, so I've never been able to try, but > I > > could see how it might. > > > > Conferencing is something that just has to work. > > > > We need to go down the list of service examples and decide which ones > are > > MUST HAVE. > > > > Brian > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > To: Brian Rosen; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > "consumers" > > to > > > think? > > > > > > These are good points and actually should copied to the SIPPING list > > > since they apply to the simple SIP Toolkit :-) > > > > > > Excellent items are these here: > > > > > > >3. All devices that support audio support wideband audio. > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > >5. All devices support presence. We define a minimal set of > presence > > > >characteristics that all devices publish. > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > >6. We define a minimal feature set (something like unattended and > > > >attended > > > >transfer, call forward no answer, call forward busy, basic > > > conferencing, > > > >...) that every device supports the same way. > > > > > > Let's first look how presence and IM may affect user behavior and if > > > this cannot be a special endpoint app, say for receptionists or > agents. > > > > > > > This is pretty much what Skype does > > > > > > I am using Skype now for several years for most long distance calls > and > > > for conferences, but have never transferred a call. May be my > secretary > > > would transfer a call, but I don't have one :-) > > > Nor do 99.99% of consumers or most employees any more. One can IM > the > > > number... > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > To: 'P2PSIP Mailing List' > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > > think? > > > > > > One of the things I think we blew big time on sip was that we didn't > > > require > > > some fundamental things in every sip device to differentiate them > from > > > existing technology. We have an opportunity to fix that with > p2psip, > > > and I > > > think we should do it. > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > > > but > > > it's a very real thing that we could do which I believe would be > > > helpful. > > > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm > assuming > > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of > presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > > > 7. All devices work behind a given set of NAT configurations, given > a > > > specified set of ICE components (or whatever). > > > > > > 8. We define what constitutes a minimal configuration set; all of > the > > > above > > > just work with this level of configuration (and credentials from an > > > overlay). We of course define the configuration mechanism. I'm > > > thinking > > > that we do this by configuring the device with the credentials, and > > > using > > > the overlay to provide any other configuration (which could be > > > influenced > > > by, say, a website the overlay runs) automatically. > > > > > > All of these are designed to be minimum capabilities, but the idea > is > > > that > > > ANY device, with credentials on an overlay, can expect to > communicate > > > with > > > any other device on that overlay with ALL of the above. > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > conformant" > > > which means a device that does that. No protocol police, but the > idea > > > is > > > that if you say you have a "p2psip conformant" device, it means all > of > > > the > > > above. Perhaps we have a way to signal that. > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > least? > > > > > > Brian > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information > from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld > Communications > > Corp. >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 16:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCYk-00016A-8M; Wed, 04 Apr 2007 16:58:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCYj-00015v-Fo for p2psip@ietf.org; Wed, 04 Apr 2007 16:58:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZCYh-0003ey-VY for p2psip@ietf.org; Wed, 04 Apr 2007 16:58:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZCYL-0003nQ-Ow; Wed, 04 Apr 2007 15:58:02 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Bruce Lowekamp'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 16:58:19 -0400 Message-ID: <1fb601c776fb$fb96a050$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com> Thread-Index: Acd20AVy9ET+QupTSqiYGjOrN30/HAAIshIwAAFGyGAAALE5EA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have many years of experience to answer this question. I was walking to dinner in Prague with Henning the other night when he said to me "I wish I had insisted we made SIP TCP only when I first proposed to do that", which was, I believe, before 2543. I was astonished he was that precient. He should have insisted. So many things would be better if we never had allowed UDP: 1. Fragmentation 2. Security 3. NAT traversal 4. State machine complexity to achieve reliable message delivery Fragmentation alone is a good reason to avoid UDP. The benefits of UDP are exactly zero: Efficiency of setup Given the realities of systems today, it just isn't true enough to matter any more. Because of fragmentation, we have to make TCP work. We have no other reasonable options. Anyone who believes p2psip setup is inherently SMALLER than base SIP is dreaming. INVITE messages (and others) are getting longer, certs will be passed around, etc. TCP is a MUST HAVE. UDP should be MUST NOT. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:30 PM > To: Brian Rosen; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > I am not sure why Datagram TLS is not an option given the benefits > involved. > > Regards > > Michael > > > > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com > > > > > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:00 PM > To: 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > > Requiring securing the protocol seems like a good goal. We need to > > have a scheme that secures ad-hoc networks and one that works with > > NATs, so TLS over TCP certainly can't be our only option. > > Why not? What is inherent in ad-hoc networks that would preclude TLS over > TCP? What is hard about doing TLS over TCP in the presence of NAT? > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > All of these assume a particular type of device that I don't think we > > can (or should) assume for P2PSIP. Where we get into the particular > > calling features for telephony devices, hopefully we can just point at > > BLISS. > As with Henry, I agree that p2psip may be used with devices that aren't > traditional telephone-like devices. We can use a term when we want to say > how devices that purport to be telephony like devices work, without > constraining interactive gaming devices. > > > > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > agreed, although defining the exact configurations that we can support > > is quite difficult. > I'm not sure I'm following this. It does seem relatively easy to specify > the characteristics of the most common NATs encountered in the wild and > use > that to define a solution that works with those. I agree that defining, > for > a given solution, which NATs work is hard. > > Brian > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > -- > > > ----------------------------------------------- > > > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > > > > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:05:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCfn-0002Ss-41; Wed, 04 Apr 2007 17:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCfl-0002Sm-DH for p2psip@ietf.org; Wed, 04 Apr 2007 17:05:41 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCfk-0003oC-EV for p2psip@ietf.org; Wed, 04 Apr 2007 17:05:41 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34L5YQM019372 for ; Wed, 4 Apr 2007 17:05:34 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 17:05:33 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90EE@photon.objectworld.com> In-Reply-To: <1fb601c776fb$fb96a050$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd20AVy9ET+QupTSqiYGjOrN30/HAAIshIwAAFGyGAAALE5EAAAaC9Q References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com> <1fb601c776fb$fb96a050$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Bruce Lowekamp" X-Spam-Score: 0.70 () [Tag at 20.00] HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.1 (/) X-Scan-Signature: 81deca529f15c4b23c0e7af81dbe55c5 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0551078626==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0551078626== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C776FC.FC6088F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C776FC.FC6088F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The problem with UDP is that it is UDP. The problem with TCP is that it is TCP. =20 Let me put this another way: =20 The pr bl m w th UDP is th t it is UD . The problem with TC =20 =20 =20 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 4:58 PM To: Michael Slavitch; 'Bruce Lowekamp' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? =20 We have many years of experience to answer this question. =20 I was walking to dinner in Prague with Henning the other night when he said to me "I wish I had insisted we made SIP TCP only when I first proposed to do that", which was, I believe, before 2543. I was astonished he was that precient. He should have insisted. So many things would be better if we never had allowed UDP: =20 1. Fragmentation 2. Security 3. NAT traversal 4. State machine complexity to achieve reliable message delivery =20 Fragmentation alone is a good reason to avoid UDP.=20=20 =20 The benefits of UDP are exactly zero: Efficiency of setup =20 Given the realities of systems today, it just isn't true enough to matter any more. =20 Because of fragmentation, we have to make TCP work. We have no other reasonable options. Anyone who believes p2psip setup is inherently SMALLER than base SIP is dreaming. INVITE messages (and others) are getting longer, certs will be passed around, etc. TCP is a MUST HAVE. UDP should be MUST NOT. =20 Brian =20 > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:30 PM > To: Brian Rosen; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I am not sure why Datagram TLS is not an option given the benefits > involved. >=20 > Regards >=20 > Michael >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:00 PM > To: 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > > Requiring securing the protocol seems like a good goal. We need to > > have a scheme that secures ad-hoc networks and one that works with > > NATs, so TLS over TCP certainly can't be our only option. >=20 > Why not? What is inherent in ad-hoc networks that would preclude TLS over > TCP? What is hard about doing TLS over TCP in the presence of NAT? >=20 >=20 > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > All of these assume a particular type of device that I don't think we > > can (or should) assume for P2PSIP. Where we get into the particular > > calling features for telephony devices, hopefully we can just point at > > BLISS. > As with Henry, I agree that p2psip may be used with devices that aren't > traditional telephone-like devices. We can use a term when we want to say > how devices that purport to be telephony like devices work, without > constraining interactive gaming devices. >=20 > > > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > agreed, although defining the exact configurations that we can support > > is quite difficult. > I'm not sure I'm following this. It does seem relatively easy to specify > the characteristics of the most common NATs encountered in the wild and > use > that to define a solution that works with those. I agree that defining, > for > a given solution, which NATs work is hard. >=20 > Brian >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > -- >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. =20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_001_01C776FC.FC6088F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

The probl= em with UDP is that it is UDP.  The problem with TCP is that it is TCP.

&nbs= p;

Let me pu= t this another way:

&nbs= p;

The pr bl= m w th UDP is th t it is UD .  The problem with TC

 

 

 

 

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, April 04, 2007 4:58 PM
To: Michael Slavitch; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink?

 

We have many years of experience to answer this que= stion.

 

I was walking to dinner in Prague with Henning the = other night when he said

to me "I wish I had insisted we made SIP TCP o= nly when I first proposed to

do that", which was, I believe, before 2543.&n= bsp; I was astonished he was that

precient.  He should have insisted.  So m= any things would be better if we

never had allowed UDP:

 

1. Fragmentation

2. Security

3. NAT traversal

4. State machine complexity to achieve reliable mes= sage delivery

 

Fragmentation alone is a good reason to avoid UDP.&= nbsp;

 

The benefits of UDP are exactly zero:

Efficiency of setup

 

Given the realities of systems today, it just isn't= true enough to matter

any more.

 

Because of fragmentation, we have to make TCP work.=   We have no other

reasonable options.  Anyone who believes p2psi= p setup is inherently SMALLER

than base SIP is dreaming.  INVITE messages (a= nd others) are getting longer,

certs will be passed around, etc.  TCP is a MU= ST HAVE.  UDP should be MUST

NOT.

 

Brian

 

> -----Original Message-----

> From: Michael Slavitch [mailto:slavitch@objectworld.com]

> Sent: Wednesday, April 04, 2007 4:30 PM

> To: Brian Rosen; Bruce Lowekamp

> Cc: P2PSIP Mailing List

> Subject: RE: [P2PSIP] When we say "p2psip= " what do we want "consumers"

> tothink?

>

> I am not  sure why Datagram TLS is not an= option given the benefits

> involved.

>

> Regards

>

> Michael

>

>

>

> Michael Slavitch

> Lead, Technology Initiatives

> slavitch@objectworld.com

>

>

>

>

>

>

> -----Original Message-----

> From: Brian Rosen [mailto:br@brianrosen.net]

> Sent: Wednesday, April 04, 2007 4:00 PM

> To: 'Bruce Lowekamp'

> Cc: 'P2PSIP Mailing List'

> Subject: RE: [P2PSIP] When we say "p2psip= " what do we want "consumers"

> tothink?

>

> > > So, I propose:

> > > 1. We do not support any form of ins= ecure signaling.  We define the

> > protocol

> > > to reject attempts to signal without= TLS (or whatever).  I'm assuming

> > the

> > > protocols are TCP only.  The ov= erlay defines what credentials are

> needed

> > > (and supplies them).

> > >

> >

> > Requiring securing the protocol seems lik= e a good goal.  We need to

> > have a scheme that secures ad-hoc network= s and one that works with

> > NATs, so TLS over TCP certainly can't be = our only option.

>

> Why not?  What is inherent in ad-hoc netw= orks that would preclude TLS over

> TCP?  What is hard about doing TLS over T= CP in the presence of NAT?

>

>

> > > 2. We do not support any form of ins= ecure media.  It's always

> encrypted.

> > > This is the tough one, especially if= we say we support SIP UAs.

> > >

> > > 3. All devices that support audio su= pport wideband audio.

> > >

> > > 4. All devices support text (IM and = real time interactive).

> > >

> > > 5. All devices support presence.&nbs= p; We define a minimal set of presence

> > > characteristics that all devices pub= lish.

> > >

> > > 6. We define a minimal feature set (something like unattended and

> > attended

> > > transfer, call forward no answer, ca= ll forward busy, basic

> conferencing,

> > > ...) that every device supports the = same way.

> >

> > All of these assume a particular type of = device that I don't think we

> > can (or should) assume for P2PSIP.  = Where we get into the particular

> > calling features for telephony devices, hopefully we can just point at

> > BLISS.

> As with Henry, I agree that p2psip may be used= with devices that aren't

> traditional telephone-like devices.  We c= an use a term when we want to say

> how devices that purport to be telephony like devices work, without

> constraining interactive gaming devices.<= /o:p>

>

> >

> > >

> > > 7. All devices work behind a given s= et of NAT configurations, given a

> > > specified set of ICE components (or whatever).

> >

> > agreed, although defining the exact configurations that we can support

> > is quite difficult.

> I'm not sure I'm following this.  It does= seem relatively easy to specify

> the characteristics of the most common NATs encountered in the wild and

> use

> that to define a solution that works with thos= e.  I agree that defining,

> for

> a given solution, which NATs work is hard.

>

> Brian

>

>

> ______________________________________________= _

> P2PSIP mailing list

> P2PSIP@ietf.org

> https://www1.ietf.org/mailman/listinfo/p2psip<= o:p>

>

>

> --

>

>

> ----------------------------------------------= -

>

>

>

> This transmission (including any attachments) = may contain confidential

> information, privileged material (including ma= terial protected by the

> solicitor-client or other applicable privilege= s), or constitute non-public

> information. Any use of this information by an= yone other than the intended

> recipient is prohibited. If you have received = this transmission in error,

> please immediately reply to the sender and del= ete this information from

> your system. Use, dissemination, distribution,= or reproduction of this

> transmission by unintended recipients is not authorized and may be

> unlawful.

>

>

>

> Any views, opinions and content presented in t= his e-mail are solely those

> of the author and may not represent those of Objectworld Communications

> Corp.

 

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_001_01C776FC.FC6088F1-- --===============0551078626== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0551078626==-- From p2psip-bounces@ietf.org Wed Apr 04 17:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCi4-00078w-8x; Wed, 04 Apr 2007 17:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCi3-00078r-Fu for p2psip@ietf.org; Wed, 04 Apr 2007 17:08:03 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCi2-0004Ct-1j for p2psip@ietf.org; Wed, 04 Apr 2007 17:08:03 -0400 Received: from [64.101.173.199] ([64.101.173.199]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l34KEMT5002278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 15:14:23 -0500 In-Reply-To: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1DFF418C-CFC9-4FAA-A2E7-9BC7B0961F69@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Re: Peer definition in Concept draft Date: Wed, 4 Apr 2007 16:07:46 -0500 To: JiangXingFeng X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'Philip Matthews' , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 3, 2007, at 6:56 AM, JiangXingFeng wrote: > Hi, Dean and Philip: > > From your responses, I learned that P2PSIP peer may be not coupled > to any > SIP entity. It also says that some P2PSIP peers will not recognize SIP > message. Is my understanding right? If it is, I have some comments > on the > concept draft which are listed as follows: > 1. In section 3, all peers in the reference model are coupled to SIP > entities except gateway Peer. In my opinion, gateway peers also > have SIP > processing functionality because they should do translation between > SIP > signaling and PSTN signaling. Does the reference model imply that > all peers > have to speak SIP? If it is not the case, do we need add some peers > which > don't speak SIP? Whether a peer understands SIP or not depends greatly on its role. Since we started with P2PSIP, the roles we've though about the most involve handling SIP requests. It's quite possible that the "Bootstrap peer" may not speak SIP. Nothing in the current model requires peers to use SIP. However, there are proposals (such as dSIP) that would effectively require every peer to have at least some level of SIP knowledge. Other proposals, if I understand what Jonathan and Philip appear to be thinking, require SIP only at nodes that also have traditional SIP roles -- basically, at UAs and at SIP-to-P2PSIP boundary nodes that would look like proxies or proxy/registrars to the SIP side. This could probably be better demonstrated in the reference model. > > Comments? > > 2. In the second option of using distributed database in section > 5.2, if > Peer Z could not parse SIP message, how does the Peer Z proxy the > INVITE > message? If I don't make mistake, Peer Z at least rewrite the > Request-URI of > the message, so it have to be able to recognize and parse the SIP > message. > Imagine a model where the peer protocol is not SIP, but instead provides a means for carrying SIP requests in an "envelope" or wrapper provided by the peer protocol. Peer Z would route the request along the P2PSIP Peer Protocol channel based on the Peer ID indicated in the request's envelope, without ever doing SIP-level parsing of the request. This has some interesting advantages: 1) The SIP body could be completely protected cryptographically and not visible to intermediate peers. 2) Since the the request could be routed without parsing the text- formatted SIP message, there is the possibility that routing decisions could require substantially (perhaps an order of magnitude) less processing power than that required for conventional SIP proxies. This is further augmented by not having to decrypt/re- encrypt each request at every proxy when TLS is used. > There are similar problems in option 3 and 4. > I believe similar logic applies therein. > Comments? > > 3. In the section 5.5, some possible client behaviors are proposed. > In terms > of third alternative, namely "a peer with bad memory", clients > participate > in DHT algorithms and do not store any resource record. Here, I have a > question. For example, there is a chord overlay and there are a > peer keyed > 20, and a client keyed 19. If a resource keyed 18 want to be stored > into the > overlay, a peer keyed 20 is responsible for key 18 according to the > third > alternative. But if a normal chord algorithm is used, the client > node keyed > 19 should be the answer. IMHO, I think this alternative will break the > underlying DHT algorithm. Comments? That'll have to be addressed by people who speak CHORD, but I suspect this mode, if deemed desirable, might influence the DHT selection process. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCnJ-00017W-Nl; Wed, 04 Apr 2007 17:13:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCnI-000175-Al for p2psip@ietf.org; Wed, 04 Apr 2007 17:13:28 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZCn6-0005vS-16 for p2psip@ietf.org; Wed, 04 Apr 2007 17:13:28 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 14:13:10 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34LD8Sd000718; Wed, 4 Apr 2007 14:13:08 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l34LCv0u029573; Wed, 4 Apr 2007 14:13:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 14:12:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 14:11:11 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF45@namail5.corp.adobe.com> In-Reply-To: <1fac01c776f7$aaf26340$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd20dlXcbhN3/73SHmSqI6aoAJljQAI7c5QAAGdW5A= References: <005d01c776d1$e0d6e290$65500a0a@ronin> <1fac01c776f7$aaf26340$81238182@cis.neustar.com> From: "Henry Sinnreich" To: "Brian Rosen" , "Eric Cooper" , "Michael Slavitch" , "Paul Kyzivat" X-OriginalArrivalTime: 04 Apr 2007 21:12:56.0830 (UTC) FILETIME=[043E21E0:01C776FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: David R Oran , P2PSIP Mailing List , "Michael Hammer \(mhammer\)" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Actually, what we will have to work with is the really complex SIP=20 > configuration framework. The really complex SIP configuration framework we will _NOT work with_. How much configuration is in a Skype UA or Skype phone? 1. Email address 2. Password 3. Inbound/Outbound phone number (optional) is selected from an available pool and inserted in the download together with the crypto keys. Done! Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 3:27 PM To: 'Eric Cooper'; Henry Sinnreich; 'Michael Slavitch'; 'Paul Kyzivat' Cc: 'David R Oran'; 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)' Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario That doesn't seem to get you a very big win. Telling on server the hostname of another for fault tolerant purposes is pretty simple. Of course, we don't know how bootstrapping is going to work, but most systems depend on configuring more than one bootstrap server address in every peer. Isn't that the same thing? Of course, this also depends on your definition of "fault tolerant". The one I am used to goes like this: - Calls already up stay up and terminate normally - Calls in the process of being set up may fail the set-up, but a retry must work. The user should not be aware the fault occurred. - The next call placed after the failure occurs (and the fact of the failure communicated) completes normally. There can be no critical windows where calls fail to complete. Now, to be sure, in commercial systems, there is one more: call detail records must always complete for every completed or attempted call. Hopefully, what we design will do that. This one puzzles me more than a little: > More to the general point, and this is just my opinion of course...I think > centralized systems could approach the ease of configuration that is > inherent in P2P systems, but in general they don't. Right, so you are agreeing with my basic premise. There is nothing inherent in p2p that makes configuration easier. You are hopeful that we won't repeat the mistakes we made in designing generic SIP based systems when we had the TDM systems to see what they did wrong. When we design p2psip systems, we'll know better. Yeah, right. Actually, what we will have to work with is the really complex SIP configuration framework. We'll have a standardized way to do something that really is inherently complex. That will help some, but not a lot, because, ah, configuration of telephony is inherently complex. We know that, we just would rather believe p2psip is the Great Simplifying Principle. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCnU-0001C3-1z; Wed, 04 Apr 2007 17:13:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCnS-0001Bp-PA for p2psip@ietf.org; Wed, 04 Apr 2007 17:13:38 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZCnO-0005vP-3m for p2psip@ietf.org; Wed, 04 Apr 2007 17:13:38 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 14:13:08 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l34LD7Sd000715; Wed, 4 Apr 2007 14:13:07 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l34LCv0s029573; Wed, 4 Apr 2007 14:13:06 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 14:12:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 14:12:52 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF44@namail5.corp.adobe.com> In-Reply-To: <1fa601c776f5$564b0290$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAAJuWHA= References: <4E2DC1ACE541B94A946B8D8657E372C57A90C2@photon.objectworld.com> <1fa601c776f5$564b0290$81238182@cis.neustar.com> From: "Henry Sinnreich" To: "Brian Rosen" , "Michael Slavitch" , "P2PSIP Mailing List" X-OriginalArrivalTime: 04 Apr 2007 21:12:56.0611 (UTC) FILETIME=[041CB730:01C776FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yes, there is an option in Skype to forward calls to some phone number.=20 That's good enough for all users except agents and receptionists where other call forwarding features are an endpoint application that use the e2e call control capabilities of SIP. Such endpoint applications can be coupled with peers collocated in agent and receptionist workstations.=20 Still no servers required, nor the horrible provisioning IT systems :-)> Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 3:11 PM To: 'Michael Slavitch'; Henry Sinnreich; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? I was talking about using standards based presence systems to control how calls are routed. It's not really "call forwarding", it's "calls from this class of callers when I'm in such-and-such presence state are routed to that device". I'm not sure the end user would understand the difference, but the implementation is quite a bit different. We have standards that would cover the inter-box interfaces for such systems. I think that those standards would work for p2psip with zero to small changes. Was that what you were thinking Henry? Do you see any need for what Michael is talking about if it's not presence based routing? Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 11:47 AM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > " I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might." >=20 > It does. For example, I don't have call forward, I have on my personal > agent right now (a shameless plug for my employer, sorry) 'always call > forward for identities that I really don't want to talk to or refuse to > identify themselves, call forward when busy for most people, call forward > for even fewer people when DND, and even when I set my presence to DND > flash my call and interrupt me if it's a call from my kid's school, my > doctor, my wife, my boss, and a few people on this list, just not too > loud.' >=20 > This is done using client-server SIP server talking to another client- > server SIP server and perhaps sometimes a third SIP server from another > much larger vendor who doesn't care if they got things wrong along with a > fourth SIP server that's a message store from two vendors and a fifth SIP > server that might do 3rd party call control if our customers buy it, > (whew!), all exchanging messages in a complex energetic manner that makes > life harder for our developers than it has to be. >=20 > The underlying mechanisms are an order of magnitude more complex than they > have to be and I have proof that the amount of code needed if standard > techiques existed* to interact with 3rd parties from low-end endpoints to > big super-duper-supernodes** would be 1/10th the amount of code needed to > do the equivalent in the C/S world. A 1.5M code-line project becomes a > 150K code-line project, which as any person who has ever put together a > project plan knows carries enormous implications for probability of > failure and success, the kind of products that result, and the kind of > sales needed to justify them. >=20 > P2P enables long-tail economics in communications systems products in the > same way that you don't have to be a 3270 forms developer to develop web > content. Vendors that participate in long-tail environments such as eBay > are wise to develop on such a platform. There are others vendors, > including employers of people reading this message, that are beneficiaries > of long-tail markets. Including mine. >=20 > Regards >=20 > Michael >=20 > *Which is the only way to get people to bother as the pull in the C/S > direction is very hard. >=20 > **Which is really what a 'server' is, albeit with a much les silly name. >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 11:25 AM > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I REALLY wish I could transfer a call from Skype to my mobile and vice > versa. >=20 > I wish I could transfer it to my hardline when, for whatever reason, the > bandwidth gods are not smiling on me. >=20 > And then there is conferencing. Depending on exactly how conferencing is > implemented, you may need to transfer to a bridge. >=20 > I really think transfer is an absolute minimal requirement. >=20 > I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but I > could see how it might. >=20 > Conferencing is something that just has to work. >=20 > We need to go down the list of service examples and decide which ones are > MUST HAVE. >=20 > Brian >=20 > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Wednesday, April 04, 2007 11:14 AM > > To: Brian Rosen; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > think? > > > > These are good points and actually should copied to the SIPPING list > > since they apply to the simple SIP Toolkit :-) > > > > Excellent items are these here: > > > > >3. All devices that support audio support wideband audio. > > > > >4. All devices support text (IM and real time interactive). > > > > >5. All devices support presence. We define a minimal set of presence > > >characteristics that all devices publish. > > > > I take exception here only to the legacy from the voice-only PBX: > > > > >6. We define a minimal feature set (something like unattended and > > >attended > > >transfer, call forward no answer, call forward busy, basic > > conferencing, > > >...) that every device supports the same way. > > > > Let's first look how presence and IM may affect user behavior and if > > this cannot be a special endpoint app, say for receptionists or agents. > > > > > This is pretty much what Skype does > > > > I am using Skype now for several years for most long distance calls and > > for conferences, but have never transferred a call. May be my secretary > > would transfer a call, but I don't have one :-) > > Nor do 99.99% of consumers or most employees any more. One can IM the > > number... > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 9:49 AM > > To: 'P2PSIP Mailing List' > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > think? > > > > One of the things I think we blew big time on sip was that we didn't > > require > > some fundamental things in every sip device to differentiate them from > > existing technology. We have an opportunity to fix that with p2psip, > > and I > > think we should do it. > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > > but > > it's a very real thing that we could do which I believe would be > > helpful. > > > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > > protocol > > to reject attempts to signal without TLS (or whatever). I'm assuming > > the > > protocols are TCP only. The overlay defines what credentials are needed > > (and supplies them). > > > > 2. We do not support any form of insecure media. It's always encrypted. > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive). > > > > 5. All devices support presence. We define a minimal set of presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and > > attended > > transfer, call forward no answer, call forward busy, basic conferencing, > > ...) that every device supports the same way. > > > > 7. All devices work behind a given set of NAT configurations, given a > > specified set of ICE components (or whatever). > > > > 8. We define what constitutes a minimal configuration set; all of the > > above > > just work with this level of configuration (and credentials from an > > overlay). We of course define the configuration mechanism. I'm > > thinking > > that we do this by configuring the device with the credentials, and > > using > > the overlay to provide any other configuration (which could be > > influenced > > by, say, a website the overlay runs) automatically. > > > > All of these are designed to be minimum capabilities, but the idea is > > that > > ANY device, with credentials on an overlay, can expect to communicate > > with > > any other device on that overlay with ALL of the above. > > > > Finally, I propose we invent a phrase, something like "p2psip > > conformant" > > which means a device that does that. No protocol police, but the idea > > is > > that if you say you have a "p2psip conformant" device, it means all of > > the > > above. Perhaps we have a way to signal that. > > > > This is pretty much what Skype does. Why should we not do that, at > > least? > > > > Brian > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > -- >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCpl-0002aT-Gc; Wed, 04 Apr 2007 17:16:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCpk-0002aO-6s for p2psip@ietf.org; Wed, 04 Apr 2007 17:16:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCpj-0006hq-Cz for p2psip@ietf.org; Wed, 04 Apr 2007 17:16:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZCpL-0008VU-4H; Wed, 04 Apr 2007 16:15:38 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Henry Sinnreich'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 17:15:52 -0400 Message-ID: <1fc501c776fe$708abde0$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90EC@photon.objectworld.com> Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVAAAJR+wAAAO/uwAADw3hA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ahh, the great "Service Provider of all beings" approach. One nested overlay which is the service provider of choice for Phil.Work, Phil.Mobile and Phil.Home. All sending ka-ching to that one great SP in the sky. Please, no. Consider this small tidbit: You don't want your employer to choose the service provider for phil.home. Actually, it's not Phil.Work. You have that backwards, it's Work.Phil. You will not give me a vCard that says Phil.Work. You give me one that says Work.Phil. That's because your office creates it. Actually, it OWNS it. When you change employers, that becomes Work2.Phil You could implement Phil.Work to give to your friends that always routes to WorkX.Phil of course, but that's not what you normally would hand out. Your employer wants you to be known as Work.Phil, and specifically, they want to control how that gets answered when you no longer work for them. So, we can't have one nested DHT. We need interoperable, interworked DHTs with some flexibilities. Now, of course, it would be spectacularly great if Work.Phil could route to the same device that Phil did. As long as the device could keep the contacts and URIs and features straight, that would be fabulous. A much more interesting question is whether you EVER want to give out Phil.Mobile and Phil.Home? That is what we have today, but is that what we want? Do we want CALLER choice of device or CALLED choice of device? I think we want the latter, with the former being something very rare. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:54 PM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > I believe that good specs use MUST as much as possible and MAY only at > gunpoint, and even then only if the shooter is a good shot, so yes common > ground. > > Given the sieve nature of a DHT presence data does not create a flood of > data, a DHT itself contains the presence database, each node contains only > the data it needs, and with one writer per AOR and many readers publishing > presence is low-complexity DB stuff. Having multiple instances of the > same AOR is multi-writer multi-reader which is more complicated. > 'Presense' in that case is the cumulative set of presence for the set of > AOR's for a single higher-level identity, ie a person. My workplace may > not want to know the cumulative presence of my cottage PC, my home PC, > my handheld along with my work devices, but my kid might, and so might > E911 for that matter. > > However this begs the question: How do you aggregate a set of AOR's for a > single abstract entity, ie me? Is this set of AOR's another nested DHT, a > DHT(me)? > > Might a nested recursive DHT that contains the cumulative set of objects > defined for a higher-level object (an organization or a person) be the > best way to aggregate AOR's and hence presence? This would be an elegant > way to get the status for nested hierarchies. > > Here is what I mean: > > A DHT contains all the AOR's of Org. > A DHT within this DHT contains all the AOR's of Org.Marketing. > A DHT within this DHT contains all the AOR's of Org.Marketing.Phil > Phil's DHT contains all the objects of Phil.Home, Phil.Mobile, and > Phil.Work > > Or it could be just one AOR, for a P2P endpoint on Phil's cellphone. > > This concept scales very well. Each DHT itself has attributes including > cumulative presence, which is calculated by the members of the DHT based > on internal black box rules, and is arbitrary enough to be flexible > without forgetting some basic rules regarding AOR. > > Does this make sense, shouldn't we be using the recursive nature of DHT > to do this? > > Regards > > Michael > > > > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com > > > > > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:34 PM > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > Ahh, common ground. > > I do think we need to consider what the box roles are in p2psip in > relation > to presence. What element is the "presence server"? That element routes > calls to multiple devices. Nice, but what element in p2psip does that > kind > of routing? > > And, you are implying another layer of identifier. Normally, when we talk > about p2psip identifiers, we are assuming some form of AoR. That is the > address someone else uses to address communication to a peer. But what if > you have multiple devices that join the overlay for the same AoR? > Certainly > allowed, but what is the unique address for such devices? Who gets the > call > to the AoR and chooses the device? > > However, if every peer MUST publish presence state, and every peer MUST > have > a presence client, we are getting somewhere you and I both want to get to. > > Brian > > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 4:15 PM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > Brian: I agree with you entirely. The point is that a DHT approach > > eliminates the need for such exhausting server integration if cumulative > > presence and cumulative inputs from many disparate sources is implicit > > within a DHT. > > > > Regards > > > > Michael > > > > > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 4:11 PM > > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I was talking about using standards based presence systems to control > > how > > calls are routed. It's not really "call forwarding", it's "calls from > > this > > class of callers when I'm in such-and-such presence state are routed to > > that > > device". I'm not sure the end user would understand the difference, but > > the > > implementation is quite a bit different. We have standards that would > > cover > > the inter-box interfaces for such systems. I think that those standards > > would work for p2psip with zero to small changes. > > > > Was that what you were thinking Henry? Do you see any need for what > > Michael > > is talking about if it's not presence based routing? > > > > Brian > > > > > -----Original Message----- > > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > > Sent: Wednesday, April 04, 2007 11:47 AM > > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > " I do think that a rich presence system might obviate the Call > > forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might." > > > > > > It does. For example, I don't have call forward, I have on my > > personal > > > agent right now (a shameless plug for my employer, sorry) 'always call > > > forward for identities that I really don't want to talk to or refuse > > to > > > identify themselves, call forward when busy for most people, call > > forward > > > for even fewer people when DND, and even when I set my presence to DND > > > flash my call and interrupt me if it's a call from my kid's school, my > > > doctor, my wife, my boss, and a few people on this list, just not too > > > loud.' > > > > > > This is done using client-server SIP server talking to another client- > > > server SIP server and perhaps sometimes a third SIP server from > > another > > > much larger vendor who doesn't care if they got things wrong along > > with a > > > fourth SIP server that's a message store from two vendors and a fifth > > SIP > > > server that might do 3rd party call control if our customers buy it, > > > (whew!), all exchanging messages in a complex energetic manner that > > makes > > > life harder for our developers than it has to be. > > > > > > The underlying mechanisms are an order of magnitude more complex than > > they > > > have to be and I have proof that the amount of code needed if standard > > > techiques existed* to interact with 3rd parties from low-end endpoints > > to > > > big super-duper-supernodes** would be 1/10th the amount of code needed > > to > > > do the equivalent in the C/S world. A 1.5M code-line project becomes > > a > > > 150K code-line project, which as any person who has ever put together > > a > > > project plan knows carries enormous implications for probability of > > > failure and success, the kind of products that result, and the kind of > > > sales needed to justify them. > > > > > > P2P enables long-tail economics in communications systems products in > > the > > > same way that you don't have to be a 3270 forms developer to develop > > web > > > content. Vendors that participate in long-tail environments such as > > eBay > > > are wise to develop on such a platform. There are others vendors, > > > including employers of people reading this message, that are > > beneficiaries > > > of long-tail markets. Including mine. > > > > > > Regards > > > > > > Michael > > > > > > *Which is the only way to get people to bother as the pull in the C/S > > > direction is very hard. > > > > > > **Which is really what a 'server' is, albeit with a much les silly > > name. > > > > > > > > > > > > Michael Slavitch > > > Lead, Technology Initiatives > > > slavitch@objectworld.com > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 11:25 AM > > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > > versa. > > > > > > I wish I could transfer it to my hardline when, for whatever reason, > > the > > > bandwidth gods are not smiling on me. > > > > > > And then there is conferencing. Depending on exactly how conferencing > > is > > > implemented, you may need to transfer to a bridge. > > > > > > I really think transfer is an absolute minimal requirement. > > > > > > I do think that a rich presence system might obviate the Call forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might. > > > > > > Conferencing is something that just has to work. > > > > > > We need to go down the list of service examples and decide which ones > > are > > > MUST HAVE. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > > To: Brian Rosen; P2PSIP Mailing List > > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > > "consumers" > > > to > > > > think? > > > > > > > > These are good points and actually should copied to the SIPPING list > > > > since they apply to the simple SIP Toolkit :-) > > > > > > > > Excellent items are these here: > > > > > > > > >3. All devices that support audio support wideband audio. > > > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > > > >5. All devices support presence. We define a minimal set of > > presence > > > > >characteristics that all devices publish. > > > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > > > >6. We define a minimal feature set (something like unattended and > > > > >attended > > > > >transfer, call forward no answer, call forward busy, basic > > > > conferencing, > > > > >...) that every device supports the same way. > > > > > > > > Let's first look how presence and IM may affect user behavior and if > > > > this cannot be a special endpoint app, say for receptionists or > > agents. > > > > > > > > > This is pretty much what Skype does > > > > > > > > I am using Skype now for several years for most long distance calls > > and > > > > for conferences, but have never transferred a call. May be my > > secretary > > > > would transfer a call, but I don't have one :-) > > > > Nor do 99.99% of consumers or most employees any more. One can IM > > the > > > > number... > > > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > > To: 'P2PSIP Mailing List' > > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > > to > > > > think? > > > > > > > > One of the things I think we blew big time on sip was that we didn't > > > > require > > > > some fundamental things in every sip device to differentiate them > > from > > > > existing technology. We have an opportunity to fix that with > > p2psip, > > > > and I > > > > think we should do it. > > > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > > issue, > > > > but > > > > it's a very real thing that we could do which I believe would be > > > > helpful. > > > > > > > > So, I propose: > > > > 1. We do not support any form of insecure signaling. We define the > > > > protocol > > > > to reject attempts to signal without TLS (or whatever). I'm > > assuming > > > > the > > > > protocols are TCP only. The overlay defines what credentials are > > needed > > > > (and supplies them). > > > > > > > > 2. We do not support any form of insecure media. It's always > > encrypted. > > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > > > 3. All devices that support audio support wideband audio. > > > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > > > 5. All devices support presence. We define a minimal set of > > presence > > > > characteristics that all devices publish. > > > > > > > > 6. We define a minimal feature set (something like unattended and > > > > attended > > > > transfer, call forward no answer, call forward busy, basic > > conferencing, > > > > ...) that every device supports the same way. > > > > > > > > 7. All devices work behind a given set of NAT configurations, given > > a > > > > specified set of ICE components (or whatever). > > > > > > > > 8. We define what constitutes a minimal configuration set; all of > > the > > > > above > > > > just work with this level of configuration (and credentials from an > > > > overlay). We of course define the configuration mechanism. I'm > > > > thinking > > > > that we do this by configuring the device with the credentials, and > > > > using > > > > the overlay to provide any other configuration (which could be > > > > influenced > > > > by, say, a website the overlay runs) automatically. > > > > > > > > All of these are designed to be minimum capabilities, but the idea > > is > > > > that > > > > ANY device, with credentials on an overlay, can expect to > > communicate > > > > with > > > > any other device on that overlay with ALL of the above. > > > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > > conformant" > > > > which means a device that does that. No protocol police, but the > > idea > > > > is > > > > that if you say you have a "p2psip conformant" device, it means all > > of > > > > the > > > > above. Perhaps we have a way to signal that. > > > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > > least? > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > -- > > > > > > > > > ----------------------------------------------- > > > > > > > > > > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > > error, > > > please immediately reply to the sender and delete this information > > from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > > unlawful. > > > > > > > > > > > > Any views, opinions and content presented in this e-mail are solely > > those > > > of the author and may not represent those of Objectworld > > Communications > > > Corp. > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute non- > public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld Communications > > Corp. > > > ----------------------------------------------- > > > > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > > > > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:16:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCqS-0003iH-CS; Wed, 04 Apr 2007 17:16:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCqR-0003i6-30 for p2psip@ietf.org; Wed, 04 Apr 2007 17:16:43 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCqP-0006ls-PT for p2psip@ietf.org; Wed, 04 Apr 2007 17:16:43 -0400 Received: from [64.101.173.199] ([64.101.173.199]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l34KMaTk002316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 15:22:37 -0500 In-Reply-To: <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> References: <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <625C34B3-B421-4735-9587-0C26AA854E5D@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 16:16:02 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org trimming the overextended cc list . . . On Apr 4, 2007, at 8:59 AM, Brian Rosen wrote: > > I see many benefits to p2p, but significantly simplifying =20 > enterprise deployment isn=92t one of them. > > Hah. You may not have had the experience of trying to get multiple =20 enterprise PBXes talking to each other. Most enterprises can barely keep DNS working, and when you have a =20 couple of thousand PBXes that have to be able to route calls between =20 each other, the configuration gets ugly. We really DO need "self =20 organizing". Now factor in business-to-business and business-to-consumer calling =20 without TDM trunks. And oh yeah, firewall traversal. Now, lets morph this into an even more fluid environment -- emergency =20= responders or the like working in an ad-hoc (aka MANET, AODV) network =20= with mixed 802.11 and 802.16 components. There are dramatic potentials for P2P to help on all these fronts. -- Dean= _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:18:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCsV-0004mw-Qw; Wed, 04 Apr 2007 17:18:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCsU-0004mm-F2 for p2psip@ietf.org; Wed, 04 Apr 2007 17:18:50 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCsT-0006rz-I0 for p2psip@ietf.org; Wed, 04 Apr 2007 17:18:50 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34LIgYg019652 for ; Wed, 4 Apr 2007 17:18:42 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 17:18:42 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90EF@photon.objectworld.com> In-Reply-To: <1fc501c776fe$708abde0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVAAAJR+wAAAO/uwAADw3hAAAIh/wA== References: <4E2DC1ACE541B94A946B8D8657E372C57A90EC@photon.objectworld.com> <1fc501c776fe$708abde0$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Henry Sinnreich" , "P2PSIP Mailing List" X-Spam-Score: 1.30 (*) [Tag at 20.00] J_CHICKENPOX_44, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org One DHT Rules Them All. Depends on your goals. Organizations above a trivial size are all hierarc= hal. It is a natural human behavior. It is fractal, it is chaotic, and it = is fluid, but there you go. Hell, families are hierarchal, especially mine. ;) Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 5:16 PM To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? Ahh, the great "Service Provider of all beings" approach. One nested overlay which is the service provider of choice for Phil.Work, Phil.Mobile and Phil.Home. All sending ka-ching to that one great SP in the sky. Please, no. Consider this small tidbit: You don't want your employer to choose the service provider for phil.home. Actually, it's not Phil.Work. You have that backwards, it's Work.Phil. You will not give me a vCard that says Phil.Work. You give me one that says Work.Phil. That's because your office creates it. Actually, it OWNS it. When you change employers, that becomes Work2.Phil You could implement Phil.Work to give to your friends that always routes to WorkX.Phil of course, but that's not what you normally would hand out. Your employer wants you to be known as Work.Phil, and specifically, they want to control how that gets answered when you no longer work for them. So, we can't have one nested DHT. We need interoperable, interworked DHTs with some flexibilities. Now, of course, it would be spectacularly great if Work.Phil could route to the same device that Phil did. As long as the device could keep the contacts and URIs and features straight, that would be fabulous. A much more interesting question is whether you EVER want to give out Phil.Mobile and Phil.Home? That is what we have today, but is that what we want? Do we want CALLER choice of device or CALLED choice of device? I think we want the latter, with the former being something very rare. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:54 PM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I believe that good specs use MUST as much as possible and MAY only at > gunpoint, and even then only if the shooter is a good shot, so yes common > ground. >=20 > Given the sieve nature of a DHT presence data does not create a flood of > data, a DHT itself contains the presence database, each node contains only > the data it needs, and with one writer per AOR and many readers publishing > presence is low-complexity DB stuff. Having multiple instances of the > same AOR is multi-writer multi-reader which is more complicated. > 'Presense' in that case is the cumulative set of presence for the set of > AOR's for a single higher-level identity, ie a person. My workplace may > not want to know the cumulative presence of my cottage PC, my home PC, > my handheld along with my work devices, but my kid might, and so might > E911 for that matter. >=20 > However this begs the question: How do you aggregate a set of AOR's for a > single abstract entity, ie me? Is this set of AOR's another nested DHT, a > DHT(me)? >=20 > Might a nested recursive DHT that contains the cumulative set of objects > defined for a higher-level object (an organization or a person) be the > best way to aggregate AOR's and hence presence? This would be an elegant > way to get the status for nested hierarchies. >=20 > Here is what I mean: >=20 > A DHT contains all the AOR's of Org. > A DHT within this DHT contains all the AOR's of Org.Marketing. > A DHT within this DHT contains all the AOR's of Org.Marketing.Phil > Phil's DHT contains all the objects of Phil.Home, Phil.Mobile, and > Phil.Work >=20 > Or it could be just one AOR, for a P2P endpoint on Phil's cellphone. >=20 > This concept scales very well. Each DHT itself has attributes including > cumulative presence, which is calculated by the members of the DHT based > on internal black box rules, and is arbitrary enough to be flexible > without forgetting some basic rules regarding AOR. >=20 > Does this make sense, shouldn't we be using the recursive nature of DHT > to do this? >=20 > Regards >=20 > Michael >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:34 PM > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > Ahh, common ground. >=20 > I do think we need to consider what the box roles are in p2psip in > relation > to presence. What element is the "presence server"? That element routes > calls to multiple devices. Nice, but what element in p2psip does that > kind > of routing? >=20 > And, you are implying another layer of identifier. Normally, when we talk > about p2psip identifiers, we are assuming some form of AoR. That is the > address someone else uses to address communication to a peer. But what if > you have multiple devices that join the overlay for the same AoR? > Certainly > allowed, but what is the unique address for such devices? Who gets the > call > to the AoR and chooses the device? >=20 > However, if every peer MUST publish presence state, and every peer MUST > have > a presence client, we are getting somewhere you and I both want to get to. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 4:15 PM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > Brian: I agree with you entirely. The point is that a DHT approach > > eliminates the need for such exhausting server integration if cumulative > > presence and cumulative inputs from many disparate sources is implicit > > within a DHT. > > > > Regards > > > > Michael > > > > > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 4:11 PM > > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I was talking about using standards based presence systems to control > > how > > calls are routed. It's not really "call forwarding", it's "calls from > > this > > class of callers when I'm in such-and-such presence state are routed to > > that > > device". I'm not sure the end user would understand the difference, but > > the > > implementation is quite a bit different. We have standards that would > > cover > > the inter-box interfaces for such systems. I think that those standards > > would work for p2psip with zero to small changes. > > > > Was that what you were thinking Henry? Do you see any need for what > > Michael > > is talking about if it's not presence based routing? > > > > Brian > > > > > -----Original Message----- > > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > > Sent: Wednesday, April 04, 2007 11:47 AM > > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > " I do think that a rich presence system might obviate the Call > > forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might." > > > > > > It does. For example, I don't have call forward, I have on my > > personal > > > agent right now (a shameless plug for my employer, sorry) 'always call > > > forward for identities that I really don't want to talk to or refuse > > to > > > identify themselves, call forward when busy for most people, call > > forward > > > for even fewer people when DND, and even when I set my presence to DND > > > flash my call and interrupt me if it's a call from my kid's school, my > > > doctor, my wife, my boss, and a few people on this list, just not too > > > loud.' > > > > > > This is done using client-server SIP server talking to another client- > > > server SIP server and perhaps sometimes a third SIP server from > > another > > > much larger vendor who doesn't care if they got things wrong along > > with a > > > fourth SIP server that's a message store from two vendors and a fifth > > SIP > > > server that might do 3rd party call control if our customers buy it, > > > (whew!), all exchanging messages in a complex energetic manner that > > makes > > > life harder for our developers than it has to be. > > > > > > The underlying mechanisms are an order of magnitude more complex than > > they > > > have to be and I have proof that the amount of code needed if standard > > > techiques existed* to interact with 3rd parties from low-end endpoints > > to > > > big super-duper-supernodes** would be 1/10th the amount of code needed > > to > > > do the equivalent in the C/S world. A 1.5M code-line project becomes > > a > > > 150K code-line project, which as any person who has ever put together > > a > > > project plan knows carries enormous implications for probability of > > > failure and success, the kind of products that result, and the kind of > > > sales needed to justify them. > > > > > > P2P enables long-tail economics in communications systems products in > > the > > > same way that you don't have to be a 3270 forms developer to develop > > web > > > content. Vendors that participate in long-tail environments such as > > eBay > > > are wise to develop on such a platform. There are others vendors, > > > including employers of people reading this message, that are > > beneficiaries > > > of long-tail markets. Including mine. > > > > > > Regards > > > > > > Michael > > > > > > *Which is the only way to get people to bother as the pull in the C/S > > > direction is very hard. > > > > > > **Which is really what a 'server' is, albeit with a much les silly > > name. > > > > > > > > > > > > Michael Slavitch > > > Lead, Technology Initiatives > > > slavitch@objectworld.com > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 11:25 AM > > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > > versa. > > > > > > I wish I could transfer it to my hardline when, for whatever reason, > > the > > > bandwidth gods are not smiling on me. > > > > > > And then there is conferencing. Depending on exactly how conferencing > > is > > > implemented, you may need to transfer to a bridge. > > > > > > I really think transfer is an absolute minimal requirement. > > > > > > I do think that a rich presence system might obviate the Call forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might. > > > > > > Conferencing is something that just has to work. > > > > > > We need to go down the list of service examples and decide which ones > > are > > > MUST HAVE. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > > To: Brian Rosen; P2PSIP Mailing List > > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > > "consumers" > > > to > > > > think? > > > > > > > > These are good points and actually should copied to the SIPPING list > > > > since they apply to the simple SIP Toolkit :-) > > > > > > > > Excellent items are these here: > > > > > > > > >3. All devices that support audio support wideband audio. > > > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > > > >5. All devices support presence. We define a minimal set of > > presence > > > > >characteristics that all devices publish. > > > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > > > >6. We define a minimal feature set (something like unattended and > > > > >attended > > > > >transfer, call forward no answer, call forward busy, basic > > > > conferencing, > > > > >...) that every device supports the same way. > > > > > > > > Let's first look how presence and IM may affect user behavior and if > > > > this cannot be a special endpoint app, say for receptionists or > > agents. > > > > > > > > > This is pretty much what Skype does > > > > > > > > I am using Skype now for several years for most long distance calls > > and > > > > for conferences, but have never transferred a call. May be my > > secretary > > > > would transfer a call, but I don't have one :-) > > > > Nor do 99.99% of consumers or most employees any more. One can IM > > the > > > > number... > > > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > > To: 'P2PSIP Mailing List' > > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > > to > > > > think? > > > > > > > > One of the things I think we blew big time on sip was that we didn't > > > > require > > > > some fundamental things in every sip device to differentiate them > > from > > > > existing technology. We have an opportunity to fix that with > > p2psip, > > > > and I > > > > think we should do it. > > > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > > issue, > > > > but > > > > it's a very real thing that we could do which I believe would be > > > > helpful. > > > > > > > > So, I propose: > > > > 1. We do not support any form of insecure signaling. We define the > > > > protocol > > > > to reject attempts to signal without TLS (or whatever). I'm > > assuming > > > > the > > > > protocols are TCP only. The overlay defines what credentials are > > needed > > > > (and supplies them). > > > > > > > > 2. We do not support any form of insecure media. It's always > > encrypted. > > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > > > 3. All devices that support audio support wideband audio. > > > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > > > 5. All devices support presence. We define a minimal set of > > presence > > > > characteristics that all devices publish. > > > > > > > > 6. We define a minimal feature set (something like unattended and > > > > attended > > > > transfer, call forward no answer, call forward busy, basic > > conferencing, > > > > ...) that every device supports the same way. > > > > > > > > 7. All devices work behind a given set of NAT configurations, given > > a > > > > specified set of ICE components (or whatever). > > > > > > > > 8. We define what constitutes a minimal configuration set; all of > > the > > > > above > > > > just work with this level of configuration (and credentials from an > > > > overlay). We of course define the configuration mechanism. I'm > > > > thinking > > > > that we do this by configuring the device with the credentials, and > > > > using > > > > the overlay to provide any other configuration (which could be > > > > influenced > > > > by, say, a website the overlay runs) automatically. > > > > > > > > All of these are designed to be minimum capabilities, but the idea > > is > > > > that > > > > ANY device, with credentials on an overlay, can expect to > > communicate > > > > with > > > > any other device on that overlay with ALL of the above. > > > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > > conformant" > > > > which means a device that does that. No protocol police, but the > > idea > > > > is > > > > that if you say you have a "p2psip conformant" device, it means all > > of > > > > the > > > > above. Perhaps we have a way to signal that. > > > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > > least? > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > -- > > > > > > > > > ----------------------------------------------- > > > > > > > > > > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > > error, > > > please immediately reply to the sender and delete this information > > from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > > unlawful. > > > > > > > > > > > > Any views, opinions and content presented in this e-mail are solely > > those > > > of the author and may not represent those of Objectworld > > Communications > > > Corp. > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute non- > public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld Communications > > Corp. >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCud-00078F-8A; Wed, 04 Apr 2007 17:21:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCuc-00078A-2G for p2psip@ietf.org; Wed, 04 Apr 2007 17:21:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCua-00072L-Jg for p2psip@ietf.org; Wed, 04 Apr 2007 17:21:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZCuC-0002KE-HM; Wed, 04 Apr 2007 16:20:39 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Bruce Lowekamp'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 17:20:54 -0400 Message-ID: <1fc601c776ff$244f8e00$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90EE@photon.objectworld.com> Thread-Index: Acd20AVy9ET+QupTSqiYGjOrN30/HAAIshIwAAFGyGAAALE5EAAAaC9QAACNZzA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Michael We are well past the point in understanding how to build reliable = systems on either TCP or UDP. That has not been an issue for nearly a decade. UDP is touted as being fast and efficient. That=92s it. There is no = other claimed advantage. The problem is, that with our current understanding, = it isn't true enough to matter any more. Brian ________________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Wednesday, April 04, 2007 5:06 PM To: Brian Rosen; Bruce Lowekamp Cc: P2PSIP Mailing List Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? The problem with UDP is that it is UDP. =A0The problem with TCP is that = it is TCP. Let me put this another way: The pr bl m w th UDP is th t it is UD .=A0 The problem with TC =A0 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 4:58 PM To: Michael Slavitch; 'Bruce Lowekamp' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? We have many years of experience to answer this question. I was walking to dinner in Prague with Henning the other night when he = said to me "I wish I had insisted we made SIP TCP only when I first proposed = to do that", which was, I believe, before 2543.=A0 I was astonished he was = that precient.=A0 He should have insisted.=A0 So many things would be better = if we never had allowed UDP: 1. Fragmentation 2. Security 3. NAT traversal 4. State machine complexity to achieve reliable message delivery Fragmentation alone is a good reason to avoid UDP.=A0=20 The benefits of UDP are exactly zero: Efficiency of setup Given the realities of systems today, it just isn't true enough to = matter any more. Because of fragmentation, we have to make TCP work.=A0 We have no other reasonable options.=A0 Anyone who believes p2psip setup is inherently = SMALLER than base SIP is dreaming.=A0 INVITE messages (and others) are getting = longer, certs will be passed around, etc.=A0 TCP is a MUST HAVE.=A0 UDP should = be MUST NOT. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:30 PM > To: Brian Rosen; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I am not=A0 sure why Datagram TLS is not an option given the benefits > involved. >=20 > Regards >=20 > Michael >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:00 PM > To: 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > > > So, I propose: > > > 1. We do not support any form of insecure signaling.=A0 We define = the > > protocol > > > to reject attempts to signal without TLS (or whatever).=A0 I'm = assuming > > the > > > protocols are TCP only.=A0 The overlay defines what credentials = are > needed > > > (and supplies them). > > > > > > > Requiring securing the protocol seems like a good goal.=A0 We need = to > > have a scheme that secures ad-hoc networks and one that works with > > NATs, so TLS over TCP certainly can't be our only option. >=20 > Why not?=A0 What is inherent in ad-hoc networks that would preclude = TLS over > TCP?=A0 What is hard about doing TLS over TCP in the presence of NAT? >=20 >=20 > > > 2. We do not support any form of insecure media.=A0 It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence.=A0 We define a minimal set of = presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > All of these assume a particular type of device that I don't think = we > > can (or should) assume for P2PSIP.=A0 Where we get into the = particular > > calling features for telephony devices, hopefully we can just point = at > > BLISS. > As with Henry, I agree that p2psip may be used with devices that = aren't > traditional telephone-like devices.=A0 We can use a term when we want = to say > how devices that purport to be telephony like devices work, without > constraining interactive gaming devices. >=20 > > > > > > > > 7. All devices work behind a given set of NAT configurations, = given a > > > specified set of ICE components (or whatever). > > > > agreed, although defining the exact configurations that we can = support > > is quite difficult. > I'm not sure I'm following this.=A0 It does seem relatively easy to = specify > the characteristics of the most common NATs encountered in the wild = and > use > that to define a solution that works with those.=A0 I agree that = defining, > for > a given solution, which NATs work is hard. >=20 > Brian >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > -- >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute = non-public > information. Any use of this information by anyone other than the = intended > recipient is prohibited. If you have received this transmission in = error, > please immediately reply to the sender and delete this information = from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely = those > of the author and may not represent those of Objectworld = Communications > Corp. ________________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than the = intended recipient is prohibited. If you have received this transmission in = error, please immediately reply to the sender and delete this information from = your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be = unlawful. Any views, opinions and content presented in this e-mail are solely = those of the author and may not represent those of Objectworld Communications = Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCwC-0000bk-Af; Wed, 04 Apr 2007 17:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCwA-0000be-Tz for p2psip@ietf.org; Wed, 04 Apr 2007 17:22:38 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCw9-0007CS-Kg for p2psip@ietf.org; Wed, 04 Apr 2007 17:22:38 -0400 Received: from [64.101.173.199] ([64.101.173.199]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l34KSV2b002360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 15:28:32 -0500 In-Reply-To: <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> <1e2701c776cd$72299710$81238182@cis.neustar.com> <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <53CFDA85-9EE4-4B2F-9360-9D4D392013EB@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 16:21:57 -0500 To: "David A. Bryan" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 4, 2007, at 10:30 AM, David A. Bryan wrote: > Tend to agree with most of this, but we also need to keep in mind > non-telephony P2PSIP applications (say IPTV, voice add-on to gaming > etc.) and make sure we don't write things in such a way these > capabilities are required for these services as well. Absolutely. For example, why put text messaging into an earbud? Why put a wideband audio codec into a device marketed exclusively to the hearing-impaired? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCyw-0003M3-C0; Wed, 04 Apr 2007 17:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCyu-0003H5-NP for p2psip@ietf.org; Wed, 04 Apr 2007 17:25:28 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCyt-0007bz-Gl for p2psip@ietf.org; Wed, 04 Apr 2007 17:25:28 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l34LPAEb001052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 17:25:11 -0400 (EDT) In-Reply-To: <1fac01c776f7$aaf26340$81238182@cis.neustar.com> References: <1fac01c776f7$aaf26340$81238182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A79623A-6183-4965-8081-F9D4A922369A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 17:25:56 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > SIP itself isn't complex to configure so that it works (you should only need a user name and Digest password, and possibly an outbound proxy, but we have a discovery mechanism for that). Unfortunately, people want to configure other stuff, mostly "policy" ("no, you can't use G.722"), dial plans, special servers, UI parameters (ring tones, etc.), non-default SIP timers, transport preferences, etc. None of these depend on P2P or disappear when using P2P, unless you just don't give users those choices. Skype and other consumer products are simpler to set up because they don't let the user configure T1, not because they discovered some P2P configuration magic. (Now, P2P systems may well use the P2P infrastructure to retrieve configuration, but that's not fundamentally different from downloading an XML file via HTTP.) Henning > Actually, what we will have to work with is the really complex SIP > configuration framework. We'll have a standardized way to do > something that > really is inherently complex. That will help some, but not a lot, > because, > ah, configuration of telephony is inherently complex. We know > that, we just > would rather believe p2psip is the Great Simplifying Principle. > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD30-0004wp-5r; Wed, 04 Apr 2007 17:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD2y-0004we-Ks for p2psip@ietf.org; Wed, 04 Apr 2007 17:29:40 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZD2x-0000BA-De for p2psip@ietf.org; Wed, 04 Apr 2007 17:29:40 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l34LTagr001980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 17:29:36 -0400 (EDT) In-Reply-To: <1fc501c776fe$708abde0$81238182@cis.neustar.com> References: <1fc501c776fe$708abde0$81238182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 17:30:23 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > See grandcentral.com and the (glowing) NYT review thereof. > A much more interesting question is whether you EVER want to give out > Phil.Mobile and Phil.Home? That is what we have today, but is that > what we > want? Do we want CALLER choice of device or CALLED choice of > device? I > think we want the latter, with the former being something very rare. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD45-0006ph-1J; Wed, 04 Apr 2007 17:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD43-0006ge-8U for p2psip@ietf.org; Wed, 04 Apr 2007 17:30:47 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZD41-0000R8-P7 for p2psip@ietf.org; Wed, 04 Apr 2007 17:30:47 -0400 Received: from [64.101.173.199] ([64.101.173.199]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l34KaghQ002413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 15:36:43 -0500 In-Reply-To: <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> References: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DF04A46-2F7E-45BE-B56F-67B38B0AFDC0@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 16:30:08 -0500 To: Bruce Lowekamp X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 4, 2007, at 3:28 PM, Bruce Lowekamp wrote: > > I'm not an expert on all the options, but my understanding of TLS is > that a basic assumption is that each end has a certificate from a > trusted CA that binds it to a domain name. In an ad hoc environment, > you lack a stable domain name and a shared trusted CA that has > preallocated a certificate, so you can't possibly use TLS. > You can still use TLS. You just don't the peer-authentication properties you might be expecting. Of course, if in the process of enrollment you get a cert signed by the overlay, a lot of this goes away. Can this be applied to ad-hoc networks? Perhaps. What if all those emergency-responder radios in an ad-hoc network required having been previously enrolled while in a more connected state? Boom, identity problem solved. > As far as TCP over NAT, not all NATs support TCP simultaneous open. > There are many NATs where you will not be able to establish a TCP > connection where you could a UDP connection. (And there are some > where you can establish a TCP but not a UDP connection, although I > think there are fewer of these.) That's why you need some STUN servers out there, and a way to find them. Seems like this would work with TCP just fine. Admittedly, if every single node is behind a port and address restricted NAT, we're going to have a problem. So? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD7D-0003UT-MH; Wed, 04 Apr 2007 17:34:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD7C-0003UJ-Ds for p2psip@ietf.org; Wed, 04 Apr 2007 17:34:02 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZD7A-0001aP-0n for p2psip@ietf.org; Wed, 04 Apr 2007 17:34:02 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34LXqhB019931 for ; Wed, 4 Apr 2007 17:33:52 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 17:33:52 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90F0@photon.objectworld.com> In-Reply-To: <1fc601c776ff$244f8e00$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd20AVy9ET+QupTSqiYGjOrN30/HAAIshIwAAFGyGAAALE5EAAAaC9QAACNZzAAAD8QIA== References: <4E2DC1ACE541B94A946B8D8657E372C57A90EE@photon.objectworld.com> <1fc601c776ff$244f8e00$81238182@cis.neustar.com> From: "Michael Slavitch" To: "Brian Rosen" , "Bruce Lowekamp" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Show and tell time please, I'd appreciate some references on this.=20=20 The networks I'm forced to deal on an ongoing basis show problems with TCP = timeouts and retransmits on a frequent basis.=20=20=20=20=20 For DHT data that aggregates over time neither fragmentation is needed nor= is retransmits. The whole point of a DHT is that data comes in chunks so = a lossy link does not matter. Getting into TCP retransmit/timeout hell do= es matter. Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 5:21 PM To: Michael Slavitch; 'Bruce Lowekamp' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? Michael We are well past the point in understanding how to build reliable systems on either TCP or UDP. That has not been an issue for nearly a decade. UDP is touted as being fast and efficient. That's it. There is no other claimed advantage. The problem is, that with our current understanding, it isn't true enough to matter any more. Brian ________________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Wednesday, April 04, 2007 5:06 PM To: Brian Rosen; Bruce Lowekamp Cc: P2PSIP Mailing List Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? The problem with UDP is that it is UDP. =A0The problem with TCP is that it = is TCP. Let me put this another way: The pr bl m w th UDP is th t it is UD .=A0 The problem with TC =A0 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 4:58 PM To: Michael Slavitch; 'Bruce Lowekamp' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? We have many years of experience to answer this question. I was walking to dinner in Prague with Henning the other night when he said to me "I wish I had insisted we made SIP TCP only when I first proposed to do that", which was, I believe, before 2543.=A0 I was astonished he was that precient.=A0 He should have insisted.=A0 So many things would be better if = we never had allowed UDP: 1. Fragmentation 2. Security 3. NAT traversal 4. State machine complexity to achieve reliable message delivery Fragmentation alone is a good reason to avoid UDP.=A0=20 The benefits of UDP are exactly zero: Efficiency of setup Given the realities of systems today, it just isn't true enough to matter any more. Because of fragmentation, we have to make TCP work.=A0 We have no other reasonable options.=A0 Anyone who believes p2psip setup is inherently SMALL= ER than base SIP is dreaming.=A0 INVITE messages (and others) are getting long= er, certs will be passed around, etc.=A0 TCP is a MUST HAVE.=A0 UDP should be M= UST NOT. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:30 PM > To: Brian Rosen; Bruce Lowekamp > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I am not=A0 sure why Datagram TLS is not an option given the benefits > involved. >=20 > Regards >=20 > Michael >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:00 PM > To: 'Bruce Lowekamp' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > > > So, I propose: > > > 1. We do not support any form of insecure signaling.=A0 We define the > > protocol > > > to reject attempts to signal without TLS (or whatever).=A0 I'm assumi= ng > > the > > > protocols are TCP only.=A0 The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > > Requiring securing the protocol seems like a good goal.=A0 We need to > > have a scheme that secures ad-hoc networks and one that works with > > NATs, so TLS over TCP certainly can't be our only option. >=20 > Why not?=A0 What is inherent in ad-hoc networks that would preclude TLS o= ver > TCP?=A0 What is hard about doing TLS over TCP in the presence of NAT? >=20 >=20 > > > 2. We do not support any form of insecure media.=A0 It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence.=A0 We define a minimal set of presen= ce > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > All of these assume a particular type of device that I don't think we > > can (or should) assume for P2PSIP.=A0 Where we get into the particular > > calling features for telephony devices, hopefully we can just point at > > BLISS. > As with Henry, I agree that p2psip may be used with devices that aren't > traditional telephone-like devices.=A0 We can use a term when we want to = say > how devices that purport to be telephony like devices work, without > constraining interactive gaming devices. >=20 > > > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > agreed, although defining the exact configurations that we can support > > is quite difficult. > I'm not sure I'm following this.=A0 It does seem relatively easy to speci= fy > the characteristics of the most common NATs encountered in the wild and > use > that to define a solution that works with those.=A0 I agree that defining, > for > a given solution, which NATs work is hard. >=20 > Brian >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > -- >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. ________________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:35:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD8j-0004s4-Ai; Wed, 04 Apr 2007 17:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZD8i-0004rv-Mh for p2psip@ietf.org; Wed, 04 Apr 2007 17:35:36 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZD8h-000244-Vr for p2psip@ietf.org; Wed, 04 Apr 2007 17:35:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZD8L-000597-7h; Wed, 04 Apr 2007 16:35:14 -0500 From: "Brian Rosen" To: "'Henry Sinnreich'" , "'Michael Slavitch'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 17:35:31 -0400 Message-ID: <1fca01c77701$2de28100$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF44@namail5.corp.adobe.com> Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAAJuWHAAAKYAcA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry I love Skype. I use it. You can Skype me if you want (brtech). I could never replace any of my 3 (4 really) telephony services with Skype. It is not reliable enough, it does not meet my feature needs and it doesn't work on a network I can count on. It's a "when it works it's great" thing. I need to have call forward - no answer, not call forward. I want presence based call forward - no answer with class of caller filters. It doesn't do that. If it did, I'd have to configure it. It has to be standards based so that it can connect to other standard based systems. It can't assume that IT is the presence client, always. It has to publish presence somewhere else, standards based. I want to control what buddies see what presence info. More configuration. I want click to call (out, on my choice of outbound device, which may not be served by the same service provider, based on my presence). Skype is a hint, a tantalizing hint, but just a hint, of what could be. I'd like to engineer something that really was the right thing. I have no illusions that such a thing is inherently simple. We might be able to make the user experience pleasant. I have a quote I love from my favorite UI designer: "You have no idea how hard it was, and how complex it is, to make it look that simple" That's a tradeoff I'd make every time: complexity in the system for apparent simplicity of the user experience, but I know how hard that is to do well. Usually, you get the worst of both worlds: complex systems AND complex UI. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, April 04, 2007 5:13 PM > To: Brian Rosen; Michael Slavitch; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > Yes, there is an option in Skype to forward calls to some phone number. > > That's good enough for all users except agents and receptionists where > other call forwarding features are an endpoint application that use the > e2e call control capabilities of SIP. > > Such endpoint applications can be coupled with peers collocated in agent > and receptionist workstations. > > Still no servers required, nor the horrible provisioning IT systems :-)> > > Henry > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 3:11 PM > To: 'Michael Slavitch'; Henry Sinnreich; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > I was talking about using standards based presence systems to control > how > calls are routed. It's not really "call forwarding", it's "calls from > this > class of callers when I'm in such-and-such presence state are routed to > that > device". I'm not sure the end user would understand the difference, but > the > implementation is quite a bit different. We have standards that would > cover > the inter-box interfaces for such systems. I think that those standards > would work for p2psip with zero to small changes. > > Was that what you were thinking Henry? Do you see any need for what > Michael > is talking about if it's not presence based routing? > > Brian > > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 11:47 AM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > " I do think that a rich presence system might obviate the Call > forward > > issues. I've never seen it done, so I've never been able to try, but > I > > could see how it might." > > > > It does. For example, I don't have call forward, I have on my > personal > > agent right now (a shameless plug for my employer, sorry) 'always call > > forward for identities that I really don't want to talk to or refuse > to > > identify themselves, call forward when busy for most people, call > forward > > for even fewer people when DND, and even when I set my presence to DND > > flash my call and interrupt me if it's a call from my kid's school, my > > doctor, my wife, my boss, and a few people on this list, just not too > > loud.' > > > > This is done using client-server SIP server talking to another client- > > server SIP server and perhaps sometimes a third SIP server from > another > > much larger vendor who doesn't care if they got things wrong along > with a > > fourth SIP server that's a message store from two vendors and a fifth > SIP > > server that might do 3rd party call control if our customers buy it, > > (whew!), all exchanging messages in a complex energetic manner that > makes > > life harder for our developers than it has to be. > > > > The underlying mechanisms are an order of magnitude more complex than > they > > have to be and I have proof that the amount of code needed if standard > > techiques existed* to interact with 3rd parties from low-end endpoints > to > > big super-duper-supernodes** would be 1/10th the amount of code needed > to > > do the equivalent in the C/S world. A 1.5M code-line project becomes > a > > 150K code-line project, which as any person who has ever put together > a > > project plan knows carries enormous implications for probability of > > failure and success, the kind of products that result, and the kind of > > sales needed to justify them. > > > > P2P enables long-tail economics in communications systems products in > the > > same way that you don't have to be a 3270 forms developer to develop > web > > content. Vendors that participate in long-tail environments such as > eBay > > are wise to develop on such a platform. There are others vendors, > > including employers of people reading this message, that are > beneficiaries > > of long-tail markets. Including mine. > > > > Regards > > > > Michael > > > > *Which is the only way to get people to bother as the pull in the C/S > > direction is very hard. > > > > **Which is really what a 'server' is, albeit with a much les silly > name. > > > > > > > > Michael Slavitch > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 11:25 AM > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > versa. > > > > I wish I could transfer it to my hardline when, for whatever reason, > the > > bandwidth gods are not smiling on me. > > > > And then there is conferencing. Depending on exactly how conferencing > is > > implemented, you may need to transfer to a bridge. > > > > I really think transfer is an absolute minimal requirement. > > > > I do think that a rich presence system might obviate the Call forward > > issues. I've never seen it done, so I've never been able to try, but > I > > could see how it might. > > > > Conferencing is something that just has to work. > > > > We need to go down the list of service examples and decide which ones > are > > MUST HAVE. > > > > Brian > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > To: Brian Rosen; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > "consumers" > > to > > > think? > > > > > > These are good points and actually should copied to the SIPPING list > > > since they apply to the simple SIP Toolkit :-) > > > > > > Excellent items are these here: > > > > > > >3. All devices that support audio support wideband audio. > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > >5. All devices support presence. We define a minimal set of > presence > > > >characteristics that all devices publish. > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > >6. We define a minimal feature set (something like unattended and > > > >attended > > > >transfer, call forward no answer, call forward busy, basic > > > conferencing, > > > >...) that every device supports the same way. > > > > > > Let's first look how presence and IM may affect user behavior and if > > > this cannot be a special endpoint app, say for receptionists or > agents. > > > > > > > This is pretty much what Skype does > > > > > > I am using Skype now for several years for most long distance calls > and > > > for conferences, but have never transferred a call. May be my > secretary > > > would transfer a call, but I don't have one :-) > > > Nor do 99.99% of consumers or most employees any more. One can IM > the > > > number... > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > To: 'P2PSIP Mailing List' > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > > think? > > > > > > One of the things I think we blew big time on sip was that we didn't > > > require > > > some fundamental things in every sip device to differentiate them > from > > > existing technology. We have an opportunity to fix that with > p2psip, > > > and I > > > think we should do it. > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > > > but > > > it's a very real thing that we could do which I believe would be > > > helpful. > > > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm > assuming > > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of > presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > > > 7. All devices work behind a given set of NAT configurations, given > a > > > specified set of ICE components (or whatever). > > > > > > 8. We define what constitutes a minimal configuration set; all of > the > > > above > > > just work with this level of configuration (and credentials from an > > > overlay). We of course define the configuration mechanism. I'm > > > thinking > > > that we do this by configuring the device with the credentials, and > > > using > > > the overlay to provide any other configuration (which could be > > > influenced > > > by, say, a website the overlay runs) automatically. > > > > > > All of these are designed to be minimum capabilities, but the idea > is > > > that > > > ANY device, with credentials on an overlay, can expect to > communicate > > > with > > > any other device on that overlay with ALL of the above. > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > conformant" > > > which means a device that does that. No protocol police, but the > idea > > > is > > > that if you say you have a "p2psip conformant" device, it means all > of > > > the > > > above. Perhaps we have a way to signal that. > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > least? > > > > > > Brian > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information > from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld > Communications > > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDGI-0007Tb-Km; Wed, 04 Apr 2007 17:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDGH-0007TW-OG for p2psip@ietf.org; Wed, 04 Apr 2007 17:43:25 -0400 Received: from bay0-omc1-s25.bay0.hotmail.com ([65.54.246.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDGF-0003i6-NY for p2psip@ietf.org; Wed, 04 Apr 2007 17:43:25 -0400 Received: from bayc1-pasmtp04.bayc1.hotmail.com ([65.54.191.164]) by bay0-omc1-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 4 Apr 2007 14:43:23 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp04.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 14:43:22 -0700 Message-ID: <00e401c77702$42edd030$65500a0a@ronin> From: "Eric Cooper" To: "Brian Rosen" , "'Henry Sinnreich'" , "'Michael Slavitch'" , "'Paul Kyzivat'" References: <1fac01c776f7$aaf26340$81238182@cis.neustar.com> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 17:43:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 04 Apr 2007 21:43:22.0698 (UTC) FILETIME=[448B7AA0:01C77702] X-Spam-Score: 2.1 (++) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: 'David R Oran' , 'P2PSIP Mailing List' , "'Michael Hammer \(mhammer\)'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Well perhaps I am just hopeful, but there is a difference between = centralized server configuration and P2P configuration: The server = config is performed once, by a knowledgeable professional, whereas the = P2P config will need to be performed millions of times by millions of = end-users. Is in an inherent principle of P2P that it is easier to configure than a = centralized system. No. I'm sure we could concoct a system that = requires a two-week training course and several hours of effort to get = up and running. Of course, no one would ever use it. That should be a strong incentive to eliminate the configuration = whenever possible (i.e. try to bootstrap via multicast or a cached list = of bootstrap peers before resorting to configured addresses). My guess is that our effort will probably fail if we don't manage to = keep the configuration down to a very few items that the average = end-user can understand. I don't believe that P2P is the great simplifying principle. I actually = think that making things easy is quite hard, but a P2P system doesn't = have the crutch of a 'system administrator' that we can force into doing = all that complex configuration. So we're going to have to eliminate as = much configuration as we can and make the rest so easy that millions of = grandmothers can do it. Best Regards, Eric. ----- Original Message -----=20 From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" = ; "'Michael Slavitch'" ; = "'Paul Kyzivat'" Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" = ; "'Michael Hammer (mhammer)'" Sent: Wednesday, April 04, 2007 4:27 PM Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario > That doesn't seem to get you a very big win. Telling on server the = hostname > of another for fault tolerant purposes is pretty simple. >=20 > Of course, we don't know how bootstrapping is going to work, but most > systems depend on configuring more than one bootstrap server address = in > every peer. Isn't that the same thing? >=20 > Of course, this also depends on your definition of "fault tolerant". >=20 > The one I am used to goes like this: >=20 > - Calls already up stay up and terminate normally >=20 > - Calls in the process of being set up may fail the set-up, but a = retry must > work. The user should not be aware the fault occurred. >=20 > - The next call placed after the failure occurs (and the fact of the = failure > communicated) completes normally. There can be no critical windows = where > calls fail to complete. >=20 > Now, to be sure, in commercial systems, there is one more: call detail > records must always complete for every completed or attempted call. >=20 > Hopefully, what we design will do that. >=20 > This one puzzles me more than a little: >> More to the general point, and this is just my opinion of course...I = think >> centralized systems could approach the ease of configuration that is >> inherent in P2P systems, but in general they don't. >=20 > Right, so you are agreeing with my basic premise. There is nothing = inherent > in p2p that makes configuration easier. You are hopeful that we won't > repeat the mistakes we made in designing generic SIP based systems = when we > had the TDM systems to see what they did wrong. When we design p2psip > systems, we'll know better. Yeah, right. >=20 > Actually, what we will have to work with is the really complex SIP > configuration framework. We'll have a standardized way to do = something that > really is inherently complex. That will help some, but not a lot, = because, > ah, configuration of telephony is inherently complex. We know that, = we just > would rather believe p2psip is the Great Simplifying Principle. >=20 > Brian >=20 >> -----Original Message----- >> From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] >> Sent: Wednesday, April 04, 2007 11:57 AM >> To: Brian Rosen; 'Henry Sinnreich'; 'Michael Slavitch'; 'Paul = Kyzivat' >> Cc: 'David R Oran'; 'P2PSIP Mailing List'; 'Michael Hammer (mhammer)' >> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario >>=20 >> One small example: P2P systems are fault-tolerant, so there's no = need to >> configure the addresses of the 'fail-over' servers. >>=20 >> More to the general point, and this is just my opinion of course...I = think >> centralized systems could approach the ease of configuration that is >> inherent in P2P systems, but in general they don't. >>=20 >> Easy configuration is a 'nice-to-have' for centralized systems, but = it's a >> necessity for P2P systems. >>=20 >> Best Regards, >>=20 >> Eric. >>=20 >> ----- Original Message ----- >> From: "Brian Rosen" >> To: "'Eric Cooper'" ; "'Henry Sinnreich'" >> ; "'Michael Slavitch'" = ; >> "'Paul Kyzivat'" >> Cc: "'David R Oran'" ; "'P2PSIP Mailing List'" >> ; "'Michael Hammer (mhammer)'" >> Sent: Wednesday, April 04, 2007 10:37 AM >> Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario >>=20 >>=20 >> >> I know of a couple of major enterprise PBX vendors who offer 1 and = 2 >> week- >> >> long training courses so that their VARs can learn to install and >> >> configure the PBX. Having had the training, it will generally = take an >> >> hour or two of configuration before the PBX gets to the point = where two >> >> extensions can call each other. >> >> >> >> On the other hand, there are P2P PBX systems emerging that can be >> unboxed, >> >> plugged in and start making calls in under 2 minutes. So I'd have = to >> say >> >> that P2P does have a lot to offer in this area. >> > With comparable feature sets? >> > >> > I know of IP PBXs that can be unboxed, plugged in, and start making >> calls in >> > maybe 10 minutes. I'm not sure the difference between 2 and 10 is = that >> > significant. >> > >> > What does p2p have, inherently, that makes it easier? What makes = the 2 >> > minutes work that, say, Asterisk doesn't have? >> > >> > I'll bet you its features. If you have no features, everything is >> simple. >> > If you support any fraction of the feature set in an IP PBX, you're >> where >> > they are now. >> > >> > I once made a small wager with someone that if IP PBX vendors = offered >> > simpler systems at a lower price, they would make much more money: = the >> idea >> > being that the complexity of the feature set had driven up the = price of >> the >> > systems so far that buyers would trade simplicity for price. I = thought >> if >> > you gave them the "top 25" feature set, with roughly out-of-the-box >> > functionality, that nearly all enterprises would be satisfied. >> > >> > He showed me a valid marketing study that showed, quite clearly, = that I >> was >> > wrong. Users DEMANDED the features. They simply wouldn't purchase >> systems >> > that didn't have the features they wanted, and price wouldn't = change >> their >> > mind (at least in the range of reasonable price differences). >> > >> > Now, I'm not so sure if you asked the actual USERS of these systems = if >> they >> > agreed. But they don't make the purchase decisions. The ones that = do >> want >> > features. >> > >> > The guys that run the big IP PBX businesses are not dumb. They = know >> their >> > customers. If there was money to be made in 2 minute set up, they = could >> > provide that right now (you can find some out there, do a web = search). >> > >> > But tell me anyways: what does p2p do that simplifies configuration = for >> > enterprise? >> > >> > Brian >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 17:48:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDLa-0005Xe-7z; Wed, 04 Apr 2007 17:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDLZ-0005VW-CU for p2psip@ietf.org; Wed, 04 Apr 2007 17:48:53 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDLY-0004zV-3D for p2psip@ietf.org; Wed, 04 Apr 2007 17:48:53 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l34LmmJC020156 for ; Wed, 4 Apr 2007 17:48:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 17:48:48 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A90F1@photon.objectworld.com> In-Reply-To: <625C34B3-B421-4735-9587-0C26AA854E5D@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd2/o+QdwEn9+r8QDWukn+zRk1K7gAA2mfA References: <1e0501c776c1$6bd6bf70$81238182@cis.neustar.com> <625C34B3-B421-4735-9587-0C26AA854E5D@softarmor.com> From: "Michael Slavitch" To: "Dean Willis" , "Brian Rosen" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline: Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Wednesday, April 04, 2007 5:16 PM To: Brian Rosen Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario trimming the overextended cc list . . . On Apr 4, 2007, at 8:59 AM, Brian Rosen wrote: > > I see many benefits to p2p, but significantly simplifying=20=20 > enterprise deployment isn't one of them. > > Hah. You may not have had the experience of trying to get multiple=20=20 enterprise PBXes talking to each other. Most enterprises can barely keep DNS working, and when you have a=20=20 couple of thousand PBXes that have to be able to route calls between=20=20 each other, the configuration gets ugly. We really DO need "self=20=20 organizing". Now factor in business-to-business and business-to-consumer calling=20=20 without TDM trunks. And oh yeah, firewall traversal. Now, lets morph this into an even more fluid environment -- emergency=20=20 responders or the like working in an ad-hoc (aka MANET, AODV) network=20=20 with mixed 802.11 and 802.16 components. There are dramatic potentials for P2P to help on all these fronts. [MNS> ] All the above? That's what I do. It's hard, and the above scratc= hes the surface. You really don't want to know and if you want details buy= lots of drinks. That's why I'm here salivating at the prospect of things b= eing easier, and if not easier, and at this stage 'not horrible' will do ju= st fine. Thanks. -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 18:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDdD-0003t1-1M; Wed, 04 Apr 2007 18:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDdC-0003sw-L0 for p2psip@ietf.org; Wed, 04 Apr 2007 18:07:06 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDdB-0001nP-Al for p2psip@ietf.org; Wed, 04 Apr 2007 18:07:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZDcn-0002wB-GU; Wed, 04 Apr 2007 17:06:43 -0500 From: "Brian Rosen" To: "'Michael Slavitch'" , "'Dean Willis'" Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 18:06:59 -0400 Message-ID: <1fcd01c77705$94328870$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A90F1@photon.objectworld.com> Thread-Index: Acd2/o+QdwEn9+r8QDWukn+zRk1K7gAA2mfAAABu+AA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 5:49 PM > To: Dean Willis; Brian Rosen > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > Inline: > > > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, April 04, 2007 5:16 PM > To: Brian Rosen > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > > trimming the overextended cc list . . . > > On Apr 4, 2007, at 8:59 AM, Brian Rosen wrote: > > > > > I see many benefits to p2p, but significantly simplifying > > enterprise deployment isn't one of them. > > > > > Hah. You may not have had the experience of trying to get multiple > enterprise PBXes talking to each other. Oh, I have, I have. > > Most enterprises can barely keep DNS working, and when you have a > couple of thousand PBXes that have to be able to route calls between > each other, the configuration gets ugly. We really DO need "self > organizing". While I'd love to believe that it's possible to do this, I don't really think it is. I think we have to do things that are akin to maintain mail servers, at the least, to make this work on top of the DNS. If you expect it to work with telephone numbers, we get even more fun. Mostly, I don't see how p2p is the magic sauce that makes this possible. I also don't believe in "oh, but we HAVE to do it, it's a requirement", without a hint as to how. > > Now factor in business-to-business and business-to-consumer calling > without TDM trunks. Ah, well, with a service provider or without? If the latter, easy for the enterprise. If the former, pretty near impossible today for business to consumer, getting more possible with business to business, but not yet any enterprise purchasing push. > > And oh yeah, firewall traversal. Yep, have to bite this bullet, but again p2p doesn't help. At least we understand how to do it (and it's complicated). We can require that everyone do it from day one. Again, no protocol police. > > Now, lets morph this into an even more fluid environment -- emergency > responders or the like working in an ad-hoc (aka MANET, AODV) network > with mixed 802.11 and 802.16 components. One of my favorite subjects. Very interesting use case. I think I understand how we do this one, but it's possible only because they have existing structures that we can build trust relationships off of. > > There are dramatic potentials for P2P to help on all these fronts. On the ad-hoc front, I more or less understand. I see lots of benefits to p2p for more conventional consumer/enterprise calling, but see no proposed mechanism to solve hard configuration problems in a better way then we have now for vanilla SIP. > > > [MNS> ] All the above? That's what I do. It's hard, and the above > scratches the surface. You really don't want to know and if you want > details buy lots of drinks. That's why I'm here salivating at the prospect > of things being easier, and if not easier, and at this stage 'not > horrible' will do just fine. Thanks. Very nice, and yes we want details. Write an I-D and propose some please. I'll buy all the 35 crown Pilsner Urquell you want the next time the IETF meets in Prague. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 18:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDxJ-0003eJ-Kp; Wed, 04 Apr 2007 18:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDxJ-0003cM-4U for p2psip@ietf.org; Wed, 04 Apr 2007 18:27:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDxH-0008Om-PQ for p2psip@ietf.org; Wed, 04 Apr 2007 18:27:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZDwB-0007pW-7k; Wed, 04 Apr 2007 17:27:29 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 18:27:01 -0400 Message-ID: <1fce01c77708$7b178090$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acd3AE0QTO5qvBUoShyCR4XcnghZ7QAAS0SQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ah, but you can't have one number. You need at least two, and most people want three: Work, Personal, Family (there really is four, because there really is an equivalent of "Family" for work, the main number). You are not allowed to choose your work number. It is assigned to you by your employer, and they own it. You can try to layer something else on top of it, but the employers would prohibit your use of that in most cases. Most people still want a "family" vs a "personal" number. It means "first person in the family that answers it", and may well have different presence and routing rules. Some day, we may grow out of that. And with current implementations, one number is quite costly because you have to pay more than double because the calls (and the media) go through the one number facility AND the device facility. We could fix that with SIP (or p2psip) of course. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 04, 2007 5:30 PM > To: Brian Rosen > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > > > > See grandcentral.com and the (glowing) NYT review thereof. > > > A much more interesting question is whether you EVER want to give out > > Phil.Mobile and Phil.Home? That is what we have today, but is that > > what we > > want? Do we want CALLER choice of device or CALLED choice of > > device? I > > think we want the latter, with the former being something very rare. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 19:14:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEga-00080O-Pj; Wed, 04 Apr 2007 19:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEgZ-00080A-7w for p2psip@ietf.org; Wed, 04 Apr 2007 19:14:39 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZEgV-0003q8-Sd for p2psip@ietf.org; Wed, 04 Apr 2007 19:14:39 -0400 Received: from [64.101.173.199] ([64.101.173.199]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l34MKVWJ002922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Apr 2007 17:20:33 -0500 In-Reply-To: <1fcd01c77705$94328870$81238182@cis.neustar.com> References: <1fcd01c77705$94328870$81238182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 4 Apr 2007 18:13:57 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 4, 2007, at 5:06 PM, Brian Rosen wrote: > While I'd love to believe that it's possible to do this, I don't > really > think it is. > Then get the heck out of the way while we work on solving the problem! > I think we have to do things that are akin to maintain mail > servers, at the > least, to make this work on top of the DNS. If you expect it to > work with > telephone numbers, we get even more fun. > > Mostly, I don't see how p2p is the magic sauce that makes this > possible. I > also don't believe in "oh, but we HAVE to do it, it's a requirement", > without a hint as to how. > >> >> Now factor in business-to-business and business-to-consumer calling >> without TDM trunks. > Ah, well, with a service provider or without? If the latter, easy > for the > enterprise. If the former, pretty near impossible today for > business to > consumer, getting more possible with business to business, but not > yet any > enterprise purchasing push. > Without, of course. >> >> And oh yeah, firewall traversal. > Yep, have to bite this bullet, but again p2p doesn't help. At > least we > understand how to do it (and it's complicated). We can require that > everyone do it from day one. Again, no protocol police. We don't have any other reasonable way to find STUN/TURN servers, so yeah, p2p helps. >> >> Now, lets morph this into an even more fluid environment -- emergency >> responders or the like working in an ad-hoc (aka MANET, AODV) network >> with mixed 802.11 and 802.16 components. > One of my favorite subjects. Very interesting use case. I think I > understand how we do this one, but it's possible only because they > have > existing structures that we can build trust relationships off of. Yep. I think this is one of the more doable things. > > >> >> There are dramatic potentials for P2P to help on all these fronts. > On the ad-hoc front, I more or less understand. > > I see lots of benefits to p2p for more conventional consumer/ > enterprise > calling, but see no proposed mechanism to solve hard configuration > problems > in a better way then we have now for vanilla SIP. > The main things that gets easier to provision is internode routing. Let's say I'm aware of an implementation of "conventional" SIP that requires root-level manual configuration of "SIP trunks" to get two PBXes from the same vendor to talk to each other. The "conventional" counter-solution is to use DNS entries. Doesn't quite work, since we're in the same user namespace, and the user namespace is really distributed over the set of PBX nodes. TRIP provides possibly another solution, but only for phone numbers. Replace all this cruft with dynamic registration into a distributed database, and It Just Works. Here's another scenario where the dynamic routing of P2P makes sense. Assume a conventional IMS with 5 million uses and 50 S-CSCF nodes. Each user is dynamically assigned to an S-CSCF at registration time. A user binding is then placed into the HSS to map from user to S- CSCF. The HSS is hard to manage, scale, replicate, etc. Every phone call requires a couple of dips into the HSS to figure out the routing. Replace HSS with P2PSIP. The originating side S-CSCF/peer transforms the R-URI into a resource ID. One DHT hash later, we have the peer ID of the terminating S-CSCF. Routing follows. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 19:28:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEuH-00012n-Gw; Wed, 04 Apr 2007 19:28:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZEuG-00012g-FA for p2psip@ietf.org; Wed, 04 Apr 2007 19:28:48 -0400 Received: from [74.95.2.163] (helo=raman.networkresonance.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZEuE-0004yQ-6N for p2psip@ietf.org; Wed, 04 Apr 2007 19:28:48 -0400 Received: from raman.networkresonance.com (localhost.networkresonance.com [127.0.0.1]) by raman.networkresonance.com (Postfix) with ESMTP id 279271E8C23; Wed, 4 Apr 2007 16:29:24 -0700 (PDT) Date: Wed, 04 Apr 2007 16:29:24 -0700 From: Eric Rescorla To: "Bruce Lowekamp" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? In-Reply-To: <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> References: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070404232924.279271E8C23@raman.networkresonance.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Wed, 4 Apr 2007 16:28:45 -0400, Bruce Lowekamp wrote: > > On 4/4/07, Brian Rosen wrote: > > > > So, I propose: > > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > > the > > > > protocols are TCP only. The overlay defines what credentials are needed > > > > (and supplies them). > > > > > > > > > > Requiring securing the protocol seems like a good goal. We need to > > > have a scheme that secures ad-hoc networks and one that works with > > > NATs, so TLS over TCP certainly can't be our only option. > > > > Why not? What is inherent in ad-hoc networks that would preclude TLS over > > TCP? What is hard about doing TLS over TCP in the presence of NAT? > > > > I'm not an expert on all the options, but my understanding of TLS is > that a basic assumption is that each end has a certificate from a > trusted CA that binds it to a domain name. In an ad hoc environment, > you lack a stable domain name and a shared trusted CA that has > preallocated a certificate, so you can't possibly use TLS. Well, you need a certificate that is bound to *something*. As I'd understood it, one of the basic assumptions of P2PSIP (in this WG) was that every entity in the system was holding some cryptographic credential, so I don't think this is an inherent problem... -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 20:43:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZG45-0001W0-9w; Wed, 04 Apr 2007 20:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZG44-0001Vv-AY for p2psip@ietf.org; Wed, 04 Apr 2007 20:43:00 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZG41-0006X3-15 for p2psip@ietf.org; Wed, 04 Apr 2007 20:43:00 -0400 Received: by py-out-1112.google.com with SMTP id f31so143904pyh for ; Wed, 04 Apr 2007 17:42:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mevdtAIOo0L2ooICVOJvGh1iGockcgazhTgb5xBUqd+ywkTjMwUIYVCyxU9GMH4fs67G0KUnkuDSJtwqT8bOi2jX09Yp7lXwIyXgRTE0EzwWRSZNMaFW/sGhyqPa72aFXCwTTcU8787II3ecl0ITZhHVktUw05cU5dMU/r/SZPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jIvWYynfbe2novpcPNmdUXa1mGSNYVWSTc/fJh2l7ztiZipaShrrwdHCud2FCa2AMB3fGRmpuR2ejjAkbNScFLtxZwdSkpHRjoX+Pj3WSFdhdknO2Ypj4ELgvEZXu/ncWtgl2WLI3kwWUP06LX0aze382rtA+9KtEfdWQAFcvTE= Received: by 10.35.27.1 with SMTP id e1mr2157264pyj.1175733776749; Wed, 04 Apr 2007 17:42:56 -0700 (PDT) Received: by 10.35.107.10 with HTTP; Wed, 4 Apr 2007 17:42:56 -0700 (PDT) Message-ID: <20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com> Date: Wed, 4 Apr 2007 20:42:56 -0400 From: "Bruce Lowekamp" To: "Brian Rosen" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? In-Reply-To: <1fb601c776fb$fb96a050$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com> <1fb601c776fb$fb96a050$81238182@cis.neustar.com> X-Google-Sender-Auth: a974f0c2281a38c0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian, You are arguing that TCP would have been a better choice for conventional SIP. I absolutely agree. But you are then inferring that because TCP would have been better for conventional, it will be better for P2PSIP. That's a huge leap. On 4/4/07, Brian Rosen wrote: > We have many years of experience to answer this question. > > I was walking to dinner in Prague with Henning the other night when he said > to me "I wish I had insisted we made SIP TCP only when I first proposed to > do that", which was, I believe, before 2543. I was astonished he was that > precient. He should have insisted. So many things would be better if we > never had allowed UDP: > > 1. Fragmentation > 2. Security > 3. NAT traversal > 4. State machine complexity to achieve reliable message delivery > These are all completely true for conventional, but when we apply them to P2P, we're looking at different issues. 1 and 4 are still true, probably 2 (though we now have some good options there), but 3 is a tough question. When both sides are behind a NAT, whether TCP or UDP is easier is a somewhat thorny question. http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ presents a discussion of some of the solutions, and while they achieve a rather success rate of almost 90%, it's with some fairly involved infrastructure, at high latency cost, and (according to some people) not on an accurate sampling once commercial NATs are taken into account. > Fragmentation alone is a good reason to avoid UDP. > > The benefits of UDP are exactly zero: > Efficiency of setup > > Given the realities of systems today, it just isn't true enough to matter > any more. Ignoring NAT traversal, let's look at this question in terms of P2P environments. A P2PSIP peer will have to maintain connections with their neighbors in the overlay. Let's say maybe 16 peers. Each TCP connection requires memory for state and requires maintenance. A large overlay or active peer will require more connections. I'm not sure we can casually wave off the cost of these connections, at least on low-end devices. (I'm not sure we can't dismiss them, I'd just rather not wave them off out of hand.) When you put those connections behind a NAT, you have the question of how many simultaneous connections a NAT can maintain. > > Because of fragmentation, we have to make TCP work. We have no other > reasonable options. Solving fragmentation inside the protocol (rather than relying on IP to do it) isn't really that hard. > Anyone who believes p2psip setup is inherently SMALLER > than base SIP is dreaming. INVITE messages (and others) are getting longer, > certs will be passed around, etc. TCP is a MUST HAVE. UDP should be MUST > NOT. > I don't dispute that it was a mistake to allow UDP for conventional SIP, but there are a lot of questions to be answered before making that decision for P2P. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 20:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGGK-0002t4-26; Wed, 04 Apr 2007 20:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGGI-0002sh-S4 for p2psip@ietf.org; Wed, 04 Apr 2007 20:55:38 -0400 Received: from bay0-omc2-s17.bay0.hotmail.com ([65.54.246.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGGF-0007po-HJ for p2psip@ietf.org; Wed, 04 Apr 2007 20:55:38 -0400 Received: from bayc1-pasmtp06.bayc1.hotmail.com ([65.54.191.166]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 4 Apr 2007 17:55:34 -0700 X-Originating-IP: [70.50.100.76] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([70.50.100.76]) by bayc1-pasmtp06.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 18:00:20 -0700 Message-ID: <010d01c7771d$1c47e860$65500a0a@ronin> From: "Eric Cooper" To: "Dean Willis" , "JiangXingFeng" References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> <1DFF418C-CFC9-4FAA-A2E7-9BC7B0961F69@softarmor.com> Subject: Re: [P2PSIP] Re: Peer definition in Concept draft Date: Wed, 4 Apr 2007 20:54:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 05 Apr 2007 01:00:20.0312 (UTC) FILETIME=[C8644580:01C7771D] X-Spam-Score: 2.1 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'Philip Matthews' , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Imagine a model where the peer protocol is not SIP, but instead =20 > provides a means for carrying SIP requests in an "envelope" or =20 > wrapper provided by the peer protocol. >=20 I think this is an interesting model and agree with the advantages you = mentioned. Would there be any charter-related problems with pursuing such a model? = I ask because I think this model could easily become a generic transport = service. Would that be out-of-scope for us? =20 If we say it's not a generic transport service, but really tied more to = SIP then this model could also be viewed as defining an alternative = transport for SIP. Is that in scope? Best Regards, Eric. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 21:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGQg-00077B-G1; Wed, 04 Apr 2007 21:06:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGQe-000772-2W for p2psip@ietf.org; Wed, 04 Apr 2007 21:06:20 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGQc-0000Va-SQ for p2psip@ietf.org; Wed, 04 Apr 2007 21:06:20 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3516465002607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Apr 2007 21:06:05 -0400 (EDT) In-Reply-To: <20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com> References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com> <1fb601c776fb$fb96a050$81238182@cis.neustar.com> <20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 21:06:02 -0400 To: "Bruce Lowekamp" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > their neighbors in the overlay. Let's say maybe 16 peers. Each TCP > connection requires memory for state and requires maintenance. A > large overlay or active peer will require more connections. I'm not > sure we can casually wave off the cost of these connections, at least > on low-end devices. (I'm not sure we can't dismiss them, I'd just > rather not wave them off out of hand.) This is a red herring. The per-connection cost is somewhere in the neighborhood of 1000 bytes for a Linux-style OS. Unless you're thinking of running P2PSIP on motes, this just doesn't matter. The 'maintenance' is an initial handshake, once per peer. (We've run several hundred thousand TCP connections on a standard modern Linux box, for what it's worth.) Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 21:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGlK-0002FE-9a; Wed, 04 Apr 2007 21:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZGlI-0002Ey-J1 for p2psip@ietf.org; Wed, 04 Apr 2007 21:27:40 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZGl7-0003Cw-Tn for p2psip@ietf.org; Wed, 04 Apr 2007 21:27:40 -0400 Received: by py-out-1112.google.com with SMTP id f31so150647pyh for ; Wed, 04 Apr 2007 18:27:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DUn9bsjNPaMZyVb/JuZr1ueOOZbuG45bZ1FIarSA/IL+M7ggP8M3X/OyqxqCZ0pRG7/kzbqc7c5fvvFT++/lvaFuV8h6fthYjAcY8QxltAemGkw6eeyWzsBZjR7EPydInvH6sng70jSfWNYihSUGV2rxCybyYriVd0B77oWJAKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=nmOf5mwOkAp5inScWNjJUXLoGHqvcjhwLo2t8nXsyMZ48dYYkzK4NukRak9+ygAlxWap79YuKjoBeZHZFghcvAX1r1+8zKCLJUAQeY1MUucOnUZq/+yBOC6RODbE2rZ5r5wqNytxNOUo41SdwPP4y6tXez2V9jD2Rxf2XAwqhiY= Received: by 10.35.61.17 with SMTP id o17mr2240169pyk.1175736447516; Wed, 04 Apr 2007 18:27:27 -0700 (PDT) Received: by 10.35.107.10 with HTTP; Wed, 4 Apr 2007 18:27:27 -0700 (PDT) Message-ID: <20d2bdfb0704041827w60cf9d24sa3c4fc29be30e8c@mail.gmail.com> Date: Wed, 4 Apr 2007 21:27:27 -0400 From: "Bruce Lowekamp" To: "Henning Schulzrinne" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com> <1fb601c776fb$fb96a050$81238182@cis.neustar.com> <20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com> X-Google-Sender-Auth: 7f09e0392a1fc799 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Thus the use of the term "low-end." I think we're much more likely to have problems with NAT or firewall limitations than kernel limitations, although I don't know enough about limitations in embedded OSes other than linux. Bruce On 4/4/07, Henning Schulzrinne wrote: > > > > their neighbors in the overlay. Let's say maybe 16 peers. Each TCP > > connection requires memory for state and requires maintenance. A > > large overlay or active peer will require more connections. I'm not > > sure we can casually wave off the cost of these connections, at least > > on low-end devices. (I'm not sure we can't dismiss them, I'd just > > rather not wave them off out of hand.) > > This is a red herring. The per-connection cost is somewhere in the > neighborhood of 1000 bytes for a Linux-style OS. Unless you're > thinking of running P2PSIP on motes, this just doesn't matter. The > 'maintenance' is an initial handshake, once per peer. > > (We've run several hundred thousand TCP connections on a standard > modern Linux box, for what it's worth.) > > Henning > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 21:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZH7n-0004JP-VZ; Wed, 04 Apr 2007 21:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZH7m-0004JF-ML for p2psip@ietf.org; Wed, 04 Apr 2007 21:50:54 -0400 Received: from bay0-omc2-s33.bay0.hotmail.com ([65.54.246.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZH7l-00070X-Aa for p2psip@ietf.org; Wed, 04 Apr 2007 21:50:54 -0400 Received: from bayc1-pasmtp03.bayc1.hotmail.com ([65.54.191.163]) by bay0-omc2-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 4 Apr 2007 18:50:52 -0700 X-Originating-IP: [70.50.100.76] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([70.50.100.76]) by bayc1-pasmtp03.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 18:50:52 -0700 Message-ID: <013501c77724$d5b97e60$65500a0a@ronin> From: "Eric Cooper" To: "Bruce Lowekamp" , "Henning Schulzrinne" References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com><1fb601c776fb$fb96a050$81238182@cis.neustar.com><20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com> <20d2bdfb0704041827w60cf9d24sa3c4fc29be30e8c@mail.gmail.com> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Wed, 4 Apr 2007 21:50:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 05 Apr 2007 01:50:52.0586 (UTC) FILETIME=[D7C490A0:01C77724] X-Spam-Score: 2.1 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I believe the default FD_SETSIZE for vxWorks is 2048, so that should = give us a hint. I don't think the low-end boxes will be getting to = hundreds of thousands, but tens of tens should be OK. In other threads there's been some discussion around running P2PSIP = peers inside the NAT/FW boxes. I believe that Linksys (Cisco) recently = changed one of their popular low-end Wi-Fi routers from Linux to vxWorks = and cut the RAM and flash in half (from 16/4MB to 8/2MB). I think there will be a lot of P2PSIP peers that are several orders of = magnitude less capable than modern PCs. Best Regards, Eric. ----- Original Message -----=20 From: "Bruce Lowekamp" To: "Henning Schulzrinne" Cc: "P2PSIP Mailing List" Sent: Wednesday, April 04, 2007 9:27 PM Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" = tothink? > Thus the use of the term "low-end." >=20 > I think we're much more likely to have problems with NAT or firewall > limitations than kernel limitations, although I don't know enough > about limitations in embedded OSes other than linux. >=20 > Bruce >=20 > On 4/4/07, Henning Schulzrinne wrote: >> >> >> > their neighbors in the overlay. Let's say maybe 16 peers. Each = TCP >> > connection requires memory for state and requires maintenance. A >> > large overlay or active peer will require more connections. I'm = not >> > sure we can casually wave off the cost of these connections, at = least >> > on low-end devices. (I'm not sure we can't dismiss them, I'd just >> > rather not wave them off out of hand.) >> >> This is a red herring. The per-connection cost is somewhere in the >> neighborhood of 1000 bytes for a Linux-style OS. Unless you're >> thinking of running P2PSIP on motes, this just doesn't matter. The >> 'maintenance' is an initial handshake, once per peer. >> >> (We've run several hundred thousand TCP connections on a standard >> modern Linux box, for what it's worth.) >> >> Henning >> >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 22:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHSr-0003uD-EH; Wed, 04 Apr 2007 22:12:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHSq-0003u6-Ol for p2psip@ietf.org; Wed, 04 Apr 2007 22:12:40 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZHSp-0002kN-54 for p2psip@ietf.org; Wed, 04 Apr 2007 22:12:40 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l352CRg4023757 for ; Wed, 4 Apr 2007 22:12:27 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Apr 2007 22:11:14 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5160AE3@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd3JPjRBrG/ubWcTqKuIY9m99DzlwAArd+i References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com><1fb601c776fb$fb96a050$81238182@cis.neustar.com><20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com><20d2bdfb0704041827w60cf9d24sa3c4fc29be30e8c@mail.gmail.com> <013501c77724$d5b97e60$65500a0a@ronin> From: "Michael Slavitch" To: "Eric Cooper" , "Bruce Lowekamp" , "Henning Schulzrinne" X-Spam-Score: 0.70 () [Tag at 20.00] HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.5 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0181806278==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0181806278== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77727.DB70BB67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77727.DB70BB67 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline My worry is not the CPU, my worry is the reality-based Internet I have to d= eal with, which is like the Bronx at 3am. -----Original Message----- From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] Sent: Wed 04/04/2007 9:50 PM To: Bruce Lowekamp; Henning Schulzrinne Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? =20 I believe the default FD_SETSIZE for vxWorks is 2048, so that should give u= s a hint. I don't think the low-end boxes will be getting to hundreds of t= housands, but tens of tens should be OK. In other threads there's been some discussion around running P2PSIP peers i= nside the NAT/FW boxes. I believe that Linksys (Cisco) recently changed on= e of their popular low-end Wi-Fi routers from Linux to vxWorks and cut the = RAM and flash in half (from 16/4MB to 8/2MB). I think there will be a lot of P2PSIP peers that are several orders of magn= itude less capable than modern PCs. Best Regards, Eric. ----- Original Message -----=20 From: "Bruce Lowekamp" To: "Henning Schulzrinne" Cc: "P2PSIP Mailing List" Sent: Wednesday, April 04, 2007 9:27 PM Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? > Thus the use of the term "low-end." >=20 > I think we're much more likely to have problems with NAT or firewall > limitations than kernel limitations, although I don't know enough > about limitations in embedded OSes other than linux. >=20 > Bruce >=20 > On 4/4/07, Henning Schulzrinne wrote: >> >> >> > their neighbors in the overlay. Let's say maybe 16 peers. Each TCP >> > connection requires memory for state and requires maintenance. A >> > large overlay or active peer will require more connections. I'm not >> > sure we can casually wave off the cost of these connections, at least >> > on low-end devices. (I'm not sure we can't dismiss them, I'd just >> > rather not wave them off out of hand.) >> >> This is a red herring. The per-connection cost is somewhere in the >> neighborhood of 1000 bytes for a Linux-style OS. Unless you're >> thinking of running P2PSIP on motes, this just doesn't matter. The >> 'maintenance' is an initial handshake, once per peer. >> >> (We've run several hundred thousand TCP connections on a standard >> modern Linux box, for what it's worth.) >> >> Henning >> >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_001_01C77727.DB70BB67 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline RE: [P2PSIP] When we say "p2psip" what do we want "co= nsumers" tothink?

My worry is not the CPU, my worry is the reality-based In= ternet I have to deal with, which is like the Bronx at 3am.

-----Original Message-----
From: Eric Cooper [mailto:eri= c_d_cooper@sympatico.ca]
Sent: Wed 04/04/2007 9:50 PM
To: Bruce Lowekamp; Henning Schulzrinne
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "= consumers" tothink?

I believe the default FD_SETSIZE for vxWorks is 2048, so that should give u= s a hint.  I don't think the low-end boxes will be getting to hundreds= of thousands, but tens of tens should be OK.

In other threads there's been some discussion around running P2PSIP peers i= nside the NAT/FW boxes.  I believe that Linksys (Cisco) recently chang= ed one of their popular low-end Wi-Fi routers from Linux to vxWorks and cut= the RAM and flash in half (from 16/4MB to 8/2MB).

I think there will be a lot of P2PSIP peers that are several orders of magn= itude less capable than modern PCs.

Best Regards,

Eric.

----- Original Message -----
From: "Bruce Lowekamp" <lowekamp@sipeerior.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: "P2PSIP Mailing List" <p2psip@ietf.org>
Sent: Wednesday, April 04, 2007 9:27 PM
Subject: Re: [P2PSIP] When we say "p2psip" what do we want "= consumers" tothink?


> Thus the use of the term "low-end."
>
> I think we're much more likely to have problems with NAT or firewall > limitations than kernel limitations, although I don't know enough
> about limitations in embedded OSes other than linux.
>
> Bruce
>
> On 4/4/07, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
>>
>>
>> > their neighbors in the overlay.  Let's say maybe 16 peer= s.  Each TCP
>> > connection requires memory for state and requires maintenance= .   A
>> > large overlay or active peer will require more connections.&n= bsp; I'm not
>> > sure we can casually wave off the cost of these connections, = at least
>> > on low-end devices.  (I'm not sure we can't dismiss them= , I'd just
>> > rather not wave them off out of hand.)
>>
>> This is a red herring. The per-connection cost is somewhere in the=
>> neighborhood of 1000 bytes for a Linux-style OS. Unless you're
>> thinking of running P2PSIP on motes, this just doesn't matter. The=
>> 'maintenance' is an initial handshake, once per peer.
>>
>> (We've run several hundred thousand TCP connections on a standard<= BR> >> modern Linux box, for what it's worth.)
>>
>> Henning
>>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1= .ietf.org/mailman/listinfo/p2psip
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf= .org/mailman/listinfo/p2psip


--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------


Teach CanIt if this mail (ID 658762) is spam:

Spam:       

Forget vote:
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D = ------_=_NextPart_001_01C77727.DB70BB67-- --===============0181806278== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0181806278==-- From p2psip-bounces@ietf.org Wed Apr 04 22:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHYa-0006CN-4b; Wed, 04 Apr 2007 22:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHYY-0006CI-85 for p2psip@ietf.org; Wed, 04 Apr 2007 22:18:34 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZHYP-0003OT-Py for p2psip@ietf.org; Wed, 04 Apr 2007 22:18:34 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 04 Apr 2007 19:18:18 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l352IGSd012817; Wed, 4 Apr 2007 19:18:17 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l352IG0c026830; Wed, 4 Apr 2007 19:18:16 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 19:18:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Wed, 4 Apr 2007 19:13:26 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF4D@namail5.corp.adobe.com> In-Reply-To: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAXtFAA References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> From: "Henry Sinnreich" To: "Brian Rosen" , "P2PSIP Mailing List" X-OriginalArrivalTime: 05 Apr 2007 02:18:14.0978 (UTC) FILETIME=[AAB5B220:01C77728] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > we didn't require some fundamental things in every sip device to=20 > differentiate them from existing technology On 2nd thought, "we" MUST NOT require any features, only the SIP rendezvous service. Features are the business of the endpoint application developers, not of standards bodies, nor of the FCC or the government. The users will select the products with the features they want.=20 Now what features do I want for my social network?=20 It's no business of the standards folks to make this decision. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, April 04, 2007 9:49 AM To: 'P2PSIP Mailing List' Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? One of the things I think we blew big time on sip was that we didn't require some fundamental things in every sip device to differentiate them from existing technology. We have an opportunity to fix that with p2psip, and I think we should do it. Now, admittedly, what I'm talking about is somewhat a "marketing" issue, but it's a very real thing that we could do which I believe would be helpful. So, I propose: 1. We do not support any form of insecure signaling. We define the protocol to reject attempts to signal without TLS (or whatever). I'm assuming the protocols are TCP only. The overlay defines what credentials are needed (and supplies them). 2. We do not support any form of insecure media. It's always encrypted. This is the tough one, especially if we say we support SIP UAs. 3. All devices that support audio support wideband audio. =20 4. All devices support text (IM and real time interactive). 5. All devices support presence. We define a minimal set of presence characteristics that all devices publish. 6. We define a minimal feature set (something like unattended and attended transfer, call forward no answer, call forward busy, basic conferencing, ...) that every device supports the same way. 7. All devices work behind a given set of NAT configurations, given a specified set of ICE components (or whatever). 8. We define what constitutes a minimal configuration set; all of the above just work with this level of configuration (and credentials from an overlay). We of course define the configuration mechanism. I'm thinking that we do this by configuring the device with the credentials, and using the overlay to provide any other configuration (which could be influenced by, say, a website the overlay runs) automatically. All of these are designed to be minimum capabilities, but the idea is that ANY device, with credentials on an overlay, can expect to communicate with any other device on that overlay with ALL of the above. Finally, I propose we invent a phrase, something like "p2psip conformant" which means a device that does that. No protocol police, but the idea is that if you say you have a "p2psip conformant" device, it means all of the above. Perhaps we have a way to signal that. This is pretty much what Skype does. Why should we not do that, at least? Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 04 22:21:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHbb-0001Ba-B0; Wed, 04 Apr 2007 22:21:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZHbZ-00015L-P1 for p2psip@ietf.org; Wed, 04 Apr 2007 22:21:41 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZHbY-0003hi-76 for p2psip@ietf.org; Wed, 04 Apr 2007 22:21:41 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG0008SM6IPS3@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 05 Apr 2007 10:20:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JG000G5R6IOYD@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 05 Apr 2007 10:20:49 +0800 (CST) Received: from j36340 ([10.164.5.25]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JG0004XS6IL8Z@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 05 Apr 2007 10:20:48 +0800 (CST) Date: Thu, 05 Apr 2007 10:20:45 +0800 From: JiangXingFeng Subject: FW: [P2PSIP] Re: Peer definition in Concept draft To: p2psip@ietf.org Message-id: <006801c77729$047ffe50$1905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acd2/VK44bw3xgSIQCKDGOwnhefHuAAJu0/AAAEwQ/A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org -- Jiang XingFeng -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------------------------------------------------------------- > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Thursday, April 05, 2007 10:08 AM > To: 'Dean Willis' > Subject: RE: [P2PSIP] Re: Peer definition in Concept draft > > Hi, Dean: > Please see inline! > Regards! > -- > Jiang XingFeng > > > > Whether a peer understands SIP or not depends greatly on its role. > > Since we started with P2PSIP, the roles we've though about the most > > involve handling SIP requests. > > > > It's quite possible that the "Bootstrap peer" may not speak SIP. > > > > Nothing in the current model requires peers to use SIP. However, > > there are proposals (such as dSIP) that would effectively require > > every peer to have at least some level of SIP knowledge. > > > > Other proposals, if I understand what Jonathan and Philip appear to > > be thinking, require SIP only at nodes that also have traditional SIP > > roles -- basically, at UAs and at SIP-to-P2PSIP boundary nodes that > > would look like proxies or proxy/registrars to the SIP side. > > > > This could probably be better demonstrated in the reference model. > [Jiang XingFeng] I'd like P2PSIP reference model should allow the existence of > non-SIP peers. If non-SIP nodes are excluded from the P2PSIP reference model, > the P2PSIP will be not flexible enough to support new type of peers, for example, > STUN peers which does not speak SIP in nature. > > > > > > Imagine a model where the peer protocol is not SIP, but instead > > provides a means for carrying SIP requests in an "envelope" or > > wrapper provided by the peer protocol. > > > > Peer Z would route the request along the P2PSIP Peer Protocol channel > > based on the Peer ID indicated in the request's envelope, without > > ever doing SIP-level parsing of the request. > > > > This has some interesting advantages: > > > > 1) The SIP body could be completely protected cryptographically and > > not visible to intermediate peers. > > > > 2) Since the the request could be routed without parsing the text- > > formatted SIP message, there is the possibility that routing > > decisions could require substantially (perhaps an order of magnitude) > > less processing power than that required for conventional SIP > > proxies. This is further augmented by not having to decrypt/re- > > encrypt each request at every proxy when TLS is used. > > > [Jiang XingFeng]I like these advantages. If application messages could be delivered > through the overlay and Peers does not care about what's in the section of > application message, it will speed up lookup operations in a recursive manner. > As you suggested, every peer should have tunnel functionality to wrap application > message. Is the tunnel functionality specific to SIP? > > Comments? > > > > > > > > That'll have to be addressed by people who speak CHORD, but I suspect > > this mode, if deemed desirable, might influence the DHT selection > > process. > [Jiang XingFeng]I agree with you. > > > > > -- > > Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 01:18:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKMe-0006Ot-Gs; Thu, 05 Apr 2007 01:18:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKMd-0006Oo-1j for p2psip@ietf.org; Thu, 05 Apr 2007 01:18:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKMb-0005ww-OK for p2psip@ietf.org; Thu, 05 Apr 2007 01:18:27 -0400 Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l354OlGW004219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 23:24:47 -0500 Message-ID: <461486E3.2060300@softarmor.com> Date: Thu, 05 Apr 2007 00:19:31 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Cooper Subject: Re: [P2PSIP] Re: Peer definition in Concept draft References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> <1DFF418C-CFC9-4FAA-A2E7-9BC7B0961F69@softarmor.com> <010d01c7771d$1c47e860$65500a0a@ronin> In-Reply-To: <010d01c7771d$1c47e860$65500a0a@ronin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Philip Matthews' , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Cooper wrote: >>Imagine a model where the peer protocol is not SIP, but instead >>provides a means for carrying SIP requests in an "envelope" or >>wrapper provided by the peer protocol. >> > > > I think this is an interesting model and agree with the advantages you mentioned. > > Would there be any charter-related problems with pursuing such a model? I ask because I think this model could easily become a generic transport service. Would that be out-of-scope for us? > > If we say it's not a generic transport service, but really tied more to SIP then this model could also be viewed as defining an alternative transport for SIP. Is that in scope? > > Best Regards, > > Eric. > I hope the charter allows for this approach. It is certainly condidered in the -03 version of the Concepts and Terminology draft, and I believe still allowed for in -04. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 01:21:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKPF-0001fk-3F; Thu, 05 Apr 2007 01:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKPB-0001fc-Uu for p2psip@ietf.org; Thu, 05 Apr 2007 01:21:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKPA-0006xl-LN for p2psip@ietf.org; Thu, 05 Apr 2007 01:21:05 -0400 Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l354RV2e004233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 23:27:32 -0500 Message-ID: <46148788.5080207@softarmor.com> Date: Thu, 05 Apr 2007 00:22:16 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Slavitch Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com><1fb601c776fb$fb96a050$81238182@cis.neustar.com><20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com><20d2bdfb0704041827w60cf9d24sa3c4fc29be30e8c@mail.gmail.com> <013501c77724$d5b97e60$65500a0a@ronin> <4E2DC1ACE541B94A946B8D8657E372C5160AE3@photon.objectworld.com> In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C5160AE3@photon.objectworld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Michael Slavitch wrote: > > My worry is not the CPU, my worry is the reality-based Internet I have > to deal with, which is like the Bronx at 3am. I've been doing my daily telephony over a VPN built using IPSEC over TCP for the last couple of months, including hotels and the IETF network, and it has worked just fine. It even works moderately well when running over GPRS EDGE using a phone as a "bluetooth modem". -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 01:25:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKT2-0004kr-I8; Thu, 05 Apr 2007 01:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZKT1-0004kf-Da for p2psip@ietf.org; Thu, 05 Apr 2007 01:25:03 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZKT0-0000XC-4i for p2psip@ietf.org; Thu, 05 Apr 2007 01:25:03 -0400 Received: from [192.168.2.104] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l354VTj7004251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 23:31:29 -0500 Message-ID: <46148876.8090309@softarmor.com> Date: Thu, 05 Apr 2007 00:26:14 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: JiangXingFeng Subject: Re: FW: [P2PSIP] Re: Peer definition in Concept draft References: <006801c77729$047ffe50$1905a40a@china.huawei.com> In-Reply-To: <006801c77729$047ffe50$1905a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org JiangXingFeng wrote: >>[Jiang XingFeng] I'd like P2PSIP reference model should allow the > > existence of > >>non-SIP peers. If non-SIP nodes are excluded from the P2PSIP reference > > model, > >>the P2PSIP will be not flexible enough to support new type of peers, for > > example, > >>STUN peers which does not speak SIP in nature. Good point. Of course, if we select SIP or modified SIP as the peer protocol (as per dSIP), then excluding non-sip nodes would be impossible. ... >>>2) Since the the request could be routed without parsing the text- >>>formatted SIP message, there is the possibility that routing >>>decisions could require substantially (perhaps an order of magnitude) >>>less processing power than that required for conventional SIP >>>proxies. This is further augmented by not having to decrypt/re- >>>encrypt each request at every proxy when TLS is used. >>> >> >>[Jiang XingFeng]I like these advantages. If application messages could be > > delivered > >>through the overlay and Peers does not care about what's in the section of >>application message, it will speed up lookup operations in a recursive > > manner. > >>As you suggested, every peer should have tunnel functionality to wrap > > application > >>message. Is the tunnel functionality specific to SIP? As I read the charter, we're tasked with making it work for SIP. If it works for something besides SIP, I guess that's OK, but really not a design goal. On the other hand, the classic Postel process is to favor generality over optimization. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 03:53:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMmc-0003Pr-9r; Thu, 05 Apr 2007 03:53:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMma-0003Nw-TG for p2psip@ietf.org; Thu, 05 Apr 2007 03:53:24 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZMmT-0002DV-3A for p2psip@ietf.org; Thu, 05 Apr 2007 03:53:24 -0400 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:53:15 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:53:14 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:53:13 +0200 Message-ID: <4614AAF3.7050409@telecomitalia.it> Date: Thu, 05 Apr 2007 09:53:23 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? References: <20d2bdfb0704040843o41fad27ay4bb9c225e8b266d6@mail.gmail.com> <1ec801c776f3$e3eeb170$81238182@cis.neustar.com> <20d2bdfb0704041328o45b42597kd22603ce3ceaed20@mail.gmail.com> <7DF04A46-2F7E-45BE-B56F-67B38B0AFDC0@softarmor.com> In-Reply-To: <7DF04A46-2F7E-45BE-B56F-67B38B0AFDC0@softarmor.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 05 Apr 2007 07:53:13.0932 (UTC) FILETIME=[769EB0C0:01C77757] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1124772227==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1124772227== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090706030501070408080903" This is a cryptographically signed message in MIME format. --------------ms090706030501070408080903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dean Willis wrote: >> As far as TCP over NAT, not all NATs support TCP simultaneous open. >> There are many NATs where you will not be able to establish a TCP >> connection where you could a UDP connection. (And there are some >> where you can establish a TCP but not a UDP connection, although I >> think there are fewer of these.) > > That's why you need some STUN servers out there, and a way to find them. > Seems like this would work with TCP just fine. If you can't establish simlutaneously opened TCP connections and you can't use UDP, you need the STUN server to relay all your traffic to any natted peer; OTOH, assuming all NATs are 4787 compliant, with UDP you need the STUN server only for discovering your mapped address. In the first case you have to pay for the bandwidth twice -- to your ISP and to the STUN server. Am I wrong, Dean? -- Ciao, Enrico --------------ms090706030501070408080903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDA1MDc1MzIzWjAjBgkqhkiG9w0BCQQxFgQUShL9Nj13 o8eX1K4PUcGAchEwCLQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAFMOv7BgqsYHuJbXhkT9Vht3YHsjlKhvHHGv225F4Pemwtha03fNrnuL tckGA6RoNCQx+oHq7AQvJoGKGgDV5bgJCAiJThR94ke5FcXUsPET7udw9p+LWlTtcvgqwWua XwQIkCdyxfWwCcA68/tMp8tlc8zbN1H4uu2Rj2T1lrGYSiPENOTPlwwykY9JzcbWBh1Tigpw 9i33u0whNd78yBXJs/yVsbO8kfzOFa1VgGFIrUjJe+h9r/m6DX8RfiSosEeSzYwmWS4layxO BplSgkxD0NrYzGgSRWKZ3OH1eaum3vOYMMTviitKEqiPv4jDtKSmXaMYRWOLvL6WtDBGlwcA AAAAAAA= --------------ms090706030501070408080903-- --===============1124772227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1124772227==-- From p2psip-bounces@ietf.org Thu Apr 05 04:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNTk-0005A8-FH; Thu, 05 Apr 2007 04:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNTj-00059l-BU for p2psip@ietf.org; Thu, 05 Apr 2007 04:37:59 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZNTi-0004K1-Aq for p2psip@ietf.org; Thu, 05 Apr 2007 04:37:59 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id 3D35A127C; Thu, 5 Apr 2007 10:37:39 +0200 (MEST) Received: from sat-relay2.telecom.ptt.nl (relay4.kpn-telecom.nl [145.7.200.30]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id 187191262; Thu, 5 Apr 2007 10:37:39 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay2.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l358bcb10173; Thu, 5 Apr 2007 10:37:38 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:36:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 10:36:34 +0200 Message-ID: In-Reply-To: <1fc501c776fe$708abde0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVAAAJR+wAAAO/uwAADw3hAAF+V3MA== References: <4E2DC1ACE541B94A946B8D8657E372C57A90EC@photon.objectworld.com> <1fc501c776fe$708abde0$81238182@cis.neustar.com> From: To: , , , X-OriginalArrivalTime: 05 Apr 2007 08:36:57.0843 (UTC) FILETIME=[9297BC30:01C7775D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4824b9ef1b1988f2983d420e78cedc0a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Michael Slavitch wrote: > Given the sieve nature of a DHT presence data does not create a flood of > data, a DHT itself contains the presence database, each node contains only > the data it needs, The implicit assumption with this is that we are only concerned with presence data within this DHT.=20 I agree with Brian that we will see multiple interworked DHTs and that it will be the CALLERs choice of device. This brings up how and where to aggregate the presence data and associated user policies (e.g. do I want Work.Phil be routed to Phil.Mobile and when do I want to do this respectively).=20 In addition, presence data may come from environments outside p2psip, e.g. IPTV (I am watching my favorite sports team on TV and do not want to be interrupted). Therefore, IMO DHT presence data should be able to be federated with other presence data sources (including a presence aggegration application). Colin Pons Senior Architect WSO Innovation Management -----Oorspronkelijk bericht----- Van: Brian Rosen [mailto:br@brianrosen.net]=20 Verzonden: woensdag 4 april 2007 23:16 Aan: 'Michael Slavitch'; 'Henry Sinnreich'; 'P2PSIP Mailing List' Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Ahh, the great "Service Provider of all beings" approach. One nested overlay which is the service provider of choice for Phil.Work, Phil.Mobile and Phil.Home. All sending ka-ching to that one great SP in the sky. Please, no. Consider this small tidbit: You don't want your employer to choose the service provider for phil.home. Actually, it's not Phil.Work. You have that backwards, it's Work.Phil. You will not give me a vCard that says Phil.Work. You give me one that says Work.Phil. That's because your office creates it. Actually, it OWNS it. When you change employers, that becomes Work2.Phil You could implement Phil.Work to give to your friends that always routes to WorkX.Phil of course, but that's not what you normally would hand out. Your employer wants you to be known as Work.Phil, and specifically, they want to control how that gets answered when you no longer work for them. So, we can't have one nested DHT. We need interoperable, interworked DHTs with some flexibilities. Now, of course, it would be spectacularly great if Work.Phil could route to the same device that Phil did. As long as the device could keep the contacts and URIs and features straight, that would be fabulous. A much more interesting question is whether you EVER want to give out Phil.Mobile and Phil.Home? That is what we have today, but is that what we want? Do we want CALLER choice of device or CALLED choice of device? I think we want the latter, with the former being something very rare. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:54 PM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I believe that good specs use MUST as much as possible and MAY only at > gunpoint, and even then only if the shooter is a good shot, so yes common > ground. >=20 > Given the sieve nature of a DHT presence data does not create a flood of > data, a DHT itself contains the presence database, each node contains only > the data it needs, and with one writer per AOR and many readers publishing > presence is low-complexity DB stuff. Having multiple instances of the > same AOR is multi-writer multi-reader which is more complicated. > 'Presense' in that case is the cumulative set of presence for the set of > AOR's for a single higher-level identity, ie a person. My workplace may > not want to know the cumulative presence of my cottage PC, my home PC, > my handheld along with my work devices, but my kid might, and so might > E911 for that matter. >=20 > However this begs the question: How do you aggregate a set of AOR's for a > single abstract entity, ie me? Is this set of AOR's another nested DHT, a > DHT(me)? >=20 > Might a nested recursive DHT that contains the cumulative set of objects > defined for a higher-level object (an organization or a person) be the > best way to aggregate AOR's and hence presence? This would be an elegant > way to get the status for nested hierarchies. >=20 > Here is what I mean: >=20 > A DHT contains all the AOR's of Org. > A DHT within this DHT contains all the AOR's of Org.Marketing. > A DHT within this DHT contains all the AOR's of Org.Marketing.Phil > Phil's DHT contains all the objects of Phil.Home, Phil.Mobile, and > Phil.Work >=20 > Or it could be just one AOR, for a P2P endpoint on Phil's cellphone. >=20 > This concept scales very well. Each DHT itself has attributes including > cumulative presence, which is calculated by the members of the DHT based > on internal black box rules, and is arbitrary enough to be flexible > without forgetting some basic rules regarding AOR. >=20 > Does this make sense, shouldn't we be using the recursive nature of DHT > to do this? >=20 > Regards >=20 > Michael >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:34 PM > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > Ahh, common ground. >=20 > I do think we need to consider what the box roles are in p2psip in > relation > to presence. What element is the "presence server"? That element routes > calls to multiple devices. Nice, but what element in p2psip does that > kind > of routing? >=20 > And, you are implying another layer of identifier. Normally, when we talk > about p2psip identifiers, we are assuming some form of AoR. That is the > address someone else uses to address communication to a peer. But what if > you have multiple devices that join the overlay for the same AoR? > Certainly > allowed, but what is the unique address for such devices? Who gets the > call > to the AoR and chooses the device? >=20 > However, if every peer MUST publish presence state, and every peer MUST > have > a presence client, we are getting somewhere you and I both want to get to. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 4:15 PM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > Brian: I agree with you entirely. The point is that a DHT approach > > eliminates the need for such exhausting server integration if cumulative > > presence and cumulative inputs from many disparate sources is implicit > > within a DHT. > > > > Regards > > > > Michael > > > > > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 4:11 PM > > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I was talking about using standards based presence systems to control > > how > > calls are routed. It's not really "call forwarding", it's "calls from > > this > > class of callers when I'm in such-and-such presence state are routed to > > that > > device". I'm not sure the end user would understand the difference, but > > the > > implementation is quite a bit different. We have standards that would > > cover > > the inter-box interfaces for such systems. I think that those standards > > would work for p2psip with zero to small changes. > > > > Was that what you were thinking Henry? Do you see any need for what > > Michael > > is talking about if it's not presence based routing? > > > > Brian > > > > > -----Original Message----- > > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > > Sent: Wednesday, April 04, 2007 11:47 AM > > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > " I do think that a rich presence system might obviate the Call > > forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might." > > > > > > It does. For example, I don't have call forward, I have on my > > personal > > > agent right now (a shameless plug for my employer, sorry) 'always call > > > forward for identities that I really don't want to talk to or refuse > > to > > > identify themselves, call forward when busy for most people, call > > forward > > > for even fewer people when DND, and even when I set my presence to DND > > > flash my call and interrupt me if it's a call from my kid's school, my > > > doctor, my wife, my boss, and a few people on this list, just not too > > > loud.' > > > > > > This is done using client-server SIP server talking to another client- > > > server SIP server and perhaps sometimes a third SIP server from > > another > > > much larger vendor who doesn't care if they got things wrong along > > with a > > > fourth SIP server that's a message store from two vendors and a fifth > > SIP > > > server that might do 3rd party call control if our customers buy it, > > > (whew!), all exchanging messages in a complex energetic manner that > > makes > > > life harder for our developers than it has to be. > > > > > > The underlying mechanisms are an order of magnitude more complex than > > they > > > have to be and I have proof that the amount of code needed if standard > > > techiques existed* to interact with 3rd parties from low-end endpoints > > to > > > big super-duper-supernodes** would be 1/10th the amount of code needed > > to > > > do the equivalent in the C/S world. A 1.5M code-line project becomes > > a > > > 150K code-line project, which as any person who has ever put together > > a > > > project plan knows carries enormous implications for probability of > > > failure and success, the kind of products that result, and the kind of > > > sales needed to justify them. > > > > > > P2P enables long-tail economics in communications systems products in > > the > > > same way that you don't have to be a 3270 forms developer to develop > > web > > > content. Vendors that participate in long-tail environments such as > > eBay > > > are wise to develop on such a platform. There are others vendors, > > > including employers of people reading this message, that are > > beneficiaries > > > of long-tail markets. Including mine. > > > > > > Regards > > > > > > Michael > > > > > > *Which is the only way to get people to bother as the pull in the C/S > > > direction is very hard. > > > > > > **Which is really what a 'server' is, albeit with a much les silly > > name. > > > > > > > > > > > > Michael Slavitch > > > Lead, Technology Initiatives > > > slavitch@objectworld.com > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 11:25 AM > > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > > versa. > > > > > > I wish I could transfer it to my hardline when, for whatever reason, > > the > > > bandwidth gods are not smiling on me. > > > > > > And then there is conferencing. Depending on exactly how conferencing > > is > > > implemented, you may need to transfer to a bridge. > > > > > > I really think transfer is an absolute minimal requirement. > > > > > > I do think that a rich presence system might obviate the Call forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might. > > > > > > Conferencing is something that just has to work. > > > > > > We need to go down the list of service examples and decide which ones > > are > > > MUST HAVE. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > > To: Brian Rosen; P2PSIP Mailing List > > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > > "consumers" > > > to > > > > think? > > > > > > > > These are good points and actually should copied to the SIPPING list > > > > since they apply to the simple SIP Toolkit :-) > > > > > > > > Excellent items are these here: > > > > > > > > >3. All devices that support audio support wideband audio. > > > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > > > >5. All devices support presence. We define a minimal set of > > presence > > > > >characteristics that all devices publish. > > > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > > > >6. We define a minimal feature set (something like unattended and > > > > >attended > > > > >transfer, call forward no answer, call forward busy, basic > > > > conferencing, > > > > >...) that every device supports the same way. > > > > > > > > Let's first look how presence and IM may affect user behavior and if > > > > this cannot be a special endpoint app, say for receptionists or > > agents. > > > > > > > > > This is pretty much what Skype does > > > > > > > > I am using Skype now for several years for most long distance calls > > and > > > > for conferences, but have never transferred a call. May be my > > secretary > > > > would transfer a call, but I don't have one :-) > > > > Nor do 99.99% of consumers or most employees any more. One can IM > > the > > > > number... > > > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > > To: 'P2PSIP Mailing List' > > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > > to > > > > think? > > > > > > > > One of the things I think we blew big time on sip was that we didn't > > > > require > > > > some fundamental things in every sip device to differentiate them > > from > > > > existing technology. We have an opportunity to fix that with > > p2psip, > > > > and I > > > > think we should do it. > > > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > > issue, > > > > but > > > > it's a very real thing that we could do which I believe would be > > > > helpful. > > > > > > > > So, I propose: > > > > 1. We do not support any form of insecure signaling. We define the > > > > protocol > > > > to reject attempts to signal without TLS (or whatever). I'm > > assuming > > > > the > > > > protocols are TCP only. The overlay defines what credentials are > > needed > > > > (and supplies them). > > > > > > > > 2. We do not support any form of insecure media. It's always > > encrypted. > > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > > > 3. All devices that support audio support wideband audio. > > > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > > > 5. All devices support presence. We define a minimal set of > > presence > > > > characteristics that all devices publish. > > > > > > > > 6. We define a minimal feature set (something like unattended and > > > > attended > > > > transfer, call forward no answer, call forward busy, basic > > conferencing, > > > > ...) that every device supports the same way. > > > > > > > > 7. All devices work behind a given set of NAT configurations, given > > a > > > > specified set of ICE components (or whatever). > > > > > > > > 8. We define what constitutes a minimal configuration set; all of > > the > > > > above > > > > just work with this level of configuration (and credentials from an > > > > overlay). We of course define the configuration mechanism. I'm > > > > thinking > > > > that we do this by configuring the device with the credentials, and > > > > using > > > > the overlay to provide any other configuration (which could be > > > > influenced > > > > by, say, a website the overlay runs) automatically. > > > > > > > > All of these are designed to be minimum capabilities, but the idea > > is > > > > that > > > > ANY device, with credentials on an overlay, can expect to > > communicate > > > > with > > > > any other device on that overlay with ALL of the above. > > > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > > conformant" > > > > which means a device that does that. No protocol police, but the > > idea > > > > is > > > > that if you say you have a "p2psip conformant" device, it means all > > of > > > > the > > > > above. Perhaps we have a way to signal that. > > > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > > least? > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > -- > > > > > > > > > ----------------------------------------------- > > > > > > > > > > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > > error, > > > please immediately reply to the sender and delete this information > > from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > > unlawful. > > > > > > > > > > > > Any views, opinions and content presented in this e-mail are solely > > those > > > of the author and may not represent those of Objectworld > > Communications > > > Corp. > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute non- > public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld Communications > > Corp. >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 04:43:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNYn-0008NJ-Mv; Thu, 05 Apr 2007 04:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNYm-0008MY-7A for p2psip@ietf.org; Thu, 05 Apr 2007 04:43:12 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZNYk-0005iJ-CR for p2psip@ietf.org; Thu, 05 Apr 2007 04:43:12 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id 2DAE9A98; Thu, 5 Apr 2007 10:42:59 +0200 (MEST) Received: from sat-relay1.telecom.ptt.nl (relay3.kpn-telecom.nl [145.7.200.29]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id 49B5EB9F; Thu, 5 Apr 2007 10:21:03 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay1.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l358L1T11076; Thu, 5 Apr 2007 10:21:01 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:20:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 10:19:51 +0200 Message-ID: In-Reply-To: <1e2b01c776ce$d3b9d3e0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2ziRvTwrFvyHWS/CKOBg5PKpARwAAIrQQACLn9CA= References: <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> <1e2b01c776ce$d3b9d3e0$81238182@cis.neustar.com> From: To: , X-OriginalArrivalTime: 05 Apr 2007 08:20:19.0031 (UTC) FILETIME=[3F411E70:01C7775B] X-Spam-Score: 0.2 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: hsinnrei@adobe.com, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I suggest to define these as "personal communication devices" Brian Rosen wrote: > 3. All devices that support audio support wideband audio. >=20 > 4. All devices support text (IM and real time interactive). >=20 > 5. All devices support presence. We define a minimal set of presence > characteristics that all devices publish. What do any of these have to do with telephony? Maybe telephony 2.0, but not the TDM version we know today. Furthermore, there will be devices that may not need these as are already mentioned on the list. I struggle with this because I do like these requirements for SIP devices, but I realize these requirements do not always make sense for specific categories of devices. Colin Pons Senior Architect WSO Innovation Management -----Oorspronkelijk bericht----- Van: Brian Rosen [mailto:br@brianrosen.net]=20 Verzonden: woensdag 4 april 2007 17:35 Aan: 'David A. Bryan' CC: 'Henry Sinnreich'; 'P2PSIP Mailing List' Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Sure. We can define these as "telephony devices". Some, of course (like signaling and media security) might apply across the board. Brian > -----Original Message----- > From: amelampus@gmail.com [mailto:amelampus@gmail.com] On Behalf Of David > A. Bryan > Sent: Wednesday, April 04, 2007 11:30 AM > To: Brian Rosen > Cc: Henry Sinnreich; P2PSIP Mailing List > Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? >=20 > Tend to agree with most of this, but we also need to keep in mind > non-telephony P2PSIP applications (say IPTV, voice add-on to gaming > etc.) and make sure we don't write things in such a way these > capabilities are required for these services as well. >=20 > David >=20 > On 4/4/07, Brian Rosen wrote: > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > versa. > > > > I wish I could transfer it to my hardline when, for whatever reason, the > > bandwidth gods are not smiling on me. > > > > And then there is conferencing. Depending on exactly how conferencing > is > > implemented, you may need to transfer to a bridge. > > > > I really think transfer is an absolute minimal requirement. > > > > I do think that a rich presence system might obviate the Call forward > > issues. I've never seen it done, so I've never been able to try, but I > > could see how it might. > > > > Conferencing is something that just has to work. > > > > We need to go down the list of service examples and decide which ones > are > > MUST HAVE. > > > > Brian > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > To: Brian Rosen; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > > > think? > > > > > > These are good points and actually should copied to the SIPPING list > > > since they apply to the simple SIP Toolkit :-) > > > > > > Excellent items are these here: > > > > > > >3. All devices that support audio support wideband audio. > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > >5. All devices support presence. We define a minimal set of presence > > > >characteristics that all devices publish. > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > >6. We define a minimal feature set (something like unattended and > > > >attended > > > >transfer, call forward no answer, call forward busy, basic > > > conferencing, > > > >...) that every device supports the same way. > > > > > > Let's first look how presence and IM may affect user behavior and if > > > this cannot be a special endpoint app, say for receptionists or > agents. > > > > > > > This is pretty much what Skype does > > > > > > I am using Skype now for several years for most long distance calls > and > > > for conferences, but have never transferred a call. May be my > secretary > > > would transfer a call, but I don't have one :-) > > > Nor do 99.99% of consumers or most employees any more. One can IM the > > > number... > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > To: 'P2PSIP Mailing List' > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > > think? > > > > > > One of the things I think we blew big time on sip was that we didn't > > > require > > > some fundamental things in every sip device to differentiate them from > > > existing technology. We have an opportunity to fix that with p2psip, > > > and I > > > think we should do it. > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > > > but > > > it's a very real thing that we could do which I believe would be > > > helpful. > > > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > > > 8. We define what constitutes a minimal configuration set; all of the > > > above > > > just work with this level of configuration (and credentials from an > > > overlay). We of course define the configuration mechanism. I'm > > > thinking > > > that we do this by configuring the device with the credentials, and > > > using > > > the overlay to provide any other configuration (which could be > > > influenced > > > by, say, a website the overlay runs) automatically. > > > > > > All of these are designed to be minimum capabilities, but the idea is > > > that > > > ANY device, with credentials on an overlay, can expect to communicate > > > with > > > any other device on that overlay with ALL of the above. > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > conformant" > > > which means a device that does that. No protocol police, but the idea > > > is > > > that if you say you have a "p2psip conformant" device, it means all of > > > the > > > above. Perhaps we have a way to signal that. > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > least? > > > > > > Brian > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 04:45:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNan-0003N1-U6; Thu, 05 Apr 2007 04:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNam-0003Mt-FZ for p2psip@ietf.org; Thu, 05 Apr 2007 04:45:16 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZNak-0006Bq-Pe for p2psip@ietf.org; Thu, 05 Apr 2007 04:45:16 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id 8A1951A7; Thu, 5 Apr 2007 10:45:13 +0200 (MEST) Received: from sat-relay2.telecom.ptt.nl (relay4.kpn-telecom.nl [145.7.200.30]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id A77A35AC; Thu, 5 Apr 2007 10:45:10 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay2.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l358jAb13890; Thu, 5 Apr 2007 10:45:10 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:44:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Thu, 5 Apr 2007 10:44:04 +0200 Message-ID: In-Reply-To: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAlW8lQ References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> From: To: , X-OriginalArrivalTime: 05 Apr 2007 08:44:29.0093 (UTC) FILETIME=[9F8F0550:01C7775E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian, Lot of these devices will be wireless and/or mobile.=20 I am interested in how to make SIM authentication and DHT work seamlessly together.=20 I believe that many wifi/wimax devices in the near future will be shipped with SIM stacks as well, allowing secure authetication and authorisation. Colin Pons Senior Architect WSO Innovation Management -----Oorspronkelijk bericht----- Van: Brian Rosen [mailto:br@brianrosen.net]=20 Verzonden: woensdag 4 april 2007 16:49 Aan: 'P2PSIP Mailing List' Onderwerp: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? One of the things I think we blew big time on sip was that we didn't require some fundamental things in every sip device to differentiate them from existing technology. We have an opportunity to fix that with p2psip, and I think we should do it. Now, admittedly, what I'm talking about is somewhat a "marketing" issue, but it's a very real thing that we could do which I believe would be helpful. So, I propose: 1. We do not support any form of insecure signaling. We define the protocol to reject attempts to signal without TLS (or whatever). I'm assuming the protocols are TCP only. The overlay defines what credentials are needed (and supplies them). 2. We do not support any form of insecure media. It's always encrypted. This is the tough one, especially if we say we support SIP UAs. 3. All devices that support audio support wideband audio. =20 4. All devices support text (IM and real time interactive). 5. All devices support presence. We define a minimal set of presence characteristics that all devices publish. 6. We define a minimal feature set (something like unattended and attended transfer, call forward no answer, call forward busy, basic conferencing, ...) that every device supports the same way. 7. All devices work behind a given set of NAT configurations, given a specified set of ICE components (or whatever). 8. We define what constitutes a minimal configuration set; all of the above just work with this level of configuration (and credentials from an overlay). We of course define the configuration mechanism. I'm thinking that we do this by configuring the device with the credentials, and using the overlay to provide any other configuration (which could be influenced by, say, a website the overlay runs) automatically. All of these are designed to be minimum capabilities, but the idea is that ANY device, with credentials on an overlay, can expect to communicate with any other device on that overlay with ALL of the above. Finally, I propose we invent a phrase, something like "p2psip conformant" which means a device that does that. No protocol police, but the idea is that if you say you have a "p2psip conformant" device, it means all of the above. Perhaps we have a way to signal that. This is pretty much what Skype does. Why should we not do that, at least? Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 07:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQTM-0007DV-CQ; Thu, 05 Apr 2007 07:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZQTL-0007DP-Rg for p2psip@ietf.org; Thu, 05 Apr 2007 07:49:47 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZQTH-0000Uq-L4 for p2psip@ietf.org; Thu, 05 Apr 2007 07:49:47 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l35BnQrc031309 for ; Thu, 5 Apr 2007 07:49:26 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Apr 2007 07:49:26 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5160AE4@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAAkzqwAACBPOAAAEHjYAAJUVkgAACbdVAAAJR+wAAAO/uwAADw3hAAF+V3MAAG6ryz References: <4E2DC1ACE541B94A946B8D8657E372C57A90EC@photon.objectworld.com> <1fc501c776fe$708abde0$81238182@cis.neustar.com> From: "Michael Slavitch" To: , , , X-Spam-Score: 1.30 (*) [Tag at 20.00] HTML_MESSAGE, J_CHICKENPOX_44, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9dc1e69317bb70324fa4170d71d27661 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1457437734==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1457437734== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77778.761E7EA1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77778.761E7EA1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Inline: -----Original Message----- From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] Sent: Thu 05/04/2007 4:36 AM To: br@brianrosen.net; Michael Slavitch; hsinnrei@adobe.com; p2psip@ietf.org Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? =20 Michael Slavitch wrote: > Given the sieve nature of a DHT presence data does not create a flood of > data, a DHT itself contains the presence database, each node contains only > the data it needs, The implicit assumption with this is that we are only concerned with presence data within this DHT.=20 MNS: If that is assumed implicit lets remove that assumption. In a peer mod= el such data can exit or enter the DHT through a peer. The question is how = does it get to a peer and what is the entity that calculates 'presence'? I agree with Brian that we will see multiple interworked DHTs and that it will be the CALLERs choice of device. This brings up how and where to aggregate the presence data and associated user policies (e.g. do I want Work.Phil be routed to Phil.Mobile and when do I want to do this respectively).=20 In addition, presence data may come from environments outside p2psip, e.g. IPTV (I am watching my favorite sports team on TV and do not want to be interrupted). Therefore, IMO DHT presence data should be able to be federated with other presence data sources (including a presence aggegration application). MNS: I fully agree, this is where things get useful, but how does it get t= here and who makes decisions? Through an aggregation via one node, where th= e aggregator makes decisions or via all nodes federated externally where so= me external (C/S) system decides? If it's external that's fine but it is a = different animal. Some decisions are best suited to one and some to others.= The question is, where is the application? In the peer fabric or in an out= side entity?=20 -----Oorspronkelijk bericht----- Van: Brian Rosen [mailto:br@brianrosen.net]=20 Verzonden: woensdag 4 april 2007 23:16 Aan: 'Michael Slavitch'; 'Henry Sinnreich'; 'P2PSIP Mailing List' Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Ahh, the great "Service Provider of all beings" approach. One nested overlay which is the service provider of choice for Phil.Work, Phil.Mobile and Phil.Home. All sending ka-ching to that one great SP in the sky. Please, no. Consider this small tidbit: You don't want your employer to choose the service provider for phil.home. Actually, it's not Phil.Work. You have that backwards, it's Work.Phil. You will not give me a vCard that says Phil.Work. You give me one that says Work.Phil. That's because your office creates it. Actually, it OWNS it. When you change employers, that becomes Work2.Phil You could implement Phil.Work to give to your friends that always routes to WorkX.Phil of course, but that's not what you normally would hand out. Your employer wants you to be known as Work.Phil, and specifically, they want to control how that gets answered when you no longer work for them. So, we can't have one nested DHT. We need interoperable, interworked DHTs with some flexibilities. Now, of course, it would be spectacularly great if Work.Phil could route to the same device that Phil did. As long as the device could keep the contacts and URIs and features straight, that would be fabulous. A much more interesting question is whether you EVER want to give out Phil.Mobile and Phil.Home? That is what we have today, but is that what we want? Do we want CALLER choice of device or CALLED choice of device? I think we want the latter, with the former being something very rare. Brian > -----Original Message----- > From: Michael Slavitch [mailto:slavitch@objectworld.com] > Sent: Wednesday, April 04, 2007 4:54 PM > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > I believe that good specs use MUST as much as possible and MAY only at > gunpoint, and even then only if the shooter is a good shot, so yes common > ground. >=20 > Given the sieve nature of a DHT presence data does not create a flood of > data, a DHT itself contains the presence database, each node contains only > the data it needs, and with one writer per AOR and many readers publishing > presence is low-complexity DB stuff. Having multiple instances of the > same AOR is multi-writer multi-reader which is more complicated. > 'Presense' in that case is the cumulative set of presence for the set of > AOR's for a single higher-level identity, ie a person. My workplace may > not want to know the cumulative presence of my cottage PC, my home PC, > my handheld along with my work devices, but my kid might, and so might > E911 for that matter. >=20 > However this begs the question: How do you aggregate a set of AOR's for a > single abstract entity, ie me? Is this set of AOR's another nested DHT, a > DHT(me)? >=20 > Might a nested recursive DHT that contains the cumulative set of objects > defined for a higher-level object (an organization or a person) be the > best way to aggregate AOR's and hence presence? This would be an elegant > way to get the status for nested hierarchies. >=20 > Here is what I mean: >=20 > A DHT contains all the AOR's of Org. > A DHT within this DHT contains all the AOR's of Org.Marketing. > A DHT within this DHT contains all the AOR's of Org.Marketing.Phil > Phil's DHT contains all the objects of Phil.Home, Phil.Mobile, and > Phil.Work >=20 > Or it could be just one AOR, for a P2P endpoint on Phil's cellphone. >=20 > This concept scales very well. Each DHT itself has attributes including > cumulative presence, which is calculated by the members of the DHT based > on internal black box rules, and is arbitrary enough to be flexible > without forgetting some basic rules regarding AOR. >=20 > Does this make sense, shouldn't we be using the recursive nature of DHT > to do this? >=20 > Regards >=20 > Michael >=20 >=20 >=20 > Michael Slavitch > Lead, Technology Initiatives > slavitch@objectworld.com >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 4:34 PM > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? >=20 > Ahh, common ground. >=20 > I do think we need to consider what the box roles are in p2psip in > relation > to presence. What element is the "presence server"? That element routes > calls to multiple devices. Nice, but what element in p2psip does that > kind > of routing? >=20 > And, you are implying another layer of identifier. Normally, when we talk > about p2psip identifiers, we are assuming some form of AoR. That is the > address someone else uses to address communication to a peer. But what if > you have multiple devices that join the overlay for the same AoR? > Certainly > allowed, but what is the unique address for such devices? Who gets the > call > to the AoR and chooses the device? >=20 > However, if every peer MUST publish presence state, and every peer MUST > have > a presence client, we are getting somewhere you and I both want to get to. >=20 > Brian >=20 > > -----Original Message----- > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > Sent: Wednesday, April 04, 2007 4:15 PM > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > Brian: I agree with you entirely. The point is that a DHT approach > > eliminates the need for such exhausting server integration if cumulative > > presence and cumulative inputs from many disparate sources is implicit > > within a DHT. > > > > Regards > > > > Michael > > > > > > Lead, Technology Initiatives > > slavitch@objectworld.com > > > > > > > > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 4:11 PM > > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > tothink? > > > > I was talking about using standards based presence systems to control > > how > > calls are routed. It's not really "call forwarding", it's "calls from > > this > > class of callers when I'm in such-and-such presence state are routed to > > that > > device". I'm not sure the end user would understand the difference, but > > the > > implementation is quite a bit different. We have standards that would > > cover > > the inter-box interfaces for such systems. I think that those standards > > would work for p2psip with zero to small changes. > > > > Was that what you were thinking Henry? Do you see any need for what > > Michael > > is talking about if it's not presence based routing? > > > > Brian > > > > > -----Original Message----- > > > From: Michael Slavitch [mailto:slavitch@objectworld.com] > > > Sent: Wednesday, April 04, 2007 11:47 AM > > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > " I do think that a rich presence system might obviate the Call > > forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might." > > > > > > It does. For example, I don't have call forward, I have on my > > personal > > > agent right now (a shameless plug for my employer, sorry) 'always call > > > forward for identities that I really don't want to talk to or refuse > > to > > > identify themselves, call forward when busy for most people, call > > forward > > > for even fewer people when DND, and even when I set my presence to DND > > > flash my call and interrupt me if it's a call from my kid's school, my > > > doctor, my wife, my boss, and a few people on this list, just not too > > > loud.' > > > > > > This is done using client-server SIP server talking to another client- > > > server SIP server and perhaps sometimes a third SIP server from > > another > > > much larger vendor who doesn't care if they got things wrong along > > with a > > > fourth SIP server that's a message store from two vendors and a fifth > > SIP > > > server that might do 3rd party call control if our customers buy it, > > > (whew!), all exchanging messages in a complex energetic manner that > > makes > > > life harder for our developers than it has to be. > > > > > > The underlying mechanisms are an order of magnitude more complex than > > they > > > have to be and I have proof that the amount of code needed if standard > > > techiques existed* to interact with 3rd parties from low-end endpoints > > to > > > big super-duper-supernodes** would be 1/10th the amount of code needed > > to > > > do the equivalent in the C/S world. A 1.5M code-line project becomes > > a > > > 150K code-line project, which as any person who has ever put together > > a > > > project plan knows carries enormous implications for probability of > > > failure and success, the kind of products that result, and the kind of > > > sales needed to justify them. > > > > > > P2P enables long-tail economics in communications systems products in > > the > > > same way that you don't have to be a 3270 forms developer to develop > > web > > > content. Vendors that participate in long-tail environments such as > > eBay > > > are wise to develop on such a platform. There are others vendors, > > > including employers of people reading this message, that are > > beneficiaries > > > of long-tail markets. Including mine. > > > > > > Regards > > > > > > Michael > > > > > > *Which is the only way to get people to bother as the pull in the C/S > > > direction is very hard. > > > > > > **Which is really what a 'server' is, albeit with a much les silly > > name. > > > > > > > > > > > > Michael Slavitch > > > Lead, Technology Initiatives > > > slavitch@objectworld.com > > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 11:25 AM > > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List' > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > > > tothink? > > > > > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > > versa. > > > > > > I wish I could transfer it to my hardline when, for whatever reason, > > the > > > bandwidth gods are not smiling on me. > > > > > > And then there is conferencing. Depending on exactly how conferencing > > is > > > implemented, you may need to transfer to a bridge. > > > > > > I really think transfer is an absolute minimal requirement. > > > > > > I do think that a rich presence system might obviate the Call forward > > > issues. I've never seen it done, so I've never been able to try, but > > I > > > could see how it might. > > > > > > Conferencing is something that just has to work. > > > > > > We need to go down the list of service examples and decide which ones > > are > > > MUST HAVE. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > > To: Brian Rosen; P2PSIP Mailing List > > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want > > "consumers" > > > to > > > > think? > > > > > > > > These are good points and actually should copied to the SIPPING list > > > > since they apply to the simple SIP Toolkit :-) > > > > > > > > Excellent items are these here: > > > > > > > > >3. All devices that support audio support wideband audio. > > > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > > > >5. All devices support presence. We define a minimal set of > > presence > > > > >characteristics that all devices publish. > > > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > > > >6. We define a minimal feature set (something like unattended and > > > > >attended > > > > >transfer, call forward no answer, call forward busy, basic > > > > conferencing, > > > > >...) that every device supports the same way. > > > > > > > > Let's first look how presence and IM may affect user behavior and if > > > > this cannot be a special endpoint app, say for receptionists or > > agents. > > > > > > > > > This is pretty much what Skype does > > > > > > > > I am using Skype now for several years for most long distance calls > > and > > > > for conferences, but have never transferred a call. May be my > > secretary > > > > would transfer a call, but I don't have one :-) > > > > Nor do 99.99% of consumers or most employees any more. One can IM > > the > > > > number... > > > > > > > > Thanks, Henry > > > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > > To: 'P2PSIP Mailing List' > > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" > > to > > > > think? > > > > > > > > One of the things I think we blew big time on sip was that we didn't > > > > require > > > > some fundamental things in every sip device to differentiate them > > from > > > > existing technology. We have an opportunity to fix that with > > p2psip, > > > > and I > > > > think we should do it. > > > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > > issue, > > > > but > > > > it's a very real thing that we could do which I believe would be > > > > helpful. > > > > > > > > So, I propose: > > > > 1. We do not support any form of insecure signaling. We define the > > > > protocol > > > > to reject attempts to signal without TLS (or whatever). I'm > > assuming > > > > the > > > > protocols are TCP only. The overlay defines what credentials are > > needed > > > > (and supplies them). > > > > > > > > 2. We do not support any form of insecure media. It's always > > encrypted. > > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > > > 3. All devices that support audio support wideband audio. > > > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > > > 5. All devices support presence. We define a minimal set of > > presence > > > > characteristics that all devices publish. > > > > > > > > 6. We define a minimal feature set (something like unattended and > > > > attended > > > > transfer, call forward no answer, call forward busy, basic > > conferencing, > > > > ...) that every device supports the same way. > > > > > > > > 7. All devices work behind a given set of NAT configurations, given > > a > > > > specified set of ICE components (or whatever). > > > > > > > > 8. We define what constitutes a minimal configuration set; all of > > the > > > > above > > > > just work with this level of configuration (and credentials from an > > > > overlay). We of course define the configuration mechanism. I'm > > > > thinking > > > > that we do this by configuring the device with the credentials, and > > > > using > > > > the overlay to provide any other configuration (which could be > > > > influenced > > > > by, say, a website the overlay runs) automatically. > > > > > > > > All of these are designed to be minimum capabilities, but the idea > > is > > > > that > > > > ANY device, with credentials on an overlay, can expect to > > communicate > > > > with > > > > any other device on that overlay with ALL of the above. > > > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > > conformant" > > > > which means a device that does that. No protocol police, but the > > idea > > > > is > > > > that if you say you have a "p2psip conformant" device, it means all > > of > > > > the > > > > above. Perhaps we have a way to signal that. > > > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > > least? > > > > > > > > Brian > > > > > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > -- > > > > > > > > > ----------------------------------------------- > > > > > > > > > > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > > error, > > > please immediately reply to the sender and delete this information > > from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > > unlawful. > > > > > > > > > > > > Any views, opinions and content presented in this e-mail are solely > > those > > > of the author and may not represent those of Objectworld > > Communications > > > Corp. > > > > > > ----------------------------------------------- > > > > > > > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute non- > public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in > error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > > > > Any views, opinions and content presented in this e-mail are solely > those > > of the author and may not represent those of Objectworld Communications > > Corp. >=20 >=20 > ----------------------------------------------- >=20 >=20 >=20 > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. >=20 >=20 >=20 > Any views, opinions and content presented in this e-mail are solely those > of the author and may not represent those of Objectworld Communications > Corp. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_001_01C77778.761E7EA1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline RE: [P2PSIP] When we say "p2psip" what do we want "co= nsumers" tothink?

Inline:


-----Original Message-----
From: colin.pons@kpn.com [mailto:coli= n.pons@kpn.com]
Sent: Thu 05/04/2007 4:36 AM
To: br@brianrosen.net; Michael Slavitch; hsinnrei@adobe.com; p2psip@ietf.or= g
Subject: RE: [P2PSIP] When we say "p2psip" what do we want "= consumers" tothink?

Michael Slavitch wrote:
> Given the sieve nature of a DHT presence data does not create a flood<= BR> of
> data, a DHT itself contains the presence database, each node contains<= BR> only
> the data it needs,

The implicit assumption with this is that we are only concerned with
presence data within this DHT.

MNS: If that is assumed implicit lets remove that assumption. In a peer mod= el such data can exit or enter the DHT through a peer. The question is how = does it get to a peer and what is the entity that calculates 'presence'?

I agree with Brian that we will see multiple interworked DHTs and that
it will be the CALLERs choice of device. This brings up how and where to
aggregate the presence data and associated user policies (e.g. do I want
Work.Phil be routed to Phil.Mobile and when do I want to do this
respectively).

In addition, presence data may come from environments outside p2psip,
e.g. IPTV (I am watching my favorite sports team on TV and do not want
to be interrupted). Therefore, IMO DHT presence data should be able to
be federated with other presence data sources (including a presence
aggegration application).

MNS:  I fully agree, this is where things get useful, but how does it = get there and who makes decisions? Through an aggregation via one node, whe= re the aggregator makes decisions or via all nodes federated externally whe= re some external (C/S) system decides? If it's external that's fine but it = is a different animal. Some decisions are best suited to one and some to ot= hers. The question is, where is the application? In the peer fabric or in a= n outside entity?


-----Oorspronkelijk bericht-----
Van: Brian Rosen [mailto:br@brianrosen= .net]
Verzonden: woensdag 4 april 2007 23:16
Aan: 'Michael Slavitch'; 'Henry Sinnreich'; 'P2PSIP Mailing List'
Onderwerp: RE: [P2PSIP] When we say "p2psip" what do we want &quo= t;consumers"
tothink?

Ahh, the great "Service Provider of all beings" approach.

One nested overlay which is the service provider of choice for
Phil.Work,
Phil.Mobile and Phil.Home.

All sending ka-ching to that one great SP in the sky.

Please, no.

Consider this small tidbit:

You don't want your employer to choose the service provider for
phil.home.

Actually, it's not Phil.Work.  You have that backwards, it's Work.Phil= .
You will not give me a vCard that says Phil.Work.  You give me one tha= t
says
Work.Phil.  That's because your office creates it.  Actually, it = OWNS
it.
When you change employers, that becomes Work2.Phil

You could implement Phil.Work to give to your friends that always routes
to
WorkX.Phil of course, but that's not what you normally would hand out.
Your
employer wants you to be known as Work.Phil, and specifically, they want
to
control how that gets answered when you no longer work for them.

So, we can't have one nested DHT.  We need interoperable, interworked<= BR> DHTs
with some flexibilities.

Now, of course, it would be spectacularly great if Work.Phil could route
to
the same device that Phil did.  As long as the device could keep the contacts and URIs and features straight, that would be fabulous.

A much more interesting question is whether you EVER want to give out
Phil.Mobile and Phil.Home?  That is what we have today, but is that wh= at
we
want?  Do we want CALLER choice of device or CALLED choice of device?&= nbsp; I
think we want the latter, with the former being something very rare.

Brian

> -----Original Message-----
> From: Michael Slavitch [ma= ilto:slavitch@objectworld.com]
> Sent: Wednesday, April 04, 2007 4:54 PM
> To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List
> Subject: RE: [P2PSIP] When we say "p2psip" what do we want &= quot;consumers"
> tothink?
>
> I believe that good specs use MUST as much as possible and MAY only at=
> gunpoint, and even then only if the shooter is a good shot, so yes
common
> ground.
>
> Given the sieve nature of a DHT presence data does not create a flood<= BR> of
> data, a DHT itself contains the presence database, each node contains<= BR> only
> the data it needs, and with one writer per AOR and many readers
publishing
> presence is low-complexity DB stuff.  Having multiple instances o= f the
> same AOR is multi-writer multi-reader which is more complicated.
> 'Presense' in that case is the cumulative set of presence for the set<= BR> of
> AOR's for a single higher-level identity, ie a person.   My = workplace
may
> not want to know the cumulative presence of my cottage PC,  my ho= me
PC,
> my handheld along with my work devices, but my kid might, and so might=
> E911 for that matter.
>
> However this begs the question:  How do you aggregate a set of AO= R's
for a
> single abstract entity, ie me?  Is this set of AOR's another nest= ed
DHT, a
> DHT(me)?
>
> Might a nested recursive DHT that contains the cumulative set of
objects
> defined for a higher-level object (an organization or a person) be the=
> best way to aggregate AOR's and hence presence?  This would be an=
elegant
> way to get the status for nested hierarchies.
>
> Here is what I mean:
>
> A DHT contains all the AOR's of  Org.
> A DHT within this DHT contains all the AOR's of Org.Marketing.
> A DHT within this DHT contains all the AOR's of Org.Marketing.Phil
> Phil's   DHT contains all the objects of Phil.Home,  Ph= il.Mobile, and
> Phil.Work
>
> Or it could be just one AOR, for a P2P endpoint on Phil's cellphone. >
> This concept scales very well.    Each DHT itself has a= ttributes
including
> cumulative presence, which is calculated by the members of the DHT
based
> on internal black box rules, and is arbitrary enough to be flexible
> without forgetting some basic rules regarding AOR.
>
> Does this make sense,  shouldn't we be using the recursive nature= of
DHT
> to do this?
>
> Regards
>
> Michael
>
>
>
> Michael Slavitch
> Lead, Technology Initiatives
> slavitch@objectworld.com
>
>
>
>
>
>
> -----Original Message-----
> From: Brian Rosen [mailto:br@bria= nrosen.net]
> Sent: Wednesday, April 04, 2007 4:34 PM
> To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List'
> Subject: RE: [P2PSIP] When we say "p2psip" what do we want &= quot;consumers"
> tothink?
>
> Ahh, common ground.
>
> I do think we need to consider what the box roles are in p2psip in
> relation
> to presence.  What element is the "presence server"?&nb= sp; That element
routes
> calls to multiple devices.  Nice, but what element in p2psip does= that
> kind
> of routing?
>
> And, you are implying another layer of identifier.  Normally, whe= n we
talk
> about p2psip identifiers, we are assuming some form of AoR.  That= is
the
> address someone else uses to address communication to a peer.  Bu= t
what if
> you have multiple devices that join the overlay for the same AoR?
> Certainly
> allowed, but what is the unique address for such devices?  Who ge= ts
the
> call
> to the AoR and chooses the device?
>
> However, if every peer MUST publish presence state, and every peer
MUST
> have
> a presence client, we are getting somewhere you and I both want to get=
to.
>
> Brian
>
> > -----Original Message-----
> > From: Michael Slavitch [mailto:slavitch@objectworld.com]
> > Sent: Wednesday, April 04, 2007 4:15 PM
> > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List
> > Subject: RE: [P2PSIP] When we say "p2psip" what do we w= ant
"consumers"
> > tothink?
> >
> > Brian: I agree with you entirely.  The point is that a DHT&n= bsp; approach
> > eliminates the need for such exhausting server integration if
cumulative
> > presence and cumulative inputs from many disparate sources is
implicit
> > within a DHT.
> >
> > Regards
> >
> > Michael
> >
> >
> > Lead, Technology Initiatives
> > slavitch@objectworld.com
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:br= @brianrosen.net]
> > Sent: Wednesday, April 04, 2007 4:11 PM
> > To: Michael Slavitch; 'Henry Sinnreich'; 'P2PSIP Mailing List'
> > Subject: RE: [P2PSIP] When we say "p2psip" what do we w= ant
"consumers"
> > tothink?
> >
> > I was talking about using standards based presence systems to
control
> > how
> > calls are routed.  It's not really "call forwarding&quo= t;, it's "calls
from
> > this
> > class of callers when I'm in such-and-such presence state are rou= ted
to
> > that
> > device".  I'm not sure the end user would understand th= e difference,
but
> > the
> > implementation is quite a bit different.  We have standards = that
would
> > cover
> > the inter-box interfaces for such systems.  I think that tho= se
standards
> > would work for p2psip with zero to small changes.
> >
> > Was that what you were thinking Henry?  Do you see any need = for what
> > Michael
> > is talking about if it's not presence based routing?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Michael Slavitch [mailto:slavitch@objectworld.com]
> > > Sent: Wednesday, April 04, 2007 11:47 AM
> > > To: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List
> > > Subject: RE: [P2PSIP] When we say "p2psip" what do= we want
"consumers"
> > > tothink?
> > >
> > > " I do think that a rich presence system might obviate = the Call
> > forward
> > > issues.  I've never seen it done, so I've never been ab= le to try,
but
> > I
> > > could see how it might."
> > >
> > > It does.  For example,  I don't have call forward,= I have on my
> > personal
> > > agent right now (a shameless plug for my employer, sorry) 'a= lways
call
> > > forward for identities that I really don't want to talk to o= r
refuse
> > to
> > > identify themselves,  call forward when busy for most p= eople, call
> > forward
> > > for even fewer people when DND, and even when I set my prese= nce to
DND
> > > flash my call and interrupt me if it's a call from my kid's<= BR> school, my
> > > doctor, my wife, my boss,  and a few people on this lis= t, just not
too
> > > loud.'
> > >
> > > This is done using client-server SIP server talking to anoth= er
client-
> > > server SIP server and perhaps sometimes a third SIP server f= rom
> > another
> > > much larger vendor who doesn't care if they got things wrong= along
> > with a
> > > fourth SIP server that's a message store from two vendors an= d a
fifth
> > SIP
> > > server that might do 3rd party call control if our customers= buy
it,
> > > (whew!), all exchanging messages in a complex energetic mann= er
that
> > makes
> > > life harder for our developers than it has to be.
> > >
> > > The underlying mechanisms are an order of magnitude more com= plex
than
> > they
> > > have to be and I have proof that the amount of code needed i= f
standard
> > > techiques existed* to interact with 3rd parties from low-end=
endpoints
> > to
> > > big super-duper-supernodes** would be 1/10th the amount of c= ode
needed
> > to
> > > do the equivalent in the C/S world.   A 1.5M code-= line project
becomes
> > a
> > > 150K code-line project, which as any person who has ever put=
together
> > a
> > > project plan knows carries enormous implications for probabi= lity
of
> > > failure and success, the kind of products that result, and t= he
kind of
> > > sales needed to justify them.
> > >
> > > P2P enables long-tail economics in communications systems pr= oducts
in
> > the
> > > same way that you don't have to be a 3270 forms developer to=
develop
> > web
> > > content.  Vendors that participate in long-tail environ= ments such
as
> > eBay
> > > are wise to develop on such a platform.  There are othe= rs vendors,
> > > including employers of people reading this message, that are=
> > beneficiaries
> > > of long-tail markets.  Including mine.
> > >
> > > Regards
> > >
> > > Michael
> > >
> > > *Which is the only way to get people to bother as the pull i= n the
C/S
> > > direction is very hard.
> > >
> > > **Which is really what a 'server' is, albeit with a much les= silly
> > name.
> > >
> > >
> > >
> > > Michael Slavitch
> > > Lead, Technology Initiatives
> > > slavitch@objectworld.com
> > >
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Brian Rosen [mail= to:br@brianrosen.net]
> > > Sent: Wednesday, April 04, 2007 11:25 AM
> > > To: 'Henry Sinnreich'; 'P2PSIP Mailing List'
> > > Subject: RE: [P2PSIP] When we say "p2psip" what do= we want
"consumers"
> > > tothink?
> > >
> > > I REALLY wish I could transfer a call from Skype to my mobil= e and
vice
> > > versa.
> > >
> > > I wish I could transfer it to my hardline when, for whatever=
reason,
> > the
> > > bandwidth gods are not smiling on me.
> > >
> > > And then there is conferencing.  Depending on exactly h= ow
conferencing
> > is
> > > implemented, you may need to transfer to a bridge.
> > >
> > > I really think transfer is an absolute minimal requirement.<= BR> > > >
> > > I do think that a rich presence system might obviate the Cal= l
forward
> > > issues.  I've never seen it done, so I've never been ab= le to try,
but
> > I
> > > could see how it might.
> > >
> > > Conferencing is something that just has to work.
> > >
> > > We need to go down the list of service examples and decide w= hich
ones
> > are
> > > MUST HAVE.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
> > > > Sent: Wednesday, April 04, 2007 11:14 AM
> > > > To: Brian Rosen; P2PSIP Mailing List
> > > > Subject: RE: [P2PSIP] When we say "p2psip" wh= at do we want
> > "consumers"
> > > to
> > > > think?
> > > >
> > > > These are good points and actually should copied to the= SIPPING
list
> > > > since they apply to the simple SIP Toolkit :-)
> > > >
> > > > Excellent items are these here:
> > > >
> > > > >3. All devices that support audio support wideband = audio.
> > > >
> > > > >4. All devices support text (IM and real time inter= active).
> > > >
> > > > >5. All devices support presence.  We define a = minimal set of
> > presence
> > > > >characteristics that all devices publish.
> > > >
> > > > I take exception here only to the legacy from the voice= -only
PBX:
> > > >
> > > > >6. We define a minimal feature set (something like = unattended
and
> > > > >attended
> > > > >transfer, call forward no answer, call forward busy= , basic
> > > > conferencing,
> > > > >...) that every device supports the same way.
> > > >
> > > > Let's first look how presence and IM may affect user be= havior
and if
> > > > this cannot be a special endpoint app, say for receptio= nists or
> > agents.
> > > >
> > > > > This is pretty much what Skype does
> > > >
> > > > I am using Skype now for several years for most long di= stance
calls
> > and
> > > > for conferences, but have never transferred a call. May= be my
> > secretary
> > > > would transfer a call, but I don't have one :-)
> > > > Nor do 99.99% of consumers or most employees any more. = One can
IM
> > the
> > > > number...
> > > >
> > > > Thanks, Henry
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Wednesday, April 04, 2007 9:49 AM
> > > > To: 'P2PSIP Mailing List'
> > > > Subject: [P2PSIP] When we say "p2psip" what d= o we want
"consumers"
> > to
> > > > think?
> > > >
> > > > One of the things I think we blew big time on sip was t= hat we
didn't
> > > > require
> > > > some fundamental things in every sip device to differen= tiate
them
> > from
> > > > existing technology.  We have an opportunity to fi= x that with
> > p2psip,
> > > > and I
> > > > think we should do it.
> > > >
> > > > Now, admittedly, what I'm talking about is somewhat a "marketing"
> > issue,
> > > > but
> > > > it's a very real thing that we could do which I believe= would be
> > > > helpful.
> > > >
> > > > So, I propose:
> > > > 1. We do not support any form of insecure signaling.&nb= sp; We define
the
> > > > protocol
> > > > to reject attempts to signal without TLS (or whatever).=   I'm
> > assuming
> > > > the
> > > > protocols are TCP only.  The overlay defines what = credentials
are
> > needed
> > > > (and supplies them).
> > > >
> > > > 2. We do not support any form of insecure media.  = It's always
> > encrypted.
> > > > This is the tough one, especially if we say we support = SIP UAs.
> > > >
> > > > 3. All devices that support audio support wideband audi= o.
> > > >
> > > > 4. All devices support text (IM and real time interacti= ve).
> > > >
> > > > 5. All devices support presence.  We define a mini= mal set of
> > presence
> > > > characteristics that all devices publish.
> > > >
> > > > 6. We define a minimal feature set (something like unat= tended
and
> > > > attended
> > > > transfer, call forward no answer, call forward busy, ba= sic
> > conferencing,
> > > > ...) that every device supports the same way.
> > > >
> > > > 7. All devices work behind a given set of NAT configura= tions,
given
> > a
> > > > specified set of ICE components (or whatever).
> > > >
> > > > 8. We define what constitutes a minimal configuration s= et; all
of
> > the
> > > > above
> > > > just work with this level of configuration (and credent= ials from
an
> > > > overlay).  We of course define the configuration m= echanism.  I'm
> > > > thinking
> > > > that we do this by configuring the device with the cred= entials,
and
> > > > using
> > > > the overlay to provide any other configuration (which c= ould be
> > > > influenced
> > > > by, say, a website the overlay runs) automatically.
> > > >
> > > > All of these are designed to be minimum capabilities, b= ut the
idea
> > is
> > > > that
> > > > ANY device, with credentials on an overlay, can expect = to
> > communicate
> > > > with
> > > > any other device on that overlay with ALL of the above.=
> > > >
> > > > Finally, I propose we invent a phrase, something like &= quot;p2psip
> > > > conformant"
> > > > which means a device that does that.  No protocol = police, but
the
> > idea
> > > > is
> > > > that if you say you have a "p2psip conformant"= ; device, it means
all
> > of
> > > > the
> > > > above.  Perhaps we have a way to signal that.
> > > >
> > > > This is pretty much what Skype does.  Why should w= e not do that,
at
> > > > least?
> > > >
> > > > Brian
> > > >
> > > >
> > > > _______________________________________________
> > > > P2PSIP mailing list
> > > > P2PSIP@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > >
> > >
> > > _______________________________________________
> > > P2PSIP mailing list
> > > P2PSIP@ietf.org
> > > ht= tps://www1.ietf.org/mailman/listinfo/p2psip
> > >
> > >
> > > --
> > >
> > >
> > > -----------------------------------------------
> > >
> > >
> > >
> > > This transmission (including any attachments) may contain
confidential
> > > information, privileged material (including material protect= ed by
the
> > > solicitor-client or other applicable privileges), or constit= ute
> > non-public
> > > information. Any use of this information by anyone other tha= n the
> > intended
> > > recipient is prohibited. If you have received this transmiss= ion in
> > error,
> > > please immediately reply to the sender and delete this infor= mation
> > from
> > > your system. Use, dissemination, distribution, or reproducti= on of
this
> > > transmission by unintended recipients is not authorized and = may be
> > > unlawful.
> > >
> > >
> > >
> > > Any views, opinions and content presented in this e-mail are=
solely
> > those
> > > of the author and may not represent those of Objectworld
> > Communications
> > > Corp.
> >
> >
> > -----------------------------------------------
> >
> >
> >
> > This transmission (including any attachments) may contain
confidential
> > information, privileged material (including material protected by=
the
> > solicitor-client or other applicable privileges), or constitute n= on-
> public
> > information. Any use of this information by anyone other than the=
> intended
> > recipient is prohibited. If you have received this transmission i= n
> error,
> > please immediately reply to the sender and delete this informatio= n
from
> > your system. Use, dissemination, distribution, or reproduction of=
this
> > transmission by unintended recipients is not authorized and may b= e
> > unlawful.
> >
> >
> >
> > Any views, opinions and content presented in this e-mail are sole= ly
> those
> > of the author and may not represent those of Objectworld
Communications
> > Corp.
>
>
> -----------------------------------------------
>
>
>
> This transmission (including any attachments) may contain confidential=
> information, privileged material (including material protected by the<= BR> > solicitor-client or other applicable privileges), or constitute
non-public
> information. Any use of this information by anyone other than the
intended
> recipient is prohibited. If you have received this transmission in
error,
> please immediately reply to the sender and delete this information
from
> your system. Use, dissemination, distribution, or reproduction of this=
> transmission by unintended recipients is not authorized and may be
> unlawful.
>
>
>
> Any views, opinions and content presented in this e-mail are solely
those
> of the author and may not represent those of Objectworld
Communications
> Corp.


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf= .org/mailman/listinfo/p2psip


--
BEGIN-ANTISPAM-VOTING-LINKS
------------------------------------------------------


Teach CanIt if this mail (ID 658818) is spam:

Spam:       

Forget vote:
------------------------------------------------------
END-ANTISPAM-VOTING-LINKS

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D = ------_=_NextPart_001_01C77778.761E7EA1-- --===============1457437734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1457437734==-- From p2psip-bounces@ietf.org Thu Apr 05 08:25:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZR1o-0004Al-Tj; Thu, 05 Apr 2007 08:25:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZR1l-00045R-B4 for p2psip@ietf.org; Thu, 05 Apr 2007 08:25:22 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZR1j-0006cR-Rk for p2psip@ietf.org; Thu, 05 Apr 2007 08:25:21 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l35CPEPf031844 for ; Thu, 5 Apr 2007 08:25:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Apr 2007 08:25:14 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C5160AE5@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd3QjhpO54yqIeoTd25OD+bZgRAswANkzcp References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com><1fb601c776fb$fb96a050$81238182@cis.neustar.com><20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com><20d2bdfb0704041827w60cf9d24sa3c4fc29be30e8c@mail.gmail.com> <013501c77724$d5b97e60$65500a0a@ronin> <4E2DC1ACE541B94A946B8D8657E372C5160AE3@photon.objectworld.com> <46148788.5080207@softarmor.com> From: "Michael Slavitch" To: "Dean Willis" X-Spam-Score: 1.30 (*) [Tag at 20.00] HTML_MESSAGE, J_CHICKENPOX_31, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314176079==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1314176079== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7777D.76448227" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7777D.76448227 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It had better work over the IETF network or the entire NOC should get fired= , and the same goes for nice hotels and academic networks running on Intern= et II fiber. That largely summarizes the problem with assumptions of the I= ETF.=20=20 What you are saying is that P2PSIP can displace a CSSIP that largely depend= s on outside well-ordered carefully provisioned detailed engineering of ser= vers and clients, an OAM&P system that lies completely out of the control o= f the SIP protocol with a P2PSIP that largely depends on and assumes an out= side well-ordered carefully provisioned detailed engineering of networks, b= ackbones and demarc nodes that lies completely out of the control of the P2= P protocol. For me, that's a show stopper. I thought that one of the use ca= ses in ad-hoc networks is Katrina-like emergencies, where Bronx At 3 AM is = utopia. If one of the goals of P2PSIP protocol is resilience you have to pr= ice in resilience into the protocol and not assume it lies elsewhere. ICE has improved, STUN will be needed in any case, fragmentation is somethi= ng that is more efficiently done at a higher layer, so the argument for TCP= and only TCP has no merit. If the SDP of P2PSIP is going to be so fat and= complex as to require protocol-level fragments that cannot be reassembled = at an application layer we are headed down the IMS path before having an em= pire to defend.=20=20=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thu 05/04/2007 1:22 AM To: Michael Slavitch Cc: Eric Cooper; Bruce Lowekamp; Henning Schulzrinne; P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" toth= ink? =20 Michael Slavitch wrote: >=20 > My worry is not the CPU, my worry is the reality-based Internet I have=20 > to deal with, which is like the Bronx at 3am. I've been doing my daily telephony over a VPN built using IPSEC over TCP=20 for the last couple of months, including hotels and the IETF network,=20 and it has worked just fine. It even works moderately well when running=20 over GPRS EDGE using a phone as a "bluetooth modem". -- Dean -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_001_01C7777D.76448227 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline RE: [P2PSIP] When we say "p2psip" what do we want "co= nsumers" tothink?

It had better work over the IETF network or the entire NO= C should get fired, and the same goes for nice hotels and academic networks= running on Internet II fiber.  That largely summarizes the problem wi= th assumptions of the IETF. 

What you are saying is that P2PSIP can displace a CSSIP that largely depend= s on outside well-ordered carefully provisioned detailed engineering of ser= vers and clients, an OAM&P system that lies completely out of the contr= ol of the SIP protocol with a P2PSIP that largely depends on and assumes an= outside well-ordered carefully provisioned detailed engineering of network= s, backbones and demarc nodes that lies completely out of the control of th= e P2P protocol. For me, that's a show stopper. I thought that one of the us= e cases in ad-hoc networks is Katrina-like emergencies, where Bronx At 3 AM= is utopia. If one of the goals of P2PSIP protocol is resilience you have t= o price in resilience into the protocol and not assume it lies elsewhere.
ICE has improved, STUN will be needed in any case, fragmentation is somethi= ng that is more efficiently done at a higher layer, so the argument for TCP= and only TCP has no merit.  If the SDP of P2PSIP is going to be so fa= t and complex as to require protocol-level fragments that cannot be reassem= bled at an application layer we are headed down the IMS path before having = an empire to defend.  



-----Original Message-----
From: Dean Willis [mailto:dean= .willis@softarmor.com]
Sent: Thu 05/04/2007 1:22 AM
To: Michael Slavitch
Cc: Eric Cooper; Bruce Lowekamp; Henning Schulzrinne; P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "= consumers" tothink?

Michael Slavitch wrote:
>
> My worry is not the CPU, my worry is the reality-based Internet I have=
> to deal with, which is like the Bronx at 3am.

I've been doing my daily telephony over a VPN built using IPSEC over TCP
for the last couple of months, including hotels and the IETF network,
and it has worked just fine. It even works moderately well when running
over GPRS EDGE using a phone as a "bluetooth modem".

--
Dean

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D = ------_=_NextPart_001_01C7777D.76448227-- --===============1314176079== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1314176079==-- From p2psip-bounces@ietf.org Thu Apr 05 08:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRNl-0000AS-LM; Thu, 05 Apr 2007 08:48:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRNk-0000AN-VH for p2psip@ietf.org; Thu, 05 Apr 2007 08:48:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRNh-0001B0-Iw for p2psip@ietf.org; Thu, 05 Apr 2007 08:48:04 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2007 05:48:01 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l35Cm1Aa020818; Thu, 5 Apr 2007 05:48:01 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l35ClMAi017525; Thu, 5 Apr 2007 12:48:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 08:47:54 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 08:47:54 -0400 Message-ID: <4614EFF9.6030702@cisco.com> Date: Thu, 05 Apr 2007 08:47:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario References: <1fcd01c77705$94328870$81238182@cis.neustar.com> <16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com> In-Reply-To: <16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2007 12:47:54.0089 (UTC) FILETIME=[A0D08D90:01C77780] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2504; t=1175777281; x=1176641281; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[P2Prg]=20RE=3A=20[Sipping]=20Simp le=20SIP=20usage=20scenario |Sender:=20; bh=MITk6xR/6e3yycKuFwzOLN4tgh7/s7j/GMbg3DYRq6U=; b=mq6gfIU2z6CWtcvp5FP3zsOpD4/LLQ81GUUGaJO7PRJ4CXTIzP7fXZqT+ktO6Swg58xvz1/T WEvZrs8kbhnsIlQo72aEahIZ30Qml7ZSj0hokJO5cSkdLzsMOjOPafgr; Authentication-Results: sj-dkim-6; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Some interesting points Dean. These are starting to help. Note that I am not "against" p2psip - I am still just a skeptic waiting to be convinced that this is not just the latest silver bullet. Some comments inline. Paul Dean Willis wrote: >>> Now factor in business-to-business and business-to-consumer calling >>> without TDM trunks. >> Ah, well, with a service provider or without? If the latter, easy for >> the >> enterprise. If the former, pretty near impossible today for business to >> consumer, getting more possible with business to business, but not yet >> any >> enterprise purchasing push. > > Without, of course. Is it really possible to eliminate SPs (loosely defined) from this market? Almost every customer will want to make calls to/from the PSTN. Either each customer has their own TDM interconnect or else they become the customer of somebody. Since TDM calls and phone numbers cost something I doubt this can be something that will be provided for free, so somebody ends up being a service provider. (I.e. Skype is a SP for TDM interconnect.) Direct business-to-business and business-to-consumer calling without TDM doesn't necessarily require TDM trunks. But unless everybody is on the same p2p network it will require *something*. If addressing is via sip URIs then all it really requires is DNS and IP connectivity, which is perhaps what you mean. If the goal is connectivity via phone number addressing then it will still require ENUM. > Here's another scenario where the dynamic routing of P2P makes sense. > > Assume a conventional IMS with 5 million uses and 50 S-CSCF nodes. Each > user is dynamically assigned to an S-CSCF at registration time. A user > binding is then placed into the HSS to map from user to S-CSCF. The HSS > is hard to manage, scale, replicate, etc. Every phone call requires a > couple of dips into the HSS to figure out the routing. > > Replace HSS with P2PSIP. The originating side S-CSCF/peer transforms the > R-URI into a resource ID. One DHT hash later, we have the peer ID of the > terminating S-CSCF. Routing follows. I think you just mixed up the domain of the caller with the domain of the callee. Fine if they are the same. Not fine if they are different. I think we can safely assume that even if p2p is embraced for IMS, it won't mean that all IMS providers share a single DHT. So it is just like the business-to-business discussion above. Paul _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 09:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRku-0006wU-IK; Thu, 05 Apr 2007 09:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZRkt-0006wJ-SG for p2psip@ietf.org; Thu, 05 Apr 2007 09:11:59 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZRko-0004fq-9P for p2psip@ietf.org; Thu, 05 Apr 2007 09:11:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZRkH-0004H0-QL; Thu, 05 Apr 2007 08:11:22 -0500 From: "Brian Rosen" To: "'Henry Sinnreich'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Thu, 5 Apr 2007 09:11:49 -0400 Message-ID: <20df01c77783$fac84b00$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF4D@namail5.corp.adobe.com> Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAXtFAAABa7UNA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org And that is how generic SIP got to be associated with a PSTN lookalike that doesn't work as well, but maybe costs less. I liken this to security "MUST IMPLEMENT" choices we make. We don't do them because the protocol depends on them to work, and it's definitely a feature. It's a value judgment; we want all implementations to have certain security characteristics because we see the consequences of not having those features. The user is free to not use the feature, but if she wants to, she can. MUST IMPLEMENT is as ignorable as any other words in an RFC. What I'm proposing is the same. What I want are interoperable implementations. To do that, I need one implementation to know that it, for example, tries to transfer, the other end will be able to do that. If it offers whatever wideband codec we choose for audio, the other end will be able to accept. If it subscribes to presence for the AoR it has, assuming permission is granted, it will get it, and certain information will be available to it (again, assuming permissions). I want more that "basic call" to work for all implementations (at least those designed to work in a telephony like environment). This is p2psip. SIP is a multimedia session establishment protocol. P2psip is a multimedia session establishment protocol. I'm not sure what you are implying with "my social network", but if it's not multimedia session establishment, then p2psip is not solving your problem. Brian > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, April 04, 2007 10:13 PM > To: Brian Rosen; P2PSIP Mailing List > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? > > > we didn't require some fundamental things in every sip device to > > differentiate them from existing technology > > On 2nd thought, "we" MUST NOT require any features, only the SIP > rendezvous service. > > Features are the business of the endpoint application developers, not of > standards bodies, nor of the FCC or the government. > > The users will select the products with the features they want. > Now what features do I want for my social network? > It's no business of the standards folks to make this decision. > > Thanks, Henry > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, April 04, 2007 9:49 AM > To: 'P2PSIP Mailing List' > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > think? > > One of the things I think we blew big time on sip was that we didn't > require > some fundamental things in every sip device to differentiate them from > existing technology. We have an opportunity to fix that with p2psip, > and I > think we should do it. > > Now, admittedly, what I'm talking about is somewhat a "marketing" issue, > but > it's a very real thing that we could do which I believe would be > helpful. > > So, I propose: > 1. We do not support any form of insecure signaling. We define the > protocol > to reject attempts to signal without TLS (or whatever). I'm assuming > the > protocols are TCP only. The overlay defines what credentials are needed > (and supplies them). > > 2. We do not support any form of insecure media. It's always encrypted. > This is the tough one, especially if we say we support SIP UAs. > > 3. All devices that support audio support wideband audio. > > 4. All devices support text (IM and real time interactive). > > 5. All devices support presence. We define a minimal set of presence > characteristics that all devices publish. > > 6. We define a minimal feature set (something like unattended and > attended > transfer, call forward no answer, call forward busy, basic conferencing, > ...) that every device supports the same way. > > 7. All devices work behind a given set of NAT configurations, given a > specified set of ICE components (or whatever). > > 8. We define what constitutes a minimal configuration set; all of the > above > just work with this level of configuration (and credentials from an > overlay). We of course define the configuration mechanism. I'm > thinking > that we do this by configuring the device with the credentials, and > using > the overlay to provide any other configuration (which could be > influenced > by, say, a website the overlay runs) automatically. > > All of these are designed to be minimum capabilities, but the idea is > that > ANY device, with credentials on an overlay, can expect to communicate > with > any other device on that overlay with ALL of the above. > > Finally, I propose we invent a phrase, something like "p2psip > conformant" > which means a device that does that. No protocol police, but the idea > is > that if you say you have a "p2psip conformant" device, it means all of > the > above. Perhaps we have a way to signal that. > > This is pretty much what Skype does. Why should we not do that, at > least? > > Brian > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 09:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSKq-0001gt-Ia; Thu, 05 Apr 2007 09:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSKo-0001gn-OT for p2psip@ietf.org; Thu, 05 Apr 2007 09:49:06 -0400 Received: from bay0-omc2-s4.bay0.hotmail.com ([65.54.246.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSKl-0001u0-66 for p2psip@ietf.org; Thu, 05 Apr 2007 09:49:06 -0400 Received: from bayc1-pasmtp02.bayc1.hotmail.com ([65.54.191.162]) by bay0-omc2-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 5 Apr 2007 06:49:02 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp02.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 06:49:02 -0700 Message-ID: <01c201c77789$299b58a0$65500a0a@ronin> From: "Eric Cooper" To: "Brian Rosen" , "'Henry Sinnreich'" , "'P2PSIP Mailing List'" References: <20df01c77783$fac84b00$81238182@cis.neustar.com> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 09:48:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 05 Apr 2007 13:49:02.0285 (UTC) FILETIME=[2B3AD7D0:01C77789] X-Spam-Score: 2.1 (++) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I thought bliss was solving the problem you're describing. Eric. ----- Original Message -----=20 From: "Brian Rosen" To: "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" = Sent: Thursday, April 05, 2007 9:11 AM Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" = tothink? > And that is how generic SIP got to be associated with a PSTN lookalike = that > doesn't work as well, but maybe costs less.=20 >=20 > I liken this to security "MUST IMPLEMENT" choices we make. We don't = do them > because the protocol depends on them to work, and it's definitely a = feature. > It's a value judgment; we want all implementations to have certain = security > characteristics because we see the consequences of not having those > features. The user is free to not use the feature, but if she wants = to, she > can. MUST IMPLEMENT is as ignorable as any other words in an RFC. = What > I'm proposing is the same. >=20 > What I want are interoperable implementations. To do that, I need one > implementation to know that it, for example, tries to transfer, the = other > end will be able to do that. If it offers whatever wideband codec we = choose > for audio, the other end will be able to accept. If it subscribes to > presence for the AoR it has, assuming permission is granted, it will = get it, > and certain information will be available to it (again, assuming > permissions). I want more that "basic call" to work for all = implementations > (at least those designed to work in a telephony like environment). >=20 > This is p2psip. SIP is a multimedia session establishment protocol. = P2psip > is a multimedia session establishment protocol. I'm not sure what you = are > implying with "my social network", but if it's not multimedia session > establishment, then p2psip is not solving your problem. >=20 > Brian=20 >=20 >> -----Original Message----- >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, April 04, 2007 10:13 PM >> To: Brian Rosen; P2PSIP Mailing List >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want = "consumers" to >> think? >>=20 >> > we didn't require some fundamental things in every sip device to >> > differentiate them from existing technology >>=20 >> On 2nd thought, "we" MUST NOT require any features, only the SIP >> rendezvous service. >>=20 >> Features are the business of the endpoint application developers, not = of >> standards bodies, nor of the FCC or the government. >>=20 >> The users will select the products with the features they want. >> Now what features do I want for my social network? >> It's no business of the standards folks to make this decision. >>=20 >> Thanks, Henry >>=20 >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Wednesday, April 04, 2007 9:49 AM >> To: 'P2PSIP Mailing List' >> Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to >> think? >>=20 >> One of the things I think we blew big time on sip was that we didn't >> require >> some fundamental things in every sip device to differentiate them = from >> existing technology. We have an opportunity to fix that with p2psip, >> and I >> think we should do it. >>=20 >> Now, admittedly, what I'm talking about is somewhat a "marketing" = issue, >> but >> it's a very real thing that we could do which I believe would be >> helpful. >>=20 >> So, I propose: >> 1. We do not support any form of insecure signaling. We define the >> protocol >> to reject attempts to signal without TLS (or whatever). I'm assuming >> the >> protocols are TCP only. The overlay defines what credentials are = needed >> (and supplies them). >>=20 >> 2. We do not support any form of insecure media. It's always = encrypted. >> This is the tough one, especially if we say we support SIP UAs. >>=20 >> 3. All devices that support audio support wideband audio. >>=20 >> 4. All devices support text (IM and real time interactive). >>=20 >> 5. All devices support presence. We define a minimal set of presence >> characteristics that all devices publish. >>=20 >> 6. We define a minimal feature set (something like unattended and >> attended >> transfer, call forward no answer, call forward busy, basic = conferencing, >> ...) that every device supports the same way. >>=20 >> 7. All devices work behind a given set of NAT configurations, given a >> specified set of ICE components (or whatever). >>=20 >> 8. We define what constitutes a minimal configuration set; all of the >> above >> just work with this level of configuration (and credentials from an >> overlay). We of course define the configuration mechanism. I'm >> thinking >> that we do this by configuring the device with the credentials, and >> using >> the overlay to provide any other configuration (which could be >> influenced >> by, say, a website the overlay runs) automatically. >>=20 >> All of these are designed to be minimum capabilities, but the idea is >> that >> ANY device, with credentials on an overlay, can expect to communicate >> with >> any other device on that overlay with ALL of the above. >>=20 >> Finally, I propose we invent a phrase, something like "p2psip >> conformant" >> which means a device that does that. No protocol police, but the = idea >> is >> that if you say you have a "p2psip conformant" device, it means all = of >> the >> above. Perhaps we have a way to signal that. >>=20 >> This is pretty much what Skype does. Why should we not do that, at >> least? >>=20 >> Brian >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 09:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSSG-0001tH-95; Thu, 05 Apr 2007 09:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSSE-0001t7-Pw for p2psip@ietf.org; Thu, 05 Apr 2007 09:56:46 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSSE-0002qo-BJ for p2psip@ietf.org; Thu, 05 Apr 2007 09:56:46 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HZSRh-0007QN-Bz; Thu, 05 Apr 2007 08:56:13 -0500 From: "Brian Rosen" To: "'Eric Cooper'" , "'Henry Sinnreich'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 09:56:41 -0400 Message-ID: <20f201c7778a$3f156f30$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <01c201c77789$299b58a0$65500a0a@ronin> Thread-Index: Acd3iRpe/qjNp67tR6uXY1CLxkRgIAAAPxLQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org No. Bliss wants to make implementation of some complex features more uniform. An example is call park. Brian > -----Original Message----- > From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] > Sent: Thursday, April 05, 2007 9:49 AM > To: Brian Rosen; 'Henry Sinnreich'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > I thought bliss was solving the problem you're describing. > > Eric. > > ----- Original Message ----- > From: "Brian Rosen" > To: "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" > > Sent: Thursday, April 05, 2007 9:11 AM > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > tothink? > > > > And that is how generic SIP got to be associated with a PSTN lookalike > that > > doesn't work as well, but maybe costs less. > > > > I liken this to security "MUST IMPLEMENT" choices we make. We don't do > them > > because the protocol depends on them to work, and it's definitely a > feature. > > It's a value judgment; we want all implementations to have certain > security > > characteristics because we see the consequences of not having those > > features. The user is free to not use the feature, but if she wants to, > she > > can. MUST IMPLEMENT is as ignorable as any other words in an RFC. > What > > I'm proposing is the same. > > > > What I want are interoperable implementations. To do that, I need one > > implementation to know that it, for example, tries to transfer, the > other > > end will be able to do that. If it offers whatever wideband codec we > choose > > for audio, the other end will be able to accept. If it subscribes to > > presence for the AoR it has, assuming permission is granted, it will get > it, > > and certain information will be available to it (again, assuming > > permissions). I want more that "basic call" to work for all > implementations > > (at least those designed to work in a telephony like environment). > > > > This is p2psip. SIP is a multimedia session establishment protocol. > P2psip > > is a multimedia session establishment protocol. I'm not sure what you > are > > implying with "my social network", but if it's not multimedia session > > establishment, then p2psip is not solving your problem. > > > > Brian > > > >> -----Original Message----- > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, April 04, 2007 10:13 PM > >> To: Brian Rosen; P2PSIP Mailing List > >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > to > >> think? > >> > >> > we didn't require some fundamental things in every sip device to > >> > differentiate them from existing technology > >> > >> On 2nd thought, "we" MUST NOT require any features, only the SIP > >> rendezvous service. > >> > >> Features are the business of the endpoint application developers, not > of > >> standards bodies, nor of the FCC or the government. > >> > >> The users will select the products with the features they want. > >> Now what features do I want for my social network? > >> It's no business of the standards folks to make this decision. > >> > >> Thanks, Henry > >> > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Wednesday, April 04, 2007 9:49 AM > >> To: 'P2PSIP Mailing List' > >> Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > >> think? > >> > >> One of the things I think we blew big time on sip was that we didn't > >> require > >> some fundamental things in every sip device to differentiate them from > >> existing technology. We have an opportunity to fix that with p2psip, > >> and I > >> think we should do it. > >> > >> Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > >> but > >> it's a very real thing that we could do which I believe would be > >> helpful. > >> > >> So, I propose: > >> 1. We do not support any form of insecure signaling. We define the > >> protocol > >> to reject attempts to signal without TLS (or whatever). I'm assuming > >> the > >> protocols are TCP only. The overlay defines what credentials are > needed > >> (and supplies them). > >> > >> 2. We do not support any form of insecure media. It's always > encrypted. > >> This is the tough one, especially if we say we support SIP UAs. > >> > >> 3. All devices that support audio support wideband audio. > >> > >> 4. All devices support text (IM and real time interactive). > >> > >> 5. All devices support presence. We define a minimal set of presence > >> characteristics that all devices publish. > >> > >> 6. We define a minimal feature set (something like unattended and > >> attended > >> transfer, call forward no answer, call forward busy, basic > conferencing, > >> ...) that every device supports the same way. > >> > >> 7. All devices work behind a given set of NAT configurations, given a > >> specified set of ICE components (or whatever). > >> > >> 8. We define what constitutes a minimal configuration set; all of the > >> above > >> just work with this level of configuration (and credentials from an > >> overlay). We of course define the configuration mechanism. I'm > >> thinking > >> that we do this by configuring the device with the credentials, and > >> using > >> the overlay to provide any other configuration (which could be > >> influenced > >> by, say, a website the overlay runs) automatically. > >> > >> All of these are designed to be minimum capabilities, but the idea is > >> that > >> ANY device, with credentials on an overlay, can expect to communicate > >> with > >> any other device on that overlay with ALL of the above. > >> > >> Finally, I propose we invent a phrase, something like "p2psip > >> conformant" > >> which means a device that does that. No protocol police, but the idea > >> is > >> that if you say you have a "p2psip conformant" device, it means all of > >> the > >> above. Perhaps we have a way to signal that. > >> > >> This is pretty much what Skype does. Why should we not do that, at > >> least? > >> > >> Brian > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 10:28:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSxI-0002Hu-Kx; Thu, 05 Apr 2007 10:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSxH-0002HC-2S for p2psip@ietf.org; Thu, 05 Apr 2007 10:28:51 -0400 Received: from bay0-omc3-s27.bay0.hotmail.com ([65.54.246.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSxE-0007cw-G9 for p2psip@ietf.org; Thu, 05 Apr 2007 10:28:51 -0400 Received: from bayc1-pasmtp04.bayc1.hotmail.com ([65.54.191.164]) by bay0-omc3-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 5 Apr 2007 07:28:47 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from ronin ([216.13.42.68]) by bayc1-pasmtp04.bayc1.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 07:28:47 -0700 Message-ID: <01d601c7778e$b72d7720$65500a0a@ronin> From: "Eric Cooper" To: "Brian Rosen" , "'Henry Sinnreich'" , "'P2PSIP Mailing List'" References: <20f201c7778a$3f156f30$81238182@cis.neustar.com> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 10:28:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 05 Apr 2007 14:28:47.0278 (UTC) FILETIME=[B8CBE4E0:01C7778E] X-Spam-Score: 2.1 (++) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org So bliss isn't trying. I guess sipping must've failed if we still don't = have interoperable transfers. What will we do differently? I thought P2PSIP was a distributed location service for SIP and a = NAT-penetrating transport mechanism for SIP. I don't think it's a = multimedia session establishment protocol. I think it's a bunch of = primitives that reliably accomplish put/get/send using the resources of = a whole bunch of nodes. I don't see it as defining a 'profile' for what = codecs and methods SIP UAs should support. There's consensus in the group for supporting vanilla SIP UAs, but if = all those UAs can't already interoperate w.r.t. call transfer do you = propose to have the proxy peer (or GW or whatever) interwork their = broken transfers to the P2PSIP transfer mechanism? I'm with Henry. I think we should stay out of this game. Eric. ----- Original Message -----=20 From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" = ; "'P2PSIP Mailing List'" Sent: Thursday, April 05, 2007 9:56 AM Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" = tothink? > No. Bliss wants to make implementation of some complex features more > uniform. An example is call park. >=20 > Brian >=20 >> -----Original Message----- >> From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] >> Sent: Thursday, April 05, 2007 9:49 AM >> To: Brian Rosen; 'Henry Sinnreich'; 'P2PSIP Mailing List' >> Subject: Re: [P2PSIP] When we say "p2psip" what do we want = "consumers" >> tothink? >>=20 >> I thought bliss was solving the problem you're describing. >>=20 >> Eric. >>=20 >> ----- Original Message ----- >> From: "Brian Rosen" >> To: "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" >> >> Sent: Thursday, April 05, 2007 9:11 AM >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want = "consumers" >> tothink? >>=20 >>=20 >> > And that is how generic SIP got to be associated with a PSTN = lookalike >> that >> > doesn't work as well, but maybe costs less. >> > >> > I liken this to security "MUST IMPLEMENT" choices we make. We = don't do >> them >> > because the protocol depends on them to work, and it's definitely a >> feature. >> > It's a value judgment; we want all implementations to have certain >> security >> > characteristics because we see the consequences of not having those >> > features. The user is free to not use the feature, but if she = wants to, >> she >> > can. MUST IMPLEMENT is as ignorable as any other words in an RFC. >> What >> > I'm proposing is the same. >> > >> > What I want are interoperable implementations. To do that, I need = one >> > implementation to know that it, for example, tries to transfer, the >> other >> > end will be able to do that. If it offers whatever wideband codec = we >> choose >> > for audio, the other end will be able to accept. If it subscribes = to >> > presence for the AoR it has, assuming permission is granted, it = will get >> it, >> > and certain information will be available to it (again, assuming >> > permissions). I want more that "basic call" to work for all >> implementations >> > (at least those designed to work in a telephony like environment). >> > >> > This is p2psip. SIP is a multimedia session establishment = protocol. >> P2psip >> > is a multimedia session establishment protocol. I'm not sure what = you >> are >> > implying with "my social network", but if it's not multimedia = session >> > establishment, then p2psip is not solving your problem. >> > >> > Brian >> > >> >> -----Original Message----- >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> >> Sent: Wednesday, April 04, 2007 10:13 PM >> >> To: Brian Rosen; P2PSIP Mailing List >> >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want = "consumers" >> to >> >> think? >> >> >> >> > we didn't require some fundamental things in every sip device to >> >> > differentiate them from existing technology >> >> >> >> On 2nd thought, "we" MUST NOT require any features, only the SIP >> >> rendezvous service. >> >> >> >> Features are the business of the endpoint application developers, = not >> of >> >> standards bodies, nor of the FCC or the government. >> >> >> >> The users will select the products with the features they want. >> >> Now what features do I want for my social network? >> >> It's no business of the standards folks to make this decision. >> >> >> >> Thanks, Henry >> >> >> >> -----Original Message----- >> >> From: Brian Rosen [mailto:br@brianrosen.net] >> >> Sent: Wednesday, April 04, 2007 9:49 AM >> >> To: 'P2PSIP Mailing List' >> >> Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" = to >> >> think? >> >> >> >> One of the things I think we blew big time on sip was that we = didn't >> >> require >> >> some fundamental things in every sip device to differentiate them = from >> >> existing technology. We have an opportunity to fix that with = p2psip, >> >> and I >> >> think we should do it. >> >> >> >> Now, admittedly, what I'm talking about is somewhat a "marketing" >> issue, >> >> but >> >> it's a very real thing that we could do which I believe would be >> >> helpful. >> >> >> >> So, I propose: >> >> 1. We do not support any form of insecure signaling. We define = the >> >> protocol >> >> to reject attempts to signal without TLS (or whatever). I'm = assuming >> >> the >> >> protocols are TCP only. The overlay defines what credentials are >> needed >> >> (and supplies them). >> >> >> >> 2. We do not support any form of insecure media. It's always >> encrypted. >> >> This is the tough one, especially if we say we support SIP UAs. >> >> >> >> 3. All devices that support audio support wideband audio. >> >> >> >> 4. All devices support text (IM and real time interactive). >> >> >> >> 5. All devices support presence. We define a minimal set of = presence >> >> characteristics that all devices publish. >> >> >> >> 6. We define a minimal feature set (something like unattended and >> >> attended >> >> transfer, call forward no answer, call forward busy, basic >> conferencing, >> >> ...) that every device supports the same way. >> >> >> >> 7. All devices work behind a given set of NAT configurations, = given a >> >> specified set of ICE components (or whatever). >> >> >> >> 8. We define what constitutes a minimal configuration set; all of = the >> >> above >> >> just work with this level of configuration (and credentials from = an >> >> overlay). We of course define the configuration mechanism. I'm >> >> thinking >> >> that we do this by configuring the device with the credentials, = and >> >> using >> >> the overlay to provide any other configuration (which could be >> >> influenced >> >> by, say, a website the overlay runs) automatically. >> >> >> >> All of these are designed to be minimum capabilities, but the idea = is >> >> that >> >> ANY device, with credentials on an overlay, can expect to = communicate >> >> with >> >> any other device on that overlay with ALL of the above. >> >> >> >> Finally, I propose we invent a phrase, something like "p2psip >> >> conformant" >> >> which means a device that does that. No protocol police, but the = idea >> >> is >> >> that if you say you have a "p2psip conformant" device, it means = all of >> >> the >> >> above. Perhaps we have a way to signal that. >> >> >> >> This is pretty much what Skype does. Why should we not do that, = at >> >> least? >> >> >> >> Brian >> >> >> >> >> >> _______________________________________________ >> >> P2PSIP mailing list >> >> P2PSIP@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/p2psip >> > >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 11:06:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTXr-0000wN-3c; Thu, 05 Apr 2007 11:06:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTXq-0000wI-Sw for p2psip@ietf.org; Thu, 05 Apr 2007 11:06:38 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTXl-0004PT-Az for p2psip@ietf.org; Thu, 05 Apr 2007 11:06:38 -0400 Received: by an-out-0708.google.com with SMTP id d30so733846and for ; Thu, 05 Apr 2007 08:06:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pR97cuHRGW+Lrdoog5BZRK/zP4Qsaxt69aVXFsmGL93S9Kwr+XJwSRC5PihYznzvFG5kJ09Q0qd8OACvSP7EzArYC/b6KJHBFgQ6eZHw3IKxrpw1Gr3KDbRSK4bK2e0BAgPp+liO1essWlCwdlHXjuW3aAgrZOqdHGl5uasA+N0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UDnOaBWzC6cmCWv4AdAg38dG53OtMut/sZ1S2QYUSa5sQMT+KV3U1MO2VzTEn3YffxoGIS0aO1U6pUwp52+/6Lrdw9vr9gaoO6oVU/S0sEIsrniK9ggVFhlIpH6RzX39Es39lHCPaH7ISB/uWV+bl1RJgzw84JXhHyPBT9CYPDE= Received: by 10.114.53.1 with SMTP id b1mr788511waa.1175785591295; Thu, 05 Apr 2007 08:06:31 -0700 (PDT) Received: by 10.114.197.10 with HTTP; Thu, 5 Apr 2007 08:06:31 -0700 (PDT) Message-ID: <9dc4a1670704050806k51db44ffsb16e9fde7f187cbd@mail.gmail.com> Date: Thu, 5 Apr 2007 11:06:31 -0400 From: EdPimentl To: "Eric Cooper" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? In-Reply-To: <01d601c7778e$b72d7720$65500a0a@ronin> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20f201c7778a$3f156f30$81238182@cis.neustar.com> <01d601c7778e$b72d7720$65500a0a@ronin> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We are now risking letting go of ietf p2psip ship rudder/steering wheel and navigating without a compass into a vehement tempestous (TelCO/CableCO IMS ) storm and will be relying on TelCO's lighthouses and buoys to help guide us through turbulent shallow waters. Would be possible to agree on the minimum subset of features that the first phase of the working code should have....?? Later hardended and make more robust and even serve as critical ip communication survival infrastructure that just works.... with or without the un-willingpartner network (telco/cableco) -E On 4/5/07, Eric Cooper wrote: > So bliss isn't trying. I guess sipping must've failed if we still don't have interoperable transfers. What will we do differently? > > I thought P2PSIP was a distributed location service for SIP and a NAT-penetrating transport mechanism for SIP. I don't think it's a multimedia session establishment protocol. I think it's a bunch of primitives that reliably accomplish put/get/send using the resources of a whole bunch of nodes. I don't see it as defining a 'profile' for what codecs and methods SIP UAs should support. > > There's consensus in the group for supporting vanilla SIP UAs, but if all those UAs can't already interoperate w.r.t. call transfer do you propose to have the proxy peer (or GW or whatever) interwork their broken transfers to the P2PSIP transfer mechanism? > > I'm with Henry. I think we should stay out of this game. > > Eric. > > ----- Original Message ----- > From: "Brian Rosen" > To: "'Eric Cooper'" ; "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" > Sent: Thursday, April 05, 2007 9:56 AM > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? > > > > No. Bliss wants to make implementation of some complex features more > > uniform. An example is call park. > > > > Brian > > > >> -----Original Message----- > >> From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] > >> Sent: Thursday, April 05, 2007 9:49 AM > >> To: Brian Rosen; 'Henry Sinnreich'; 'P2PSIP Mailing List' > >> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" > >> tothink? > >> > >> I thought bliss was solving the problem you're describing. > >> > >> Eric. > >> > >> ----- Original Message ----- > >> From: "Brian Rosen" > >> To: "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" > >> > >> Sent: Thursday, April 05, 2007 9:11 AM > >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > >> tothink? > >> > >> > >> > And that is how generic SIP got to be associated with a PSTN lookalike > >> that > >> > doesn't work as well, but maybe costs less. > >> > > >> > I liken this to security "MUST IMPLEMENT" choices we make. We don't do > >> them > >> > because the protocol depends on them to work, and it's definitely a > >> feature. > >> > It's a value judgment; we want all implementations to have certain > >> security > >> > characteristics because we see the consequences of not having those > >> > features. The user is free to not use the feature, but if she wants to, > >> she > >> > can. MUST IMPLEMENT is as ignorable as any other words in an RFC. > >> What > >> > I'm proposing is the same. > >> > > >> > What I want are interoperable implementations. To do that, I need one > >> > implementation to know that it, for example, tries to transfer, the > >> other > >> > end will be able to do that. If it offers whatever wideband codec we > >> choose > >> > for audio, the other end will be able to accept. If it subscribes to > >> > presence for the AoR it has, assuming permission is granted, it will get > >> it, > >> > and certain information will be available to it (again, assuming > >> > permissions). I want more that "basic call" to work for all > >> implementations > >> > (at least those designed to work in a telephony like environment). > >> > > >> > This is p2psip. SIP is a multimedia session establishment protocol. > >> P2psip > >> > is a multimedia session establishment protocol. I'm not sure what you > >> are > >> > implying with "my social network", but if it's not multimedia session > >> > establishment, then p2psip is not solving your problem. > >> > > >> > Brian > >> > > >> >> -----Original Message----- > >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> >> Sent: Wednesday, April 04, 2007 10:13 PM > >> >> To: Brian Rosen; P2PSIP Mailing List > >> >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" > >> to > >> >> think? > >> >> > >> >> > we didn't require some fundamental things in every sip device to > >> >> > differentiate them from existing technology > >> >> > >> >> On 2nd thought, "we" MUST NOT require any features, only the SIP > >> >> rendezvous service. > >> >> > >> >> Features are the business of the endpoint application developers, not > >> of > >> >> standards bodies, nor of the FCC or the government. > >> >> > >> >> The users will select the products with the features they want. > >> >> Now what features do I want for my social network? > >> >> It's no business of the standards folks to make this decision. > >> >> > >> >> Thanks, Henry > >> >> > >> >> -----Original Message----- > >> >> From: Brian Rosen [mailto:br@brianrosen.net] > >> >> Sent: Wednesday, April 04, 2007 9:49 AM > >> >> To: 'P2PSIP Mailing List' > >> >> Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > >> >> think? > >> >> > >> >> One of the things I think we blew big time on sip was that we didn't > >> >> require > >> >> some fundamental things in every sip device to differentiate them from > >> >> existing technology. We have an opportunity to fix that with p2psip, > >> >> and I > >> >> think we should do it. > >> >> > >> >> Now, admittedly, what I'm talking about is somewhat a "marketing" > >> issue, > >> >> but > >> >> it's a very real thing that we could do which I believe would be > >> >> helpful. > >> >> > >> >> So, I propose: > >> >> 1. We do not support any form of insecure signaling. We define the > >> >> protocol > >> >> to reject attempts to signal without TLS (or whatever). I'm assuming > >> >> the > >> >> protocols are TCP only. The overlay defines what credentials are > >> needed > >> >> (and supplies them). > >> >> > >> >> 2. We do not support any form of insecure media. It's always > >> encrypted. > >> >> This is the tough one, especially if we say we support SIP UAs. > >> >> > >> >> 3. All devices that support audio support wideband audio. > >> >> > >> >> 4. All devices support text (IM and real time interactive). > >> >> > >> >> 5. All devices support presence. We define a minimal set of presence > >> >> characteristics that all devices publish. > >> >> > >> >> 6. We define a minimal feature set (something like unattended and > >> >> attended > >> >> transfer, call forward no answer, call forward busy, basic > >> conferencing, > >> >> ...) that every device supports the same way. > >> >> > >> >> 7. All devices work behind a given set of NAT configurations, given a > >> >> specified set of ICE components (or whatever). > >> >> > >> >> 8. We define what constitutes a minimal configuration set; all of the > >> >> above > >> >> just work with this level of configuration (and credentials from an > >> >> overlay). We of course define the configuration mechanism. I'm > >> >> thinking > >> >> that we do this by configuring the device with the credentials, and > >> >> using > >> >> the overlay to provide any other configuration (which could be > >> >> influenced > >> >> by, say, a website the overlay runs) automatically. > >> >> > >> >> All of these are designed to be minimum capabilities, but the idea is > >> >> that > >> >> ANY device, with credentials on an overlay, can expect to communicate > >> >> with > >> >> any other device on that overlay with ALL of the above. > >> >> > >> >> Finally, I propose we invent a phrase, something like "p2psip > >> >> conformant" > >> >> which means a device that does that. No protocol police, but the idea > >> >> is > >> >> that if you say you have a "p2psip conformant" device, it means all of > >> >> the > >> >> above. Perhaps we have a way to signal that. > >> >> > >> >> This is pretty much what Skype does. Why should we not do that, at > >> >> least? > >> >> > >> >> Brian > >> >> > >> >> > >> >> _______________________________________________ > >> >> P2PSIP mailing list > >> >> P2PSIP@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > >> > > >> > _______________________________________________ > >> > P2PSIP mailing list > >> > P2PSIP@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Thanks in advance and best regards, Ed Pimentel AgileCO Founder Mail: edpimentl[at]gmail.com IM: edpimentl [AOL | Jabber | Yahoo | MSN ] Voip: edpimentl [SKype | GoogleTalk ] Mobile Content Marketing/Management/Digital Delivery http://mobilecentral.ws Mobile ( Relevant, Ambient, Location ) based Social Network http://TagR.mobi (Alpha) Mobile Payment - P2P Payment http://agilepay.ws Sponsor of P2PSIP open source [viasip_ng] project Creating a standards base P2PSIP dSIP infrastructure https://sourceforge.net/projects/viasip/ Mailing List viasip_ng@freelists.org _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 12:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUUU-0007gX-8V; Thu, 05 Apr 2007 12:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUUS-0007gK-Lu for p2psip@ietf.org; Thu, 05 Apr 2007 12:07:12 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZUUQ-0003T7-0k for p2psip@ietf.org; Thu, 05 Apr 2007 12:07:12 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Thu, 05 Apr 2007 09:07:06 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l35G6XD1004462; Thu, 5 Apr 2007 09:06:33 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l35G6x0e026950; Thu, 5 Apr 2007 09:07:00 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 09:06:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 09:06:51 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF53@namail5.corp.adobe.com> In-Reply-To: <01d601c7778e$b72d7720$65500a0a@ronin> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd3jr7/RHu/vFMRRUa8oiluxkCyKQAC3Gqw References: <20f201c7778a$3f156f30$81238182@cis.neustar.com> <01d601c7778e$b72d7720$65500a0a@ronin> From: "Henry Sinnreich" To: "Eric Cooper" , "Brian Rosen" , "P2PSIP Mailing List" X-OriginalArrivalTime: 05 Apr 2007 16:06:58.0605 (UTC) FILETIME=[704D0DD0:01C7779C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Thanks Eric! > I think we should stay out of this game. Just to make it clear: 1. P2P SIP is a rendezvous and e2e session setup protocol ONLY, 2. Don't mess with SIP based applications, they belong to the p2p endpoint developers, owners and users. The Internet must stay transparent to such. 3. SIP has far too many extensions already and if anything, we need to just ignore them (the "simple SIP" I-D!).=20 If endpoint developers want to publish their features and SIP extensions on a web site or share them in confidential business meetings or discuss them in industry alliances and consortiums, that's their business. It is not the business of Internet standards engineers, the government or the United Nations. Thanks again, Henry -----Original Message----- From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca]=20 Sent: Thursday, April 05, 2007 9:29 AM To: Brian Rosen; Henry Sinnreich; 'P2PSIP Mailing List' Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? So bliss isn't trying. I guess sipping must've failed if we still don't have interoperable transfers. What will we do differently? I thought P2PSIP was a distributed location service for SIP and a NAT-penetrating transport mechanism for SIP. I don't think it's a multimedia session establishment protocol. I think it's a bunch of primitives that reliably accomplish put/get/send using the resources of a whole bunch of nodes. I don't see it as defining a 'profile' for what codecs and methods SIP UAs should support. There's consensus in the group for supporting vanilla SIP UAs, but if all those UAs can't already interoperate w.r.t. call transfer do you propose to have the proxy peer (or GW or whatever) interwork their broken transfers to the P2PSIP transfer mechanism? I'm with Henry. I think we should stay out of this game. Eric. ----- Original Message -----=20 From: "Brian Rosen" To: "'Eric Cooper'" ; "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" Sent: Thursday, April 05, 2007 9:56 AM Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? > No. Bliss wants to make implementation of some complex features more > uniform. An example is call park. >=20 > Brian >=20 >> -----Original Message----- >> From: Eric Cooper [mailto:eric_d_cooper@sympatico.ca] >> Sent: Thursday, April 05, 2007 9:49 AM >> To: Brian Rosen; 'Henry Sinnreich'; 'P2PSIP Mailing List' >> Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" >> tothink? >>=20 >> I thought bliss was solving the problem you're describing. >>=20 >> Eric. >>=20 >> ----- Original Message ----- >> From: "Brian Rosen" >> To: "'Henry Sinnreich'" ; "'P2PSIP Mailing List'" >> >> Sent: Thursday, April 05, 2007 9:11 AM >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" >> tothink? >>=20 >>=20 >> > And that is how generic SIP got to be associated with a PSTN lookalike >> that >> > doesn't work as well, but maybe costs less. >> > >> > I liken this to security "MUST IMPLEMENT" choices we make. We don't do >> them >> > because the protocol depends on them to work, and it's definitely a >> feature. >> > It's a value judgment; we want all implementations to have certain >> security >> > characteristics because we see the consequences of not having those >> > features. The user is free to not use the feature, but if she wants to, >> she >> > can. MUST IMPLEMENT is as ignorable as any other words in an RFC. >> What >> > I'm proposing is the same. >> > >> > What I want are interoperable implementations. To do that, I need one >> > implementation to know that it, for example, tries to transfer, the >> other >> > end will be able to do that. If it offers whatever wideband codec we >> choose >> > for audio, the other end will be able to accept. If it subscribes to >> > presence for the AoR it has, assuming permission is granted, it will get >> it, >> > and certain information will be available to it (again, assuming >> > permissions). I want more that "basic call" to work for all >> implementations >> > (at least those designed to work in a telephony like environment). >> > >> > This is p2psip. SIP is a multimedia session establishment protocol. >> P2psip >> > is a multimedia session establishment protocol. I'm not sure what you >> are >> > implying with "my social network", but if it's not multimedia session >> > establishment, then p2psip is not solving your problem. >> > >> > Brian >> > >> >> -----Original Message----- >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> >> Sent: Wednesday, April 04, 2007 10:13 PM >> >> To: Brian Rosen; P2PSIP Mailing List >> >> Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" >> to >> >> think? >> >> >> >> > we didn't require some fundamental things in every sip device to >> >> > differentiate them from existing technology >> >> >> >> On 2nd thought, "we" MUST NOT require any features, only the SIP >> >> rendezvous service. >> >> >> >> Features are the business of the endpoint application developers, not >> of >> >> standards bodies, nor of the FCC or the government. >> >> >> >> The users will select the products with the features they want. >> >> Now what features do I want for my social network? >> >> It's no business of the standards folks to make this decision. >> >> >> >> Thanks, Henry >> >> >> >> -----Original Message----- >> >> From: Brian Rosen [mailto:br@brianrosen.net] >> >> Sent: Wednesday, April 04, 2007 9:49 AM >> >> To: 'P2PSIP Mailing List' >> >> Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to >> >> think? >> >> >> >> One of the things I think we blew big time on sip was that we didn't >> >> require >> >> some fundamental things in every sip device to differentiate them from >> >> existing technology. We have an opportunity to fix that with p2psip, >> >> and I >> >> think we should do it. >> >> >> >> Now, admittedly, what I'm talking about is somewhat a "marketing" >> issue, >> >> but >> >> it's a very real thing that we could do which I believe would be >> >> helpful. >> >> >> >> So, I propose: >> >> 1. We do not support any form of insecure signaling. We define the >> >> protocol >> >> to reject attempts to signal without TLS (or whatever). I'm assuming >> >> the >> >> protocols are TCP only. The overlay defines what credentials are >> needed >> >> (and supplies them). >> >> >> >> 2. We do not support any form of insecure media. It's always >> encrypted. >> >> This is the tough one, especially if we say we support SIP UAs. >> >> >> >> 3. All devices that support audio support wideband audio. >> >> >> >> 4. All devices support text (IM and real time interactive). >> >> >> >> 5. All devices support presence. We define a minimal set of presence >> >> characteristics that all devices publish. >> >> >> >> 6. We define a minimal feature set (something like unattended and >> >> attended >> >> transfer, call forward no answer, call forward busy, basic >> conferencing, >> >> ...) that every device supports the same way. >> >> >> >> 7. All devices work behind a given set of NAT configurations, given a >> >> specified set of ICE components (or whatever). >> >> >> >> 8. We define what constitutes a minimal configuration set; all of the >> >> above >> >> just work with this level of configuration (and credentials from an >> >> overlay). We of course define the configuration mechanism. I'm >> >> thinking >> >> that we do this by configuring the device with the credentials, and >> >> using >> >> the overlay to provide any other configuration (which could be >> >> influenced >> >> by, say, a website the overlay runs) automatically. >> >> >> >> All of these are designed to be minimum capabilities, but the idea is >> >> that >> >> ANY device, with credentials on an overlay, can expect to communicate >> >> with >> >> any other device on that overlay with ALL of the above. >> >> >> >> Finally, I propose we invent a phrase, something like "p2psip >> >> conformant" >> >> which means a device that does that. No protocol police, but the idea >> >> is >> >> that if you say you have a "p2psip conformant" device, it means all of >> >> the >> >> above. Perhaps we have a way to signal that. >> >> >> >> This is pretty much what Skype does. Why should we not do that, at >> >> least? >> >> >> >> Brian >> >> >> >> >> >> _______________________________________________ >> >> P2PSIP mailing list >> >> P2PSIP@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/p2psip >> > >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 12:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUii-0001SV-KY; Thu, 05 Apr 2007 12:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZUii-0001SQ-9t for p2psip@ietf.org; Thu, 05 Apr 2007 12:21:56 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZUig-0005eN-Qj for p2psip@ietf.org; Thu, 05 Apr 2007 12:21:56 -0400 Received: from [192.168.2.102] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l35FSI95007164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2007 10:28:18 -0500 In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C5160AE5@photon.objectworld.com> References: <4E2DC1ACE541B94A946B8D8657E372C57A90EA@photon.objectworld.com><1fb601c776fb$fb96a050$81238182@cis.neustar.com><20d2bdfb0704041742n6d031134h7f749bfb280ae73@mail.gmail.com><20d2bdfb0704041827w60cf9d24sa3c4fc29be30e8c@mail.gmail.com> <013501c77724$d5b97e60$65500a0a@ronin> <4E2DC1ACE541B94A946B8D8657E372C5160AE3@photon.objectworld.com> <46148788.5080207@softarmor.com> <4E2DC1ACE541B94A946B8D8657E372C5160AE5@photon.objectworld.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 11:21:44 -0500 To: Michael Slavitch X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 5, 2007, at 7:25 AM, Michael Slavitch wrote: > If the SDP of P2PSIP is going to be so fat and complex as to > require protocol-level fragments that cannot be reassembled at an > application layer we are headed down the IMS path before having an > empire to defend. > I think that's a given, especially if we use some sort of S/MIME wrapper to keep intervening peers out of our SDP. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 12:47:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZV78-0000IY-N6; Thu, 05 Apr 2007 12:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZV77-0000IR-Cf for p2psip@ietf.org; Thu, 05 Apr 2007 12:47:09 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZV74-000169-Vs for p2psip@ietf.org; Thu, 05 Apr 2007 12:47:09 -0400 Received: from [192.168.2.102] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l35FqwHo007252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2007 10:52:58 -0500 In-Reply-To: <4614EFF9.6030702@cisco.com> References: <1fcd01c77705$94328870$81238182@cis.neustar.com> <16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com> <4614EFF9.6030702@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Thu, 5 Apr 2007 11:46:23 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 5, 2007, at 7:47 AM, Paul Kyzivat wrote: > Is it really possible to eliminate SPs (loosely defined) from this > market? > Of course not. But their role will differ somewhat, and we can expect that they will not be required for all enterprise to enterprise communications. B2B does not require mediators, although it allows them. I predict SPs will split into two classes -- overlay maintainers, and gateway providers. Skype, of course, does both. Consider what happened with enterprise email systems (I'll skip the UUCP story, as although influential, it's a different story). In the beginning, it was a pure service provider play. My buddies at MCI got $2 per page of email sent through MCIMail. Everybody's address was in the MCIMail namespace, and it didn't talk to any other namespaces. If you wanted to email somebody on The Well, you had to dial in there instead. Same for CompuServ. Then the email services began interconnecting using SMTP, and people started recognizing "@" style addressing for name spaces. Some enterprises figured out that they could run their own email services, just like universities and national labs did, using the same software and protocols. At first the big email services refused to talk to them, and then it became commonplace. Eventually a three-tier system emerged for enterprises. Big or technically astute enterprises ran their own email services. Mid- sized or very name conscious ones contracted with a service provider to represent them in the DNS namespace and host an appropriate email server. And little companies continued to use "service provider" hosting and namespace, like "business class" AOL. Now, how does this apply to P2PSIP? 1) If the service-provider interface is CSSIP, the service provider has to find the other service providers to talk to. This is likely to be resolved by RFC 3263 procedures, but could also be resolved using P2PSIP between the service providers. 2) The relationship between end users (such as enterprises) and their gateway service providers could occur inside a P2PSIP model. Perhaps the enterprise and the gateway provider are members of the same overlay. 3) Enterprises that participate in the same overlay as each other can just use P2PSIP procedures between each other. This is especially useful for the small-to-medium business that can't figure out how (or don't want to pay to) to manage their own DNS entries and SIP gateways and things. Just sign up with an overlay, plug in an ICE- friendly router and some P2PSIP phones, and start talking. The overlay gets you to other enterprises in the overlay, gets you to a SIP gateway for destinations not on the overlay, and gets you to TDM gateway providers for users that have to be reached via TDM (although you might contract seperately for these gateway services). > Almost every customer will want to make calls to/from the PSTN. > Either each customer has their own TDM interconnect or else they > become the customer of somebody. Since TDM calls and phone numbers > cost something I doubt this can be something that will be provided > for free, so somebody ends up being a service provider. (I.e. Skype > is a SP for TDM interconnect.) Right. But in today's market, the service providers also require that they are the provider of IP interconnect. That won't hold up. It's entirely reasonable to provide your own IP interconnect, and use a service provider for TDM. Or use two entirely different service providers. Or maybe three -- one for overlay, one for TDM, and one for CSSIP. > > Direct business-to-business and business-to-consumer calling > without TDM doesn't necessarily require TDM trunks. But unless > everybody is on the same p2p network it will require *something*. > If addressing is via sip URIs then all it really requires is DNS > and IP connectivity, which is perhaps what you mean. If the goal is > connectivity via phone number addressing then it will still require > ENUM. Within an overlay, no ENUM needed. ENUM is useful between overlays (at CSSIP gateways), which includes selecting a TDM gateway that is outside one's overlay. > >> Here's another scenario where the dynamic routing of P2P makes sense. >> Assume a conventional IMS with 5 million uses and 50 S-CSCF nodes. >> Each user is dynamically assigned to an S-CSCF at registration >> time. A user binding is then placed into the HSS to map from user >> to S-CSCF. The HSS is hard to manage, scale, replicate, etc. Every >> phone call requires a couple of dips into the HSS to figure out >> the routing. >> Replace HSS with P2PSIP. The originating side S-CSCF/peer >> transforms the R-URI into a resource ID. One DHT hash later, we >> have the peer ID of the terminating S-CSCF. Routing follows. > > I think you just mixed up the domain of the caller with the domain > of the callee. Fine if they are the same. Not fine if they are > different. I tried to keep my example within a single IMS domain, which is roughly equivalent to keeping it within an overlay. If one is crossing between IMSes, this might well be equivalent to crossing between overlays, which we assume requries either 3262 procedures or fixed "trunk"style routing. > > I think we can safely assume that even if p2p is embraced for IMS, > it won't mean that all IMS providers share a single DHT. > Correct. They're more likely to use fixed inter-IMS trunking for the forseeable future. > So it is just like the business-to-business discussion above. yep. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 12:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVBJ-000109-BG; Thu, 05 Apr 2007 12:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZVBH-0000zn-Ku for p2psip@ietf.org; Thu, 05 Apr 2007 12:51:27 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZVBF-0001UP-Bw for p2psip@ietf.org; Thu, 05 Apr 2007 12:51:27 -0400 Received: from [192.168.2.102] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l35FvMYi007271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2007 10:57:22 -0500 In-Reply-To: <01d601c7778e$b72d7720$65500a0a@ronin> References: <20f201c7778a$3f156f30$81238182@cis.neustar.com> <01d601c7778e$b72d7720$65500a0a@ronin> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 11:50:47 -0500 To: Eric Cooper X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 5, 2007, at 9:28 AM, Eric Cooper wrote: > So bliss isn't trying. I guess sipping must've failed if we still > don't have interoperable transfers. What will we do differently? > > I thought P2PSIP was a distributed location service for SIP and a > NAT-penetrating transport mechanism for SIP. I don't think it's a > multimedia session establishment protocol. I think it's a bunch of > primitives that reliably accomplish put/get/send using the > resources of a whole bunch of nodes. I don't see it as defining a > 'profile' for what codecs and methods SIP UAs should support. > > There's consensus in the group for supporting vanilla SIP UAs, but > if all those UAs can't already interoperate w.r.t. call transfer do > you propose to have the proxy peer (or GW or whatever) interwork > their broken transfers to the P2PSIP transfer mechanism? > > I'm with Henry. I think we should stay out of this game. If I understand the question being asked to be the same as the one Eric answers above, then I find I must agree with Eric. P2PSIP must not attempt to define a profile of SIP user agent features for SIPPING-style call scenarios. That's somebody else's problem. I'm not exactly sure I understand the question being asked, however. I think it may have slithered away from us while being reduced to the absurd by the discussion. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 14:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWaa-0001T6-6C; Thu, 05 Apr 2007 14:21:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZWaY-0001T1-NO for p2psip@ietf.org; Thu, 05 Apr 2007 14:21:38 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWaY-0006Ut-8I for p2psip@ietf.org; Thu, 05 Apr 2007 14:21:38 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l35ILOKU005317 for ; Thu, 5 Apr 2007 14:21:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 5 Apr 2007 14:20:49 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd3oiYiHJ0rgRoER4iaFexMavsrqQADNBrA References: <1fcd01c77705$94328870$81238182@cis.neustar.com><16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com><4614EFF9.6030702@cisco.com> From: "Michael Slavitch" To: "Dean Willis" , "Paul Kyzivat" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I concur so much with Dean's description I may have to consider him a compe= titor. ;) Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, April 05, 2007 12:46 PM To: Paul Kyzivat Cc: 'P2PSIP Mailing List' Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario On Apr 5, 2007, at 7:47 AM, Paul Kyzivat wrote: > Is it really possible to eliminate SPs (loosely defined) from this=20=20 > market? > Of course not. But their role will differ somewhat, and we can expect=20=20 that they will not be required for all enterprise to enterprise=20=20 communications. B2B does not require mediators, although it allows=20=20 them. I predict SPs will split into two classes -- overlay=20=20 maintainers, and gateway providers. Skype, of course, does both. Consider what happened with enterprise email systems (I'll skip the=20=20 UUCP story, as although influential, it's a different story). In the beginning, it was a pure service provider play. My buddies at=20=20 MCI got $2 per page of email sent through MCIMail. Everybody's=20=20 address was in the MCIMail namespace, and it didn't talk to any other=20=20 namespaces. If you wanted to email somebody on The Well, you had to=20=20 dial in there instead. Same for CompuServ. Then the email services began interconnecting using SMTP, and people=20=20 started recognizing "@" style addressing for name spaces. Some enterprises figured out that they could run their own email=20=20 services, just like universities and national labs did, using the=20=20 same software and protocols. At first the big email services refused=20=20 to talk to them, and then it became commonplace. Eventually a three-tier system emerged for enterprises. Big or=20=20 technically astute enterprises ran their own email services. Mid-=20 sized or very name conscious ones contracted with a service provider=20=20 to represent them in the DNS namespace and host an appropriate email=20=20 server. And little companies continued to use "service provider"=20=20 hosting and namespace, like "business class" AOL. Now, how does this apply to P2PSIP? 1) If the service-provider interface is CSSIP, the service provider=20=20 has to find the other service providers to talk to. This is likely to=20=20 be resolved by RFC 3263 procedures, but could also be resolved using=20=20 P2PSIP between the service providers. 2) The relationship between end users (such as enterprises) and their=20=20 gateway service providers could occur inside a P2PSIP model. Perhaps=20=20 the enterprise and the gateway provider are members of the same overlay. 3) Enterprises that participate in the same overlay as each other can=20=20 just use P2PSIP procedures between each other. This is especially=20=20 useful for the small-to-medium business that can't figure out how (or=20=20 don't want to pay to) to manage their own DNS entries and SIP=20=20 gateways and things. Just sign up with an overlay, plug in an ICE-=20 friendly router and some P2PSIP phones, and start talking. The=20=20 overlay gets you to other enterprises in the overlay, gets you to a=20=20 SIP gateway for destinations not on the overlay, and gets you to TDM=20=20 gateway providers for users that have to be reached via TDM (although=20=20 you might contract seperately for these gateway services). > Almost every customer will want to make calls to/from the PSTN.=20=20 > Either each customer has their own TDM interconnect or else they=20=20 > become the customer of somebody. Since TDM calls and phone numbers=20=20 > cost something I doubt this can be something that will be provided=20=20 > for free, so somebody ends up being a service provider. (I.e. Skype=20=20 > is a SP for TDM interconnect.) Right. But in today's market, the service providers also require that=20=20 they are the provider of IP interconnect. That won't hold up. It's=20=20 entirely reasonable to provide your own IP interconnect, and use a=20=20 service provider for TDM. Or use two entirely different service=20=20 providers. Or maybe three -- one for overlay, one for TDM, and one=20=20 for CSSIP. > > Direct business-to-business and business-to-consumer calling=20=20 > without TDM doesn't necessarily require TDM trunks. But unless=20=20 > everybody is on the same p2p network it will require *something*.=20=20 > If addressing is via sip URIs then all it really requires is DNS=20=20 > and IP connectivity, which is perhaps what you mean. If the goal is=20=20 > connectivity via phone number addressing then it will still require=20=20 > ENUM. Within an overlay, no ENUM needed. ENUM is useful between overlays=20=20 (at CSSIP gateways), which includes selecting a TDM gateway that is=20=20 outside one's overlay. > >> Here's another scenario where the dynamic routing of P2P makes sense. >> Assume a conventional IMS with 5 million uses and 50 S-CSCF nodes.=20=20 >> Each user is dynamically assigned to an S-CSCF at registration=20=20 >> time. A user binding is then placed into the HSS to map from user=20=20 >> to S-CSCF. The HSS is hard to manage, scale, replicate, etc. Every=20=20 >> phone call requires a couple of dips into the HSS to figure out=20=20 >> the routing. >> Replace HSS with P2PSIP. The originating side S-CSCF/peer=20=20 >> transforms the R-URI into a resource ID. One DHT hash later, we=20=20 >> have the peer ID of the terminating S-CSCF. Routing follows. > > I think you just mixed up the domain of the caller with the domain=20=20 > of the callee. Fine if they are the same. Not fine if they are=20=20 > different. I tried to keep my example within a single IMS domain, which is=20=20 roughly equivalent to keeping it within an overlay. If one is=20=20 crossing between IMSes, this might well be equivalent to crossing=20=20 between overlays, which we assume requries either 3262 procedures or=20=20 fixed "trunk"style routing. > > I think we can safely assume that even if p2p is embraced for IMS,=20=20 > it won't mean that all IMS providers share a single DHT. > Correct. They're more likely to use fixed inter-IMS trunking for the=20=20 forseeable future. > So it is just like the business-to-business discussion above. yep. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 22:08:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdrs-0004pB-UP; Thu, 05 Apr 2007 22:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdrr-0004op-Db for p2psip@ietf.org; Thu, 05 Apr 2007 22:07:59 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZdrn-0004RA-TH for p2psip@ietf.org; Thu, 05 Apr 2007 22:07:59 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Thu, 05 Apr 2007 19:07:49 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3627cSd005137; Thu, 5 Apr 2007 19:07:43 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3627WI9013358; Thu, 5 Apr 2007 19:07:32 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 19:07:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Thu, 5 Apr 2007 19:06:41 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF58@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd2yFdT6QjVEeRNSS6r+eAr6p73OgAlW8lQACSQDfA= References: <1e1b01c776c8$66fd46c0$81238182@cis.neustar.com> From: "Henry Sinnreich" To: , , X-OriginalArrivalTime: 06 Apr 2007 02:07:37.0515 (UTC) FILETIME=[592A4FB0:01C777F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >I am interested in how to make SIM authentication and DHT work seamlessly together. The enrollment service can provide the crypto key pair that may or may not reside in the SIM card. Henry -----Original Message----- From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]=20 Sent: Thursday, April 05, 2007 3:44 AM To: br@brianrosen.net; p2psip@ietf.org Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Brian, Lot of these devices will be wireless and/or mobile.=20 I am interested in how to make SIM authentication and DHT work seamlessly together.=20 I believe that many wifi/wimax devices in the near future will be shipped with SIM stacks as well, allowing secure authetication and authorisation. Colin Pons Senior Architect WSO Innovation Management -----Oorspronkelijk bericht----- Van: Brian Rosen [mailto:br@brianrosen.net]=20 Verzonden: woensdag 4 april 2007 16:49 Aan: 'P2PSIP Mailing List' Onderwerp: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? One of the things I think we blew big time on sip was that we didn't require some fundamental things in every sip device to differentiate them from existing technology. We have an opportunity to fix that with p2psip, and I think we should do it. Now, admittedly, what I'm talking about is somewhat a "marketing" issue, but it's a very real thing that we could do which I believe would be helpful. So, I propose: 1. We do not support any form of insecure signaling. We define the protocol to reject attempts to signal without TLS (or whatever). I'm assuming the protocols are TCP only. The overlay defines what credentials are needed (and supplies them). 2. We do not support any form of insecure media. It's always encrypted. This is the tough one, especially if we say we support SIP UAs. 3. All devices that support audio support wideband audio. =20 4. All devices support text (IM and real time interactive). 5. All devices support presence. We define a minimal set of presence characteristics that all devices publish. 6. We define a minimal feature set (something like unattended and attended transfer, call forward no answer, call forward busy, basic conferencing, ...) that every device supports the same way. 7. All devices work behind a given set of NAT configurations, given a specified set of ICE components (or whatever). 8. We define what constitutes a minimal configuration set; all of the above just work with this level of configuration (and credentials from an overlay). We of course define the configuration mechanism. I'm thinking that we do this by configuring the device with the credentials, and using the overlay to provide any other configuration (which could be influenced by, say, a website the overlay runs) automatically. All of these are designed to be minimum capabilities, but the idea is that ANY device, with credentials on an overlay, can expect to communicate with any other device on that overlay with ALL of the above. Finally, I propose we invent a phrase, something like "p2psip conformant" which means a device that does that. No protocol police, but the idea is that if you say you have a "p2psip conformant" device, it means all of the above. Perhaps we have a way to signal that. This is pretty much what Skype does. Why should we not do that, at least? Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 05 22:08:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdsc-0004xW-LE; Thu, 05 Apr 2007 22:08:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdsb-0004xQ-91 for p2psip@ietf.org; Thu, 05 Apr 2007 22:08:45 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZdsZ-0004Tq-Ul for p2psip@ietf.org; Thu, 05 Apr 2007 22:08:45 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 05 Apr 2007 19:08:05 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3627vSd005155; Thu, 5 Apr 2007 19:08:02 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3627mI9013370; Thu, 5 Apr 2007 19:07:48 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 19:07:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Thu, 5 Apr 2007 19:07:52 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd3oiYiHJ0rgRoER4iaFexMavsrqQADNBrAAA7zD6A= References: <1fcd01c77705$94328870$81238182@cis.neustar.com><16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com><4614EFF9.6030702@cisco.com> <4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> From: "Henry Sinnreich" To: "Michael Slavitch" , "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 06 Apr 2007 02:07:53.0046 (UTC) FILETIME=[626C2760:01C777F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Michael, I agree with what you say but just cannot understand why you assume IMS = will matter for the Internet (it is supposed to be the last stand = against the Internet) and even if so, on what basis do you assume IMS = will ever change direction 180 degrees and adopt P2P?=20 Isn't IMS all about everything in the network and the endpoints are = under total control? Mobile operators may see the light and adopt P2P, but would it be IMS as = it is defined today? Can you help and explain? Thanks, Henry -----Original Message----- From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Thursday, April 05, 2007 1:21 PM To: Dean Willis; Paul Kyzivat Cc: P2PSIP Mailing List Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario I concur so much with Dean's description I may have to consider him a = competitor. ;) Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =20 Lead, Technology Initiatives slavitch@objectworld.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 06 03:33:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZix0-0002eK-7v; Fri, 06 Apr 2007 03:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZiwy-0002e7-Jw for p2psip@ietf.org; Fri, 06 Apr 2007 03:33:36 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZiwx-0002T3-3b for p2psip@ietf.org; Fri, 06 Apr 2007 03:33:36 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG20046UFLS5A@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 06 Apr 2007 15:32:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG200MWRFLRG0@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 06 Apr 2007 15:32:16 +0800 (CST) Received: from j36340 ([10.164.5.25]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JG200LBQFLNH1@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 06 Apr 2007 15:32:15 +0800 (CST) Date: Fri, 06 Apr 2007 15:32:12 +0800 From: JiangXingFeng Subject: RE: FW: [P2PSIP] Re: Peer definition in Concept draft In-reply-to: <46148876.8090309@softarmor.com> To: 'Dean Willis' Message-id: <003201c7781d$b10f40a0$1905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acd3QsIEiMe1qLACTfaPfQSyKHl8KQA2pFcg X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > >>[Jiang XingFeng] I'd like P2PSIP reference model should allow the > > > > existence of > > > >>non-SIP peers. If non-SIP nodes are excluded from the P2PSIP reference > > > > model, > > > >>the P2PSIP will be not flexible enough to support new type of peers, for > > > > example, > > > >>STUN peers which does not speak SIP in nature. > > Good point. > > Of course, if we select SIP or modified SIP as the peer protocol (as > per dSIP), then excluding non-sip nodes would be impossible. [JiangXingFeng] I hope non-sip nodes playing peer role is in the scope. > > ... > > >>>2) Since the the request could be routed without parsing the text- > >>>formatted SIP message, there is the possibility that routing > >>>decisions could require substantially (perhaps an order of magnitude) > >>>less processing power than that required for conventional SIP > >>>proxies. This is further augmented by not having to decrypt/re- > >>>encrypt each request at every proxy when TLS is used. > >>> > >> > >>[Jiang XingFeng]I like these advantages. If application messages could be > > > > delivered > > > >>through the overlay and Peers does not care about what's in the section of > >>application message, it will speed up lookup operations in a recursive > > > > manner. > > > >>As you suggested, every peer should have tunnel functionality to wrap > > > > application > > > >>message. Is the tunnel functionality specific to SIP? > > As I read the charter, we're tasked with making it work for SIP. If it > works for something besides SIP, I guess that's OK, but really not a > design goal. > > On the other hand, the classic Postel process is to favor generality > over optimization. [JiangXingfeng] I like the general one. :-) > > -- > Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 06 10:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpNu-00030b-P6; Fri, 06 Apr 2007 10:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpNr-00030G-O5 for p2psip@ietf.org; Fri, 06 Apr 2007 10:25:47 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpNq-00067h-DG for p2psip@ietf.org; Fri, 06 Apr 2007 10:25:47 -0400 Received: by py-out-1112.google.com with SMTP id f31so420886pyh for ; Fri, 06 Apr 2007 07:25:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=kg3O8/wX5mjZODvUSsIgM1SNNwQMMa5fSgbvea5x6Mwhgont5U469R43FC4yzuPqc9o5il3/dnvrJlqjPVt0dD4aJawOpX+hYGimR1uP0bN8REVQgWSWpcc9RuxVn/BT2UsK+wBlC3MGHpwbFmWfSkxNkFOm+iHSEfSrP3Zdzuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=G4tiAw884aNJi89v+H1PMgJM5GgOuvJpFoo/JHpW4zvNDSjrVZotOH6Y4GMEPQiUqnTneirLaB6fZYcWeR0Q4ecdvL8hQGK2Jo1anI+GlEXpwFyxEYmi5gSBj3tSgTF4W7QPXmqXidVx5VLcBfLkfE1j8bgqT8b7plTlEOKaPm4= Received: by 10.35.43.10 with SMTP id v10mr5317475pyj.1175869546129; Fri, 06 Apr 2007 07:25:46 -0700 (PDT) Received: by 10.35.76.19 with HTTP; Fri, 6 Apr 2007 07:25:46 -0700 (PDT) Message-ID: <7b683f3f0704060725q72d2e8ebke20c0caba05b2988@mail.gmail.com> Date: Fri, 6 Apr 2007 10:25:46 -0400 From: "Eunsoo Shim" To: "Dean Willis" Subject: Re: [P2PSIP] Re: Peer definition in Concept draft In-Reply-To: <461486E3.2060300@softarmor.com> MIME-Version: 1.0 References: <000601c775e7$1c446cd0$1905a40a@china.huawei.com> <1DFF418C-CFC9-4FAA-A2E7-9BC7B0961F69@softarmor.com> <010d01c7771d$1c47e860$65500a0a@ronin> <461486E3.2060300@softarmor.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Philip Matthews , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0731387202==" Errors-To: p2psip-bounces@ietf.org --===============0731387202== Content-Type: multipart/alternative; boundary="----=_Part_2526_31882240.1175869546049" ------=_Part_2526_31882240.1175869546049 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/5/07, Dean Willis wrote: > > Eric Cooper wrote: > >>Imagine a model where the peer protocol is not SIP, but instead > >>provides a means for carrying SIP requests in an "envelope" or > >>wrapper provided by the peer protocol. > >> > > > > > > I think this is an interesting model and agree with the advantages you > mentioned. > > > > Would there be any charter-related problems with pursuing such a > model? I ask because I think this model could easily become a generic > transport service. Would that be out-of-scope for us? > > > > If we say it's not a generic transport service, but really tied more to > SIP then this model could also be viewed as defining an alternative > transport for SIP. Is that in scope? > > > > Best Regards, > > > > Eric. > > > > I hope the charter allows for this approach. It is certainly condidered > in the -03 version of the Concepts and Terminology draft, and I believe > still allowed for in -04. This 'transport' functionality is not one of the core functionalities of the Peer Protocol or the Client Protocol as described in the current charter. However, the charter cannot describe all the functionalities the protocols can provide. So I believe there is a room for adopting such 'transport' functionality into the protocols at least as far as the charter is concerned. Well, probably we would need our AD's help in this discussion. Anyway, other important questions are how useful the functionality is, how close/far this functionality is to/from the core functionalities of the protocols, and whether it is better to put it in the protocols rather than to separate it into a different protocol. Thanks. Eunsoo ------=_Part_2526_31882240.1175869546049 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 4/5/07, Dean Willis <dean.willis@softarmor.com> wrote:
Eric Cooper wrote:
>>Imagine a model where the peer protocol is not SIP, but instead
>>provides a means for carrying SIP requests in an "envelope" or
>>wrapper provided by the peer protocol.
>>
>
>
> I think this is an interesting model and agree with the advantages you mentioned.
>
> Would there be any charter-related problems with pursuing such a model?  I ask because I think this model could easily become a generic transport service.  Would that be out-of-scope for us?
>
> If we say it's not a generic transport service, but really tied more to SIP then this model could also be viewed as defining an alternative transport for SIP.  Is that in scope?
>
> Best Regards,
>
> Eric.
>

I hope the charter allows for this approach. It is certainly condidered
in the -03 version of the Concepts and Terminology draft, and I believe
still allowed for in -04.

 
This 'transport' functionality is not one of the core functionalities of the Peer Protocol or the Client Protocol as described in the current charter. However, the charter cannot describe all the functionalities the protocols can provide. So I believe there is a room for adopting such 'transport' functionality into the protocols at least as far as the charter is concerned. Well, probably we would need our AD's help in this discussion.

Anyway, other important questions are how useful the functionality is,  how close/far this functionality is to/from the core functionalities of the protocols, and whether it is better to put it in the protocols rather than to separate it into a different protocol.

Thanks.

Eunsoo


------=_Part_2526_31882240.1175869546049-- --===============0731387202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0731387202==-- From p2psip-bounces@ietf.org Fri Apr 06 10:43:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpf1-0006eX-Se; Fri, 06 Apr 2007 10:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpf0-0006eB-Cz for p2psip@ietf.org; Fri, 06 Apr 2007 10:43:30 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpey-0004dv-Ma for p2psip@ietf.org; Fri, 06 Apr 2007 10:43:30 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id F27C11460; Fri, 6 Apr 2007 16:43:20 +0200 (MEST) Received: from sat-relay1.telecom.ptt.nl (relay3.kpn-telecom.nl [145.7.200.29]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id EE5BA1462; Fri, 6 Apr 2007 16:43:18 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay1.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l36EhHT26852; Fri, 6 Apr 2007 16:43:17 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 16:42:23 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Fri, 6 Apr 2007 16:42:13 +0200 Message-ID: In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd3oiYiHJ0rgRoER4iaFexMavsrqQADNBrAAA7zD6AAGytJ0A== References: <1fcd01c77705$94328870$81238182@cis.neustar.com><16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com><4614EFF9.6030702@cisco.com><4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> From: To: , , , X-OriginalArrivalTime: 06 Apr 2007 14:42:23.0843 (UTC) FILETIME=[C9EB9330:01C77859] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry, My 2-cents worth IMS is often viewed, pushed or what ever you want as a defence against = 'the Internet Model'. Orignially, it was position to provide Internet = style services, buit remaining some control in the network. There are some benefits for telco's in using IMS even if not used as a = "last stand against The Internet". In that it provides some interfaces = for billing, OSS/BSS en SIM authentication amongst others.=20 Now I am a firm believer of open networks and deploying Application in = end-to-end fashion. Although this is not always quite possible, eg when = using SIP for PSTN Simulation services. I know it goes against many of = your believes, but replacing TDM network technology with IP/ethernet = networks and the demand from marketers to do this unintrusive for our = customers, does not leave us with much choose. But, we are not trying to = replace every feature (e.g. we abandon Call Completion services). I = share your worry that too much focus is on standardization efforts to = replicate the PSTN using SIP. We would like to use IMS for more than PSTN, so we deploy it as open as = possible and challenge our IMS vendor to implement basically a SIP = Proxy. But not everyone shares this view, I admit. Now, I do not see how P2P would be incorporated into IMS. It would = render the HSS obsolete and hence IMS would loose much of it's value. I = would say Dean's decription sounds like an interesting path for = migrating IMS to P2P but not as a long term co-existence. Colin Pons -----Oorspronkelijk bericht----- Van: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Verzonden: vrijdag 6 april 2007 4:08 Aan: Michael Slavitch; Dean Willis; Paul Kyzivat CC: P2PSIP Mailing List Onderwerp: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario Michael, I agree with what you say but just cannot understand why you assume IMS = will matter for the Internet (it is supposed to be the last stand = against the Internet) and even if so, on what basis do you assume IMS = will ever change direction 180 degrees and adopt P2P?=20 Isn't IMS all about everything in the network and the endpoints are = under total control? Mobile operators may see the light and adopt P2P, but would it be IMS as = it is defined today? Can you help and explain? Thanks, Henry -----Original Message----- From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Thursday, April 05, 2007 1:21 PM To: Dean Willis; Paul Kyzivat Cc: P2PSIP Mailing List Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage = scenario I concur so much with Dean's description I may have to consider him a = competitor. ;) Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =20 Lead, Technology Initiatives slavitch@objectworld.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Apr 07 02:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha48b-0008Sy-Au; Sat, 07 Apr 2007 02:11:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha48a-0008St-Bh for p2psip@ietf.org; Sat, 07 Apr 2007 02:11:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha48Z-0001Nv-1X for p2psip@ietf.org; Sat, 07 Apr 2007 02:11:00 -0400 Received: from [192.168.2.116] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l375HPKb015979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2007 00:17:26 -0500 Message-ID: <461735E9.7010702@softarmor.com> Date: Sat, 07 Apr 2007 01:10:49 -0500 From: Dean Willis User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: colin.pons@kpn.com Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario References: <1fcd01c77705$94328870$81238182@cis.neustar.com><16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com><4614EFF9.6030702@cisco.com><4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: hsinnrei@adobe.com, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org colin.pons@kpn.com wrote: > > Now, I do not see how P2P would be incorporated into IMS. It would > render the HSS obsolete and hence IMS would loose much of it's value. > I would say Dean's decription sounds like an interesting path for > migrating IMS to P2P but not as a long term co-existence. > I would say, rather, that it transforms a complex and hard to maintain centralized HSS (or hierarchy of centralized HSS organized by a seperate but still centralized locator function) into an easier-to maintain and somewhat more robust distributed HSS with a fully-distributed and very fault-tolerant locator function. I suppose one could even implement the PEER protocol "GET" and "PUT" functions using DIAMETER so that legacy systems couldn't really tell the difference ;-). -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Apr 07 05:18:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha73i-0003Uz-Ix; Sat, 07 Apr 2007 05:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha73h-0003U6-DB for p2psip@ietf.org; Sat, 07 Apr 2007 05:18:09 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha73c-0006dO-OZ for p2psip@ietf.org; Sat, 07 Apr 2007 05:18:09 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 29C8544A40B; Sat, 7 Apr 2007 17:17:58 +0800 (CST) Message-ID: <001101c778f5$a4a2ecd0$a507740a@DELLWEI> From: "Wei Gengyu" To: "Dean Willis" References: <1fcd01c77705$94328870$81238182@cis.neustar.com><16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com><4614EFF9.6030702@cisco.com><4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com><24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> <461735E9.7010702@softarmor.com> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Sat, 7 Apr 2007 17:17:59 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799568624==" Errors-To: p2psip-bounces@ietf.org --===============0799568624== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 U29tZXRoaW5nIGhlcmUgYXQgbGVhc3QuDQoNClRoZSBkZXBsb3llZCBITFIgaW4gYSBwcm92aW5j ZSBoZXJlIGlzIGNlbnRyYWxpemVkLCBhbmQgSExScyBiZXR3ZWVuIHByb3ZpbmNlcyBhcmUgcGVl cnMuDQpUaGUgY29uZmlndXJhdGlvbiBvZiBTQ1BzIGluIElOIGFyZSB0aGUgc2FtZS4gDQoNClRo ZSBIU1Mgc2hvdWxkIGJlIGNlbnRyYWxpemVkLCBidXQgaXQgaXMgbm90IHRvIGtub3cgaG93IEhT UyB3aWxsIGJlIG9yZ2FuaXplZC4NCg0KU28gdGhlIHBlZXItdG8tcGVlcmUgcHJvdG9jb2wgbWF5 IGJlIHVzZWQgYmV0d2VlbiB0aGUgSExSIG9yIEhTUyBvZiBlYWNoIHByb3ZpbmNlIA0Kd2hpbGUg dGhlIHByb3RvY29sIGluIHVzZSBpcyBDQU1FTCwgb3IgdGhlIGxpa2UuDQoNCkdlbmd5dQ0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRlYW4gV2lsbGlzIiA8ZGVhbi53 aWxsaXNAc29mdGFybW9yLmNvbT4NClRvOiA8Y29saW4ucG9uc0BrcG4uY29tPg0KQ2M6IDxoc2lu bnJlaUBhZG9iZS5jb20+OyA8cDJwc2lwQGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIEFwcmls IDA3LCAyMDA3IDI6MTAgUE0NClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBSRTogW1AyUHJnXSBSRTog W1NpcHBpbmddIFNpbXBsZSBTSVAgdXNhZ2Ugc2NlbmFyaW8NCg0KDQo+IGNvbGluLnBvbnNAa3Bu LmNvbSB3cm90ZToNCj4+IA0KPj4gTm93LCBJIGRvIG5vdCBzZWUgaG93IFAyUCB3b3VsZCBiZSBp bmNvcnBvcmF0ZWQgaW50byBJTVMuIEl0IHdvdWxkDQo+PiByZW5kZXIgdGhlIEhTUyBvYnNvbGV0 ZSBhbmQgaGVuY2UgSU1TIHdvdWxkIGxvb3NlIG11Y2ggb2YgaXQncyB2YWx1ZS4NCj4+IEkgd291 bGQgc2F5IERlYW4ncyBkZWNyaXB0aW9uIHNvdW5kcyBsaWtlIGFuIGludGVyZXN0aW5nIHBhdGgg Zm9yDQo+PiBtaWdyYXRpbmcgSU1TIHRvIFAyUCBidXQgbm90IGFzIGEgbG9uZyB0ZXJtIGNvLWV4 aXN0ZW5jZS4NCj4+IA0KPiANCj4gSSB3b3VsZCBzYXksIHJhdGhlciwgdGhhdCBpdCB0cmFuc2Zv cm1zIGEgY29tcGxleCBhbmQgaGFyZCB0byBtYWludGFpbiANCj4gY2VudHJhbGl6ZWQgSFNTIChv ciBoaWVyYXJjaHkgb2YgY2VudHJhbGl6ZWQgSFNTIG9yZ2FuaXplZCBieSBhIHNlcGVyYXRlIA0K PiBidXQgc3RpbGwgY2VudHJhbGl6ZWQgbG9jYXRvciBmdW5jdGlvbikgaW50byBhbiBlYXNpZXIt dG8gbWFpbnRhaW4gYW5kIA0KPiBzb21ld2hhdCBtb3JlIHJvYnVzdCBkaXN0cmlidXRlZCBIU1Mg d2l0aCBhIGZ1bGx5LWRpc3RyaWJ1dGVkIGFuZCB2ZXJ5IA0KPiBmYXVsdC10b2xlcmFudCBsb2Nh dG9yIGZ1bmN0aW9uLg0KDQoNCj4gDQo+IEkgc3VwcG9zZSBvbmUgY291bGQgZXZlbiBpbXBsZW1l bnQgdGhlIFBFRVIgcHJvdG9jb2wgIkdFVCIgYW5kICJQVVQiIA0KPiBmdW5jdGlvbnMgdXNpbmcg RElBTUVURVIgc28gdGhhdCBsZWdhY3kgc3lzdGVtcyBjb3VsZG4ndCByZWFsbHkgdGVsbCB0aGUg DQo+IGRpZmZlcmVuY2UgOy0pLg0KPiANCj4gDQo+IC0tDQo+IERlYW4NCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5n IGxpc3QNCj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3AycHNpcA0KPg== --===============0799568624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0799568624==-- From p2psip-bounces@ietf.org Sun Apr 08 14:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hacbt-0006w4-02; Sun, 08 Apr 2007 14:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HacPM-0008BC-PT for p2psip@ietf.org; Sun, 08 Apr 2007 14:46:36 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HacPJ-0004rg-Fo for p2psip@ietf.org; Sun, 08 Apr 2007 14:46:36 -0400 Received: by py-out-1112.google.com with SMTP id f31so807089pyh for ; Sun, 08 Apr 2007 11:46:29 -0700 (PDT) Received: by 10.115.92.2 with SMTP id u2mr1994896wal.1176057988887; Sun, 08 Apr 2007 11:46:28 -0700 (PDT) Received: by 10.115.88.19 with HTTP; Sun, 8 Apr 2007 11:46:28 -0700 (PDT) Message-ID: Date: Sun, 8 Apr 2007 14:46:28 -0400 From: "Michael Slavitch" To: "Wei Gengyu" , p2psip@ietf.org Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario In-Reply-To: <001101c778f5$a4a2ecd0$a507740a@DELLWEI> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1fcd01c77705$94328870$81238182@cis.neustar.com> <16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com> <4614EFF9.6030702@cisco.com> <4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> <461735E9.7010702@softarmor.com> <001101c778f5$a4a2ecd0$a507740a@DELLWEI> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Sun, 08 Apr 2007 14:59:32 -0400 Cc: Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yes, however the approach you describe is only possible in peer protocols that support implicit structure and heirarchy otherwise decisions regarding which node is authoritative will require a 3rd party system, which begins to defeat the purpose of the whole enterprise. On 4/7/07, Wei Gengyu wrote: > Something here at least. > > The deployed HLR in a province here is centralized, and HLRs between provinces are peers. > The configuration of SCPs in IN are the same. > > The HSS should be centralized, but it is not to know how HSS will be organized. > > So the peer-to-peere protocol may be used between the HLR or HSS of each province > while the protocol in use is CAMEL, or the like. > > Gengyu > > ----- Original Message ----- > From: "Dean Willis" > To: > Cc: ; > Sent: Saturday, April 07, 2007 2:10 PM > Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario > > > > colin.pons@kpn.com wrote: > >> > >> Now, I do not see how P2P would be incorporated into IMS. It would > >> render the HSS obsolete and hence IMS would loose much of it's value. > >> I would say Dean's decription sounds like an interesting path for > >> migrating IMS to P2P but not as a long term co-existence. > >> > > > > I would say, rather, that it transforms a complex and hard to maintain > > centralized HSS (or hierarchy of centralized HSS organized by a seperate > > but still centralized locator function) into an easier-to maintain and > > somewhat more robust distributed HSS with a fully-distributed and very > > fault-tolerant locator function. > > > > > > I suppose one could even implement the PEER protocol "GET" and "PUT" > > functions using DIAMETER so that legacy systems couldn't really tell the > > difference ;-). > > > > > > -- > > Dean > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 08 15:13:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HacpW-0003X2-MY; Sun, 08 Apr 2007 15:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HacpV-0003Wa-I0 for p2psip@ietf.org; Sun, 08 Apr 2007 15:13:37 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hacky-0001b3-5Z for p2psip@ietf.org; Sun, 08 Apr 2007 15:08:57 -0400 Received: by nz-out-0506.google.com with SMTP id z6so998963nzd for ; Sun, 08 Apr 2007 12:08:53 -0700 (PDT) Received: by 10.114.210.2 with SMTP id i2mr2004896wag.1176059333462; Sun, 08 Apr 2007 12:08:53 -0700 (PDT) Received: by 10.115.88.19 with HTTP; Sun, 8 Apr 2007 12:08:53 -0700 (PDT) Message-ID: Date: Sun, 8 Apr 2007 15:08:53 -0400 From: "Michael Slavitch" To: "Dean Willis" , colin.pons@kpn.com, hsinnrei@adobe.com, p2psip@ietf.org Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario In-Reply-To: <461735E9.7010702@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1fcd01c77705$94328870$81238182@cis.neustar.com> <16F43AD1-FE10-449D-80BB-890832587EC9@softarmor.com> <4614EFF9.6030702@cisco.com> <4E2DC1ACE541B94A946B8D8657E372C57A911B@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF5C@namail5.corp.adobe.com> <461735E9.7010702@softarmor.com> X-Google-Sender-Auth: 443e4ea741399fd4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry wrote: "Isn't IMS all about everything in the network and the endpoints are under total control?" Yes. However I fear that the flipside is no better, a pure-peer environment without any control may create a tragedy of the Internet commons, one that expects something for nothing without boundries or checks and balances. There is a vast gulf between greedy Stalinist totalitarianism and doctrinaire anarchy. "Mobile operators may see the light and adopt P2P, but would it be IMS as it is defined today?" Certainly not. IMS as it stands today will go the way of FDDI and ATM et al. What a P2P successor will be called depends on who is doing the marketing. Gigabit Ethernet isn't coax CDMA either. Just try buying a token-ring or FDDI card. If I had the answers to these questions they'd be in a set of power-point slides doing the VC samba on Sand Hill Road. The mobiles will adopt it under the following circumstances: 1. It puts the issue of recurring revenues to bed long enough for a bond issue. 2. It permits a level of certainty regarding customer retention. 3. It allows them to offer different services at different prices to different people. 4. It allows them to shrink their OPEX enough to make more and charge less. 5. It keeps E911/DHS/FBI/NSA happy enough. 6. It allows them to do what they do best, bury costs in ongoing charges and fees. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 08 15:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hacsd-0007ML-Qh; Sun, 08 Apr 2007 15:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hacsc-0007MD-Mj; Sun, 08 Apr 2007 15:16:50 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hacsb-0003ML-CP; Sun, 08 Apr 2007 15:16:50 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l38JGbkG029179; Sun, 8 Apr 2007 15:16:38 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: FW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Sun, 8 Apr 2007 15:16:09 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd6EhaKK5/NwcMzSCSNddSCuPdu8QAAAcfA From: "Michael Slavitch" To: , "P2PSIP Mailing List" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org "Isn't IMS all about everything in the network and the endpoints are under total control?" Yes. However I fear that the flipside is no better, a pure-peer environment without any control may create a tragedy of the Internet commons, one that expects something for nothing without boundries or checks and balances. There is a vast gulf between greedy Stalinist totalitarianism and doctrinaire anarchy. "Mobile operators may see the light and adopt P2P, but would it be IMS as it is defined today?" Certainly not. IMS as it stands today will go the way of FDDI and ATM et al. Too expensive, too complex, and not enough value. What a P2P successor could be called depends on who is doing the marketing. Gigabit Ethernet isn't coax CDMA either. Just try buying a token-ring or FDDI card. If I had the answers to these questions they'd be in a set of power-point slides doing the VC samba on Sand Hill Road. The mobiles will adopt it under the following circumstances: 1. It puts the issue of recurring revenues to bed long enough for a bond issue. 2. It permits a level of certainty regarding customer retention. 3. It allows them to offer different services at different prices to different people. 4. It allows them to shrink their OPEX enough to make more and charge less. 5. It keeps E911/DHS/FBI/NSA happy enough. 6. It allows them to do what they do best, bury costs in ongoing charges and fees. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 09 16:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb0VM-0006qi-6Y; Mon, 09 Apr 2007 16:30:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb006-0002ly-6R; Mon, 09 Apr 2007 15:58:07 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HazzX-0001Ox-Vg; Mon, 09 Apr 2007 15:58:05 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Mon, 09 Apr 2007 12:57:19 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l39JvDSd027756; Mon, 9 Apr 2007 12:57:14 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l39Jv2I9017452; Mon, 9 Apr 2007 12:57:02 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 12:57:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Mon, 9 Apr 2007 12:57:11 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd6EhaKK5/NwcMzSCSNddSCuPdu8QAAAcfAADKJASA= References: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> From: "Henry Sinnreich" To: "Michael Slavitch" , , "P2PSIP Mailing List" X-OriginalArrivalTime: 09 Apr 2007 19:57:12.0246 (UTC) FILETIME=[43866560:01C77AE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >However I fear that the flipside is no better, a pure-peer environment >without any control may create a tragedy of the Internet commons, one >that expects something for nothing without boundries or checks and >balances. 100% agreement here. The DHT overlay and SIP part require strong identity: The krypto keys issued by the owner of the P2P SIP network. Not less but also not more. To prevent Sybil attacks, the certificate issuer can use various options that go beyond our topic discussed here. Henry -----Original Message----- From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Sunday, April 08, 2007 2:16 PM To: p2prg@ietf.org; P2PSIP Mailing List Subject: FW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario "Isn't IMS all about everything in the network and the endpoints are under total control?" Yes. However I fear that the flipside is no better, a pure-peer environment without any control may create a tragedy of the Internet commons, one that expects something for nothing without boundries or checks and balances. There is a vast gulf between greedy Stalinist totalitarianism and doctrinaire anarchy. "Mobile operators may see the light and adopt P2P, but would it be IMS as it is defined today?" Certainly not. IMS as it stands today will go the way of FDDI and ATM et al. Too expensive, too complex, and not enough value. What a P2P successor could be called depends on who is doing the marketing. Gigabit Ethernet isn't coax CDMA either. Just try buying a token-ring or FDDI card. If I had the answers to these questions they'd be in a set of power-point slides doing the VC samba on Sand Hill Road. The mobiles will adopt it under the following circumstances: 1. It puts the issue of recurring revenues to bed long enough for a bond issue. 2. It permits a level of certainty regarding customer retention. 3. It allows them to offer different services at different prices to different people. 4. It allows them to shrink their OPEX enough to make more and charge less. 5. It keeps E911/DHS/FBI/NSA happy enough. 6. It allows them to do what they do best, bury costs in ongoing charges and fees. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 ----------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=20 Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 09 18:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb26a-0005jF-CO; Mon, 09 Apr 2007 18:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb26Z-0005j4-Od; Mon, 09 Apr 2007 18:12:55 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb26Y-0000dU-C2; Mon, 09 Apr 2007 18:12:55 -0400 Received: from [192.168.2.102] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l39LJHNC017841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2007 16:19:20 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> References: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Mon, 9 Apr 2007 17:12:36 -0500 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: p2prg@ietf.org, P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 9, 2007, at 2:57 PM, Henry Sinnreich wrote: >> However I fear that the flipside is no better, a pure-peer >> environment >> without any control may create a tragedy of the Internet commons, one >> that expects something for nothing without boundries or checks and >> balances. > > 100% agreement here. > > The DHT overlay and SIP part require strong identity: The krypto keys > issued by the owner of the P2P SIP network. Not less but also not > more. There are, of course, people interested in "ownerless" P2PSIP overlays. A model of how this might work uses a "first come, first served" model, something like: An "ownerless" overlay exists at overlay.example.org. It uses a distributed file-store model to store public credentials. Bob makes himself a self-signed cert. Bob uses this self-signed cert to enroll in the overlay, which works as long as there is nobody else named Bob@overlay.example.org (first come first severd). As a result, Bob's public cert is stored in the overlay. Bob then inserts into the overlay using his private key, which establishes that he is the previously registered Bob. And people talk to him. Now, nothing says I can't come along and register as Henry, if Henry hasn't already done so. So the names don't really "mean" anything -- they're just index values that are human memorable so you can know that the Henry you talk to today is the same as the Henry you talked to last week. Now, if the whole overlay resets such that the name-enrollments are lost, everybody gets to re-enroll, and there's a land-rush on being called Henry instead of Bob (or vice-versa). -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 09 19:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3dy-0004UV-Ot; Mon, 09 Apr 2007 19:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3dx-0004UN-RE; Mon, 09 Apr 2007 19:51:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb3dv-0005Ga-Ek; Mon, 09 Apr 2007 19:51:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Apr 2007 19:51:27 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l39NpRJk025017; Mon, 9 Apr 2007 19:51:27 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l39NpKlG026168; Mon, 9 Apr 2007 23:51:20 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 19:51:20 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 19:51:20 -0400 Message-ID: <461AD178.7060005@cisco.com> Date: Mon, 09 Apr 2007 19:51:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario References: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> In-Reply-To: <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 23:51:20.0226 (UTC) FILETIME=[F8C60820:01C77B01] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2115; t=1176162687; x=1177026687; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[P2Prg]=20RE=3A=20[Sipping]=20Simp le=20SIP=20usage=20scenario |Sender:=20 |To:=20Dean=20Willis=20; bh=oJ8GYFDP72Y3E0IiR9k8ZNjndlcrT5+FR+EdD0IDKkA=; b=HYjUOlIWhez29LIfdL9TqMFXnAyJNfn0ssjnQOxVbA9zsHecchJ34L6gyj7jjOJGD7xDmwQr MpcUeTiEhsxkxlt1QW5RNstm02zmcc30590ABKY5Jn7b33/FdsjDvikJ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Henry Sinnreich , p2prg@ietf.org, P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean, In such a scenario, I gather there is no way for an outside caller to know that the Henry today is based on a different enrollment than the Henry from yesterday? Paul Dean Willis wrote: > > On Apr 9, 2007, at 2:57 PM, Henry Sinnreich wrote: > >>> However I fear that the flipside is no better, a pure-peer environment >>> without any control may create a tragedy of the Internet commons, one >>> that expects something for nothing without boundries or checks and >>> balances. >> >> 100% agreement here. >> >> The DHT overlay and SIP part require strong identity: The krypto keys >> issued by the owner of the P2P SIP network. Not less but also not more. > > There are, of course, people interested in "ownerless" P2PSIP overlays. > > A model of how this might work uses a "first come, first served" model, > something like: > > An "ownerless" overlay exists at overlay.example.org. It uses a > distributed file-store model to store public credentials. > > Bob makes himself a self-signed cert. > > Bob uses this self-signed cert to enroll in the overlay, which works as > long as there is nobody else named Bob@overlay.example.org (first come > first severd). As a result, Bob's public cert is stored in the overlay. > > Bob then inserts into the overlay using his private key, which > establishes that he is the previously registered Bob. > > And people talk to him. > > Now, nothing says I can't come along and register as Henry, if Henry > hasn't already done so. So the names don't really "mean" anything -- > they're just index values that are human memorable so you can know that > the Henry you talk to today is the same as the Henry you talked to last > week. > > Now, if the whole overlay resets such that the name-enrollments are > lost, everybody gets to re-enroll, and there's a land-rush on being > called Henry instead of Bob (or vice-versa). > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 09 19:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3gr-0006AU-RP; Mon, 09 Apr 2007 19:54:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3gq-00069P-4k; Mon, 09 Apr 2007 19:54:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb3go-0006KC-8L; Mon, 09 Apr 2007 19:54:28 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2007 16:54:25 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l39NsPuh006163; Mon, 9 Apr 2007 16:54:25 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l39NrnAc028454; Mon, 9 Apr 2007 23:54:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 19:54:23 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 19:54:23 -0400 Message-ID: <461AD230.8060207@cisco.com> Date: Mon, 09 Apr 2007 19:54:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario References: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> In-Reply-To: <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 23:54:23.0296 (UTC) FILETIME=[65E44C00:01C77B02] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2069; t=1176162865; x=1177026865; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[P2Prg]=20RE=3A=20[Sipping]=20Simp le=20SIP=20usage=20scenario |Sender:=20; bh=pHWjsCjRI6aBxDRgYuJmagrE6tX828Ft3cz8ihuL4UE=; b=DYHUY/kY5Iajfu1cNuVzOPQHqOVdcT2lA3lFwSFcYV9VWeKmNFEIWyuM6scZKC7l4XyfBctw cgXgv6MBs402i7kO1zKuLhU0xWfdaQcSPA80iYF/n8Zvi1tzjEnfoTIU; Authentication-Results: sj-dkim-5; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Henry Sinnreich , p2prg@ietf.org, P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org BTW, This sounds very much like the a server for nicknames that seems to be a requirement for chat proposal over in SIMPLE. Paul Dean Willis wrote: > > On Apr 9, 2007, at 2:57 PM, Henry Sinnreich wrote: > >>> However I fear that the flipside is no better, a pure-peer environment >>> without any control may create a tragedy of the Internet commons, one >>> that expects something for nothing without boundries or checks and >>> balances. >> >> 100% agreement here. >> >> The DHT overlay and SIP part require strong identity: The krypto keys >> issued by the owner of the P2P SIP network. Not less but also not more. > > There are, of course, people interested in "ownerless" P2PSIP overlays. > > A model of how this might work uses a "first come, first served" model, > something like: > > An "ownerless" overlay exists at overlay.example.org. It uses a > distributed file-store model to store public credentials. > > Bob makes himself a self-signed cert. > > Bob uses this self-signed cert to enroll in the overlay, which works as > long as there is nobody else named Bob@overlay.example.org (first come > first severd). As a result, Bob's public cert is stored in the overlay. > > Bob then inserts into the overlay using his private key, which > establishes that he is the previously registered Bob. > > And people talk to him. > > Now, nothing says I can't come along and register as Henry, if Henry > hasn't already done so. So the names don't really "mean" anything -- > they're just index values that are human memorable so you can know that > the Henry you talk to today is the same as the Henry you talked to last > week. > > Now, if the whole overlay resets such that the name-enrollments are > lost, everybody gets to re-enroll, and there's a land-rush on being > called Henry instead of Bob (or vice-versa). > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 09 20:14:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3zy-0000ch-EG; Mon, 09 Apr 2007 20:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3zx-0000c1-1q; Mon, 09 Apr 2007 20:14:13 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb3zu-0000oD-MF; Mon, 09 Apr 2007 20:14:12 -0400 Received: from [192.168.2.102] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l39NKe0l018381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2007 18:20:40 -0500 In-Reply-To: <461AD178.7060005@cisco.com> References: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> <461AD178.7060005@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A465494-A790-4A65-BE5A-ECED87730270@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Mon, 9 Apr 2007 19:13:58 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Henry Sinnreich , p2prg@ietf.org, P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 9, 2007, at 6:51 PM, Paul Kyzivat wrote: > Dean, > > In such a scenario, I gather there is no way for an outside caller > to know that the Henry today is based on a different enrollment > than the Henry from yesterday? > Well, one would hope the overlay was sufficiently stable that Henry lasts indefinitely, something like one of those army Meals Ready to Eat things (three lies in one box, we always called 'em. Not a Meal, not Ready, and you wouldn't want to Eat it.). Remember, enrollment is not registration. It persists as long as the distributed database doesn't get nuked or the enrollment isn't explicitly revoked. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 10 03:57:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbBDi-0003RS-ST; Tue, 10 Apr 2007 03:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbBDh-0003RK-Ir; Tue, 10 Apr 2007 03:56:53 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbBDd-0005rR-5w; Tue, 10 Apr 2007 03:56:53 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Tue, 10 Apr 2007 09:56:20 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 09:56:19 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Tue, 10 Apr 2007 09:56:19 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB77A@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <7A465494-A790-4A65-BE5A-ECED87730270@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario thread-index: Acd7BU3f9KA1QReISBea/8zmTVYMyAAPg8nA From: "Beck01, Wolfgang" To: , X-OriginalArrivalTime: 10 Apr 2007 07:56:19.0682 (UTC) FILETIME=[B966A420:01C77B45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > [discussion about unique nicknames and their registration] http://www.skyhunter.com/marcs/petnames/IntroPetNames.html discusses an interesting idea. It goes like this: - every user has a globally known nickname, which isn't necessarily unique.=20 - To ensure uniqueness, every user has some sort of public key. It is not memorable (a string of hex), though. - If I have different users with the same nickname in my address book, I'd locally assign different 'petnames' to them.=20 This scheme has some weaknesses, though. You would have to put your nickname and key on you business card (and worse, read the key from a business card and enter it into the client). It doesn't fit too well into SIP messages either = (sip:nickname?key0a12030bff7e39582b1c55626a@p2p.sip?) I'm not sure if it has been discussed already. Wolfgang (sorry about the long sig, EU regulations require it) -- T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 10 11:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbI9t-00035A-9r; Tue, 10 Apr 2007 11:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbI9s-00034v-1W; Tue, 10 Apr 2007 11:21:24 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbI9q-0001Zh-MV; Tue, 10 Apr 2007 11:21:24 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l3AFLEkt002007; Tue, 10 Apr 2007 11:21:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Apr 2007 11:21:01 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A9182@photon.objectworld.com> In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB77A@S4DE9JSAAIG.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd7BU3f9KA1QReISBea/8zmTVYMyAAPg8nAABANxIA= References: <7A465494-A790-4A65-BE5A-ECED87730270@softarmor.com> <1E4CCB2441C5C0409AD8A929482A09F31BB77A@S4DE9JSAAIG.ost.t-com.de> From: "Michael Slavitch" To: "Beck01, Wolfgang" , , X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org "This scheme has some weaknesses, though. You would have to put your nickname and key on you business card (and worse, read the=20 key from a business card and enter it into the client). It doesn't fit too well into SIP messages either (sip:nickname?key0a12030bff7e39582b1c556= 26a@p2p.sip?)" Smartcard-enabled business cards, like hotel room pass keys, solve this issue and more, and many PC's support smart-card readers. Other solutions for this include using a bar code on the back of the card, bar code readers are cheap too. Many people use OCR for scanned business cards already, which is fraught with errors, scanning and reading a bar-code is easy. If the identity is a machine-readable key use a machine-readable card to solve the problem. They are cheap. Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com -----Original Message----- From: Beck01, Wolfgang [mailto:BeckW@t-systems.com]=20 Sent: Tuesday, April 10, 2007 3:56 AM To: p2prg@ietf.org; p2psip@ietf.org Subject: AW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario > [discussion about unique nicknames and their registration] http://www.skyhunter.com/marcs/petnames/IntroPetNames.html discusses an interesting idea. It goes like this: - every user has a globally known nickname, which isn't necessarily unique.=20 - To ensure uniqueness, every user has some sort of public key. It is not memorable (a string of hex), though. - If I have different users with the same nickname in my address book, I'd locally assign different 'petnames' to them.=20 This scheme has some weaknesses, though. You would have to put your nickname and key on you business card (and worse, read the key from a business card and enter it into the client). It doesn't fit too well into SIP messages either (sip:nickname?key0a12030bff7e39582b1c5562= 6a@p2p.sip?) I'm not sure if it has been discussed already. Wolfgang (sorry about the long sig, EU regulations require it) -- T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert He= nn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 10 13:59:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKcr-0006jp-80; Tue, 10 Apr 2007 13:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKcp-0006ja-Cg; Tue, 10 Apr 2007 13:59:27 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbKcn-0001cp-Ve; Tue, 10 Apr 2007 13:59:27 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Tue, 10 Apr 2007 10:58:48 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3AHwgSd018160; Tue, 10 Apr 2007 10:58:46 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3AHwO1A001887; Tue, 10 Apr 2007 10:58:41 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:58:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Tue, 10 Apr 2007 10:58:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226B2655@namail5.corp.adobe.com> In-Reply-To: <461AD230.8060207@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd7AmtiCvNz+pmuT1+vWsd0kPmXiQAlt3mA References: <4E2DC1ACE541B94A946B8D8657E372C57A9145@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D223ADF87@namail5.corp.adobe.com> <56555EC2-DFF2-4B10-8546-B4403CBAF53C@softarmor.com> <461AD230.8060207@cisco.com> From: "Henry Sinnreich" To: "Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 10 Apr 2007 17:58:39.0030 (UTC) FILETIME=[DE218560:01C77B99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: p2prg@ietf.org, P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Actually, I believe Dean's idea makes sense without any server and ownership - just like in http://openid.net/=20 Could this concept of lack of ownership in http://openid.net/ be applied to ownerless p2p systems? Ownerless P2P systems would be a powerful and complementary alternative to service provider P2P. What do you think? Thanks, Henry -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, April 09, 2007 4:54 PM To: Dean Willis Cc: Henry Sinnreich; p2prg@ietf.org; P2PSIP Mailing List Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario BTW, This sounds very much like the a server for nicknames that seems to be a requirement for chat proposal over in SIMPLE. Paul Dean Willis wrote: >=20 > On Apr 9, 2007, at 2:57 PM, Henry Sinnreich wrote: >=20 >>> However I fear that the flipside is no better, a pure-peer environment >>> without any control may create a tragedy of the Internet commons, one >>> that expects something for nothing without boundries or checks and >>> balances. >> >> 100% agreement here. >> >> The DHT overlay and SIP part require strong identity: The krypto keys >> issued by the owner of the P2P SIP network. Not less but also not more. >=20 > There are, of course, people interested in "ownerless" P2PSIP overlays. >=20 > A model of how this might work uses a "first come, first served" model,=20 > something like: >=20 > An "ownerless" overlay exists at overlay.example.org. It uses a=20 > distributed file-store model to store public credentials. >=20 > Bob makes himself a self-signed cert. >=20 > Bob uses this self-signed cert to enroll in the overlay, which works as=20 > long as there is nobody else named Bob@overlay.example.org (first come > first severd). As a result, Bob's public cert is stored in the overlay. >=20 > Bob then inserts into the overlay using his private key, which=20 > establishes that he is the previously registered Bob. >=20 > And people talk to him. >=20 > Now, nothing says I can't come along and register as Henry, if Henry=20 > hasn't already done so. So the names don't really "mean" anything --=20 > they're just index values that are human memorable so you can know that=20 > the Henry you talk to today is the same as the Henry you talked to last=20 > week. >=20 > Now, if the whole overlay resets such that the name-enrollments are=20 > lost, everybody gets to re-enroll, and there's a land-rush on being=20 > called Henry instead of Bob (or vice-versa). >=20 > --=20 > Dean >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 10 14:32:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbL8c-00065Y-NW; Tue, 10 Apr 2007 14:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbL8Y-0005ua-Ir for p2psip@ietf.org; Tue, 10 Apr 2007 14:32:14 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbL8W-0000om-Gm for p2psip@ietf.org; Tue, 10 Apr 2007 14:32:14 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l3AIW6sI005406 for ; Tue, 10 Apr 2007 14:32:06 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C77B9E.8AE1189C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 10 Apr 2007 14:31:19 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C57A91A6@photon.objectworld.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd7njpW7FB9jkX6T8abqIW6wd2vnAAAAsEg From: "Michael Slavitch" To: X-Spam-Score: 0.70 () [Tag at 20.00] HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C77B9E.8AE1189C Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_002_01C77B9E.8AE1189C" ------_=_NextPart_002_01C77B9E.8AE1189C Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C77B9E.8AE1189C" ------_=_NextPart_003_01C77B9E.8AE1189C Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Disposition: inline IA0KDQpGcm9tOiBNaWNoYWVsIFNsYXZpdGNoIFttYWlsdG86c2xhdml0Y2hA Z21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDA3IDI6 MjkgUE0NClRvOiBIZW5yeSBTaW5ucmVpY2gNCkNjOiBQYXVsIEt5eml2YXQ7 IHAycHJnQGlldGYub3JnOyBQMlBTSVAgTWFpbGluZyBMaXN0OyBEZWFuIFdp bGxpcw0KU3ViamVjdDogUmU6IFtQMlBTSVBdIFJFOiBbUDJQcmddIFJFOiBb U2lwcGluZ10gU2ltcGxlIFNJUCB1c2FnZSBzY2VuYXJpbw0KDQogDQoNCkkg YWdyZWUgd2l0aCB0aGlzIGdpdmVuIHRoZSBmb2xsb3dpbmcgY2F2ZWF0czog ICANCg0KDQotIFdpdGhvdXQgYW4gb3duZXIgeW91IG5lZWQgYWdyZWVtZW50 IGFuZCBlbmZvcmNlbWVudCBhbW9uZ3N0IHBlZXJzLiAgU29tZXRoaW5nIGhh cyB0byBwb2xpY2UsIGFuZCBzb21ldGhpbmcgaGFzIHRvIHBvbGljZSB0aGUg cG9saWNlbWVuLg0KLSBUaGUgY2FycmllcnMgYnkgY29udHJhc3Qgb2ZmZXIg YSBmZXVkYWwgbWVudGFsaXR5IHdoZXJlIHRoZSBjYXJyaWVycyBvd24gdGhl IGxhbmQgYW5kIG1ha2UgdGhlIGxhd3MgYXMgd2VsbCBhcyBlbmZvcmNlIHRo ZW0uICANCi0gSGlzdG9yeSBpcyBsaXR0ZXJlZCB3aXRoIGV4YW1wbGVzIG9m IHBlb3BsZSByZXZlcnRpbmcgdG8gZmV1ZGFsaXNtIHdoZW4gbW9yZSBkZW1v Y3JhdGljIGFsdGVybmF0aXZlcyBmYWlsLg0KLSBVbmxlc3Mgb3duZXJsZXNz IFAyUCBzeXN0ZW1zIGhhdmUgc3Ryb25nIGxhd3MgcmVnYXJkaW5nIGJlaGF2 aW91ciBhbmQgc3Ryb25nIHNlY3VyaXR5IGFuZCB0cnVzdCB0aGV5IHdpbGwg ZmFpbCBhbmQgcGVvcGxlIHdpbGwgcmV2ZXJ0IHRvIHRoZSBmYW1pbGlhci4g DQotIEl0IG1pZ2h0IGJlIGVhc2llciB0byBtYWludGFpbiB0aGUgY2Fycmll ci9raW5ncyBhcyB0b290aGxlc3MgZmlndXJlaGVhZHMgdGhhbiBhdHRlbXB0 IGEgcmV2b2x1dGlvbi4NCi0gTHVja2lseSBtdWNoIGxpa2UgaW4gaGlzdG9y eSB0aGUgY2Fycmllci9raW5ncyBzZWVtIGNvbnRlbnQgdG8gdGhpcyBmYXRl IGFzIGxvbmcgYXMgdGhleSByZW1haW4gd2VhbHRoeSBhbmQgZG8gbm8gd29y ayBhdCBhbGwgd2hpbGUgbWFpbnRhaW5pbmcgYnJhbmQuDQoNCiANCg0KIA0K DQogIDxodHRwOi8vd3d3Lm9iamVjdHdvcmxkLmNvbS8+IA0KDQogDQoNCgkJ IAkgDQpNaWNoYWVsIFNsYXZpdGNoICAgICAgICAgICAgICANCg0KTGVhZCwg VGVjaG5vbG9neSBJbml0aWF0aXZlcw0KDQpzbGF2aXRjaEBvYmplY3R3b3Js ZC5jb20NCg0KCQkgCSANCg0KIA0KDQogDQoNCg0KUmVnYXJkcw0KDQpNaWNo YWVsDQoNCk9uIDQvMTAvMDcsIEhlbnJ5IFNpbm5yZWljaCA8aHNpbm5yZWlA YWRvYmUuY29tPiB3cm90ZToNCg0KQWN0dWFsbHksIEkgYmVsaWV2ZSBEZWFu J3MgaWRlYSBtYWtlcyBzZW5zZSB3aXRob3V0IGFueSBzZXJ2ZXIgYW5kDQpv d25lcnNoaXAgLSBqdXN0IGxpa2UgaW4gaHR0cDovL29wZW5pZC5uZXQvDQoN CkNvdWxkIHRoaXMgY29uY2VwdCBvZiBsYWNrIG9mIG93bmVyc2hpcCBpbiBo dHRwOi8vb3BlbmlkLm5ldC8gYmUgYXBwbGllZA0KdG8gb3duZXJsZXNzIHAy cCBzeXN0ZW1zPw0KDQpPd25lcmxlc3MgUDJQIHN5c3RlbXMgd291bGQgYmUg YSBwb3dlcmZ1bCBhbmQgY29tcGxlbWVudGFyeSBhbHRlcm5hdGl2ZQ0KdG8g c2VydmljZSBwcm92aWRlciBQMlAuIFdoYXQgZG8geW91IHRoaW5rPw0KDQpU aGFua3MsIEhlbnJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0K RnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAY2lzY28uY29t XQ0KU2VudDogTW9uZGF5LCBBcHJpbCAwOSwgMjAwNyA0OjU0IFBNDQpUbzog RGVhbiBXaWxsaXMNCkNjOiBIZW5yeSBTaW5ucmVpY2g7IHAycHJnQGlldGYu b3JnIDsgUDJQU0lQIE1haWxpbmcgTGlzdA0KU3ViamVjdDogUmU6IFtQMlBT SVBdIFJFOiBbUDJQcmddIFJFOiBbU2lwcGluZ10gU2ltcGxlIFNJUCB1c2Fn ZQ0Kc2NlbmFyaW8NCg0KQlRXLA0KDQpUaGlzIHNvdW5kcyB2ZXJ5IG11Y2gg bGlrZSB0aGUgYSBzZXJ2ZXIgZm9yIG5pY2tuYW1lcyB0aGF0IHNlZW1zIHRv IGJlIGENCg0KcmVxdWlyZW1lbnQgZm9yIGNoYXQgcHJvcG9zYWwgb3ZlciBp biBTSU1QTEUuIA0KDQogICAgICAgIFBhdWwNCg0KRGVhbiBXaWxsaXMgd3Jv dGU6DQo+DQo+IE9uIEFwciA5LCAyMDA3LCBhdCAyOjU3IFBNLCBIZW5yeSBT aW5ucmVpY2ggd3JvdGU6DQo+DQo+Pj4gSG93ZXZlciBJIGZlYXIgdGhhdCB0 aGUgZmxpcHNpZGUgaXMgbm8gYmV0dGVyLCBhIHB1cmUtcGVlcg0KZW52aXJv bm1lbnQNCj4+PiB3aXRob3V0IGFueSBjb250cm9sIG1heSBjcmVhdGUgYSB0 cmFnZWR5IG9mIHRoZSBJbnRlcm5ldCBjb21tb25zLCANCm9uZQ0KPj4+IHRo YXQgZXhwZWN0cyBzb21ldGhpbmcgZm9yIG5vdGhpbmcgd2l0aG91dCBib3Vu ZHJpZXMgb3IgY2hlY2tzIGFuZA0KPj4+IGJhbGFuY2VzLg0KPj4NCj4+IDEw MCUgYWdyZWVtZW50IGhlcmUuDQo+Pg0KPj4gVGhlIERIVCBvdmVybGF5IGFu ZCBTSVAgcGFydCByZXF1aXJlIHN0cm9uZyBpZGVudGl0eTogVGhlIGtyeXB0 byBrZXlzIA0KPj4gaXNzdWVkIGJ5IHRoZSBvd25lciBvZiB0aGUgUDJQIFNJ UCBuZXR3b3JrLiBOb3QgbGVzcyBidXQgYWxzbyBub3QNCm1vcmUuDQo+DQo+ IFRoZXJlIGFyZSwgb2YgY291cnNlLCBwZW9wbGUgaW50ZXJlc3RlZCBpbiAi b3duZXJsZXNzIiBQMlBTSVANCm92ZXJsYXlzLg0KPg0KPiBBIG1vZGVsIG9m IGhvdyB0aGlzIG1pZ2h0IHdvcmsgdXNlcyBhICJmaXJzdCBjb21lLCBmaXJz dCBzZXJ2ZWQiIA0KbW9kZWwsDQo+IHNvbWV0aGluZyBsaWtlOg0KPg0KPiBB biAib3duZXJsZXNzIiBvdmVybGF5IGV4aXN0cyBhdCBvdmVybGF5LmV4YW1w bGUub3JnLiBJdCB1c2VzIGENCj4gZGlzdHJpYnV0ZWQgZmlsZS1zdG9yZSBt b2RlbCB0byBzdG9yZSBwdWJsaWMgY3JlZGVudGlhbHMuIA0KPg0KPiBCb2Ig bWFrZXMgaGltc2VsZiBhIHNlbGYtc2lnbmVkIGNlcnQuDQo+DQo+IEJvYiB1 c2VzIHRoaXMgc2VsZi1zaWduZWQgY2VydCB0byBlbnJvbGwgaW4gdGhlIG92 ZXJsYXksIHdoaWNoIHdvcmtzDQphcw0KPiBsb25nIGFzIHRoZXJlIGlzIG5v Ym9keSBlbHNlIG5hbWVkIEJvYkBvdmVybGF5LmV4YW1wbGUub3JnIChmaXJz dCBjb21lDQoNCj4gZmlyc3Qgc2V2ZXJkKS4gQXMgYSByZXN1bHQsIEJvYidz IHB1YmxpYyBjZXJ0IGlzIHN0b3JlZCBpbiB0aGUNCm92ZXJsYXkuDQo+DQo+ IEJvYiB0aGVuIGluc2VydHMgaW50byB0aGUgb3ZlcmxheSB1c2luZyBoaXMg cHJpdmF0ZSBrZXksIHdoaWNoDQo+IGVzdGFibGlzaGVzIHRoYXQgaGUgaXMg dGhlIHByZXZpb3VzbHkgcmVnaXN0ZXJlZCBCb2IuIA0KPg0KPiBBbmQgcGVv cGxlIHRhbGsgdG8gaGltLg0KPg0KPiBOb3csIG5vdGhpbmcgc2F5cyBJIGNh bid0IGNvbWUgYWxvbmcgYW5kIHJlZ2lzdGVyIGFzIEhlbnJ5LCBpZiBIZW5y eQ0KPiBoYXNuJ3QgYWxyZWFkeSBkb25lIHNvLiBTbyB0aGUgbmFtZXMgZG9u J3QgcmVhbGx5ICJtZWFuIiBhbnl0aGluZyAtLSANCj4gdGhleSdyZSBqdXN0 IGluZGV4IHZhbHVlcyB0aGF0IGFyZSBodW1hbiBtZW1vcmFibGUgc28geW91 IGNhbiBrbm93DQp0aGF0DQo+IHRoZSBIZW5yeSB5b3UgdGFsayB0byB0b2Rh eSBpcyB0aGUgc2FtZSBhcyB0aGUgSGVucnkgeW91IHRhbGtlZCB0bw0KbGFz dA0KPiB3ZWVrLg0KPg0KPiBOb3csIGlmIHRoZSB3aG9sZSBvdmVybGF5IHJl c2V0cyBzdWNoIHRoYXQgdGhlIG5hbWUtZW5yb2xsbWVudHMgYXJlIA0KPiBs b3N0LCBldmVyeWJvZHkgZ2V0cyB0byByZS1lbnJvbGwsIGFuZCB0aGVyZSdz IGEgbGFuZC1ydXNoIG9uIGJlaW5nDQo+IGNhbGxlZCBIZW5yeSBpbnN0ZWFk IG9mIEJvYiAob3IgdmljZS12ZXJzYSkuDQo+DQo+IC0tDQo+IERlYW4NCj4N Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18gDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3AycHNpcA0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyANClAycHJnIG1haWxpbmcgbGlzdA0KUDJw cmdAaXJ0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycHJnDQoNCg0KDQoNCi0tIA0KTWljaGFlbCBTbGF2aXRjaA0K T3R0YXdhIE9udGFyaW8gQ2FuYWRhIA0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQoNCg0KCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoaXMgdHJhbnNtaXNzaW9u IChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGlu Y2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1j bGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29u c3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRo aXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVu ZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVk aWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGlu Zm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFu c21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRo b3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIA0KDQpBbnkgdmlld3MsIG9w aW5pb25zIGFuZCBjb250ZW50IHByZXNlbnRlZCBpbiB0aGlzIGUtbWFpbCBh cmUgc29sZWx5IHRob3NlIG9mIHRoZSBhdXRob3IgYW5kIG1heSBub3QgcmVw cmVzZW50IHRob3NlIG9mIE9iamVjdHdvcmxkIENvbW11bmljYXRpb25zIENv cnAuIAo= ------_=_NextPart_003_01C77B9E.8AE1189C Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 Content-Disposition: inline PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9m ZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5v cmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0 Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29m dCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYgIW1zb10+ DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9 DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9y OnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4N CjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpz cGFuLmdtYWlscXVvdGUNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWxfcXVvdGU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0K QHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtw YWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjIwNTAiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2 IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PiBNaWNoYWVsIFNsYXZpdGNoDQpbbWFpbHRvOnNsYXZpdGNoQGdtYWlsLmNv bV0gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEwLCAyMDA3 IDI6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IEhlbnJ5IFNpbm5yZWljaDxicj4N CjxiPkNjOjwvYj4gUGF1bCBLeXppdmF0OyBwMnByZ0BpZXRmLm9yZzsgUDJQ U0lQIE1haWxpbmcgTGlzdDsgRGVhbiBXaWxsaXM8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtQMlBTSVBdIFJFOiBbUDJQcmddIFJFOiBbU2lwcGluZ10g U2ltcGxlIFNJUCB1c2FnZQ0Kc2NlbmFyaW88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPkkgYWdyZWUgd2l0aCB0aGlzIGdpdmVuIHRo ZQ0KZm9sbG93aW5nIGNhdmVhdHM6Jm5ic3A7Jm5ic3A7IDxicj4NCjxicj4N Cjxicj4NCi0gV2l0aG91dCBhbiBvd25lciB5b3UgbmVlZCBhZ3JlZW1lbnQg YW5kIGVuZm9yY2VtZW50IGFtb25nc3QgcGVlcnMuJm5ic3A7DQpTb21ldGhp bmcgaGFzIHRvIHBvbGljZSwgYW5kIHNvbWV0aGluZyBoYXMgdG8gcG9saWNl IHRoZSBwb2xpY2VtZW4uPGJyPg0KLSBUaGUgY2FycmllcnMgYnkgY29udHJh c3Qgb2ZmZXIgYSBmZXVkYWwgbWVudGFsaXR5IHdoZXJlIHRoZSBjYXJyaWVy cyBvd24gdGhlDQpsYW5kIGFuZCBtYWtlIHRoZSBsYXdzIGFzIHdlbGwgYXMg ZW5mb3JjZSB0aGVtLiZuYnNwOyA8YnI+DQotIEhpc3RvcnkgaXMgbGl0dGVy ZWQgd2l0aCBleGFtcGxlcyBvZiBwZW9wbGUgcmV2ZXJ0aW5nIHRvIGZldWRh bGlzbSB3aGVuIG1vcmUNCmRlbW9jcmF0aWMgYWx0ZXJuYXRpdmVzIGZhaWwu PGJyPg0KLSBVbmxlc3Mgb3duZXJsZXNzIFAyUCBzeXN0ZW1zIGhhdmUgc3Ry b25nIGxhd3MgcmVnYXJkaW5nIGJlaGF2aW91ciBhbmQgc3Ryb25nDQpzZWN1 cml0eSBhbmQgdHJ1c3QgdGhleSB3aWxsIGZhaWwgYW5kIHBlb3BsZSB3aWxs IHJldmVydCB0byB0aGUgZmFtaWxpYXIuIDxicj4NCi0gSXQgbWlnaHQgYmUg ZWFzaWVyIHRvIG1haW50YWluIHRoZSBjYXJyaWVyL2tpbmdzIGFzIHRvb3Ro bGVzcyBmaWd1cmVoZWFkcw0KdGhhbiBhdHRlbXB0IGEgcmV2b2x1dGlvbi48 YnI+DQotIEx1Y2tpbHkgbXVjaCBsaWtlIGluIGhpc3RvcnkgdGhlIGNhcnJp ZXIva2luZ3Mgc2VlbSBjb250ZW50IHRvIHRoaXMgZmF0ZSBhcw0KbG9uZyBh cyB0aGV5IHJlbWFpbiB3ZWFsdGh5IGFuZCBkbyBubyB3b3JrIGF0IGFsbCB3 aGlsZSBtYWludGFpbmluZyBicmFuZC48bzpwPjwvbzpwPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQoNCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxU YWJsZSBib3JkZXI9MSBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lk dGg9IjEwMCUiDQogc3R5bGU9J3dpZHRoOjEwMC4wJTtib3JkZXItY29sbGFw c2U6Y29sbGFwc2U7Ym9yZGVyOm5vbmUnPg0KIDx0cj4NCiAgPHRkIHdpZHRo PTYzOCBjb2xzcGFuPTQgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6Ni42NWlu O2JvcmRlcjpub25lOw0KICBib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7YmFja2dyb3VuZDp3aGl0ZTtwYWRkaW5nOjBpbiA1LjRwdCAwaW4g NS40cHQnPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCiAgY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0cj4NCiAgPHRkIHdpZHRoPTI4 NiB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoyMTQuNTVwdDtib3JkZXI6bm9u ZTtiYWNrZ3JvdW5kOndoaXRlOw0KICBwYWRkaW5nOjBpbiAwaW4gMGluIDBp bic+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJodHRwOi8vd3d3 Lm9iamVjdHdvcmxkLmNvbS8iDQogIHRpdGxlPSJPYmplY3R3b3JsZCBDb21t dW5pY2F0aW9ucyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6DQogICJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh Y2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUnPjxpbWcgYm9yZGVyPTANCiAgd2lk dGg9MjM3IGhlaWdodD00MiBpZD0iUGljdHVyZV94MDAyMF8xIg0KICBzcmM9 ImNpZDppbWFnZTAwMS5qcGdAMDFDNzdCN0MuRTc0NjNFNTAiIGFsdD0iY29y cF8yY29sb3VyIj48L3NwYW4+PC9hPjxzcGFuDQogIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQogIGNvbG9yOmJs YWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQogIDwvdGQ+DQog IDx0ZCB3aWR0aD0yMTEgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MTU4LjA1 cHQ7Ym9yZGVyOm5vbmU7YmFja2dyb3VuZDp3aGl0ZTsNCiAgcGFkZGluZzow aW4gMGluIDBpbiAwaW4nPjwvdGQ+DQogIDx0ZCB3aWR0aD0xMzcgdmFsaWdu PXRvcCBzdHlsZT0nd2lkdGg6MTAyLjZwdDtib3JkZXI6bm9uZTtiYWNrZ3Jv dW5kOndoaXRlOw0KICBwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PC90ZD4N CiAgPHRkIHN0eWxlPSdib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbicgd2lkdGg9Mj48cCBjbGFzcz0nTXNvTm9ybWFsJz4mbmJzcDs8L3Rk Pg0KIDwvdHI+DQogPHRyPg0KICA8dGQgd2lkdGg9Mjg2IHZhbGlnbj10b3Ag c3R5bGU9J3dpZHRoOjIxNC41NXB0O2JvcmRlcjpub25lO2JhY2tncm91bmQ6 d2hpdGU7DQogIHBhZGRpbmc6MGluIDBpbiAwaW4gMGluJz4NCiAgPHRhYmxl IGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAg Y2VsbHBhZGRpbmc9MA0KICAgc3R5bGU9J2JvcmRlci1jb2xsYXBzZTpjb2xs YXBzZSc+DQogICA8dHI+DQogICAgPHRkIHdpZHRoPTI3OCB2YWxpZ249dG9w IHN0eWxlPSd3aWR0aDoyMDguNHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Jz4NCiAgICA8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCiAgICBjb2xvcjpibGFjayc+TWljaGFlbA0KICAgIFNsYXZpdGNoJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7wqDCoMKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAg ICA8L3RkPg0KICAgPC90cj4NCiAgIDx0cj4NCiAgICA8dGQgd2lkdGg9Mjc4 IHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjIwOC40cHQ7cGFkZGluZzowaW4g MGluIDBpbiAwaW4nPg0KICAgIDxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KICAgIGNvbG9yOmJsYWNrJz5MZWFkLCBUZWNobm9s b2d5IEluaXRpYXRpdmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KICAgIDwv dGQ+DQogICA8L3RyPg0KICAgPHRyPg0KICAgIDx0ZCB3aWR0aD0yNzggdmFs aWduPXRvcCBzdHlsZT0nd2lkdGg6MjA4LjRwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDBpbic+DQogICAgPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQogICAgY29sb3I6YmxhY2snPnNsYXZpdGNoQG9iamVjdHdv cmxkLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgICA8L3RkPg0KICAg PC90cj4NCiAgPC90YWJsZT4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPTIxMSB2 YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoxNTguMDVwdDtib3JkZXI6bm9uZTti YWNrZ3JvdW5kOndoaXRlOw0KICBwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+ PC90ZD4NCiAgPHRkIHdpZHRoPTEzNyB2YWxpZ249dG9wIHN0eWxlPSd3aWR0 aDoxMDIuNnB0O2JvcmRlcjpub25lO2JhY2tncm91bmQ6d2hpdGU7DQogIHBh ZGRpbmc6MGluIDBpbiAwaW4gMGluJz48L3RkPg0KICA8dGQgc3R5bGU9J2Jv cmRlcjpub25lO3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJyB3aWR0aD0yPjxw IGNsYXNzPSdNc29Ob3JtYWwnPiZuYnNwOzwvdGQ+DQogPC90cj4NCjwvdGFi bGU+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KY29sb3I6YmxhY2s7bGV0dGVyLXNwYWNpbmc6LS41cHQnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PGk+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt YXJnaW4tYm90dG9tOjEyLjBwdCc+PGJyPg0KUmVnYXJkczxicj4NCjxicj4N Ck1pY2hhZWw8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWdtYWlscXVvdGU+T24gNC8xMC8wNywg PGI+SGVucnkgU2lubnJlaWNoPC9iPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpo c2lubnJlaUBhZG9iZS5jb20iPmhzaW5ucmVpQGFkb2JlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPkFjdHVhbGx5LCBJIGJlbGlldmUgRGVhbidzIGlkZWEgbWFrZXMg c2Vuc2Ugd2l0aG91dCBhbnkNCnNlcnZlciBhbmQ8YnI+DQpvd25lcnNoaXAg LSBqdXN0IGxpa2UgaW4gPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvIj5o dHRwOi8vb3BlbmlkLm5ldC88L2E+PGJyPg0KPGJyPg0KQ291bGQgdGhpcyBj b25jZXB0IG9mIGxhY2sgb2Ygb3duZXJzaGlwIGluIDxhIGhyZWY9Imh0dHA6 Ly9vcGVuaWQubmV0LyI+aHR0cDovL29wZW5pZC5uZXQvPC9hPg0KYmUgYXBw bGllZDxicj4NCnRvIG93bmVybGVzcyBwMnAgc3lzdGVtcz88YnI+DQo8YnI+ DQpPd25lcmxlc3MgUDJQIHN5c3RlbXMgd291bGQgYmUgYSBwb3dlcmZ1bCBh bmQgY29tcGxlbWVudGFyeSBhbHRlcm5hdGl2ZTxicj4NCnRvIHNlcnZpY2Ug cHJvdmlkZXIgUDJQLiBXaGF0IGRvIHlvdSB0aGluaz88YnI+DQo8YnI+DQpU aGFua3MsIEhlbnJ5PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gPGJyPg0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnBreXppdmF0QGNpc2NvLmNvbSI+cGt5eml2YXRAY2lzY28u Y29tPC9hPl08YnI+DQpTZW50OiBNb25kYXksIEFwcmlsIDA5LCAyMDA3IDQ6 NTQgUE08YnI+DQpUbzogRGVhbiBXaWxsaXM8YnI+DQpDYzogSGVucnkgU2lu bnJlaWNoOyA8YSBocmVmPSJtYWlsdG86cDJwcmdAaWV0Zi5vcmciPnAycHJn QGlldGYub3JnPC9hPiA7DQpQMlBTSVAgTWFpbGluZyBMaXN0PGJyPg0KU3Vi amVjdDogUmU6IFtQMlBTSVBdIFJFOiBbUDJQcmddIFJFOiBbU2lwcGluZ10g U2ltcGxlIFNJUCB1c2FnZTxicj4NCnNjZW5hcmlvPGJyPg0KPGJyPg0KQlRX LDxicj4NCjxicj4NClRoaXMgc291bmRzIHZlcnkgbXVjaCBsaWtlIHRoZSBh IHNlcnZlciBmb3Igbmlja25hbWVzIHRoYXQgc2VlbXMgdG8gYmUgYTxicj4N Cjxicj4NCnJlcXVpcmVtZW50IGZvciBjaGF0IHByb3Bvc2FsIG92ZXIgaW4g U0lNUExFLiA8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQYXVsPGJyPg0KPGJyPg0KRGVhbiBX aWxsaXMgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gQXByIDksIDIw MDcsIGF0IDI6NTcgUE0sIEhlbnJ5IFNpbm5yZWljaCB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEhvd2V2ZXIgSSBmZWFyIHRoYXQgdGhl IGZsaXBzaWRlIGlzIG5vIGJldHRlciwgYSBwdXJlLXBlZXI8YnI+DQplbnZp cm9ubWVudDxicj4NCiZndDsmZ3Q7Jmd0OyB3aXRob3V0IGFueSBjb250cm9s IG1heSBjcmVhdGUgYSB0cmFnZWR5IG9mIHRoZSBJbnRlcm5ldCBjb21tb25z LCA8YnI+DQpvbmU8YnI+DQomZ3Q7Jmd0OyZndDsgdGhhdCBleHBlY3RzIHNv bWV0aGluZyBmb3Igbm90aGluZyB3aXRob3V0IGJvdW5kcmllcyBvciBjaGVj a3MgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7IGJhbGFuY2VzLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgMTAwJSBhZ3JlZW1lbnQgaGVyZS48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBESFQgb3ZlcmxheSBhbmQgU0lQ IHBhcnQgcmVxdWlyZSBzdHJvbmcgaWRlbnRpdHk6IFRoZSBrcnlwdG8ga2V5 cyA8YnI+DQomZ3Q7Jmd0OyBpc3N1ZWQgYnkgdGhlIG93bmVyIG9mIHRoZSBQ MlAgU0lQIG5ldHdvcmsuIE5vdCBsZXNzIGJ1dCBhbHNvIG5vdDxicj4NCm1v cmUuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUgYXJlLCBvZiBjb3Vyc2Us IHBlb3BsZSBpbnRlcmVzdGVkIGluICZxdW90O293bmVybGVzcyZxdW90OyBQ MlBTSVA8YnI+DQpvdmVybGF5cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIG1v ZGVsIG9mIGhvdyB0aGlzIG1pZ2h0IHdvcmsgdXNlcyBhICZxdW90O2ZpcnN0 IGNvbWUsIGZpcnN0IHNlcnZlZCZxdW90Ow0KPGJyPg0KbW9kZWwsPGJyPg0K Jmd0OyBzb21ldGhpbmcgbGlrZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbiAm cXVvdDtvd25lcmxlc3MmcXVvdDsgb3ZlcmxheSBleGlzdHMgYXQgPGENCmhy ZWY9Imh0dHA6Ly9vdmVybGF5LmV4YW1wbGUub3JnIj5vdmVybGF5LmV4YW1w bGUub3JnPC9hPi4gSXQgdXNlcyBhPGJyPg0KJmd0OyBkaXN0cmlidXRlZCBm aWxlLXN0b3JlIG1vZGVsIHRvIHN0b3JlIHB1YmxpYyBjcmVkZW50aWFscy4g PGJyPg0KJmd0Ozxicj4NCiZndDsgQm9iIG1ha2VzIGhpbXNlbGYgYSBzZWxm LXNpZ25lZCBjZXJ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEJvYiB1c2VzIHRo aXMgc2VsZi1zaWduZWQgY2VydCB0byBlbnJvbGwgaW4gdGhlIG92ZXJsYXks IHdoaWNoIHdvcmtzPGJyPg0KYXM8YnI+DQomZ3Q7IGxvbmcgYXMgdGhlcmUg aXMgbm9ib2R5IGVsc2UgbmFtZWQgPGEgaHJlZj0ibWFpbHRvOkJvYkBvdmVy bGF5LmV4YW1wbGUub3JnIj5Cb2JAb3ZlcmxheS5leGFtcGxlLm9yZzwvYT4N CihmaXJzdCBjb21lPGJyPg0KPGJyPg0KJmd0OyBmaXJzdCBzZXZlcmQpLiBB cyBhIHJlc3VsdCwgQm9iJ3MgcHVibGljIGNlcnQgaXMgc3RvcmVkIGluIHRo ZTxicj4NCm92ZXJsYXkuPGJyPg0KJmd0Ozxicj4NCiZndDsgQm9iIHRoZW4g aW5zZXJ0cyBpbnRvIHRoZSBvdmVybGF5IHVzaW5nIGhpcyBwcml2YXRlIGtl eSwgd2hpY2g8YnI+DQomZ3Q7IGVzdGFibGlzaGVzIHRoYXQgaGUgaXMgdGhl IHByZXZpb3VzbHkgcmVnaXN0ZXJlZCBCb2IuIDxicj4NCiZndDs8YnI+DQom Z3Q7IEFuZCBwZW9wbGUgdGFsayB0byBoaW0uPGJyPg0KJmd0Ozxicj4NCiZn dDsgTm93LCBub3RoaW5nIHNheXMgSSBjYW4ndCBjb21lIGFsb25nIGFuZCBy ZWdpc3RlciBhcyBIZW5yeSwgaWYgSGVucnk8YnI+DQomZ3Q7IGhhc24ndCBh bHJlYWR5IGRvbmUgc28uIFNvIHRoZSBuYW1lcyBkb24ndCByZWFsbHkgJnF1 b3Q7bWVhbiZxdW90Ow0KYW55dGhpbmcgLS0gPGJyPg0KJmd0OyB0aGV5J3Jl IGp1c3QgaW5kZXggdmFsdWVzIHRoYXQgYXJlIGh1bWFuIG1lbW9yYWJsZSBz byB5b3UgY2FuIGtub3c8YnI+DQp0aGF0PGJyPg0KJmd0OyB0aGUgSGVucnkg eW91IHRhbGsgdG8gdG9kYXkgaXMgdGhlIHNhbWUgYXMgdGhlIEhlbnJ5IHlv dSB0YWxrZWQgdG88YnI+DQpsYXN0PGJyPg0KJmd0OyB3ZWVrLjxicj4NCiZn dDs8YnI+DQomZ3Q7IE5vdywgaWYgdGhlIHdob2xlIG92ZXJsYXkgcmVzZXRz IHN1Y2ggdGhhdCB0aGUgbmFtZS1lbnJvbGxtZW50cyBhcmUgPGJyPg0KJmd0 OyBsb3N0LCBldmVyeWJvZHkgZ2V0cyB0byByZS1lbnJvbGwsIGFuZCB0aGVy ZSdzIGEgbGFuZC1ydXNoIG9uIGJlaW5nPGJyPg0KJmd0OyBjYWxsZWQgSGVu cnkgaW5zdGVhZCBvZiBCb2IgKG9yIHZpY2UtdmVyc2EpLjxicj4NCiZndDs8 YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBEZWFuPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIDxicj4NCiZndDsgUDJQU0lQIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOlAyUFNJUEBpZXRmLm9yZyI+ UDJQU0lQQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIj5odHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L2E+ PGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIDxicj4NClAycHJnIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpQMnByZ0BpcnRmLm9yZyI+UDJw cmdAaXJ0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwcmciPmh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHJnPC9hPjxvOnA+PC9vOnA+ PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxicj4NCjxi ciBjbGVhcj1hbGw+DQo8YnI+DQotLSA8YnI+DQpNaWNoYWVsIFNsYXZpdGNo PGJyPg0KT3R0YXdhIE9udGFyaW8gQ2FuYWRhIDxvOnA+PC9vOnA+PC9wPg0K DQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIg c3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48c3Bhbg0Kc3R5bGU9J2ZvbnQt c2l6ZToxMy41cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSc+DQoN CjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj4NCg0KPC9z cGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMy41cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0 ZSc+PGJyPg0KPGENCmhyZWY9Imh0dHA6Ly9jYW5pdHByby1pbnQub2JqZWN0 d29ybGQuY29tL2Nhbml0L2IucGhwP2k9NjYwNTc0JmFtcDttPTMxMzc3ZjZk MWI5NyZhbXA7Yz1zIj5TcGFtPC9hPjxicj4NCjxhDQpocmVmPSJodHRwOi8v Y2FuaXRwcm8taW50Lm9iamVjdHdvcmxkLmNvbS9jYW5pdC9iLnBocD9pPTY2 MDU3NCZhbXA7bT0zMTM3N2Y2ZDFiOTcmYW1wO2M9biI+Tm90DQpzcGFtPC9h Pjxicj4NCjxhDQpocmVmPSJodHRwOi8vY2FuaXRwcm8taW50Lm9iamVjdHdv cmxkLmNvbS9jYW5pdC9iLnBocD9pPTY2MDU3NCZhbXA7bT0zMTM3N2Y2ZDFi OTcmYW1wO2M9ZiI+Rm9yZ2V0DQpwcmV2aW91cyB2b3RlPC9hPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8aHIgd2lk dGg9IjEwMCUiPg0KPGZvbnQgc2l6ZT0iLTIiPjxwPg0KVGhpcyB0cmFuc21p c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlh bCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNp dG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBv ciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ug b2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2Ug aW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90 IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48L3A+DQoNCjxwPkFu eSB2aWV3cywgb3BpbmlvbnMgYW5kIGNvbnRlbnQgcHJlc2VudGVkIGluIHRo aXMgZS1tYWlsIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQg bWF5IG5vdCByZXByZXNlbnQgdGhvc2Ugb2YgT2JqZWN0d29ybGQgQ29tbXVu aWNhdGlvbnMgQ29ycC48L3A+DQo8L2ZvbnQ+CjwvYm9keT4NCg0KPC9odG1s Pg0K ------_=_NextPart_003_01C77B9E.8AE1189C-- ------_=_NextPart_002_01C77B9E.8AE1189C Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_002_01C77B9E.8AE1189C-- ------_=_NextPart_001_01C77B9E.8AE1189C Content-Type: text/plain; name="ATT426740.txt" Content-Transfer-Encoding: base64 Content-Description: ATT426740.txt Content-Disposition: inline; filename="ATT426740.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NClAycHJnIG1haWxpbmcgbGlzdA0KUDJwcmdAaXJ0Zi5vcmcNCmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHJnDQo= ------_=_NextPart_001_01C77B9E.8AE1189C Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_001_01C77B9E.8AE1189C-- From p2psip-bounces@ietf.org Tue Apr 10 14:50:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLQ1-00020B-0V; Tue, 10 Apr 2007 14:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLPz-000201-FU for p2psip@ietf.org; Tue, 10 Apr 2007 14:50:15 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbLPx-00077P-3t for p2psip@ietf.org; Tue, 10 Apr 2007 14:50:15 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 10 Apr 2007 11:50:11 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3AIncD1017720; Tue, 10 Apr 2007 11:49:39 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3AIo70e010252; Tue, 10 Apr 2007 11:50:08 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:50:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Tue, 10 Apr 2007 11:50:01 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226B26A3@namail5.corp.adobe.com> In-Reply-To: <4E2DC1ACE541B94A946B8D8657E372C57A91A6@photon.objectworld.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd7njpW7FB9jkX6T8abqIW6wd2vnAAAAsEgAAB0qrA= References: <4E2DC1ACE541B94A946B8D8657E372C57A91A6@photon.objectworld.com> From: "Henry Sinnreich" To: "Michael Slavitch" , X-OriginalArrivalTime: 10 Apr 2007 18:50:06.0570 (UTC) FILETIME=[0E72BCA0:01C77BA1] X-Spam-Score: 0.5 (/) X-Scan-Signature: 717d651095a319b49fc3b6c7b72cb4dd Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0740628883==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0740628883== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C77BA1.0BD0C87E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77BA1.0BD0C87E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C77BA1.0BD0C87E" ------_=_NextPart_002_01C77BA1.0BD0C87E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are a few usage scenarios where ownerless P2P makes sense:=20 =20 In emergency situations, during natural or man made disasters, when disconnected form the Internet, the ownerless p2p may be the life saver. =20 Also, on the battlefield there is the agreement and strong enforcement among peers. =20 Last but not least, a group of fans going to car race or some other event and wandering around. This may seem a more trivial pursuit but has some user appeal. =20 Thanks, Henry =20 ________________________________ From: Michael Slavitch [mailto:slavitch@objectworld.com]=20 Sent: Tuesday, April 10, 2007 11:31 AM To: p2psip@ietf.org Subject: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 =20 From: Michael Slavitch [mailto:slavitch@gmail.com]=20 Sent: Tuesday, April 10, 2007 2:29 PM To: Henry Sinnreich Cc: Paul Kyzivat; p2prg@ietf.org; P2PSIP Mailing List; Dean Willis Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario =20 I agree with this given the following caveats: =20 - Without an owner you need agreement and enforcement amongst peers. Something has to police, and something has to police the policemen. - The carriers by contrast offer a feudal mentality where the carriers own the land and make the laws as well as enforce them. =20 - History is littered with examples of people reverting to feudalism when more democratic alternatives fail. - Unless ownerless P2P systems have strong laws regarding behaviour and strong security and trust they will fail and people will revert to the familiar.=20 - It might be easier to maintain the carrier/kings as toothless figureheads than attempt a revolution. - Luckily much like in history the carrier/kings seem content to this fate as long as they remain wealthy and do no work at all while maintaining brand. =20 =20 =20 =20 =20 =20 =20 Michael Slavitch =20 Lead, Technology Initiatives slavitch@objectworld.com =20 =20 =20 =20 =20 Regards Michael On 4/10/07, Henry Sinnreich wrote: Actually, I believe Dean's idea makes sense without any server and ownership - just like in http://openid.net/ Could this concept of lack of ownership in http://openid.net/ be applied to ownerless p2p systems? Ownerless P2P systems would be a powerful and complementary alternative to service provider P2P. What do you think? Thanks, Henry -----Original Message-----=20 From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, April 09, 2007 4:54 PM To: Dean Willis Cc: Henry Sinnreich; p2prg@ietf.org ; P2PSIP Mailing List Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario BTW, This sounds very much like the a server for nicknames that seems to be a requirement for chat proposal over in SIMPLE.=20 Paul Dean Willis wrote: > > On Apr 9, 2007, at 2:57 PM, Henry Sinnreich wrote: > >>> However I fear that the flipside is no better, a pure-peer environment >>> without any control may create a tragedy of the Internet commons,=20 one >>> that expects something for nothing without boundries or checks and >>> balances. >> >> 100% agreement here. >> >> The DHT overlay and SIP part require strong identity: The krypto keys >> issued by the owner of the P2P SIP network. Not less but also not more. > > There are, of course, people interested in "ownerless" P2PSIP overlays. > > A model of how this might work uses a "first come, first served"=20 model, > something like: > > An "ownerless" overlay exists at overlay.example.org. It uses a > distributed file-store model to store public credentials.=20 > > Bob makes himself a self-signed cert. > > Bob uses this self-signed cert to enroll in the overlay, which works as > long as there is nobody else named Bob@overlay.example.org (first come > first severd). As a result, Bob's public cert is stored in the overlay. > > Bob then inserts into the overlay using his private key, which > establishes that he is the previously registered Bob.=20 > > And people talk to him. > > Now, nothing says I can't come along and register as Henry, if Henry > hasn't already done so. So the names don't really "mean" anything --=20 > they're just index values that are human memorable so you can know that > the Henry you talk to today is the same as the Henry you talked to last > week. > > Now, if the whole overlay resets such that the name-enrollments are=20 > lost, everybody gets to re-enroll, and there's a land-rush on being > called Henry instead of Bob (or vice-versa). > > -- > Dean > > > _______________________________________________=20 > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________=20 P2prg mailing list P2prg@irtf.org https://www1.ietf.org/mailman/listinfo/p2prg --=20 Michael Slavitch Ottawa Ontario Canada=20 ________________________________ Spam =20 Not spam =20 Forget previous vote =20 ________________________________ This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp. ------_=_NextPart_002_01C77BA1.0BD0C87E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are a few usage scenarios = where ownerless P2P makes sense:

 

In emergency situations, during natural or man made disasters, when disconnected form = the Internet, the ownerless p2p may be the life = saver.

 

Also, on the battlefield there is = the agreement and strong enforcement among = peers.

 

Last but not least, a group of fans = going to car race or some other event and wandering around. This may seem a = more trivial pursuit but has some user appeal.

 

Thanks, = Henry

 

From: = Michael Slavitch [mailto:slavitch@objectworld.com]
Sent: Tuesday, April 10, = 2007 11:31 AM
To: = p2psip@ietf.org
Subject: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

 

From: = Michael Slavitch [mailto:slavitch@gmail.com]
Sent: Tuesday, April 10, = 2007 2:29 PM
To: Henry Sinnreich
Cc: Paul Kyzivat; = p2prg@ietf.org; P2PSIP Mailing List; Dean Willis
Subject: Re: [P2PSIP] RE: = [P2Prg] RE: [Sipping] Simple SIP usage = scenario

 

I agree with = this given the following caveats:  


- Without an owner you need agreement and enforcement amongst = peers.  Something has to police, and something has to police the policemen.
- The carriers by contrast offer a feudal mentality where the carriers = own the land and make the laws as well as enforce them. 
- History is littered with examples of people reverting to feudalism = when more democratic alternatives fail.
- Unless ownerless P2P systems have strong laws regarding behaviour and = strong security and trust they will fail and people will revert to the = familiar.
- It might be easier to maintain the carrier/kings as toothless = figureheads than attempt a revolution.
- Luckily much like in history the carrier/kings seem content to this = fate as long as they remain wealthy and do no work at all while maintaining = brand.

 

 

3D"corp_2colour"

 

 

 

 

Michael = Slavitch           = ;  

Lead, = Technology Initiatives

slavitch@objec= tworld.com

 

 

 

 

 


Regards

Michael

On 4/10/07, Henry Sinnreich <hsinnrei@adobe.com> wrote:

Actually, I believe Dean's idea makes sense without any server = and
ownership - just like in http://openid.net/

Could this concept of lack of ownership in http://openid.net/ be applied
to ownerless p2p systems?

Ownerless P2P systems would be a powerful and complementary = alternative
to service provider P2P. What do you think?

Thanks, Henry

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
Sent: Monday, April 09, 2007 4:54 PM
To: Dean Willis
Cc: Henry Sinnreich; p2prg@ietf.org ; P2PSIP Mailing List
Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage
scenario

BTW,

This sounds very much like the a server for nicknames that seems to be = a

requirement for chat proposal over in SIMPLE.

        Paul

Dean Willis wrote:
>
> On Apr 9, 2007, at 2:57 PM, Henry Sinnreich wrote:
>
>>> However I fear that the flipside is no better, a = pure-peer
environment
>>> without any control may create a tragedy of the Internet = commons,
one
>>> that expects something for nothing without boundries or = checks and
>>> balances.
>>
>> 100% agreement here.
>>
>> The DHT overlay and SIP part require strong identity: The = krypto keys
>> issued by the owner of the P2P SIP network. Not less but also = not
more.
>
> There are, of course, people interested in "ownerless" = P2PSIP
overlays.
>
> A model of how this might work uses a "first come, first = served"
model,
> something like:
>
> An "ownerless" overlay exists at overlay.example.org. It uses = a
> distributed file-store model to store public credentials.
>
> Bob makes himself a self-signed cert.
>
> Bob uses this self-signed cert to enroll in the overlay, which = works
as
> long as there is nobody else named Bob@overlay.example.org (first come

> first severd). As a result, Bob's public cert is stored in the
overlay.
>
> Bob then inserts into the overlay using his private key, which
> establishes that he is the previously registered Bob.
>
> And people talk to him.
>
> Now, nothing says I can't come along and register as Henry, if = Henry
> hasn't already done so. So the names don't really "mean" = anything --
> they're just index values that are human memorable so you can = know
that
> the Henry you talk to today is the same as the Henry you talked = to
last
> week.
>
> Now, if the whole overlay resets such that the name-enrollments are =
> lost, everybody gets to re-enroll, and there's a land-rush on = being
> called Henry instead of Bob (or vice-versa).
>
> --
> Dean
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>

_______________________________________________
P2prg mailing list
P2prg@irtf.org
https://www1.ietf.o= rg/mailman/listinfo/p2prg




--
Michael Slavitch
Ottawa = Ontario Canada =

This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute non-public information. Any = use of this information by anyone other than the intended recipient is = prohibited. If you have received this transmission in error, please immediately reply = to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful.

Any views, opinions and content presented in this e-mail are solely those of the = author and may not represent those of Objectworld Communications = Corp.

------_=_NextPart_002_01C77BA1.0BD0C87E-- ------_=_NextPart_001_01C77BA1.0BD0C87E Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6 +0EbNruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHExlWYK4wpGMhue leLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9clnAj17UWQKd3+kNjPb+tN/s+6bR 21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHN R/8AAlv8a9P8NWv/AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1U9W1W00TSrjU76Qx 29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GFE6eqnPpzXoHzp19FZniHXIPDmhXOr3Mc ksNsoZkjxuOSBxn61ieHPiLpniHVV0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc 3dpDNClvcvbMJQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq39uaT FqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jHGM/M3Psa2tC1uy8RaPb6 rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFreaPqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+ w3Vj5hYeRdJskXBxyKANGisRvFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6v RZpDhd+8n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA2fxg0W4n Tz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumtpPNA+Zh3GD0oA26KiuJltraW dgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPKt7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8 kKcE9M5IrD1H4h6Hpltazzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+ jtPI2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1LvgEhv5V4sNKivt c+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m1u7X7PGJ4vL+zRoFMe3J3YHY5x9a 1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej 3PAy/C1qWJTmmkt+vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLNd74l0OHxJ4evNInk MSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZrKOGLYFXGMse5wf/AK9ekfLl74p/8k31 j/rmv/oa1xfhqXUW+IHhl/E0MVuf7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5 C4YHp+Fc5oHgDVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu11WK/ m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYHA9OBQByXjWXV4fi9oj6F b29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRqZ0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xa WxgBkg8zqWycHjo1dFoNtq1ppaQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs 9CsdDjg8OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/gK2/CHhuL wn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ceFpvFmlWtlDdJbNBdpcFnUsCF B44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1 Lx54N/4TPT7K2FwsDWt0sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/ AJoeP+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6Wv+oH+7/SvnjT 59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrzofC+5XwYNFXUoReQ6l9vt7nyzhD6 YznpmgD0RFCIqDooArz34S/e8Uf9hmWvQk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2 gYsC2SMnOOOOKAO41X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689GHQ1lT+EdCuQBLYK2 CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgBumKworm4ESATyYCj+M0j3M5KZnk4bj5z Xjey97c+4WK/dr3e39bG/ChiiCEjIz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5 OW5+c+lCpbu45YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckxNyf9 9q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFAH//Z ------_=_NextPart_001_01C77BA1.0BD0C87E-- --===============0740628883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0740628883==-- From p2psip-bounces@ietf.org Tue Apr 10 21:18:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbRTI-0007EP-Kj; Tue, 10 Apr 2007 21:18:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbRTH-0007EB-A3 for p2psip@ietf.org; Tue, 10 Apr 2007 21:18:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbRTG-0004PL-1Y for p2psip@ietf.org; Tue, 10 Apr 2007 21:18:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Apr 2007 21:17:59 -0400 X-IronPort-AV: i="4.14,392,1170651600"; d="scan'208"; a="118188954:sNHT45134788" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3B1HxHE005159; Tue, 10 Apr 2007 21:17:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3B1HrlG006400; Wed, 11 Apr 2007 01:17:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 21:17:53 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 21:17:52 -0400 Message-ID: <461C3740.2010904@cisco.com> Date: Tue, 10 Apr 2007 21:17:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario References: <4E2DC1ACE541B94A946B8D8657E372C57A91A6@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D226B26A3@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226B26A3@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 01:17:52.0970 (UTC) FILETIME=[3A4DA2A0:01C77BD7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=580; t=1176254279; x=1177118279; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[P2Prg]=20RE=3A=20[Sipping]=20Simp le=20SIP=20usage=20scenario |Sender:=20 |To:=20Henry=20Sinnreich=20; bh=wqrG58ssaFvklsuc6m2SRJwyCrKJQR8dJmAjb1uepe8=; b=b5YvkL+Jqyiavr8t8JHctDH5N+k2nnLiopRcaj4QVRoK6KwCsEUycHcF2DnMmgcTGKqcR6+M QL0juDcyg0t53gFDx13V2xg1IQbYMrpgUwmVQLVIWyxISODQRZhyBjzW; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry Sinnreich wrote: > Here are a few usage scenarios where ownerless P2P makes sense: > > > > In emergency situations, during natural or man made disasters, when > disconnected form the Internet, the ownerless p2p may be the life saver. > > > > Also, on the battlefield there is the agreement and strong enforcement > among peers. Maybe I'm missing something, but on the battlefield I think I would like to distinguish the guys on my side from the guys on the other side. With a truly ownerless system I don't think that is supported. Paul _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 10 22:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbSON-0008Ks-56; Tue, 10 Apr 2007 22:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHwq-0002jD-Hl for p2psip@ietf.org; Tue, 10 Apr 2007 11:07:56 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbHwp-000624-8d for p2psip@ietf.org; Tue, 10 Apr 2007 11:07:56 -0400 Received: by wr-out-0506.google.com with SMTP id i20so1663817wra for ; Tue, 10 Apr 2007 08:07:50 -0700 (PDT) Received: by 10.115.54.1 with SMTP id g1mr2824999wak.1176217670269; Tue, 10 Apr 2007 08:07:50 -0700 (PDT) Received: by 10.115.88.19 with HTTP; Tue, 10 Apr 2007 08:07:49 -0700 (PDT) Message-ID: Date: Tue, 10 Apr 2007 11:07:49 -0400 From: "Michael Slavitch" To: "Beck01, Wolfgang" Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB77A@S4DE9JSAAIG.ost.t-com.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7A465494-A790-4A65-BE5A-ECED87730270@softarmor.com> <1E4CCB2441C5C0409AD8A929482A09F31BB77A@S4DE9JSAAIG.ost.t-com.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Tue, 10 Apr 2007 22:17:01 -0400 Cc: p2prg@ietf.org, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >You would have to put > your nickname and key on you business card (and worse, read the > key from a business card and enter it into the client). It doesn't fit > too well into SIP messages either Smartcard-enabled business cards, like hotel room pass keys, solve this issue and more, and many PC's support smart-card readers. Other solutions for this include using a bar code on the back of the card, bar code readers are cheap too. Many people use OCR for scanned business cards already, which is fraught with errors, scanning and reading a bar-code is easy. M On 4/10/07, Beck01, Wolfgang wrote: > > > > [discussion about unique nicknames and their registration] > http://www.skyhunter.com/marcs/petnames/IntroPetNames.html > discusses an interesting idea. It goes like this: > > - every user has a globally known nickname, which isn't > necessarily unique. > - To ensure uniqueness, every user has some sort of public key. > It is not memorable (a string of hex), though. > - If I have different users with the same nickname in my address book, > I'd locally assign different 'petnames' to them. > > This scheme has some weaknesses, though. You would have to put > your nickname and key on you business card (and worse, read the > key from a business card and enter it into the client). It doesn't fit > too well into SIP messages either (sip:nickname?key0a12030bff7e39582b1c55= 626a@p2p.sip?) > > I'm not sure if it has been discussed already. > > > Wolfgang > > > > > (sorry about the long sig, EU regulations require it) > -- > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, > Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 10 23:40:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbThS-0005F6-NH; Tue, 10 Apr 2007 23:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbThS-0005F1-5Z for p2psip@ietf.org; Tue, 10 Apr 2007 23:40:50 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbThQ-00065r-Ch for p2psip@ietf.org; Tue, 10 Apr 2007 23:40:50 -0400 Received: from DELLWEI (unknown [125.33.207.132]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 64EEDAC252E; Wed, 11 Apr 2007 11:40:43 +0800 (CST) Message-ID: <003501c77beb$2f744af0$0500a8c0@DELLWEI> From: "Wei Gengyu" To: "Paul Kyzivat" References: <4E2DC1ACE541B94A946B8D8657E372C57A91A6@photon.objectworld.com><24CCCC428EFEA2469BF046DB3C7A8D226B26A3@namail5.corp.adobe.com> <461C3740.2010904@cisco.com> Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 11 Apr 2007 11:40:35 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1793515876==" Errors-To: p2psip-bounces@ietf.org --===============1793515876== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpBIHNjZW5hcmlvIG9mIHNlbnNvciBuZXR3b3JrcyBpbiB0aGUgY2FzZSBvZiBkaXNhc3RlcnMg d2FzIGRpc2N1c3NlZC4NCiAgDQpTZW5zb3JzIGFyZSBsYWlkIG9yIGV2ZW4gZHJvcHBlZCBmcm9t IGhlbGljb3B0ZXJzIGFjcm9zcyBmaWVsZHMuIA0KRWFjaCBzZW5zb3IgaGFzIGEgSUQgYW5kIGFz c29jaWF0ZWQgd2l0aCBHUFMtYmFzZWQgbG9jYXRpb24gaW5mb21hdGlvbi4gDQpTZW5zb3JzIGFy ZSBwZWVycywgYW5kIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gc2Vuc29ycyBpcyBwZWVyIHRv IHBlZXIuDQoNClNvbWUgc3VwZXIgcGVlcnMgbXVzdCBiZSBleGlzdGVkIHRvIG1ha2UgbG9uZy1o YXVsIHRyYW5zbWlzc2lvbiBwb3NzaWJsZS4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1DQoNCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiUGF1bCBLeXppdmF0IiA8cGt5eml2YXRA Y2lzY28uY29tPg0KVG86ICJIZW5yeSBTaW5ucmVpY2giIDxoc2lubnJlaUBhZG9iZS5jb20+DQpD YzogPHAycHNpcEBpZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTEsIDIwMDcgOTox NyBBTQ0KU3ViamVjdDogUmU6IFtQMlBTSVBdIFJFOiBbUDJQcmddIFJFOiBbU2lwcGluZ10gU2lt cGxlIFNJUCB1c2FnZSBzY2VuYXJpbw0KDQoNCj4gDQo+IA0KPiBIZW5yeSBTaW5ucmVpY2ggd3Jv dGU6DQo+PiBIZXJlIGFyZSBhIGZldyB1c2FnZSBzY2VuYXJpb3Mgd2hlcmUgb3duZXJsZXNzIFAy UCBtYWtlcyBzZW5zZToNCj4+IA0KPj4gIA0KPj4gDQo+PiBJbiBlbWVyZ2VuY3kgc2l0dWF0aW9u cywgZHVyaW5nIG5hdHVyYWwgb3IgbWFuIG1hZGUgZGlzYXN0ZXJzLCB3aGVuIA0KPj4gZGlzY29u bmVjdGVkIGZvcm0gdGhlIEludGVybmV0LCB0aGUgb3duZXJsZXNzIHAycCBtYXkgYmUgdGhlIGxp ZmUgc2F2ZXIuDQo+PiANCj4+ICANCj4+IA0KPj4gQWxzbywgb24gdGhlIGJhdHRsZWZpZWxkIHRo ZXJlIGlzIHRoZSBhZ3JlZW1lbnQgYW5kIHN0cm9uZyBlbmZvcmNlbWVudCANCj4+IGFtb25nIHBl ZXJzLg0KPiANCj4gTWF5YmUgSSdtIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgb24gdGhlIGJhdHRs ZWZpZWxkIEkgdGhpbmsgSSB3b3VsZCBsaWtlIA0KPiB0byBkaXN0aW5ndWlzaCB0aGUgZ3V5cyBv biBteSBzaWRlIGZyb20gdGhlIGd1eXMgb24gdGhlIG90aGVyIHNpZGUuIFdpdGggDQo+IGEgdHJ1 bHkgb3duZXJsZXNzIHN5c3RlbSBJIGRvbid0IHRoaW5rIHRoYXQgaXMgc3VwcG9ydGVkLg0KPiAN Cj4gUGF1bA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+ --===============1793515876== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1793515876==-- From p2psip-bounces@ietf.org Wed Apr 11 03:57:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXhW-0000lB-Mc; Wed, 11 Apr 2007 03:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbXhU-0000kv-Rq; Wed, 11 Apr 2007 03:57:08 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbXcm-0006r4-5a; Wed, 11 Apr 2007 03:52:26 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Wed, 11 Apr 2007 09:52:15 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 09:52:14 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 11 Apr 2007 09:52:13 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB77C@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226B2655@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario thread-index: Acd7AmtiCvNz+pmuT1+vWsd0kPmXiQAlt3mAABxv6bA= From: "Beck01, Wolfgang" To: , , X-OriginalArrivalTime: 11 Apr 2007 07:52:14.0481 (UTC) FILETIME=[51A9B010:01C77C0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: p2prg@ietf.org, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry wrote: >=20 > Actually, I believe Dean's idea makes sense without any=20 > server and ownership - just like in http://openid.net/=20 Openid relies on the DNS to get unique user ids, it's not exactly = ownerless. Dean wrote: > >=20 > > Now, if the whole overlay resets such that the name-enrollments are > > lost, everybody gets to re-enroll, and there's a land-rush on being=20 > > called Henry instead of Bob (or vice-versa). The land-rush is an inevitable result of using a human-memorable name as = key. If we are using something different, the problem will go away. Theoretically, = the public key of a user is a good candidate. In practice, we might use something = shorter for routing (and business cards), like the user name plus some = fingerprint of the public key . The result of the P2PSIP user location would be a list of candidate = pairs, (IP addresses, public key). The calling UA would pick the IP address = with the public key of the user I wanted to call: henry?@overlay.example.org -> [(10.0.0.1, ), (10.1.0.100, ] -> send INVITE to 10.0.0.1 If the public keys get signed in the fashion of PGP, the scheme would be ownerless. Wolfgang -- T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut Binder, Albert = Henn, Olaf Heyden*, Katrin Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 11 18:22:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HblCd-00075c-PL; Wed, 11 Apr 2007 18:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HblCc-00075X-Ls for p2psip@ietf.org; Wed, 11 Apr 2007 18:22:10 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HblCb-0007fP-BA for p2psip@ietf.org; Wed, 11 Apr 2007 18:22:10 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 11 Apr 2007 15:22:04 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3BMLWD1014277; Wed, 11 Apr 2007 15:21:32 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3BMM10c019485; Wed, 11 Apr 2007 15:22:02 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 15:22:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Date: Wed, 11 Apr 2007 15:21:44 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226B2A87@namail5.corp.adobe.com> In-Reply-To: <461C3740.2010904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Thread-Index: Acd71z9t752eTG1hSwymlKsgAehQeQAsAdQg References: <4E2DC1ACE541B94A946B8D8657E372C57A91A6@photon.objectworld.com> <24CCCC428EFEA2469BF046DB3C7A8D226B26A3@namail5.corp.adobe.com> <461C3740.2010904@cisco.com> From: "Henry Sinnreich" To: "Paul Kyzivat" X-OriginalArrivalTime: 11 Apr 2007 22:22:01.0100 (UTC) FILETIME=[D34FCCC0:01C77C87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Paul, You are right.=20 On the battlefield the peers would have to be preconfigured with certificates from the CA. I meant local configuration MUST be excluded, except some individual token such as Michael Slavitch is mentioning - maybe a fingerprint readier, voice identification, etc. Henry -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Tuesday, April 10, 2007 6:18 PM To: Henry Sinnreich Cc: Michael Slavitch; p2psip@ietf.org Subject: Re: [P2PSIP] RE: [P2Prg] RE: [Sipping] Simple SIP usage scenario Henry Sinnreich wrote: > Here are a few usage scenarios where ownerless P2P makes sense: >=20 > =20 >=20 > In emergency situations, during natural or man made disasters, when=20 > disconnected form the Internet, the ownerless p2p may be the life saver. >=20 > =20 >=20 > Also, on the battlefield there is the agreement and strong enforcement > among peers. Maybe I'm missing something, but on the battlefield I think I would like to distinguish the guys on my side from the guys on the other side. With a truly ownerless system I don't think that is supported. Paul _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 13 06:43:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJFG-0006AP-DQ; Fri, 13 Apr 2007 06:43:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJFF-0006AF-Dt for p2psip@ietf.org; Fri, 13 Apr 2007 06:43:09 -0400 Received: from sernt4.essex.ac.uk ([155.245.48.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcJFE-00068h-3Y for p2psip@ietf.org; Fri, 13 Apr 2007 06:43:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2007 11:43:04 +0100 Message-ID: <811D385AE1CEBB42839C50DF0B0D38E003D35A47@sernt4.essex.ac.uk> In-reply-to: <003201c7781d$b10f40a0$1905a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presence in P2P-SIP Thread-Index: Acd3QsIEiMe1qLACTfaPfQSyKHl8KQA2pFcgAWayHcA= From: "Oredope, Adetola" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [P2PSIP] Presence in P2P-SIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello, Do any one know of where I can find any information on Presence services using P2P-SIP (SIMPLE)? Is there any one out there working on this? Regards, Tola _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 13 23:11:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcYg4-0005nz-WB; Fri, 13 Apr 2007 23:11:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcYg3-0005np-E5 for p2psip@ietf.org; Fri, 13 Apr 2007 23:11:51 -0400 Received: from spark.hss.co.in ([203.145.155.21] helo=tapal.aricent.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcYg1-0008Qa-HK for p2psip@ietf.org; Fri, 13 Apr 2007 23:11:51 -0400 Received: from tapal.aricent.com (localhost [127.0.0.1]) by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l3E3B0Hg006430 for ; Sat, 14 Apr 2007 08:41:00 +0530 Received: from pragati.blr.hss.hns.com (pragati.blr.hss.hns.com [10.203.193.22])by tapal.aricent.com (8.13.8/8.13.8) with ESMTP id l3E3B0ii006427;Sat, 14 Apr 2007 08:41:00 +0530 Importance: Normal X-Priority: 3 (Normal) Subject: Re: [P2PSIP] Comments on draft-baset-p2psip-p2pcommon-01 Attn: Baset/Schulzrinne MIME-Version: 1.0 From: anuroop.r@aricent.com To: Salman Abdul Baset Date: Sat, 14 Apr 2007 08:40:18 +0530 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.5 November 30, 2005 X-MIMETrack: Serialize by Notes Server on Prudent/BLR/HSS(Release 6.5.5|November 30, 2005) at04/14/2007 08:40:18 AM, Serialize complete at 04/14/2007 08:40:18 AM, Itemize by Notes Server on Prudent/BLR/HSS(Release 6.5.5|November 30, 2005) at04/14/2007 08:40:18 AM, Serialize by Router on Pragati/BLR/HSS(Release 6.5.5|November 30, 2005) at04/14/2007 08:38:45 AM,Serialize complete at 04/14/2007 08:38:45 AM MIME-Version: 1.0 X-imss-version: 2.046 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.6120 TC:1F TRN:66 TV:3.6.1039(15110.002) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:2 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 1.5 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1404598534==" Errors-To: p2psip-bounces@ietf.org --===============1404598534== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Hello=20Base= t/Schulzrinne.
 
Thanks=20for=20your=20response=20for=20my=20co= mments.=20I=20have=20few=20more= =20comments.=20Please=20read=20below. When=20would=20be=20the= =20updated=20draft=20available=20?.I=20would=20like=20to=20contribute=20to=20this=20draft.=20Let=20me=20kn= ow=20if =20i=20couldbe=20any= =20help=20for=20you. <= DIV=20style=3D"DIRECTION:=20ltr">Thanks=20&=20Regards,Anuroop.=  Comments:  = ;1.=20There=20is=20a=20"Response-Code"=20parameter=20in=20Join=20Response= =20and=20Insert=20Response=20messages.
   =20The=20comm= on=20header=20has=20the=20provision=20to=20send=20the=20response=20code= =20as=20well.=20Why=20is
   =20this=20explicity=20respo= nse=20code=20required?.=20Also=20there=20is=20no=20TLV=20object=20defined= =20for
   =20Response-Code.=20My=20understanding=20is= =20that=20this=20parameter=20shall=20be=20removed=20from=20
 &nbs= p; =20Join=20Response=20and=20Insert=20Response=20as=20the=20common= =20header=20would=20suffice.
 
 
 2.=20The=20Repl= icate=20message=20should=20have=20"Expires"=20field=20as=20well.=20Since= =20the=20resouces=20shall
   =20be=20inserted=20into=20= peer=20with=20as=20associated=20"Expires"=20field,=20when=20these=20resou= rces=20are
   =20replicated,=20the=20associated=20expir= es=20should=20also=20get=20transfered=20to=20the=20Peer=20who=20is
&nb= sp;  =20owning=20this=20resources.
   =20
=  
 3.=20The=20state=20machine=20is=20written=20only=20from= =20the=20perspective=20of=20a=20Peer=20sending=20out=20requests.
 = ;  =20A=20Peer=20can=20receive=20requests=20from=20other=20Peer= ,=20which=20is=20not=20addressed=20in=20this=20state=20machine.
 =   =20New=20state=20should=20be=20introduced=20to=20indicate=20t= he=20"received=20request"=20from=20other=20peer.=20when
  &n= bsp;=20a=20Peer=20receives=20a=20request,=20as=20part=20of=20processing,= =20it=20may=20send=20the=20request=20to=20the=20DHT=20
  &nb= sp;=20layer=20with=20in=20the=20node.=20Then=20it=20should=20change=20the= =20state=20to=20"Req_Recv"=20state.=20On=20receving
   = =20the=20response=20from=20DHT=20Layer,=20it=20shall=20respond=20to=20the= =20other=20peer,=20and=20then=20move=20to
   =20sucess= =20or=20failure=20state.
   =20
 4.=20The=20pro= tocol=20should=20clearly=20specifiy=20whether=20the=20encoding=20should= =20be=20done=20in=20big/little=20
   =20endian=20format= .=20In=20the=20absence=20of=20such=20a=20statement,=20the=20default=20i= =20think=20is=20big=20endian.


*****Ar= icent-Unclassified=20*****=3D=0D=0A
"DISCLAIMER:=20This=20message=20is=20proprietar=
y=20to=20Aricent=20and=20is=20intended=20solely=20for=20the=20use=20of=20=
=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It=20may=20conta=
in=20privileged=20or=20confidential=20information=20and=20should=20not=20=
be=20=0Acirculated=20or=20used=20for=20any=20purpose=20other=20than=20for=
=20what=20it=20is=20intended.=20If=20you=20have=20received=20this=20messa=
ge=20in=20error,=20=0Aplease=20notify=20the=20originator=20immediately.=
=20If=20you=20are=20not=20the=20intended=20recipient,=20you=20are=20notif=
ied=20that=20you=20are=20strictly=0Aprohibited=20from=20using,=20copying,=
=20altering,=20or=20disclosing=20the=20contents=20of=20this=20message.=20=
Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20or=20damage=20a=
rising=20from=20the=20use=20of=20the=20information=20transmitted=20by=20t=
his=20email=20including=20damage=20from=20virus."=0A
--===============1404598534== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1404598534==-- From p2psip-bounces@ietf.org Sat Apr 14 05:35:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hceex-0003KH-0l; Sat, 14 Apr 2007 05:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hceev-0003KC-H5 for p2psip@ietf.org; Sat, 14 Apr 2007 05:35:05 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcees-0001ED-Np for p2psip@ietf.org; Sat, 14 Apr 2007 05:35:05 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1026907nzd for ; Sat, 14 Apr 2007 02:35:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jCe7r444bTU3fTP262ow5LYKebvxQjL0s6LS02u/6WYBpLXjdkqJQfMeu+LdnxzJeXD2BbPEqkZk1Iyqn5U5gh9rz3IkTGiXDspYOi4ZJc8L5GiPIeUnT1agN8YaONc4t1q7bkW52zmUlc8m5EoqK+Fxo/xeH7ErmMluJy0GtwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ie18yr+6qSTgt93CsCLcrdWtQQChsJyi4pxDKBn8cWMWPyqEtDbzI60o0KJogbWcEEOax1bVMOaDeQc25PoJT+pHOnNJulU/v7JEESw3ffpdeMillfRxcF1tjEKcrAuDkF2taknY1XSMkIUw+I/ITqTwwpXrcpLLdGC8mCkv124= Received: by 10.114.181.1 with SMTP id d1mr190044waf.1176543299666; Sat, 14 Apr 2007 02:34:59 -0700 (PDT) Received: by 10.114.182.11 with HTTP; Sat, 14 Apr 2007 02:34:32 -0700 (PDT) Message-ID: <618e24240704140234l75c444a7jc049d7b0d10f6099@mail.gmail.com> Date: Sat, 14 Apr 2007 11:34:32 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "David A. Bryan" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? In-Reply-To: <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> MIME-Version: 1.0 References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> <1e2701c776cd$72299710$81238182@cis.neustar.com> <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1361598748==" Errors-To: p2psip-bounces@ietf.org --===============1361598748== Content-Type: multipart/alternative; boundary="----=_Part_19005_33116725.1176543272534" ------=_Part_19005_33116725.1176543272534 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree with both points entirely. But I'd like to keep in mind the following issues: 1) could we consider SCTP? we could then manage QoS issues at lower levels if working with MANET 2) could we consider working with IPv6 ip addresses using *RFC 2462* IPv6 Stateless Address Autoconfiguration? (A pure p2p net should not consider a dhcp server). -but i also agree that using v4 or v6 should not be relevant- 3) is a p2p-sip net a closed net with no other service dependence? Should p2psip rely on dhcp, dns and so on? My opinion is p2psip should be and independent network with no other servic= e dependence, p2psip users should be able to perform an overlay in spite ther= e are no centralised servers (dns, dhcp, ntp..) neither internet reachability (why not be able to perform an overlay when climbing the Everest? ) 4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload) So, p2psip could be used for audio, video and other media session signaling and... why not as a grid computing signaling protocol? Thanks, Victor Pascual On 04/04/07, David A. Bryan wrote: > > Tend to agree with most of this, but we also need to keep in mind > non-telephony P2PSIP applications (say IPTV, voice add-on to gaming > etc.) and make sure we don't write things in such a way these > capabilities are required for these services as well. > > David > > On 4/4/07, Brian Rosen wrote: > > I REALLY wish I could transfer a call from Skype to my mobile and vice > > versa. > > > > I wish I could transfer it to my hardline when, for whatever reason, th= e > > bandwidth gods are not smiling on me. > > > > And then there is conferencing. Depending on exactly how conferencing > is > > implemented, you may need to transfer to a bridge. > > > > I really think transfer is an absolute minimal requirement. > > > > I do think that a rich presence system might obviate the Call forward > > issues. I've never seen it done, so I've never been able to try, but I > > could see how it might. > > > > Conferencing is something that just has to work. > > > > We need to go down the list of service examples and decide which ones > are > > MUST HAVE. > > > > Brian > > > > > -----Original Message----- > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > > Sent: Wednesday, April 04, 2007 11:14 AM > > > To: Brian Rosen; P2PSIP Mailing List > > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers= " > to > > > think? > > > > > > These are good points and actually should copied to the SIPPING list > > > since they apply to the simple SIP Toolkit :-) > > > > > > Excellent items are these here: > > > > > > >3. All devices that support audio support wideband audio. > > > > > > >4. All devices support text (IM and real time interactive). > > > > > > >5. All devices support presence. We define a minimal set of presenc= e > > > >characteristics that all devices publish. > > > > > > I take exception here only to the legacy from the voice-only PBX: > > > > > > >6. We define a minimal feature set (something like unattended and > > > >attended > > > >transfer, call forward no answer, call forward busy, basic > > > conferencing, > > > >...) that every device supports the same way. > > > > > > Let's first look how presence and IM may affect user behavior and if > > > this cannot be a special endpoint app, say for receptionists or > agents. > > > > > > > This is pretty much what Skype does > > > > > > I am using Skype now for several years for most long distance calls > and > > > for conferences, but have never transferred a call. May be my > secretary > > > would transfer a call, but I don't have one :-) > > > Nor do 99.99% of consumers or most employees any more. One can IM the > > > number... > > > > > > Thanks, Henry > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, April 04, 2007 9:49 AM > > > To: 'P2PSIP Mailing List' > > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" to > > > think? > > > > > > One of the things I think we blew big time on sip was that we didn't > > > require > > > some fundamental things in every sip device to differentiate them fro= m > > > existing technology. We have an opportunity to fix that with p2psip, > > > and I > > > think we should do it. > > > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" > issue, > > > but > > > it's a very real thing that we could do which I believe would be > > > helpful. > > > > > > So, I propose: > > > 1. We do not support any form of insecure signaling. We define the > > > protocol > > > to reject attempts to signal without TLS (or whatever). I'm assuming > > > the > > > protocols are TCP only. The overlay defines what credentials are > needed > > > (and supplies them). > > > > > > 2. We do not support any form of insecure media. It's always > encrypted. > > > This is the tough one, especially if we say we support SIP UAs. > > > > > > 3. All devices that support audio support wideband audio. > > > > > > 4. All devices support text (IM and real time interactive). > > > > > > 5. All devices support presence. We define a minimal set of presence > > > characteristics that all devices publish. > > > > > > 6. We define a minimal feature set (something like unattended and > > > attended > > > transfer, call forward no answer, call forward busy, basic > conferencing, > > > ...) that every device supports the same way. > > > > > > 7. All devices work behind a given set of NAT configurations, given a > > > specified set of ICE components (or whatever). > > > > > > 8. We define what constitutes a minimal configuration set; all of the > > > above > > > just work with this level of configuration (and credentials from an > > > overlay). We of course define the configuration mechanism. I'm > > > thinking > > > that we do this by configuring the device with the credentials, and > > > using > > > the overlay to provide any other configuration (which could be > > > influenced > > > by, say, a website the overlay runs) automatically. > > > > > > All of these are designed to be minimum capabilities, but the idea is > > > that > > > ANY device, with credentials on an overlay, can expect to communicate > > > with > > > any other device on that overlay with ALL of the above. > > > > > > Finally, I propose we invent a phrase, something like "p2psip > > > conformant" > > > which means a device that does that. No protocol police, but the ide= a > > > is > > > that if you say you have a "p2psip conformant" device, it means all o= f > > > the > > > above. Perhaps we have a way to signal that. > > > > > > This is pretty much what Skype does. Why should we not do that, at > > > least? > > > > > > Brian > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip:victor.pascual@iptel.org fon user: 223364 ------=_Part_19005_33116725.1176543272534 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I agree with both points entirely. But I'd like to keep in mind the fol= lowing issues:
1) could we consider SCTP? we could then manage QoS issue= s at lower levels if working with MANET
2) could we consider working wit= h IPv6 ip addresses using=20 RFC 2462 IPv6 Stateless Address Autoconfiguration?=
(A pure p2p net should not consider a dhcp server). -but i also agree t= hat using v4 or v6 should not be relevant-
3) is a p2p-sip net a = closed net with no other service dependence? Should p2psip rely on dhcp, dn= s and so on?
My opinion is p2psip should be and independent network with no other se= rvice dependence, p2psip users should be able to perform an overlay in spit= e there are no centralised servers (dns, dhcp, ntp..) neither internet reac= hability (why not be able to perform an overlay when climbing the Everest? = )
4) we should consider p2psip only as a singaling protocol with independ= ence of tx media (we can define it at SDP payload)
So, p2psip could be u= sed for audio, video and other media session signaling and... why not as a = grid computing signaling protocol?

Thanks, Victor Pascual
On 04/04/07, David A. Bryan <dbryan@sip= eerior.com> wrote:
Tend to agree with most of this, but we also need to keep in mind
non-te= lephony P2PSIP applications (say IPTV, voice add-on to gaming
etc.) and = make sure we don't write things in such a way these
capabilities are= required for these services as well.

David

On 4/4/07, Brian Rosen <br@brianrosen.net> wrote:
> I REALLY wish I could tr= ansfer a call from Skype to my mobile and vice
> versa.
>
> I wish I could transfer it to my hardline when, for whatever reason, t= he
> bandwidth gods are not smiling on me.
>
> And then t= here is conferencing.  Depending on exactly how conferencing is> implemented, you may need to transfer to a bridge.
>
> I really think transfer is an absolute minimal requirement= .
>
> I do think that a rich presence system might obviate the = Call forward
> issues.  I've never seen it done, so I&#= 39;ve never been able to try, but I
> could see how it might.
>
> Conferencing is something = that just has to work.
>
> We need to go down the list of servi= ce examples and decide which ones are
> MUST HAVE.
>
> Br= ian
>
> > -----Original Message-----
> > From: Henry S= innreich [mailto:hsinnrei@adobe.com]
> > Sent: Wednesday, April 04, 2007 11:14 AM
> > To: = Brian Rosen; P2PSIP Mailing List
> > Subject: RE: [P2PSIP] When we say "p2psip" what do = we want "consumers" to
> > think?
> >
> &= gt; These are good points and actually should copied to the SIPPING list
> > since they apply to the simple SIP Toolkit :-)
> >> > Excellent items are these here:
> >
> > >3= . All devices that support audio support wideband audio.
> >
> > >4. All devices support text (IM and real time interactive).> >
> > >5. All devices support presence.  We= define a minimal set of presence
> > >characteristics that all= devices publish.
> >
> > I take exception here only to the legacy from th= e voice-only PBX:
> >
> > >6. We define a minimal feat= ure set (something like unattended and
> > >attended
> &g= t; >transfer, call forward no answer, call forward busy, basic
> > conferencing,
> > >...) that every device support= s the same way.
> >
> > Let's first look how presence= and IM may affect user behavior and if
> > this cannot be a speci= al endpoint app, say for receptionists or agents.
> >
> > > This is pretty much what Skype does
>= >
> > I am using Skype now for several years for most long dis= tance calls and
> > for conferences, but have never transferred a = call. May be my secretary
> > would transfer a call, but I don't have one :-)
> &= gt; Nor do 99.99% of consumers or most employees any more. One can IM the> > number...
> >
> > Thanks, Henry
> >
> >
> > -----Original Message-----
> > From: Br= ian Rosen [mailto:br@brianrosen.net]
> > Sent: Wednesday, April 04, 2007 9:49 AM
> > To: &#= 39;P2PSIP Mailing List'
> > Subject: [P2PSIP] When we say "p2psip" what do we w= ant "consumers" to
> > think?
> >
> > = One of the things I think we blew big time on sip was that we didn't
> > require
> > some fundamental things in every sip dev= ice to differentiate them from
> > existing technology.  = ;We have an opportunity to fix that with p2psip,
> > and I
>= > think we should do it.
> >
> > Now, admittedly, what I'm talking about is s= omewhat a "marketing" issue,
> > but
> > it'= ;s a very real thing that we could do which I believe would be
> >= helpful.
> >
> > So, I propose:
> > 1. We do not support= any form of insecure signaling.  We define the
> > prot= ocol
> > to reject attempts to signal without TLS (or whatever).&n= bsp; I'm assuming
> > the
> > protocols are TCP only.  The overl= ay defines what credentials are needed
> > (and supplies them).> >
> > 2. We do not support any form of insecure media.&nb= sp; It's always encrypted.
> > This is the tough one, especially if we say we support SIP UA= s.
> >
> > 3. All devices that support audio support wide= band audio.
> >
> > 4. All devices support text (IM and r= eal time interactive).
> >
> > 5. All devices support presence.  We d= efine a minimal set of presence
> > characteristics that all devic= es publish.
> >
> > 6. We define a minimal feature set (s= omething like unattended and
> > attended
> > transfer, call forward no answer, call = forward busy, basic conferencing,
> > ...) that every device suppo= rts the same way.
> >
> > 7. All devices work behind a gi= ven set of NAT configurations, given a
> > specified set of ICE components (or whatever).
> >> > 8. We define what constitutes a minimal configuration set; all = of the
> > above
> > just work with this level of configu= ration (and credentials from an
> > overlay).  We of course define the configuration me= chanism.  I'm
> > thinking
> > that we do t= his by configuring the device with the credentials, and
> > using<= br>> > the overlay to provide any other configuration (which could be
> > influenced
> > by, say, a website the overlay runs) = automatically.
> >
> > All of these are designed to be mi= nimum capabilities, but the idea is
> > that
> > ANY devi= ce, with credentials on an overlay, can expect to communicate
> > with
> > any other device on that overlay with ALL o= f the above.
> >
> > Finally, I propose we invent a phras= e, something like "p2psip
> > conformant"
> > w= hich means a device that does that.  No protocol police, but the = idea
> > is
> > that if you say you have a "p2psip confo= rmant" device, it means all of
> > the
> > above.&nb= sp; Perhaps we have a way to signal that.
> >
> > Th= is is pretty much what Skype does.  Why should we not do that, at
> > least?
> >
> > Brian
> >
> &= gt;
> > _______________________________________________
> &g= t; P2PSIP mailing list
> > P2PS= IP@ietf.org
> > https://www1.ietf.org/mailman/listinfo/p2psip
>
>
> = _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/p2psip
>


--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)www.SIPeerior.com

_______= ________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Victor Pascual =C1vila

mail: victor.pascual.avila@gmail.com
sip:victor.pascual@iptel.org
fon user: 223364 ------=_Part_19005_33116725.1176543272534-- --===============1361598748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1361598748==-- From p2psip-bounces@ietf.org Sat Apr 14 05:46:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcepe-00018u-4c; Sat, 14 Apr 2007 05:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcepc-00018R-DF for p2psip@ietf.org; Sat, 14 Apr 2007 05:46:09 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcepa-00042Y-Q8 for p2psip@ietf.org; Sat, 14 Apr 2007 05:46:08 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1017146wri for ; Sat, 14 Apr 2007 02:46:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=T9qM8SucSlT0BMYw5WUYXi/Qvt7QHMoDfDXTSSOLNeIVjOolbjsyXN/bLmhaa+xEL6Zqf2JkCNygEQb5uv6en+tn9JiaO4DGl0Iw+jm5pwXqosBmiOWxYXu1xvpCv2GbW5/Dbbe8OLr66iJQfcuXfF4HKG1RuZaOGPEwuBmBAuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pdZXHiZMSC48In6RBuPrRTRiL2QwJxYx4j5v7sv7qjMY1eKoVIApefP9Hw+4DLK0ojRnuULjTaRUGYLCxRFlGv9X+XByC+/ov/PRQPyHwTAi2vJj8OrBCtrzxjlr/v/VFF0y45bw8yO5ivSoldMCxPgbcsXZvV7ALUsbyHrIDiw= Received: by 10.114.153.18 with SMTP id a18mr193158wae.1176543964850; Sat, 14 Apr 2007 02:46:04 -0700 (PDT) Received: by 10.114.182.11 with HTTP; Sat, 14 Apr 2007 02:46:04 -0700 (PDT) Message-ID: <618e24240704140246i3dc18fafx8eae4de8c745c059@mail.gmail.com> Date: Sat, 14 Apr 2007 11:46:04 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: zhuxian Subject: Re: [P2PSIP] Roles In-Reply-To: <000001c7701c$1c1630c0$af244e0a@china.huawei.com> MIME-Version: 1.0 References: <9dc4a1670703231044g117a216bhb9aad0faeeb8a5b@mail.gmail.com> <000001c7701c$1c1630c0$af244e0a@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: p2psip@ietf.org, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684481844==" Errors-To: p2psip-bounces@ietf.org --===============1684481844== Content-Type: multipart/alternative; boundary="----=_Part_19113_33456992.1176543964742" ------=_Part_19113_33456992.1176543964742 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline What about the leaving node? When a responsible node for a dht-hash area performs a planned leave from the overlay it should delegate it's responsibilities when possible. Is it correct? Thanks, Victor Pascual On 27/03/07, zhuxian wrote: > > EdPimentl, > > These authentication mechanisms are typical used in the C/S model. In the > P2P model, SAML assertion or identity can be easily replayed, for the pee= r > receieved the assertion can replay it. But this may not be happened in th= e > C/S model, as we often believed that the server is trusted enough. > > So, even we use the SAML assertion, it also need some authentication > mechanisms to prove the peer sending the SAML assertion is the peer ownin= g > the SAML assertion. > > This is why I believe that peer should authenticate each other at all > times. > > > Kurt Zhu > > ------------------------------ > *From:* EdPimentl [mailto:edpimentl@gmail.com] > *Sent:* Saturday, March 24, 2007 1:44 AM > *To:* zhuxian > *Cc:* David A. Bryan; Henning Schulzrinne; Philip Matthews; > p2psip@ietf.org > *Subject:* Re: [P2PSIP] Roles > > As we explore authentication mechanisms. > It would good to consider one of the following methods for authentication= , > authorizations and entitlements such as: > http://dev.inames.net/wiki/Tech_FAQs > http://www.sourceid.org/ > http://www.projectliberty.org/ > > My .02 > Best, > -E > > > > On 3/23/07, zhuxian wrote: > > > > I fully agree with the following sentence from David: > > In a peer-to-peer system, all peers must check all credentials at > > all > > times. > > > > Even if a centralized authentication server has been deployed in the > > hybrid-p2p scenario, every peer should also authenticate each other at > > all > > times. Otherwise, the peer could not confirm whether another peer is > > admited > > by the authentication server, or it just join the overlay through its > > colluding peer. > > > > Kurt Zhu > > > > > > -- > Thanks in advance and best regards, > > Ed Pimentel > AgileCO > Founder > > Mail: edpimentl[at]gmail.com > sip: sip:2150112@truphone.com > IM: edpimentl [AOL | Jabber | Yahoo | MSN ] > Voip: edpimentl [SKype | GoogleTalk ] > > Mobile Content Marketing/Management/Digital Delivery > http://mobilecentral.ws > > Mobile ( Relevant, Ambient Intelligence, Location ) based Social Network > http://TagR.mobi (Alpha) > > Mobile Payment - P2P Payment > http://agilepay.ws > > Sponsor of P2PSIP open source [viasip_ng] project > Creating a standards base P2PSIP dSIP infrastructure > https://sourceforge.net/projects/viasip/ > Mailing List viasip_ng@freelists.org > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip:victor.pascual@iptel.org fon user: 223364 ------=_Part_19113_33456992.1176543964742 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCBhYm91dCB0aGUgbGVhdmluZyBub2RlPyBXaGVuIGEgcmVzcG9uc2libGUgbm9kZSBmb3Ig YSBkaHQtaGFzaCBhcmVhIHBlcmZvcm1zIGEgcGxhbm5lZCBsZWF2ZSBmcm9tIHRoZSBvdmVybGF5 IGl0IHNob3VsZCBkZWxlZ2F0ZSBpdCYjMzk7cyByZXNwb25zaWJpbGl0aWVzIHdoZW4gcG9zc2li bGUuIElzIGl0IGNvcnJlY3Q/PGJyPjxicj5UaGFua3MsIFZpY3RvciBQYXNjdWFsPGJyPgo8YnI+ PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDI3LzAzLzA3LCA8YiBjbGFzcz0iZ21h aWxfc2VuZGVybmFtZSI+emh1eGlhbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzp6aHV4aWFuQGh1 YXdlaS5jb20iPnpodXhpYW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4KCgoKCjxkaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNl PSLlrovkvZMiPjxzcGFuPkVkUGltZW50bCw8L3NwYW4+PC9mb250PjwvZGl2Pgo8ZGl2IGRpcj0i bHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0i5a6L5L2TIj48c3Bhbj48L3NwYW4+PC9mb250 PiZuYnNwOzwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0i5a6L 5L2TIj48c3Bhbj5UaGVzZSAKYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBhcmUgdHlwaWNhbCB1 c2VkIGluIHRoZSBDL1MgbW9kZWwuIEluIHRoZSBQMlAgbW9kZWwsIApTQU1MIGFzc2VydGlvbiZu YnNwO29yIGlkZW50aXR5IGNhbiBiZSBlYXNpbHkgcmVwbGF5ZWQsIGZvciB0aGUgcGVlciByZWNl aWV2ZWQgCnRoZSBhc3NlcnRpb24gY2FuIHJlcGxheSBpdC4gQnV0IHRoaXMgbWF5IG5vdCBiZSBo YXBwZW5lZCBpbiB0aGUgQy9TIG1vZGVsLCAKYXMmbmJzcDt3ZSBvZnRlbiBiZWxpZXZlZCB0aGF0 IHRoZSBzZXJ2ZXIgaXMgdHJ1c3RlZCAKZW5vdWdoLiZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSLlrovkvZMiPjxz cGFuPjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0 Ij48Zm9udCBmYWNlPSLlrovkvZMiPjxzcGFuPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i5a6L 5L2TIj48c3Bhbj5TbywgZXZlbiB3ZSZuYnNwO3VzZSB0aGUgU0FNTCBhc3NlcnRpb24sIGl0IGFs c28gbmVlZCAKc29tZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zIHRvIHByb3ZlIHRoZSBwZWVy IHNlbmRpbmcgdGhlIFNBTUwgYXNzZXJ0aW9uIGlzIAp0aGUgcGVlciBvd25pbmcgdGhlIFNBTUwg YXNzZXJ0aW9uLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0 Ij48Zm9udCBmYWNlPSLlrovkvZMiPjxzcGFuPjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PC9kaXY+Cjxk aXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSLlrovkvZMiPjxzcGFuPlRoaXMg aXMgd2h5IApJIGJlbGlldmUgdGhhdCBwZWVyIHNob3VsZCZuYnNwO2F1dGhlbnRpY2F0ZSBlYWNo IG90aGVyIGF0IGFsbCB0aW1lcy4gCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+CjxkaXY+PGZvbnQgY29s b3I9IiMwMDAwZmYiIGZhY2U9IuWui+S9kyI+PC9mb250PiZuYnNwOzwvZGl2Pgo8ZGl2Pjxmb250 IGNvbG9yPSIjMDAwMGZmIiBmYWNlPSLlrovkvZMiPjwvZm9udD48Zm9udCBmYWNlPSLlrovkvZMi PjwvZm9udD4mbmJzcDs8L2Rpdj4KPGRpdj48c3Bhbj48Zm9udCBmYWNlPSLlrovkvZMiPkt1cnQg Wmh1PC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdj48YnI+PC9kaXY+CjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXItbGVmdDogMnB4IHNvbGlkIHJnYigwLCAwLCAyNTUpOyBwYWRkaW5nLWxlZnQ6IDVw eDsgbWFyZ2luLWxlZnQ6IDVweDsgbWFyZ2luLXJpZ2h0OiAwcHg7Ij4KICA8ZGl2IGRpcj0ibHRy IiBhbGlnbj0ibGVmdCIgbGFuZz0iemgtY24iPgogIDxocj4KICA8Zm9udCBmYWNlPSJUYWhvbWEi IHNpemU9IjIiPjxiPkZyb206PC9iPiBFZFBpbWVudGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 ZWRwaW1lbnRsQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5lZHBpbWVudGxAZ21haWwuY29tPC9h Pl0gCiAgPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMjQsIDIwMDcgMTo0NCBBTTxi cj48Yj5Ubzo8L2I+IAogIHpodXhpYW48YnI+PGI+Q2M6PC9iPiBEYXZpZCBBLiBCcnlhbjsgSGVu bmluZyBTY2h1bHpyaW5uZTsgUGhpbGlwIE1hdHRoZXdzOyAKICA8YSBocmVmPSJtYWlsdG86cDJw c2lwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPnAycHNpcEBpZXRmLm9yZzwvYT48YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBbUDJQU0lQXSBSb2xlczxicj48L2ZvbnQ+PGJyPjwvZGl2PgogIDxkaXY+ PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExMTkxNWM3NjM4NjNhZGJfMSI+PGRpdj48L2Rpdj5BcyB3 ZSBleHBsb3JlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuPGJyPkl0IHdvdWxkIGdvb2QgdG8g CiAgY29uc2lkZXIgb25lIG9mIHRoZSBmb2xsb3dpbmcgbWV0aG9kcyBmb3IgYXV0aGVudGljYXRp b24sIGF1dGhvcml6YXRpb25zIGFuZCAKICBlbnRpdGxlbWVudHMgc3VjaCBhczo8YnI+PGEgaHJl Zj0iaHR0cDovL2Rldi5pbmFtZXMubmV0L3dpa2kvVGVjaF9GQVFzIiB0YXJnZXQ9Il9ibGFuayIg b25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmh0 dHA6Ly9kZXYuaW5hbWVzLm5ldC93aWtpL1RlY2hfRkFRcyAKICA8L2E+PGJyPjxhIGhyZWY9Imh0 dHA6Ly93d3cuc291cmNlaWQub3JnLyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3LnNvdXJjZWlk Lm9yZy88L2E+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cucHJvamVjdGxpYmVydHkub3JnLyIgdGFy Z2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2 ZW50LHRoaXMpIj4KaHR0cDovL3d3dy5wcm9qZWN0bGliZXJ0eS5vcmcvPC9hPjxicj48YnI+TXkg CiAgLjAyPGJyPkJlc3QsPGJyPi1FPGJyPjxicj48YnI+PGJyPgogIDxkaXY+PHNwYW4gY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiAzLzIzLzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+emh1 eGlhbjwvYj4gCiAgJmx0OzxhIGhyZWY9Im1haWx0bzp6aHV4aWFuQGh1YXdlaS5jb20iIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+emh1eGlhbkBodWF3ZWkuY29tPC9hPiZndDsgCiAgd3JvdGU6PC9zcGFuPgogIDxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29s aWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5n LWxlZnQ6IDFleDsiPkkgCiAgICBmdWxseSBhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcgc2VudGVu Y2UgZnJvbSAKICAgIERhdmlkOjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJbiBhIHBlZXIt dG8tcGVlciBzeXN0ZW0sIGFsbCBwZWVycyBtdXN0IAogICAgY2hlY2sgYWxsIGNyZWRlbnRpYWxz IGF0IGFsbDxicj50aW1lcy48YnI+PGJyPkV2ZW4gaWYgYSBjZW50cmFsaXplZCAKICAgIGF1dGhl bnRpY2F0aW9uIHNlcnZlciBoYXMgYmVlbiBkZXBsb3llZCBpbiB0aGU8YnI+aHlicmlkLXAycCBz Y2VuYXJpbywgZXZlcnkgCiAgICBwZWVyIHNob3VsZCBhbHNvIGF1dGhlbnRpY2F0ZSBlYWNoIG90 aGVyIGF0IGFsbCA8YnI+dGltZXMuIE90aGVyd2lzZSwgdGhlIAogICAgcGVlciBjb3VsZCBub3Qg Y29uZmlybSB3aGV0aGVyIGFub3RoZXIgcGVlciBpcyBhZG1pdGVkPGJyPmJ5IHRoZSAKICAgIGF1 dGhlbnRpY2F0aW9uIHNlcnZlciwgb3IgaXQganVzdCBqb2luIHRoZSBvdmVybGF5IHRocm91Z2gg aXRzPGJyPmNvbGx1ZGluZyAKICAgIHBlZXIuPGJyPjxicj5LdXJ0Jm5ic3A7Jm5ic3A7Wmh1PGJy Pjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+VGhhbmtz IGluIGFkdmFuY2UgYW5kIGJlc3QgcmVnYXJkcyw8YnI+PGJyPkVkIAogIFBpbWVudGVsPGJyPkFn aWxlQ088YnI+Rm91bmRlcjxicj48YnI+TWFpbDombmJzcDsmbmJzcDsgCiAgZWRwaW1lbnRsW2F0 XWdtYWlsLmNvbTxicj5zaXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRv OnNpcDoyMTUwMTEyQHRydXBob25lLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5zaXA6MjE1MDExMkB0cnVw aG9uZS5jb208L2E+PGJyPklNOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBlZHBpbWVudGwg W0FPTCB8IEphYmJlciB8IFlhaG9vIHwgTVNOIF0gPGJyPlZvaXA6Jm5ic3A7Jm5ic3A7IGVkcGlt ZW50bCBbU0t5cGUgCiAgfCBHb29nbGVUYWxrIF08YnI+PGJyPk1vYmlsZSBDb250ZW50IE1hcmtl dGluZy9NYW5hZ2VtZW50L0RpZ2l0YWwgCiAgRGVsaXZlcnk8YnI+PGEgaHJlZj0iaHR0cDovL21v YmlsZWNlbnRyYWwud3MiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDovL21vYmlsZWNlbnRyYWwud3M8L2E+ PGJyPjxicj5Nb2JpbGUgKCAKICBSZWxldmFudCwgQW1iaWVudCBJbnRlbGxpZ2VuY2UsIExvY2F0 aW9uICkgYmFzZWQgU29jaWFsIE5ldHdvcmsgPGJyPjxhIGhyZWY9Imh0dHA6Ly9UYWdSLm1vYmki IHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSI+aHR0cDovL1RhZ1IubW9iaTwvYT4gKEFscGhhKTxicj48YnI+TW9iaWxl IFBheW1lbnQgLSAKICBQMlAgUGF5bWVudDxicj48YSBocmVmPSJodHRwOi8vYWdpbGVwYXkud3Mi IHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSI+aHR0cDovL2FnaWxlcGF5LndzPC9hPjxicj48YnI+U3BvbnNvciBvZiAK ICBQMlBTSVAmbmJzcDsmbmJzcDtvcGVuIHNvdXJjZSBbdmlhc2lwX25nXSBwcm9qZWN0PGJyPkNy ZWF0aW5nIGEgc3RhbmRhcmRzIGJhc2UgCiAgUDJQU0lQIGRTSVAgaW5mcmFzdHJ1Y3R1cmUgPGJy PjxhIGhyZWY9Imh0dHBzOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3ZpYXNpcC8iIHRhcmdl dD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSI+aHR0cHM6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvdmlhc2lwLzwvYT48YnI+ TWFpbGluZyAKICBMaXN0IDxhIGhyZWY9Im1haWx0bzp2aWFzaXBfbmdAZnJlZWxpc3RzLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93 LGV2ZW50LHRoaXMpIj52aWFzaXBfbmdAZnJlZWxpc3RzLm9yZzwvYT4gCjwvc3Bhbj48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+Cjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj5QMlBTSVAgbWFpbGluZyBsaXN0PGJyPjxhIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86UDJQ U0lQQGlldGYub3JnIj5QMlBTSVBAaWV0Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAiIHRhcmdldD0iX2JsYW5rIj4KaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwPC9hPjxicj48YnI+PC9ibG9j a3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+PGJyPi0tIDxicj5WaWN0b3IgUGFzY3Vh bCDDgXZpbGE8YnI+PGJyPm1haWw6PGEgaHJlZj0ibWFpbHRvOnZpY3Rvci5wYXNjdWFsLmF2aWxh QGdtYWlsLmNvbSI+dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwuY29tPC9hPgo8YnI+c2lwOjxh IGhyZWY9Im1haWx0bzp2aWN0b3IucGFzY3VhbEBpcHRlbC5vcmciPnZpY3Rvci5wYXNjdWFsQGlw dGVsLm9yZzwvYT48YnI+Zm9uIHVzZXI6IDIyMzM2NAo= ------=_Part_19113_33456992.1176543964742-- --===============1684481844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1684481844==-- From p2psip-bounces@ietf.org Sat Apr 14 12:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HckkS-0000GW-Bw; Sat, 14 Apr 2007 12:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HckkR-0000GR-Kx for p2psip@ietf.org; Sat, 14 Apr 2007 12:05:11 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HckkP-0003wY-E3 for p2psip@ietf.org; Sat, 14 Apr 2007 12:05:11 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Sat, 14 Apr 2007 09:04:54 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3EG4lSd026800; Sat, 14 Apr 2007 09:04:48 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3EG4LI9016087; Sat, 14 Apr 2007 09:04:21 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 09:04:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Date: Sat, 14 Apr 2007 09:04:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226B30AC@namail5.corp.adobe.com> In-Reply-To: <618e24240704140234l75c444a7jc049d7b0d10f6099@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? Thread-Index: Acd+eD0tr7zgsQbARBKNUY3akA/GogANOCtg References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> <1e2701c776cd$72299710$81238182@cis.neustar.com> <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> <618e24240704140234l75c444a7jc049d7b0d10f6099@mail.gmail.com> From: "Henry Sinnreich" To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= , "David A. Bryan" X-OriginalArrivalTime: 14 Apr 2007 16:04:36.0189 (UTC) FILETIME=[9921D8D0:01C77EAE] X-Spam-Score: 0.1 (/) X-Scan-Signature: cadb9ba0ba1c1ba4f99ac017158fabc3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0407944873==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0407944873== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77EAE.981FB4C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77EAE.981FB4C4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Victor Pasqual wrote: =20 >My opinion is p2psip should be and independent network with no other = service dependence,=20 >p2psip users should be able to perform an overlay in spite there are no = centralised servers (dns, dhcp, ntp..)=20 >neither internet reachability (why not be able to perform an overlay = when climbing the Everest? )=20 >4) we should consider p2psip only as a singaling protocol with = independence of tx media (we can define it at SDP payload) >So, p2psip could be used for audio, video and other media session = signaling =20 Thanks Victor! It was time someone reminded the list what P2P SIP is all = about! =20 Thanks again, Henry =20 ________________________________ From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com]=20 Sent: Saturday, April 14, 2007 2:35 AM To: David A. Bryan Cc: Brian Rosen; Henry Sinnreich; P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" = to think? =20 I agree with both points entirely. But I'd like to keep in mind the = following issues: 1) could we consider SCTP? we could then manage QoS issues at lower = levels if working with MANET 2) could we consider working with IPv6 ip addresses using RFC 2462 IPv6 = Stateless Address Autoconfiguration? (A pure p2p net should not consider a dhcp server). -but i also agree = that using v4 or v6 should not be relevant- 3) is a p2p-sip net a closed net with no other service dependence? = Should p2psip rely on dhcp, dns and so on?=20 My opinion is p2psip should be and independent network with no other = service dependence, p2psip users should be able to perform an overlay in = spite there are no centralised servers (dns, dhcp, ntp..) neither = internet reachability (why not be able to perform an overlay when = climbing the Everest? )=20 4) we should consider p2psip only as a singaling protocol with = independence of tx media (we can define it at SDP payload) So, p2psip could be used for audio, video and other media session = signaling and... why not as a grid computing signaling protocol?=20 Thanks, Victor Pascual On 04/04/07, David A. Bryan wrote: Tend to agree with most of this, but we also need to keep in mind non-telephony P2PSIP applications (say IPTV, voice add-on to gaming etc.) and make sure we don't write things in such a way these capabilities are required for these services as well.=20 =09 David =09 On 4/4/07, Brian Rosen wrote: > I REALLY wish I could transfer a call from Skype to my mobile and = vice > versa. > > I wish I could transfer it to my hardline when, for whatever reason, = the > bandwidth gods are not smiling on me. > > And then there is conferencing. Depending on exactly how = conferencing is > implemented, you may need to transfer to a bridge.=20 > > I really think transfer is an absolute minimal requirement. > > I do think that a rich presence system might obviate the Call forward > issues. I've never seen it done, so I've never been able to try, but = I=20 > could see how it might. > > Conferencing is something that just has to work. > > We need to go down the list of service examples and decide which ones = are > MUST HAVE. > > Brian=20 > > > -----Original Message----- > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > > Sent: Wednesday, April 04, 2007 11:14 AM > > To: Brian Rosen; P2PSIP Mailing List=20 > > Subject: RE: [P2PSIP] When we say "p2psip" what do we want = "consumers" to > > think? > > > > These are good points and actually should copied to the SIPPING = list=20 > > since they apply to the simple SIP Toolkit :-) > > > > Excellent items are these here: > > > > >3. All devices that support audio support wideband audio. > > > > >4. All devices support text (IM and real time interactive). > > > > >5. All devices support presence. We define a minimal set of = presence > > >characteristics that all devices publish.=20 > > > > I take exception here only to the legacy from the voice-only PBX: > > > > >6. We define a minimal feature set (something like unattended and > > >attended > > >transfer, call forward no answer, call forward busy, basic=20 > > conferencing, > > >...) that every device supports the same way. > > > > Let's first look how presence and IM may affect user behavior and = if > > this cannot be a special endpoint app, say for receptionists or = agents.=20 > > > > > This is pretty much what Skype does > > > > I am using Skype now for several years for most long distance calls = and > > for conferences, but have never transferred a call. May be my = secretary=20 > > would transfer a call, but I don't have one :-) > > Nor do 99.99% of consumers or most employees any more. One can IM = the > > number... > > > > Thanks, Henry > >=20 > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, April 04, 2007 9:49 AM > > To: 'P2PSIP Mailing List'=20 > > Subject: [P2PSIP] When we say "p2psip" what do we want "consumers" = to > > think? > > > > One of the things I think we blew big time on sip was that we = didn't=20 > > require > > some fundamental things in every sip device to differentiate them = from > > existing technology. We have an opportunity to fix that with = p2psip, > > and I > > think we should do it.=20 > > > > Now, admittedly, what I'm talking about is somewhat a "marketing" = issue, > > but > > it's a very real thing that we could do which I believe would be > > helpful.=20 > > > > So, I propose: > > 1. We do not support any form of insecure signaling. We define the > > protocol > > to reject attempts to signal without TLS (or whatever). I'm = assuming=20 > > the > > protocols are TCP only. The overlay defines what credentials are = needed > > (and supplies them). > > > > 2. We do not support any form of insecure media. It's always = encrypted.=20 > > This is the tough one, especially if we say we support SIP UAs. > > > > 3. All devices that support audio support wideband audio. > > > > 4. All devices support text (IM and real time interactive).=20 > > > > 5. All devices support presence. We define a minimal set of = presence > > characteristics that all devices publish. > > > > 6. We define a minimal feature set (something like unattended and=20 > > attended > > transfer, call forward no answer, call forward busy, basic = conferencing, > > ...) that every device supports the same way. > > > > 7. All devices work behind a given set of NAT configurations, given = a=20 > > specified set of ICE components (or whatever). > > > > 8. We define what constitutes a minimal configuration set; all of = the > > above > > just work with this level of configuration (and credentials from an = > > overlay). We of course define the configuration mechanism. I'm > > thinking > > that we do this by configuring the device with the credentials, and > > using > > the overlay to provide any other configuration (which could be=20 > > influenced > > by, say, a website the overlay runs) automatically. > > > > All of these are designed to be minimum capabilities, but the idea = is > > that > > ANY device, with credentials on an overlay, can expect to = communicate=20 > > with > > any other device on that overlay with ALL of the above. > > > > Finally, I propose we invent a phrase, something like "p2psip > > conformant" > > which means a device that does that. No protocol police, but the = idea=20 > > is > > that if you say you have a "p2psip conformant" device, it means all = of > > the > > above. Perhaps we have a way to signal that. > > > > This is pretty much what Skype does. Why should we not do that, at = > > least? > > > > Brian > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list=20 > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > =09 =09 -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 Victor Pascual =C1vila mail: victor.pascual.avila@gmail.com = =20 sip:victor.pascual@iptel.org fon user: 223364=20 ------_=_NextPart_001_01C77EAE.981FB4C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Victor Pasqual = wrote:

 

>My opinion is p2psip should be and independent network with = no other service dependence,

>p2psip users should be able to perform an overlay in spite = there are no centralised servers (dns, dhcp, ntp..) =

>neither internet reachability (why not be able to perform an overlay when climbing the Everest? )
>4) we should consider p2psip only as a singaling protocol with = independence of tx media (we can define it at SDP payload)
>So, p2psip could be used for audio, video and other media session = signaling

 

Thanks Victor! It was time someone reminded the list what P2P SIP is all = about!

 

Thanks again, = Henry

 

From: = Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com]
Sent: Saturday, April 14, = 2007 2:35 AM
To: David A. Bryan
Cc: Brian Rosen; = Henry Sinnreich; P2PSIP Mailing List
Subject: Re: [P2PSIP] = When we say "p2psip" what do we want "consumers" to = think?

 

I agree with both points entirely. But I'd like to keep in mind = the following issues:
1) could we consider SCTP? we could then manage QoS issues at lower = levels if working with MANET
2) could we consider working with IPv6 ip addresses using = RFC = 2462 IPv6 Stateless Address Autoconfiguration?
(A pure p2p net should not consider a dhcp server). -but i also agree = that using v4 or v6 should not be relevant-
3) is a p2p-sip net a closed net with no other service dependence? Should p2psip rely on dhcp, dns and so on?
My opinion is p2psip should be and independent network with no other = service dependence, p2psip users should be able to perform an overlay in spite = there are no centralised servers (dns, dhcp, ntp..) neither internet = reachability (why not be able to perform an overlay when climbing the Everest? )
4) we should consider p2psip only as a singaling protocol with = independence of tx media (we can define it at SDP payload)
So, p2psip could be used for audio, video and other media session = signaling and... why not as a grid computing signaling protocol?

Thanks, Victor Pascual
On 04/04/07, David A. = Bryan <dbryan@sipeerior.com> = wrote:

Tend to agree with most of this, but we also need to keep in = mind
non-telephony P2PSIP applications (say IPTV, voice add-on to gaming
etc.) and make sure we don't write things in such a way these
capabilities are required for these services as well.

David

On 4/4/07, Brian Rosen <br@brianrosen.net> wrote:
> I REALLY wish I could transfer a call from Skype to my mobile and = vice
> versa.
>
> I wish I could transfer it to my hardline when, for whatever = reason, the
> bandwidth gods are not smiling on me.
>
> And then there is conferencing.  Depending on exactly how conferencing is
> implemented, you may need to transfer to a bridge.
>
> I really think transfer is an absolute minimal requirement.
>
> I do think that a rich presence system might obviate the Call = forward
> issues.  I've never seen it done, so I've never been able = to try, but I
> could see how it might.
>
> Conferencing is something that just has to work.
>
> We need to go down the list of service examples and decide which = ones are
> MUST HAVE.
>
> Brian
>
> > -----Original Message-----
> > From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
> > Sent: Wednesday, April 04, 2007 11:14 AM
> > To: Brian Rosen; P2PSIP Mailing List
> > Subject: RE: [P2PSIP] When we say "p2psip" what do = we want "consumers" to
> > think?
> >
> > These are good points and actually should copied to the = SIPPING list
> > since they apply to the simple SIP Toolkit :-)
> >
> > Excellent items are these here:
> >
> > >3. All devices that support audio support wideband = audio.
> >
> > >4. All devices support text (IM and real time = interactive).
> >
> > >5. All devices support presence.  We define a = minimal set of presence
> > >characteristics that all devices publish.
> >
> > I take exception here only to the legacy from the voice-only = PBX:
> >
> > >6. We define a minimal feature set (something like = unattended and
> > >attended
> > >transfer, call forward no answer, call forward busy, basic =
> > conferencing,
> > >...) that every device supports the same way.
> >
> > Let's first look how presence and IM may affect user behavior = and if
> > this cannot be a special endpoint app, say for receptionists = or agents.
> >
> > > This is pretty much what Skype does
> >
> > I am using Skype now for several years for most long distance = calls and
> > for conferences, but have never transferred a call. May be my secretary
> > would transfer a call, but I don't have one :-)
> > Nor do 99.99% of consumers or most employees any more. One can = IM the
> > number...
> >
> > Thanks, Henry
> >
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Wednesday, April 04, 2007 9:49 AM
> > To: 'P2PSIP Mailing List'
> > Subject: [P2PSIP] When we say "p2psip" what do we = want "consumers" to
> > think?
> >
> > One of the things I think we blew big time on sip was that we = didn't
> > require
> > some fundamental things in every sip device to differentiate = them from
> > existing technology.  We have an opportunity to fix = that with p2psip,
> > and I
> > think we should do it.
> >
> > Now, admittedly, what I'm talking about is somewhat a "marketing" issue,
> > but
> > it's a very real thing that we could do which I believe would = be
> > helpful.
> >
> > So, I propose:
> > 1. We do not support any form of insecure = signaling.  We define the
> > protocol
> > to reject attempts to signal without TLS (or whatever).  I'm assuming
> > the
> > protocols are TCP only.  The overlay defines what credentials are needed
> > (and supplies them).
> >
> > 2. We do not support any form of insecure = media.  It's always encrypted.
> > This is the tough one, especially if we say we support SIP = UAs.
> >
> > 3. All devices that support audio support wideband audio.
> >
> > 4. All devices support text (IM and real time interactive). =
> >
> > 5. All devices support presence.  We define a = minimal set of presence
> > characteristics that all devices publish.
> >
> > 6. We define a minimal feature set (something like unattended = and
> > attended
> > transfer, call forward no answer, call forward busy, basic conferencing,
> > ...) that every device supports the same way.
> >
> > 7. All devices work behind a given set of NAT configurations, = given a
> > specified set of ICE components (or whatever).
> >
> > 8. We define what constitutes a minimal configuration set; all = of the
> > above
> > just work with this level of configuration (and credentials = from an
> > overlay).  We of course define the configuration mechanism.  I'm
> > thinking
> > that we do this by configuring the device with the = credentials, and
> > using
> > the overlay to provide any other configuration (which could be =
> > influenced
> > by, say, a website the overlay runs) automatically.
> >
> > All of these are designed to be minimum capabilities, but the = idea is
> > that
> > ANY device, with credentials on an overlay, can expect to = communicate
> > with
> > any other device on that overlay with ALL of the above.
> >
> > Finally, I propose we invent a phrase, something like = "p2psip
> > conformant"
> > which means a device that does that.  No protocol = police, but the idea
> > is
> > that if you say you have a "p2psip conformant" = device, it means all of
> > the
> > above.  Perhaps we have a way to signal that.
> >
> > This is pretty much what Skype does.  Why should we = not do that, at
> > least?
> >
> > Brian
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > P2PSIP@ietf.org
> > https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>


--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip




--
Victor Pascual =C1vila

mail: victor.pascual.avila@gmail.com
sip:victor.pascual@iptel.org
= fon user: 223364

------_=_NextPart_001_01C77EAE.981FB4C4-- --===============0407944873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0407944873==-- From p2psip-bounces@ietf.org Sat Apr 14 12:11:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HckqS-0003H5-GD; Sat, 14 Apr 2007 12:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HckqR-0003H0-P8 for p2psip@ietf.org; Sat, 14 Apr 2007 12:11:23 -0400 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HckqQ-0005oZ-F7 for p2psip@ietf.org; Sat, 14 Apr 2007 12:11:23 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1067583nzd for ; Sat, 14 Apr 2007 09:11:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=fKx1tQmoZu66NWVGyhpaCzTPhSHwXqIr0V1g8vw/lwvUFmR0nPxThdb2W+Ya7O72Dio4FrBrieDqrQQFQY1vWy4Rxmm10pWKTFJfD33xP3sHfVLDYLFLl744pXQbqGIy8sHknH8KC7JoPiw3C5aFJPq8Ue+UJ9ysPqvyfqW00gU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Gc2VOyerBKSfrdbWKu03WRA0TUJ7cAVNNOZRx7fyld6RIgFVmnskEv4U8FmwXg36aWvs4F3dB/p+hY/aTnWinJ5JYd4soE4xZ/F892bWEnWH0Xf/yUThWeHwbIJ6KUYK31l/tDXdYmHbpcSW+t2NZjkXnXHvuyAK/wZAaMYSq+0= Received: by 10.114.202.15 with SMTP id z15mr1401808waf.1176567081583; Sat, 14 Apr 2007 09:11:21 -0700 (PDT) Received: by 10.114.198.8 with HTTP; Sat, 14 Apr 2007 09:11:21 -0700 (PDT) Message-ID: <9dc4a1670704140911l68608345j99a1e19822b8c807@mail.gmail.com> Date: Sat, 14 Apr 2007 12:11:21 -0400 From: EdPimentl To: "P2PSIP Mailing List" Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" to think? In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226B30AC@namail5.corp.adobe.com> MIME-Version: 1.0 References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com> <1e2701c776cd$72299710$81238182@cis.neustar.com> <4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com> <618e24240704140234l75c444a7jc049d7b0d10f6099@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D226B30AC@namail5.corp.adobe.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1319863236==" Errors-To: p2psip-bounces@ietf.org --===============1319863236== Content-Type: multipart/alternative; boundary="----=_Part_15165_2958494.1176567081184" ------=_Part_15165_2958494.1176567081184 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Would using an alias as a reminder help us keep these point top of mind? P2PSIP is FINE "Future Internet Network Engineering" :-) -Ed On 4/14/07, Henry Sinnreich wrote: > > Victor Pasqual wrote: > > >My opinion is p2psip should be and independent network with no other > service dependence, > >p2psip users should be able to perform an overlay in spite there are no > centralised servers (dns, dhcp, ntp..) > >neither internet reachability (why not be able to perform an overlay when > climbing the Everest? ) > >4) we should consider p2psip only as a singaling protocol with > independence of tx media (we can define it at SDP payload) > >So, p2psip could be used for audio, video and other media session > signaling > > Thanks Victor! It was time someone reminded the list what P2P SIP is all > about! > > Thanks again, Henry > > > > ------=_Part_15165_2958494.1176567081184 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Would using an alias as a reminder help us keep these point top of mind?
P2PSIP is  FINE   "Future Internet Network Engineering"   :-)

-Ed

On 4/14/07, Henry Sinnreich <hsinnrei@adobe.com> wrote:

Victor Pasqual wrote:

>My opinion is p2psip should be and independent network with no other service dependence,
>p2psip users should be able to perform an overlay in spite there are no centralised servers (dns, dhcp, ntp..)
>neither internet reachability (why not be able to perform an overlay when climbing the Everest? )
>4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload)
>So, p2psip could be used for audio, video and other media session signaling

Thanks Victor! It was time someone reminded the list what P2P SIP is all about!

Thanks again, Henry

 


------=_Part_15165_2958494.1176567081184-- --===============1319863236== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1319863236==-- From p2psip-bounces@ietf.org Sat Apr 14 12:15:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hckul-00073m-0W; Sat, 14 Apr 2007 12:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hckuj-00073c-LS for p2psip@ietf.org; Sat, 14 Apr 2007 12:15:49 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hckue-00078N-3l for p2psip@ietf.org; Sat, 14 Apr 2007 12:15:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sat, 14 Apr 2007 09:15:43 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3EGF9D1029128; Sat, 14 Apr 2007 09:15:09 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3EGFe0c003615; Sat, 14 Apr 2007 09:15:41 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 09:15:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Sat, 14 Apr 2007 09:15:20 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226B30AE@namail5.corp.adobe.com> In-Reply-To: <9dc4a1670704140911l68608345j99a1e19822b8c807@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd+r5CGZzUWF84TQjWHCZshfQ7RBAAACWTg References: <24CCCC428EFEA2469BF046DB3C7A8D223ADF3C@namail5.corp.adobe.com><1e2701c776cd$72299710$81238182@cis.neustar.com><4d4304a00704040830h3249841bw591de6394ac02b25@mail.gmail.com><618e24240704140234l75c444a7jc049d7b0d10f6099@mail.gmail.com><24CCCC428EFEA2469BF046DB3C7A8D226B30AC@namail5.corp.adobe.com> <9dc4a1670704140911l68608345j99a1e19822b8c807@mail.gmail.com> From: "Henry Sinnreich" To: "EdPimentl" , "P2PSIP Mailing List" X-OriginalArrivalTime: 14 Apr 2007 16:15:39.0426 (UTC) FILETIME=[2473C820:01C77EB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0469292402==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0469292402== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77EB0.21AB99AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77EB0.21AB99AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > P2PSIP is FINE "Future Internet Network Engineering" :-) =20 Actually, the P2P SIP work comes a little late, at the time when p2p traffic already dominates the Internet and Skype dominates VoIP. =20 So LATE may be more appropriate than FINE :-( =20 Henry =20 ________________________________ From: EdPimentl [mailto:edpimentl@gmail.com]=20 Sent: Saturday, April 14, 2007 9:11 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? =20 Would using an alias as a reminder help us keep these point top of mind? P2PSIP is FINE "Future Internet Network Engineering" :-) -Ed On 4/14/07, Henry Sinnreich wrote: Victor Pasqual wrote: >My opinion is p2psip should be and independent network with no other service dependence, >p2psip users should be able to perform an overlay in spite there are no centralised servers (dns, dhcp, ntp..) >neither internet reachability (why not be able to perform an overlay when climbing the Everest? )=20 >4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload) >So, p2psip could be used for audio, video and other media session signaling Thanks Victor! It was time someone reminded the list what P2P SIP is all about! Thanks again, Henry =20 =20 ------_=_NextPart_001_01C77EB0.21AB99AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> P2PSIP is  FINE   "Future Internet Network = Engineering"   :-)

 

Actually, the P2P SIP work comes a little late, at the time when = p2p traffic already dominates the Internet and Skype dominates = VoIP.

 

So LATE may be more appropriate than FINE L

 

Henry

 

From: = EdPimentl [mailto:edpimentl@gmail.com]
Sent: Saturday, April 14, = 2007 9:11 AM
To: P2PSIP Mailing = List
Subject: Re: [P2PSIP] = When we say "p2psip" what do we want "consumers" = tothink?

 

Would using an = alias as a reminder help us keep these point top of mind?
P2PSIP is  FINE   "Future Internet Network Engineering"   :-)

-Ed

On 4/14/07, Henry Sinnreich = <hsinnrei@adobe.com> = wrote:

Victor Pasqual wrote:

>My opinion is p2psip should be and independent network with no other = service dependence,
>p2psip users should be able to perform an overlay in spite there are = no centralised servers (dns, dhcp, ntp..)
>neither internet reachability (why not be able to perform an overlay = when climbing the Everest? )
>4) we should consider p2psip only as a singaling protocol with = independence of tx media (we can define it at SDP payload)
>So, p2psip could be used for audio, video and other media session = signaling

Thanks Victor! It was time someone reminded the list = what P2P SIP is all about!

Thanks again, Henry

 

 

------_=_NextPart_001_01C77EB0.21AB99AD-- --===============0469292402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0469292402==-- From p2psip-bounces@ietf.org Mon Apr 16 10:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSOJ-0004gJ-28; Mon, 16 Apr 2007 10:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSOH-0004Zj-Kr for p2psip@ietf.org; Mon, 16 Apr 2007 10:41:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSOG-0003yo-63 for p2psip@ietf.org; Mon, 16 Apr 2007 10:41:13 -0400 Received: by ug-out-1314.google.com with SMTP id 72so895536ugd for ; Mon, 16 Apr 2007 07:41:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HcNSy+wp6I70KhnWOMvr1Z60dUie36GmzLQF6ahvBSpKNEULNja97b5YR5tG7Neaqk45HZZF4pd1HCy3XxMmFJb6GucOmd3OLq+kanNDyF29BauGchbknE0aq52FyLGN7HCiQaoUZo/b4BiC678hMjKJXJECd9MmZNWL2/GN/Gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rikDF2J4EgVFmKmixxbv8eKYOGBN0yl1tPkwo6Xfy748+Xu/hXwuRQM3OrSrHSlqUi87mz7D/CpBqYd602etMblQukhAYal3Y/tA3B4y4vNWByXiOVqQ4uiJLMbUFvlqVjgj7hQjy50j/8+VbwHswGS/ha1OWOyb0YYS4NLmfTU= Received: by 10.82.153.5 with SMTP id a5mr8523085bue.1176734470633; Mon, 16 Apr 2007 07:41:10 -0700 (PDT) Received: by 10.82.106.15 with HTTP; Mon, 16 Apr 2007 07:41:10 -0700 (PDT) Message-ID: <4d4304a00704160741p766e62bdhe2d47f55fde18c55@mail.gmail.com> Date: Mon, 16 Apr 2007 10:41:10 -0400 From: "David A. Bryan" To: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" Subject: Re: [P2PSIP] Roles In-Reply-To: <618e24240704140246i3dc18fafx8eae4de8c745c059@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9dc4a1670703231044g117a216bhb9aad0faeeb8a5b@mail.gmail.com> <000001c7701c$1c1630c0$af244e0a@china.huawei.com> <618e24240704140246i3dc18fafx8eae4de8c745c059@mail.gmail.com> X-Google-Sender-Auth: d96c7ba524171ad4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Philip Matthews , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Indeed, and use some mechanism to pass off any information it is responsible for. On 4/14/07, Victor Pascual =C1vila wrote: > What about the leaving node? When a responsible node for a dht-hash area > performs a planned leave from the overlay it should delegate it's > responsibilities when possible. Is it correct? > > Thanks, Victor Pascual > > > On 27/03/07, zhuxian wrote: > > > > > > > > EdPimentl, > > > > These authentication mechanisms are typical used in the C/S model. In t= he > P2P model, SAML assertion or identity can be easily replayed, for the pee= r > receieved the assertion can replay it. But this may not be happened in th= e > C/S model, as we often believed that the server is trusted enough. > > > > So, even we use the SAML assertion, it also need some authentication > mechanisms to prove the peer sending the SAML assertion is the peer ownin= g > the SAML assertion. > > > > This is why I believe that peer should authenticate each other at all > times. > > > > > > Kurt Zhu > > > > > > > > ________________________________ > From: EdPimentl [mailto:edpimentl@gmail.com] > > Sent: Saturday, March 24, 2007 1:44 AM > > To: zhuxian > > Cc: David A. Bryan; Henning Schulzrinne; Philip Matthews; p2psip@ietf.o= rg > > Subject: Re: [P2PSIP] Roles > > > > > > > > As we explore authentication mechanisms. > > It would good to consider one of the following methods for authenticati= on, > authorizations and entitlements such as: > > http://dev.inames.net/wiki/Tech_FAQs > > http://www.sourceid.org/ > > http://www.projectliberty.org/ > > > > My .02 > > Best, > > -E > > > > > > > > > > On 3/23/07, zhuxian wrote: > > > I fully agree with the following sentence from David: > > > In a peer-to-peer system, all peers must check all credentials at > all > > > times. > > > > > > Even if a centralized authentication server has been deployed in the > > > hybrid-p2p scenario, every peer should also authenticate each other a= t > all > > > times. Otherwise, the peer could not confirm whether another peer is > admited > > > by the authentication server, or it just join the overlay through its > > > colluding peer. > > > > > > Kurt Zhu > > > > > > > > > > > > -- > > Thanks in advance and best regards, > > > > Ed Pimentel > > AgileCO > > Founder > > > > Mail: edpimentl[at]gmail.com > > sip: sip:2150112@truphone.com > > IM: edpimentl [AOL | Jabber | Yahoo | MSN ] > > Voip: edpimentl [SKype | GoogleTalk ] > > > > Mobile Content Marketing/Management/Digital Delivery > > http://mobilecentral.ws > > > > Mobile ( Relevant, Ambient Intelligence, Location ) based Social Networ= k > > http://TagR.mobi (Alpha) > > > > Mobile Payment - P2P Payment > > http://agilepay.ws > > > > Sponsor of P2PSIP open source [viasip_ng] project > > Creating a standards base P2PSIP dSIP infrastructure > > https://sourceforge.net/projects/viasip/ > > Mailing List viasip_ng@freelists.org > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > -- > Victor Pascual =C1vila > > mail:victor.pascual.avila@gmail.com > sip:victor.pascual@iptel.org > fon user: 223364 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 17 04:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdj0L-00078Y-BM; Tue, 17 Apr 2007 04:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdj0K-00078T-6w for p2psip@ietf.org; Tue, 17 Apr 2007 04:25:36 -0400 Received: from sernt4.essex.ac.uk ([155.245.48.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdj0J-0007fa-H1 for p2psip@ietf.org; Tue, 17 Apr 2007 04:25:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Tue, 17 Apr 2007 09:25:31 +0100 Message-ID: <811D385AE1CEBB42839C50DF0B0D38E003D35A4D@sernt4.essex.ac.uk> In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D226B30AE@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd+r5CGZzUWF84TQjWHCZshfQ7RBAAACWTgAIYxI3A= From: "Oredope, Adetola" To: "Henry Sinnreich" , "EdPimentl" , "P2PSIP Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2108063153==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2108063153== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C780C9.F6301ACC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C780C9.F6301ACC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I really do believe that P2P-SIP when fully developed can still give skype a run for its money and this is due to many reasons such as P2P-SIP will facilitate trusted and secured interconnectivity between domains. Also, due to it standardized and Open-source approach new services can easily be developed (cf the Internet) Even skype can admit that since releasing some APIs, thousand of news services that were not thought about have emerge all of a sudden. Who ever though that there could be a Skype Enterprise Edition? P2P-SIP is the way forward! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: 14 April 2007 17:15 To: EdPimentl; P2PSIP Mailing List Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? =09 =09 > P2PSIP is FINE "Future Internet Network Engineering" :-) =20 Actually, the P2P SIP work comes a little late, at the time when p2p traffic already dominates the Internet and Skype dominates VoIP. =20 So LATE may be more appropriate than FINE :-( =20 Henry =20 =09 ________________________________ From: EdPimentl [mailto:edpimentl@gmail.com]=20 Sent: Saturday, April 14, 2007 9:11 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? =20 Would using an alias as a reminder help us keep these point top of mind?=20 P2PSIP is FINE "Future Internet Network Engineering" :-) =09 -Ed On 4/14/07, Henry Sinnreich wrote: Victor Pasqual wrote: >My opinion is p2psip should be and independent network with no other service dependence, >p2psip users should be able to perform an overlay in spite there are no centralised servers (dns, dhcp, ntp..) >neither internet reachability (why not be able to perform an overlay when climbing the Everest? )=20 >4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload) >So, p2psip could be used for audio, video and other media session signaling Thanks Victor! It was time someone reminded the list what P2P SIP is all about! Thanks again, Henry =20 =20 ------_=_NextPart_001_01C780C9.F6301ACC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message=

I=20 really do believe that P2P-SIP when fully developed can still give = skype a=20 run for its money and this is due to many reasons such as P2P-SIP will=20 facilitate trusted and secured interconnectivity between domains. Also, = due to=20 it standardized and Open-source approach new services can easily be = developed=20 (cf the Internet)

Even=20 skype can admit that since releasing some APIs, thousand of news = services that=20 were not thought about have emerge all of a sudden. Who ever though that = there=20 could be a Skype Enterprise Edition?

P2P-SIP is the=20 way forward!

-----Original Message-----
From: = Henry Sinnreich=20 [mailto:hsinnrei@adobe.com]
Sent: 14 April 2007 = 17:15
To:=20 EdPimentl; P2PSIP Mailing List
Subject: RE: [P2PSIP] When we = say=20 "p2psip" what do we want "consumers" tothink?

>=20 P2PSIP is  FINE   "Future Internet Network=20 Engineering"   :-)

 

Actually, the P2P SIP work comes a little = late, at the=20 time when p2p traffic already dominates the Internet and Skype = dominates=20 VoIP.

 

So LATE may be more appropriate than FINE=20 L

 

Henry

 

From:=20 EdPimentl [mailto:edpimentl@gmail.com]
Sent: Saturday, April 14, 2007 = 9:11=20 AM
To: P2PSIP = Mailing=20 List
Subject: Re: = [P2PSIP]=20 When we say "p2psip" what do we want "consumers"=20 tothink?

 

Would using an alias as a = reminder help=20 us keep these point top of mind?
P2PSIP is  FINE   = "Future=20 Internet Network Engineering"  =20 :-)

-Ed

On 4/14/07, Henry=20 Sinnreich <hsinnrei@adobe.com>=20 wrote:

Victor = Pasqual=20 wrote:

>My=20 opinion is p2psip should be and independent network with no other = service=20 dependence,
>p2psip users should be able to perform an overlay = in spite=20 there are no centralised servers (dns, dhcp, ntp..)
>neither = internet=20 reachability (why not be able to perform an overlay when climbing the = Everest?=20 )
>4) we should consider p2psip only as a singaling protocol = with=20 independence of tx media (we can define it at SDP payload)
>So, = p2psip=20 could be used for audio, video and other media session=20 signaling

Thanks = Victor! It was=20 time someone reminded the list what P2P SIP is all=20 about!

Thanks = again,=20 Henry

 

 

= ------_=_NextPart_001_01C780C9.F6301ACC-- --===============2108063153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2108063153==-- From p2psip-bounces@ietf.org Tue Apr 17 08:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnEf-0007UI-DP; Tue, 17 Apr 2007 08:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnEf-0007UD-3F for p2psip@ietf.org; Tue, 17 Apr 2007 08:56:41 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdnEc-0000nx-Ah for p2psip@ietf.org; Tue, 17 Apr 2007 08:56:41 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Apr 2007 05:56:28 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3HCtoD1016612; Tue, 17 Apr 2007 05:55:51 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3HCuN0c004552; Tue, 17 Apr 2007 05:56:23 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 05:56:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Date: Tue, 17 Apr 2007 05:54:44 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F5826@namail5.corp.adobe.com> In-Reply-To: <811D385AE1CEBB42839C50DF0B0D38E003D35A4D@sernt4.essex.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? Thread-Index: Acd+r5CGZzUWF84TQjWHCZshfQ7RBAAACWTgAIYxI3AACbGecA== References: <24CCCC428EFEA2469BF046DB3C7A8D226B30AE@namail5.corp.adobe.com> <811D385AE1CEBB42839C50DF0B0D38E003D35A4D@sernt4.essex.ac.uk> From: "Henry Sinnreich" To: "Oredope, Adetola" , "EdPimentl" , "P2PSIP Mailing List" X-OriginalArrivalTime: 17 Apr 2007 12:56:22.0527 (UTC) FILETIME=[CCD308F0:01C780EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: fa183e2955b1d12e35b5783ab5b4f6df Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0983547643==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0983547643== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C780EF.CCB453A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C780EF.CCB453A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adetola Oredope wrote: =20 >I really do believe that P2P-SIP when fully developed can still give skype a run for its money and this is due to many reasons=20 =20 Many of us fully agree with you. Thanks for the good note! =20 Henry =20 ________________________________ From: Oredope, Adetola [mailto:aoredo@essex.ac.uk]=20 Sent: Tuesday, April 17, 2007 1:26 AM To: Henry Sinnreich; EdPimentl; P2PSIP Mailing List Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? =20 I really do believe that P2P-SIP when fully developed can still give skype a run for its money and this is due to many reasons such as P2P-SIP will facilitate trusted and secured interconnectivity between domains. Also, due to it standardized and Open-source approach new services can easily be developed (cf the Internet) Even skype can admit that since releasing some APIs, thousand of news services that were not thought about have emerge all of a sudden. Who ever though that there could be a Skype Enterprise Edition? P2P-SIP is the way forward! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: 14 April 2007 17:15 To: EdPimentl; P2PSIP Mailing List Subject: RE: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? > P2PSIP is FINE "Future Internet Network Engineering" :-) =20 Actually, the P2P SIP work comes a little late, at the time when p2p traffic already dominates the Internet and Skype dominates VoIP. =20 So LATE may be more appropriate than FINE :-( =20 Henry =20 =09 ________________________________ From: EdPimentl [mailto:edpimentl@gmail.com]=20 Sent: Saturday, April 14, 2007 9:11 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] When we say "p2psip" what do we want "consumers" tothink? =20 Would using an alias as a reminder help us keep these point top of mind?=20 P2PSIP is FINE "Future Internet Network Engineering" :-) =09 -Ed On 4/14/07, Henry Sinnreich wrote: Victor Pasqual wrote: >My opinion is p2psip should be and independent network with no other service dependence, >p2psip users should be able to perform an overlay in spite there are no centralised servers (dns, dhcp, ntp..) >neither internet reachability (why not be able to perform an overlay when climbing the Everest? )=20 >4) we should consider p2psip only as a singaling protocol with independence of tx media (we can define it at SDP payload) >So, p2psip could be used for audio, video and other media session signaling Thanks Victor! It was time someone reminded the list what P2P SIP is all about! Thanks again, Henry =20 =20 ------_=_NextPart_001_01C780EF.CCB453A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Adetola Oredope = wrote:

 

>I really do believe that = P2P-SIP when fully developed can still give skype a run for its money and this = is due to many reasons

 

Many of us fully agree with you. = Thanks for the good note!

 

Henry

 

From: = Oredope, Adetola [mailto:aoredo@essex.ac.uk]
Sent: Tuesday, April 17, = 2007 1:26 AM
To: Henry Sinnreich; EdPimentl; P2PSIP Mailing List
Subject: RE: [P2PSIP] = When we say "p2psip" what do we want "consumers" = tothink?

 

I really do believe that P2P-SIP = when fully developed can still give skype a run for its money and this = is due to many reasons such as P2P-SIP will facilitate trusted and secured interconnectivity between domains. Also, due to it standardized and = Open-source approach new services can easily be developed (cf the = Internet)

Even skype can admit that since = releasing some APIs, thousand of news services that were not thought about have = emerge all of a sudden. Who ever though that = there could be a Skype Enterprise Edition?

P2P-SIP is the way = forward!

-----Original = Message-----
From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: 14 April 2007 = 17:15
To: EdPimentl; P2PSIP = Mailing List
Subject: RE: [P2PSIP] = When we say "p2psip" what do we want "consumers" = tothink?

> P2PSIP is  FINE   "Future Internet Network = Engineering"   :-)

 

Actually, the P2P SIP work comes a little late, at the time when = p2p traffic already dominates the Internet and Skype dominates = VoIP.

 

So LATE may be more appropriate than FINE L

 

Henry

 

From: = EdPimentl [mailto:edpimentl@gmail.com]
Sent: Saturday, April 14, = 2007 9:11 AM
To: P2PSIP Mailing = List
Subject: Re: [P2PSIP] = When we say "p2psip" what do we want "consumers" = tothink?

 

Would using an = alias as a reminder help us keep these point top of mind?
P2PSIP is  FINE   "Future Internet Network Engineering"   :-)

-Ed

On 4/14/07, Henry Sinnreich = <hsinnrei@adobe.com> = wrote:

Victor Pasqual wrote:

>My opinion is p2psip should be and independent network with no other = service dependence,
>p2psip users should be able to perform an overlay in spite there are = no centralised servers (dns, dhcp, ntp..)
>neither internet reachability (why not be able to perform an overlay = when climbing the Everest? )
>4) we should consider p2psip only as a singaling protocol with = independence of tx media (we can define it at SDP payload)
>So, p2psip could be used for audio, video and other media session = signaling

Thanks Victor! It was time someone reminded the list = what P2P SIP is all about!

Thanks again, Henry

 

 

------_=_NextPart_001_01C780EF.CCB453A9-- --===============0983547643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0983547643==-- From p2psip-bounces@ietf.org Tue Apr 17 21:48:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzHg-0001zC-Pr; Tue, 17 Apr 2007 21:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzHd-0001z6-Rb for p2psip@ietf.org; Tue, 17 Apr 2007 21:48:33 -0400 Received: from smtp3.akamai.com ([63.116.109.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdzHc-0007jf-FI for p2psip@ietf.org; Tue, 17 Apr 2007 21:48:33 -0400 Received: from smtp3.akamai.com (vwall1.sanmateo.corp.akamai.com [172.23.1.71]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3I1mf95022642 for ; Tue, 17 Apr 2007 18:48:41 -0700 (PDT) Received: from USCA1EX-GATE1.sanmateo.corp.akamai.com (usca1ex-gate1.sanmateo.corp.akamai.com [172.23.1.110]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3I1meZs022632 for ; Tue, 17 Apr 2007 18:48:40 -0700 (PDT) Received: from CAVS1.sanmateo.corp.akamai.com ([172.23.1.125]) by USCA1EX-GATE1.sanmateo.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 18:52:24 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Apr 2007 18:48:30 -0700 Message-ID: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Thread-Index: AceBW6pZCYVRQCrsQtKRwpN34e7Olg== From: "Barrett, David" To: X-OriginalArrivalTime: 18 Apr 2007 01:52:24.0781 (UTC) FILETIME=[361727D0:01C7815C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org So I'm behind the times, but I just became aware that the BEHAVE group, = which is the IETF group dedicated to specifying future NAT behavior, = decided in 8/2005 to recommend that NATs by default implement = "endpoint-dependent" (aka "restricted cone") filtering. If this became = the norm, so far as I understand it, wouldn=92t P2P-SIP cease to = function? Basically, all decentralized P2P networks would stop working as the = ratio of "accessible" to "inaccessible" nodes trends toward zero. At = that point, basically no DHT can possibly function because nobody can = accept unsolicited incoming connections. Indeed, in this world (the world that BEHAVE is trying to create), only = Napster-style, centrally-managed P2P networks can function. In other = words, all DHTs and decentralized overlay networks *will not work* if = BEHAVE succeeds. Is this correct and commonly understood? Should we talk with the BEHAVE = folks about this? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 17 22:04:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzWb-0000PJ-UT; Tue, 17 Apr 2007 22:04:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzWa-0000JZ-Hj for p2psip@ietf.org; Tue, 17 Apr 2007 22:04:00 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdzWZ-0005Tz-A5 for p2psip@ietf.org; Tue, 17 Apr 2007 22:04:00 -0400 Received: by py-out-1112.google.com with SMTP id f31so3458pyh for ; Tue, 17 Apr 2007 19:03:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=A3LROZN9DoEYm8fXIOwIdf8FPNjxMagXR+q9E7tIPeXLsZF4cgHN+SAafwDJIk164JqDfi5L2Cv6XreRZPuq0FvSuqMt8sjnIWk24WSD9kREMwgUN8GHTBw2xU5eNA4S/jzftct3wl7Tm1AZQIntiP603wzhSquPt2edSr5GzSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UvqBPVdCUombedK3chHAfhk758xDvoW4T1oVfaYLRg7QB/4wDnblZ+Wl6ATsrmkBsfJTwRZuRyEIPtAKdEf5n5ZKcfgsy+Rw3tRKqbeqSJwu54z3L9vrBn49XSRE46inSrQhfkwXVDWU8q39Liigo867AX/gJoipEmiW2YrTny8= Received: by 10.35.103.12 with SMTP id f12mr10642pym.1176861838966; Tue, 17 Apr 2007 19:03:58 -0700 (PDT) Received: by 10.35.107.17 with HTTP; Tue, 17 Apr 2007 19:03:58 -0700 (PDT) Message-ID: <20d2bdfb0704171903v7f4d340g83f8d0be4fa59162@mail.gmail.com> Date: Tue, 17 Apr 2007 22:03:58 -0400 From: "Bruce Lowekamp" To: "Barrett, David" Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> X-Google-Sender-Auth: 2181e8110100bb1f X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 4/17/07, Barrett, David wrote: > So I'm behind the times, but I just became aware that the BEHAVE group, which is the IETF group dedicated to specifying future NAT behavior, decided in 8/2005 to recommend that NATs by default implement "endpoint-dependent" (aka "restricted cone") filtering. If this became the norm, so far as I understand it, wouldn't P2P-SIP cease to function? > Here is the text from RFC4787: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. > Basically, all decentralized P2P networks would stop working as the ratio of "accessible" to "inaccessible" nodes trends toward zero. At that point, basically no DHT can possibly function because nobody can accept unsolicited incoming connections. > > Indeed, in this world (the world that BEHAVE is trying to create), only Napster-style, centrally-managed P2P networks can function. In other words, all DHTs and decentralized overlay networks *will not work* if BEHAVE succeeds. > > Is this correct and commonly understood? Should we talk with the BEHAVE folks about this? It's not a problem. (well, it makes life a bit harder, but the solutions aren't too bad.) Philip, Eric, David, and I wrote draft-matthews-p2psip-dsip-nat-traversal that describes how to use ICE to open connections between peers behind NATs that have endpoint dependent filtering. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 17 22:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzrT-0005zv-Jk; Tue, 17 Apr 2007 22:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzrT-0005zf-AM for p2psip@ietf.org; Tue, 17 Apr 2007 22:25:35 -0400 Received: from smtp3.akamai.com ([63.116.109.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdzrR-0003ao-Vw for p2psip@ietf.org; Tue, 17 Apr 2007 22:25:35 -0400 Received: from smtp3.akamai.com (vwall3.sanmateo.corp.akamai.com [172.23.1.73]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3I2PhbH021870 for ; Tue, 17 Apr 2007 19:25:43 -0700 (PDT) Received: from USCA1EX-GATE1.sanmateo.corp.akamai.com (usca1ex-gate1.sanmateo.corp.akamai.com [172.23.1.110]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3I2PgxR021859; Tue, 17 Apr 2007 19:25:42 -0700 (PDT) Received: from CAVS1.sanmateo.corp.akamai.com ([172.23.1.125]) by USCA1EX-GATE1.sanmateo.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 19:29:26 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Apr 2007 19:25:32 -0700 Message-ID: <38464B16719C77439C06051F392AB9E6062EB2EF@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Thread-Index: AceBXdcfievHn5E2TOi3AfuHmEOQZgAAVP9A References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <20d2bdfb0704171903v7f4d340g83f8d0be4fa59162@mail.gmail.com> From: "Barrett, David" To: "Bruce Lowekamp" X-OriginalArrivalTime: 18 Apr 2007 02:29:26.0656 (UTC) FILETIME=[626E6000:01C78161] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Got it, thanks. Basically, use a partial-mesh of long-lived connections = such so long as everyone has a connection to somebody, they can always = establish a connection to everybody (is that a fair summary?). So that seems like a fine mitigation strategy that will enable DHTs (and = other decentralized networks) to live for a few more years. But as the = ratio of NAT'd to non-NAT'd increases, and as the ratio of dependent to = independent filtering increases, won't even this fail eventually? (Not to mention that if endpoint-dependent filtering becomes the norms = for NATs, it'll also become the norm for firewalls, and thus even the = non-NAT'd clients become inaccessible -- both IPv4 and IPv6. Imagine = for a second if this became the standard for Windows Firewall? Game = over.) Fundamentally, the point I'm making is that BEHAVE is actively fighting = what P2P-SIP wants: end-to-end accessibility. Even if it's not a bullet = to the head in the short term, we're on opposite sides of the issue for = the long term. I bring this up because when researching the reasoning behind the BEHAVE = decision, it just came down to numbers: there was a vote, and only one = DHT advocate was there, so he was outvoted. Does P2P-SIP feel that it = was fairly represented in this issue? -david -----Original Message----- From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] It's not a problem. (well, it makes life a bit harder, but the solutions aren't too bad.) Philip, Eric, David, and I wrote draft-matthews-p2psip-dsip-nat-traversal that describes how to use ICE to open connections between peers behind NATs that have endpoint dependent filtering. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 17 22:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He05g-0003iR-Im; Tue, 17 Apr 2007 22:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He05f-0003i5-Np for p2psip@ietf.org; Tue, 17 Apr 2007 22:40:15 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He05e-0005cn-Fh for p2psip@ietf.org; Tue, 17 Apr 2007 22:40:15 -0400 Received: by py-out-1112.google.com with SMTP id f31so10001pyh for ; Tue, 17 Apr 2007 19:40:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HrNkEBHmJ1YTLV7GmxP8iMVeoawrVELIKCPhMGpL7LprrOZOtTdRqAmMTBMCpTmxKGy3a1sjQa2+qOCwaE6pD8Gqi5z6qQhpdTmPkyBXNaAzkGeM8d/fMXwAZXF244dNzH0dvfMgGuLvneCosMT7jzw0kb4MKKpjW5iO6Zs0Fvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=c8DlVZF21O1ASzlv0S6xP2lJaDwBfhOzuMT/ulVdd9b7aJBPOkCdrFXTdmIm4U+e2PPmFIOtA8qpNnJRNf91vycYjjazqjgq89vOOz7Y5TWgf2nnbp0k9EG50zUmfLDbl2Bqp0ai1PxPChRFaaDBi/c8zHYYe5Va5jtNxN4HByA= Received: by 10.35.49.15 with SMTP id b15mr651pyk.1176864014230; Tue, 17 Apr 2007 19:40:14 -0700 (PDT) Received: by 10.35.107.17 with HTTP; Tue, 17 Apr 2007 19:40:14 -0700 (PDT) Message-ID: <20d2bdfb0704171940rda6ea2ck8948d4929bac1464@mail.gmail.com> Date: Tue, 17 Apr 2007 22:40:14 -0400 From: "Bruce Lowekamp" To: "Barrett, David" Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EF@CAVS1.sanmateo.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <20d2bdfb0704171903v7f4d340g83f8d0be4fa59162@mail.gmail.com> <38464B16719C77439C06051F392AB9E6062EB2EF@CAVS1.sanmateo.corp.akamai.com> X-Google-Sender-Auth: 707af6cc571941ce X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think that this solution continues to work as the proportion of endpoint-dependent filtering NATs increases, it just requires a bit more work (you always need to ask for help to establish a new connection). The solution starts to fail as the proportion of endpoint-depending mapping NATs increases, but hopefully 4787's MUST be endpoint-independent mapping will avert that problem. IIRC, there were some manufacturers who were prepared to ignore behave's output entirely if it said MUST be endpoint-independent filtering, but I may be misremembering (and I wasn't at Paris). Since there are workarounds, the argument for requiring it wasn't as strong as for mapping. Bruce On 4/17/07, Barrett, David wrote: > Got it, thanks. Basically, use a partial-mesh of long-lived connections such so long as everyone has a connection to somebody, they can always establish a connection to everybody (is that a fair summary?). > > So that seems like a fine mitigation strategy that will enable DHTs (and other decentralized networks) to live for a few more years. But as the ratio of NAT'd to non-NAT'd increases, and as the ratio of dependent to independent filtering increases, won't even this fail eventually? > > (Not to mention that if endpoint-dependent filtering becomes the norms for NATs, it'll also become the norm for firewalls, and thus even the non-NAT'd clients become inaccessible -- both IPv4 and IPv6. Imagine for a second if this became the standard for Windows Firewall? Game over.) > > Fundamentally, the point I'm making is that BEHAVE is actively fighting what P2P-SIP wants: end-to-end accessibility. Even if it's not a bullet to the head in the short term, we're on opposite sides of the issue for the long term. > > I bring this up because when researching the reasoning behind the BEHAVE decision, it just came down to numbers: there was a vote, and only one DHT advocate was there, so he was outvoted. Does P2P-SIP feel that it was fairly represented in this issue? > > -david > > -----Original Message----- > From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] > > It's not a problem. (well, it makes life a bit harder, but the > solutions aren't too bad.) Philip, Eric, David, and I wrote > draft-matthews-p2psip-dsip-nat-traversal that describes how to use ICE > to open connections between peers behind NATs that have endpoint > dependent filtering. > > Bruce > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 18 03:58:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He53X-0007qw-GR; Wed, 18 Apr 2007 03:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He53V-0007qo-M2 for p2psip@ietf.org; Wed, 18 Apr 2007 03:58:21 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He53T-0004PE-Cs for p2psip@ietf.org; Wed, 18 Apr 2007 03:58:21 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:58:17 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:58:17 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:58:16 +0200 Message-ID: <4625CFB2.4070101@telecomitalia.it> Date: Wed, 18 Apr 2007 09:58:42 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "Barrett, David" Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 18 Apr 2007 07:58:16.0495 (UTC) FILETIME=[5254E3F0:01C7818F] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0591671412==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0591671412== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070303040807060705030608" This is a cryptographically signed message in MIME format. --------------ms070303040807060705030608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Barrett, David wrote: > So I'm behind the times, but I just became aware that the BEHAVE group, > which is the IETF group dedicated to specifying future NAT behavior, > decided in 8/2005 to recommend that NATs by default implement > "endpoint-dependent" (aka "restricted cone") filtering. Exactly, "filtering", not "mapping" as in the subject. They are very different things and, in fact, RFC 4787 explicitly requires endpoint-independent mapping". > Basically, all decentralized P2P networks would stop working as the > ratio of "accessible" to "inaccessible" nodes trends toward zero. At > that point, basically no DHT can possibly function because nobody can > accept unsolicited incoming connections. Not true. In some DHTs, e.g. CAN, nodes use just a pretty stable set of persistent connections and do not need to receive unsolicited messages. If NATs /behave/, what is needed is just a small set of "unrestricted" peers providing the rendezvous service needed to establish persistent connections between natted peers. -- Ciao, Enrico --------------ms070303040807060705030608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDE4MDc1ODQyWjAjBgkqhkiG9w0BCQQxFgQUz3F/zjfZ Gz/aLXfmTzqfdv0r/ucwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBALVgO2YnSXYfdNEQL9jcUiOtbf0SswaWYW138M1nvH6uCWqZP9u2egTZ LduhfzjZtHSnic4MALiqV+aRvDBmTwPkgzCOwaST2pEqss+VVoGF+PCTYk+9sWUBUuWsFhdL LYZMxIOJ8ovutmLdGDx2rP87Y0fVsFZm/s2jtD6kmOgTHc+Mawx+/3YROy2AIO5pSHgbvPi9 K2M0EWAA7+LkV5l70b2iyXoFBB0kJDXoLLAUADeI04kZech4/SjuCg2MX4/Y3ldOur/ln08O asIZfPABZ5f3t+9d7+S29L2CNw80Gwqa7Tw6txLa/VkaMsFvMUL7r6m4XMkqKBHgQPFVMcIA AAAAAAA= --------------ms070303040807060705030608-- --===============0591671412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0591671412==-- From p2psip-bounces@ietf.org Wed Apr 18 08:18:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He97A-0000eQ-J6; Wed, 18 Apr 2007 08:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He978-0000Wn-Dg for p2psip@ietf.org; Wed, 18 Apr 2007 08:18:22 -0400 Received: from mx3-6.spamtrap.magma.ca ([209.217.78.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He975-0002fD-1I for p2psip@ietf.org; Wed, 18 Apr 2007 08:18:22 -0400 Received: from mail1.magma.ca (mail1.internal.magma.ca [10.0.10.11]) by mx3-6.spamtrap.magma.ca (8.13.0/8.13.1) with ESMTP id l3ICIFcd020773; Wed, 18 Apr 2007 08:18:15 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail1.magma.ca (Magma's Mail Server) with ESMTP id l3ICIEqa008530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 08:18:15 -0400 In-Reply-To: <4625CFB2.4070101@telecomitalia.it> References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <4625CFB2.4070101@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Date: Wed, 18 Apr 2007 08:18:15 -0400 To: "Barrett, David" X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I just want to second what Enrico and Bruce are saying: I believe we can live with NATs and Firewalls that have endpoint-dependent filtering. The basics of the idea for how to deal with these are described in three drafts draft-matthews-p2psip-bootstrap-mechanisms, and draft-matthews-p2psip-dsip-nat-traversal (which Bruce already mentioned) draft-matthews-p2psip-nats-and-overlays The first draft describes how a node that wishes to join a peer-to- peer overlay can establish a connection to ONE peer in the overlay. The second draft describes how the node can then leverage this connection to establish a partial mesh of connections to other peers, and then use this partial mesh to route messages through the overlay. The third draft attempts to explain this idea and compare it with other approaches to NAT Traversal for peer-to-peer networks. There is still more work to do flesh out all the details, but I believe the drafts adequately describe the core of the idea. There was a hot debate in the BEHAVE group on the filtering issue. However, the key fact is that there are many, many NATs today that already implement endpoint-dependent filtering for "security" reasons, and it was felt that many manufacturers would just ignore the recommendation if the document said "NATs MUST have endpoint-independent filtering". - Philip On 18-Apr-07, at 03:58 , Enrico Marocco wrote: > Barrett, David wrote: >> So I'm behind the times, but I just became aware that the BEHAVE >> group, >> which is the IETF group dedicated to specifying future NAT behavior, >> decided in 8/2005 to recommend that NATs by default implement >> "endpoint-dependent" (aka "restricted cone") filtering. > > Exactly, "filtering", not "mapping" as in the subject. They are very > different things and, in fact, RFC 4787 explicitly requires > endpoint-independent mapping". > >> Basically, all decentralized P2P networks would stop working as the >> ratio of "accessible" to "inaccessible" nodes trends toward zero. At >> that point, basically no DHT can possibly function because nobody can >> accept unsolicited incoming connections. > > Not true. In some DHTs, e.g. CAN, nodes use just a pretty stable > set of > persistent connections and do not need to receive unsolicited > messages. > If NATs /behave/, what is needed is just a small set of > "unrestricted" > peers providing the rendezvous service needed to establish persistent > connections between natted peers. > > -- > Ciao, > Enrico > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 18 08:25:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Dp-0003ym-2C; Wed, 18 Apr 2007 08:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Dm-0003ya-Ff for p2psip@ietf.org; Wed, 18 Apr 2007 08:25:14 -0400 Received: from mx4-3.spamtrap.magma.ca ([209.217.78.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9Dl-00067b-4z for p2psip@ietf.org; Wed, 18 Apr 2007 08:25:14 -0400 Received: from mail3.magma.ca (mail3.internal.magma.ca [10.0.10.13]) by mx4-3.spamtrap.magma.ca (8.13.1/8.13.1) with ESMTP id l3ICPAFj002620; Wed, 18 Apr 2007 08:25:10 -0400 Received: from [10.10.80.124] ([216.13.42.68]) (authenticated bits=0) by mail3.magma.ca (Magma's Mail Server) with ESMTP id l3ICP8OL000641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 08:25:09 -0400 In-Reply-To: <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca> References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <4625CFB2.4070101@telecomitalia.it> <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92CC3345-A95F-4EB1-919C-F4D1E74AD5A1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Date: Wed, 18 Apr 2007 08:25:09 -0400 To: David Barrett X-Mailer: Apple Mail (2.752.2) X-magma-MailScanner-Information: Magma Mailscanner Service X-magma-MailScanner: Clean X-Spam-Status: X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I should add that, even though all three drafts have my name in their filenames, that just means that I did the work of writing things down. There was a host of people who worked hard at coming up and fleshing out these ideas: Eric Cooper, Alan Johnston, Bruce Lowekamp, and David Bryan were the main contributors, but others in the IETF also provided inspiration at one time or another. - Philip On 18-Apr-07, at 08:18 , Philip Matthews wrote: > I just want to second what Enrico and Bruce are saying: I believe > we can live with > NATs and Firewalls that have endpoint-dependent filtering. > > The basics of the idea for how to deal with these are described in > three drafts > draft-matthews-p2psip-bootstrap-mechanisms, and > draft-matthews-p2psip-dsip-nat-traversal (which Bruce > already mentioned) > draft-matthews-p2psip-nats-and-overlays > > The first draft describes how a node that wishes to join a peer-to- > peer overlay > can establish a connection to ONE peer in the overlay. > The second draft describes how the node can then leverage this > connection > to establish a partial mesh of connections to other peers, and then > use this > partial mesh to route messages through the overlay. > The third draft attempts to explain this idea and compare it with > other approaches > to NAT Traversal for peer-to-peer networks. > > There is still more work to do flesh out all the details, but I > believe the drafts > adequately describe the core of the idea. > > There was a hot debate in the BEHAVE group on the filtering issue. > However, the key fact is that there are many, many NATs today > that already implement endpoint-dependent filtering for "security" > reasons, > and it was felt that many manufacturers would just ignore the > recommendation > if the document said "NATs MUST have endpoint-independent filtering". > > - Philip > > > > > On 18-Apr-07, at 03:58 , Enrico Marocco wrote: > >> Barrett, David wrote: >>> So I'm behind the times, but I just became aware that the BEHAVE >>> group, >>> which is the IETF group dedicated to specifying future NAT behavior, >>> decided in 8/2005 to recommend that NATs by default implement >>> "endpoint-dependent" (aka "restricted cone") filtering. >> >> Exactly, "filtering", not "mapping" as in the subject. They are very >> different things and, in fact, RFC 4787 explicitly requires >> endpoint-independent mapping". >> >>> Basically, all decentralized P2P networks would stop working as the >>> ratio of "accessible" to "inaccessible" nodes trends toward >>> zero. At >>> that point, basically no DHT can possibly function because nobody >>> can >>> accept unsolicited incoming connections. >> >> Not true. In some DHTs, e.g. CAN, nodes use just a pretty stable >> set of >> persistent connections and do not need to receive unsolicited >> messages. >> If NATs /behave/, what is needed is just a small set of >> "unrestricted" >> peers providing the rendezvous service needed to establish persistent >> connections between natted peers. >> >> -- >> Ciao, >> Enrico >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 18 13:05:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDbN-0003W3-Lx; Wed, 18 Apr 2007 13:05:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDbN-0003Vy-7E for p2psip@ietf.org; Wed, 18 Apr 2007 13:05:53 -0400 Received: from smtp3.akamai.com ([63.116.109.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDbL-0005DF-Rc for p2psip@ietf.org; Wed, 18 Apr 2007 13:05:53 -0400 Received: from smtp3.akamai.com (vwall1.sanmateo.corp.akamai.com [172.23.1.71]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3IH60ng008412 for ; Wed, 18 Apr 2007 10:06:00 -0700 (PDT) Received: from USCA1EX-GATE1.sanmateo.corp.akamai.com (usca1ex-gate1.sanmateo.corp.akamai.com [172.23.1.110]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3IH60BU008409 for ; Wed, 18 Apr 2007 10:06:00 -0700 (PDT) Received: from CAVS1.sanmateo.corp.akamai.com ([172.23.1.125]) by USCA1EX-GATE1.sanmateo.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:09:45 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP]BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Apr 2007 10:00:58 -0700 Message-ID: <38464B16719C77439C06051F392AB9E6062EB2F0@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Thread-Index: AceBW6pZCYVRQCrsQtKRwpN34e7OlgAf3hJe References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> From: "Barrett, David" To: "Barrett, David" , X-OriginalArrivalTime: 18 Apr 2007 17:09:45.0406 (UTC) FILETIME=[5CDC05E0:01C781DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Oops, I should have done my homework better -- it turns out the BEHAVE = group does *not* recommend endpoint-dependent filtering as I earlier = said. (In fact, it makes no recommendation, which is unusual, but at = least less bad.) I apologize for the alarmist post. (Plus, my subject line is wrong -- I meant "filtering", not "mapping". = I long for the good-ole days of just calling it "restricted cone".) -david -----Original Message----- From: Barrett, David [mailto:dbarrett@akamai.com] Sent: Tue 4/17/2007 6:48 PM To: p2psip@ietf.org Subject: [P2PSIP]BEHAVE recommends endpoint-dependent mapping, kills = p2p-sip? =20 So I'm behind the times, but I just became aware that the BEHAVE group, = which is the IETF group dedicated to specifying future NAT behavior, = decided in 8/2005 to recommend that NATs by default implement = "endpoint-dependent" (aka "restricted cone") filtering. If this became = the norm, so far as I understand it, wouldn't P2P-SIP cease to function? Basically, all decentralized P2P networks would stop working as the = ratio of "accessible" to "inaccessible" nodes trends toward zero. At = that point, basically no DHT can possibly function because nobody can = accept unsolicited incoming connections. Indeed, in this world (the world that BEHAVE is trying to create), only = Napster-style, centrally-managed P2P networks can function. In other = words, all DHTs and decentralized overlay networks *will not work* if = BEHAVE succeeds. Is this correct and commonly understood? Should we talk with the BEHAVE = folks about this? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 18 13:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDmx-0000Qp-Qz; Wed, 18 Apr 2007 13:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDmx-0000Qk-7H for p2psip@ietf.org; Wed, 18 Apr 2007 13:17:51 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDmv-0007yb-0Y for p2psip@ietf.org; Wed, 18 Apr 2007 13:17:51 -0400 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 19:17:46 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 19:17:46 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 19:17:45 +0200 Message-ID: <462652D5.6050703@telecomitalia.it> Date: Wed, 18 Apr 2007 19:18:13 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "Barrett, David" Subject: Re: [P2PSIP]BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <38464B16719C77439C06051F392AB9E6062EB2F0@CAVS1.sanmateo.corp.akamai.com> In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2F0@CAVS1.sanmateo.corp.akamai.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 18 Apr 2007 17:17:45.0376 (UTC) FILETIME=[7AF1A200:01C781DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1776094668==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1776094668== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020801040009010308010904" This is a cryptographically signed message in MIME format. --------------ms020801040009010308010904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Barrett, David wrote: > Oops, I should have done my homework better -- it turns out the BEHAVE > group does *not* recommend endpoint-dependent filtering as I earlier > said. (In fact, it makes no recommendation, which is unusual, but at > least less bad.) I apologize for the alarmist post. Actually it recommends both :-( >From RFC 4787: REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. -- Ciao, Enrico --------------ms020801040009010308010904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDE4MTcxODEzWjAjBgkqhkiG9w0BCQQxFgQUxmB0hTAc tb1SN98RvBsEGJaMj+YwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBADuOwq4skA6e6KX/HadEkFRuafO9LHnp/oIG9TDN4zvPXhqFnpZrHdce 3vS1CNUmzY36A6FBsZZsB3jsIBMLw9uMM7+i7echbSaEpWs1VcXXFMML53WekKleRCtbNT/C ID75Q7/vD9epFdIPvvREEVQxN5zfRDAevJUarZ4fUzXg0D0TXtjxr6KEICyjhQJrXCrSJpus LdzJ/aQOZM9piNDGUkS1pOX70ZxWEw8zHN3gkZtw0DCE2c1cWhNRsEHi2vCRECvyIMd9IsH1 fhI2lonxFsiq7Ej9YxpvcGPBKoVzUkRKWBJVfMEWCORQVkqrQTuVCkTN8aSDNUJb/wMsSzMA AAAAAAA= --------------ms020801040009010308010904-- --===============1776094668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1776094668==-- From p2psip-bounces@ietf.org Wed Apr 18 15:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFap-0004Vt-Ub; Wed, 18 Apr 2007 15:13:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFao-0004Vo-Mq for p2psip@ietf.org; Wed, 18 Apr 2007 15:13:26 -0400 Received: from smtp3.akamai.com ([63.116.109.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFan-0002vF-Ap for p2psip@ietf.org; Wed, 18 Apr 2007 15:13:26 -0400 Received: from smtp3.akamai.com (vwall3.sanmateo.corp.akamai.com [172.23.1.73]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3IJDXL0016452 for ; Wed, 18 Apr 2007 12:13:34 -0700 (PDT) Received: from USCA1EX-GATE1.sanmateo.corp.akamai.com (usca1ex-gate1.sanmateo.corp.akamai.com [172.23.1.110]) by smtp3.akamai.com (8.13.8/8.12.10) with ESMTP id l3IJDXrB016443; Wed, 18 Apr 2007 12:13:33 -0700 (PDT) Received: from CAVS1.sanmateo.corp.akamai.com ([172.23.1.125]) by USCA1EX-GATE1.sanmateo.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:17:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2007 12:13:22 -0700 Message-ID: <38464B16719C77439C06051F392AB9E6062EB2F2@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] RE: Endpoint-independent filtering is the way to go. Thread-Index: AceBnZ+mj8AouHweR7C7OlFAf0D7+AASObor References: <38464B16719C77439C06051F392AB9E6062EB2EB@CAVS1.sanmateo.corp.akamai.com> <1176889223.6657.44.camel@sioux.systems.cs.cornell.edu> From: "Barrett, David" To: "Saikat Guha" , X-OriginalArrivalTime: 18 Apr 2007 19:17:18.0187 (UTC) FILETIME=[2E45BBB0:01C781EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [P2PSIP] RE: [BEHAVE] RE: Endpoint-independent filtering is the way to go. X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org True, it's all in degrees. It's just that full-cone allows for greater = decentralization than restricted-cone. For example, this works fine in a full-cone world, but doesn't work at = all in a restricted: 1) My VoIP application uses STUN to find my external IP:port 2) I send you a (password:IP:port) via IM/email/postcard/psychic-link 3) You type it into your VoIP client and call me I agree, there are other VoIP architectures that would work. Just not = this one. And this is the one I want the internet to support. As for the supposed security protections of restricted cone, I'll admit = they're nonzero, but not by much. For example, the only way restricted = cone is at all a security risk is if there's *also* a flaw in the = protocol design:=20 - If the protocol is secure, then full cone is fine. - If the protocol is insecure, then restricted cone is still inadequate. Take the slammer example (where a child is synchronizing with a parent). = The child might be protected by a restricted cone NAT and thus = inaccessible to the slammer worm. But the parent needs to be open to = the world (remember -- the children are NAT'd so the parent doesn't know = the IP:port the child will use ahead of time). Thus restricted cone is = an inadequate defense in this case anyway -- maybe it protects the = limbs, but the head can still be chopped off. In the end, the only = effective security is protocol security. But yes, security also comes in degrees, and restricted cone does offer = *some* degree of protection. But at the cost of eliminating an entire = class of decentralized application design by repealing the end-to-end = nature of the internet? It just seems like the cure is worse than the = disease. -david PS: And this topic isn't limited to just IPv4 NATs. I imagine whatever = precedent we set will have strong influence over the default filtering = properties of non-NAT firewalls, even as we move to IPv6. -----Original Message----- From: Saikat Guha [mailto:saikat@cs.cornell.edu] Sent: Wed 4/18/2007 2:40 AM To: Barrett, David Cc: behave@ietf.org Subject: Re: [BEHAVE] RE: Endpoint-independent filtering is the way to = go. =20 On Tue, 2007-04-17 at 18:55 -0700, Barrett, David wrote: > Is it safe to say that the consensus of the BEHAVE group is the > benefit offered by decentralized overlay networks (eg, DHTs) are > outweighed by the security risks of endpoint-independent mapping? No. You are presupposing the solution -- that in the future no global rendezvous service exists. I would say, there exists at least one way where developers can achieve *BOTH* decentralized networks *AND* secure connections. Global rendezvous service (e.g. a SIP infrastructure much like the DNS infrastructure today) is one such way, there may be others. However, requiring endpoint independent filtering would be to admit defeat / condemn the network by saying that security simply cannot be achieved if decentralized networks is a goal. Obviously, that is wrong. --=20 Saikat _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 19 13:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hea1S-0001XI-Nd; Thu, 19 Apr 2007 13:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hea1S-0001XD-Aa for p2psip@ietf.org; Thu, 19 Apr 2007 13:02:18 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hea1P-0004zE-SP for p2psip@ietf.org; Thu, 19 Apr 2007 13:02:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Apr 2007 10:02:12 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3JH1RD1012666; Thu, 19 Apr 2007 10:01:32 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3JH1w0i004363; Thu, 19 Apr 2007 10:02:02 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 10:01:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Date: Thu, 19 Apr 2007 09:58:52 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F5E4F@namail5.corp.adobe.com> In-Reply-To: <38464B16719C77439C06051F392AB9E6062EB2EF@CAVS1.sanmateo.corp.akamai.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Thread-Index: AceBXdcfievHn5E2TOi3AfuHmEOQZgAAVP9AAFDsevA= References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com><20d2bdfb0704171903v7f4d340g83f8d0be4fa59162@mail.gmail.com> <38464B16719C77439C06051F392AB9E6062EB2EF@CAVS1.sanmateo.corp.akamai.com> From: "Henry Sinnreich" To: "Barrett, David" , "Bruce Lowekamp" X-OriginalArrivalTime: 19 Apr 2007 17:01:56.0033 (UTC) FILETIME=[6F812310:01C782A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David, In addition to what Bruce Lowekamp has mentioned to this trail, I would like to add that the bootstrap peers can also be collocated with STUN/TURN relays so that with ICE, NAT traversal is also always possible. Let's hope however that your comments will be taken into consideration by BEHAVE. >there was a vote, and only one DHT advocate was there, so he was outvoted. >Does P2P-SIP feel that it was fairly represented in this issue? Consensus is the worst design approach IMHO, if it is not backed up by running code and testing of implementations, as used to be the rule in the IETF. Or people who don't have an implementation should have no vote. Period. Beware the flames :-) Thanks, Henry -----Original Message----- From: Barrett, David [mailto:dbarrett@akamai.com]=20 Sent: Tuesday, April 17, 2007 9:26 PM To: Bruce Lowekamp Cc: p2psip@ietf.org Subject: RE: [P2PSIP] BEHAVE recommends endpoint-dependent mapping,kills p2p-sip? Got it, thanks. Basically, use a partial-mesh of long-lived connections such so long as everyone has a connection to somebody, they can always establish a connection to everybody (is that a fair summary?). So that seems like a fine mitigation strategy that will enable DHTs (and other decentralized networks) to live for a few more years. But as the ratio of NAT'd to non-NAT'd increases, and as the ratio of dependent to independent filtering increases, won't even this fail eventually? (Not to mention that if endpoint-dependent filtering becomes the norms for NATs, it'll also become the norm for firewalls, and thus even the non-NAT'd clients become inaccessible -- both IPv4 and IPv6. Imagine for a second if this became the standard for Windows Firewall? Game over.) Fundamentally, the point I'm making is that BEHAVE is actively fighting what P2P-SIP wants: end-to-end accessibility. Even if it's not a bullet to the head in the short term, we're on opposite sides of the issue for the long term. I bring this up because when researching the reasoning behind the BEHAVE decision, it just came down to numbers: there was a vote, and only one DHT advocate was there, so he was outvoted. Does P2P-SIP feel that it was fairly represented in this issue? -david -----Original Message----- From: Bruce Lowekamp [mailto:lowekamp@sipeerior.com] It's not a problem. (well, it makes life a bit harder, but the solutions aren't too bad.) Philip, Eric, David, and I wrote draft-matthews-p2psip-dsip-nat-traversal that describes how to use ICE to open connections between peers behind NATs that have endpoint dependent filtering. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 20 05:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepJe-00087m-EV; Fri, 20 Apr 2007 05:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepJd-00087Z-5G for p2psip@ietf.org; Fri, 20 Apr 2007 05:22:05 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepJb-0003zN-SS for p2psip@ietf.org; Fri, 20 Apr 2007 05:22:05 -0400 Received: by wx-out-0506.google.com with SMTP id h31so955106wxd for ; Fri, 20 Apr 2007 02:22:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=t+AuQp8gWx5M0zg4Bb49mxFPqdBRsyoN15Xmx1UvhyOxtefQiUMNSIzTcqhb3kk/uIORW31xMJQM52WfjHylzHCqJf6CMoUpbwF/9puu0NV5DBz56papwkOG9q44esYM58UCXeRXK6EqcqeCQYFZgjioU4LgIsf98VR/7v5Ntxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=pKm7M+nkv6NoCXTr4Zz6hTKFjacDmoMVlUQ9Lc+/M1w9JDWPuixo0BOLUvntbvCN3FUqLAu3tWg4n1ovdGmC/EZpEePMofHXWmwZ3ekrBZJO56/B0bconJru6Orn2fw+FFb05kGCyVpGBQBUjnhOhLmkPkI8B3G6UNWZlrcZJS0= Received: by 10.115.14.1 with SMTP id r1mr1166570wai.1177060922712; Fri, 20 Apr 2007 02:22:02 -0700 (PDT) Received: by 10.114.159.14 with HTTP; Fri, 20 Apr 2007 02:22:02 -0700 (PDT) Message-ID: <95ab55010704200222y6bd1e3d3w16d0fcb562c48c40@mail.gmail.com> Date: Fri, 20 Apr 2007 17:22:02 +0800 From: "Jing Cao" To: p2psip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [P2PSIP] P2P in mobile phone market X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080242130==" Errors-To: p2psip-bounces@ietf.org --===============2080242130== Content-Type: multipart/alternative; boundary="----=_Part_118650_21664772.1177060922624" ------=_Part_118650_21664772.1177060922624 Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline UmVjZW50IE5va2lhIE45NSBoYXMgYmVlbiBkaXNhYmxlZCBvZiBpdHMgU0lQIGJhc2VkIFZPSVAg Y2FwYWJpbGl0eSBieQpPcmFuZ2UgYW5kIFZvZGFmb25lLCByZWZlciB0bwpodHRwOi8vd3d3LnRo ZXJlZ2lzdGVyLmNvLnVrLzIwMDcvMDQvMTgvbjk1X2NyaXBwbGVkLy4gIEFuIE9yYW5nZSBjdXN0 b21lcgpzZXJ2aWNlcyBhZHZpc29yIGV4cGxhaW5lZDogIldlIEJlbGlldmUgaXQgYWxsb3dzIHlv dSB0byBtYWtlIGNhbGxzIHRoYXQKd29uJ3QgYmUgcm91dGVkIG92ZXIgb3VyIG5ldHdvcmsgYW5k IHRoZXJlZm9yZSBPcmFuZ2UgaGFkIGRlY2lkZWQgbm90IHRvCmluY2x1ZGUgdGhhdCBmdW5jdGlv bmFsaXR5IG9uIG91dCBOOTUiLgoKTXkgcXVlc3Rpb25zIGFyZToKCjEuIElmIFAyUCBpcyBlbmFi bGVkIG92ZXIgbW9iaWxlIGRldmljZXMsIGlzIHRoZXJlIGFueSBjaGFuY2UgdGhhdCB0aGUKb3Bl cmF0b3IgY2FuIGNoYXJnZSB0aGUgY3VzdG9tZXIgZm9yIGhpcy9oZXIgUDJQIGRhdGEgdHJhbnNm ZXI/CgoyLiBGdXJ0aGVyLCBpcyBpdCBwb3NzaWJsZSBmb3IgdGhlIG9wZXJhdG9yIHRvIHV0aWxp emUgdGhlIFAyUCB0ZWNobmlxdWUKaW5zaWRlIHRoZWlyIG93biBuZXR3b3JrPyAgIEN1cnJlbnQg bW9iaWxlIG1hcmtldCBpcyBvcGVyYXRvciBkb21pbmFudCwgdGhleQpjYW4gcHV0IHRoZWlyIHJl dmVudSBjb25jZXJuIGFib3ZlIHRoZSBjdXN0b21lcidzIHJlcXVlc3QuIEJ1dCBJIGd1ZXNzCm9w ZXJhdG9yIGNhbiByZXN0cmljdCB0aGUgbW9iaWxlIGRldmljZSB0byBhY2Nlc3Mgb25seSBvcGVy YXRvcidzIFNJUCBzZXJ2ZXIKYW5kIHRyYW5zZmVyIGRhdGEgb25seSB2aWEgb3BlcmF0b3IncyBu ZXR3b3JrIKGtIElzIHRoaXMgcG9zc2libGU/PwoKCkFueSBkaXNjdXNzaW9uIGFyZSB3ZWxjb21l IEoKCkkgZG8gaG9wZSBQMlAgY2FuIGJlIHVzZWQgaW4gb3VyIG1vYmlsZSBkZXZpY2VzISEK ------=_Part_118650_21664772.1177060922624 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNv LWJpZGktZm9udC1zaXplOiAxMC4wcHQiPlJlY2VudCBOb2tpYSBOOTUgaGFzIGJlZW4gZGlzYWJs ZWQgb2YgaXRzIFNJUCBiYXNlZCBWT0lQIGNhcGFiaWxpdHkgYnkgT3JhbmdlIGFuZCBWb2RhZm9u ZSwgcmVmZXIgdG8gCjxhIGhyZWY9Imh0dHA6Ly93d3cudGhlcmVnaXN0ZXIuY28udWsvMjAwNy8w NC8xOC9uOTVfY3JpcHBsZWQvIj48Zm9udCBjb2xvcj0iIzYwNjQyMCI+aHR0cDovL3d3dy50aGVy ZWdpc3Rlci5jby51ay8yMDA3LzA0LzE4L245NV9jcmlwcGxlZC88L2ZvbnQ+PC9hPi4gPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBB cmlhbCI+CjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9zcGFuPjxzcGFu IGNsYXNzPSJmb3J1bWRlc2NyaXB0aW9udGV4dCI+QW4gT3JhbmdlIGN1c3RvbWVyIHNlcnZpY2Vz IGFkdmlzb3IgZXhwbGFpbmVkOiAmcXVvdDtXZSBCZWxpZXZlIGl0IGFsbG93cyB5b3UgdG8gbWFr ZSBjYWxscyB0aGF0IHdvbid0IGJlIHJvdXRlZCBvdmVyIG91ciBuZXR3b3JrIGFuZCB0aGVyZWZv cmUgT3JhbmdlCiBoYWQgZGVjaWRlZCBub3QgdG8gaW5jbHVkZSB0aGF0IGZ1bmN0aW9uYWxpdHkg b24gb3V0IE45NSIuPC9zcGFuPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0la RTogOXB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij5N eSBxdWVzdGlvbnMgYXJlOiA8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6 IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+MS4g SWYgUDJQIGlzIGVuYWJsZWQgb3ZlciBtb2JpbGUgZGV2aWNlcywgaXMgdGhlcmUgYW55IGNoYW5j ZSB0aGF0IHRoZSBvcGVyYXRvciBjYW4gY2hhcmdlIHRoZSBjdXN0b21lciBmb3IgaGlzL2hlciBQ MlAgZGF0YSB0cmFuc2Zlcj8KPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05U LUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0Ij4yLiBGdXJ0aGVyLCBp cyBpdCBwb3NzaWJsZSBmb3IgdGhlIG9wZXJhdG9yIHRvIHV0aWxpemUgdGhlIFAyUCB0ZWNobmlx dWUgaW5zaWRlIHRoZWlyIG93biBuZXR3b3JrPyZuYnNwOyZuYnNwOwo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZv bnQtc2l6ZTogMTAuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogy87M5TsgbXNvLWZvbnQt a2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPgo8c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOiB5ZXMiPiZuYnNwO0M8L3NwYW4+dXJyZW50IG1vYmlsZSBtYXJrZXQgaXMgb3Bl cmF0b3IgZG9taW5hbnQsJm5ic3A7dGhleSBjYW4gcHV0IHRoZWlyIHJldmVudSBjb25jZXJuIGFi b3ZlIHRoZSBjdXN0b21lciYjMzk7cyByZXF1ZXN0LiBCdXQgSTwvc3Bhbj4mbmJzcDtndWVzcyBv cGVyYXRvciBjYW4gcmVzdHJpY3QgdGhlIG1vYmlsZSBkZXZpY2UgdG8gYWNjZXNzIG9ubHkgb3Bl cmF0b3IncyBTSVAgc2VydmVyIGFuZCB0cmFuc2ZlciBkYXRhIG9ubHkgdmlhIG9wZXJhdG9yJiMz OTtzIG5ldHdvcmsgoa0gSXMgdGhpcyBwb3NzaWJsZT8/Cjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQt c2l6ZTogMTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC9wPgo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkZPTlQt U0laRTogOXB0OyBGT05ULUZBTUlMWTogQXJpYWw7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTAuMHB0 Ij5BbnkgZGlzY3Vzc2lvbiBhcmUgd2VsY29tZSA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IFdpbmdkaW5nczsgbXNvLWJpZGktZm9u dC1zaXplOiAxMC4wcHQ7IG1zby1hc2NpaS1mb250LWZhbWlseTogQXJpYWw7IG1zby1oYW5zaS1m b250LWZhbWlseTogQXJpYWw7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiBBcmlhbDsgbXNvLWNoYXIt dHlwZTogc3ltYm9sOyBtc28tc3ltYm9sLWZvbnQtZmFtaWx5OiBXaW5nZGluZ3MiPgo8c3BhbiBz dHlsZT0ibXNvLWNoYXItdHlwZTogc3ltYm9sOyBtc28tc3ltYm9sLWZvbnQtZmFtaWx5OiBXaW5n ZGluZ3MiPko8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpF OiA5cHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPiA8 L3NwYW4+PC9kaXY+CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFN SUxZOiBBcmlhbDsgbXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjwvc3Bhbj4mbmJzcDs8L2Rp dj4KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFs OyBtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJG T05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IEFyaWFsOyBtc28tYmlkaS1mb250LXNpemU6IDEw LjBwdCI+CkkgZG8gaG9wZSBQMlAgY2FuIGJlIHVzZWQgaW4gb3VyIG1vYmlsZSBkZXZpY2VzISE8 L3NwYW4+PC9zcGFuPjwvZGl2Pgo= ------=_Part_118650_21664772.1177060922624-- --===============2080242130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2080242130==-- From p2psip-bounces@ietf.org Fri Apr 20 06:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepwI-0008Eu-6L; Fri, 20 Apr 2007 06:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepwG-0008Dy-Tm for p2psip@ietf.org; Fri, 20 Apr 2007 06:02:00 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepwG-0004gn-H0 for p2psip@ietf.org; Fri, 20 Apr 2007 06:02:00 -0400 Received: by nz-out-0506.google.com with SMTP id z6so761534nzd for ; Fri, 20 Apr 2007 03:02:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hMIiohohinT2UIFLqhmBTMMB1tRngcBfZljjsrZRxva2Z27QIyE2iyJeJQu4OngVlWsbzaUYUH9Kw856UEMzDCjLhZqz1gBz7SrnIaAYpyUwU37nBnRiZEKV2gi/S9z7Su74WT3jk6CBg0oLywavRJcM2JjFnn5Qi11swy+r1CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sb5CybEzof2NTgrBlh/Ki6KrMLCPHsIiK/xxubmRvAH+0cEAigXdrbuot7VRUKTcanZJ1mAmo20qet8CHfKt6B8rbzU5+pe89pLoVr2ZPLswZ8xhhegxjg5DTQsfJmLY5JS8sHYP3a7qvSGkhlhyIGvrjTBjT44iKlVXHy0gLIw= Received: by 10.114.185.8 with SMTP id i8mr1186770waf.1177063319877; Fri, 20 Apr 2007 03:01:59 -0700 (PDT) Received: by 10.114.112.8 with HTTP; Fri, 20 Apr 2007 03:01:59 -0700 (PDT) Message-ID: <618e24240704200301t1acf1aa0xd26553d5c2119e58@mail.gmail.com> Date: Fri, 20 Apr 2007 12:01:59 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "Jing Cao" Subject: Re: [P2PSIP] P2P in mobile phone market In-Reply-To: <95ab55010704200222y6bd1e3d3w16d0fcb562c48c40@mail.gmail.com> MIME-Version: 1.0 References: <95ab55010704200222y6bd1e3d3w16d0fcb562c48c40@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2070751188==" Errors-To: p2psip-bounces@ietf.org --===============2070751188== Content-Type: multipart/alternative; boundary="----=_Part_117264_3854450.1177063319798" ------=_Part_117264_3854450.1177063319798 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Inline, On 20/04/07, Jing Cao wrote: > > 1. If P2P is enabled over mobile devices, is there any chance that the > operator can charge the customer for his/her P2P data transfer? intelligence remains at end-points, but.. what about if a p2psip device wants to call to pstn? Here, from my point of view, operator role is important. Operator could implement p2psip gateways in order to establish connections to pstn, 3g or other networks. So, 'internal' calls could be performed with no operator action (think as i= n sip calling directly to an IP and not to a sip-id), and 'external' calls ar= e performed using operator infrastructure (p2psip-gwToPstn,p2psip-gwToSip and so on...) 2. Further, is it possible for the operator to utilize the P2P technique > inside their own network? Current mobile market is operator > dominant, they can put their revenu concern above the customer's request. > But I guess operator can restrict the mobile device to access only > operator's SIP server and transfer data only via operator's network =85 I= s > this possible?? > I strongly think it's possible. Telcos could use p2psip as a signaling protocol to implement distributed apps, grid computing, etc... SDP allows it. Imagine a distributed process core network composed by 'n' elements where, using a DHT and information consistency, firmware/configuration/etc updates could be performed element-by-element. You don't need to stop service by maintenanece, you just could stop few elements to update them and still use the 'old-configuration' ones. Now think about most voip service providers, 'internal calls' (from user1@domainprovider1 to user2@domainprovider1) use to be for free, they revenue is based on monthly fees and billing calls to pstn or other networks. So, using p2psip they will reduce significally the use of their resources (internal calls will be perfomed end-to-end directly, with no central proxy neither user locator) and they could implement, as told before, gateways, media conversion systems and so on for other networks interconnection Thank you, --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip:victor.pascual@iptel.org fon user: 223364 ------=_Part_117264_3854450.1177063319798 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Inline,
On 20/04/07, Jing Cao <caojin= gnju@gmail.com> wrote:
1. If P2P is enabled over mobile devices, is there any chance that the operator can charge the customer for his/her P2P data transfer? 
intelligence remains at end-points, but.. what about if a p2psip device wants to call to pstn? Here, from my point of view, operator role is important. Operator could implement p2psip gateways in order to establish connections to pstn, 3g or other networks.
So, 'internal' calls could be performed with no operator action (th= ink as in sip calling directly to an IP and not to a sip-id), and 'external' calls are performed using operator infrastructure (p2psip-gwToPstn,p2psip-gwToSip and so on...)

2. Further, is it possible for the operator to utilize the P2P technique in= side their own network?    Current mobile market is operator dominant, they ca= n put their revenu concern above the customer's request. But I&n= bsp;guess operator can restrict the mobile device to access only operator's SIP server and transfer data only via operator's network =85 Is this possible??

I strongly think it's possible. Telcos could use p2psip as a signaling protocol to implement distributed apps, grid computing, etc... SDP allows it.
Imagine a distributed process core network composed by 'n' elements where, using a DHT and information consistency, firmware/configuration/etc updates could be performed element-by-element. You don't need to stop service by maintenanece, you just could stop few elements to update them and still use the 'old-configuration' ones.

Now think about most voip service providers, 'internal calls' (from user1@domainprovider1 to user2@domainprovider1) use to be for free, they revenue is based on monthly fees and billing calls to pstn or other networks. So, using p2psip they will reduce significally the use of their resources (internal calls will be perfomed end-to-end directly, with no central proxy neither user locator) and they could implement, as told before, gateways, media conversion systems and so on for other networks interconnection

Thank you,
--
Victor Pascual =C1vila

mail:victor.pascual.avila@gmail.com
sip:<= a href=3D"mailto:victor.pascual@iptel.org">victor.pascual@iptel.org
= fon user: 223364 ------=_Part_117264_3854450.1177063319798-- --===============2070751188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2070751188==-- From p2psip-bounces@ietf.org Fri Apr 20 06:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heqak-0004VT-Kd; Fri, 20 Apr 2007 06:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heqaj-0004OU-7v for p2psip@ietf.org; Fri, 20 Apr 2007 06:43:49 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heqah-0000EY-CX for p2psip@ietf.org; Fri, 20 Apr 2007 06:43:49 -0400 Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:43:45 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:43:44 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:43:43 +0200 Message-ID: <4628997D.3030901@telecomitalia.it> Date: Fri, 20 Apr 2007 12:44:13 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Jing Cao Subject: Re: [P2PSIP] P2P in mobile phone market References: <95ab55010704200222y6bd1e3d3w16d0fcb562c48c40@mail.gmail.com> In-Reply-To: <95ab55010704200222y6bd1e3d3w16d0fcb562c48c40@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 20 Apr 2007 10:43:43.0830 (UTC) FILETIME=[C44F7F60:01C78338] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1643902449==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1643902449== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070008040004030204020507" This is a cryptographically signed message in MIME format. --------------ms070008040004030204020507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jing Cao wrote: > My questions are: > > 1. If P2P is enabled over mobile devices, is there any chance that the > operator can charge the customer for his/her P2P data transfer? Yes, of course. They charge for Internet access -- broadband if backed by wi-fi, mobile (slurp!) otherwise. > 2. Further, is it possible for the operator to utilize the P2P technique > inside their own network? Usually operators buy network equipments from vendors. If vendors were able to build less expensive equipments using P2PSIP (e.g. replacing IMS elements with P2P-SBCs), well, operators would immediately buy them. -- Ciao, Enrico --------------ms070008040004030204020507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIwMTA0NDEzWjAjBgkqhkiG9w0BCQQxFgQU0y7owtXi 5sCr1bguZAmkLxDdXDUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAEZfso4PC+e7u3m5F8t5pStm68pagftsN0os4SpwQlYvWqH765iOjK7U jgld84TgmEXLVnDl5B8FazLg85DGi1qQ29kk7OXA4BFez7BiDVU6k8oOXkkb+o9P9vygvYWs Yh7SLb3/BnBeIMqefekcKR/EYxd1meey7FDZHe0/FdMGWjAmUxL8rRkGBLqGcHdm+yhE9FUj BVOoUemOiXRHNm0oH5CdBbh3x0PwwOkCbKZeuXzcTxlZ3+Rd6H9rl9HYo4lLk6mc/Wb0XMf0 7mirXR4+ZsuoqyccAHTNVvQm2Fgl+3yKCTkH0Dq3n5ucwpphSn4PpOH2reo0SaWBZsKzD6cA AAAAAAA= --------------ms070008040004030204020507-- --===============1643902449== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1643902449==-- From p2psip-bounces@ietf.org Fri Apr 20 08:39:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesO9-0004kZ-AZ; Fri, 20 Apr 2007 08:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesO8-0004iN-60 for p2psip@ietf.org; Fri, 20 Apr 2007 08:38:56 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HesO7-00024A-Kz for p2psip@ietf.org; Fri, 20 Apr 2007 08:38:56 -0400 Received: by wr-out-0506.google.com with SMTP id 71so851163wri for ; Fri, 20 Apr 2007 05:38:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=XLkI0cHjRU333khlAZYlHJBvucuUwUFVGiFVRQsFogssj2ZDusXATpWcZc2vDXrOPbYwtMvmJ1HldP2HAe1+FXxaXQnmVYH8/T5EdWuniStOgF5fl57geyXc2s/94oC6H17aQttezh9s0Kg6GhykgcuYIO5s4g9l2hNl5sxzT1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=Jbq8Javs4eSYK1K1Bx8ZCpDg6RA/VCHNC2dM6zwVF52c556WAVAOeXnwEXYqMXgdGe3mb/wMSKkratJ7dLpK5iPHU9jAb+UgMUPe5OFGLKQ9k8yxOoJJ2EKNmVPc3EnjETXjiInvUburR/OD0NgKncOPWYVkblzSFOvvqo33OIM= Received: by 10.114.81.1 with SMTP id e1mr1187957wab.1177072731658; Fri, 20 Apr 2007 05:38:51 -0700 (PDT) Received: from WangYao ( [59.64.186.164]) by mx.google.com with ESMTP id a8sm548316poa.2007.04.20.05.36.03; Fri, 20 Apr 2007 05:38:50 -0700 (PDT) From: "Yao Wang" To: "'Enrico Marocco'" , "'Jing Cao'" Subject: RE: [P2PSIP] P2P in mobile phone market Date: Fri, 20 Apr 2007 20:35:58 +0800 Message-ID: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4628997D.3030901@telecomitalia.it> Thread-Index: AceDONp34+9+1/BkRDeQfqu3sf57mgABgezw X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I don't think only the charge of Internet access is attractive enough = for operators to replace their IMS equipments with P2PSIP devices. Because within the IMS, all sessions, services, and contents can be accounted. Obviously, the amount of these bills is much attractive to operators = than the Internet access fee. In my opinion, for the sake of making P2PSIP successful in the future, business aspects should be considered when its protocols are = standardized. The peer protocol and client protocol to be defined should make it = possible to control sessions and services to some extent and collect some kind of information on user's sessions in P2PSIP. The reasons are as follows. Firstly, accounting and management for P2PSIP will make users' = experience better. Frequent search failures and unreliable services are = unacceptable for end users. To avoid these problems, P2PSIP operators should be able = to collect information on users' activities and their required QoS levels = in order to meet different requirements of each user adjusting network resources. In addition, if charging mechanism is provided, more service providers will be attracted to the P2PSIP field, making services in = P2PSIP become richer. Secondly, management may be mandatory for P2PSIP operators. When P2PSIP = is used for large-scale commercial operation, government or judiciary is = likely to setup rules requesting operators to monitor sessions of users. Thus, = it may be mandatory to control and record users=A1=AF sessions to some = extent. To draw a conclusion, I think management and accounting mechanisms need = to be introduced into P2PSIP. I think my words focus too much on non-technical issues. Apologize in advance if I had gone beyond the task of this WG. :) Sincerely yours,=20 =20 Yao Wang -----Original Message----- From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 Sent: Friday, April 20, 2007 6:44 PM To: Jing Cao Cc: p2psip@ietf.org Subject: Re: [P2PSIP] P2P in mobile phone market Jing Cao wrote: > My questions are: >=20 > 1. If P2P is enabled over mobile devices, is there any chance that the > operator can charge the customer for his/her P2P data transfer? =20 Yes, of course. They charge for Internet access -- broadband if backed by wi-fi, mobile (slurp!) otherwise. > 2. Further, is it possible for the operator to utilize the P2P = technique > inside their own network? Usually operators buy network equipments from vendors. If vendors were able to build less expensive equipments using P2PSIP (e.g. replacing IMS elements with P2P-SBCs), well, operators would immediately buy them. --=20 Ciao, Enrico _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 20 09:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hesn9-00043K-7f; Fri, 20 Apr 2007 09:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hesn8-00043A-IC for p2psip@ietf.org; Fri, 20 Apr 2007 09:04:46 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hesn6-0006B2-N9 for p2psip@ietf.org; Fri, 20 Apr 2007 09:04:46 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:04:36 +0200 Received: from PTPXCH029BA020.idc.cww.telecomitalia.it ([156.54.240.46]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:04:35 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by PTPXCH029BA020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:04:34 +0200 Message-ID: <4628BA81.1020300@telecomitalia.it> Date: Fri, 20 Apr 2007 15:05:05 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Yao Wang Subject: Re: [P2PSIP] P2P in mobile phone market References: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> In-Reply-To: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 20 Apr 2007 13:04:35.0001 (UTC) FILETIME=[7199DA90:01C7834C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1327274808==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1327274808== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070502080504040906030002" This is a cryptographically signed message in MIME format. --------------ms070502080504040906030002 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Yao Wang wrote: > I don't think only the charge of Internet access is attractive enough f= or > operators to replace their IMS equipments with P2PSIP devices. Because > within the IMS, all sessions, services, and contents can be accounted. > Obviously, the amount of these bills is much attractive to operators th= an > the Internet access fee. I 100% agree. If subscribers agree too, it's done and we don't need P2PSIP any more (at least my employer doesn't). > In my opinion, for the sake of making P2PSIP successful in the future, > business aspects should be considered when its protocols are standardiz= ed. > The peer protocol and client protocol to be defined should make it poss= ible > to control sessions and services to some extent and collect some kind o= f > information on user's sessions in P2PSIP. >=20 > The reasons are as follows. >=20 > Firstly, accounting and management for P2PSIP will make users' experien= ce > better. Frequent search failures and unreliable services are unacceptab= le > for end users. To avoid these problems, P2PSIP operators should be able= to > collect information on users' activities and their required QoS levels = in > order to meet different requirements of each user adjusting network > resources. In addition, if charging mechanism is provided, more service= > providers will be attracted to the P2PSIP field, making services in P2P= SIP > become richer. Isn't this exactly what IMS provid^H^H^Hmises? > Secondly, management may be mandatory for P2PSIP operators. When P2PSIP= is > used for large-scale commercial operation, government or judiciary is l= ikely > to setup rules requesting operators to monitor sessions of users. Thus,= it > may be mandatory to control and record users=A1=AF sessions to some ext= ent. As far as I know, in Europe and US, regulation asks the providers to be able to intercept communications when they are _terminated_ on telephony networks. Maybe one day governments will mandate legal interception also for communications both originating and terminating over the Internet, but, once again, they will first have to ban encryption to make it effective. > To draw a conclusion, I think management and accounting mechanisms need= to > be introduced into P2PSIP. >=20 > I think my words focus too much on non-technical issues. Apologize in > advance if I had gone beyond the task of this WG. :) Oh no, really, it's always entertaining to have this kind of discussions = ;-) --=20 Ciao, Enrico --------------ms070502080504040906030002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDIwMTMwNTA1WjAjBgkqhkiG9w0BCQQxFgQUsHRWnafW 3E7exW6saZpRNOjOXB4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBACkMAXsElW/wEIo0dobOG2ELxcSmyiv9jMYjTViuupCSKpz9erb8kEpd /wd7mnWYSNtyv+kexYn7KuUb4S+Lt6SRdv1Vwq8f+2sgWHzzDHWlCxBXSOezBkIrntrEPhoq iC97WASj4htrc2SzGZDHh6yLVnay+O/+Sl8wOWHKBfz2KtwOqgs0//x26zqsRbxfYmFYM46M Vxpt1GPo282i6lBBl0MEngK+dCtWkzkSiKDd1eJ/bK8byWH2yqHhUAhcV1t3exHFzozHz2ty 4d99kTL5WYWRY9EnbelWxQs72yFDAhPqaBa+G4ypmKg8PsyjW8rrtNEkKvzzPbpY3ESBEP4A AAAAAAA= --------------ms070502080504040906030002-- --===============1327274808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1327274808==-- From p2psip-bounces@ietf.org Fri Apr 20 09:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetAC-0005Gh-Sc; Fri, 20 Apr 2007 09:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetAB-0005Eu-QE for p2psip@ietf.org; Fri, 20 Apr 2007 09:28:35 -0400 Received: from wx-out-0506.google.com ([66.249.82.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HetAA-000131-JP for p2psip@ietf.org; Fri, 20 Apr 2007 09:28:35 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1022959wxd for ; Fri, 20 Apr 2007 06:28:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=glmQ9/rAknqA9B4lCmGPNJlttmCGcJPASTMnS+ytVnAW3rvnUsAMS3PydqS/mQot6/1+DGk6Nh3RL9+7raBSgeoHXqblUWAe7iTnBvQwmd5Dbt+8pLNvrIA0bsiw4dEZ4zGPeNWD4cwPMQ2cD1VyshEvbtzm6cdgvRBKQcQI1zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dli27oaWKOZ7Z+anyQ6+tFLSF/2ccx+sYAn3+pC78cB3h5gfwmC4whCpFz9OmHutiVYqNDKz4MvZ4jUQGLZMc1o3sQCjXuo4yrh7xCjS1h4LhyRdD8dVABFu+xf+g+0R88h6ihNpFNmtVUs/h2lcjoz4IZdotyjXNLWpfJLur0o= Received: by 10.70.32.13 with SMTP id f13mr5495836wxf.1177075714242; Fri, 20 Apr 2007 06:28:34 -0700 (PDT) Received: by 10.70.129.2 with HTTP; Fri, 20 Apr 2007 06:28:34 -0700 (PDT) Message-ID: <6a40ca380704200628q2815631ejf94e75fbbfce5e5f@mail.gmail.com> Date: Fri, 20 Apr 2007 16:28:34 +0300 From: "Alex Gakuru" To: "Enrico Marocco" Subject: Re: [P2PSIP] P2P in mobile phone market In-Reply-To: <4628BA81.1020300@telecomitalia.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> <4628BA81.1020300@telecomitalia.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 4/20/07, Enrico Marocco wrote: > > > > I think my words focus too much on non-technical issues. Apologize in > > advance if I had gone beyond the task of this WG. :) > > Oh no, really, it's always entertaining to have this kind of discussions ;-) > Well then, I am courageous enough to make my first-ever post and I hope you find it interesting, thanks "Wireless Net Neutrality: Cellular Carterfone and Consumer Choice in Mobile Broadband" Tim Wu, Professor, Columbia University School of Law February 15, 2007 Alex _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 20 09:41:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetMx-0000c1-U4; Fri, 20 Apr 2007 09:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetMw-0000bt-DI for p2psip@ietf.org; Fri, 20 Apr 2007 09:41:46 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HetMt-00081j-SF for p2psip@ietf.org; Fri, 20 Apr 2007 09:41:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 20 Apr 2007 06:41:39 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3KDfYSd023893; Fri, 20 Apr 2007 06:41:34 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3KDfV0e006116; Fri, 20 Apr 2007 06:41:33 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 06:41:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] P2P in mobile phone market Date: Fri, 20 Apr 2007 06:37:08 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F6072@namail5.corp.adobe.com> In-Reply-To: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P in mobile phone market Thread-Index: AceDONp34+9+1/BkRDeQfqu3sf57mgABgezwAAPJyQA= References: <4628997D.3030901@telecomitalia.it> <003f01c78348$b39f8b50$9f0aa8c0@WangYao> From: "Henry Sinnreich" To: "Yao Wang" X-OriginalArrivalTime: 20 Apr 2007 13:41:31.0060 (UTC) FILETIME=[9A799F40:01C78351] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yao Wang wrote: > Because within the IMS, all sessions, services, and contents can be=20 > accounted. Disappointing experiences have proven to operators that accounting for a call costs more than the call itself. For this reason most telephone services I know of are flat rate. As for mobile phones, the value will migrate from charging per call and duration to charging for mobile IP access where many more lucrative services can be offered, that just voice. Except the racket of charging for roaming, but in many countries, the regulator has stepped in to limit the roaming charge abuses. On the Internet mobility is a native property. Also, in our time when high quality wideband voice and video is free from PC to PC (or SIP/Skype phone to SIP/Skype phone), the business model of charging for usage may no longer be valid. Telephony will IMHO end up in many cases to be a free add-on to other services, for example allowing buyers and sellers to talk and see each other when conducting a commercial transaction, say at an auction house.=20 > their required QoS levels in order to meet different requirements of each > user adjusting network resources QoS has developed mostly into a DOS attack on the IP flows from competitors and it makes no sense for sure for VoIP where only the cut-outs matter (as in your digital cell phone) and practically nothing else. Such cut-outs are due to congestion and are best monitored in the IP routers. > government or judiciary is likely > to setup rules requesting operators to monitor sessions of users. There are so many types of sessions possible that monitoring every application by itself does not make sense any more. The IP flows can however be monitored at the IP level.=20 Thanks, Henry -----Original Message----- From: Yao Wang [mailto:yaowang.bupt@gmail.com]=20 Sent: Friday, April 20, 2007 7:36 AM To: 'Enrico Marocco'; 'Jing Cao' Cc: p2psip@ietf.org Subject: RE: [P2PSIP] P2P in mobile phone market I don't think only the charge of Internet access is attractive enough for operators to replace their IMS equipments with P2PSIP devices. Because within the IMS, all sessions, services, and contents can be accounted. Obviously, the amount of these bills is much attractive to operators than the Internet access fee. In my opinion, for the sake of making P2PSIP successful in the future, business aspects should be considered when its protocols are standardized. The peer protocol and client protocol to be defined should make it possible to control sessions and services to some extent and collect some kind of information on user's sessions in P2PSIP. The reasons are as follows. Firstly, accounting and management for P2PSIP will make users' experience better. Frequent search failures and unreliable services are unacceptable for end users. To avoid these problems, P2PSIP operators should be able to collect information on users' activities and their required QoS levels in order to meet different requirements of each user adjusting network resources. In addition, if charging mechanism is provided, more service providers will be attracted to the P2PSIP field, making services in P2PSIP become richer. Secondly, management may be mandatory for P2PSIP operators. When P2PSIP is used for large-scale commercial operation, government or judiciary is likely to setup rules requesting operators to monitor sessions of users. Thus, it may be mandatory to control and record users' sessions to some extent. To draw a conclusion, I think management and accounting mechanisms need to be introduced into P2PSIP. I think my words focus too much on non-technical issues. Apologize in advance if I had gone beyond the task of this WG. :) Sincerely yours,=20 =20 Yao Wang -----Original Message----- From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 Sent: Friday, April 20, 2007 6:44 PM To: Jing Cao Cc: p2psip@ietf.org Subject: Re: [P2PSIP] P2P in mobile phone market Jing Cao wrote: > My questions are: >=20 > 1. If P2P is enabled over mobile devices, is there any chance that the > operator can charge the customer for his/her P2P data transfer? =20 Yes, of course. They charge for Internet access -- broadband if backed by wi-fi, mobile (slurp!) otherwise. > 2. Further, is it possible for the operator to utilize the P2P technique > inside their own network? Usually operators buy network equipments from vendors. If vendors were able to build less expensive equipments using P2PSIP (e.g. replacing IMS elements with P2P-SBCs), well, operators would immediately buy them. --=20 Ciao, Enrico _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 20 09:57:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hetbk-0002fK-Qv; Fri, 20 Apr 2007 09:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hetbj-0002fD-B0 for p2psip@ietf.org; Fri, 20 Apr 2007 09:57:03 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hetbh-0008OD-KR for p2psip@ietf.org; Fri, 20 Apr 2007 09:57:03 -0400 Received: from source ([192.150.11.134]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 20 Apr 2007 06:56:48 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3KDuBD1005280; Fri, 20 Apr 2007 06:56:12 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3KDuc0q007782; Fri, 20 Apr 2007 06:56:46 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 06:56:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] P2P in mobile phone market Date: Fri, 20 Apr 2007 06:56:35 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F6074@namail5.corp.adobe.com> In-Reply-To: <618e24240704200301t1acf1aa0xd26553d5c2119e58@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P in mobile phone market Thread-Index: AceDMvvGJgaFutRPTW+baTt3SjGslwAHmC5A References: <95ab55010704200222y6bd1e3d3w16d0fcb562c48c40@mail.gmail.com> <618e24240704200301t1acf1aa0xd26553d5c2119e58@mail.gmail.com> From: "Henry Sinnreich" To: =?iso-8859-1?Q?Victor_Pascual_=C1vila?= , "Jing Cao" X-OriginalArrivalTime: 20 Apr 2007 13:56:35.0302 (UTC) FILETIME=[B5720060:01C78353] X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979763475==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1979763475== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78353.B55A7D48" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78353.B55A7D48 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable * Telcos could use p2psip as a signaling protocol to implement = distributed apps, grid computing, etc... =20 Yes, this very true and also easy to implement by operators. In one = scenario for example all they have to do is to place the peer software = into residential and enterprise access routers. =20 Thanks, Henry =20 ________________________________ From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com]=20 Sent: Friday, April 20, 2007 5:02 AM To: Jing Cao Cc: p2psip@ietf.org Subject: Re: [P2PSIP] P2P in mobile phone market =20 Inline, On 20/04/07, Jing Cao wrote: 1. If P2P is enabled over mobile devices, is there any chance that the = operator can charge the customer for his/her P2P data transfer?=20 intelligence remains at end-points, but.. what about if a p2psip device = wants to call to pstn? Here, from my point of view, operator role is = important. Operator could implement p2psip gateways in order to = establish connections to pstn, 3g or other networks. So, 'internal' calls could be performed with no operator action (think = as in sip calling directly to an IP and not to a sip-id), and 'external' = calls are performed using operator infrastructure = (p2psip-gwToPstn,p2psip-gwToSip and so on...) 2. Further, is it possible for the operator to utilize the P2P = technique inside their own network? Current mobile market is operator = dominant, they can put their revenu concern above the customer's = request. But I guess operator can restrict the mobile device to access = only operator's SIP server and transfer data only via operator's network = ... Is this possible?? I strongly think it's possible. Telcos could use p2psip as a signaling = protocol to implement distributed apps, grid computing, etc... SDP = allows it. Imagine a distributed process core network composed by 'n' elements = where, using a DHT and information consistency, = firmware/configuration/etc updates could be performed = element-by-element. You don't need to stop service by maintenanece, you = just could stop few elements to update them and still use the = 'old-configuration' ones. Now think about most voip service providers, 'internal calls' (from = user1@domainprovider1 to user2@domainprovider1) use to be for free, they = revenue is based on monthly fees and billing calls to pstn or other = networks. So, using p2psip they will reduce significally the use of = their resources (internal calls will be perfomed end-to-end directly, = with no central proxy neither user locator) and they could implement, as = told before, gateways, media conversion systems and so on for other = networks interconnection Thank you,=20 --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip:victor.pascual@iptel.org fon user: 223364=20 ------_=_NextPart_001_01C78353.B55A7D48 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8       Telcos could use p2psip as = a signaling protocol to implement distributed apps, grid computing, = etc...

 

Yes, this very true and also easy to implement by operators. In = one scenario for example all they have to do is to place the peer software = into residential and enterprise access routers.

 

Thanks, Henry

 

From: = Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com]
Sent: Friday, April 20, = 2007 5:02 AM
To: Jing Cao
Cc: = p2psip@ietf.org
Subject: Re: [P2PSIP] P2P = in mobile phone market

 

Inline,

On 20/04/07, Jing Cao <caojingnju@gmail.com> wrote:

1. If P2P is enabled over mobile devices, is there = any chance that the operator can charge the customer for his/her P2P data = transfer? 

intelligence = remains at end-points, but.. what about if a p2psip device wants to call to pstn? = Here, from my point of view, operator role is important. Operator could = implement p2psip gateways in order to establish connections to pstn, 3g or other networks.
So, 'internal' calls could be performed with no operator action (think = as in sip calling directly to an IP and not to a sip-id), and 'external' calls = are performed using operator infrastructure (p2psip-gwToPstn,p2psip-gwToSip = and so on...)

2. Further, is it possible = for the operator to utilize the P2P technique inside their own = network?    Current mobile market is operator dominant, they can put = their revenu concern above the customer's request. But I guess operator = can restrict the mobile device to access only operator's SIP server and = transfer data only via operator's network … Is this = possible??

I strongly think it's possible. Telcos could use p2psip as a = signaling protocol to implement distributed apps, grid computing, etc... SDP = allows it.
Imagine a distributed process core network composed by 'n' elements = where, using a DHT and information consistency, firmware/configuration/etc = updates could be performed element-by-element. You don't need to stop service by maintenanece, you just could stop few elements to update them and still = use the 'old-configuration' ones.

Now think about most voip service providers, 'internal calls' (from user1@domainprovider1 to user2@domainprovider1) use to be for free, they revenue is based on monthly fees and billing calls to pstn or other = networks. So, using p2psip they will reduce significally the use of their = resources (internal calls will be perfomed end-to-end directly, with no central = proxy neither user locator) and they could implement, as told before, = gateways, media conversion systems and so on for other networks interconnection

Thank you,
--
Victor Pascual =C1vila

mail:victor.pascual.avila@gmail= .com
sip:victor.pascual@iptel.org
= fon user: 223364

------_=_NextPart_001_01C78353.B55A7D48-- --===============1979763475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1979763475==-- From p2psip-bounces@ietf.org Fri Apr 20 10:15:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HettY-0007pc-EM; Fri, 20 Apr 2007 10:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HettW-0007pM-P5 for p2psip@ietf.org; Fri, 20 Apr 2007 10:15:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HettV-0004nc-D9 for p2psip@ietf.org; Fri, 20 Apr 2007 10:15:26 -0400 Received: by ug-out-1314.google.com with SMTP id 72so753698ugd for ; Fri, 20 Apr 2007 07:15:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OH91xUZSDVgmfP/1rauHsspmWxL6RYX4A5G78JyLryAbJ0hb4KLKkoBuQ77oT2b31LZsiCNtuG1wDA3mif90WRskEV63pGiFSHS5Yab6y+k+GXuA5VKSQ+PBrcsL16fbSjOFzCnwfl4cqJtlU4BLW0XeShMVovEpS2PC40sijHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=R9ycX/rNDFb34fMYIOK1Hxu9n/y2C50EGdU+H8x4MH98iC7vxDg3px7DgcsxWs7g/PO83P/tg87uCwMNUkDglYMoB/1QW/TQVxKHYFSJVY3+/BVCtgzd6jSM0bKyZgDyboEUzgDLfbPPZoLV8OQ+5lCfndNSpeByYl1KAX2V2lc= Received: by 10.82.113.6 with SMTP id l6mr4737666buc.1177078524421; Fri, 20 Apr 2007 07:15:24 -0700 (PDT) Received: by 10.82.126.13 with HTTP; Fri, 20 Apr 2007 07:15:24 -0700 (PDT) Message-ID: <4d4304a00704200715g14625afcm63b246e77cc00a50@mail.gmail.com> Date: Fri, 20 Apr 2007 10:15:24 -0400 From: "David A. Bryan" To: "Enrico Marocco" Subject: Re: [P2PSIP] P2P in mobile phone market In-Reply-To: <4628BA81.1020300@telecomitalia.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> <4628BA81.1020300@telecomitalia.it> X-Google-Sender-Auth: 36b7acacf6c6ef56 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org In many countries the current rules require intercept of PSTN only, but several (including the US) have made it clear that all calls (even IP to IP) will eventually need to be interceptable (if that is a real word...). David On 4/20/07, Enrico Marocco wrote: > Yao Wang wrote: > > I don't think only the charge of Internet access is attractive enough for > > operators to replace their IMS equipments with P2PSIP devices. Because > > within the IMS, all sessions, services, and contents can be accounted. > > Obviously, the amount of these bills is much attractive to operators than > > the Internet access fee. > > I 100% agree. If subscribers agree too, it's done and we don't need > P2PSIP any more (at least my employer doesn't). > > > In my opinion, for the sake of making P2PSIP successful in the future, > > business aspects should be considered when its protocols are standardized. > > The peer protocol and client protocol to be defined should make it possible > > to control sessions and services to some extent and collect some kind of > > information on user's sessions in P2PSIP. > > > > The reasons are as follows. > > > > Firstly, accounting and management for P2PSIP will make users' experience > > better. Frequent search failures and unreliable services are unacceptable > > for end users. To avoid these problems, P2PSIP operators should be able to > > collect information on users' activities and their required QoS levels in > > order to meet different requirements of each user adjusting network > > resources. In addition, if charging mechanism is provided, more service > > providers will be attracted to the P2PSIP field, making services in P2PSIP > > become richer. > > Isn't this exactly what IMS provid^H^H^Hmises? > > > Secondly, management may be mandatory for P2PSIP operators. When P2PSIP is > > used for large-scale commercial operation, government or judiciary is likely > > to setup rules requesting operators to monitor sessions of users. Thus, it > > may be mandatory to control and record users' sessions to some extent. > > As far as I know, in Europe and US, regulation asks the providers to be > able to intercept communications when they are _terminated_ on telephony > networks. Maybe one day governments will mandate legal interception > also for communications both originating and terminating over the > Internet, but, once again, they will first have to ban encryption to > make it effective. > > > To draw a conclusion, I think management and accounting mechanisms need to > > be introduced into P2PSIP. > > > > I think my words focus too much on non-technical issues. Apologize in > > advance if I had gone beyond the task of this WG. :) > > Oh no, really, it's always entertaining to have this kind of discussions ;-) > > -- > Ciao, > Enrico > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 20 17:28:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0eQ-0003td-TM; Fri, 20 Apr 2007 17:28:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0eP-0003tS-AG for p2psip@ietf.org; Fri, 20 Apr 2007 17:28:17 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0eO-0003ZL-3e for p2psip@ietf.org; Fri, 20 Apr 2007 17:28:17 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGT00KKDFN3D4@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 20 Apr 2007 14:28:15 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGT00FO1FN1AL@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 20 Apr 2007 14:28:15 -0700 (PDT) Date: Fri, 20 Apr 2007 16:26:53 -0500 From: Spencer Dawkins To: P2PSIP Mailing List Message-id: <1e2101c78392$9dca8e70$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [P2PSIP] Next steps on draft-willis-p2psip-concepts-04 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear P2PSIP Concepts and Terminology draft authors, I'm looking at draft-willis-p2psip-concepts-04 and seeing 9. Open Issues Here are some open issues in this document: 1. The word "service" is being overloaded to refer both to what the overlay provides (distributed location service, distributed transport service) and what an individual peer or client provides. How can we fix this? 2. Does P2PSIP provide a distributed location service or an alternative mechanism to RFC 3263? The answer seems to be both, but what is the relationship between these? Does this look like your current open issues list, post-Prague? I'm almost sure we have an open issue about clients, for instance... How do you/we plan to move forward on this draft? Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Apr 21 08:53:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfF5Q-0002FF-Ge; Sat, 21 Apr 2007 08:53:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfF5O-0002DM-In for p2psip@ietf.org; Sat, 21 Apr 2007 08:53:06 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfF5N-0004xt-7i for p2psip@ietf.org; Sat, 21 Apr 2007 08:53:06 -0400 Received: by ug-out-1314.google.com with SMTP id 72so907048ugd for ; Sat, 21 Apr 2007 05:53:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uJUXwPGp7Jq0r4E8n3OwXJzOIv7Nah3o+avFR5LcYI+SV9Ez8VPy9VDUBmb1aYvOsI3V2SQzr/8Jw7cZHyZzVa5EQ+W2K97eaJkav3rUBsjAOmJ86SPI6oK/YF/J7FyY6924gpAAjmCAL/+DnxARo1VfwnDo55Nt68WedQIUMDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lm4Qhwl9W1NN4U4R+WpnIBiM3Stmr//6CSTF/B4+XaR0mpiUs8N0uKxpW7ej5S6AV/MRJgGpvHik+w5qEVHd+9riMv/x1I3a/OMGBoiYo6TQs5ajUDYrSNov9/te3ajGTUPnhbLp+NW4/izXbZmyGJ+d5xfAkBTF59u7yf2nrlM= Received: by 10.67.76.16 with SMTP id d16mr3571955ugl.1177159984383; Sat, 21 Apr 2007 05:53:04 -0700 (PDT) Received: by 10.67.55.6 with HTTP; Sat, 21 Apr 2007 05:53:04 -0700 (PDT) Message-ID: <7b683f3f0704210553j2063166eo75514bcdd3533c43@mail.gmail.com> Date: Sat, 21 Apr 2007 08:53:04 -0400 From: "Eunsoo Shim" To: "Spencer Dawkins" Subject: Re: [P2PSIP] Next steps on draft-willis-p2psip-concepts-04 In-Reply-To: <1e2101c78392$9dca8e70$ad600240@china.huawei.com> MIME-Version: 1.0 References: <1e2101c78392$9dca8e70$ad600240@china.huawei.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167558696==" Errors-To: p2psip-bounces@ietf.org --===============1167558696== Content-Type: multipart/alternative; boundary="----=_Part_45845_11721961.1177159984294" ------=_Part_45845_11721961.1177159984294 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The authors and the chairs are discussing about designating one person as the editor of the draft. Once the editor is designated, I think the authors and the editor are going to work on those issues. On 4/20/07, Spencer Dawkins wrote: > > Dear P2PSIP Concepts and Terminology draft authors, > > I'm looking at draft-willis-p2psip-concepts-04 and seeing > > 9. Open Issues > > Here are some open issues in this document: > > 1. The word "service" is being overloaded to refer both to what the > overlay provides (distributed location service, distributed > transport service) and what an individual peer or client > provides. How can we fix this? > > 2. Does P2PSIP provide a distributed location service or an > alternative mechanism to RFC 3263? The answer seems to be both, > but what is the relationship between these? The function described in RFC3263 is a subset of the distributed location service, I believe. Does this look like your current open issues list, post-Prague? I'm almost > sure we have an open issue about clients, for instance... > > How do you/we plan to move forward on this draft? > > Thanks. Eunsoo ------=_Part_45845_11721961.1177159984294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline The authors and the chairs are discussing about designating one person as the editor of the draft. Once the editor is designated, I think the authors and the editor are going to work on those issues.

On 4/20/07, Spencer Dawkins <spencer@mcsr-labs.org> wrote:
Dear P2PSIP Concepts and Terminology draft authors,

I'm looking at draft-willis-p2psip-concepts-04 and seeing

9.  Open Issues

   Here are some open issues in this document:

   1.  The word "service" is being overloaded to refer both to what the
       overlay provides (distributed location service, distributed
       transport service) and what an individual peer or client
       provides.  How can we fix this?

   2.  Does P2PSIP provide a distributed location service or an
       alternative mechanism to RFC 3263?  The answer seems to be both,
       but what is the relationship between these?

The function described in RFC3263 is a subset of the distributed location service, I believe.

Does this look like your current open issues list, post-Prague? I'm almost
sure we have an open issue about clients, for instance...

How do you/we plan to move forward on this draft?


Thanks.

Eunsoo
------=_Part_45845_11721961.1177159984294-- --===============1167558696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1167558696==-- From p2psip-bounces@ietf.org Mon Apr 23 00:06:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpon-0007pc-2f; Mon, 23 Apr 2007 00:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpom-0007mt-Iv for p2psip@ietf.org; Mon, 23 Apr 2007 00:06:24 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfpol-0006IN-77 for p2psip@ietf.org; Mon, 23 Apr 2007 00:06:24 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Apr 2007 21:06:23 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="480558720:sNHT51348300" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3N46MGU016551; Sun, 22 Apr 2007 21:06:22 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l3N46KZU000722; Mon, 23 Apr 2007 04:06:20 GMT In-Reply-To: <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca> References: <38464B16719C77439C06051F392AB9E6062EB2EA@CAVS1.sanmateo.corp.akamai.com> <4625CFB2.4070101@telecomitalia.it> <9EE3D40D-B562-4A61-922D-5801ABB8E08E@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41BCFFB7-5876-4F44-8705-DB82A4AD80AE@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] BEHAVE recommends endpoint-dependent mapping, kills p2p-sip? Date: Sun, 22 Apr 2007 21:05:48 -0700 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3210; t=1177301182; x=1178165182; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=09BEHAVE=20recommends=20endpoint-dependent=2 0mapping,=20kills=20p2p-sip? |Sender:=20; bh=RELRLJIvgMPbCWNyQlkcThYkGiQT4CqLY+W2vH4eEFw=; b=V4fq0YIAi9lCBT0guwYG0jzgBdTc1JW8p8yiwI6eormzKNQYWNWX7pQni1nvT3a49mb2UYKt oJs4io6vk3SJjJ7kg7R+I2U5AJlC85DUyEmYQYdC6RGvzTFf4GSo9pmZ; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: P2PSIP WG , "Barrett, David" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Philip. And I think we have plenty of examples that show what he is saying is true. Cullen On Apr 18, 2007, at 5:18 AM, Philip Matthews wrote: > I just want to second what Enrico and Bruce are saying: I believe > we can live with > NATs and Firewalls that have endpoint-dependent filtering. > > The basics of the idea for how to deal with these are described in > three drafts > draft-matthews-p2psip-bootstrap-mechanisms, and > draft-matthews-p2psip-dsip-nat-traversal (which Bruce > already mentioned) > draft-matthews-p2psip-nats-and-overlays > > The first draft describes how a node that wishes to join a peer-to- > peer overlay > can establish a connection to ONE peer in the overlay. > The second draft describes how the node can then leverage this > connection > to establish a partial mesh of connections to other peers, and then > use this > partial mesh to route messages through the overlay. > The third draft attempts to explain this idea and compare it with > other approaches > to NAT Traversal for peer-to-peer networks. > > There is still more work to do flesh out all the details, but I > believe the drafts > adequately describe the core of the idea. > > There was a hot debate in the BEHAVE group on the filtering issue. > However, the key fact is that there are many, many NATs today > that already implement endpoint-dependent filtering for "security" > reasons, > and it was felt that many manufacturers would just ignore the > recommendation > if the document said "NATs MUST have endpoint-independent filtering". > > - Philip > > > > > On 18-Apr-07, at 03:58 , Enrico Marocco wrote: > >> Barrett, David wrote: >>> So I'm behind the times, but I just became aware that the BEHAVE >>> group, >>> which is the IETF group dedicated to specifying future NAT behavior, >>> decided in 8/2005 to recommend that NATs by default implement >>> "endpoint-dependent" (aka "restricted cone") filtering. >> >> Exactly, "filtering", not "mapping" as in the subject. They are very >> different things and, in fact, RFC 4787 explicitly requires >> endpoint-independent mapping". >> >>> Basically, all decentralized P2P networks would stop working as the >>> ratio of "accessible" to "inaccessible" nodes trends toward >>> zero. At >>> that point, basically no DHT can possibly function because nobody >>> can >>> accept unsolicited incoming connections. >> >> Not true. In some DHTs, e.g. CAN, nodes use just a pretty stable >> set of >> persistent connections and do not need to receive unsolicited >> messages. >> If NATs /behave/, what is needed is just a small set of >> "unrestricted" >> peers providing the rendezvous service needed to establish persistent >> connections between natted peers. >> >> -- >> Ciao, >> Enrico >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 23 00:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqGp-00061d-VU; Mon, 23 Apr 2007 00:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqGo-0005wl-Vo for p2psip@ietf.org; Mon, 23 Apr 2007 00:35:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfqGn-0003QI-MO for p2psip@ietf.org; Mon, 23 Apr 2007 00:35:22 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2007 21:35:22 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="414437346:sNHT47117938" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l3N4ZLgX015228; Sun, 22 Apr 2007 21:35:21 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l3N4ZJZU021171; Mon, 23 Apr 2007 04:35:19 GMT In-Reply-To: <811D385AE1CEBB42839C50DF0B0D38E003D35A47@sernt4.essex.ac.uk> References: <811D385AE1CEBB42839C50DF0B0D38E003D35A47@sernt4.essex.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Presence in P2P-SIP Date: Sun, 22 Apr 2007 21:34:46 -0700 To: "Oredope, Adetola" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=890; t=1177302921; x=1178166921; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Presence=20in=20P2P-SIP |Sender:=20; bh=yroT3X/1B5ynq9HTfwgfTrWGT5ENaI5DzAj+1bBtiLY=; b=Sbnmr+0paEaG4Oys/bfVjkJhj8xP7HF1UuRt7MX47Clk/4GRJax4HYuJCuO6yHyC2k/Dqe4w njYEUrXZIcQYfW5v5sX7qZbsg4bbnvVcxCiotwDhSHO1evZHuXv43DK8; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I've been told about implementations where there is no presence server but instead pair wise subscriptions. Assume that for everyone on your buddy list you are on their buddy list. Then when you come on- line, you subscribe to everyone on your buddy list by sending them a subscribe directly over the P2P mesh just like you would send them an INVITE. When your buddies see you subscribe to them, they subscribe to you. It's less than perfect but it works pretty well. On Apr 13, 2007, at 3:43 AM, Oredope, Adetola wrote: > Hello, > > Do any one know of where I can find any information on Presence > services > using P2P-SIP (SIMPLE)? > Is there any one out there working on this? > > Regards, > > Tola > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 23 11:29:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0To-0001B3-IP; Mon, 23 Apr 2007 11:29:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0Tm-0001Ax-OI for p2psip@ietf.org; Mon, 23 Apr 2007 11:29:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0Tl-0002dV-Ex for p2psip@ietf.org; Mon, 23 Apr 2007 11:29:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg0SM-0007Qn-3n; Mon, 23 Apr 2007 10:27:58 -0500 From: "Brian Rosen" To: "'Eunsoo Shim'" , "'Spencer Dawkins'" Subject: RE: [P2PSIP] Next steps on draft-willis-p2psip-concepts-04 Date: Mon, 23 Apr 2007 11:29:20 -0400 Message-ID: <04ba01c785bc$2b5dec70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7b683f3f0704210553j2063166eo75514bcdd3533c43@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceEE+aDROhyZy+mTgu8m5HN6eTonwBqCCuQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org But don=92t let that stop you from sending text (to the list preferably, = or to the authors). Brian ________________________________________ From: Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: Saturday, April 21, 2007 8:53 AM To: Spencer Dawkins Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Next steps on draft-willis-p2psip-concepts-04 The authors and the chairs are discussing about designating one person = as the editor of the draft. Once the editor is designated, I think the = authors and the editor are going to work on those issues. On 4/20/07, Spencer Dawkins wrote: Dear P2PSIP Concepts and Terminology draft authors, I'm looking at draft-willis-p2psip-concepts-04 and seeing 9.=A0=A0Open Issues =A0=A0 Here are some open issues in this document: =A0=A0 1.=A0=A0The word "service" is being overloaded to refer both to = what the=20 =A0=A0=A0=A0=A0=A0 overlay provides (distributed location service, = distributed =A0=A0=A0=A0=A0=A0 transport service) and what an individual peer or = client =A0=A0=A0=A0=A0=A0 provides.=A0=A0How can we fix this? =A0=A0 2.=A0=A0Does P2PSIP provide a distributed location service or an=20 =A0=A0=A0=A0=A0=A0 alternative mechanism to RFC 3263?=A0=A0The answer = seems to be both, =A0=A0=A0=A0=A0=A0 but what is the relationship between these? The function described in RFC3263 is a subset of the distributed = location service, I believe.=20 Does this look like your current open issues list, post-Prague? I'm = almost=20 sure we have an open issue about clients, for instance... How do you/we plan to move forward on this draft? Thanks. Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 23 13:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1uP-0004xS-Qm; Mon, 23 Apr 2007 13:01:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1SS-0001C1-Ll for p2psip@ietf.org; Mon, 23 Apr 2007 12:32:08 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hg1SS-0007h9-FP for p2psip@ietf.org; Mon, 23 Apr 2007 12:32:08 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id 637542AD41 for ; Mon, 23 Apr 2007 16:31:38 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 12:31:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Apr 2007 12:31:32 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A020964E4@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Editorship for the Concepts Document Thread-Index: AceFxNo94/U1sLnLT86+03Fgw25RCg== From: "Rosen, Brian" To: "P2PSIP Mailing List" X-OriginalArrivalTime: 23 Apr 2007 16:31:38.0151 (UTC) FILETIME=[DD9D5B70:01C785C4] X-Spam-Score: -2.8 (--) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-Mailman-Approved-At: Mon, 23 Apr 2007 13:01:00 -0400 Subject: [P2PSIP] Editorship for the Concepts Document X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip Matthews and Dean Willis will be co-editors of the -concepts document, which is a work group item. The author list remains the same. Please send comments on the draft, or suggested text to the list. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 23 14:51:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3dP-0003gz-Nl; Mon, 23 Apr 2007 14:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3dO-0003gu-Sh for p2psip@ietf.org; Mon, 23 Apr 2007 14:51:34 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3dN-0005DK-IT for p2psip@ietf.org; Mon, 23 Apr 2007 14:51:34 -0400 Received: from [64.101.172.87] ([64.101.172.87]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3NHwO7b004507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Apr 2007 12:58:25 -0500 In-Reply-To: <1e2101c78392$9dca8e70$ad600240@china.huawei.com> References: <1e2101c78392$9dca8e70$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <504CF0A1-759A-4404-B922-7EF7EEFCD101@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Next steps on draft-willis-p2psip-concepts-04 Date: Mon, 23 Apr 2007 13:51:22 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 20, 2007, at 4:26 PM, Spencer Dawkins wrote: > Dear P2PSIP Concepts and Terminology draft authors, > > I'm looking at draft-willis-p2psip-concepts-04 and seeing > > 9. Open Issues > > Here are some open issues in this document: > > 1. The word "service" is being overloaded to refer both to what the > overlay provides (distributed location service, distributed > transport service) and what an individual peer or client > provides. How can we fix this? I can give it a try -- will be looking at the next round of editing. > > 2. Does P2PSIP provide a distributed location service or an > alternative mechanism to RFC 3263? The answer seems to be both, > but what is the relationship between these? > The distributed location service is an alternative to RFC 3263. > Does this look like your current open issues list, post-Prague? I'm > almost sure we have an open issue about clients, for instance... > Good question. Top of my to-do list (after figuring out how to feed myself and pay my creditors) is assembling he list of things I want to tackle in the next rev. > How do you/we plan to move forward on this draft? I'll take the token for the next editing pass. It has been suggested that we do something like a wiki or issue tracker for capturing and tracking open issues. I'm planning an OS upgrade on the softarmor site, so I might roll in wiki support when I do that. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 23 15:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg42W-0004ln-DH; Mon, 23 Apr 2007 15:17:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg42V-0004li-Jl for p2psip@ietf.org; Mon, 23 Apr 2007 15:17:31 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg42V-0004Ux-2J for p2psip@ietf.org; Mon, 23 Apr 2007 15:17:31 -0400 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Mon, 23 Apr 2007 12:17:21 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3NJHDSd026688; Mon, 23 Apr 2007 12:17:15 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3NJH90c021416; Mon, 23 Apr 2007 12:17:09 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 12:17:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Presence in P2P-SIP Date: Mon, 23 Apr 2007 12:16:55 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F6454@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Presence in P2P-SIP Thread-Index: AceFYNejEHJQn1WeQvqQ67uVE8t97gAdoSqQ References: <811D385AE1CEBB42839C50DF0B0D38E003D35A47@sernt4.essex.ac.uk> From: "Henry Sinnreich" To: "Cullen Jennings" , "Oredope, Adetola" X-OriginalArrivalTime: 23 Apr 2007 19:17:08.0550 (UTC) FILETIME=[FC97FE60:01C785DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I've been told about implementations where there is no presence =20 > server but instead pair wise subscriptions. > It's less than perfect but it works pretty well. Sorry for the late reply, but we can do better than that. A few key I-D is all that is required for example to support powerful multimedia chat rooms for CS-SIP: 1. Message sessions: draft-ietf-simple-message-sessions-19=20 by B. Campbell, R. Mahy and C. Jennings=20 2. Chat rooms: draft-niemi-simple-chat-06=20 by A. Niemi/Nokia and M. Garcia-Martin/Nokia=20 3. NAT traversal for chat using ICE: draft-niemi-simple-msrp-ice-00=20 by A. Niemi/Nokia By using the power of P2P multicast, such as in Scribe/Pastry. See here the=20 background:=20 http://research.microsoft.com/~antr/PAST/jsac.pdf=20 I understand there is free code at Rice University. I have focused here on SIMPLE P2P chat rooms, since the lack of open source SIMPLE servers makes us all here use XMPP instead, for the simple reason that it's available as OS and free downloads :-)>=20 Reminder: We can write protocol standards until we get blue in the face and they will fail unless OS code and free implementations are made available to support the standard.=20 Now back to SIMPLE P2P as by the above references... Thanks, Henry -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Sunday, April 22, 2007 11:35 PM To: Oredope, Adetola Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Presence in P2P-SIP I've been told about implementations where there is no presence =20 server but instead pair wise subscriptions. Assume that for everyone =20 on your buddy list you are on their buddy list. Then when you come on-=20 line, you subscribe to everyone on your buddy list by sending them a =20 subscribe directly over the P2P mesh just like you would send them an =20 INVITE. When your buddies see you subscribe to them, they subscribe =20 to you. It's less than perfect but it works pretty well. On Apr 13, 2007, at 3:43 AM, Oredope, Adetola wrote: > Hello, > > Do any one know of where I can find any information on Presence =20 > services > using P2P-SIP (SIMPLE)? > Is there any one out there working on this? > > Regards, > > Tola > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 01:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgDih-0004EB-4z; Tue, 24 Apr 2007 01:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgDif-00047G-Q8 for p2psip@ietf.org; Tue, 24 Apr 2007 01:37:41 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgDie-0004N1-AW for p2psip@ietf.org; Tue, 24 Apr 2007 01:37:41 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id 19511247A; Tue, 24 Apr 2007 07:37:37 +0200 (MEST) Received: from sat-relay1.telecom.ptt.nl (relay3.kpn-telecom.nl [145.7.200.29]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id CD9962466; Tue, 24 Apr 2007 07:37:36 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay1.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l3O5bVo12124; Tue, 24 Apr 2007 07:37:31 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 07:37:31 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [P2PSIP] P2P in mobile phone market Date: Tue, 24 Apr 2007 07:37:29 +0200 Message-ID: In-Reply-To: <4d4304a00704200715g14625afcm63b246e77cc00a50@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P in mobile phone market Thread-Index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbg References: <003f01c78348$b39f8b50$9f0aa8c0@WangYao><4628BA81.1020300@telecomitalia.it> <4d4304a00704200715g14625afcm63b246e77cc00a50@mail.gmail.com> From: To: , X-OriginalArrivalTime: 24 Apr 2007 05:37:31.0376 (UTC) FILETIME=[A7207F00:01C78632] X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org In the EU all calls could be subject to lawful intercept. PSTN and mobile telephony are obvious, but in many EU countries is obligatory to allow LI for VoIP. Also, ISPs are required to provide the necessary LI capbilities, delivering the IP Flow to a LEA. Colin Pons Senior Architect WSO Innovation Management -----Oorspronkelijk bericht----- Van: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Verzonden: vrijdag 20 april 2007 16:15 Aan: Enrico Marocco CC: p2psip@ietf.org Onderwerp: Re: [P2PSIP] P2P in mobile phone market In many countries the current rules require intercept of PSTN only, but several (including the US) have made it clear that all calls (even IP to IP) will eventually need to be interceptable (if that is a real word...). David On 4/20/07, Enrico Marocco wrote: > Yao Wang wrote: > > I don't think only the charge of Internet access is attractive enough for > > operators to replace their IMS equipments with P2PSIP devices. Because > > within the IMS, all sessions, services, and contents can be accounted. > > Obviously, the amount of these bills is much attractive to operators than > > the Internet access fee. > > I 100% agree. If subscribers agree too, it's done and we don't need > P2PSIP any more (at least my employer doesn't). > > > In my opinion, for the sake of making P2PSIP successful in the future, > > business aspects should be considered when its protocols are standardized. > > The peer protocol and client protocol to be defined should make it possible > > to control sessions and services to some extent and collect some kind of > > information on user's sessions in P2PSIP. > > > > The reasons are as follows. > > > > Firstly, accounting and management for P2PSIP will make users' experience > > better. Frequent search failures and unreliable services are unacceptable > > for end users. To avoid these problems, P2PSIP operators should be able to > > collect information on users' activities and their required QoS levels in > > order to meet different requirements of each user adjusting network > > resources. In addition, if charging mechanism is provided, more service > > providers will be attracted to the P2PSIP field, making services in P2PSIP > > become richer. > > Isn't this exactly what IMS provid^H^H^Hmises? > > > Secondly, management may be mandatory for P2PSIP operators. When P2PSIP is > > used for large-scale commercial operation, government or judiciary is likely > > to setup rules requesting operators to monitor sessions of users. Thus, it > > may be mandatory to control and record users' sessions to some extent. > > As far as I know, in Europe and US, regulation asks the providers to be > able to intercept communications when they are _terminated_ on telephony > networks. Maybe one day governments will mandate legal interception > also for communications both originating and terminating over the > Internet, but, once again, they will first have to ban encryption to > make it effective. > > > To draw a conclusion, I think management and accounting mechanisms need to > > be introduced into P2PSIP. > > > > I think my words focus too much on non-technical issues. Apologize in > > advance if I had gone beyond the task of this WG. :) > > Oh no, really, it's always entertaining to have this kind of discussions ;-) > > -- > Ciao, > Enrico > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 07:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJOi-0006zk-G1; Tue, 24 Apr 2007 07:41:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJOh-0006ze-IT for p2psip@ietf.org; Tue, 24 Apr 2007 07:41:27 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJOg-0007sC-4n for p2psip@ietf.org; Tue, 24 Apr 2007 07:41:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HgJN1-000494-Cf; Tue, 24 Apr 2007 06:39:43 -0500 From: "Brian Rosen" To: , , Subject: RE: [P2PSIP] P2P in mobile phone market Date: Tue, 24 Apr 2007 07:41:19 -0400 Message-ID: <070901c78665$7bb84040$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbgACnTQQA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org LI in p2p is harder than LI in a normal VoIP system. If something like a carrier deploys a p2psip overlay, it will have to figure out how to meet its LI requirement, and we're not going to provide any special facility to help (there is an RFC about that subject). The ISP delivering IP flows to LEAS is at a level below our work, and would, of course deliver p2psip signaling and media. Our security recommendations may impact a LEA's ability to tap. LI is not part of our charter. Brian > -----Original Message----- > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > Sent: Tuesday, April 24, 2007 1:37 AM > To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market > > In the EU all calls could be subject to lawful intercept. PSTN and > mobile telephony are obvious, but in many EU countries is obligatory to > allow LI for VoIP. > Also, ISPs are required to provide the necessary LI capbilities, > delivering the IP Flow to a LEA. > > Colin Pons > Senior Architect > WSO Innovation Management > > > -----Oorspronkelijk bericht----- > Van: David A. Bryan [mailto:dbryan@sipeerior.com] > Verzonden: vrijdag 20 april 2007 16:15 > Aan: Enrico Marocco > CC: p2psip@ietf.org > Onderwerp: Re: [P2PSIP] P2P in mobile phone market > > In many countries the current rules require intercept of PSTN only, > but several (including the US) have made it clear that all calls (even > IP to IP) will eventually need to be interceptable (if that is a real > word...). > > David > > On 4/20/07, Enrico Marocco wrote: > > Yao Wang wrote: > > > I don't think only the charge of Internet access is attractive > enough for > > > operators to replace their IMS equipments with P2PSIP devices. > Because > > > within the IMS, all sessions, services, and contents can be > accounted. > > > Obviously, the amount of these bills is much attractive to operators > than > > > the Internet access fee. > > > > I 100% agree. If subscribers agree too, it's done and we don't need > > P2PSIP any more (at least my employer doesn't). > > > > > In my opinion, for the sake of making P2PSIP successful in the > future, > > > business aspects should be considered when its protocols are > standardized. > > > The peer protocol and client protocol to be defined should make it > possible > > > to control sessions and services to some extent and collect some > kind of > > > information on user's sessions in P2PSIP. > > > > > > The reasons are as follows. > > > > > > Firstly, accounting and management for P2PSIP will make users' > experience > > > better. Frequent search failures and unreliable services are > unacceptable > > > for end users. To avoid these problems, P2PSIP operators should be > able to > > > collect information on users' activities and their required QoS > levels in > > > order to meet different requirements of each user adjusting network > > > resources. In addition, if charging mechanism is provided, more > service > > > providers will be attracted to the P2PSIP field, making services in > P2PSIP > > > become richer. > > > > Isn't this exactly what IMS provid^H^H^Hmises? > > > > > Secondly, management may be mandatory for P2PSIP operators. When > P2PSIP is > > > used for large-scale commercial operation, government or judiciary > is likely > > > to setup rules requesting operators to monitor sessions of users. > Thus, it > > > may be mandatory to control and record users' sessions to some > extent. > > > > As far as I know, in Europe and US, regulation asks the providers to > be > > able to intercept communications when they are _terminated_ on > telephony > > networks. Maybe one day governments will mandate legal interception > > also for communications both originating and terminating over the > > Internet, but, once again, they will first have to ban encryption to > > make it effective. > > > > > To draw a conclusion, I think management and accounting mechanisms > need to > > > be introduced into P2PSIP. > > > > > > I think my words focus too much on non-technical issues. Apologize > in > > > advance if I had gone beyond the task of this WG. :) > > > > Oh no, really, it's always entertaining to have this kind of > discussions ;-) > > > > -- > > Ciao, > > Enrico > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 08:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJvT-00087x-SG; Tue, 24 Apr 2007 08:15:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJvS-00087q-El for p2psip@ietf.org; Tue, 24 Apr 2007 08:15:18 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgJvQ-0007AT-Q4 for p2psip@ietf.org; Tue, 24 Apr 2007 08:15:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Tue, 24 Apr 2007 05:15:08 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3OCEGD1011055; Tue, 24 Apr 2007 05:14:16 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3OCEMI9018512; Tue, 24 Apr 2007 05:14:23 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 05:14:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] P2P in mobile phone market Date: Tue, 24 Apr 2007 05:14:47 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F65BC@namail5.corp.adobe.com> In-Reply-To: <070901c78665$7bb84040$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P in mobile phone market Thread-Index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbgACnTQQAAAHProA== References: <070901c78665$7bb84040$640fa8c0@cis.neustar.com> From: "Henry Sinnreich" To: "Brian Rosen" , , , X-OriginalArrivalTime: 24 Apr 2007 12:14:48.0263 (UTC) FILETIME=[2704CD70:01C7866A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Brian on all points here.=20 Since LI will most certainly come up again, the WG will have to articulate clearly what P2P SIP will and will not do for LI and why. > ISPs are required to provide the necessary LI capabilities, > delivering the IP Flow to a LEA. P2P flows can be correlated to some degree at the IP level, but cannot necessarily be understood even if copies of the media flows are delivered to the LEA. The back door provision for the now infamous Clipper chip has long been discarded. Some documentation on the history of the back door discussions and the issues involved may be useful here as well. Last but not least, P2P SIP (just like SIP) is not meant as a replacement for existing TDM telephony systems. I am bringing this up, since it is often a forgotten item, ignored or simply not understood. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, April 24, 2007 6:41 AM To: colin.pons@kpn.com; dbryan@sipeerior.com; enrico.marocco@telecomitalia.it Cc: p2psip@ietf.org Subject: RE: [P2PSIP] P2P in mobile phone market LI in p2p is harder than LI in a normal VoIP system. If something like a carrier deploys a p2psip overlay, it will have to figure out how to meet its LI requirement, and we're not going to provide any special facility to help (there is an RFC about that subject). The ISP delivering IP flows to LEAS is at a level below our work, and would, of course deliver p2psip signaling and media. Our security recommendations may impact a LEA's ability to tap. LI is not part of our charter. Brian > -----Original Message----- > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > Sent: Tuesday, April 24, 2007 1:37 AM > To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market >=20 > In the EU all calls could be subject to lawful intercept. PSTN and > mobile telephony are obvious, but in many EU countries is obligatory to > allow LI for VoIP. > Also, ISPs are required to provide the necessary LI capbilities, > delivering the IP Flow to a LEA. >=20 > Colin Pons > Senior Architect > WSO Innovation Management >=20 >=20 > -----Oorspronkelijk bericht----- > Van: David A. Bryan [mailto:dbryan@sipeerior.com] > Verzonden: vrijdag 20 april 2007 16:15 > Aan: Enrico Marocco > CC: p2psip@ietf.org > Onderwerp: Re: [P2PSIP] P2P in mobile phone market >=20 > In many countries the current rules require intercept of PSTN only, > but several (including the US) have made it clear that all calls (even > IP to IP) will eventually need to be interceptable (if that is a real > word...). >=20 > David >=20 > On 4/20/07, Enrico Marocco wrote: > > Yao Wang wrote: > > > I don't think only the charge of Internet access is attractive > enough for > > > operators to replace their IMS equipments with P2PSIP devices. > Because > > > within the IMS, all sessions, services, and contents can be > accounted. > > > Obviously, the amount of these bills is much attractive to operators > than > > > the Internet access fee. > > > > I 100% agree. If subscribers agree too, it's done and we don't need > > P2PSIP any more (at least my employer doesn't). > > > > > In my opinion, for the sake of making P2PSIP successful in the > future, > > > business aspects should be considered when its protocols are > standardized. > > > The peer protocol and client protocol to be defined should make it > possible > > > to control sessions and services to some extent and collect some > kind of > > > information on user's sessions in P2PSIP. > > > > > > The reasons are as follows. > > > > > > Firstly, accounting and management for P2PSIP will make users' > experience > > > better. Frequent search failures and unreliable services are > unacceptable > > > for end users. To avoid these problems, P2PSIP operators should be > able to > > > collect information on users' activities and their required QoS > levels in > > > order to meet different requirements of each user adjusting network > > > resources. In addition, if charging mechanism is provided, more > service > > > providers will be attracted to the P2PSIP field, making services in > P2PSIP > > > become richer. > > > > Isn't this exactly what IMS provid^H^H^Hmises? > > > > > Secondly, management may be mandatory for P2PSIP operators. When > P2PSIP is > > > used for large-scale commercial operation, government or judiciary > is likely > > > to setup rules requesting operators to monitor sessions of users. > Thus, it > > > may be mandatory to control and record users' sessions to some > extent. > > > > As far as I know, in Europe and US, regulation asks the providers to > be > > able to intercept communications when they are _terminated_ on > telephony > > networks. Maybe one day governments will mandate legal interception > > also for communications both originating and terminating over the > > Internet, but, once again, they will first have to ban encryption to > > make it effective. > > > > > To draw a conclusion, I think management and accounting mechanisms > need to > > > be introduced into P2PSIP. > > > > > > I think my words focus too much on non-technical issues. Apologize > in > > > advance if I had gone beyond the task of this WG. :) > > > > Oh no, really, it's always entertaining to have this kind of > discussions ;-) > > > > -- > > Ciao, > > Enrico > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 10:15:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLnv-00021C-Ox; Tue, 24 Apr 2007 10:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLnu-000211-4A for p2psip@ietf.org; Tue, 24 Apr 2007 10:15:38 -0400 Received: from smtpscan-nl3.aots.nl ([145.7.191.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgLns-0003xE-Fa for p2psip@ietf.org; Tue, 24 Apr 2007 10:15:38 -0400 Received: from smtpscan-nl3.aots.nl (localhost [127.0.0.1]) by localhost.aots.nl (Postfix) with ESMTP id 9B87C24AF; Tue, 24 Apr 2007 16:15:29 +0200 (MEST) Received: from sat-relay1.telecom.ptt.nl (relay3.kpn-telecom.nl [145.7.200.29]) by smtpscan-nl3.aots.nl (Postfix) with ESMTP id 8395126A6; Tue, 24 Apr 2007 16:15:26 +0200 (MEST) Received: from KKWNLEX010.kpnnl.local (kkwnlex010.kpnnl.local [145.7.180.33]) by sat-relay1.telecom.ptt.nl (8.11.6p2-20030924/8.11.6) with ESMTP id l3OEFPo05757; Tue, 24 Apr 2007 16:15:25 +0200 Received: from KKWNLEX181.kpnnl.local ([172.23.222.150]) by KKWNLEX010.kpnnl.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 16:15:23 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [P2PSIP] P2P in mobile phone market Date: Tue, 24 Apr 2007 16:15:25 +0200 Message-ID: In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226F65BC@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P in mobile phone market Thread-Index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbgACnTQQAAAHProAAEyzaQ References: <070901c78665$7bb84040$640fa8c0@cis.neustar.com> <24CCCC428EFEA2469BF046DB3C7A8D226F65BC@namail5.corp.adobe.com> From: To: , , , X-OriginalArrivalTime: 24 Apr 2007 14:15:23.0416 (UTC) FILETIME=[FF818980:01C7867A] X-Spam-Score: 0.2 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I largely agree with both Brian and Henry. For ISPs LI is just a matter of reality, P2P SIP wouldn't change any of it. Having said that, LEA and congress men (lawmakers) likely have a different opinion, requiring special facilities for tapping of voice and other communication. Do expect the LI obligations that apply now for TDM will also be applied to Internet communication services (even if those have nothing to do with TDM voice). Not having *special* intermediaries, such as Application servers or proxies, has an impact on those obligations (a special problem will be to only tap traffic from specific users). I sympathize with the exclusion of LI from the P2P SIP chapter, if not for the many uncertainities to which obligations to solution should comply. Colin Pons -----Oorspronkelijk bericht----- Van: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Verzonden: dinsdag 24 april 2007 14:15 Aan: Brian Rosen; Pons, C.A. (Colin); dbryan@sipeerior.com; enrico.marocco@telecomitalia.it CC: p2psip@ietf.org Onderwerp: RE: [P2PSIP] P2P in mobile phone market I agree with Brian on all points here.=20 Since LI will most certainly come up again, the WG will have to articulate clearly what P2P SIP will and will not do for LI and why. > ISPs are required to provide the necessary LI capabilities, > delivering the IP Flow to a LEA. P2P flows can be correlated to some degree at the IP level, but cannot necessarily be understood even if copies of the media flows are delivered to the LEA. The back door provision for the now infamous Clipper chip has long been discarded. Some documentation on the history of the back door discussions and the issues involved may be useful here as well. Last but not least, P2P SIP (just like SIP) is not meant as a replacement for existing TDM telephony systems. I am bringing this up, since it is often a forgotten item, ignored or simply not understood. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, April 24, 2007 6:41 AM To: colin.pons@kpn.com; dbryan@sipeerior.com; enrico.marocco@telecomitalia.it Cc: p2psip@ietf.org Subject: RE: [P2PSIP] P2P in mobile phone market LI in p2p is harder than LI in a normal VoIP system. If something like a carrier deploys a p2psip overlay, it will have to figure out how to meet its LI requirement, and we're not going to provide any special facility to help (there is an RFC about that subject). The ISP delivering IP flows to LEAS is at a level below our work, and would, of course deliver p2psip signaling and media. Our security recommendations may impact a LEA's ability to tap. LI is not part of our charter. Brian > -----Original Message----- > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > Sent: Tuesday, April 24, 2007 1:37 AM > To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market >=20 > In the EU all calls could be subject to lawful intercept. PSTN and > mobile telephony are obvious, but in many EU countries is obligatory to > allow LI for VoIP. > Also, ISPs are required to provide the necessary LI capbilities, > delivering the IP Flow to a LEA. >=20 > Colin Pons > Senior Architect > WSO Innovation Management >=20 >=20 > -----Oorspronkelijk bericht----- > Van: David A. Bryan [mailto:dbryan@sipeerior.com] > Verzonden: vrijdag 20 april 2007 16:15 > Aan: Enrico Marocco > CC: p2psip@ietf.org > Onderwerp: Re: [P2PSIP] P2P in mobile phone market >=20 > In many countries the current rules require intercept of PSTN only, > but several (including the US) have made it clear that all calls (even > IP to IP) will eventually need to be interceptable (if that is a real > word...). >=20 > David >=20 > On 4/20/07, Enrico Marocco wrote: > > Yao Wang wrote: > > > I don't think only the charge of Internet access is attractive > enough for > > > operators to replace their IMS equipments with P2PSIP devices. > Because > > > within the IMS, all sessions, services, and contents can be > accounted. > > > Obviously, the amount of these bills is much attractive to operators > than > > > the Internet access fee. > > > > I 100% agree. If subscribers agree too, it's done and we don't need > > P2PSIP any more (at least my employer doesn't). > > > > > In my opinion, for the sake of making P2PSIP successful in the > future, > > > business aspects should be considered when its protocols are > standardized. > > > The peer protocol and client protocol to be defined should make it > possible > > > to control sessions and services to some extent and collect some > kind of > > > information on user's sessions in P2PSIP. > > > > > > The reasons are as follows. > > > > > > Firstly, accounting and management for P2PSIP will make users' > experience > > > better. Frequent search failures and unreliable services are > unacceptable > > > for end users. To avoid these problems, P2PSIP operators should be > able to > > > collect information on users' activities and their required QoS > levels in > > > order to meet different requirements of each user adjusting network > > > resources. In addition, if charging mechanism is provided, more > service > > > providers will be attracted to the P2PSIP field, making services in > P2PSIP > > > become richer. > > > > Isn't this exactly what IMS provid^H^H^Hmises? > > > > > Secondly, management may be mandatory for P2PSIP operators. When > P2PSIP is > > > used for large-scale commercial operation, government or judiciary > is likely > > > to setup rules requesting operators to monitor sessions of users. > Thus, it > > > may be mandatory to control and record users' sessions to some > extent. > > > > As far as I know, in Europe and US, regulation asks the providers to > be > > able to intercept communications when they are _terminated_ on > telephony > > networks. Maybe one day governments will mandate legal interception > > also for communications both originating and terminating over the > > Internet, but, once again, they will first have to ban encryption to > > make it effective. > > > > > To draw a conclusion, I think management and accounting mechanisms > need to > > > be introduced into P2PSIP. > > > > > > I think my words focus too much on non-technical issues. Apologize > in > > > advance if I had gone beyond the task of this WG. :) > > > > Oh no, really, it's always entertaining to have this kind of > discussions ;-) > > > > -- > > Ciao, > > Enrico > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 10:42:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMDV-0002b0-D7; Tue, 24 Apr 2007 10:42:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMDU-0002au-O1 for p2psip@ietf.org; Tue, 24 Apr 2007 10:42:04 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMDT-0003DK-4c for p2psip@ietf.org; Tue, 24 Apr 2007 10:42:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HgMBe-0002kg-Pk; Tue, 24 Apr 2007 09:40:11 -0500 From: "Brian Rosen" To: , , , Subject: RE: [P2PSIP] P2P in mobile phone market Date: Tue, 24 Apr 2007 10:41:48 -0400 Message-ID: <000401c7867e$b2654110$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbgACnTQQAAAHProAAEyzaQAAC/tiA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It's always ugly when old laws, and old law makers, apply old thinking to new technologies. LI is one of those cases. LI should never have focused on the telephony aspects of VoIP; it should have focused on the packet stuff, and treated the telephony as one of many services of interest on the pipe. If you take the p2psip ideas we have in mind to the logical extreme, where the only "service" is an enrollment server and possibly one or more bootstrap nodes, there is no infrastructure to do a pen trace (signaling tap), let alone a media trace. LI as seen by a "carrier" in a p2psip environment can be looked at as pretty much impossible. The lawmen can scream all they want, but p2p is p2p and not p2server. I don't think we're going to do anything to be more helpful to such "carriers". I don't think it's possible to do anything short of making every peer have the kind of backdoor Henry alluded to. We're sure not going to standardize that kind of thing. It's possible that the law makers and law enforcers will take a while to deal with the reality here. But what can they do? Ban p2psip? What they can do is deal with it at the packet level. That's a reasonable solution. The encryption part may hamper them, but again, that's the reality of modern Internet communications: increasingly using modern crypto to protect transactions and flows. Remember my "what do we want p2psip to mean" thread? One of the items was "all signaling and all media encrypted all the time". That will frustrate LI also, but it is the right thing to do for p2psip. Brian > -----Original Message----- > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > Sent: Tuesday, April 24, 2007 10:15 AM > To: hsinnrei@adobe.com; br@brianrosen.net; dbryan@sipeerior.com; > enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market > > I largely agree with both Brian and Henry. For ISPs LI is just a matter > of reality, P2P SIP wouldn't change any of it. > > Having said that, LEA and congress men (lawmakers) likely have a > different opinion, requiring special facilities for tapping of voice and > other communication. Do expect the LI obligations that apply now for TDM > will also be applied to Internet communication services (even if those > have nothing to do with TDM voice). Not having *special* intermediaries, > such as Application servers or proxies, has an impact on those > obligations (a special problem will be to only tap traffic from specific > users). > > I sympathize with the exclusion of LI from the P2P SIP chapter, if not > for the many uncertainities to which obligations to solution should > comply. > > Colin Pons > > > -----Oorspronkelijk bericht----- > Van: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Verzonden: dinsdag 24 april 2007 14:15 > Aan: Brian Rosen; Pons, C.A. (Colin); dbryan@sipeerior.com; > enrico.marocco@telecomitalia.it > CC: p2psip@ietf.org > Onderwerp: RE: [P2PSIP] P2P in mobile phone market > > I agree with Brian on all points here. > > Since LI will most certainly come up again, the WG will have to > articulate clearly what P2P SIP will and will not do for LI and why. > > > ISPs are required to provide the necessary LI capabilities, > > delivering the IP Flow to a LEA. > > P2P flows can be correlated to some degree at the IP level, but cannot > necessarily be understood even if copies of the media flows are > delivered to the LEA. > > The back door provision for the now infamous Clipper chip has long been > discarded. Some documentation on the history of the back door > discussions and the issues involved may be useful here as well. > > Last but not least, P2P SIP (just like SIP) is not meant as a > replacement for existing TDM telephony systems. I am bringing this up, > since it is often a forgotten item, ignored or simply not understood. > > Thanks, Henry > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, April 24, 2007 6:41 AM > To: colin.pons@kpn.com; dbryan@sipeerior.com; > enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market > > LI in p2p is harder than LI in a normal VoIP system. If something like > a > carrier deploys a p2psip overlay, it will have to figure out how to meet > its > LI requirement, and we're not going to provide any special facility to > help > (there is an RFC about that subject). > > The ISP delivering IP flows to LEAS is at a level below our work, and > would, > of course deliver p2psip signaling and media. Our security > recommendations > may impact a LEA's ability to tap. > > LI is not part of our charter. > > Brian > > > > > > -----Original Message----- > > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > > Sent: Tuesday, April 24, 2007 1:37 AM > > To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it > > Cc: p2psip@ietf.org > > Subject: RE: [P2PSIP] P2P in mobile phone market > > > > In the EU all calls could be subject to lawful intercept. PSTN and > > mobile telephony are obvious, but in many EU countries is obligatory > to > > allow LI for VoIP. > > Also, ISPs are required to provide the necessary LI capbilities, > > delivering the IP Flow to a LEA. > > > > Colin Pons > > Senior Architect > > WSO Innovation Management > > > > > > -----Oorspronkelijk bericht----- > > Van: David A. Bryan [mailto:dbryan@sipeerior.com] > > Verzonden: vrijdag 20 april 2007 16:15 > > Aan: Enrico Marocco > > CC: p2psip@ietf.org > > Onderwerp: Re: [P2PSIP] P2P in mobile phone market > > > > In many countries the current rules require intercept of PSTN only, > > but several (including the US) have made it clear that all calls (even > > IP to IP) will eventually need to be interceptable (if that is a real > > word...). > > > > David > > > > On 4/20/07, Enrico Marocco wrote: > > > Yao Wang wrote: > > > > I don't think only the charge of Internet access is attractive > > enough for > > > > operators to replace their IMS equipments with P2PSIP devices. > > Because > > > > within the IMS, all sessions, services, and contents can be > > accounted. > > > > Obviously, the amount of these bills is much attractive to > operators > > than > > > > the Internet access fee. > > > > > > I 100% agree. If subscribers agree too, it's done and we don't need > > > P2PSIP any more (at least my employer doesn't). > > > > > > > In my opinion, for the sake of making P2PSIP successful in the > > future, > > > > business aspects should be considered when its protocols are > > standardized. > > > > The peer protocol and client protocol to be defined should make it > > possible > > > > to control sessions and services to some extent and collect some > > kind of > > > > information on user's sessions in P2PSIP. > > > > > > > > The reasons are as follows. > > > > > > > > Firstly, accounting and management for P2PSIP will make users' > > experience > > > > better. Frequent search failures and unreliable services are > > unacceptable > > > > for end users. To avoid these problems, P2PSIP operators should be > > able to > > > > collect information on users' activities and their required QoS > > levels in > > > > order to meet different requirements of each user adjusting > network > > > > resources. In addition, if charging mechanism is provided, more > > service > > > > providers will be attracted to the P2PSIP field, making services > in > > P2PSIP > > > > become richer. > > > > > > Isn't this exactly what IMS provid^H^H^Hmises? > > > > > > > Secondly, management may be mandatory for P2PSIP operators. When > > P2PSIP is > > > > used for large-scale commercial operation, government or judiciary > > is likely > > > > to setup rules requesting operators to monitor sessions of users. > > Thus, it > > > > may be mandatory to control and record users' sessions to some > > extent. > > > > > > As far as I know, in Europe and US, regulation asks the providers to > > be > > > able to intercept communications when they are _terminated_ on > > telephony > > > networks. Maybe one day governments will mandate legal interception > > > also for communications both originating and terminating over the > > > Internet, but, once again, they will first have to ban encryption to > > > make it effective. > > > > > > > To draw a conclusion, I think management and accounting mechanisms > > need to > > > > be introduced into P2PSIP. > > > > > > > > I think my words focus too much on non-technical issues. Apologize > > in > > > > advance if I had gone beyond the task of this WG. :) > > > > > > Oh no, really, it's always entertaining to have this kind of > > discussions ;-) > > > > > > -- > > > Ciao, > > > Enrico > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 10:46:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMI4-0006JZ-IZ; Tue, 24 Apr 2007 10:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMI4-0006JU-5e for p2psip@ietf.org; Tue, 24 Apr 2007 10:46:48 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgMI3-00045m-HJ for p2psip@ietf.org; Tue, 24 Apr 2007 10:46:48 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 24 Apr 2007 07:46:34 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3OEjtD1029495; Tue, 24 Apr 2007 07:45:56 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3OEkR0k016957; Tue, 24 Apr 2007 07:46:32 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 07:46:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] P2P in mobile phone market Date: Tue, 24 Apr 2007 07:46:21 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F65D3@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2P in mobile phone market Thread-Index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbgACnTQQAAAHProAAEyzaQAADi34A= References: <070901c78665$7bb84040$640fa8c0@cis.neustar.com> <24CCCC428EFEA2469BF046DB3C7A8D226F65BC@namail5.corp.adobe.com> From: "Henry Sinnreich" To: , , , X-OriginalArrivalTime: 24 Apr 2007 14:46:22.0358 (UTC) FILETIME=[53859360:01C7867F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is probably out of scope for the P2P SIP WG, but it is useful to inform ISPs and lawmakers that "interception" of communications poses first of all the danger to law enforcement agencies themselves to infiltration and of physical danger to its agents. Interception is also unacceptable to the financial industry as a whole and to most enterprise IT organizations. Various commercial products claim to be useful for legal interception, but a closer look show they can be easily circumvented given there are so many types of communications possible, besides the basic consideration that LI may be self defeating. I suggest we find who in the IETF is dealing with these issues (they have been discussed a memorable plenary some time ago) and keep a strong liaison to the work on LI. Maybe new research on backdoor security will change all this. Please share any information if/when it becomes available, so we can apply it to P2P SIP.=20 Thanks, Henry=20 -----Original Message----- From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]=20 Sent: Tuesday, April 24, 2007 9:15 AM To: Henry Sinnreich; br@brianrosen.net; dbryan@sipeerior.com; enrico.marocco@telecomitalia.it Cc: p2psip@ietf.org Subject: RE: [P2PSIP] P2P in mobile phone market I largely agree with both Brian and Henry. For ISPs LI is just a matter of reality, P2P SIP wouldn't change any of it. Having said that, LEA and congress men (lawmakers) likely have a different opinion, requiring special facilities for tapping of voice and other communication. Do expect the LI obligations that apply now for TDM will also be applied to Internet communication services (even if those have nothing to do with TDM voice). Not having *special* intermediaries, such as Application servers or proxies, has an impact on those obligations (a special problem will be to only tap traffic from specific users). I sympathize with the exclusion of LI from the P2P SIP chapter, if not for the many uncertainities to which obligations to solution should comply. Colin Pons -----Oorspronkelijk bericht----- Van: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Verzonden: dinsdag 24 april 2007 14:15 Aan: Brian Rosen; Pons, C.A. (Colin); dbryan@sipeerior.com; enrico.marocco@telecomitalia.it CC: p2psip@ietf.org Onderwerp: RE: [P2PSIP] P2P in mobile phone market I agree with Brian on all points here.=20 Since LI will most certainly come up again, the WG will have to articulate clearly what P2P SIP will and will not do for LI and why. > ISPs are required to provide the necessary LI capabilities, > delivering the IP Flow to a LEA. P2P flows can be correlated to some degree at the IP level, but cannot necessarily be understood even if copies of the media flows are delivered to the LEA. The back door provision for the now infamous Clipper chip has long been discarded. Some documentation on the history of the back door discussions and the issues involved may be useful here as well. Last but not least, P2P SIP (just like SIP) is not meant as a replacement for existing TDM telephony systems. I am bringing this up, since it is often a forgotten item, ignored or simply not understood. Thanks, Henry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, April 24, 2007 6:41 AM To: colin.pons@kpn.com; dbryan@sipeerior.com; enrico.marocco@telecomitalia.it Cc: p2psip@ietf.org Subject: RE: [P2PSIP] P2P in mobile phone market LI in p2p is harder than LI in a normal VoIP system. If something like a carrier deploys a p2psip overlay, it will have to figure out how to meet its LI requirement, and we're not going to provide any special facility to help (there is an RFC about that subject). The ISP delivering IP flows to LEAS is at a level below our work, and would, of course deliver p2psip signaling and media. Our security recommendations may impact a LEA's ability to tap. LI is not part of our charter. Brian > -----Original Message----- > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > Sent: Tuesday, April 24, 2007 1:37 AM > To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market >=20 > In the EU all calls could be subject to lawful intercept. PSTN and > mobile telephony are obvious, but in many EU countries is obligatory to > allow LI for VoIP. > Also, ISPs are required to provide the necessary LI capbilities, > delivering the IP Flow to a LEA. >=20 > Colin Pons > Senior Architect > WSO Innovation Management >=20 >=20 > -----Oorspronkelijk bericht----- > Van: David A. Bryan [mailto:dbryan@sipeerior.com] > Verzonden: vrijdag 20 april 2007 16:15 > Aan: Enrico Marocco > CC: p2psip@ietf.org > Onderwerp: Re: [P2PSIP] P2P in mobile phone market >=20 > In many countries the current rules require intercept of PSTN only, > but several (including the US) have made it clear that all calls (even > IP to IP) will eventually need to be interceptable (if that is a real > word...). >=20 > David >=20 > On 4/20/07, Enrico Marocco wrote: > > Yao Wang wrote: > > > I don't think only the charge of Internet access is attractive > enough for > > > operators to replace their IMS equipments with P2PSIP devices. > Because > > > within the IMS, all sessions, services, and contents can be > accounted. > > > Obviously, the amount of these bills is much attractive to operators > than > > > the Internet access fee. > > > > I 100% agree. If subscribers agree too, it's done and we don't need > > P2PSIP any more (at least my employer doesn't). > > > > > In my opinion, for the sake of making P2PSIP successful in the > future, > > > business aspects should be considered when its protocols are > standardized. > > > The peer protocol and client protocol to be defined should make it > possible > > > to control sessions and services to some extent and collect some > kind of > > > information on user's sessions in P2PSIP. > > > > > > The reasons are as follows. > > > > > > Firstly, accounting and management for P2PSIP will make users' > experience > > > better. Frequent search failures and unreliable services are > unacceptable > > > for end users. To avoid these problems, P2PSIP operators should be > able to > > > collect information on users' activities and their required QoS > levels in > > > order to meet different requirements of each user adjusting network > > > resources. In addition, if charging mechanism is provided, more > service > > > providers will be attracted to the P2PSIP field, making services in > P2PSIP > > > become richer. > > > > Isn't this exactly what IMS provid^H^H^Hmises? > > > > > Secondly, management may be mandatory for P2PSIP operators. When > P2PSIP is > > > used for large-scale commercial operation, government or judiciary > is likely > > > to setup rules requesting operators to monitor sessions of users. > Thus, it > > > may be mandatory to control and record users' sessions to some > extent. > > > > As far as I know, in Europe and US, regulation asks the providers to > be > > able to intercept communications when they are _terminated_ on > telephony > > networks. Maybe one day governments will mandate legal interception > > also for communications both originating and terminating over the > > Internet, but, once again, they will first have to ban encryption to > > make it effective. > > > > > To draw a conclusion, I think management and accounting mechanisms > need to > > > be introduced into P2PSIP. > > > > > > I think my words focus too much on non-technical issues. Apologize > in > > > advance if I had gone beyond the task of this WG. :) > > > > Oh no, really, it's always entertaining to have this kind of > discussions ;-) > > > > -- > > Ciao, > > Enrico > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 11:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgN59-0000xh-2D; Tue, 24 Apr 2007 11:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgN57-0000xF-MS for p2psip@ietf.org; Tue, 24 Apr 2007 11:37:29 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgN56-000897-6v for p2psip@ietf.org; Tue, 24 Apr 2007 11:37:29 -0400 Received: by wx-out-0506.google.com with SMTP id h31so2318525wxd for ; Tue, 24 Apr 2007 08:37:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lChsamv3hF7I+cFAamPTPRXP1byklEWs2q6uEsuqQGdCKSZbBb0rEQUUEVnf3mOBWTj3YcxTbaCVkfC0JBX2XrE9XsUz/MKh5hjSCj2ugVnsup6y24/jgpipz63hLLgJd/uknrWtNPctWJ7KTZANykke6ueIDTSQ0Xxkz0GTVeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DchnEmPBvZi2jxMN3qaHMGAss7xC8rJaoijEgVqEqAvH+KqXYK/fE6d6ZTyQ8Ic6QOvZyAZ84GNB/+fAw9O2+gwcWduwoCev3r1G6O1auxOGZdHyTA5qJbRcNyCEMgb8n1vebh1tfLiic15S0uCaV6B9ml9fiivajUf3gcT7OPA= Received: by 10.70.74.1 with SMTP id w1mr12720247wxa.1177429047178; Tue, 24 Apr 2007 08:37:27 -0700 (PDT) Received: by 10.70.126.4 with HTTP; Tue, 24 Apr 2007 08:37:27 -0700 (PDT) Message-ID: <6a40ca380704240837l1e082abaka6ab5ec35830ebf7@mail.gmail.com> Date: Tue, 24 Apr 2007 18:37:27 +0300 From: "Alex Gakuru" To: "Henry Sinnreich" Subject: Re: [P2PSIP] P2P in mobile phone market In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226F65D3@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <070901c78665$7bb84040$640fa8c0@cis.neustar.com> <24CCCC428EFEA2469BF046DB3C7A8D226F65BC@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D226F65D3@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I know Fred Baker has done quite much on LI and written a briefing on the subject. He would be quite resourceful. Thanks Alex On 4/24/07, Henry Sinnreich wrote: > This is probably out of scope for the P2P SIP WG, but it is useful to > inform ISPs and lawmakers that "interception" of communications poses > first of all the danger to law enforcement agencies themselves to > infiltration and of physical danger to its agents. > > Interception is also unacceptable to the financial industry as a whole > and to most enterprise IT organizations. > > Various commercial products claim to be useful for legal interception, > but a closer look show they can be easily circumvented given there are > so many types of communications possible, besides the basic > consideration that LI may be self defeating. > > I suggest we find who in the IETF is dealing with these issues (they > have been discussed a memorable plenary some time ago) and keep a strong > liaison to the work on LI. > > Maybe new research on backdoor security will change all this. Please > share any information if/when it becomes available, so we can apply it > to P2P SIP. > > Thanks, Henry > > -----Original Message----- > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > Sent: Tuesday, April 24, 2007 9:15 AM > To: Henry Sinnreich; br@brianrosen.net; dbryan@sipeerior.com; > enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market > > I largely agree with both Brian and Henry. For ISPs LI is just a matter > of reality, P2P SIP wouldn't change any of it. > > Having said that, LEA and congress men (lawmakers) likely have a > different opinion, requiring special facilities for tapping of voice and > other communication. Do expect the LI obligations that apply now for TDM > will also be applied to Internet communication services (even if those > have nothing to do with TDM voice). Not having *special* intermediaries, > such as Application servers or proxies, has an impact on those > obligations (a special problem will be to only tap traffic from specific > users). > > I sympathize with the exclusion of LI from the P2P SIP chapter, if not > for the many uncertainities to which obligations to solution should > comply. > > Colin Pons > > > -----Oorspronkelijk bericht----- > Van: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Verzonden: dinsdag 24 april 2007 14:15 > Aan: Brian Rosen; Pons, C.A. (Colin); dbryan@sipeerior.com; > enrico.marocco@telecomitalia.it > CC: p2psip@ietf.org > Onderwerp: RE: [P2PSIP] P2P in mobile phone market > > I agree with Brian on all points here. > > Since LI will most certainly come up again, the WG will have to > articulate clearly what P2P SIP will and will not do for LI and why. > > > ISPs are required to provide the necessary LI capabilities, > > delivering the IP Flow to a LEA. > > P2P flows can be correlated to some degree at the IP level, but cannot > necessarily be understood even if copies of the media flows are > delivered to the LEA. > > The back door provision for the now infamous Clipper chip has long been > discarded. Some documentation on the history of the back door > discussions and the issues involved may be useful here as well. > > Last but not least, P2P SIP (just like SIP) is not meant as a > replacement for existing TDM telephony systems. I am bringing this up, > since it is often a forgotten item, ignored or simply not understood. > > Thanks, Henry > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, April 24, 2007 6:41 AM > To: colin.pons@kpn.com; dbryan@sipeerior.com; > enrico.marocco@telecomitalia.it > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] P2P in mobile phone market > > LI in p2p is harder than LI in a normal VoIP system. If something like > a > carrier deploys a p2psip overlay, it will have to figure out how to meet > its > LI requirement, and we're not going to provide any special facility to > help > (there is an RFC about that subject). > > The ISP delivering IP flows to LEAS is at a level below our work, and > would, > of course deliver p2psip signaling and media. Our security > recommendations > may impact a LEA's ability to tap. > > LI is not part of our charter. > > Brian > > > > > > -----Original Message----- > > From: colin.pons@kpn.com [mailto:colin.pons@kpn.com] > > Sent: Tuesday, April 24, 2007 1:37 AM > > To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it > > Cc: p2psip@ietf.org > > Subject: RE: [P2PSIP] P2P in mobile phone market > > > > In the EU all calls could be subject to lawful intercept. PSTN and > > mobile telephony are obvious, but in many EU countries is obligatory > to > > allow LI for VoIP. > > Also, ISPs are required to provide the necessary LI capbilities, > > delivering the IP Flow to a LEA. > > > > Colin Pons > > Senior Architect > > WSO Innovation Management > > > > > > -----Oorspronkelijk bericht----- > > Van: David A. Bryan [mailto:dbryan@sipeerior.com] > > Verzonden: vrijdag 20 april 2007 16:15 > > Aan: Enrico Marocco > > CC: p2psip@ietf.org > > Onderwerp: Re: [P2PSIP] P2P in mobile phone market > > > > In many countries the current rules require intercept of PSTN only, > > but several (including the US) have made it clear that all calls (even > > IP to IP) will eventually need to be interceptable (if that is a real > > word...). > > > > David > > > > On 4/20/07, Enrico Marocco wrote: > > > Yao Wang wrote: > > > > I don't think only the charge of Internet access is attractive > > enough for > > > > operators to replace their IMS equipments with P2PSIP devices. > > Because > > > > within the IMS, all sessions, services, and contents can be > > accounted. > > > > Obviously, the amount of these bills is much attractive to > operators > > than > > > > the Internet access fee. > > > > > > I 100% agree. If subscribers agree too, it's done and we don't need > > > P2PSIP any more (at least my employer doesn't). > > > > > > > In my opinion, for the sake of making P2PSIP successful in the > > future, > > > > business aspects should be considered when its protocols are > > standardized. > > > > The peer protocol and client protocol to be defined should make it > > possible > > > > to control sessions and services to some extent and collect some > > kind of > > > > information on user's sessions in P2PSIP. > > > > > > > > The reasons are as follows. > > > > > > > > Firstly, accounting and management for P2PSIP will make users' > > experience > > > > better. Frequent search failures and unreliable services are > > unacceptable > > > > for end users. To avoid these problems, P2PSIP operators should be > > able to > > > > collect information on users' activities and their required QoS > > levels in > > > > order to meet different requirements of each user adjusting > network > > > > resources. In addition, if charging mechanism is provided, more > > service > > > > providers will be attracted to the P2PSIP field, making services > in > > P2PSIP > > > > become richer. > > > > > > Isn't this exactly what IMS provid^H^H^Hmises? > > > > > > > Secondly, management may be mandatory for P2PSIP operators. When > > P2PSIP is > > > > used for large-scale commercial operation, government or judiciary > > is likely > > > > to setup rules requesting operators to monitor sessions of users. > > Thus, it > > > > may be mandatory to control and record users' sessions to some > > extent. > > > > > > As far as I know, in Europe and US, regulation asks the providers to > > be > > > able to intercept communications when they are _terminated_ on > > telephony > > > networks. Maybe one day governments will mandate legal interception > > > also for communications both originating and terminating over the > > > Internet, but, once again, they will first have to ban encryption to > > > make it effective. > > > > > > > To draw a conclusion, I think management and accounting mechanisms > > need to > > > > be introduced into P2PSIP. > > > > > > > > I think my words focus too much on non-technical issues. Apologize > > in > > > > advance if I had gone beyond the task of this WG. :) > > > > > > Oh no, really, it's always entertaining to have this kind of > > discussions ;-) > > > > > > -- > > > Ciao, > > > Enrico > > > > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Apr 24 17:08:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSFC-0006dW-KX; Tue, 24 Apr 2007 17:08:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgSFA-0006XG-WA for p2psip@ietf.org; Tue, 24 Apr 2007 17:08:13 -0400 Received: from [63.110.43.12] (helo=mail.covergence.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgSF9-00072l-Oj for p2psip@ietf.org; Tue, 24 Apr 2007 17:08:12 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2007 17:07:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <0D1719326D64BD4E9F92A0C12023767801F01ADE@eserv.covergence.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lawful Intercept [was P2P in mobile phone market] Thread-Index: AceDVibw0/zvgtH8S8GPJXkOu3yy5gCZuEbgAD1cVlA= References: <003f01c78348$b39f8b50$9f0aa8c0@WangYao><4628BA81.1020300@telecomitalia.it><4d4304a00704200715g14625afcm63b246e77cc00a50@mail.gmail.com> From: "Rob Welbourn" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org In the US, the CALEA regulations address both PSTN-interconnected VoIP service providers and broadband service providers. Even if communications traffic is not directed to/from the PSTN, it can be subject to wiretapping simply by virtue of traveling over an Internet access pipe, in which case the legal responsibility falls to the ISP to perform the wiretapping. Note, however, that there is no obligation for the ISP to decrypt the traffic -- which it can't do in any event, if the traffic travels over a P2P overlay that the ISP doesn't control. Rob Welbourn -----Original Message----- From: colin.pons@kpn.com [mailto:colin.pons@kpn.com]=20 Sent: Tuesday, April 24, 2007 1:37 AM To: dbryan@sipeerior.com; enrico.marocco@telecomitalia.it Cc: p2psip@ietf.org Subject: RE: [P2PSIP] P2P in mobile phone market In the EU all calls could be subject to lawful intercept. PSTN and mobile telephony are obvious, but in many EU countries is obligatory to allow LI for VoIP. Also, ISPs are required to provide the necessary LI capbilities, delivering the IP Flow to a LEA. Colin Pons Senior Architect WSO Innovation Management -----Oorspronkelijk bericht----- Van: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Verzonden: vrijdag 20 april 2007 16:15 Aan: Enrico Marocco CC: p2psip@ietf.org Onderwerp: Re: [P2PSIP] P2P in mobile phone market In many countries the current rules require intercept of PSTN only, but several (including the US) have made it clear that all calls (even IP to IP) will eventually need to be interceptable (if that is a real word...). David _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 25 05:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdPy-00007W-7V; Wed, 25 Apr 2007 05:04:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgdPw-00007K-Ik for p2psip@ietf.org; Wed, 25 Apr 2007 05:04:04 -0400 Received: from node06.dns-hosting.info ([83.149.75.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgdPu-00071S-7t for p2psip@ietf.org; Wed, 25 Apr 2007 05:04:04 -0400 Received: from mit.xs4all.nl ([213.84.95.205]:49927 helo=[192.168.0.36]) by node06.dns-hosting.info with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HgdPp-0007RB-Uc; Wed, 25 Apr 2007 11:03:58 +0200 In-Reply-To: <811D385AE1CEBB42839C50DF0B0D38E003D35A47@sernt4.essex.ac.uk> References: <811D385AE1CEBB42839C50DF0B0D38E003D35A47@sernt4.essex.ac.uk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <96A9A946-A1EB-4538-8C8C-1DA493456C8E@ag-projects.com> Content-Transfer-Encoding: 7bit From: Adrian Georgescu Date: Wed, 25 Apr 2007 11:03:34 +0200 To: "Oredope, Adetola" X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 213.84.95.205 X-SA-Exim-Mail-From: ag@ag-projects.com X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on node06.dns-hosting.info X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Subject: Re: [P2PSIP] Presence in P2P-SIP X-SA-Exim-Version: 4.2.1 (built Sun, 03 Dec 2006 00:39:09 +0000) X-SA-Exim-Scanned: Yes (on node06.dns-hosting.info) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eyebeam - SIP UA with SIMPLE and XCAP support http://counterpath.com OpenSER - SIP SIMPLE Presence agent http://openser.org Xcap-lite - XCAP server http://www.ag-projects.com/downloads Regards, Adrian On Apr 13, 2007, at 12:43 PM, Oredope, Adetola wrote: > Hello, > > Do any one know of where I can find any information on Presence > services > using P2P-SIP (SIMPLE)? > Is there any one out there working on this? > > Regards, > > Tola > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Apr 25 16:46:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgoNY-0008Qe-DU; Wed, 25 Apr 2007 16:46:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgoNW-0008JU-SP for p2psip@ietf.org; Wed, 25 Apr 2007 16:46:18 -0400 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgoNV-0003US-Kl for p2psip@ietf.org; Wed, 25 Apr 2007 16:46:18 -0400 Received: by nz-out-0506.google.com with SMTP id z6so481288nzd for ; Wed, 25 Apr 2007 13:46:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BY4gBbgubCBHQcjNcj14/r9UZISqCGcXpY+zwW7B0fTYCOPWF+jo9HjPwfCTdU1q7HXhGPH/FEoqx/7p2NFO5M69d8EFtAN7vmz3Rh25koqC3B7SphJGlAcHJqfYDDJaUHo5f+ElLSQjqKGY44iwN8juxKlyPth8C7s9t4Dn3i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=HlNszxg8VXGhkHq7FV8U1f6hFWM5wjffzIovqntv41sfTuoO2WYxJlLzriZzdGOM6IMgffzXhgGbzx67WzYfM1rPIyjetdq+RBltbgxYh8nVjxOPVhzLOfyyYHdDJduXOJtSzB0g+U8MS9sJ7KCw5gugUOnMt8mgsdHKR/D+pB8= Received: by 10.114.182.1 with SMTP id e1mr320641waf.1177533976740; Wed, 25 Apr 2007 13:46:16 -0700 (PDT) Received: by 10.114.110.2 with HTTP; Wed, 25 Apr 2007 13:46:16 -0700 (PDT) Message-ID: <618e24240704251346p2cb12aa1i414e43191ce2bcda@mail.gmail.com> Date: Wed, 25 Apr 2007 22:46:16 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "Rob Welbourn" Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] In-Reply-To: <0D1719326D64BD4E9F92A0C12023767801F01ADE@eserv.covergence.com> MIME-Version: 1.0 References: <003f01c78348$b39f8b50$9f0aa8c0@WangYao> <4628BA81.1020300@telecomitalia.it> <4d4304a00704200715g14625afcm63b246e77cc00a50@mail.gmail.com> <0D1719326D64BD4E9F92A0C12023767801F01ADE@eserv.covergence.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0872383172==" Errors-To: p2psip-bounces@ietf.org --===============0872383172== Content-Type: multipart/alternative; boundary="----=_Part_65287_8899304.1177533976682" ------=_Part_65287_8899304.1177533976682 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, Are we discussing a service or just an underlying technology? Traditional telephony service (in Spain called STDP -something like 'public telephony service'-) is just a service independently from the used underlying technology. So it's a fact that all-like-telephony VoIP _services_ will have to address interception and _emergency calls routing_ issues, but I think it should be addressed by operators in order to include p2psip-based services to their portfolio. Sorry if it was already discussed, Thank you, Victor Pascual --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip:victor.pascual@iptel.org fon user: 223364 ------=_Part_65287_8899304.1177533976682 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all,
Are we discussing a service or just an underlying technology?=
Traditional telephony service (in Spain called STDP -something like = 9;public telephony service'-) is just a service independently from the = used underlying technology.
So it's a fact that all-like-telephony VoIP _services_ will have to= address interception and _emergency calls routing_ issues, but I think it = should be addressed by operators in order to include p2psip-based services = to their portfolio.

Sorry if it was already discussed,

Thank you,
Victor Pasc= ual
--
Victor Pascual =C1vila

mail:victor.pascual.avila@gmail.com
sip: victor.pascual@iptel.org
fon user: 223364 ------=_Part_65287_8899304.1177533976682-- --===============0872383172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0872383172==-- From p2psip-bounces@ietf.org Wed Apr 25 19:35:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgr1D-0001OQ-7b; Wed, 25 Apr 2007 19:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgr1C-0001OL-11 for p2psip@ietf.org; Wed, 25 Apr 2007 19:35:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgr1A-0006bm-OY for p2psip@ietf.org; Wed, 25 Apr 2007 19:35:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HgqzA-0004jj-P6; Wed, 25 Apr 2007 18:33:21 -0500 From: "Brian Rosen" To: =?iso-8859-1?Q?'Victor_Pascual_=C1vila'?= , "'Rob Welbourn'" Subject: RE: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Wed, 25 Apr 2007 19:35:19 -0400 Message-ID: <033301c78792$65170190$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <618e24240704251346p2cb12aa1i414e43191ce2bcda@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceHeoFlIk+rpeu/QYCqLl4U90UFdQAFxhVA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just so we=92re clear: p2psip is unlikely to have any problems meeting emergency call requirements. The things that make p2psip different from regular sip don=92t impact emergency calls, especially in the IETF = emergency call work (ecrit). Legal Intercept is another matter. The differences in p2psip do = challenge LI regimes currently in place. As I said before, to the extent LI moves = to being a packet interception rather than a call interception regime, = p2psip will become just another packet stream. It is decidedly NOT just = another telephone call. Agree that it will always be a local carrier problem to meet local = emergency call and local legal intercept requirements. It is, of course, quite a challenge to define "local" on the Internet.=20 Brian ________________________________________ From: Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com]=20 Sent: Wednesday, April 25, 2007 4:46 PM To: Rob Welbourn Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Hello all, Are we discussing a service or just an underlying technology? Traditional telephony service (in Spain called STDP -something like = 'public telephony service'-) is just a service independently from the used underlying technology.=20 So it's a fact that all-like-telephony VoIP _services_ will have to = address interception and _emergency calls routing_ issues, but I think it should = be addressed by operators in order to include p2psip-based services to = their portfolio.=20 Sorry if it was already discussed, Thank you, Victor Pascual --=20 Victor Pascual =C1vila mail:victor.pascual.avila@gmail.com sip: victor.pascual@iptel.org fon user: 223364=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 26 11:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5qZ-0004pW-6a; Thu, 26 Apr 2007 11:25:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5qX-0004pR-T7 for p2psip@ietf.org; Thu, 26 Apr 2007 11:25:25 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5qV-00009O-LC for p2psip@ietf.org; Thu, 26 Apr 2007 11:25:25 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 2BD3014DDC26 for ; Thu, 26 Apr 2007 23:25:19 +0800 (CST) Message-ID: <000801c78817$193c0e20$a507740a@DELLWEI> From: "Wei Gengyu" To: References: <033301c78792$65170190$640fa8c0@cis.neustar.com> Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Thu, 26 Apr 2007 23:25:18 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0688100178==" Errors-To: p2psip-bounces@ietf.org --===============0688100178== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIGFsbCwgDQoNCkkgcHV0IGEgcXVlc3Rpb24gdGhhdCBpcyByZWxhdGVkIHRvIHRoZSBzdWJq ZWN0LiANCg0KU29tZSBjYXJyaWVycyBjb25jZXJuIGhvdyB0byBtb25pdG9yIGFuZCBtZWFzdXJl IHRoZSB0cmFmZmljIG9mIFAyUCBhcHBsaWNhdGlvbnMuDQpCdXQgY3VycmVudCBkZXBseWVkIG1l dGhvZCwgZ2VuZXJhbGx5LCBhcmUgYmFzZWQgb24gYW5hbHlzaXMgdHJhZmZpYyBwYXR0ZXJucywg DQpzb21ldGhpbmcgbGlrZSB0aGF0IGluIHRoZSBJbmZvY29tJzIwMDQgcGFwZXIgIlRyYW5zcG9y dCBMYXllciBJZGVudGlmaWNhdGlvbiBvZiBQMlAgVHJhZmZpYyIgYnkgVGhvbWFzIEsuIGV0LiBh bC4gDQoNCkZvciBzaW1wbGlmeWluZyB0aGUgbWVhc3VyZW1lbnQsIGl0IHNlZW1zIHJhdGlvbmFs IHRoYXQgYW4gZXhwbGljaXQgUDJQIGlkZW50aWZpZXIgaXMgZGVmaW5lZCBpbiB0cmFuc3BvcnQg bGF5ZXIgcHJvdG9jb2wgaGVhZGVyLiANCkFyZSB0aGVyZSBhbnl3b3JrcyBvciByZWNvbW1lbmRl ZCBzdGFuZGFyZHMgYWJvdXQgdGhpcy4NCkFyZSB0aGVyZSBhbnkgb3RoZXIgbWV0aG9kcyAoUkZD IG9yIGRyYWZ0IHJmY3MpIHRvIGlkZW50aWZ5IFAyUCB0cmFuc3BvcnRhdGlvbi4gDQoNCkdlbmd5 dSA= --===============0688100178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0688100178==-- From p2psip-bounces@ietf.org Thu Apr 26 11:36:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh616-0003UD-Rr; Thu, 26 Apr 2007 11:36:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh616-0003U4-67 for p2psip@ietf.org; Thu, 26 Apr 2007 11:36:20 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh614-0001fQ-7J for p2psip@ietf.org; Thu, 26 Apr 2007 11:36:20 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:36:17 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:36:16 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 17:36:15 +0200 Message-ID: <4630C715.6090208@telecomitalia.it> Date: Thu, 26 Apr 2007 17:36:53 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Wei Gengyu Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <000801c78817$193c0e20$a507740a@DELLWEI> In-Reply-To: <000801c78817$193c0e20$a507740a@DELLWEI> X-Enigmail-Version: 0.94.2.0 X-OriginalArrivalTime: 26 Apr 2007 15:36:15.0857 (UTC) FILETIME=[A09CC610:01C78818] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0157457595==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0157457595== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000505050408040808090402" This is a cryptographically signed message in MIME format. --------------ms000505050408040808090402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wei Gengyu wrote: > I put a question that is related to the subject. > > Some carriers concern how to monitor and measure the traffic of P2P applications. > But current deplyed method, generally, are based on analysis traffic patterns, > something like that in the Infocom'2004 paper "Transport Layer Identification of P2P Traffic" by Thomas K. et. al. > > For simplifying the measurement, it seems rational that an explicit P2P identifier is defined in transport layer protocol header. > Are there anyworks or recommended standards about this. > Are there any other methods (RFC or draft rfcs) to identify P2P transportation. In theory it would be great to have one defined and adopted. In practice, I'm afraid if it existed, it would be an April's fool (see RFC 3514) ;-) -- Ciao, Enrico --------------ms000505050408040808090402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNDI2MTUzNjUzWjAjBgkqhkiG9w0BCQQxFgQUAsayO1W/ RciWDBwpLLxjj8lYDrgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAFspMF+u0Oxr4uj8m3vbIRR0ITpsxjEf2pfiJ9VDd0xhlB7J00G5EYdu aeIKff/YMFdnC4PaQmQw7xDZrjNC14PJHrY4xDJq48GKISgbxwg8w+6pqp3tNne3nowqb7wP R9vrBsddgHhfAxyq0I46U+5n0usPnyx12LSImTzuUzL70DuXm8GOiTriTASEZk4uherj34yA M2hkW1HA1fm0mCBjLHfp5L/e3hXKWdkNl/oVHFsE8kPIpQXSM+nci40aa4ZoGhXDc0kOCv2t NxV/aI3uv6ZB6kmxK2STvC806pOSRVUme55WGp4wzifs5zOsQhiH0JNnVLRXGPo8A3lc6JcA AAAAAAA= --------------ms000505050408040808090402-- --===============0157457595== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0157457595==-- From p2psip-bounces@ietf.org Thu Apr 26 11:40:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh64s-00049f-5y; Thu, 26 Apr 2007 11:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh64q-00048M-RW for p2psip@ietf.org; Thu, 26 Apr 2007 11:40:12 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh64p-0002Ef-Gn for p2psip@ietf.org; Thu, 26 Apr 2007 11:40:12 -0400 Received: by ug-out-1314.google.com with SMTP id 72so517693ugd for ; Thu, 26 Apr 2007 08:40:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uowileFnDfav2FvMu4U64e9GkpaOFNIrqnu/5k8fL/nMJVSz7yErNTMtQ0rVJFlB0w87wG0Nb27/3g6kUynkBKo722RqsHF1qfD0ERotw+JUn/3EcjPaKpDCRmdxD/2tWMnITzpohcm6jHcXnV4d0BLQ9BUu1SmagFByp/zgoAA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=b419SusYscOSpeMc6jMyCpnzWbDcNpPEeKrXtofaV8b5Zt4cNovZech5NnbJ5Sn4IAWZPdVWistvdzoC8OnM58bXOjUGiRVd42kcNKms2RhJa/qcMPy4zlk35zn5gdut/IiOlLje8lOR0g8r1oQjECdDx0HRfFro+lREaj1mPtc= Received: by 10.82.169.4 with SMTP id r4mr3534380bue.1177602009834; Thu, 26 Apr 2007 08:40:09 -0700 (PDT) Received: by 10.82.127.17 with HTTP; Thu, 26 Apr 2007 08:40:09 -0700 (PDT) Message-ID: <4d4304a00704260840r2767856dled3d4c077c85c315@mail.gmail.com> Date: Thu, 26 Apr 2007 11:40:09 -0400 From: "David A. Bryan" To: "Wei Gengyu" Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] In-Reply-To: <000801c78817$193c0e20$a507740a@DELLWEI> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <000801c78817$193c0e20$a507740a@DELLWEI> X-Google-Sender-Auth: 353d833d7c56b54c X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Personally, I think such an effort isn't needed and in fact doesn't really make sense. The assumption of that would be that somehow P2P traffic is treated differently than client server. P2P and Client Server are mechanisms. Interest in this idea arose because the earliest use of P2P was filesharing, which many administrators wanted to restrict from their network. For that particular case, it could make some sense. As time goes on, however, P2P will be a mechanism, like client server, that is used for many types of applications. Today, a flag of "this is client-server" would make no sense -- treating web traffic, VoIP, SSH and NFS the same because they all happen to be client-server, for example. As P2P is used as a technique for various types of applications, a flag saying it is P2P will evolve to become just as meaningless. My 2 cents, David On 4/26/07, Wei Gengyu wrote: > Hi, all, > > I put a question that is related to the subject. > > Some carriers concern how to monitor and measure the traffic of P2P applications. > But current deplyed method, generally, are based on analysis traffic patterns, > something like that in the Infocom'2004 paper "Transport Layer Identification of P2P Traffic" by Thomas K. et. al. > > For simplifying the measurement, it seems rational that an explicit P2P identifier is defined in transport layer protocol header. > Are there anyworks or recommended standards about this. > Are there any other methods (RFC or draft rfcs) to identify P2P transportation. > > Gengyu > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 26 11:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh65r-0004n1-MG; Thu, 26 Apr 2007 11:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh65q-0004j6-Lj for p2psip@ietf.org; Thu, 26 Apr 2007 11:41:14 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh65p-0002Pz-EV for p2psip@ietf.org; Thu, 26 Apr 2007 11:41:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hh65f-0002pV-NS; Thu, 26 Apr 2007 10:41:03 -0500 From: "Brian Rosen" To: "'Wei Gengyu'" , Subject: RE: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Thu, 26 Apr 2007 11:41:09 -0400 Message-ID: <04ca01c78819$517d6200$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000801c78817$193c0e20$a507740a@DELLWEI> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIFxwTfb8J/a+uTuWxzJaKxWUlyAAAYjuw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > For simplifying the measurement, it seems rational that an explicit P2P > identifier is defined in transport layer protocol header. Every application protocol has a recognizable header, but usually we use the port number to know to look for a particular application protocol. Of course, we sometimes use a protocol like HTTP as a transport protocol for multiple applications protocols, and it can be hard to see the difference between one use of HTTP and another. We don't know yet if p2psip will need a separate port number from sip. If we don't, it may be hard to recognize p2psip from regular sip. > Are there anyworks or recommended standards about this. No > Are there any other methods (RFC or draft rfcs) to identify P2P > transportation. No _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 26 19:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDEk-0005U3-4m; Thu, 26 Apr 2007 19:18:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDEi-0005Tv-IU for p2psip@ietf.org; Thu, 26 Apr 2007 19:18:52 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-03.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhDEe-0006Bh-BP for p2psip@ietf.org; Thu, 26 Apr 2007 19:18:52 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-03.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HhDEd-0006Lp-Bp; Thu, 26 Apr 2007 19:18:47 -0400 In-Reply-To: <4d4304a00704260840r2767856dled3d4c077c85c315@mail.gmail.com> References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <000801c78817$193c0e20$a507740a@DELLWEI> <4d4304a00704260840r2767856dled3d4c077c85c315@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Thu, 26 Apr 2007 19:18:50 -0400 To: David A. Bryan X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 26-Apr-07, at 11:40 , David A. Bryan wrote: > Personally, I think such an effort isn't needed and in fact doesn't > really make sense. > > The assumption of that would be that somehow P2P traffic is treated > differently than client server. P2P and Client Server are mechanisms. > Interest in this idea arose because the earliest use of P2P was > filesharing, which many administrators wanted to restrict from their > network. For that particular case, it could make some sense. Yup. File-sharing programs like UUCP ("Unix-to-Unix Copy") from the late 1970s and a protocol for e-mail called SMTP (RFC 821) published in 1982 in which e-mail addresses originally had to specify the hop-by-hop path from the sending machine to the receiving machine. P2P technology has been around for a while ... - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Apr 26 19:59:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDsL-0005Zl-OJ; Thu, 26 Apr 2007 19:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhDsJ-0005Zd-Vu for p2psip@ietf.org; Thu, 26 Apr 2007 19:59:47 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhDsI-0004Dz-Pa for p2psip@ietf.org; Thu, 26 Apr 2007 19:59:47 -0400 Received: by wr-out-0506.google.com with SMTP id 71so775624wri for ; Thu, 26 Apr 2007 16:59:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=Y32Gf5ecStfLVh0mrkaiv7+ufhrrgHj1ypMrEAhogVJKCwEypqKjLeWkbmlcnrFzbOqiIoRSdhDlirdF4wdgC/o23fQUu1C/zwP8f0xA2QhTNXsBe4kqz4F74yDgA7+wSv+vQjWlIzc44Kw9rWHMLc8QufX+j/RiQGuC++jZEpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=VVWDfSD7pKSttXscgrvmcTRoDlYUN/iiKMA6b9uLSk0rwhUPP/z+KoZRZOLdl2p1yCjLCIF6dqKR4fFkS/K/EKhTgIsMQ5UVU1qGaSB6yC+JYbxS7X8TUWXAsk/cPTKaB/BH1FkxGoEc41B9JTYN2RIoNfcr8nPo/GVI+gyc0Yk= Received: by 10.114.106.1 with SMTP id e1mr786717wac.1177631986095; Thu, 26 Apr 2007 16:59:46 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Thu, 26 Apr 2007 16:59:46 -0700 (PDT) Message-ID: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> Date: Thu, 26 Apr 2007 19:59:46 -0400 From: "Medhavi Bhatia" To: p2psip@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 8b9b9b5198caa9f8 X-Spam-Score: 1.3 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1657130654==" Errors-To: p2psip-bounces@ietf.org --===============1657130654== Content-Type: multipart/alternative; boundary="----=_Part_183225_17140222.1177631986061" ------=_Part_183225_17140222.1177631986061 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I was a little confused by the wording in the draft. It started by saying that it doesn't make any assumptions about the p2p protocol (sip based or other), but then states the OPTIONS and REGISTER methods for bootstrap peers to join the bootstrap server. Wouldn't these operations be part of the p2p protocol draft? ------=_Part_183225_17140222.1177631986061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I was a little confused by the wording in the draft. It started by saying that it doesn't make any assumptions about the p2p protocol (sip based or other), but then states the OPTIONS and REGISTER methods for bootstrap peers to join the bootstrap server. Wouldn't these operations be part of the p2p protocol draft? ------=_Part_183225_17140222.1177631986061-- --===============1657130654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1657130654==-- From p2psip-bounces@ietf.org Thu Apr 26 23:06:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGmy-0006kD-Rs; Thu, 26 Apr 2007 23:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGmx-0006fp-4w for p2psip@ietf.org; Thu, 26 Apr 2007 23:06:27 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhGmu-0002Xn-5R for p2psip@ietf.org; Thu, 26 Apr 2007 23:06:27 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 6320E44A42B for ; Fri, 27 Apr 2007 11:06:15 +0800 (CST) Message-ID: <006801c78879$07356a70$a507740a@DELLWEI> From: "Wei Gengyu" To: Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Fri, 27 Apr 2007 11:06:15 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1884058120==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1884058120== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C788BC.13130030" This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C788BC.13130030 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpGaXJzdCwgdGhhbmtzIGFsbCBmb3IgcmVwbHlpbmcgbXkgcXVldGlvbi4NCg0KSSB0cnkgdG8g Z2l2ZSBzb21lIGV4cGxhbmF0aW9uczoNCg0KUDJQIHRyYWZmaWNzIGFyZSBpbnRlbmRlZCB0byB0 cmVhdCBkaWZmZXJlbnRseSBoZXJlIGJ5IGNhcnJpZXJzIG5vIG1hdHRlciB3aGF0IHRvIGRvLg0K VGhlIFAyUCB0cmFmZmljIGlkZW50aWZpZWQgYnkgcG9ydCBudW1iZXIgbWF5IG5vdCB3b3JrIGFz IGN1cnJlbnQgdmVyc2lvbiBvZiBCVCB1c2VzIHJhbmRvbWx5IHNlbGVjdGVkIHBvcnQgbnVtYmVy Lg0KU28gbW9uaXRvciBhbmQgbWVhc3VyZW1lbnRzIG9mIFAyUCB0cmFmZmljcyBpbiBiYWNrYm9u ZSBuZXR3b3JrcyBhcmUgZGlmZmljdWx0Lg0KDQpTb21lb25lIHN1Z2dlc3RlZCB0byBzdHVkeSBw cm90b2NvbCBjb250cm9sIHByb2Nlc3MgYXQgZW5kcG9pbnQsDQphbmQgb3RoZXJzIHVzZSB0aGUg YW5hbHlzaXMgdG9vbCBvZiB0cmFmZmljIHBhdGVybi4gDQpUaGVzZSBtZWNoYW5pc21zIGFyZSBu b3Qgc28gZmFzdCBpbiB0ZXJtcyBvZiByZWFsIHRpbWUgY29udHJvbC4gDQoNCkFuIGVmZmljaWVu dCBQMlAgdHJhZmZpYyBtb25pdG9yIGFuZCBtZWFzdXJlbWVudCBtZXRob2QgaXMgcmVxdWlyZWQu IEhvdyB0byBkZWZpbmUgb3IgdG8gaW52ZW50Pw0KDQpJIGRvIG5vdCBhZ3JlZSB0aGF0IG5vIGlk IG9mIHAycCBpcyBiZWNhc3VzZSBvZiBubyBpZCBvZiBjbGllbnQtc2VydmVyLg0KQXMgeW91IGtu b3csIHRoZXJlIGlzIG5vIHRyb3VibGUgdG8gbW9uaXRvciB0cmFmZmljIGluIGNsaWVudC9zZXJ2 ZXIgbW9kZWwuIA0KQnV0IHRoYXQgbWVjaGFuaXNtIGRvZXMgbm90IHdvcmsgZm9yIFAyUCBtb2Rl bC4NCg0KQXMgdGhlcmUgaGF2ZSBiZWVuIGNvbnNpZGVyYXRpb25zIG9mIGFkZGluZyBjb250cm9s IHBsYW5lIGluIEludGVybmV0LCBhbmQgUDJQU0lQIGlzIGFib3V0IGNvbnRyb2wgbWVzc2FnZXMs IA0Kc28sIHRyYWZmaWMgY2xhc3NpZmljYXRpb25zLCBtb25pdG9yLCBhbmQgbWVhc3VyZW1lbnQg bWlnaHQgYmUgY29uc2lkZXJlZCBpbiBjb250cm9sIG1lc3NhZ2VzLg0KQW5kIHRoaXMgcHJvYmxl bSBpcyBhbHNvIHJlbGF0ZWQgdG8gTEkuDQoNCkkgc3RpbGwgd2FudCB0byBrbm93IHdoYXQgbWFr ZXMgdGhlIHByb2JsZW0gc29sdmVkLg0KSG93ZXZlciwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRo aXMgcHJvYmxlbSBzaG91bGQgYmUgZGlzc2N1c3NlZCBpbiB0aGlzIGdyb3VwIG9yIGluIHRoaXMg c3RhZ2UuDQoNClRoYW5rIHlvdSBpbiBhZHZhbmNlLg0KDQpHZW5neXUg ------=_NextPart_000_0063_01C788BC.13130030 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMwNTkiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5GaXJzdCwgdGhhbmtzIGFsbCBmb3IgcmVwbHlpbmcgbXkg cXVldGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHRyeSB0byBnaXZlIHNvbWUgZXhwbGFuYXRpb25zOjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgc2l6ZT0yPlAyUCB0cmFmZmljcyBhcmUgaW50ZW5kZWQgdG8gdHJlYXQgZGlmZmVyZW50 bHkgaGVyZSANCmJ5Jm5ic3A7Y2FycmllcnMgbm8gbWF0dGVyIHdoYXQgdG8gZG8uPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhlIFAyUCB0cmFmZmljIGlkZW50aWZpZWQgYnkgcG9y dCBudW1iZXIgbWF5IG5vdCB3b3JrIGFzIA0KY3VycmVudCB2ZXJzaW9uIG9mIEJUIHVzZXMgcmFu ZG9tbHkgc2VsZWN0ZWQgcG9ydCBudW1iZXIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+U28gbW9uaXRvciBhbmQgbWVhc3VyZW1lbnRzIG9mIFAyUCB0cmFmZmljcyBpbiBiYWNrYm9u ZSANCm5ldHdvcmtzIGFyZSBkaWZmaWN1bHQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U29tZW9uZSBzdWdnZXN0 ZWQgdG8gc3R1ZHkgcHJvdG9jb2wgY29udHJvbCBwcm9jZXNzIGF0IA0KZW5kcG9pbnQsPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YW5kIG90aGVycyB1c2UgdGhlIGFuYWx5c2lzIHRv b2wgb2YgdHJhZmZpYyBwYXRlcm4uIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ VGhlc2UgbWVjaGFuaXNtcyBhcmUgbm90IHNvJm5ic3A7ZmFzdCBpbiB0ZXJtcyBvZiZuYnNwO3Jl YWwgDQp0aW1lIGNvbnRyb2wuIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkFuIGVmZmljaWVudCBQMlAgdHJhZmZp YyBtb25pdG9yIGFuZCBtZWFzdXJlbWVudCBtZXRob2QgaXMgDQpyZXF1aXJlZC4gPC9GT05UPjxG T05UIHNpemU9Mj5Ib3cgdG8gZGVmaW5lIG9yIHRvIGludmVudD88L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGRv IG5vdCBhZ3JlZSB0aGF0IG5vIGlkIG9mIHAycCBpcyBiZWNhc3VzZSBvZiBubyBpZCBvZiANCmNs aWVudC1zZXJ2ZXIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QXMgeW91IGtub3cs IHRoZXJlIGlzIG5vIHRyb3VibGUmbmJzcDt0byZuYnNwO21vbml0b3IgdHJhZmZpYyANCmluIGNs aWVudC9zZXJ2ZXImbmJzcDttb2RlbC4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ QnV0IHRoYXQgbWVjaGFuaXNtIGRvZXMgbm90IHdvcmsgZm9yIFAyUCBtb2RlbC48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5BcyB0aGVyZSBoYXZlIGJlZW4gY29uc2lkZXJhdGlvbnMmbmJzcDtvZiBhZGRpbmcgY29u dHJvbCBwbGFuZSANCmluIEludGVybmV0LCA8L0ZPTlQ+PEZPTlQgc2l6ZT0yPmFuZCBQMlBTSVAg aXMgYWJvdXQgY29udHJvbCANCm1lc3NhZ2VzLCZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPnNvLCB0cmFmZmljIGNsYXNzaWZpY2F0aW9ucywgbW9uaXRvciwgYW5kIA0KbWVh c3VyZW1lbnQmbmJzcDttaWdodCBiZSBjb25zaWRlcmVkIGluIGNvbnRyb2wgbWVzc2FnZXMuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+QW5kIHRoaXMgcHJvYmxlbSBpcyBhbHNvIHJl bGF0ZWQgdG8gTEkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SSBzdGlsbCB3YW50IHRvIGtub3cgd2hhdCBtYWtl cyB0aGUgcHJvYmxlbSANCnNvbHZlZC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5I b3dldmVyLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhpcyBwcm9ibGVtIHNob3VsZCANCmJlJm5i c3A7ZGlzc2N1c3NlZCBpbiZuYnNwO3RoaXMmbmJzcDtncm91cCBvciBpbiZuYnNwO3RoaXMgc3Rh Z2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91IGluIGFkdmFuY2UuPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+R2Vu Z3l1PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0063_01C788BC.13130030-- --===============1884058120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1884058120==-- From p2psip-bounces@ietf.org Thu Apr 26 23:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhHG2-0003Ud-4k; Thu, 26 Apr 2007 23:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhHG0-0003OB-Kj for p2psip@ietf.org; Thu, 26 Apr 2007 23:36:28 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhHFz-0002ja-DN for p2psip@ietf.org; Thu, 26 Apr 2007 23:36:28 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH500GTJ0OQU5@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 26 Apr 2007 20:36:27 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH50003C0OO8Z@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 26 Apr 2007 20:36:26 -0700 (PDT) Date: Thu, 26 Apr 2007 22:34:45 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] To: p2psip@ietf.org Message-id: <1a3201c7887d$00479810$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <033301c78792$65170190$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I like Brian's take on this topic. Can we address lawful intercept in the Requirements and (possibly) the Concepts and Terminology drafts, so we can be sure we agree and (one would hope) avoid discussing the topic again in the future? Thanks, Spencer From: "Brian Rosen" Sent: Wednesday, April 25, 2007 6:35 PM Subject: RE: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Just so we're clear: p2psip is unlikely to have any problems meeting emergency call requirements. The things that make p2psip different from regular sip don't impact emergency calls, especially in the IETF emergency call work (ecrit). Legal Intercept is another matter. The differences in p2psip do challenge LI regimes currently in place. As I said before, to the extent LI moves to being a packet interception rather than a call interception regime, p2psip will become just another packet stream. It is decidedly NOT just another telephone call. Agree that it will always be a local carrier problem to meet local emergency call and local legal intercept requirements. It is, of course, quite a challenge to define "local" on the Internet. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 27 02:07:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJcA-0001o4-GN; Fri, 27 Apr 2007 02:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJc9-0001nx-M9 for p2psip@ietf.org; Fri, 27 Apr 2007 02:07:29 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJc8-0001m3-DY for p2psip@ietf.org; Fri, 27 Apr 2007 02:07:29 -0400 Received: from [192.168.2.103] (rcdn4-dmznat-gw1-nat-27.cisco.com [12.5.186.27]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id l3R5EO6G025338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Apr 2007 00:14:25 -0500 In-Reply-To: <1a3201c7887d$00479810$ad600240@china.huawei.com> References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <1a3201c7887d$00479810$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Fri, 27 Apr 2007 01:07:15 -0500 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Apr 26, 2007, at 10:34 PM, Spencer Dawkins wrote: > I like Brian's take on this topic. Can we address lawful intercept > in the Requirements and (possibly) the Concepts and Terminology > drafts, so we can be sure we agree and (one would hope) avoid > discussing the topic again in the future? No. We shall make no considerations for lawful intercept in protocol design. It's just Out of Scope. We don't need to say anything else. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 27 10:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRAn-0003SR-3q; Fri, 27 Apr 2007 10:11:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRAl-0003SI-EG for p2psip@ietf.org; Fri, 27 Apr 2007 10:11:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRAk-0005Tc-1t for p2psip@ietf.org; Fri, 27 Apr 2007 10:11:43 -0400 Received: by ug-out-1314.google.com with SMTP id 72so666628ugd for ; Fri, 27 Apr 2007 07:11:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=qNhmNm+D4hEbtK2BPdor68LOjrFFI/BZXiR4Q4fm3iNKxhQpa1EtLi1OBG3mAV+QbSQv2mjOF1n2eNJz3larHPttxXMuc1KwBU1E/+FmtulQsj7v3SdWA8rQ8g4CkHakYE2wc5gShNKk+l/ayV3zIMdrwRBCoOGfOtb7i+J1DD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=eZXKy4ViMHdFQJ8jpOLjXSrpSrwkENYPR7X8LPpJB7mKE+7WpvwqLwB4WxG54sUZgqGVVQX7Lx4fvY9RJw+OdOTNQAK9fHkZbcfHNJasnRWdYln8OL1ltiZ5mdzr5+hY9h0ccrCfjUHgc8AZOX3Q34kSpAoisW9J+MBzLCUPzCs= Received: by 10.82.120.14 with SMTP id s14mr5834300buc.1177683101118; Fri, 27 Apr 2007 07:11:41 -0700 (PDT) Received: by 10.82.127.17 with HTTP; Fri, 27 Apr 2007 07:11:40 -0700 (PDT) Message-ID: <4d4304a00704270711s192427f8q1d51964759408127@mail.gmail.com> Date: Fri, 27 Apr 2007 10:11:40 -0400 From: "David A. Bryan" To: "Wei Gengyu" Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] In-Reply-To: <006801c78879$07356a70$a507740a@DELLWEI> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <006801c78879$07356a70$a507740a@DELLWEI> X-Google-Sender-Auth: 9cd746538dcc7bc7 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Before I start, this would clearly be out of our WG scope, but still an interesting discussion. I think I need to know more about what you think this could be used for...I don't see any use for it. What would you do with this bit (unless to mark traffic that isn't from a "blessed" provider?) Why should the P2P traffic be treated differently because it is P2P? P2P traffic may be highly desirable, even to a service provider, if they are using P2P as their transport mechanism. Certainly realtime P2P media traffic, shouldn't be treated the same as a filesharing traffic just because they are both P2P. The media traffic might even be P2P, but provided by the service provider or network owner, so you can't even use this bit to prioritize traffic in a walled garden. Would RTP that flows directly between endpoints (as media does today in conventional SIP) be marked this way? Is BGP P2P? UUCP? SMTP? I think it is very hard to say what is really P2P, as well. If the bit really means a way to mark "traffic I can't bill for", rather than "P2P", I can see why a carrier might want it, but the IETF isn't likely to be the best place to propose that, since an open Internet is the guiding principle here. David On 4/26/07, Wei Gengyu wrote: > > > > First, thanks all for replying my quetion. > > I try to give some explanations: > > P2P traffics are intended to treat differently here by carriers no matter > what to do. > The P2P traffic identified by port number may not work as current version of > BT uses randomly selected port number. > So monitor and measurements of P2P traffics in backbone networks are > difficult. > > Someone suggested to study protocol control process at endpoint, > and others use the analysis tool of traffic patern. > These mechanisms are not so fast in terms of real time control. > > An efficient P2P traffic monitor and measurement method is required. How to > define or to invent? > > I do not agree that no id of p2p is becasuse of no id of client-server. > As you know, there is no trouble to monitor traffic in client/server model. > But that mechanism does not work for P2P model. > > As there have been considerations of adding control plane in Internet, and > P2PSIP is about control messages, > so, traffic classifications, monitor, and measurement might be considered in > control messages. > And this problem is also related to LI. > > I still want to know what makes the problem solved. > However, I am not sure whether this problem should be disscussed in this > group or in this stage. > > Thank you in advance. > > Gengyu > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 27 10:56:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRrs-0005Rf-67; Fri, 27 Apr 2007 10:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRrq-0005Mx-CJ for p2psip@ietf.org; Fri, 27 Apr 2007 10:56:14 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhRpu-0003Nb-IH for p2psip@ietf.org; Fri, 27 Apr 2007 10:54:14 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Apr 2007 07:54:13 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3RErZD1004062; Fri, 27 Apr 2007 07:53:36 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3REsB0c022551; Fri, 27 Apr 2007 07:54:11 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 07:54:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Fri, 27 Apr 2007 07:54:03 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22757690@namail5.corp.adobe.com> In-Reply-To: <1a3201c7887d$00479810$ad600240@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Thread-Index: AceIfUm2oDnMxyLYSVOCPif08qiSNgAXVjyQ References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <1a3201c7887d$00479810$ad600240@china.huawei.com> From: "Henry Sinnreich" To: "Spencer Dawkins" , X-OriginalArrivalTime: 27 Apr 2007 14:54:10.0530 (UTC) FILETIME=[E9D03420:01C788DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Can we address lawful intercept in the Requirements I am not sure there is space to dedicate to all PSTN-style items that don't make sense on the Internet.=20 For example: If we discuss why marking p2p, then also which type of p2p exactly does it apply, etc. What about QoS? (Remember it's a DOS attack on the competition's VoIP) What class of QoS? What's the definition of QoS classes? :-) How does Skype work without QoS? (Woops!) What about service definitions recently discussed ad nauseam recently here on a list? I suggest some references to the architectural principles of the Internet would be just adequate. And to specify that P2P is for broadband. What do you think? -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Thursday, April 26, 2007 10:35 PM To: p2psip@ietf.org Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] I like Brian's take on this topic. Can we address lawful intercept in the=20 Requirements and (possibly) the Concepts and Terminology drafts, so we can=20 be sure we agree and (one would hope) avoid discussing the topic again in=20 the future? Thanks, Spencer From: "Brian Rosen" Sent: Wednesday, April 25, 2007 6:35 PM Subject: RE: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Just so we're clear: p2psip is unlikely to have any problems meeting emergency call requirements. The things that make p2psip different from regular sip don't impact emergency calls, especially in the IETF emergency call work (ecrit). Legal Intercept is another matter. The differences in p2psip do challenge LI regimes currently in place. As I said before, to the extent LI moves to being a packet interception rather than a call interception regime, p2psip will become just another packet stream. It is decidedly NOT just another telephone call. Agree that it will always be a local carrier problem to meet local emergency call and local legal intercept requirements. It is, of course, quite a challenge to define "local" on the Internet. Brian=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 27 13:34:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUKh-0001g7-O3; Fri, 27 Apr 2007 13:34:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUKg-0001fy-Er for p2psip@ietf.org; Fri, 27 Apr 2007 13:34:10 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUKf-0001mS-6i for p2psip@ietf.org; Fri, 27 Apr 2007 13:34:10 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JH60046M3GWZF@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 27 Apr 2007 10:34:08 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JH6006TL3GU5U@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 27 Apr 2007 10:34:08 -0700 (PDT) Date: Fri, 27 Apr 2007 12:32:44 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] To: p2psip@ietf.org Message-id: <004501c788f2$11533f40$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <1a3201c7887d$00479810$ad600240@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D22757690@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Based on discussions with Dean, I'm not making my suggestion clear. I'm not suggesting that we discuss all PSTN concepts, only that (based on RFC 2804) we know what the answer for lawful intercept is, for P2PSIP, and that it might be helpful to write "this is out of scope" someplace where people would see it. Thanks, Spencer From: "Henry Sinnreich" > Can we address lawful intercept in the Requirements I am not sure there is space to dedicate to all PSTN-style items that don't make sense on the Internet. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Apr 27 14:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVNa-0008Qc-Ny; Fri, 27 Apr 2007 14:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhVNZ-0008QX-MZ for p2psip@ietf.org; Fri, 27 Apr 2007 14:41:13 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhVNY-0001Fu-Ap for p2psip@ietf.org; Fri, 27 Apr 2007 14:41:13 -0400 Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Apr 2007 11:41:10 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l3RIf5Sd029411; Fri, 27 Apr 2007 11:41:09 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l3RIex0i026658; Fri, 27 Apr 2007 11:41:04 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:41:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Fri, 27 Apr 2007 11:40:50 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22757768@namail5.corp.adobe.com> In-Reply-To: <004501c788f2$11533f40$ad600240@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Thread-Index: AceI8ktBxRwMpdc3QYKnjs04UpnoBQACS2Aw References: <033301c78792$65170190$640fa8c0@cis.neustar.com><1a3201c7887d$00479810$ad600240@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D22757690@namail5.corp.adobe.com> <004501c788f2$11533f40$ad600240@china.huawei.com> From: "Henry Sinnreich" To: "Spencer Dawkins" , X-OriginalArrivalTime: 27 Apr 2007 18:41:00.0379 (UTC) FILETIME=[99EA5AB0:01C788FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yes, you are right! > it might be helpful to write "this is out of scope" someplace where=20 > people would see it. Henry -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Friday, April 27, 2007 12:33 PM To: p2psip@ietf.org Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Based on discussions with Dean, I'm not making my suggestion clear. I'm not suggesting that we discuss all PSTN concepts, only that (based on=20 RFC 2804) we know what the answer for lawful intercept is, for P2PSIP, and=20 that it might be helpful to write "this is out of scope" someplace where people would see it. Thanks, Spencer From: "Henry Sinnreich" > Can we address lawful intercept in the Requirements I am not sure there is space to dedicate to all PSTN-style items that don't make sense on the Internet. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 29 00:36:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi19F-00042T-QG; Sun, 29 Apr 2007 00:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi19E-00042O-UY for p2psip@ietf.org; Sun, 29 Apr 2007 00:36:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi19D-0002Q1-Mk for p2psip@ietf.org; Sun, 29 Apr 2007 00:36:32 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 28 Apr 2007 21:36:31 -0700 X-IronPort-AV: i="4.14,465,1170662400"; d="scan'208"; a="416746762:sNHT42164220" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l3T4aV3Q004992 for ; Sat, 28 Apr 2007 21:36:31 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id l3T4aUA9026886 for ; Sun, 29 Apr 2007 04:36:30 GMT In-Reply-To: <1a3201c7887d$00479810$ad600240@china.huawei.com> References: <033301c78792$65170190$640fa8c0@cis.neustar.com> <1a3201c7887d$00479810$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6E5BCA31-45A8-4325-B383-3F0C5CB6E87D@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Sat, 28 Apr 2007 21:35:55 -0700 To: P2PSIP WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=114; t=1177821391; x=1178685391; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Lawful=20Intercept=20[was=20P2P=20in=20mob ile=20phone=20market] |Sender:=20; bh=y/IVs1XryoNtbAAg3Gp3gUxou0oXB4ixWISflk+WFv8=; b=HzpI+QK2TBSY6oYmiuZBIeSJADjOa56Tu8vk6nzi0qAM0uNeiDuH4uzcydQzep8YTDZ5fWK1 XDWC0A0ykZmL9YRUTp8W9Xi060ISA34u9pdwnI/sdG/SIgmlktUGDkCo; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Keep in mind anything we do here would have to be consistent with RFC 2804. Cullen - with my AD hat on. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 29 01:14:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi1kI-0000ln-Po; Sun, 29 Apr 2007 01:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hi1kH-0000h1-5C for p2psip@ietf.org; Sun, 29 Apr 2007 01:14:49 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hi1kE-0003v2-G7 for p2psip@ietf.org; Sun, 29 Apr 2007 01:14:49 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 9A99311DB550 for ; Sun, 29 Apr 2007 13:14:43 +0800 (CST) Message-ID: <002001c78a1d$4c2c3a00$a507740a@DELLWEI> From: "Wei Gengyu" To: "P2PSIP WG" References: <033301c78792$65170190$640fa8c0@cis.neustar.com><1a3201c7887d$00479810$ad600240@china.huawei.com> <6E5BCA31-45A8-4325-B383-3F0C5CB6E87D@cisco.com> Subject: Re: [P2PSIP] Lawful Intercept [was P2P in mobile phone market] Date: Sun, 29 Apr 2007 13:14:43 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966195983==" Errors-To: p2psip-bounces@ietf.org --===============0966195983== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSBhZ3JlZSBkaXNjdXNzaW9ucyBpbiB0aGlzIGdyb3VwIHNob3VsZCBiZSB3aXRoaW4gdGhlIHNj b3BlIG9mIHN1YmplY3RzIGRlZmluZWQgYnkgdGhlIFdHLg0KDQpCdXQgc29tZSBmYWN0IHdlIG11 c2sga25vdywgDQpMSSBpcyBub3QgYSBjYXJyaWVyLXNwZWNpZmljLCBvciBjb250cnkgc3BlY2lm aWMgZmVhdHVyZSwgaXQgd2FzIGRlZmluZWQgYnkgQ0NJVFQsIG5vdyBJVFUtVC4NCjNHUFAgYWxz byBkZWZpbmVkIExJIGluIGl0cyAzRyByZWxhdGVkIGRvY3VtZW50cy4NCiANCklFVEYsIGFzIGFu IGludGVybmF0aW9uYWwgc3RhbmRhcmRzIGJvZHksIGNvdWxkIGhhdmUgaXRzIHBvc2l0aW9uIG9m IHdpcmVzdGFwcGluZyBvciBMSSwNCmFuZCB0aGlzIFdHIHNob3VsZCB3b3JrIHdpdGggdGhlIHNh bWUgcG9zaXRpb24gb2YgUkZDMjgwNC4NCkJ1dCwgYXMgUkZDMjgwNCBpcyBhYm91dCAgd2lyZXN0 YXBwaW5nIG9yIExJLCAgaXQgY291bGQgbm90IGJlIHVuZGVyc3Rvb2QgYXMgYW55dGhpbmcgb3Ig YWxsIGNvbmNlcHRzIHJlbGF0ZWQgdG8gUFNUTi4gDQoNClJlZ2FyZHMsDQoNCkdlbmd5dQ0K --===============0966195983== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0966195983==-- From p2psip-bounces@ietf.org Sun Apr 29 23:05:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiMCI-0000iw-7i; Sun, 29 Apr 2007 23:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiMCG-0000iq-OY for p2psip@ietf.org; Sun, 29 Apr 2007 23:05:04 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiMCE-0004nY-7A for p2psip@ietf.org; Sun, 29 Apr 2007 23:05:04 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HiMCD-0006rF-2Z; Sun, 29 Apr 2007 23:05:01 -0400 In-Reply-To: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Sun, 29 Apr 2007 23:05:00 -0400 To: Medhavi Bhatia X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 1.2 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote: > I was a little confused by the wording in the draft. It started by > saying that it doesn't make any assumptions about the p2p protocol > (sip based or other), but then states the OPTIONS and REGISTER > methods for bootstrap peers to join the bootstrap server. Wouldn't > these operations be part of the p2p protocol draft? The draft makes no assumptions on the nature of the Peer Protocol. However, the draft assumes that SIP is used to signal Peer Protocol connections -- SIP is a very good signaling protocol, so why not use it to set up Peer Protocol connections? So the support of OPTIONS and REGISTER are for SIP when signaling Peer Protocol connections. However, the Peer Protocol itself could be anything. Does this help? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Apr 29 23:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiMYB-0003O4-MJ; Sun, 29 Apr 2007 23:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiMYA-0003No-76 for p2psip@ietf.org; Sun, 29 Apr 2007 23:27:42 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiMY8-0001VT-Sz for p2psip@ietf.org; Sun, 29 Apr 2007 23:27:42 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1430177wri for ; Sun, 29 Apr 2007 20:27:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=h5oHUODnfnQjpxm0D0vr2BqnVziteRjs5lnX5XOACgfbY2/u5ft/9p5yTBGn5ikLf7NIjk5iRQ0w6Euwh+5/QbOEUiibbwkUhSS3TLGPDrcdcuseaPVxp9KrVZRiGmD5/a0P88lYW6dBnp/TPd7bM56bwzLWSwqnGq7qxwoKZWs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=h3+YhB5rHb+XJNwYFn9WlojdLdT/KKps9UbhomsZAqS3L78mxTqx/0nTirSzohIJM0Bu2+qDD6uwRJHmYZk1797FyQeDaaIGnJVhjaup79jEJTjY+rR0TKYRxqvlzVn6JbNLabshnXWVEWYz8OQZBZiBaXJ2aS+4Njz+gxFz0yM= Received: by 10.115.55.1 with SMTP id h1mr1847033wak.1177903660112; Sun, 29 Apr 2007 20:27:40 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Sun, 29 Apr 2007 20:27:39 -0700 (PDT) Message-ID: <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> Date: Sun, 29 Apr 2007 23:27:39 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 In-Reply-To: MIME-Version: 1.0 References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> X-Google-Sender-Auth: 848b0249e2d84692 X-Spam-Score: 1.7 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0162073391==" Errors-To: p2psip-bounces@ietf.org --===============0162073391== Content-Type: multipart/alternative; boundary="----=_Part_20159_4343359.1177903659716" ------=_Part_20159_4343359.1177903659716 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip, I think the use of SIP with ICE is used to signal the control connection is fine. Moreover its debatable whether it is SIP or ICE which should be the control connection protocol. After reading the draft, it seems to me that OPTIONS is used to locate the bootstrap peer and not establish a control connection (in multicast domain) and REGISTER is used between bootstrap peer and bootstrap server (and not to establish a control connection in a more regular environment). It seems NAT traversal may not an issue in either case. Did I understand this correctly? Medhavi. On 4/29/07, Philip Matthews wrote: > > > On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote: > > > I was a little confused by the wording in the draft. It started by > > saying that it doesn't make any assumptions about the p2p protocol > > (sip based or other), but then states the OPTIONS and REGISTER > > methods for bootstrap peers to join the bootstrap server. Wouldn't > > these operations be part of the p2p protocol draft? > > The draft makes no assumptions on the nature of the Peer Protocol. > However, the draft assumes that SIP is used to signal Peer Protocol > connections -- SIP is a very good signaling protocol, so why not use > it to set up Peer Protocol connections? > > So the support of OPTIONS and REGISTER are for SIP when signaling > Peer Protocol connections. However, the Peer Protocol itself could > be anything. > > Does this help? > > - Philip > > ------=_Part_20159_4343359.1177903659716 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip,

I think the use of SIP with ICE is used to signal the control connection is fine. Moreover its debatable whether it is SIP or ICE which should be the control connection protocol. After reading the draft, it seems to me that OPTIONS is used to locate the bootstrap peer and not establish a control connection (in multicast domain) and REGISTER is used between bootstrap peer and bootstrap server (and not to establish a control connection in a more regular environment). It seems NAT traversal may not an issue in either case.

Did I understand this correctly?

Medhavi.

On 4/29/07, Philip Matthews <philip_matthews@magma.ca > wrote:

On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote:

> I was a little confused by the wording in the draft. It started by
> saying that it doesn't make any assumptions about the p2p protocol
> (sip based or other), but then states the OPTIONS and REGISTER
> methods for bootstrap peers to join the bootstrap server. Wouldn't
> these operations be part of the p2p protocol draft?

The draft makes no assumptions on the nature of the Peer Protocol.
However, the draft assumes that SIP is used to signal Peer Protocol
connections  -- SIP is a very good signaling protocol, so why not use
it to set up Peer Protocol connections?

So the support of OPTIONS and REGISTER are for SIP when signaling
Peer Protocol connections.  However, the Peer Protocol itself could
be anything.

Does this help?

- Philip


------=_Part_20159_4343359.1177903659716-- --===============0162073391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0162073391==-- From p2psip-bounces@ietf.org Mon Apr 30 01:06:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO5n-0003AN-F4; Mon, 30 Apr 2007 01:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiO5m-0003AD-6h for p2psip@ietf.org; Mon, 30 Apr 2007 01:06:30 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiO5i-0007c9-AF for p2psip@ietf.org; Mon, 30 Apr 2007 01:06:30 -0400 Received: from Quinthar ([67.169.180.240]) by quinthar.com for ; Sun, 29 Apr 2007 22:06:21 -0700 From: "David Barrett" To: Date: Sun, 29 Apr 2007 22:06:21 -0700 Message-ID: <057a01c78ae5$4b8a57d0$7101a8c0@Quinthar> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_057B_01C78AAA.9F2B7FD0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceJzhG6KCwxhhqdRUGSTdf9djPIeABFt3Qg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Subject: [P2PSIP] FW: [p2p-hackers] P2P in SFC, redux: Monday, 4/30, at 8pm X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_057B_01C78AAA.9F2B7FD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_057C_01C78AAA.9F2B7FD0" ------=_NextPart_001_057C_01C78AAA.9F2B7FD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi there, I assume most of you are already on the p2p-hackers list and thus have already seen my invitation. If you haven't, however, a few of us are getting together in San Francisco on Monday at 8pm - details follow. Any p2p-sippers out there are of course welcome (but please give me a head's up so I can plan accordingly)! -david _____ From: p2p-hackers-bounces@lists.zooko.com [mailto:p2p-hackers-bounces@lists.zooko.com] On Behalf Of David Barrett Sent: Saturday, April 28, 2007 12:48 PM To: 'theory and practice of decentralized computer networks' Subject: [p2p-hackers] P2P in SFC, redux: Monday, 4/30, at 8pm Alright, the votes are in and Monday (4/30) was the clear champion. I've got down the following list; if you're planning to come and aren't on it, please let me know: - Jeffrey Chang - Ryan Barrett - Drew Andersen - Travis Kalanick - Tom Jacobs - Witold Stankiewicz - Priyanka Sinha - Lemon Obrien - Serguei Osokine - Susheel Daswani - Matthew Kaufman Please come prepared with a couple juicy questions for discussion, anything from "Which DHT will come out on top (if any)?" to "What ever happened to Waste?" to "What's the best way to get laid?" The questions will be drawn from a fishbowl and offered up as topics for discussion Once again, the location is: Ryoko's Sushi http://tinyurl.com/3ckp4c 619 Taylor St San Francisco, CA (415) 775-1028 8pm Bring $20-30 to cover all the food and drink you intend to consume and we'll figure out how to put it to best use. (And veggie sushi options are available.) See you soon! -david ------=_NextPart_001_057C_01C78AAA.9F2B7FD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi there, I assume most of you are = already on the p2p-hackers list and thus have already seen my invitation.  = If you haven’t, however, a few of us are getting together in San Francisco on Monday at 8pm = – details follow.  Any p2p-sippers out there are of course welcome = (but please give me a head’s up so I can plan = accordingly)!

 

-david

 

From: p2p-hackers-bounces@lists.zooko.com [mailto:p2p-hackers-bounces@lists.zooko.com] On Behalf Of David Barrett
Sent: Saturday, April 28, = 2007 12:48 PM
To: 'theory and practice of decentralized computer networks'
Subject: [p2p-hackers] = P2P in SFC, redux: Monday, 4/30, at 8pm

 

Alright, the votes are in and Monday (4/30) was the = clear champion.  I’ve got down the following list; if you’re planning to come and aren’t on it, please let me = know:

 

-          Jeffrey = Chang

-          Ryan = Barrett

-          Drew = Andersen

-          Travis = Kalanick

-          Tom = Jacobs

-          Witold = Stankiewicz

-          Priyanka = Sinha

-          Lemon = Obrien

-          Serguei = Osokine

-          Susheel = Daswani

-          Matthew = Kaufman

 

Please come prepared with a couple juicy questions = for discussion, anything from “Which DHT will come out on top (if any)?” to “What ever happened to Waste?” to “What’s the best way to get laid?”  The questions = will be drawn from a fishbowl and offered up as topics for = discussion

 

Once again, the location = is:

 

         =    Ryoko’s Sushi

         =    http://tinyurl.com/3ckp4c

         =    619 Taylor = St

         =    San Francisco, = CA

         =    (415) 775-1028

         =    8pm

 

Bring $20-30 to cover all the food and drink you = intend to consume and we’ll figure out how to put it to best use.  (And = veggie sushi options are available.)

 

See you soon!

 

-david

 

 

------=_NextPart_001_057C_01C78AAA.9F2B7FD0-- ------=_NextPart_000_057B_01C78AAA.9F2B7FD0 Content-Type: text/plain; name="ATT00916.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00916.txt" _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ------=_NextPart_000_057B_01C78AAA.9F2B7FD0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_057B_01C78AAA.9F2B7FD0-- From p2psip-bounces@ietf.org Mon Apr 30 07:39:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUED-0007G8-01; Mon, 30 Apr 2007 07:39:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUEC-0007Az-5M for p2psip@ietf.org; Mon, 30 Apr 2007 07:39:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUE8-0003y9-GY for p2psip@ietf.org; Mon, 30 Apr 2007 07:39:36 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HiUE7-0005tR-34; Mon, 30 Apr 2007 07:39:32 -0400 In-Reply-To: <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Mon, 30 Apr 2007 07:39:31 -0400 To: "Medhavi Bhatia" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.2 (+) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881742217==" Errors-To: p2psip-bounces@ietf.org --===============0881742217== Content-Type: multipart/alternative; boundary=Apple-Mail-7--90008057 --Apple-Mail-7--90008057 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Taking your points one-by--one: - ICE is not a signaling protocol by itself, but (as currently defined) needs to ride on a signaling protocol that exchanges SDP messages. SIP is the premiere example of such a protocol. This is why the draft using SIP for signaling - For the multicast case, a SIP OPTIONS message is used to _locate_ bootstrap peers. In the Bootstrap Server Mechanism, a SIP REGISTER message is used to _register_ a bootstrap peer with a bootstrap server. However, in both methods, a SIP INVITE transaction is used to establish the connection between the joining peer and the admitting peer. - Not sure what you mean by the statement "NAT Traversal is not an issue", as there was a lot of thought put into the draft to make it work in the presence of NATs. Did I understand and answer your questions? - Philip On 29-Apr-07, at 23:27 , Medhavi Bhatia wrote: > Hi Philip, > > I think the use of SIP with ICE is used to signal the control > connection is fine. Moreover its debatable whether it is SIP or ICE > which should be the control connection protocol. After reading the > draft, it seems to me that OPTIONS is used to locate the bootstrap > peer and not establish a control connection (in multicast domain) > and REGISTER is used between bootstrap peer and bootstrap server > (and not to establish a control connection in a more regular > environment). It seems NAT traversal may not an issue in either case. > > Did I understand this correctly? > > Medhavi. > > On 4/29/07, Philip Matthews wrote: > > On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote: > > > I was a little confused by the wording in the draft. It started by > > saying that it doesn't make any assumptions about the p2p protocol > > (sip based or other), but then states the OPTIONS and REGISTER > > methods for bootstrap peers to join the bootstrap server. Wouldn't > > these operations be part of the p2p protocol draft? > > The draft makes no assumptions on the nature of the Peer Protocol. > However, the draft assumes that SIP is used to signal Peer Protocol > connections -- SIP is a very good signaling protocol, so why not use > it to set up Peer Protocol connections? > > So the support of OPTIONS and REGISTER are for SIP when signaling > Peer Protocol connections. However, the Peer Protocol itself could > be anything. > > Does this help? > > - Philip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-7--90008057 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Taking your points = one-by--one:
- ICE is not a signaling protocol by itself, but (as = currently defined) needs to ride on a signaling protocol that exchanges = SDP messages. SIP is the premiere example of such a protocol. This is = why the draft using SIP for signaling
- For the multicast = case, a SIP OPTIONS message is used to _locate_ bootstrap peers. In the = Bootstrap Server Mechanism, a SIP REGISTER message is used to _register_ = a bootstrap peer with a bootstrap server.=A0 However, in both methods, a = SIP INVITE transaction is used to establish the connection between the = joining peer and the admitting peer.
- Not sure what you mean = by the statement "NAT Traversal is not an issue", as=A0 there was a lot = of thought put into the draft to make it work in the presence of = NATs.=A0=A0

Did= I understand and answer your questions?

- Philip


On 29-Apr-07, at = 23:27 , Medhavi Bhatia wrote:

Hi = Philip,

I think the use of SIP with ICE is used to signal the = control connection is fine. Moreover its debatable whether it is SIP or = ICE which should be the control connection protocol. After reading the = draft, it seems to me that OPTIONS is used to locate the bootstrap peer = and not establish a control connection (in multicast domain) and = REGISTER is used between bootstrap peer and bootstrap server (and not to = establish a control connection in a more regular environment). It seems = NAT traversal may not an issue in either case.

Did I understand = this correctly?

Medhavi.

On= 4/29/07, Philip Matthews <philip_matthews@magma.ca = > wrote:

On 26-Apr-07, at 19:59 , Medhavi Bhatia = wrote:

> I was a little confused by the wording in the draft. = It started by
> saying that it doesn't make any assumptions about = the p2p protocol
> (sip based or other), but then states the = OPTIONS and REGISTER
> methods for bootstrap peers to join the = bootstrap server. Wouldn't
> these operations be part of the p2p = protocol draft?

The draft makes no assumptions on the nature of = the Peer Protocol.
However, the draft assumes that SIP is used to = signal Peer Protocol
connections=A0=A0-- SIP is a very good signaling = protocol, so why not use
it to set up Peer Protocol = connections?

So the support of OPTIONS and REGISTER are for SIP = when signaling
Peer Protocol connections.=A0=A0However, the Peer = Protocol itself could
be anything.

Does this help?

- = Philip


P2PSIP mailing list
=

= --Apple-Mail-7--90008057-- --===============0881742217== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0881742217==-- From p2psip-bounces@ietf.org Mon Apr 30 11:25:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXk2-0000mQ-Dl; Mon, 30 Apr 2007 11:24:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiXk1-0000mG-Gi for p2psip@ietf.org; Mon, 30 Apr 2007 11:24:41 -0400 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiXk1-00005H-0y for p2psip@ietf.org; Mon, 30 Apr 2007 11:24:41 -0400 Received: by nz-out-0506.google.com with SMTP id z6so2110301nzd for ; Mon, 30 Apr 2007 08:24:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iFkCaHfad34zutVphxyUwt4ePJeTlxjVgeCl/RA/03/+u+XP/R/IvExxo8zUPL9NHfRzq4FbBY22O7rqDYSkZ3f1SAVbXlECGBjsVz5iLOi7Y5pMXHWHwlqk3UcaZC6FdqIoQ5K0o37iXQXF/vIyUsNfmrReh5mS5QntzYJfGsg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=iSl0jOcQ/XHo4NcPSWWaLwTo2pMBGr4npf3EPUD0b78Wj82XB12vGcKGs/bM7NStknlZVp5l62yC/7N+ae0fxu+DE44nFHQHsxmch5VjyRf/TV3eipo6Nmxc0fqQk0ftOmIPfTg4NyXdMqvAV08jH/us+RU7Va71FPFk9dvjpO0= Received: by 10.114.53.1 with SMTP id b1mr2048603waa.1177946678214; Mon, 30 Apr 2007 08:24:38 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Mon, 30 Apr 2007 08:24:38 -0700 (PDT) Message-ID: <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> Date: Mon, 30 Apr 2007 11:24:38 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 In-Reply-To: <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> MIME-Version: 1.0 References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> X-Google-Sender-Auth: 5378ca4fa42d131b X-Spam-Score: 1.2 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0170906500==" Errors-To: p2psip-bounces@ietf.org --===============0170906500== Content-Type: multipart/alternative; boundary="----=_Part_25915_11216051.1177946678147" ------=_Part_25915_11216051.1177946678147 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip, NAT Traversal brings a lot of complexity to a P2P network. I think we need to carefully identify what we are doing for traversing NAT from what we need to get the P2P to work itself. I think if we keep in mind that another offer-answer protocol (other than SIP) can be used with ICE to set up control connections as well then things are easier to analyze at least. The bootstrap server seems to have two roles. It helps location of a bootstrap peer (P2P part) as well as act as a rendezvous point for establishing a control connection to it (NAT Traversal part). The functionality provided by SIP OPTIONS and REGISTER (mainly location of the bootstrap peer) seems to be related to P2P part. So I think the draft seems to have over specified since it is discussing the use of SIP to do that. Medhavi. On 4/30/07, Philip Matthews wrote: > > Taking your points one-by--one:- ICE is not a signaling protocol by > itself, but (as currently defined) needs to ride on a signaling protocol > that exchanges SDP messages. SIP is the premiere example of such a protocol. > This is why the draft using SIP for signaling > - For the multicast case, a SIP OPTIONS message is used to _locate_ > bootstrap peers. In the Bootstrap Server Mechanism, a SIP REGISTER message > is used to _register_ a bootstrap peer with a bootstrap server. However, in > both methods, a SIP INVITE transaction is used to establish the connection > between the joining peer and the admitting peer. > - Not sure what you mean by the statement "NAT Traversal is not an issue", > as there was a lot of thought put into the draft to make it work in the > presence of NATs. > > Did I understand and answer your questions? > > - Philip > > > On 29-Apr-07, at 23:27 , Medhavi Bhatia wrote: > > Hi Philip, > > I think the use of SIP with ICE is used to signal the control connection > is fine. Moreover its debatable whether it is SIP or ICE which should be the > control connection protocol. After reading the draft, it seems to me that > OPTIONS is used to locate the bootstrap peer and not establish a control > connection (in multicast domain) and REGISTER is used between bootstrap peer > and bootstrap server (and not to establish a control connection in a more > regular environment). It seems NAT traversal may not an issue in either > case. > > Did I understand this correctly? > > Medhavi. > > On 4/29/07, Philip Matthews wrote: > > > > > > On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote: > > > > > I was a little confused by the wording in the draft. It started by > > > saying that it doesn't make any assumptions about the p2p protocol > > > (sip based or other), but then states the OPTIONS and REGISTER > > > methods for bootstrap peers to join the bootstrap server. Wouldn't > > > these operations be part of the p2p protocol draft? > > > > The draft makes no assumptions on the nature of the Peer Protocol. > > However, the draft assumes that SIP is used to signal Peer Protocol > > connections -- SIP is a very good signaling protocol, so why not use > > it to set up Peer Protocol connections? > > > > So the support of OPTIONS and REGISTER are for SIP when signaling > > Peer Protocol connections. However, the Peer Protocol itself could > > be anything. > > > > Does this help? > > > > - Philip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > ------=_Part_25915_11216051.1177946678147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip,

NAT Traversal brings a lot of complexity to a P2P network. I think we need to carefully identify what we are doing for traversing NAT from what we need to get the P2P to work itself. I think if we keep in mind that another offer-answer protocol (other than SIP) can be used with ICE to set up control connections as well then things are easier to analyze at least.

The bootstrap server seems to have two roles. It helps location of a bootstrap peer (P2P part) as well as act as a rendezvous point for establishing a control connection to it (NAT Traversal part). The functionality provided by SIP OPTIONS and REGISTER (mainly location of the bootstrap peer) seems to be related to P2P part. So I think the draft seems to have over specified since it is discussing the use of SIP to do that.

Medhavi.

On 4/30/07, Philip Matthews <philip_matthews@magma.ca> wrote:
Taking your points one-by--one:
- ICE is not a signaling protocol by itself, but (as currently defined) needs to ride on a signaling protocol that exchanges SDP messages. SIP is the premiere example of such a protocol. This is why the draft using SIP for signaling
- For the multicast case, a SIP OPTIONS message is used to _locate_ bootstrap peers. In the Bootstrap Server Mechanism, a SIP REGISTER message is used to _register_ a bootstrap peer with a bootstrap server.  However, in both methods, a SIP INVITE transaction is used to establish the connection between the joining peer and the admitting peer.
- Not sure what you mean by the statement "NAT Traversal is not an issue", as  there was a lot of thought put into the draft to make it work in the presence of NATs.  

Did I understand and answer your questions?

- Philip


On 29-Apr-07, at 23:27 , Medhavi Bhatia wrote:

Hi Philip,

I think the use of SIP with ICE is used to signal the control connection is fine. Moreover its debatable whether it is SIP or ICE which should be the control connection protocol. After reading the draft, it seems to me that OPTIONS is used to locate the bootstrap peer and not establish a control connection (in multicast domain) and REGISTER is used between bootstrap peer and bootstrap server (and not to establish a control connection in a more regular environment). It seems NAT traversal may not an issue in either case.

Did I understand this correctly?

Medhavi.

On 4/29/07, Philip Matthews < philip_matthews@magma.ca > wrote:

On 26-Apr-07, at 19:59 , Medhavi Bhatia wrote:

> I was a little confused by the wording in the draft. It started by
> saying that it doesn't make any assumptions about the p2p protocol
> (sip based or other), but then states the OPTIONS and REGISTER
> methods for bootstrap peers to join the bootstrap server. Wouldn't
> these operations be part of the p2p protocol draft?

The draft makes no assumptions on the nature of the Peer Protocol.
However, the draft assumes that SIP is used to signal Peer Protocol
connections  -- SIP is a very good signaling protocol, so why not use
it to set up Peer Protocol connections?

So the support of OPTIONS and REGISTER are for SIP when signaling
Peer Protocol connections.  However, the Peer Protocol itself could
be anything.

Does this help?

- Philip


_______________________________________________
P2PSIP mailing list


------=_Part_25915_11216051.1177946678147-- --===============0170906500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0170906500==-- From p2psip-bounces@ietf.org Mon Apr 30 13:59:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hia9z-0006nM-D6; Mon, 30 Apr 2007 13:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hia9w-0006jq-JV for p2psip@ietf.org; Mon, 30 Apr 2007 13:59:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hia65-0007ig-8x for p2psip@ietf.org; Mon, 30 Apr 2007 13:55:38 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hia64-0000KD-2o; Mon, 30 Apr 2007 13:55:36 -0400 In-Reply-To: <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 Date: Mon, 30 Apr 2007 13:55:35 -0400 To: "Medhavi Bhatia" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 1.2 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote: > Hi Philip, > > NAT Traversal brings a lot of complexity to a P2P network. I think > we need to carefully identify what we are doing for traversing NAT > from what we need to get the P2P to work itself. I think if we keep > in mind that another offer-answer protocol (other than SIP) can be > used with ICE to set up control connections as well then things are > easier to analyze at least. NAT traversal is complex. Unfortunately, it also seems integral to P2PSIP. What we do NOT want to do is to repeat the SIP experience and design a P2PSIP system and then try to add NAT Traversal as an afterthought. > > The bootstrap server seems to have two roles. It helps location of > a bootstrap peer (P2P part) as well as act as a rendezvous point > for establishing a control connection to it (NAT Traversal part). > The functionality provided by SIP OPTIONS and REGISTER (mainly > location of the bootstrap peer) seems to be related to P2P part. So > I think the draft seems to have over specified since it is > discussing the use of SIP to do that. I agree that that the bootstrap server does a number of things. However, I don't see the distinction that you seem to be suggesting. Can you explain further? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Apr 30 15:49:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibrr-0003ZP-N1; Mon, 30 Apr 2007 15:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibrq-0003ZK-K8 for p2psip@ietf.org; Mon, 30 Apr 2007 15:49:02 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hibrq-0003VM-8V for p2psip@ietf.org; Mon, 30 Apr 2007 15:49:02 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1664332wri for ; Mon, 30 Apr 2007 12:49:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=biuDcTh65KYFv7Vkh1vk5LiM6ia9E4/uYSb22Htg2aP45cLb9+BwWehMLXzinDdQc3ZjIWs9BuXWIYrAUYa/tVoTQNp4I/GeuhMzafByNNNRZAK2uz71G0K60pgfNh06i1jEI5GlcucajRYi3XOSAf1kisRvUIuM516/4GtTvHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=rlTXCJLMIBdk0RkR4dpPm8yqtmy2Fv2nuvlIeOCVc23DGHpj4//C2mLjMhhkfHMZ8KXBQhPj9Ix+O9EoIY5A6pCZo03AgBM8KGWkELmhrRi/VnuGx/nx0zMEPVWT6xtDQ9rIYCJ+1p4TZL3/fGhjrKYdCG1EU59D1IbkLmadCgw= Received: by 10.114.125.2 with SMTP id x2mr2111879wac.1177962541330; Mon, 30 Apr 2007 12:49:01 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Mon, 30 Apr 2007 12:49:01 -0700 (PDT) Message-ID: <894e079b0704301249g3c538639o4d088fd104e11b7e@mail.gmail.com> Date: Mon, 30 Apr 2007 15:49:01 -0400 From: "Medhavi Bhatia" To: "Philip Matthews" Subject: Re: [P2PSIP] Comments on draft draft-matthews-p2psip-bootstrap-mechanisms-00 In-Reply-To: <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> MIME-Version: 1.0 References: <894e079b0704261659t66b77385j4614cd8b40c5ba22@mail.gmail.com> <894e079b0704292027s4921ed69g3d68e5803c08229b@mail.gmail.com> <3084061F-5C99-44E1-9A83-D8DB464F1BEA@magma.ca> <894e079b0704300824q515f14bdv5347e0d9dbda96ab@mail.gmail.com> <783A4A1F-3A23-4BDE-A9BE-77149AEC5597@magma.ca> X-Google-Sender-Auth: ee23f8fde824bc4c X-Spam-Score: 1.4 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1495532738==" Errors-To: p2psip-bounces@ietf.org --===============1495532738== Content-Type: multipart/alternative; boundary="----=_Part_30577_22933930.1177962541257" ------=_Part_30577_22933930.1177962541257 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip, If I organize the tasks required to become part of the P2P network in the following categories: Step1: Determine which admitting peer to connect to (bootstrap server/multicast/static config) Step2: Form a control connection with the admitting peer (bootstrap server) Step3: Run the P2P protocol to join the p2p network, register resources, query, exchange routes etc. I think the use of OPTIONS applies to step1. SIP/ICE or any connection establishment protocol which works over NATS applies to steps 1 and 2. However registering myself as a bootstrap peer seems to be part of Step3. I assume that the bootstrap server is part of the p2p network. I am just trying to put my head together on this one now ;). Medhavi. On 4/30/07, Philip Matthews wrote: > > > On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote: > > > Hi Philip, > > > > NAT Traversal brings a lot of complexity to a P2P network. I think > > we need to carefully identify what we are doing for traversing NAT > > from what we need to get the P2P to work itself. I think if we keep > > in mind that another offer-answer protocol (other than SIP) can be > > used with ICE to set up control connections as well then things are > > easier to analyze at least. > > NAT traversal is complex. Unfortunately, it also seems integral to > P2PSIP. What we do NOT want to do is to repeat the SIP experience > and design a P2PSIP system and then try to add NAT Traversal as an > afterthought. > > > > > The bootstrap server seems to have two roles. It helps location of > > a bootstrap peer (P2P part) as well as act as a rendezvous point > > for establishing a control connection to it (NAT Traversal part). > > The functionality provided by SIP OPTIONS and REGISTER (mainly > > location of the bootstrap peer) seems to be related to P2P part. So > > I think the draft seems to have over specified since it is > > discussing the use of SIP to do that. > > I agree that that the bootstrap server does a number of things. > However, I don't see the distinction that you seem to be suggesting. > Can you explain further? > > - Philip > > > > ------=_Part_30577_22933930.1177962541257 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Philip,

If I organize the tasks required to become part of the P2P network in the following categories:

Step1: Determine which admitting peer to connect to (bootstrap server/multicast/static config)
Step2: Form a control connection with the admitting peer (bootstrap server)
Step3: Run the P2P protocol to join the p2p network, register resources, query, exchange routes etc.

I think the use of OPTIONS applies to step1. SIP/ICE or any connection establishment protocol which works over NATS applies to steps 1 and 2. However registering myself as a bootstrap peer seems to be part of Step3. I assume that the bootstrap server is part of the p2p network.

I am just trying to put my head together on this one now ;).

Medhavi.

On 4/30/07, Philip Matthews < philip_matthews@magma.ca> wrote:

On 30-Apr-07, at 11:24 , Medhavi Bhatia wrote:

> Hi Philip,
>
> NAT Traversal brings a lot of complexity to a P2P network. I think
> we need to carefully identify what we are doing for traversing NAT
> from what we need to get the P2P to work itself. I think if we keep
> in mind that another offer-answer protocol (other than SIP) can be
> used with ICE to set up control connections as well then things are
> easier to analyze at least.

NAT traversal is complex. Unfortunately, it also seems integral to
P2PSIP. What we do NOT want to do is to repeat the  SIP experience
and design a P2PSIP system and then try to  add NAT Traversal as an
afterthought.

>
> The bootstrap server seems to have two roles. It helps location of
> a bootstrap peer (P2P part) as well as act as a rendezvous point
> for establishing a control connection to it (NAT Traversal part).
> The functionality provided by SIP OPTIONS and REGISTER (mainly
> location of the bootstrap peer) seems to be related to P2P part. So
> I think the draft seems to have over specified since it is
> discussing the use of SIP to do that.

I agree that that the bootstrap server does a number of things.
However, I don't see the distinction that you seem to be suggesting.
Can you explain further?

- Philip




------=_Part_30577_22933930.1177962541257-- --===============1495532738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1495532738==-- From p2psip-bounces@ietf.org Mon Apr 30 21:36:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HihHv-0007AU-9O; Mon, 30 Apr 2007 21:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HihHu-0007AP-90 for p2psip@ietf.org; Mon, 30 Apr 2007 21:36:18 -0400 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HihHt-00023w-0a for p2psip@ietf.org; Mon, 30 Apr 2007 21:36:18 -0400 Received: by nz-out-0506.google.com with SMTP id z6so2278497nzd for ; Mon, 30 Apr 2007 18:36:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=WZswVEpWg0j5wjsqSV2sfSDoj/aSxJ/bycQfLH+KdnlZ1HtNJ2b8mt3WRjb6RfFtIGpyo8cFJnKYoDl5dioql55wNgyW5ov+aLLLiVZXyvypimmhTkKK9xKa4I4TZAn7PMXDl2znViiRwx/tYdN1xgWjDHc4SOVrkA6fQxGgVLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=uHc1WRhPAjr987FsmpVytsBcj0wfclQAskro6Jf6dQNDVqwoNND7fvskse/GzxHAdGAbzJpkSgMNVWprN4CyUfILcPZHOc3tTCh6feqi0sm1VMaq1J7uPb8RHHGA4vap+R8SshEHB7ERMHrY7Dw6JdlYa7489UepJ1GuOd+7H6s= Received: by 10.114.199.1 with SMTP id w1mr2185849waf.1177983376323; Mon, 30 Apr 2007 18:36:16 -0700 (PDT) Received: by 10.114.120.9 with HTTP; Mon, 30 Apr 2007 18:36:16 -0700 (PDT) Message-ID: <894e079b0704301836y678f4250t308d7af2517cf137@mail.gmail.com> Date: Mon, 30 Apr 2007 21:36:16 -0400 From: "Medhavi Bhatia" To: p2psip@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 08d312e19b68dc78 X-Spam-Score: 1.3 (+) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [P2PSIP] Comments on draft-jiang-p2psip-peer-protocol-requirement-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1974342957==" Errors-To: p2psip-bounces@ietf.org --===============1974342957== Content-Type: multipart/alternative; boundary="----=_Part_34943_7843779.1177983376265" ------=_Part_34943_7843779.1177983376265 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems this draft is a little out of update and probably needs some re-organization as well. 1. First and foremost the draft needs to split requirements in more categories: requirements pertaining to operate the p2p network itself (join/leave/updates and other operations required for p2p network to work) should be separate from transport level. It seems that other drafts are talking about transport and control connections separate from the p2p protocol itself and the draft needs to lay down requirements for these separately from the p2p protocol. 2. At the p2p protocol level, the requirements are very vague and say too little. In my understanding, they don't help much at this point to specifically serve as guidance when choosing SIP or a new protocol (comparing the bryan and henning drafts here). 3. Security requirements for the p2p protocol don't exist. There is a section on security, but I am not sure it is giving any requirements for the p2p protocol or the control connection protocol or transport. 4. Diagnostics collection is quite important, more so since there is no management. I think requirements should be there for this as well since diagnostics should be built into the protocol as well to test if it is working properly. Medhavi. ------=_Part_34943_7843779.1177983376265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems this draft is a little out of update and probably needs some re-organization as well.

1. First and foremost the draft needs to split requirements in more categories: requirements pertaining to operate the p2p network itself (join/leave/updates and other operations required for p2p network to work) should be separate from transport level. It seems that other drafts are talking about transport and control connections separate from the p2p protocol itself and the draft needs to lay down requirements for these separately from the p2p protocol.

2. At the p2p protocol level, the requirements are very vague and say too little. In my understanding, they don't help much at this point to specifically serve as guidance when choosing SIP or a new protocol (comparing the bryan and henning drafts here).

3. Security requirements for the p2p protocol don't exist. There is a section on security, but I am not sure it is giving any requirements for the p2p protocol or the control connection protocol or transport.

4. Diagnostics collection is quite important, more so since there is no management. I think requirements should be there for this as well since diagnostics should be built into the protocol as well to test if it is working properly.

Medhavi.

------=_Part_34943_7843779.1177983376265-- --===============1974342957== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1974342957==--