From speermint-bounces@ietf.org Tue Apr 10 19: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 1HbQCI-0001qw-4D; Tue, 10 Apr 2007 19:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbQCG-0001qq-BK for speermint@ietf.org; Tue, 10 Apr 2007 19:56:24 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbQCE-0003uy-Vc for speermint@ietf.org; Tue, 10 Apr 2007 19:56:24 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l3ANtpoK029983; Tue, 10 Apr 2007 23:55:51 GMT Subject: Re: [Speermint] Differing Administration Categories From: Daryl Malas To: "Uzelac, Adam" In-Reply-To: References: Content-Type: text/plain Date: Tue, 10 Apr 2007 18:08:43 -0600 Message-Id: <1176250123.17141.140.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Wed, 2007-03-28 at 18:34 -0500, Uzelac, Adam wrote: > In Prague - their was a discussion around the distinctions between > federations and other concepts. As the Consolidated VoIP use case draft > sits today - indeed there is "fuzziness" around this. It's not clear > and I would like make it so. > I think the big question came as, does a 1:1 peering relationship constitute a federation? I think many people believe a federation means peering relationship between more than 2 entities. > Removed from the use-case categorization definitions will be > non-technical terms like "trust". With an entirely new section called > 'Administration' or 'Peering Contexts' (anyone have a preference) where > things like nuances in the use cases, like trust, non-E164 numbering > plans, etc will be captured. Outside of Federations, should > Enterprises, CLECs, MSOs, etc be categorized as 'Administration' or > 'Peering Contexts'? Thoughts? > I thought we were going to include things like 'Administration' and 'Security' into the actual use case examples in the document. Not actually creating a totally different section for them. I think it makes more sense to add them to the actual use case itself as to make it more relevant in reviewing the use case. I think these should be taken into consideration in the 'Enterprise' use case document as well. > Once we get a feel for this - I believe this also needs to be in the > terminology draft. > > Adam Uzelac > Director Converged Arch. > Global Crossing > 585-255-8916 > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 11 08:37: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 1Hbc3y-0000TE-5s; Wed, 11 Apr 2007 08:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbc3x-0000Qn-4w for speermint@ietf.org; Wed, 11 Apr 2007 08:36:37 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbc3v-0008UO-OB for speermint@ietf.org; Wed, 11 Apr 2007 08:36:37 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 4833298F5; Wed, 11 Apr 2007 08:36:05 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 08:36:04 -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 Subject: RE: [Speermint] Differing Administration Categories Date: Wed, 11 Apr 2007 08:36:03 -0400 Message-ID: In-Reply-To: <1176250123.17141.140.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Differing Administration Categories Thread-Index: Acd7y9jeHQmU+D8hRcOgfhYjFDaDQwAY5dcw References: <1176250123.17141.140.camel@montag.eng.level3.com> From: "Uzelac, Adam" To: "Daryl Malas" X-OriginalArrivalTime: 11 Apr 2007 12:36:04.0986 (UTC) FILETIME=[F8A285A0:01C77C35] X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks for the comments Daryl. I reviewed the notes from the meeting, both my own notes and from the jabber room - from those it wasn't clear to me consensus on the organization. I am keying on Jon P.'s comments that within definitions of some of the peering scenarios, and within Federation, there were non-technical terms. I have tried my best to remove those and place them in a non-technical category called 'Administration'. Federation is a subcategory. So is trust as well as some other concepts. Hopefully it will be more clear once the next draft is complete. I hope to have that done next week some time. Again - thanks for the comments. And I echo your comment that this should be done in the Enterprise use case as well. -AU > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Tuesday, April 10, 2007 8:09 PM > To: Uzelac, Adam > Cc: speermint@ietf.org > Subject: Re: [Speermint] Differing Administration Categories >=20 > On Wed, 2007-03-28 at 18:34 -0500, Uzelac, Adam wrote: > > In Prague - their was a discussion around the distinctions between=20 > > federations and other concepts. As the Consolidated VoIP use case=20 > > draft sits today - indeed there is "fuzziness" around this.=20 > It's not=20 > > clear and I would like make it so. > >=20 > I think the big question came as, does a 1:1 peering=20 > relationship constitute a federation? I think many people=20 > believe a federation means peering relationship between more=20 > than 2 entities. >=20 > > Removed from the use-case categorization definitions will be=20 > > non-technical terms like "trust". With an entirely new=20 > section called=20 > > 'Administration' or 'Peering Contexts' (anyone have a preference)=20 > > where things like nuances in the use cases, like trust, non-E164=20 > > numbering plans, etc will be captured. Outside of=20 > Federations, should=20 > > Enterprises, CLECs, MSOs, etc be categorized as 'Administration' or=20 > > 'Peering Contexts'? Thoughts? > >=20 > I thought we were going to include things like=20 > 'Administration' and 'Security' into the actual use case=20 > examples in the document. Not actually creating a totally=20 > different section for them. I think it makes more sense to=20 > add them to the actual use case itself as to make it more=20 > relevant in reviewing the use case. >=20 > I think these should be taken into consideration in the=20 > 'Enterprise' use case document as well. >=20 > > Once we get a feel for this - I believe this also needs to=20 > be in the=20 > > terminology draft. > >=20 > > Adam Uzelac > > Director Converged Arch. > > Global Crossing > > 585-255-8916 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 13 16:19: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 1HcSEM-0000nL-HZ; Fri, 13 Apr 2007 16:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSEL-0000mA-70 for speermint@ietf.org; Fri, 13 Apr 2007 16:18:49 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcSEJ-0000Pv-VM for speermint@ietf.org; Fri, 13 Apr 2007 16:18:49 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 935D09D7F for ; Fri, 13 Apr 2007 16:18:45 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 16:18:45 -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 16:18:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-making or Un-making the PSTN Thread-Index: Acd+CO+duoZ2g0AATTis8pcNPBGzCg== From: "Uzelac, Adam" To: X-OriginalArrivalTime: 13 Apr 2007 20:18:45.0478 (UTC) FILETIME=[F000F060:01C77E08] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Speermint] Re-making or Un-making the PSTN X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org As I sit here working on the VoIP use-case draft, I can't help but thinking if we aren't just re-making the PSTN, instead of un-making it. The crux of this issue lies with the routing. At some of the basic constructs of next-hop routing decisions that border elements need to do, these use-cases are starting to smell more and more like PSTN-based routing look-ups. A simple determination of who owns the SIP-URI of the intended recipient can not be determined definitively, so it's just punted off to the next chain in the link. The ultimate end-point determination needs to occur before the next-hop decision can be made. If we then consider B2BUAs in the mix, it's more likely than not that the original calling and called parties are changed. I realize some of this changes due to local policy, but that still doesn't get to the root of the problem. For instance, say there were 2 federations where Bob registered his SIP-URI, so that according to members of both federation, to reach bob sessions should be targeted to bob@company.com. Now if Alice is part of a an external domain to those federations, and with both feds "advertising" reachablity to Bob, how does Alice determine next-hop? Basically, who owns Bob's uri? =20 If we were to bring ENUM into the discussion, it even get's worse more wrought with concern due to starting with regulated e164. I just sharing out some thoughts. -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 13 17:20: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 1HcTBl-0006mV-Vy; Fri, 13 Apr 2007 17:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTBk-0006l5-PP for speermint@ietf.org; Fri, 13 Apr 2007 17:20:12 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcTBk-0006rm-9h for speermint@ietf.org; Fri, 13 Apr 2007 17:20:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] Re-making or Un-making the PSTN Date: Fri, 13 Apr 2007 23:20:13 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D78@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+CO+duoZ2g0AATTis8pcNPBGzCgABhb3y References: From: "Stastny Richard" To: "Uzelac, Adam" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Adam, =20 welcome to the bell-heads club ;-) =20 I think yoe (we all) should be very careful to go down this road. Others went down this road already -> and out came the IMS. One sip proxy is replaced by ten boxes (ok functions). IMS is rebuilding the PSTN =20 The real problem in IMS is that they have now their boxes, but still no solution for interconnect. One way out is done by 3GPP, it is the IPX. The IPX is a separate internet for signalling and eventually also for voice media.=20 =20 TISPANs NGN (the IMS for fixed network) has no solution yet for interconnect beside bilateral interconnect. =20 >For instance, say there were 2 federations where Bob registered his >SIP-URI, so that according to members of both federation, to reach bob >sessions should be targeted to bob@company.com =20 I always thought Bob registers within an administrative domain and not within a federation. An administrative domain may be part of one or more federations =20 >Now if Alice is part of >a an external domain to those federations, and with both feds >"advertising" reachablity to Bob, how does Alice determine next-hop? =20 random, cheapest termination rate, ... >Basically, who owns Bob's uri?=20 company.com It is still a DNS domain name. =20 Please Un-make the PSTN =20 Richard =20 ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Fr 13.04.2007 22:18 An: speermint@ietf.org Betreff: [Speermint] Re-making or Un-making the PSTN As I sit here working on the VoIP use-case draft, I can't help but thinking if we aren't just re-making the PSTN, instead of un-making it. The crux of this issue lies with the routing. At some of the basic constructs of next-hop routing decisions that border elements need to do, these use-cases are starting to smell more and more like PSTN-based routing look-ups. A simple determination of who owns the SIP-URI of the intended recipient can not be determined definitively, so it's just punted off to the next chain in the link. The ultimate end-point determination needs to occur before the next-hop decision can be made. If we then consider B2BUAs in the mix, it's more likely than not that the original calling and called parties are changed. I realize some of this changes due to local policy, but that still doesn't get to the root of the problem. For instance, say there were 2 federations where Bob registered his SIP-URI, so that according to members of both federation, to reach bob sessions should be targeted to bob@company.com. Now if Alice is part of a an external domain to those federations, and with both feds "advertising" reachablity to Bob, how does Alice determine next-hop? Basically, who owns Bob's uri?=20 If we were to bring ENUM into the discussion, it even get's worse more wrought with concern due to starting with regulated e164. I just sharing out some thoughts. -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 13 22:01: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 1HcXZm-0000OC-CO; Fri, 13 Apr 2007 22:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXZl-0000O3-HZ for speermint@ietf.org; Fri, 13 Apr 2007 22:01:17 -0400 Received: from web90606.mail.mud.yahoo.com ([216.252.100.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcXZk-0004P1-61 for speermint@ietf.org; Fri, 13 Apr 2007 22:01:17 -0400 Received: (qmail 77155 invoked by uid 60001); 14 Apr 2007 02:01:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=2zrAtMR/Q8aenxVfMqtzDo9HlSCOV7d5UoMA2jKr65vyeWYzSQTzqgHMh/F8dg0eFlIWye2SP/wvF01Y7J88eRiTtXZPL3039AMTE8tMwVrTHg0cGHgBQsFQcVhvZy01+MzYmle/7FbyaVoM8YnqUMCXuG3R57LIKQaEpjHkaPg=; X-YMail-OSG: EU7_V_EVM1l9rw0yi6DXe9ArFNiizwAI5MQUDIuQD8spXFhimqCF6CbCp1MNJINpI_eFEyJ65l.ZZP3oVkdk1rfq6dy5ADNWrbhYnN_bOmqfYa5.x4re_D32wCX8NQ-- Received: from [67.169.93.180] by web90606.mail.mud.yahoo.com via HTTP; Fri, 13 Apr 2007 19:01:15 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Fri, 13 Apr 2007 19:01:15 -0700 (PDT) From: Sukanta ganguly Subject: Re: [Speermint] Re-making or Un-making the PSTN To: "Uzelac, Adam" , speermint@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Message-ID: <825730.76940.qm@web90606.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, I am not sure I follow your complication. The fact that there are two federation of Bob's uri (according to your example) should provide Alice a way to find Bob's uri. Are you concerned about Alice's discovery of Bob's uri? The border element will do that. In that manner it is no different than a classical IP route discovery with a router. If no deterministic way of finding out the uri ownership can be concluded then the next hop makes this attempt. That is the most logical way of doing unless their is uniform and well understood global master. This happens to be how PSTN does it and hence no difference. SG ----- Original Message ---- From: "Uzelac, Adam" To: speermint@ietf.org Sent: Friday, April 13, 2007 1:18:44 PM Subject: [Speermint] Re-making or Un-making the PSTN As I sit here working on the VoIP use-case draft, I can't help but thinking if we aren't just re-making the PSTN, instead of un-making it. The crux of this issue lies with the routing. At some of the basic constructs of next-hop routing decisions that border elements need to do, these use-cases are starting to smell more and more like PSTN-based routing look-ups. A simple determination of who owns the SIP-URI of the intended recipient can not be determined definitively, so it's just punted off to the next chain in the link. The ultimate end-point determination needs to occur before the next-hop decision can be made. If we then consider B2BUAs in the mix, it's more likely than not that the original calling and called parties are changed. I realize some of this changes due to local policy, but that still doesn't get to the root of the problem. For instance, say there were 2 federations where Bob registered his SIP-URI, so that according to members of both federation, to reach bob sessions should be targeted to bob@company.com. Now if Alice is part of a an external domain to those federations, and with both feds "advertising" reachablity to Bob, how does Alice determine next-hop? Basically, who owns Bob's uri? If we were to bring ENUM into the discussion, it even get's worse more wrought with concern due to starting with regulated e164. I just sharing out some thoughts. -AU _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 16 11:48: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 1HdTQq-0004hq-GP; Mon, 16 Apr 2007 11:47:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTQo-0004hP-Pz for speermint@ietf.org; Mon, 16 Apr 2007 11:47:54 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTQm-0007w3-DT for speermint@ietf.org; Mon, 16 Apr 2007 11:47:54 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 20CA49850; Mon, 16 Apr 2007 11:47:52 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 11:47:51 -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: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 16 Apr 2007 11:47:50 -0400 Message-ID: In-Reply-To: <825730.76940.qm@web90606.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gA References: <825730.76940.qm@web90606.mail.mud.yahoo.com> From: "Uzelac, Adam" To: "Sukanta ganguly" , X-OriginalArrivalTime: 16 Apr 2007 15:47:51.0845 (UTC) FILETIME=[97529D50:01C7803E] X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 16 15:03: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 1HdWTd-0005WB-3v; Mon, 16 Apr 2007 15:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWTc-0005Ur-FB for speermint@ietf.org; Mon, 16 Apr 2007 15:03:00 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdWTb-0007bK-TY for speermint@ietf.org; Mon, 16 Apr 2007 15:03:00 -0400 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1176750178!16834487!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 5457 invoked from network); 16 Apr 2007 19:02:58 -0000 Received: from unknown (HELO attrh0i.attrh.att.com) (134.24.146.4) by server-5.tower-120.messagelabs.com with SMTP; 16 Apr 2007 19:02:58 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3GJ2wk9028143; Mon, 16 Apr 2007 15:02:58 -0400 (EDT) Received: from ACCLUST02EVS1.ugd.att.com (acst03.ugd.att.com [135.37.16.8]) by attrh0i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l3GJ2ov1028022; Mon, 16 Apr 2007 15:02:50 -0400 (EDT) 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: [Speermint] Re-making or Un-making the PSTN Date: Mon, 16 Apr 2007 15:02:49 -0400 Message-ID: <34DA635B184A644DA4588E260EC0A25A0F2D5426@ACCLUST02EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAAbPATA= References: <825730.76940.qm@web90606.mail.mud.yahoo.com> From: "PFAUTZ, PENN L, ATTCORP" To: "Uzelac, Adam" , "Sukanta ganguly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree?=20 Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 16 15:38: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 1HdX1q-0002jU-3K; Mon, 16 Apr 2007 15:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdX1o-0002he-Og for speermint@ietf.org; Mon, 16 Apr 2007 15:38:20 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdX1m-0003Ph-4L for speermint@ietf.org; Mon, 16 Apr 2007 15:38:20 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1553501wri for ; Mon, 16 Apr 2007 12:38: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:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HiSpM+5h8A4z+NWD2B5bEPCAfMqOpEeqwuqiVK0Vaz2YaIUsRH5FWv4CnEtedamCuAgn4vvc0nqEKSHWxA4fZ9SegxjvPb20/iZr27izSWZL+bWUj3xLi1LNJGgRezaEI/ajRauWvY7aZ6GU7rRbQ1q1l91JD/WY4jtJ2exiW0s= 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=ATKpnLhWiSoFFDDtqjzwQm1ALcPMwFcAXuN0IgB3OoK2NUEac15qQBjrF2M2L5ZDLhthIklZNqj5qmpQdW9xyZMcUWLEjG7meP2B1NmKmkKmclTv1wuygxPtRKrV7IDsr7HuB+JWV4LiQs+/ap2r4Rnzizs1h5jOYQStzVRFrP8= Received: by 10.114.201.1 with SMTP id y1mr2044742waf.1176752296676; Mon, 16 Apr 2007 12:38:16 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Mon, 16 Apr 2007 12:38:16 -0700 (PDT) Message-ID: <894e079b0704161238x6d51d6fctee5c6dfaef668a3e@mail.gmail.com> Date: Mon, 16 Apr 2007 15:38:16 -0400 From: "Medhavi Bhatia" To: "Uzelac, Adam" Subject: Re: [Speermint] Re-making or Un-making the PSTN In-Reply-To: MIME-Version: 1.0 References: <825730.76940.qm@web90606.mail.mud.yahoo.com> X-Google-Sender-Auth: 81b2d5312c3405b9 X-Spam-Score: 0.5 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441949108==" Errors-To: speermint-bounces@ietf.org --===============0441949108== Content-Type: multipart/alternative; boundary="----=_Part_45137_31379257.1176752296349" ------=_Part_45137_31379257.1176752296349 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess, there could be an argument that the PSTN was born out of not technical stuff, but how SPs wanted to connect to each other. That will re-surface again and again (e.g IMS and here as well). Not sure how you can prevent this. Even in the P2P SIP scenario (later as Penn points out), if one P2P user wants to talk to another P2P user who happens to be on a different P2P network, I am not sure peering problems will be over (you could assume everything interoperates, but if provider A provides a P2P network and provider B provides another P2P network then they may only talk through some sort of peering since provider B's infrastructure nodes or endpoints may refuse to directly accept calls from provider A's endpoints because they may think that they are insecure). I am just thinking on the fly here... On 4/16/07, Uzelac, Adam wrote: > > The point that I am trying to make is that the SIP Peering models being > drawn up here rely too much on the SP representing Bob. Bob should be > able to represent himself and how the world can reach him without the > help of a service provider. There are numerous and well documented > reasons that Bill might want a SP to represent him, for services like > authentication, anti-SPIT, etc - but Bill should have another option. > Speermint is gaining more and more of a PSTN coloring in it's attempt to > create universal connectivity by NOT using the PSTN. There's some irony > in that. > > -AU > > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Friday, April 13, 2007 10:01 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > Adam, > > I am not sure I follow your complication. The fact that > > there are two federation of Bob's uri (according to your > > example) should provide Alice a way to find Bob's uri. Are > > you concerned about Alice's discovery of Bob's uri? The > > border element will do that. In that manner it is no > > different than a classical IP route discovery with a router. > > If no deterministic way of finding out the uri ownership can > > be concluded then the next hop makes this attempt. That is > > the most logical way of doing unless their is uniform and > > well understood global master. This happens to be how PSTN > > does it and hence no difference. > > > > > > SG > > > > ----- Original Message ---- > > From: "Uzelac, Adam" > > To: speermint@ietf.org > > Sent: Friday, April 13, 2007 1:18:44 PM > > Subject: [Speermint] Re-making or Un-making the PSTN > > > > > > As I sit here working on the VoIP use-case draft, I can't > > help but thinking if we aren't just re-making the PSTN, > > instead of un-making it. > > The crux of this issue lies with the routing. At some of the > > basic constructs of next-hop routing decisions that border > > elements need to do, these use-cases are starting to smell > > more and more like PSTN-based routing look-ups. A simple > > determination of who owns the SIP-URI of the intended > > recipient can not be determined definitively, so it's just > > punted off to the next chain in the link. The ultimate > > end-point determination needs to occur before the next-hop > > decision can be made. > > If we then consider B2BUAs in the mix, it's more likely than > > not that the original calling and called parties are changed. > > I realize some of this changes due to local policy, but that > > still doesn't get to the root of the problem. > > > > For instance, say there were 2 federations where Bob > > registered his SIP-URI, so that according to members of both > > federation, to reach bob sessions should be targeted to > > bob@company.com. Now if Alice is part of a an external > > domain to those federations, and with both feds "advertising" > > reachablity to Bob, how does Alice determine next-hop? > > Basically, who owns Bob's uri? > > > > If we were to bring ENUM into the discussion, it even get's > > worse more wrought with concern due to starting with > > regulated e164. I just sharing out some thoughts. > > > > -AU > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection > > around http://mail.yahoo.com > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > ------=_Part_45137_31379257.1176752296349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess, there could be an argument that the PSTN was born out of not technical stuff, but how SPs wanted to connect to each other. That will re-surface again and again (e.g IMS and here as well). Not sure how you can prevent this.

Even in the P2P SIP scenario (later as Penn points out), if one P2P user wants to talk to another P2P user who happens to be on a different P2P network, I am not sure peering problems will be over (you could assume everything interoperates, but if provider A provides a P2P network and provider B provides another P2P network then they may only talk through some sort of peering since provider B's infrastructure nodes or endpoints may refuse to directly accept calls from provider A's endpoints because they may think that they are insecure). I am just thinking on the fly here...

On 4/16/07, Uzelac, Adam <Adam.Uzelac@globalcrossing.com> wrote:
The point that I am trying to make is that the SIP Peering models being
drawn up here rely too much on the SP representing Bob.  Bob should be
able to represent himself and how the world can reach him without the
help of a service provider.  There are numerous and well documented
reasons that Bill might want a SP to represent him, for services like
authentication, anti-SPIT, etc - but Bill should have another option.
Speermint is gaining more and more of a PSTN coloring in it's attempt to
create universal connectivity by NOT using the PSTN.  There's some irony
in that.

-AU

> -----Original Message-----
> From: Sukanta ganguly [mailto:sganguly@yahoo.com ]
> Sent: Friday, April 13, 2007 10:01 PM
> To: Uzelac, Adam; speermint@ietf.org
> Subject: Re: [Speermint] Re-making or Un-making the PSTN
>
> Adam,
>    I am not sure I follow your complication. The fact that
> there are two federation of Bob's uri (according to your
> example) should provide Alice a way to find Bob's uri. Are
> you concerned about Alice's discovery of Bob's uri? The
> border element will do that. In that manner it is no
> different than a classical IP route discovery with a router.
> If no deterministic way of finding out the uri ownership can
> be concluded then the next hop makes this attempt. That is
> the most logical way of doing unless their is uniform and
> well understood global master. This happens to be how PSTN
> does it and hence no difference.
>
>
> SG
>
> ----- Original Message ----
> From: "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>
> To: speermint@ietf.org
> Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] Re-making or Un-making the PSTN
>
>
> As I sit here working on the VoIP use-case draft, I can't
> help but thinking if we aren't just re-making the PSTN,
> instead of un-making it.
> The crux of this issue lies with the routing.  At some of the
> basic constructs of next-hop routing decisions that border
> elements need to do, these use-cases are starting to smell
> more and more like PSTN-based routing look-ups.  A simple
> determination of who owns the SIP-URI of the intended
> recipient can not be determined definitively, so it's just
> punted off to the next chain in the link.  The ultimate
> end-point determination needs to occur before the next-hop
> decision can be made.
> If we then consider B2BUAs in the mix, it's more likely than
> not that the original calling and called parties are changed.
>  I realize some of this changes due to local policy, but that
> still doesn't get to the root of the problem.
>
> For instance, say there were 2 federations where Bob
> registered his SIP-URI, so that according to members of both
> federation, to reach bob sessions should be targeted to
> bob@company.com.  Now if Alice is part of a an external
> domain to those federations, and with both feds "advertising"
> reachablity to Bob, how does Alice determine next-hop?
> Basically, who owns Bob's uri?
>
> If we were to bring ENUM into the discussion, it even get's
> worse more wrought with concern due to starting with
> regulated e164.  I just sharing out some thoughts.
>
> -AU
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection
> around http://mail.yahoo.com
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

------=_Part_45137_31379257.1176752296349-- --===============0441949108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0441949108==-- From speermint-bounces@ietf.org Mon Apr 16 15:49: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 1HdXCz-0007go-KS; Mon, 16 Apr 2007 15:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXCz-0007gj-1D for speermint@ietf.org; Mon, 16 Apr 2007 15:49:53 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdXCy-0001Ky-F7 for speermint@ietf.org; Mon, 16 Apr 2007 15:49:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] Re-making or Un-making the PSTN Date: Mon, 16 Apr 2007 21:45:55 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D7B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAAh7lk0= References: <825730.76940.qm@web90606.mail.mud.yahoo.com> From: "Stastny Richard" To: "Uzelac, Adam" , "Sukanta ganguly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >Bob should be >able to represent himself and how the world can reach him without the >help of a service provider.=20 Hmm, eh, USER ENUM? =20 But this is not used (wanted) by providers and users And, as Penn says, the scope of SPEERMINT is provider peering End-users, if they want to, may use User ENUM and RFC3263 anyway =20 Richard ________________________________ Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Gesendet: Mo 16.04.2007 17:47 An: Sukanta ganguly; speermint@ietf.org Betreff: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > Adam, > I am not sure I follow your complication. The fact that > there are two federation of Bob's uri (according to your > example) should provide Alice a way to find Bob's uri. Are > you concerned about Alice's discovery of Bob's uri? The > border element will do that. In that manner it is no > different than a classical IP route discovery with a router. > If no deterministic way of finding out the uri ownership can > be concluded then the next hop makes this attempt. That is > the most logical way of doing unless their is uniform and > well understood global master. This happens to be how PSTN > does it and hence no difference. > > > SG > > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN > > > As I sit here working on the VoIP use-case draft, I can't > help but thinking if we aren't just re-making the PSTN, > instead of un-making it. > The crux of this issue lies with the routing. At some of the > basic constructs of next-hop routing decisions that border > elements need to do, these use-cases are starting to smell > more and more like PSTN-based routing look-ups. A simple > determination of who owns the SIP-URI of the intended > recipient can not be determined definitively, so it's just > punted off to the next chain in the link. The ultimate > end-point determination needs to occur before the next-hop > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than > not that the original calling and called parties are changed. > I realize some of this changes due to local policy, but that > still doesn't get to the root of the problem. > > For instance, say there were 2 federations where Bob > registered his SIP-URI, so that according to members of both > federation, to reach bob sessions should be targeted to > bob@company.com. Now if Alice is part of a an external > domain to those federations, and with both feds "advertising" > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri?=20 > > If we were to bring ENUM into the discussion, it even get's > worse more wrought with concern due to starting with > regulated e164. I just sharing out some thoughts. > > -AU > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection > around http://mail.yahoo.com > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 16 16:04: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 1HdXQp-00013y-Sc; Mon, 16 Apr 2007 16:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXQn-00013K-Oh for speermint@ietf.org; Mon, 16 Apr 2007 16:04:09 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXQm-0004JJ-5r for speermint@ietf.org; Mon, 16 Apr 2007 16:04:09 -0400 Received: from w3uspdy19.ams.gblxint.com (w3uspdy19.ams.gblxint.com [10.60.51.69]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id A22BD9A52; Mon, 16 Apr 2007 16:04:07 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy19.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:04:07 -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: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 16 Apr 2007 16:04:06 -0400 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D7B@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAAh7lk0AAEd44A== References: <825730.76940.qm@web90606.mail.mud.yahoo.com> <32755D354E6B65498C3BD9FD496C7D466B1D7B@oefeg-s04.oefeg.loc> From: "Uzelac, Adam" To: "Stastny Richard" , "Sukanta ganguly" , X-OriginalArrivalTime: 16 Apr 2007 20:04:07.0502 (UTC) FILETIME=[63EDAEE0:01C78062] X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Consider me charter refreshed. Just needed to get grounded here on some thoughts. Back to re-making or un-making the PSTN - whichever is more appropriate. ;) Adam=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Monday, April 16, 2007 3:46 PM > To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > >Bob should be > >able to represent himself and how the world can reach him=20 > without the=20 > >help of a service provider. >=20 > Hmm, eh, USER ENUM? > =20 > But this is not used (wanted) by providers and users >=20 > And, as Penn says, the scope of SPEERMINT is provider peering >=20 > End-users, if they want to, may use User ENUM and RFC3263 anyway > =20 > Richard >=20 > ________________________________ >=20 > Von: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Gesendet: Mo 16.04.2007 17:47 > An: Sukanta ganguly; speermint@ietf.org > Betreff: RE: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > The point that I am trying to make is that the SIP Peering=20 > models being drawn up here rely too much on the SP=20 > representing Bob. Bob should be able to represent himself=20 > and how the world can reach him without the help of a service=20 > provider. There are numerous and well documented reasons=20 > that Bill might want a SP to represent him, for services like=20 > authentication, anti-SPIT, etc - but Bill should have another option. > Speermint is gaining more and more of a PSTN coloring in it's=20 > attempt to create universal connectivity by NOT using the=20 > PSTN. There's some irony in that. >=20 > -AU >=20 > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Friday, April 13, 2007 10:01 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > Adam, > > I am not sure I follow your complication. The fact that=20 > there are=20 > > two federation of Bob's uri (according to your > > example) should provide Alice a way to find Bob's uri. Are you=20 > > concerned about Alice's discovery of Bob's uri? The border element=20 > > will do that. In that manner it is no different than a classical IP=20 > > route discovery with a router. > > If no deterministic way of finding out the uri ownership can be=20 > > concluded then the next hop makes this attempt. That is the most=20 > > logical way of doing unless their is uniform and well understood=20 > > global master. This happens to be how PSTN does it and hence no=20 > > difference. > > > > > > SG > > > > ----- Original Message ---- > > From: "Uzelac, Adam" > > To: speermint@ietf.org > > Sent: Friday, April 13, 2007 1:18:44 PM > > Subject: [Speermint] Re-making or Un-making the PSTN > > > > > > As I sit here working on the VoIP use-case draft, I can't help but=20 > > thinking if we aren't just re-making the PSTN, instead of un-making=20 > > it. > > The crux of this issue lies with the routing. At some of the basic=20 > > constructs of next-hop routing decisions that border=20 > elements need to=20 > > do, these use-cases are starting to smell more and more like=20 > > PSTN-based routing look-ups. A simple determination of who=20 > owns the=20 > > SIP-URI of the intended recipient can not be determined=20 > definitively,=20 > > so it's just punted off to the next chain in the link. The=20 > ultimate=20 > > end-point determination needs to occur before the next-hop decision=20 > > can be made. > > If we then consider B2BUAs in the mix, it's more likely=20 > than not that=20 > > the original calling and called parties are changed. > > I realize some of this changes due to local policy, but that still=20 > > doesn't get to the root of the problem. > > > > For instance, say there were 2 federations where Bob registered his=20 > > SIP-URI, so that according to members of both federation,=20 > to reach bob=20 > > sessions should be targeted to bob@company.com. Now if=20 > Alice is part=20 > > of a an external domain to those federations, and with both feds=20 > > "advertising" > > reachablity to Bob, how does Alice determine next-hop? > > Basically, who owns Bob's uri?=20 > > > > If we were to bring ENUM into the discussion, it even get's=20 > worse more=20 > > wrought with concern due to starting with regulated e164. I just=20 > > sharing out some thoughts. > > > > -AU > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > http://mail.yahoo.com > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 16 18:15: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 1HdZUJ-00045r-8X; Mon, 16 Apr 2007 18:15:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdZUI-0003zL-2S for speermint@ietf.org; Mon, 16 Apr 2007 18:15:54 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdZUH-00043v-Bf for speermint@ietf.org; Mon, 16 Apr 2007 18:15:53 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Apr 2007 15:15:22 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 l3GMFGSd024104; Mon, 16 Apr 2007 15:15:16 -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 l3GMFF0c018910; Mon, 16 Apr 2007 15:15:15 -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, 16 Apr 2007 15:15: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: [Speermint] Re-making or Un-making the PSTN Date: Mon, 16 Apr 2007 15:15:14 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F5794@namail5.corp.adobe.com> In-Reply-To: <34DA635B184A644DA4588E260EC0A25A0F2D5426@ACCLUST02EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAAbPATAABkgRsA== References: <825730.76940.qm@web90606.mail.mud.yahoo.com> <34DA635B184A644DA4588E260EC0A25A0F2D5426@ACCLUST02EVS1.ugd.att.com> From: "Henry Sinnreich" To: "PFAUTZ, PENN L, ATTCORP" , "Uzelac, Adam" , "Sukanta ganguly" , X-OriginalArrivalTime: 16 Apr 2007 22:15:14.0273 (UTC) FILETIME=[B4E3AD10:01C78074] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Penn Pfautz wrote? >Pure user-to-user calls either aren't an issue or are dealt with in the >P2P SIP discussions. Do folks disagree? As pointed out by Medhavi Bhatia, peering issues exist as well when users are in different P2P networks. We can only hope that peering between overlays would avoid some of the issues discussed here, such as policies, QoS, public/private ENUM, etc., in short all the constraints inherited from the PSTN mindset and just focus on security, spam, etc. In short: Internet-minded peering. The work reported here on IM peering is a good start IMHO since it shows the huge traffic issues just for IM. The reported IM systems can also do voice and video :-) Internet-minded peering will require some work however and the present exercise may be a useful experience (what to avoid), if we learn from it. Thanks, Henry -----Original Message----- From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]=20 Sent: Monday, April 16, 2007 12:03 PM To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree?=20 Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 16 19:03: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 1HdaED-0006AS-37; Mon, 16 Apr 2007 19:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdaEB-0006AN-OJ for speermint@ietf.org; Mon, 16 Apr 2007 19:03:19 -0400 Received: from web90604.mail.mud.yahoo.com ([216.252.100.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdaEA-0005vY-V5 for speermint@ietf.org; Mon, 16 Apr 2007 19:03:19 -0400 Received: (qmail 43614 invoked by uid 60001); 16 Apr 2007 23:03:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=ZjA+4hGU4ZMwuN7sqcBuo0Cd98ia5f+LUtElu/3pqdCweJ+BIt5fl1zr+ZAD4G6LdUFNr4j+R/KbujYmI35lLZEcpLyDCK2JxQDmM3XTioM6M+IwbJq8xUcO7NNfJs2BzZtXHKQZZDlrl+3cC/YjIExPRKdQiVIU72bFoEPxa/k=; X-YMail-OSG: FrwpUnoVM1lgXXY9T2yOT2jy3rnLa7WlnPtQR92Md2X9dnv9bFID1Z3wATNbDGK5PA-- Received: from [65.113.98.146] by web90604.mail.mud.yahoo.com via HTTP; Mon, 16 Apr 2007 16:03:18 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Mon, 16 Apr 2007 16:03:18 -0700 (PDT) From: Sukanta ganguly Subject: Re: [Speermint] Re-making or Un-making the PSTN To: Henry Sinnreich , "PFAUTZ, PENN L, ATTCORP" , "Uzelac, Adam" , speermint@ietf.org MIME-Version: 1.0 Message-ID: <247462.42924.qm@web90604.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2070407120==" Errors-To: speermint-bounces@ietf.org --===============2070407120== Content-Type: multipart/alternative; boundary="0-1248104833-1176764598=:42924" --0-1248104833-1176764598=:42924 Content-Type: text/plain; charset=ascii Henry, "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings. So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding. Thanks SG ----- Original Message ---- From: Henry Sinnreich To: "PFAUTZ, PENN L, ATTCORP" ; "Uzelac, Adam" ; Sukanta ganguly ; speermint@ietf.org Sent: Monday, April 16, 2007 3:15:14 PM Subject: RE: [Speermint] Re-making or Un-making the PSTN Penn Pfautz wrote? >Pure user-to-user calls either aren't an issue or are dealt with in the >P2P SIP discussions. Do folks disagree? As pointed out by Medhavi Bhatia, peering issues exist as well when users are in different P2P networks. We can only hope that peering between overlays would avoid some of the issues discussed here, such as policies, QoS, public/private ENUM, etc., in short all the constraints inherited from the PSTN mindset and just focus on security, spam, etc. In short: Internet-minded peering. The work reported here on IM peering is a good start IMHO since it shows the huge traffic issues just for IM. The reported IM systems can also do voice and video :-) Internet-minded peering will require some work however and the present exercise may be a useful experience (what to avoid), if we learn from it. Thanks, Henry -----Original Message----- From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] Sent: Monday, April 16, 2007 12:03 PM To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree? Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > Adam, > I am not sure I follow your complication. The fact that > there are two federation of Bob's uri (according to your > example) should provide Alice a way to find Bob's uri. Are > you concerned about Alice's discovery of Bob's uri? The > border element will do that. In that manner it is no > different than a classical IP route discovery with a router. > If no deterministic way of finding out the uri ownership can > be concluded then the next hop makes this attempt. That is > the most logical way of doing unless their is uniform and > well understood global master. This happens to be how PSTN > does it and hence no difference. > > > SG > > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN > > > As I sit here working on the VoIP use-case draft, I can't > help but thinking if we aren't just re-making the PSTN, > instead of un-making it. > The crux of this issue lies with the routing. At some of the > basic constructs of next-hop routing decisions that border > elements need to do, these use-cases are starting to smell > more and more like PSTN-based routing look-ups. A simple > determination of who owns the SIP-URI of the intended > recipient can not be determined definitively, so it's just > punted off to the next chain in the link. The ultimate > end-point determination needs to occur before the next-hop > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than > not that the original calling and called parties are changed. > I realize some of this changes due to local policy, but that > still doesn't get to the root of the problem. > > For instance, say there were 2 federations where Bob > registered his SIP-URI, so that according to members of both > federation, to reach bob sessions should be targeted to > bob@company.com. Now if Alice is part of a an external > domain to those federations, and with both feds "advertising" > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? > > If we were to bring ENUM into the discussion, it even get's > worse more wrought with concern due to starting with > regulated e164. I just sharing out some thoughts. > > -AU > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection > around http://mail.yahoo.com > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-1248104833-1176764598=:42924 Content-Type: text/html; charset=ascii
Henry,
   "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings.
   So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding.
 
Thanks
SG

----- Original Message ----
From: Henry Sinnreich <hsinnrei@adobe.com>
To: "PFAUTZ, PENN L, ATTCORP" <ppfautz@att.com>; "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>; Sukanta ganguly <sganguly@yahoo.com>; speermint@ietf.org
Sent: Monday, April 16, 2007 3:15:14 PM
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz wrote?

>Pure user-to-user calls either aren't an issue or are dealt with in the
>P2P SIP discussions. Do folks disagree?

As pointed out by Medhavi Bhatia, peering issues exist as well when
users are in different P2P networks.

We can only hope that peering between overlays would avoid some of the
issues discussed here, such as policies, QoS, public/private ENUM, etc.,
in short all the constraints inherited from the PSTN mindset and just
focus on security, spam, etc. In short: Internet-minded peering.

The work reported here on IM peering is a good start IMHO since it shows
the huge traffic issues just for IM. The reported IM systems can also do
voice and video :-)

Internet-minded peering will require some work however and the present
exercise may be a useful experience (what to avoid), if we learn from
it.

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org
Subject: RE: [Speermint] Re-making or Un-making the PSTN

I thought, however, that the point of Speermint *was* to deal with
peering between service providers.
Pure user-to-user calls either aren't an issue or are dealt with in the
P2P SIP discussions. Do folks disagree?
Quoting from the charter:
"The most focused deliverables of SPEERMINT are best current practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed."

Did I fall off the wagon somewhere?

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; speermint@ietf.org
Subject: RE: [Speermint] Re-making or Un-making the PSTN

The point that I am trying to make is that the SIP Peering models being
drawn up here rely too much on the SP representing Bob.  Bob should be
able to represent himself and how the world can reach him without the
help of a service provider.  There are numerous and well documented
reasons that Bill might want a SP to represent him, for services like
authentication, anti-SPIT, etc - but Bill should have another option.
Speermint is gaining more and more of a PSTN coloring in it's attempt to
create universal connectivity by NOT using the PSTN.  There's some irony
in that.

-AU

> -----Original Message-----
> From: Sukanta ganguly [mailto:sganguly@yahoo.com]
> Sent: Friday, April 13, 2007 10:01 PM
> To: Uzelac, Adam; speermint@ietf.org
> Subject: Re: [Speermint] Re-making or Un-making the PSTN
>
> Adam,
>    I am not sure I follow your complication. The fact that
> there are two federation of Bob's uri (according to your
> example) should provide Alice a way to find Bob's uri. Are
> you concerned about Alice's discovery of Bob's uri? The
> border element will do that. In that manner it is no
> different than a classical IP route discovery with a router.
> If no deterministic way of finding out the uri ownership can
> be concluded then the next hop makes this attempt. That is
> the most logical way of doing unless their is uniform and
> well understood global master. This happens to be how PSTN
> does it and hence no difference.
>
>
> SG
>
> ----- Original Message ----
> From: "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>
> To: speermint@ietf.org
> Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] Re-making or Un-making the PSTN
>
>
> As I sit here working on the VoIP use-case draft, I can't
> help but thinking if we aren't just re-making the PSTN,
> instead of un-making it.
> The crux of this issue lies with the routing.  At some of the
> basic constructs of next-hop routing decisions that border
> elements need to do, these use-cases are starting to smell
> more and more like PSTN-based routing look-ups.  A simple
> determination of who owns the SIP-URI of the intended
> recipient can not be determined definitively, so it's just
> punted off to the next chain in the link.  The ultimate
> end-point determination needs to occur before the next-hop
> decision can be made.
> If we then consider B2BUAs in the mix, it's more likely than
> not that the original calling and called parties are changed.
>  I realize some of this changes due to local policy, but that
> still doesn't get to the root of the problem.
>
> For instance, say there were 2 federations where Bob
> registered his SIP-URI, so that according to members of both
> federation, to reach bob sessions should be targeted to
> bob@company.com.  Now if Alice is part of a an external
> domain to those federations, and with both feds "advertising"
> reachablity to Bob, how does Alice determine next-hop?
> Basically, who owns Bob's uri?  
>
> If we were to bring ENUM into the discussion, it even get's
> worse more wrought with concern due to starting with
> regulated e164.  I just sharing out some thoughts.
>
> -AU
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection
> around http://mail.yahoo.com
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-1248104833-1176764598=:42924-- --===============2070407120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============2070407120==-- From speermint-bounces@ietf.org Mon Apr 16 20:09: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 1HdbFn-0002ge-Ts; Mon, 16 Apr 2007 20:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdbFm-0002ZI-4u for speermint@ietf.org; Mon, 16 Apr 2007 20:09:02 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdbDn-0006iq-Jp for speermint@ietf.org; Mon, 16 Apr 2007 20:07:01 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Apr 2007 17:06:29 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 l3H05tD1009726; Mon, 16 Apr 2007 17:05:55 -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 l3H06BI9024052; Mon, 16 Apr 2007 17:06:11 -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, 16 Apr 2007 17:06:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 16 Apr 2007 17:02:27 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F57ED@namail5.corp.adobe.com> In-Reply-To: <247462.42924.qm@web90604.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceAe3CqhBhtyakPQuWTxOfN7gCfNAABu5HQ References: <247462.42924.qm@web90604.mail.mud.yahoo.com> From: "Henry Sinnreich" To: "Sukanta ganguly" , "PFAUTZ, PENN L, ATTCORP" , "Uzelac, Adam" , X-OriginalArrivalTime: 17 Apr 2007 00:06:28.0979 (UTC) FILETIME=[3F52FC30:01C78084] X-Spam-Score: 0.1 (/) X-Scan-Signature: 093e26f1a1ce195f411d3b0c3b9d5e74 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0365834719==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0365834719== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78084.3B5C4651" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78084.3B5C4651 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think we need to qualify the peering topic a little more so that a clear understanding. =20 I agree and the best starting point would be some application scenarios for P2P overlay operators, if they agree to share their product view in the IETF.=20 =20 This may not happen any time soon however, for similar reasons as in VoIP: Policies are not gladly shared between competitors.=20 Competition was invoked as one of the reasons why 'best effort' is the only reasonable policy on the Internet. =20 It will be interesting to see the extent of peering beyond best effort that will actually be deployed, except in closed federations that could be exposed to law suits of various types... =20 Thanks, Henry =20 =20 =20 ________________________________ From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 Sent: Monday, April 16, 2007 4:03 PM To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN =20 Henry, "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings. So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding. =20 Thanks SG ----- Original Message ---- From: Henry Sinnreich To: "PFAUTZ, PENN L, ATTCORP" ; "Uzelac, Adam" ; Sukanta ganguly ; speermint@ietf.org Sent: Monday, April 16, 2007 3:15:14 PM Subject: RE: [Speermint] Re-making or Un-making the PSTN Penn Pfautz wrote? >Pure user-to-user calls either aren't an issue or are dealt with in the >P2P SIP discussions. Do folks disagree? As pointed out by Medhavi Bhatia, peering issues exist as well when users are in different P2P networks. We can only hope that peering between overlays would avoid some of the issues discussed here, such as policies, QoS, public/private ENUM, etc., in short all the constraints inherited from the PSTN mindset and just focus on security, spam, etc. In short: Internet-minded peering. The work reported here on IM peering is a good start IMHO since it shows the huge traffic issues just for IM. The reported IM systems can also do voice and video :-) Internet-minded peering will require some work however and the present exercise may be a useful experience (what to avoid), if we learn from it. Thanks, Henry -----Original Message----- From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]=20 Sent: Monday, April 16, 2007 12:03 PM To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree?=20 Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com =20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =20 =20 ________________________________ Ahhh...imagining that irresistible "new car" smell? Check out new cars at Yahoo! Autos. =20 ------_=_NextPart_001_01C78084.3B5C4651 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I think we need = to qualify the peering topic a little more so that a clear = understanding.

 

I agree and the best starting point = would be some application scenarios for P2P overlay operators, if they agree = to share their product view in the IETF.

 

This may not happen any time soon = however, for similar reasons as in VoIP: Policies are not gladly shared between competitors.

Competition was invoked as one of = the reasons why ‘best effort’ is the only reasonable policy on = the Internet.

 

It will be interesting to see the = extent of peering beyond best effort that will actually be deployed, except in = closed federations that could be exposed to law suits of various = types…

 

Thanks, = Henry

 

 

 

From: = Sukanta ganguly [mailto:sganguly@yahoo.com] =
Sent: Monday, April 16, = 2007 4:03 PM
To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org
Subject: Re: [Speermint] = Re-making or Un-making the PSTN

 

Henry,

   "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in = essence, it still needs to co-exist with the end-point peering resolution = policies. What I was getting as was the fact that it was no different from any = peer-to-peer discovery and the fact that the advertiser needs to have control over = how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can = be hidden inside corp databases and then we had the NAT folks who build a = logical manner to handle this mappings.

   So I am not sure we are getting to the right mode = of understanding the problem here. I think we need to qualify the peering = topic a little more so that a clear understanding.

 

Thanks

SG

----- Original = Message ----
From: Henry Sinnreich <hsinnrei@adobe.com>
To: "PFAUTZ, PENN L, ATTCORP" <ppfautz@att.com>; = "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>; Sukanta ganguly <sganguly@yahoo.com>; speermint@ietf.org
Sent: Monday, April 16, 2007 3:15:14 PM
Subject: RE: [Speermint] Re-making or Un-making the = PSTN

Penn Pfautz wrote?

>Pure user-to-user calls either aren't an issue or are dealt with in = the
>P2P SIP discussions. Do folks disagree?

As pointed out by Medhavi Bhatia, peering issues exist as well when
users are in different P2P networks.

We can only hope that peering between overlays would avoid some of = the
issues discussed here, such as policies, QoS, public/private ENUM, = etc.,
in short all the constraints inherited from the PSTN mindset and = just
focus on security, spam, etc. In short: Internet-minded peering.

The work reported here on IM peering is a good start IMHO since it = shows
the huge traffic issues just for IM. The reported IM systems can also = do
voice and video :-)

Internet-minded peering will require some work however and the = present
exercise may be a useful experience (what to avoid), if we learn = from
it.

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; = Sukanta ganguly; speermint@ietf.org
Subject: RE: [Speermint] Re-making or Un-making the PSTN

I thought, however, that the point of Speermint *was* to deal with
peering between service providers.
Pure user-to-user calls either aren't an issue or are dealt with in = the
P2P SIP discussions. Do folks disagree?
Quoting from the charter:
"The most focused deliverables of SPEERMINT are best current = practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed."

Did I fall off the wagon somewhere?

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Uzelac, Adam = [mailto:Adam.Uzelac@globalcrossing.com]
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; = speermint@ietf.org
Subject: RE: [Speermint] Re-making or Un-making the PSTN

The point that I am trying to make is that the SIP Peering models = being
drawn up here rely too much on the SP representing Bob.  Bob = should be
able to represent himself and how the world can reach him without = the
help of a service provider.  There are numerous and well = documented
reasons that Bill might want a SP to represent him, for services = like
authentication, anti-SPIT, etc - but Bill should have another = option.
Speermint is gaining more and more of a PSTN coloring in it's attempt = to
create universal connectivity by NOT using the PSTN.  There's = some irony
in that.

-AU

> -----Original Message-----
> From: Sukanta ganguly [mailto:sganguly@yahoo.com]
> Sent: Friday, April 13, 2007 10:01 PM
> To: Uzelac, Adam; = speermint@ietf.org
> Subject: Re: [Speermint] Re-making or Un-making the PSTN
>
> Adam,
>    I am not sure I follow your complication. = The fact that
> there are two federation of Bob's uri (according to your
> example) should provide Alice a way to find Bob's uri. Are
> you concerned about Alice's discovery of Bob's uri? The
> border element will do that. In that manner it is no
> different than a classical IP route discovery with a router.
> If no deterministic way of finding out the uri ownership can
> be concluded then the next hop makes this attempt. That is
> the most logical way of doing unless their is uniform and
> well understood global master. This happens to be how PSTN
> does it and hence no difference.
>
>
> SG
>
> ----- Original Message ----
> From: "Uzelac, = Adam" <Adam.Uzelac@globalcrossing.com>
> To: speermint@ietf.org
> Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] Re-making or Un-making the PSTN
>
>
> As I sit here working on the VoIP use-case draft, I can't
> help but thinking if we aren't just re-making the PSTN,
> instead of un-making it.
> The crux of this issue lies with the routing.  At some of = the
> basic constructs of next-hop routing decisions that border
> elements need to do, these use-cases are starting to smell
> more and more like PSTN-based routing look-ups.  A simple =
> determination of who owns the SIP-URI of the intended
> recipient can not be determined definitively, so it's just
> punted off to the next chain in the link.  The ultimate =
> end-point determination needs to occur before the next-hop
> decision can be made.
> If we then consider B2BUAs in the mix, it's more likely than
> not that the original calling and called parties are changed.
>  I realize some of this changes due to local policy, but = that
> still doesn't get to the root of the problem.
>
> For instance, say there were 2 federations where Bob
> registered his SIP-URI, so that according to members of both
> federation, to reach bob sessions should be targeted to
> bob@company.com.  Now if Alice is part of a an external
> domain to those federations, and with both feds = "advertising"
> reachablity to Bob, how does Alice determine next-hop?
> Basically, who owns Bob's uri?  
>
> If we were to bring ENUM into the discussion, it even get's
> worse more wrought with concern due to starting with
> regulated e164.  I just sharing out some thoughts.
>
> -AU
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint >
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection =
> around http://mail.yahoo.com
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint
_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

 

 

Ahhh...imagining that irresistible "new car" = smell?
Check out new cars at Yahoo! Autos.

------_=_NextPart_001_01C78084.3B5C4651-- --===============0365834719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0365834719==-- From speermint-bounces@ietf.org Tue Apr 17 04:33: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 1Hdj7c-0006da-3y; Tue, 17 Apr 2007 04:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdj7a-0006Y3-He for speermint@ietf.org; Tue, 17 Apr 2007 04:33:06 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdj7Z-0001IR-PZ for speermint@ietf.org; Tue, 17 Apr 2007 04:33:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2007 10:32:56 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E03@oefeg-s04.oefeg.loc> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226F5794@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP Peering (was: Re-making or Un-making the PSTN) Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAAbPATAABkgRsAAVyAgg From: "Stastny Richard" To: "Henry Sinnreich" , "PFAUTZ, PENN L, ATTCORP" , "Uzelac, Adam" , "Sukanta ganguly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Subject: [Speermint] P2PSIP Peering (was: Re-making or Un-making the PSTN) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Hi Henry, I do not see any difference in P2PSIP peering and SIP Client-Server Peering Both is peering of administrative domains One can assume that P2PSIP peering may use direct media stream between=20 clients, but this may also be the case in client-server peering. =20 > As pointed out by Medhavi Bhatia, peering issues exist as well when > users are in different P2P networks. >=20 > We can only hope that peering between overlays would avoid some of the > issues discussed here, such as policies, QoS, public/private ENUM, etc., > in short all the constraints inherited from the PSTN mindset and just > focus on security, spam, etc. In short: Internet-minded peering. Nice you call ENUM inherited from the PSTN mindset ;-) Serious, there is no difference in P2PSIP peering and CS-Peering You can do it Internet-minded or PSTN-minded >=20 > The work reported here on IM peering is a good start IMHO since it shows > the huge traffic issues just for IM. The reported IM systems can also do > voice and video :-) >=20 > Internet-minded peering will require some work however and the present > exercise may be a useful experience (what to avoid), if we learn from > it. Correct: Internet-minded (e-mail?) has some problems, most of them can be resolved with proper identities Richard >=20 > Thanks, Henry >=20 > -----Original Message----- > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > Sent: Monday, April 16, 2007 12:03 PM > To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > I thought, however, that the point of Speermint *was* to deal with > peering between service providers. > Pure user-to-user calls either aren't an issue or are dealt with in the > P2P SIP discussions. Do folks disagree? > Quoting from the charter: > "The most focused deliverables of SPEERMINT are best current practices > regarding exchange of real-time sessions among VoIP and other > real-time application service providers and, in particular, how > such calls are routed." >=20 > Did I fall off the wagon somewhere? >=20 > Penn Pfautz > AT&T Global Access Management > +1-732-420-4962 >=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Monday, April 16, 2007 11:48 AM > To: Sukanta ganguly; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > The point that I am trying to make is that the SIP Peering models being > drawn up here rely too much on the SP representing Bob. Bob should be > able to represent himself and how the world can reach him without the > help of a service provider. There are numerous and well documented > reasons that Bill might want a SP to represent him, for services like > authentication, anti-SPIT, etc - but Bill should have another option. > Speermint is gaining more and more of a PSTN coloring in it's attempt to > create universal connectivity by NOT using the PSTN. There's some irony > in that. >=20 > -AU >=20 > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Friday, April 13, 2007 10:01 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > Adam, > > I am not sure I follow your complication. The fact that > > there are two federation of Bob's uri (according to your > > example) should provide Alice a way to find Bob's uri. Are > > you concerned about Alice's discovery of Bob's uri? The > > border element will do that. In that manner it is no > > different than a classical IP route discovery with a router. > > If no deterministic way of finding out the uri ownership can > > be concluded then the next hop makes this attempt. That is > > the most logical way of doing unless their is uniform and > > well understood global master. This happens to be how PSTN > > does it and hence no difference. > > > > > > SG > > > > ----- Original Message ---- > > From: "Uzelac, Adam" > > To: speermint@ietf.org > > Sent: Friday, April 13, 2007 1:18:44 PM > > Subject: [Speermint] Re-making or Un-making the PSTN > > > > > > As I sit here working on the VoIP use-case draft, I can't > > help but thinking if we aren't just re-making the PSTN, > > instead of un-making it. > > The crux of this issue lies with the routing. At some of the > > basic constructs of next-hop routing decisions that border > > elements need to do, these use-cases are starting to smell > > more and more like PSTN-based routing look-ups. A simple > > determination of who owns the SIP-URI of the intended > > recipient can not be determined definitively, so it's just > > punted off to the next chain in the link. The ultimate > > end-point determination needs to occur before the next-hop > > decision can be made. > > If we then consider B2BUAs in the mix, it's more likely than > > not that the original calling and called parties are changed. > > I realize some of this changes due to local policy, but that > > still doesn't get to the root of the problem. > > > > For instance, say there were 2 federations where Bob > > registered his SIP-URI, so that according to members of both > > federation, to reach bob sessions should be targeted to > > bob@company.com. Now if Alice is part of a an external > > domain to those federations, and with both feds "advertising" > > reachablity to Bob, how does Alice determine next-hop? > > Basically, who owns Bob's uri? > > > > If we were to bring ENUM into the discussion, it even get's > > worse more wrought with concern due to starting with > > regulated e164. I just sharing out some thoughts. > > > > -AU > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection > > around http://mail.yahoo.com > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 09:40: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 1HdnvP-0001m5-Uc; Tue, 17 Apr 2007 09:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnvO-0001lu-OX for speermint@ietf.org; Tue, 17 Apr 2007 09:40:50 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdnvM-00035P-0V for speermint@ietf.org; Tue, 17 Apr 2007 09:40:50 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id AB2AE9546; Tue, 17 Apr 2007 09:40:45 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 09:40:45 -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 Date: Tue, 17 Apr 2007 09:40:44 -0400 Message-ID: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E03@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP Peering (was: Re-making or Un-making the PSTN) Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAAbPATAABkgRsAAVyAggAArr1CA= References: <24CCCC428EFEA2469BF046DB3C7A8D226F5794@namail5.corp.adobe.com> <32755D354E6B65498C3BD9FD496C7D46646E03@oefeg-s04.oefeg.loc> From: "Uzelac, Adam" To: "Stastny Richard" , "Henry Sinnreich" , "PFAUTZ, PENN L, ATTCORP" , "Sukanta ganguly" , X-OriginalArrivalTime: 17 Apr 2007 13:40:45.0348 (UTC) FILETIME=[FFFD4640:01C780F5] X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: Subject: [Speermint] RE: P2PSIP Peering (was: Re-making or Un-making the PSTN) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I completely agree with Richard. I have been following the P2PSIP working group for some time now, and I see no difference between peering between 2 overlays, and peering between to SIP VSP. In terms of charters, the only difference is the voice-centric focus of Speermint. I think that it's going to be very interesting to observe the path of the P2PSIP working group on this front. Without peering between overlay capabilities, yet another method to build an "Island" will be created. I acknowledge this would be a "better" self-governing/free-market type of island, versus the monopolistic PSTN type - but an "island" nonetheless. Adam > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, April 17, 2007 4:33 AM > To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam;=20 > Sukanta ganguly; speermint@ietf.org > Subject: P2PSIP Peering (was: Re-making or Un-making the PSTN) >=20 > Hi Henry, >=20 > I do not see any difference in P2PSIP peering and SIP=20 > Client-Server Peering >=20 > Both is peering of administrative domains >=20 > One can assume that P2PSIP peering may use direct media=20 > stream between clients, but this may also be the case in=20 > client-server peering. > =20 > > As pointed out by Medhavi Bhatia, peering issues exist as well when=20 > > users are in different P2P networks. > >=20 > > We can only hope that peering between overlays would avoid=20 > some of the=20 > > issues discussed here, such as policies, QoS, public/private ENUM, > etc., > > in short all the constraints inherited from the PSTN=20 > mindset and just=20 > > focus on security, spam, etc. In short: Internet-minded peering. >=20 > Nice you call ENUM inherited from the PSTN mindset ;-) >=20 > Serious, there is no difference in P2PSIP peering and=20 > CS-Peering You can do it Internet-minded or PSTN-minded >=20 > >=20 > > The work reported here on IM peering is a good start IMHO since it > shows > > the huge traffic issues just for IM. The reported IM=20 > systems can also > do > > voice and video :-) > >=20 > > Internet-minded peering will require some work however and=20 > the present=20 > > exercise may be a useful experience (what to avoid), if we=20 > learn from=20 > > it. >=20 > Correct: Internet-minded (e-mail?) has some problems, most of=20 > them can be resolved with proper identities >=20 > Richard >=20 > >=20 > > Thanks, Henry > >=20 > > -----Original Message----- > > From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com] > > Sent: Monday, April 16, 2007 12:03 PM > > To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > >=20 > > I thought, however, that the point of Speermint *was* to deal with=20 > > peering between service providers. > > Pure user-to-user calls either aren't an issue or are dealt with in > the > > P2P SIP discussions. Do folks disagree? > > Quoting from the charter: > > "The most focused deliverables of SPEERMINT are best=20 > current practices=20 > > regarding exchange of real-time sessions among VoIP and other=20 > > real-time application service providers and, in particular,=20 > how such=20 > > calls are routed." > >=20 > > Did I fall off the wagon somewhere? > >=20 > > Penn Pfautz > > AT&T Global Access Management > > +1-732-420-4962 > >=20 > > -----Original Message----- > > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > > Sent: Monday, April 16, 2007 11:48 AM > > To: Sukanta ganguly; speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > >=20 > > The point that I am trying to make is that the SIP Peering models > being > > drawn up here rely too much on the SP representing Bob. =20 > Bob should be=20 > > able to represent himself and how the world can reach him=20 > without the=20 > > help of a service provider. There are numerous and well documented=20 > > reasons that Bill might want a SP to represent him, for=20 > services like=20 > > authentication, anti-SPIT, etc - but Bill should have=20 > another option. > > Speermint is gaining more and more of a PSTN coloring in=20 > it's attempt > to > > create universal connectivity by NOT using the PSTN. There's some > irony > > in that. > >=20 > > -AU > >=20 > > > -----Original Message----- > > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > > Sent: Friday, April 13, 2007 10:01 PM > > > To: Uzelac, Adam; speermint@ietf.org > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > > > Adam, > > > I am not sure I follow your complication. The fact=20 > that there are=20 > > > two federation of Bob's uri (according to your > > > example) should provide Alice a way to find Bob's uri. Are you=20 > > > concerned about Alice's discovery of Bob's uri? The=20 > border element=20 > > > will do that. In that manner it is no different than a=20 > classical IP=20 > > > route discovery with a router. > > > If no deterministic way of finding out the uri ownership can be=20 > > > concluded then the next hop makes this attempt. That is the most=20 > > > logical way of doing unless their is uniform and well understood=20 > > > global master. This happens to be how PSTN does it and hence no=20 > > > difference. > > > > > > > > > SG > > > > > > ----- Original Message ---- > > > From: "Uzelac, Adam" > > > To: speermint@ietf.org > > > Sent: Friday, April 13, 2007 1:18:44 PM > > > Subject: [Speermint] Re-making or Un-making the PSTN > > > > > > > > > As I sit here working on the VoIP use-case draft, I can't=20 > help but=20 > > > thinking if we aren't just re-making the PSTN, instead of=20 > un-making=20 > > > it. > > > The crux of this issue lies with the routing. At some of=20 > the basic=20 > > > constructs of next-hop routing decisions that border=20 > elements need=20 > > > to do, these use-cases are starting to smell more and more like=20 > > > PSTN-based routing look-ups. A simple determination of=20 > who owns the=20 > > > SIP-URI of the intended recipient can not be determined=20 > > > definitively, so it's just punted off to the next chain=20 > in the link. =20 > > > The ultimate end-point determination needs to occur before the=20 > > > next-hop decision can be made. > > > If we then consider B2BUAs in the mix, it's more likely than not=20 > > > that the original calling and called parties are changed. > > > I realize some of this changes due to local policy, but=20 > that still=20 > > > doesn't get to the root of the problem. > > > > > > For instance, say there were 2 federations where Bob=20 > registered his=20 > > > SIP-URI, so that according to members of both federation,=20 > to reach=20 > > > bob sessions should be targeted to bob@company.com. Now=20 > if Alice is=20 > > > part of a an external domain to those federations, and with both=20 > > > feds "advertising" > > > reachablity to Bob, how does Alice determine next-hop? > > > Basically, who owns Bob's uri? > > > > > > If we were to bring ENUM into the discussion, it even get's worse=20 > > > more wrought with concern due to starting with regulated e164. I=20 > > > just sharing out some thoughts. > > > > > > -AU > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > > http://mail.yahoo.com > > > > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 10:04: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 1HdoIT-0004Vz-8p; Tue, 17 Apr 2007 10:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoIR-0004Vr-5h for speermint@ietf.org; Tue, 17 Apr 2007 10:04:39 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdoIQ-0007FL-Ag for speermint@ietf.org; Tue, 17 Apr 2007 10:04:39 -0400 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l3HE3hda009545; Tue, 17 Apr 2007 10:03:43 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 10:03:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 10:03:35 -0400 Message-ID: <768BEB5E70C897468D015E23EDCC304E021A3334@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <247462.42924.qm@web90604.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceAfZNsL7UMo2m6StGH4rVOyyXOfwAeAnug From: "Chauhan, Sanjeev" To: "Sukanta ganguly" , "Henry Sinnreich" , "PFAUTZ, PENN L, ATTCORP" , "Uzelac, Adam" , X-OriginalArrivalTime: 17 Apr 2007 14:03:37.0037 (UTC) FILETIME=[319467D0:01C780F9] X-Spam-Score: 0.1 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0039079243==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0039079243== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C780F9.3119C70E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C780F9.3119C70E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable my 0.02 cents -=20 =20 - in the dns world the issue is simpler - there exists one authoratative database where the owner of the domain lists how the domain can be discovered. the peer (or end customer) is not given a choice.=20 =20 - in ip-communication (ie voip, im ...) world - both the originating and terminating parties want to have choices (ie control) the originating party wants to ensure the call is delivered to the correct end-point for reasons like a. avoid customer service issues b. for security reasons c. .. the terminating party wants to ensure it only gets the calls that it should be receiving because a. reduce extraneous traffic on network b. keep QoS=20 c. avoid transiting traffic that it cannot charge for.=20 d. ... =20 in the above i have assumed peering b/w service providers - this could be extended to peering b/w end-customers.=20 =20 going back to the original example where 2 service providers (or federation) have claimed to be able to deliver IMs to bob@company - and alice@company2 is trying to reach bob - the routing decision on which one to send should be based on a combination of=20 - originating parties peering relation with the 2 federations - federations peering relation with the originating party - industry source (enum directory) that provides 3rd-party authoratative information.=20 =20 -sanjeev =20 ________________________________ From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 Sent: Monday, April 16, 2007 7:03 PM To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Henry, "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings. So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding. =20 Thanks SG ----- Original Message ---- From: Henry Sinnreich To: "PFAUTZ, PENN L, ATTCORP" ; "Uzelac, Adam" ; Sukanta ganguly ; speermint@ietf.org Sent: Monday, April 16, 2007 3:15:14 PM Subject: RE: [Speermint] Re-making or Un-making the PSTN Penn Pfautz wrote? >Pure user-to-user calls either aren't an issue or are dealt with in the >P2P SIP discussions. Do folks disagree? As pointed out by Medhavi Bhatia, peering issues exist as well when users are in different P2P networks. We can only hope that peering between overlays would avoid some of the issues discussed here, such as policies, QoS, public/private ENUM, etc., in short all the constraints inherited from the PSTN mindset and just focus on security, spam, etc. In short: Internet-minded peering. The work reported here on IM peering is a good start IMHO since it shows the huge traffic issues just for IM. The reported IM systems can also do voice and video :-) Internet-minded peering will require some work however and the present exercise may be a useful experience (what to avoid), if we learn from it. Thanks, Henry -----Original Message----- From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]=20 Sent: Monday, April 16, 2007 12:03 PM To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree?=20 Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com =20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ________________________________ Ahhh...imagining that irresistible "new car" smell? Check out new cars at Yahoo! Autos. =20 ------_=_NextPart_001_01C780F9.3119C70E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
my 0.02 cents -
 
- in the dns world the issue is simpler - there = exists one=20 authoratative database where the owner of the domain lists how the = domain can be=20 discovered. the peer (or end customer) is not given a choice.=20
 
- in ip-communication (ie voip, im ...) world - = both the=20 originating and terminating parties want to have choices (ie=20 control)
    the originating party = wants to=20 ensure the call is delivered to the correct end-point = for reasons=20 like
         a.=20 avoid customer service issues
         b. for=20 security reasons
         c.=20 ..
    the terminating party = wants to=20 ensure it only gets the calls that it should be receiving=20 because
         a. reduce=20 extraneous traffic on network
         b.=20 keep QoS
         c. avoid=20 transiting traffic that it cannot charge for.
         d.=20 ...
 
in the above i have assumed peering b/w service = providers -=20 this could be extended to peering b/w end-customers. =
 
going back to the original example where 2 = service=20 providers (or federation) have claimed to be able to deliver IMs to bob@company - and alice@company2 is trying to reach bob = - the=20 routing decision on which one to send should be based on a combination = of=20
 - originating parties peering relation = with the 2=20 federations
 - federations peering relation with the = originating=20 party
 - industry source (enum directory) that=20 provides 3rd-party authoratative information.
 
-sanjeev
 
From: Sukanta ganguly=20 [mailto:sganguly@yahoo.com]
Sent: Monday, April 16, 2007 7:03 = PM
To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; = speermint@ietf.org
Subject: Re: [Speermint] Re-making or = Un-making the=20 PSTN

Henry,   =20 "Internet-minded" peering can work as aon overlay, not to the extent of=20 violating the internal policies. So in essence, it still needs to = co-exist with=20 the end-point peering resolution policies. What I was getting as was the = fact=20 that it was no different from any peer-to-peer discovery and the fact = that the=20 advertiser needs to have control over how he/she can be discovered. This = is how=20 we did in the DNS world. Ofcourse, corporations came along with m-n = mappings so=20 that users information can be hidden inside corp databases and then we = had the=20 NAT folks who build a logical manner to handle this mappings.   =20 So I am not sure we are getting to the right mode of understanding the = problem=20 here. I think we need to qualify the peering topic a little more so that = a clear=20 understanding.   Thanks SG

-----=20 Original Message ----
From: Henry Sinnreich = <hsinnrei@adobe.com>
To:=20 "PFAUTZ, PENN L, ATTCORP" <ppfautz@att.com>; "Uzelac, Adam"=20 <Adam.Uzelac@globalcrossing.com>; Sukanta ganguly=20 <sganguly@yahoo.com>; speermint@ietf.org
Sent: Monday, April = 16, 2007=20 3:15:14 PM
Subject: RE: [Speermint] Re-making or Un-making the = PSTN

Penn Pfautz wrote?

>Pure user-to-user calls either aren't = an=20 issue or are dealt with in the
>P2P SIP discussions. Do folks=20 disagree?

As pointed out by Medhavi Bhatia, peering issues exist = as well=20 when
users are in different P2P networks.

We can only hope = that=20 peering between overlays would avoid some of the
issues discussed = here, such=20 as policies, QoS, public/private ENUM, etc.,
in short all the = constraints=20 inherited from the PSTN mindset and just
focus on security, spam, = etc. In=20 short: Internet-minded peering.

The work reported here on IM = peering is a=20 good start IMHO since it shows
the huge traffic issues just for IM. = The=20 reported IM systems can also do
voice and video = :-)

Internet-minded=20 peering will require some work however and the present
exercise may = be a=20 useful experience (what to avoid), if we learn = from
it.

Thanks,=20 Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP = [mailto:ppfautz@att.com]
Sent: Monday, April 16, 2007 12:03 = PM
To:=20 Uzelac, Adam; Sukanta ganguly; speermint@ietf.org
Subject: RE: = [Speermint]=20 Re-making or Un-making the PSTN

I thought, however, that the = point of=20 Speermint *was* to deal with
peering between service = providers.
Pure=20 user-to-user calls either aren't an issue or are dealt with in = the
P2P SIP=20 discussions. Do folks disagree?
Quoting from the charter:
"The = most=20 focused deliverables of SPEERMINT are best current = practices
regarding=20 exchange of real-time sessions among VoIP and other
real-time = application=20 service providers and, in particular, how
such calls are = routed."

Did=20 I fall off the wagon somewhere?

Penn Pfautz
AT&T Global = Access=20 Management
+1-732-420-4962

-----Original Message-----
From: = Uzelac,=20 Adam [mailto:Adam.Uzelac@globalcrossing.com]
Sent: Monday, April 16, = 2007=20 11:48 AM
To: Sukanta ganguly; speermint@ietf.org
Subject: RE: = [Speermint]=20 Re-making or Un-making the PSTN

The point that I am trying to = make is=20 that the SIP Peering models being
drawn up here rely too much on the = SP=20 representing Bob.  Bob should be
able to represent himself = and how=20 the world can reach him without the
help of a service=20 provider.  There are numerous and well documented
reasons = that Bill=20 might want a SP to represent him, for services like
authentication,=20 anti-SPIT, etc - but Bill should have another option.
Speermint is = gaining=20 more and more of a PSTN coloring in it's attempt to
create universal=20 connectivity by NOT using the PSTN.  There's some irony
in=20 that.

-AU

> -----Original Message-----
> From: = Sukanta=20 ganguly [mailto:sganguly@yahoo.com]
> Sent: Friday, April 13, = 2007 10:01=20 PM
> To: Uzelac, Adam; speermint@ietf.org
> Subject: Re: = [Speermint]=20 Re-making or Un-making the PSTN
>
>=20 Adam,
>    I am not sure I follow your = complication.=20 The fact that
> there are two federation of Bob's uri (according = to your=20
> example) should provide Alice a way to find Bob's uri. Are =
> you=20 concerned about Alice's discovery of Bob's uri? The
> border = element will=20 do that. In that manner it is no
> different than a classical IP = route=20 discovery with a router.
> If no deterministic way of finding out = the uri=20 ownership can
> be concluded then the next hop makes this = attempt. That=20 is
> the most logical way of doing unless their is uniform and =
>=20 well understood global master. This happens to be how PSTN
> does = it and=20 hence no difference.
>
>
> SG
>
> ----- = Original Message ----
> From: "Uzelac, Adam"=20 <Adam.Uzelac@globalcrossing.com>
> To: = speermint@ietf.org
>=20 Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] = Re-making=20 or Un-making the PSTN
>
>
> As I sit here working on = the=20 VoIP use-case draft, I can't
> help but thinking if we aren't = just=20 re-making the PSTN,
> instead of un-making it.
> The crux = of this=20 issue lies with the routing.  At some of the
> basic = constructs=20 of next-hop routing decisions that border
> elements need to do, = these=20 use-cases are starting to smell
> more and more like PSTN-based = routing=20 look-ups.  A simple
> determination of who owns the = SIP-URI of=20 the intended
> recipient can not be determined definitively, so = it's just=20
> punted off to the next chain in the link.  The = ultimate=20
> end-point determination needs to occur before the next-hop =
>=20 decision can be made.
> If we then consider B2BUAs in the mix, = it's more=20 likely than
> not that the original calling and called parties = are=20 changed.
>  I realize some of this changes due to local = policy,=20 but that
> still doesn't get to the root of the problem.
> =
>=20 For instance, say there were 2 federations where Bob
> registered = his=20 SIP-URI, so that according to members of both
> federation, to = reach bob=20 sessions should be targeted to
> bob@company.com.  Now = if Alice=20 is part of a an external
> domain to those federations, and with = both=20 feds "advertising"
> reachablity to Bob, how does Alice determine = next-hop?
> Basically, who owns Bob's uri?  
> =
> If=20 we were to bring ENUM into the discussion, it even get's
> worse = more=20 wrought with concern due to starting with
> regulated = e164.  I=20 just sharing out some thoughts.
>
> -AU
>
>=20 _______________________________________________
> Speermint = mailing=20 list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
&= gt;=20
> __________________________________________________
> Do = You=20 Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam=20 protection
> around http://mail.yahoo.com
>=20

_______________________________________________
Speermint = mailing=20 list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint
<= BR>_______________________________________________
Speermint=20 mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


Ahhh...imagining that irresistible "new car" smell?
Check out new=20 cars at Yahoo! Autos. ------_=_NextPart_001_01C780F9.3119C70E-- --===============0039079243== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0039079243==-- From speermint-bounces@ietf.org Tue Apr 17 10:20: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 1HdoXP-00020O-IX; Tue, 17 Apr 2007 10:20:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoXO-00020E-09 for speermint@ietf.org; Tue, 17 Apr 2007 10:20:06 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdoXJ-00032Z-Mq for speermint@ietf.org; Tue, 17 Apr 2007 10:20:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 16:20:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E09@oefeg-s04.oefeg.loc> In-Reply-To: <768BEB5E70C897468D015E23EDCC304E021A3334@dul1wnexmb01.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceAfZNsL7UMo2m6StGH4rVOyyXOfwAeAnugAAEvRUA= From: "Stastny Richard" To: "Chauhan, Sanjeev" , "Uzelac, Adam" , X-Spam-Score: 0.1 (/) X-Scan-Signature: e3978de407602efd2b8a96e4a52907ca Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1714147179==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1714147179== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C780FB.7D52C118" This is a multi-part message in MIME format. ------_=_NextPart_001_01C780FB.7D52C118 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * - industry source (enum directory) that provides 3rd-party authoratative information.=20 =20 I do not understand why you need ENUM for delivering a call to a SIP URI? =20 In addition, the basic problem we encounter is that we always mix layer 3 and layer 5 in these discussions. =20 Layer 5 is signalling and layer 3 is traffic including QoS =20 We should first come up a solution for layer 5 between SIP proxies =20 The traffic is going between UE and may never touch the networks (administrative domains, whatever) of the SIP Proxies I do not want to carry over the mobile tromboning to IP =20 Richard =20 =20 ________________________________ From: Chauhan, Sanjeev [mailto:SChauhan@verisign.com]=20 Sent: Tuesday, April 17, 2007 4:04 PM To: Sukanta ganguly; Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN =20 my 0.02 cents -=20 =20 - in the dns world the issue is simpler - there exists one authoratative database where the owner of the domain lists how the domain can be discovered. the peer (or end customer) is not given a choice.=20 =20 - in ip-communication (ie voip, im ...) world - both the originating and terminating parties want to have choices (ie control) the originating party wants to ensure the call is delivered to the correct end-point for reasons like a. avoid customer service issues b. for security reasons c. .. the terminating party wants to ensure it only gets the calls that it should be receiving because a. reduce extraneous traffic on network b. keep QoS=20 c. avoid transiting traffic that it cannot charge for.=20 d. ... =20 in the above i have assumed peering b/w service providers - this could be extended to peering b/w end-customers.=20 =20 going back to the original example where 2 service providers (or federation) have claimed to be able to deliver IMs to bob@company - and alice@company2 is trying to reach bob - the routing decision on which one to send should be based on a combination of=20 - originating parties peering relation with the 2 federations - federations peering relation with the originating party - industry source (enum directory) that provides 3rd-party authoratative information.=20 =20 -sanjeev =20 ________________________________ From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 Sent: Monday, April 16, 2007 7:03 PM To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Henry, "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings. So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding. =20 Thanks SG ----- Original Message ---- From: Henry Sinnreich To: "PFAUTZ, PENN L, ATTCORP" ; "Uzelac, Adam" ; Sukanta ganguly ; speermint@ietf.org Sent: Monday, April 16, 2007 3:15:14 PM Subject: RE: [Speermint] Re-making or Un-making the PSTN Penn Pfautz wrote? >Pure user-to-user calls either aren't an issue or are dealt with in the >P2P SIP discussions. Do folks disagree? As pointed out by Medhavi Bhatia, peering issues exist as well when users are in different P2P networks. We can only hope that peering between overlays would avoid some of the issues discussed here, such as policies, QoS, public/private ENUM, etc., in short all the constraints inherited from the PSTN mindset and just focus on security, spam, etc. In short: Internet-minded peering. The work reported here on IM peering is a good start IMHO since it shows the huge traffic issues just for IM. The reported IM systems can also do voice and video :-) Internet-minded peering will require some work however and the present exercise may be a useful experience (what to avoid), if we learn from it. Thanks, Henry -----Original Message----- From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]=20 Sent: Monday, April 16, 2007 12:03 PM To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree?=20 Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com =20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =20 =20 ________________________________ Ahhh...imagining that irresistible "new car" smell? Check out new cars at Yahoo! Autos. =20 ------_=_NextPart_001_01C780FB.7D52C118 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ø       - industry source (enum directory) that = provides 3rd-party authoratative information.

 =

I do not = understand why you need ENUM for delivering a call to a SIP = URI?

 =

In addition, the = basic problem we encounter is that we always mix layer 3 and layer 5
in these discussions.

 =

Layer 5 is = signalling and layer 3 is traffic including QoS

 =

We should first = come up a solution for layer 5 between SIP proxies

 =

The traffic is = going between UE and may never touch the networks (administrative domains, = whatever)

of the SIP = Proxies

I do not want to carry over the mobile tromboning to = IP

 =

Richard

 =

 =

From: = Chauhan, Sanjeev [mailto:SChauhan@verisign.com]
Sent: Tuesday, April 17, = 2007 4:04 PM
To: Sukanta ganguly; = Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org
Subject: RE: [Speermint] = Re-making or Un-making the PSTN

 

my 0.02 cents - =

 

- in the dns world the issue is = simpler - there exists one authoratative database where the owner of the domain = lists how the domain can be discovered. the peer (or end customer) is not given a = choice.

 

- in ip-communication (ie voip, im = ...) world - both the originating and terminating parties want to have = choices (ie control)

    the = originating party wants to ensure the call is delivered to the correct = end-point for reasons like

      =    a. avoid customer service issues

      =    b. for security reasons

      =    c. ..

    the = terminating party wants to ensure it only gets the calls that it should be receiving because

      =    a. reduce extraneous traffic on network

      =    b. keep QoS

      =    c. avoid transiting traffic that it cannot charge for. =

      =    d. ...

 

in the above i have assumed peering = b/w service providers - this could be extended to peering b/w end-customers. =

 

going back to the original example = where 2 service providers (or federation) have claimed to be able to deliver IMs = to bob@company - and alice@company2 is trying to reach bob - the routing decision on which one to send = should be based on a combination of

 - originating parties peering relation with the 2 federations

 - federations peering = relation with the originating party

 - industry source (enum = directory) that provides 3rd-party authoratative information. =

 

-sanjeev

 

From: Sukanta ganguly [mailto:sganguly@yahoo.com]
Sent: Monday, April 16, = 2007 7:03 PM
To: Henry Sinnreich; = PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org
Subject: Re: [Speermint] = Re-making or Un-making the PSTN

Henry,

   "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in = essence, it still needs to co-exist with the end-point peering resolution = policies. What I was getting as was the fact that it was no different from any = peer-to-peer discovery and the fact that the advertiser needs to have control over = how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can = be hidden inside corp databases and then we had the NAT folks who build a = logical manner to handle this mappings.

   So I am not sure we are getting to the right mode = of understanding the problem here. I think we need to qualify the peering = topic a little more so that a clear understanding.

 

Thanks

SG

----- Original = Message ----
From: Henry Sinnreich <hsinnrei@adobe.com>
To: "PFAUTZ, PENN L, ATTCORP" <ppfautz@att.com>; = "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>; Sukanta ganguly <sganguly@yahoo.com>; speermint@ietf.org
Sent: Monday, April 16, 2007 3:15:14 PM
Subject: RE: [Speermint] Re-making or Un-making the = PSTN

Penn Pfautz wrote?

>Pure user-to-user calls either aren't an issue or are dealt with in = the
>P2P SIP discussions. Do folks disagree?

As pointed out by Medhavi Bhatia, peering issues exist as well when
users are in different P2P networks.

We can only hope that peering between overlays would avoid some of = the
issues discussed here, such as policies, QoS, public/private ENUM, = etc.,
in short all the constraints inherited from the PSTN mindset and = just
focus on security, spam, etc. In short: Internet-minded peering.

The work reported here on IM peering is a good start IMHO since it = shows
the huge traffic issues just for IM. The reported IM systems can also = do
voice and video :-)

Internet-minded peering will require some work however and the = present
exercise may be a useful experience (what to avoid), if we learn = from
it.

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org
Subject: RE: [Speermint] Re-making or Un-making the PSTN

I thought, however, that the point of Speermint *was* to deal with
peering between service providers.
Pure user-to-user calls either aren't an issue or are dealt with in = the
P2P SIP discussions. Do folks disagree?
Quoting from the charter:
"The most focused deliverables of SPEERMINT are best current = practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed."

Did I fall off the wagon somewhere?

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; speermint@ietf.org
Subject: RE: [Speermint] Re-making or Un-making the PSTN

The point that I am trying to make is that the SIP Peering models = being
drawn up here rely too much on the SP representing Bob.  Bob = should be
able to represent himself and how the world can reach him without = the
help of a service provider.  There are numerous and well = documented
reasons that Bill might want a SP to represent him, for services = like
authentication, anti-SPIT, etc - but Bill should have another = option.
Speermint is gaining more and more of a PSTN coloring in it's attempt = to
create universal connectivity by NOT using the PSTN.  There's = some irony
in that.

-AU

> -----Original Message-----
> From: Sukanta ganguly [mailto:sganguly@yahoo.com]
> Sent: Friday, April 13, 2007 10:01 PM
> To: Uzelac, Adam; speermint@ietf.org
> Subject: Re: [Speermint] Re-making or Un-making the PSTN
>
> Adam,
>    I am not sure I follow your complication. = The fact that
> there are two federation of Bob's uri (according to your
> example) should provide Alice a way to find Bob's uri. Are
> you concerned about Alice's discovery of Bob's uri? The
> border element will do that. In that manner it is no
> different than a classical IP route discovery with a router.
> If no deterministic way of finding out the uri ownership can
> be concluded then the next hop makes this attempt. That is
> the most logical way of doing unless their is uniform and
> well understood global master. This happens to be how PSTN
> does it and hence no difference.
>
>
> SG
>
> ----- Original Message ----
> From: "Uzelac, Adam" = <Adam.Uzelac@globalcrossing.com>
> To: speermint@ietf.org
> Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] Re-making or Un-making the PSTN
>
>
> As I sit here working on the VoIP use-case draft, I can't
> help but thinking if we aren't just re-making the PSTN,
> instead of un-making it.
> The crux of this issue lies with the routing.  At some of = the
> basic constructs of next-hop routing decisions that border
> elements need to do, these use-cases are starting to smell
> more and more like PSTN-based routing look-ups.  A simple =
> determination of who owns the SIP-URI of the intended
> recipient can not be determined definitively, so it's just
> punted off to the next chain in the link.  The ultimate =
> end-point determination needs to occur before the next-hop
> decision can be made.
> If we then consider B2BUAs in the mix, it's more likely than
> not that the original calling and called parties are changed.
>  I realize some of this changes due to local policy, but = that
> still doesn't get to the root of the problem.
>
> For instance, say there were 2 federations where Bob
> registered his SIP-URI, so that according to members of both
> federation, to reach bob sessions should be targeted to
> bob@company.com.  Now if Alice is part of a an external =
> domain to those federations, and with both feds = "advertising"
> reachablity to Bob, how does Alice determine next-hop?
> Basically, who owns Bob's uri?  
>
> If we were to bring ENUM into the discussion, it even get's
> worse more wrought with concern due to starting with
> regulated e164.  I just sharing out some thoughts.
>
> -AU
>
> _______________________________________________
> Speermint mailing list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint >
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection =
> around http://mail.yahoo.com
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint
_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint

 

 

Ahhh...imagining that irresistible "new car" = smell?
Check out new cars at Yahoo! Autos.

------_=_NextPart_001_01C780FB.7D52C118-- --===============1714147179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1714147179==-- From speermint-bounces@ietf.org Tue Apr 17 10:46: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 1Hdowc-0005y8-P0; Tue, 17 Apr 2007 10:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdowc-0005y0-C4 for speermint@ietf.org; Tue, 17 Apr 2007 10:46:10 -0400 Received: from osprey.verisign.com ([216.168.239.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdowa-0001nO-U4 for speermint@ietf.org; Tue, 17 Apr 2007 10:46:10 -0400 Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id l3HEjrCD013327; Tue, 17 Apr 2007 10:45:53 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 10:45:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 10:45:46 -0400 Message-ID: <768BEB5E70C897468D015E23EDCC304E021A3348@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E09@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceAfZNsL7UMo2m6StGH4rVOyyXOfwAeAnugAAEvRUAAAN3X8A== From: "Chauhan, Sanjeev" To: "Stastny Richard" , "Uzelac, Adam" , X-OriginalArrivalTime: 17 Apr 2007 14:45:46.0758 (UTC) FILETIME=[15693260:01C780FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2ab14096843dab69630d256f59fc791 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1786776793==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1786776793== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C780FF.1545EB42" This is a multi-part message in MIME format. ------_=_NextPart_001_01C780FF.1545EB42 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable richard - all valid points. let me try to restate (my intent below is to keep peering discussing to layer 5 ie signalling) =20 - in ip-communication (ie voip, im ...) world - both the originating and terminating parties want to have choices (ie control) the originating party wants to ensure the call is delivered to the correct end-point for various reasons=20 a. avoid customer service issues b. for security reasons c. .. the terminating party wants to ensure it only gets the calls that it should be receiving because a. reduce extraneous traffic on network b. avoid transiting traffic that it cannot charge for.=20 c.. ... =20 in the above i have assumed peering b/w service providers - this could be extended to peering b/w end-customers.=20 =20 going back to the original example where 2 service providers (or federation) have claimed to be able to deliver IMs to bob@company - and alice@company2 is trying to reach bob - the routing decision on which one to send should be based on a combination of=20 - originating parties peering relation with the 2 federations - federations peering relation with the originating party - industry source that provides 3rd-party authoratative information.=20 ________________________________ From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Tuesday, April 17, 2007 10:20 AM To: Chauhan, Sanjeev; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN * - industry source (enum directory) that provides 3rd-party authoratative information.=20 =20 I do not understand why you need ENUM for delivering a call to a SIP URI? =20 In addition, the basic problem we encounter is that we always mix layer 3 and layer 5 in these discussions. =20 Layer 5 is signalling and layer 3 is traffic including QoS =20 We should first come up a solution for layer 5 between SIP proxies =20 The traffic is going between UE and may never touch the networks (administrative domains, whatever) of the SIP Proxies I do not want to carry over the mobile tromboning to IP =20 Richard =20 =20 ________________________________ From: Chauhan, Sanjeev [mailto:SChauhan@verisign.com]=20 Sent: Tuesday, April 17, 2007 4:04 PM To: Sukanta ganguly; Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN =20 my 0.02 cents -=20 =20 - in the dns world the issue is simpler - there exists one authoratative database where the owner of the domain lists how the domain can be discovered. the peer (or end customer) is not given a choice.=20 =20 - in ip-communication (ie voip, im ...) world - both the originating and terminating parties want to have choices (ie control) the originating party wants to ensure the call is delivered to the correct end-point for reasons like a. avoid customer service issues b. for security reasons c. .. the terminating party wants to ensure it only gets the calls that it should be receiving because a. reduce extraneous traffic on network b. keep QoS=20 c. avoid transiting traffic that it cannot charge for.=20 d. ... =20 in the above i have assumed peering b/w service providers - this could be extended to peering b/w end-customers.=20 =20 going back to the original example where 2 service providers (or federation) have claimed to be able to deliver IMs to bob@company - and alice@company2 is trying to reach bob - the routing decision on which one to send should be based on a combination of=20 - originating parties peering relation with the 2 federations - federations peering relation with the originating party - industry source (enum directory) that provides 3rd-party authoratative information.=20 =20 -sanjeev =20 ________________________________ From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 Sent: Monday, April 16, 2007 7:03 PM To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Henry, "Internet-minded" peering can work as aon overlay, not to the extent of violating the internal policies. So in essence, it still needs to co-exist with the end-point peering resolution policies. What I was getting as was the fact that it was no different from any peer-to-peer discovery and the fact that the advertiser needs to have control over how he/she can be discovered. This is how we did in the DNS world. Ofcourse, corporations came along with m-n mappings so that users information can be hidden inside corp databases and then we had the NAT folks who build a logical manner to handle this mappings. So I am not sure we are getting to the right mode of understanding the problem here. I think we need to qualify the peering topic a little more so that a clear understanding. =20 Thanks SG ----- Original Message ---- From: Henry Sinnreich To: "PFAUTZ, PENN L, ATTCORP" ; "Uzelac, Adam" ; Sukanta ganguly ; speermint@ietf.org Sent: Monday, April 16, 2007 3:15:14 PM Subject: RE: [Speermint] Re-making or Un-making the PSTN Penn Pfautz wrote? >Pure user-to-user calls either aren't an issue or are dealt with in the >P2P SIP discussions. Do folks disagree? As pointed out by Medhavi Bhatia, peering issues exist as well when users are in different P2P networks. We can only hope that peering between overlays would avoid some of the issues discussed here, such as policies, QoS, public/private ENUM, etc., in short all the constraints inherited from the PSTN mindset and just focus on security, spam, etc. In short: Internet-minded peering. The work reported here on IM peering is a good start IMHO since it shows the huge traffic issues just for IM. The reported IM systems can also do voice and video :-) Internet-minded peering will require some work however and the present exercise may be a useful experience (what to avoid), if we learn from it. Thanks, Henry -----Original Message----- From: PFAUTZ, PENN L, ATTCORP [mailto:ppfautz@att.com]=20 Sent: Monday, April 16, 2007 12:03 PM To: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN I thought, however, that the point of Speermint *was* to deal with peering between service providers. Pure user-to-user calls either aren't an issue or are dealt with in the P2P SIP discussions. Do folks disagree?=20 Quoting from the charter: "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." Did I fall off the wagon somewhere? Penn Pfautz AT&T Global Access Management +1-732-420-4962 -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 Sent: Monday, April 16, 2007 11:48 AM To: Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN The point that I am trying to make is that the SIP Peering models being drawn up here rely too much on the SP representing Bob. Bob should be able to represent himself and how the world can reach him without the help of a service provider. There are numerous and well documented reasons that Bill might want a SP to represent him, for services like authentication, anti-SPIT, etc - but Bill should have another option. Speermint is gaining more and more of a PSTN coloring in it's attempt to create universal connectivity by NOT using the PSTN. There's some irony in that. -AU=20 > -----Original Message----- > From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 > Sent: Friday, April 13, 2007 10:01 PM > To: Uzelac, Adam; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Adam, > I am not sure I follow your complication. The fact that=20 > there are two federation of Bob's uri (according to your=20 > example) should provide Alice a way to find Bob's uri. Are=20 > you concerned about Alice's discovery of Bob's uri? The=20 > border element will do that. In that manner it is no=20 > different than a classical IP route discovery with a router.=20 > If no deterministic way of finding out the uri ownership can=20 > be concluded then the next hop makes this attempt. That is=20 > the most logical way of doing unless their is uniform and=20 > well understood global master. This happens to be how PSTN=20 > does it and hence no difference. >=20 >=20 > SG >=20 > ----- Original Message ---- > From: "Uzelac, Adam" > To: speermint@ietf.org > Sent: Friday, April 13, 2007 1:18:44 PM > Subject: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > As I sit here working on the VoIP use-case draft, I can't=20 > help but thinking if we aren't just re-making the PSTN,=20 > instead of un-making it. > The crux of this issue lies with the routing. At some of the=20 > basic constructs of next-hop routing decisions that border=20 > elements need to do, these use-cases are starting to smell=20 > more and more like PSTN-based routing look-ups. A simple=20 > determination of who owns the SIP-URI of the intended=20 > recipient can not be determined definitively, so it's just=20 > punted off to the next chain in the link. The ultimate=20 > end-point determination needs to occur before the next-hop=20 > decision can be made. > If we then consider B2BUAs in the mix, it's more likely than=20 > not that the original calling and called parties are changed.=20 > I realize some of this changes due to local policy, but that=20 > still doesn't get to the root of the problem. >=20 > For instance, say there were 2 federations where Bob=20 > registered his SIP-URI, so that according to members of both=20 > federation, to reach bob sessions should be targeted to=20 > bob@company.com. Now if Alice is part of a an external=20 > domain to those federations, and with both feds "advertising"=20 > reachablity to Bob, how does Alice determine next-hop? > Basically, who owns Bob's uri? =20 >=20 > If we were to bring ENUM into the discussion, it even get's=20 > worse more wrought with concern due to starting with=20 > regulated e164. I just sharing out some thoughts. >=20 > -AU >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com =20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint =20 =20 ________________________________ Ahhh...imagining that irresistible "new car" smell? Check out new cars at Yahoo! Autos. =20 ------_=_NextPart_001_01C780FF.1545EB42 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

richard - all valid points. let me try to = restate (my=20 intent below is to keep peering discussing to layer 5 ie=20 signalling)

 

- in = ip-communication=20 (ie voip, im ...) world - both the originating and terminating parties = want to=20 have choices (ie control)

    the=20 originating party wants to ensure the call is delivered to the = correct=20 end-point for various = reasons=20

        =20 a. avoid customer service issues

        =20 b. for security reasons

        =20 c. ..

    the=20 terminating party wants to ensure it only gets the calls that it should = be=20 receiving because

        =20 a. reduce extraneous traffic on network

         b. avoid=20 transiting traffic that it cannot charge for. =

         c.. ...

 

in the above = i have=20 assumed peering b/w service providers - this could be extended to = peering b/w=20 end-customers.

 

going back to = the=20 original example where 2 service providers (or federation) have claimed = to be=20 able to deliver IMs to bob@company - and alice@company2 is trying to reach bob = - the=20 routing decision on which one to send should be based on a combination = of=20

 - = originating=20 parties peering relation with the 2 = federations

 - = federations=20 peering relation with the originating party

 - = industry=20 source that provides 3rd-party authoratative information.=20


From: Stastny Richard=20 [mailto:Richard.Stastny@oefeg.at]
Sent: Tuesday, April 17, = 2007 10:20=20 AM
To: Chauhan, Sanjeev; Uzelac, Adam;=20 speermint@ietf.org
Subject: RE: [Speermint] Re-making or = Un-making the=20 PSTN

Ø      =20 - industry = source (enum=20 directory) that provides 3rd-party authoratative information.=20

 

I do not = understand why=20 you need ENUM for delivering a call to a SIP = URI?

 

In addition, = the basic=20 problem we encounter is that we always mix layer 3 and layer 5
in = these=20 discussions.

 

Layer 5 is = signalling=20 and layer 3 is traffic including QoS

 

We should = first come up=20 a solution for layer 5 between SIP proxies

 

The traffic = is going=20 between UE and may never touch the networks (administrative domains,=20 whatever)

of the SIP=20 Proxies

I do not want to carry over the mobile tromboning to=20 IP

 

Richard

 

 

From: Chauhan,=20 Sanjeev [mailto:SChauhan@verisign.com]
Sent: Tuesday, April 17, 2007 = 4:04=20 PM
To: Sukanta = ganguly; Henry=20 Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; = speermint@ietf.org
Subject: RE: [Speermint] = Re-making or=20 Un-making the PSTN

 

my 0.02 cents = -=20

 

- in the dns = world the=20 issue is simpler - there exists one authoratative database where the = owner of=20 the domain lists how the domain can be discovered. the peer (or end = customer) is=20 not given a choice.

 

- in = ip-communication=20 (ie voip, im ...) world - both the originating and terminating parties = want to=20 have choices (ie control)

    the=20 originating party wants to ensure the call is delivered to the = correct=20 end-point for reasons like

        =20 a. avoid customer service issues

        =20 b. for security reasons

        =20 c. ..

    the=20 terminating party wants to ensure it only gets the calls that it should = be=20 receiving because

        =20 a. reduce extraneous traffic on network

         b.=20 keep QoS

        =20 c. avoid transiting traffic that it cannot charge for.=20

        =20 d. ...

 

in the above = i have=20 assumed peering b/w service providers - this could be extended to = peering b/w=20 end-customers.

 

going back to = the=20 original example where 2 service providers (or federation) have claimed = to be=20 able to deliver IMs to bob@company - = and alice@company2 is trying to reach bob = - the=20 routing decision on which one to send should be based on a combination = of=20

 - = originating=20 parties peering relation with the 2 = federations

 - = federations=20 peering relation with the originating party

 - = industry source=20 (enum directory) that provides 3rd-party authoratative information. =

 

-sanjeev

 

From: Sukanta=20 ganguly [mailto:sganguly@yahoo.com]
Sent: Monday, April 16, 2007 7:03 = PM
To: Henry = Sinnreich; PFAUTZ,=20 PENN L, ATTCORP; Uzelac, Adam; speermint@ietf.org
Subject: Re: [Speermint] = Re-making or=20 Un-making the PSTN

Henry,

   "Internet-minded" peering can = work as aon=20 overlay, not to the extent of violating the internal policies. So in = essence, it=20 still needs to co-exist with the end-point peering resolution policies. = What I=20 was getting as was the fact that it was no different from any = peer-to-peer=20 discovery and the fact that the advertiser needs to have control over = how he/she=20 can be discovered. This is how we did in the DNS world. Ofcourse, = corporations=20 came along with m-n mappings so that users information can be hidden = inside corp=20 databases and then we had the NAT folks who build a logical manner to = handle=20 this mappings.

   So I am not sure we are getting = to the=20 right mode of understanding the problem here. I think we need to qualify = the=20 peering topic a little more so that a clear=20 understanding.

 

Thanks

SG

----- Original Message = ----
From: Henry=20 Sinnreich <hsinnrei@adobe.com>
To: "PFAUTZ, PENN L, ATTCORP"=20 <ppfautz@att.com>; "Uzelac, Adam" = <Adam.Uzelac@globalcrossing.com>;=20 Sukanta ganguly <sganguly@yahoo.com>; speermint@ietf.org
Sent: = Monday,=20 April 16, 2007 3:15:14 PM
Subject: RE: [Speermint] Re-making or = Un-making the=20 PSTN

Penn Pfautz wrote?

>Pure = user-to-user calls=20 either aren't an issue or are dealt with in the
>P2P SIP = discussions. Do=20 folks disagree?

As pointed out by Medhavi Bhatia, peering issues = exist as=20 well when
users are in different P2P networks.

We can only = hope that=20 peering between overlays would avoid some of the
issues discussed = here, such=20 as policies, QoS, public/private ENUM, etc.,
in short all the = constraints=20 inherited from the PSTN mindset and just
focus on security, spam, = etc. In=20 short: Internet-minded peering.

The work reported here on IM = peering is a=20 good start IMHO since it shows
the huge traffic issues just for IM. = The=20 reported IM systems can also do
voice and video = :-)

Internet-minded=20 peering will require some work however and the present
exercise may = be a=20 useful experience (what to avoid), if we learn = from
it.

Thanks,=20 Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP = [mailto:ppfautz@att.com]
Sent: Monday, April 16, 2007 12:03 = PM
To:=20 Uzelac, Adam; Sukanta ganguly; speermint@ietf.org
Subject: RE: = [Speermint]=20 Re-making or Un-making the PSTN

I thought, however, that the = point of=20 Speermint *was* to deal with
peering between service = providers.
Pure=20 user-to-user calls either aren't an issue or are dealt with in = the
P2P SIP=20 discussions. Do folks disagree?
Quoting from the charter:
"The = most=20 focused deliverables of SPEERMINT are best current = practices
regarding=20 exchange of real-time sessions among VoIP and other
real-time = application=20 service providers and, in particular, how
such calls are = routed."

Did=20 I fall off the wagon somewhere?

Penn Pfautz
AT&T Global = Access=20 Management
+1-732-420-4962

-----Original Message-----
From: = Uzelac,=20 Adam [mailto:Adam.Uzelac@globalcrossing.com]
Sent: Monday, April 16, = 2007=20 11:48 AM
To: Sukanta ganguly; speermint@ietf.org
Subject: RE: = [Speermint]=20 Re-making or Un-making the PSTN

The point that I am trying to = make is=20 that the SIP Peering models being
drawn up here rely too much on the = SP=20 representing Bob.  Bob should be
able to represent himself = and how=20 the world can reach him without the
help of a service=20 provider.  There are numerous and well documented
reasons = that Bill=20 might want a SP to represent him, for services like
authentication,=20 anti-SPIT, etc - but Bill should have another option.
Speermint is = gaining=20 more and more of a PSTN coloring in it's attempt to
create universal=20 connectivity by NOT using the PSTN.  There's some irony
in=20 that.

-AU

> -----Original Message-----
> From: = Sukanta=20 ganguly [mailto:sganguly@yahoo.com]
> Sent: Friday, April 13, = 2007 10:01=20 PM
> To: Uzelac, Adam; speermint@ietf.org
> Subject: Re: = [Speermint]=20 Re-making or Un-making the PSTN
>
>=20 Adam,
>    I am not sure I follow your = complication.=20 The fact that
> there are two federation of Bob's uri (according = to your=20
> example) should provide Alice a way to find Bob's uri. Are =
> you=20 concerned about Alice's discovery of Bob's uri? The
> border = element will=20 do that. In that manner it is no
> different than a classical IP = route=20 discovery with a router.
> If no deterministic way of finding out = the uri=20 ownership can
> be concluded then the next hop makes this = attempt. That=20 is
> the most logical way of doing unless their is uniform and =
>=20 well understood global master. This happens to be how PSTN
> does = it and=20 hence no difference.
>
>
> SG
>
> ----- = Original Message ----
> From: "Uzelac, Adam"=20 <Adam.Uzelac@globalcrossing.com>
> To: = speermint@ietf.org
>=20 Sent: Friday, April 13, 2007 1:18:44 PM
> Subject: [Speermint] = Re-making=20 or Un-making the PSTN
>
>
> As I sit here working on = the=20 VoIP use-case draft, I can't
> help but thinking if we aren't = just=20 re-making the PSTN,
> instead of un-making it.
> The crux = of this=20 issue lies with the routing.  At some of the
> basic = constructs=20 of next-hop routing decisions that border
> elements need to do, = these=20 use-cases are starting to smell
> more and more like PSTN-based = routing=20 look-ups.  A simple
> determination of who owns the = SIP-URI of=20 the intended
> recipient can not be determined definitively, so = it's just=20
> punted off to the next chain in the link.  The = ultimate=20
> end-point determination needs to occur before the next-hop =
>=20 decision can be made.
> If we then consider B2BUAs in the mix, = it's more=20 likely than
> not that the original calling and called parties = are=20 changed.
>  I realize some of this changes due to local = policy,=20 but that
> still doesn't get to the root of the problem.
> =
>=20 For instance, say there were 2 federations where Bob
> registered = his=20 SIP-URI, so that according to members of both
> federation, to = reach bob=20 sessions should be targeted to
> bob@company.com.  Now = if Alice=20 is part of a an external
> domain to those federations, and with = both=20 feds "advertising"
> reachablity to Bob, how does Alice determine = next-hop?
> Basically, who owns Bob's uri?  
> =
> If=20 we were to bring ENUM into the discussion, it even get's
> worse = more=20 wrought with concern due to starting with
> regulated = e164.  I=20 just sharing out some thoughts.
>
> -AU
>
>=20 _______________________________________________
> Speermint = mailing=20 list
> Speermint@ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
&= gt;=20
> __________________________________________________
> Do = You=20 Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam=20 protection
> around http://mail.yahoo.com
>=20

_______________________________________________
Speermint = mailing=20 list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint
<= BR>_______________________________________________
Speermint=20 mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint=

 

 

Ahhh...imagining that irresistible "new car"=20 smell?
Check out new=20 cars at Yahoo! Autos.=20

------_=_NextPart_001_01C780FF.1545EB42-- --===============1786776793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1786776793==-- From speermint-bounces@ietf.org Tue Apr 17 11:09: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 1HdpJG-0000hC-Em; Tue, 17 Apr 2007 11:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpJE-0000Wx-TB for speermint@ietf.org; Tue, 17 Apr 2007 11:09:32 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpJD-00063N-J7 for speermint@ietf.org; Tue, 17 Apr 2007 11:09:32 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 5B1254CC07; Tue, 17 Apr 2007 17:09:30 +0200 (CEST) Date: Tue, 17 Apr 2007 17:09:30 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070417150930.GA29145@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/13 22:04, "Uzelac, Adam" wrote: > As I sit here working on the VoIP use-case draft, I can't help but > thinking if we aren't just re-making the PSTN, instead of un-making it. > The crux of this issue lies with the routing. At some of the basic > constructs of next-hop routing decisions that border elements need to > do, these use-cases are starting to smell more and more like PSTN-based > routing look-ups. Not just PSTN routing. IP routing is another example. The source is IMHO the following: * With the email-model, no multihop L7 routing is needed: The source contacts the destination directly and relies on the underlying IP network to do the heavy lifting in terms of routing. * The email model has been (mostly) rejected by the real life VoIP deployments. The reason seems to be that most carriers simply will not accept incoming SIP calls from the wide open Internet. The rest follows: A source network cannot be sure that the destination network will accept INVITES it sends via the Internet. It thus needs to employ the help of "transit" services. Once there are competing operators who offer transit services, the set of carriers and their links form a text-book example of a graph. Go to any Networking 101 class to learn about solutions to such an old fashioned routing problem. ---- Summary: If GC/Level3/DT/ATT/... and all the other carriers can agree to directly accept calls from all VoIP operators (regardless of country of origin), and thus implicitly also from other operators with which they haven't signed a contract, THEN AND ONLY THEN can we avoid the routing problem. I consider this to be pretty unlikely. I've written up a draft on this topic which will be submitted to the archives soon. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 11:31: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 1Hdpec-0003th-PO; Tue, 17 Apr 2007 11:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpec-0003tb-6X for speermint@ietf.org; Tue, 17 Apr 2007 11:31:38 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpeW-00052J-K2 for speermint@ietf.org; Tue, 17 Apr 2007 11:31:38 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 17 Apr 2007 08:31:31 -0700 X-IronPort-AV: i="4.14,419,1170662400"; d="scan'208"; a="136830566:sNHT57676068" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HFVV2G001765; Tue, 17 Apr 2007 11:31:31 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HFURGf016527; Tue, 17 Apr 2007 15:31:26 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); Tue, 17 Apr 2007 11:30:41 -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, 17 Apr 2007 11:30:40 -0400 Message-ID: <4624E824.7010407@cisco.com> Date: Tue, 17 Apr 2007 11:30:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Otmar Lendl , speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <20070417150930.GA29145@nic.at> In-Reply-To: <20070417150930.GA29145@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2007 15:30:40.0678 (UTC) FILETIME=[5B1CC460:01C78105] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2642; t=1176823891; x=1177687891; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20Otmar=20Lendl=20,=20speermint@ietf.org; bh=V5pOzwl67dklriYFoTF1lPSfKGBAf/0RUImj6qyoFM8=; b=NHRBchVHovXjviWsISqmM1iy7dr5QQ3I/6uVAoPuNIo64zBnawJV61bOs7DFV2gRpIAdxCLO kYbRVyHToKmlQWMX7jVoJCTjq6newDNz76uqwD4ENy3hGtH9/xHiNjBH; 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: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar Lendl wrote: > On 2007/04/13 22:04, "Uzelac, Adam" wrote: >> As I sit here working on the VoIP use-case draft, I can't help but >> thinking if we aren't just re-making the PSTN, instead of un-making it. >> The crux of this issue lies with the routing. At some of the basic >> constructs of next-hop routing decisions that border elements need to >> do, these use-cases are starting to smell more and more like PSTN-based >> routing look-ups. > > Not just PSTN routing. IP routing is another example. > > The source is IMHO the following: > > * With the email-model, no multihop L7 routing is needed: The source > contacts the destination directly and relies on the underlying IP > network to do the heavy lifting in terms of routing. > > * The email model has been (mostly) rejected by the real life > VoIP deployments. The reason seems to be that most carriers > simply will not accept incoming SIP calls from the wide open > Internet. IMO this needs to change. Maybe it will take legislation, or maybe the free market will fix it (if we ever get a free market), but it needs to change. The SP ought to be the agent for the end user's policies of whether to restrict the sources or destinations of calls. It may be that better guarantees of service can be given when there is a peering agreement between source and destination. But it seems absurd to enforce that the only alternative is no service at all. So it seems to me that the purpose of the peering agreements ought to be to assist in obtaining the degree of service that the caller is and callee desire, or coming as close as possible. Paul > The rest follows: > > A source network cannot be sure that the destination network > will accept INVITES it sends via the Internet. > > It thus needs to employ the help of "transit" services. > > Once there are competing operators who offer transit services, the set > of carriers and their links form a text-book example of a graph. Go > to any Networking 101 class to learn about solutions to such an old > fashioned routing problem. > > ---- > > Summary: If GC/Level3/DT/ATT/... and all the other carriers can agree to > directly accept calls from all VoIP operators (regardless of country of > origin), and thus implicitly also from other operators with which they > haven't signed a contract, THEN AND ONLY THEN can we avoid the routing > problem. > > I consider this to be pretty unlikely. > > I've written up a draft on this topic which will be submitted to > the archives soon. > > /ol _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 11:54: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 1Hdq0p-0006fL-GH; Tue, 17 Apr 2007 11:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdq0o-0006fF-9G for speermint@ietf.org; Tue, 17 Apr 2007 11:54:34 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdq0m-0007Sk-V5 for speermint@ietf.org; Tue, 17 Apr 2007 11:54:34 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 38E5C4CC07; Tue, 17 Apr 2007 17:54:32 +0200 (CEST) Date: Tue, 17 Apr 2007 17:54:32 +0200 From: Otmar Lendl To: Paul Kyzivat Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070417155431.GA30254@nic.at> Mail-Followup-To: Otmar Lendl , Paul Kyzivat , speermint@ietf.org References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4624E824.7010407@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/17 17:04, Paul Kyzivat wrote: > Otmar Lendl wrote: > > > >* The email model has been (mostly) rejected by the real life > > VoIP deployments. The reason seems to be that most carriers > > simply will not accept incoming SIP calls from the wide open > > Internet. > > IMO this needs to change. Maybe it will take legislation, or maybe the > free market will fix it (if we ever get a free market), but it needs to > change. The SP ought to be the agent for the end user's policies of > whether to restrict the sources or destinations of calls. > > It may be that better guarantees of service can be given when there is a > peering agreement between source and destination. But it seems absurd to > enforce that the only alternative is no service at all. IMHO the single most important reason for the current state of affairs is the fact that there *is* an alternative: the PSTN. Walling off your SIP service does not mean that your customers are not reachable. It only implies that calls have to be routed via the PSTN. That's the main difference to email: if you reject the incoming SMTP connection, then you don't get this email. There is no automatic fallback to snail-mail. New entrants into the email space thus had no other choice but accept SMTP connections from almost all hosts on the Internet. Those are the rules of email: you can take them or risk losing your reachability. E.164 based VoIP is different: there has always been the PSTN as a backup, as a default interconnection fabric. > So it seems to me that the purpose of the peering agreements ought to be > to assist in obtaining the degree of service that the caller is and > callee desire, or coming as close as possible. In an ideal world: yes. For now, I'd settle for "peering agreement ought to make direct interconnection possible". /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 12:44: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 1Hdqmd-0006yk-0L; Tue, 17 Apr 2007 12:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqmb-0006yU-PJ for speermint@ietf.org; Tue, 17 Apr 2007 12:43:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdqma-0005oq-DK for speermint@ietf.org; Tue, 17 Apr 2007 12:43:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2007 12:43:56 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="118745493:sNHT56119160" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HGhu2R011653; Tue, 17 Apr 2007 12:43:56 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HGhhGn011395; Tue, 17 Apr 2007 16:43:49 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 12:43:46 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 12:43:45 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <20070417155431.GA30254@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBCLz0NQxbYX7+TtylKcF4ifmhfQABnbVQ References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 17 Apr 2007 16:43:46.0532 (UTC) FILETIME=[9148FA40:01C7810F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3047; t=1176828236; x=1177692236; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Otmar=20Lendl=22=20, =0A=20=20=20=20=20=20=20=20=2 2Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=FeG9OiWvLV9w7PLdIfLkooD35GpOLcUbq1TPfYu4F0c=; b=LoZhYE8znmDI0n4YkqY+KRRACuBxDemXHLDZXjm5MSvePQEACux1kM6n7fMNIPgdEPjF3uaL j66iegoVvID+ElfvSKw6lC/7PbVtZSB9gmJfpcJ5MT+Zb9/nsDDIXUwM; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, Eventually, the PSTN as backup will go away. The issue here is trust and accountability of from whom one accepts calls.=20 The same could be said for email. Folks are working on that, I think. I'd rather not get calls from systems that are purposely avoiding accountability. They tend to be spammers. Mike > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Tuesday, April 17, 2007 11:55 AM > To: Paul Kyzivat (pkyzivat) > Cc: speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > On 2007/04/17 17:04, Paul Kyzivat wrote: > > Otmar Lendl wrote: > > > > > >* The email model has been (mostly) rejected by the real life > > > VoIP deployments. The reason seems to be that most carriers > > > simply will not accept incoming SIP calls from the wide open > > > Internet. > >=20 > > IMO this needs to change. Maybe it will take legislation,=20 > or maybe the=20 > > free market will fix it (if we ever get a free market), but=20 > it needs=20 > > to change. The SP ought to be the agent for the end user's=20 > policies of=20 > > whether to restrict the sources or destinations of calls. > >=20 > > It may be that better guarantees of service can be given=20 > when there is=20 > > a peering agreement between source and destination. But it seems=20 > > absurd to enforce that the only alternative is no service at all. >=20 > IMHO the single most important reason for the current state=20 > of affairs is the fact that there *is* an alternative: the=20 > PSTN. Walling off your SIP service does not mean that your=20 > customers are not reachable. It only implies that calls have=20 > to be routed via the PSTN. >=20 > That's the main difference to email: if you reject the=20 > incoming SMTP connection, then you don't get this email.=20 > There is no automatic fallback to snail-mail. New entrants=20 > into the email space thus had no other choice but accept SMTP=20 > connections from almost all hosts on the Internet. Those are=20 > the rules of email: you can take them or risk losing your=20 > reachability. >=20 > E.164 based VoIP is different: there has always been the PSTN=20 > as a backup, as a default interconnection fabric. >=20 > > So it seems to me that the purpose of the peering=20 > agreements ought to=20 > > be to assist in obtaining the degree of service that the=20 > caller is and=20 > > callee desire, or coming as close as possible. >=20 > In an ideal world: yes.=20 >=20 > For now, I'd settle for "peering agreement ought to make=20 > direct interconnection possible". >=20 > /ol > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 12:53: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 1Hdqvo-0001ug-8T; Tue, 17 Apr 2007 12:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqvn-0001ub-Et for speermint@ietf.org; Tue, 17 Apr 2007 12:53:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdqvm-0002LN-2p for speermint@ietf.org; Tue, 17 Apr 2007 12:53:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Apr 2007 12:53:26 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="118746599:sNHT66331524" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3HGrPAf008576; Tue, 17 Apr 2007 12:53:25 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HGrKGp014367; Tue, 17 Apr 2007 16:53: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); Tue, 17 Apr 2007 12:53:24 -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, 17 Apr 2007 12:53:23 -0400 Message-ID: <4624FB8F.7040408@cisco.com> Date: Tue, 17 Apr 2007 12:53:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2007 16:53:23.0881 (UTC) FILETIME=[E9697190:01C78110] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3504; t=1176828805; x=1177692805; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Michael=20Hammer=20(mhammer)=22=20; bh=BKoDolh8/eu2LgVP5A3uE38JVYWVio9Q2qYpqhoFqE8=; b=l4pE9xoS2p4E2sf+3OLI+qT7W+HeLIelyc6UhpZAD0NNe8LS3+GkSFV+/f0bmcyuOSh0YD68 GzDJmW0fheBzemooBkOxzt88OXKIZ7+l3UtZDN2MsLHU2tfnsgLzL9gK; 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: b5d20af10c334b36874c0264b10f59f1 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Otmar, > > Eventually, the PSTN as backup will go away. > > The issue here is trust and accountability of from whom one accepts > calls. > > The same could be said for email. Folks are working on that, I think. > > I'd rather not get calls from systems that are purposely avoiding > accountability. They tend to be spammers. It would be great to have that kind of control over who you receive calls from. But its *policy*, and the same policy is not right for everybody. In the case of spam, I'd rather get it all than have the decision of what I get be made by my service provider. Just think how bad it would be if the only way you could choose your spam filter was by which SP you signed up with. I'd like the same degree of control over VoIP and IM. Paul > Mike > > >> -----Original Message----- >> From: Otmar Lendl [mailto:lendl@nic.at] >> Sent: Tuesday, April 17, 2007 11:55 AM >> To: Paul Kyzivat (pkyzivat) >> Cc: speermint@ietf.org >> Subject: Re: [Speermint] Re-making or Un-making the PSTN >> >> On 2007/04/17 17:04, Paul Kyzivat wrote: >>> Otmar Lendl wrote: >>>> * The email model has been (mostly) rejected by the real life >>>> VoIP deployments. The reason seems to be that most carriers >>>> simply will not accept incoming SIP calls from the wide open >>>> Internet. >>> IMO this needs to change. Maybe it will take legislation, >> or maybe the >>> free market will fix it (if we ever get a free market), but >> it needs >>> to change. The SP ought to be the agent for the end user's >> policies of >>> whether to restrict the sources or destinations of calls. >>> >>> It may be that better guarantees of service can be given >> when there is >>> a peering agreement between source and destination. But it seems >>> absurd to enforce that the only alternative is no service at all. >> IMHO the single most important reason for the current state >> of affairs is the fact that there *is* an alternative: the >> PSTN. Walling off your SIP service does not mean that your >> customers are not reachable. It only implies that calls have >> to be routed via the PSTN. >> >> That's the main difference to email: if you reject the >> incoming SMTP connection, then you don't get this email. >> There is no automatic fallback to snail-mail. New entrants >> into the email space thus had no other choice but accept SMTP >> connections from almost all hosts on the Internet. Those are >> the rules of email: you can take them or risk losing your >> reachability. >> >> E.164 based VoIP is different: there has always been the PSTN >> as a backup, as a default interconnection fabric. >> >>> So it seems to me that the purpose of the peering >> agreements ought to >>> be to assist in obtaining the degree of service that the >> caller is and >>> callee desire, or coming as close as possible. >> In an ideal world: yes. >> >> For now, I'd settle for "peering agreement ought to make >> direct interconnection possible". >> >> /ol >> -- >> / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ >> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | >> \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 13:06: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 1Hdr8U-0001dj-Sg; Tue, 17 Apr 2007 13:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr8U-0001dd-2Y for speermint@ietf.org; Tue, 17 Apr 2007 13:06:34 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdr8S-0007MB-P6 for speermint@ietf.org; Tue, 17 Apr 2007 13:06:34 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 098804CC07; Tue, 17 Apr 2007 19:06:32 +0200 (CEST) Date: Tue, 17 Apr 2007 19:06:32 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070417170631.GB30254@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/17 18:04, "Michael Hammer (mhammer)" wrote: > > Eventually, the PSTN as backup will go away. The TDM technology: yes. I'm not sure about the organisational structure. > The issue here is trust and accountability of from whom one accepts > calls. Yes. Plus the financial aspects (cf. termination fees). > The same could be said for email. Folks are working on that, I think. Oh, they've been working on that for ages now. The ratio of spam vs. ham keeps increasing nevertheless. Where are we now? 80% SPAM? Is this the success we can afford to emulate? > I'd rather not get calls from systems that are purposely avoiding > accountability. They tend to be spammers. Can you envision a system where this accountability works all over the globe? Across jurisdiction? Across cultures and economic systems? Yes, I'd like to have such a system as well. This seems to be a rather non-trivial problem. Do you have concrete ideas on how this could be implemented? /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 13: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 1HdrFN-0004yh-UG; Tue, 17 Apr 2007 13:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrFM-0004yc-RA for speermint@ietf.org; Tue, 17 Apr 2007 13:13:40 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrFM-0000s6-Er for speermint@ietf.org; Tue, 17 Apr 2007 13:13:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 13:13:40 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57874509:sNHT55333122" 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 l3HHDeiT017829; Tue, 17 Apr 2007 13:13:40 -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 l3HHDZlM011096; Tue, 17 Apr 2007 17:13:40 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 13:13:33 -0400 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: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 13:13:32 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <4624FB8F.7040408@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBEOmxJONbbAnNSjaeO/XkYMmoewAAfV5g References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <4624FB8F.7040408@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 17 Apr 2007 17:13:33.0943 (UTC) FILETIME=[BAAA4070:01C78113] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4801; t=1176830020; x=1177694020; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=D7KpJjdvCqDXuILKkXfq3dYDv1UiuaTjNBMFLGRt5Z8=; b=Sh8OpLqEQDvMpWxAd3PAWwMfuy9fZ8RaSeRrvRIfzBrp9BH871q+QQENDZHZPkpykQ03BpCA 5XoNJP+S5GOaSeJysWq8mRHrRaqlKUWEgb97T37ikAa6d9CVatHoy9No; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Paul, This is not about stopping individual calls. It is about accountability = for those calls. You may still get the call, but there can be = consequences. This is developing a network without the na=EFve assumption that = everyone is trustworthy. The Internet itself assumed that and now some = folks are questioning the wisdom of that fundamental assumption and = wanting to design the next generation of Internet with different = assumptions due to DDoS and Spam and other miscreant behavior. This is in effect the PSTN redefining itself as an IP-based network. = Should it follow that same na=EFve assumption? Remember the definition of insanity: Doing the exact same thing over = again and expecting a different result. :) Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Tuesday, April 17, 2007 12:54 PM > To: Michael Hammer (mhammer) > Cc: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > Otmar, > >=20 > > Eventually, the PSTN as backup will go away. > >=20 > > The issue here is trust and accountability of from whom one accepts=20 > > calls. > >=20 > > The same could be said for email. Folks are working on=20 > that, I think. > >=20 > > I'd rather not get calls from systems that are purposely avoiding=20 > > accountability. They tend to be spammers. >=20 > It would be great to have that kind of control over who you=20 > receive calls from. But its *policy*, and the same policy is=20 > not right for everybody. >=20 > In the case of spam, I'd rather get it all than have the=20 > decision of what I get be made by my service provider. Just=20 > think how bad it would be if the only way you could choose=20 > your spam filter was by which SP you signed up with. I'd like=20 > the same degree of control over VoIP and IM. >=20 > Paul >=20 > > Mike > >=20 > >=20 > >> -----Original Message----- > >> From: Otmar Lendl [mailto:lendl@nic.at] > >> Sent: Tuesday, April 17, 2007 11:55 AM > >> To: Paul Kyzivat (pkyzivat) > >> Cc: speermint@ietf.org > >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >> > >> On 2007/04/17 17:04, Paul Kyzivat wrote: > >>> Otmar Lendl wrote: > >>>> * The email model has been (mostly) rejected by the real=20 > life VoIP=20 > >>>> deployments. The reason seems to be that most carriers =20 > simply will=20 > >>>> not accept incoming SIP calls from the wide open Internet. > >>> IMO this needs to change. Maybe it will take legislation, > >> or maybe the > >>> free market will fix it (if we ever get a free market), but > >> it needs > >>> to change. The SP ought to be the agent for the end user's > >> policies of > >>> whether to restrict the sources or destinations of calls. > >>> > >>> It may be that better guarantees of service can be given > >> when there is > >>> a peering agreement between source and destination. But it seems=20 > >>> absurd to enforce that the only alternative is no service at all. > >> IMHO the single most important reason for the current state of=20 > >> affairs is the fact that there *is* an alternative: the=20 > PSTN. Walling=20 > >> off your SIP service does not mean that your customers are not=20 > >> reachable. It only implies that calls have to be routed=20 > via the PSTN. > >> > >> That's the main difference to email: if you reject the=20 > incoming SMTP=20 > >> connection, then you don't get this email. > >> There is no automatic fallback to snail-mail. New entrants=20 > into the=20 > >> email space thus had no other choice but accept SMTP=20 > connections from=20 > >> almost all hosts on the Internet. Those are the rules of=20 > email: you=20 > >> can take them or risk losing your reachability. > >> > >> E.164 based VoIP is different: there has always been the PSTN as a=20 > >> backup, as a default interconnection fabric. > >> > >>> So it seems to me that the purpose of the peering > >> agreements ought to > >>> be to assist in obtaining the degree of service that the > >> caller is and > >>> callee desire, or coming as close as possible. > >> In an ideal world: yes.=20 > >> > >> For now, I'd settle for "peering agreement ought to make direct=20 > >> interconnection possible". > >> > >> /ol > >> -- > >> / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > >> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > >> \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > >> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > >> > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 13:27: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 1HdrT0-00035g-Ve; Tue, 17 Apr 2007 13:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdrSz-00032Q-5L for speermint@ietf.org; Tue, 17 Apr 2007 13:27:45 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdrSv-0005gh-JK for speermint@ietf.org; Tue, 17 Apr 2007 13:27:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 13:27:42 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57876161:sNHT55340240" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3HHRf7l025134; Tue, 17 Apr 2007 13:27:41 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HHRaHB024264; Tue, 17 Apr 2007 17:27:41 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); Tue, 17 Apr 2007 13:27:31 -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, 17 Apr 2007 13:27:31 -0400 Message-ID: <4625038F.1030005@cisco.com> Date: Tue, 17 Apr 2007 13:27:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <4624FB8F.7040408@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Apr 2007 17:27:31.0180 (UTC) FILETIME=[ADB27AC0:01C78115] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5223; t=1176830861; x=1177694861; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Michael=20Hammer=20(mhammer)=22=20; bh=0YaJXaLg7/XwM7G9XaQanFi9EWUUfbAP6Xv0mQ8DyzE=; b=FRKr8wgwYh1mLCriOrHxdGNcASl+rjpUWX6UkoSbEjJRkaYFmm3zV/b99frZjuaYK8kV8MKZ 4oA5kv26MSd64ODNuCabm+cQD9sB+h1NeVOgjw2dV5YQlrk6t9ks863X; 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: a1852b4f554b02e7e4548cc7928acc1f Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Paul, > > This is not about stopping individual calls. It is about accountability for those calls. You may still get the call, but there can be consequences. > > This is developing a network without the naïve assumption that everyone is trustworthy. The Internet itself assumed that and now some folks are questioning the wisdom of that fundamental assumption and wanting to design the next generation of Internet with different assumptions due to DDoS and Spam and other miscreant behavior. > > This is in effect the PSTN redefining itself as an IP-based network. Should it follow that same naïve assumption? > > Remember the definition of insanity: Doing the exact same thing over again and expecting a different result. :) I agree that we don't want the spam problems that have been aggravated by the assumptions of the email system. But that doesn't mean that even the short term answer should be restriction to members of the old boys network. Some simple policies that customers can select would be a fine start. If there are settlement issues, then it could be that part of the deal is that you must pay to accept calls from callers the SP has no settlement agreement with. Paul > Mike > > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Tuesday, April 17, 2007 12:54 PM >> To: Michael Hammer (mhammer) >> Cc: Otmar Lendl; speermint@ietf.org >> Subject: Re: [Speermint] Re-making or Un-making the PSTN >> >> >> >> Michael Hammer (mhammer) wrote: >>> Otmar, >>> >>> Eventually, the PSTN as backup will go away. >>> >>> The issue here is trust and accountability of from whom one accepts >>> calls. >>> >>> The same could be said for email. Folks are working on >> that, I think. >>> I'd rather not get calls from systems that are purposely avoiding >>> accountability. They tend to be spammers. >> It would be great to have that kind of control over who you >> receive calls from. But its *policy*, and the same policy is >> not right for everybody. >> >> In the case of spam, I'd rather get it all than have the >> decision of what I get be made by my service provider. Just >> think how bad it would be if the only way you could choose >> your spam filter was by which SP you signed up with. I'd like >> the same degree of control over VoIP and IM. >> >> Paul >> >>> Mike >>> >>> >>>> -----Original Message----- >>>> From: Otmar Lendl [mailto:lendl@nic.at] >>>> Sent: Tuesday, April 17, 2007 11:55 AM >>>> To: Paul Kyzivat (pkyzivat) >>>> Cc: speermint@ietf.org >>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>>> >>>> On 2007/04/17 17:04, Paul Kyzivat wrote: >>>>> Otmar Lendl wrote: >>>>>> * The email model has been (mostly) rejected by the real >> life VoIP >>>>>> deployments. The reason seems to be that most carriers >> simply will >>>>>> not accept incoming SIP calls from the wide open Internet. >>>>> IMO this needs to change. Maybe it will take legislation, >>>> or maybe the >>>>> free market will fix it (if we ever get a free market), but >>>> it needs >>>>> to change. The SP ought to be the agent for the end user's >>>> policies of >>>>> whether to restrict the sources or destinations of calls. >>>>> >>>>> It may be that better guarantees of service can be given >>>> when there is >>>>> a peering agreement between source and destination. But it seems >>>>> absurd to enforce that the only alternative is no service at all. >>>> IMHO the single most important reason for the current state of >>>> affairs is the fact that there *is* an alternative: the >> PSTN. Walling >>>> off your SIP service does not mean that your customers are not >>>> reachable. It only implies that calls have to be routed >> via the PSTN. >>>> That's the main difference to email: if you reject the >> incoming SMTP >>>> connection, then you don't get this email. >>>> There is no automatic fallback to snail-mail. New entrants >> into the >>>> email space thus had no other choice but accept SMTP >> connections from >>>> almost all hosts on the Internet. Those are the rules of >> email: you >>>> can take them or risk losing your reachability. >>>> >>>> E.164 based VoIP is different: there has always been the PSTN as a >>>> backup, as a default interconnection fabric. >>>> >>>>> So it seems to me that the purpose of the peering >>>> agreements ought to >>>>> be to assist in obtaining the degree of service that the >>>> caller is and >>>>> callee desire, or coming as close as possible. >>>> In an ideal world: yes. >>>> >>>> For now, I'd settle for "peering agreement ought to make direct >>>> interconnection possible". >>>> >>>> /ol >>>> -- >>>> / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ >>>> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | >>>> \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >>>> >>>> _______________________________________________ >>>> Speermint mailing list >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint >>>> > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 14:03: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 1Hds1P-0003Et-IP; Tue, 17 Apr 2007 14:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hds1N-0003C4-4U for speermint@ietf.org; Tue, 17 Apr 2007 14:03:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hds1L-0004Jx-By for speermint@ietf.org; Tue, 17 Apr 2007 14:03:17 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 14:03:15 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57880249:sNHT49256024" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HI3F2j018966; Tue, 17 Apr 2007 14:03:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HI2SGl005024; Tue, 17 Apr 2007 18:03:14 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 14:03:14 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 14:03:13 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E7565D@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <20070417170631.GB30254@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBEshF8LUV8XlgQ9yWzLmHmLyGqQAB0K8w References: <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at><072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <20070417170631.GB30254@nic.at> From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , X-OriginalArrivalTime: 17 Apr 2007 18:03:14.0330 (UTC) FILETIME=[AB1D37A0:01C7811A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2305; t=1176832995; x=1177696995; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Otmar=20Lendl=22=20,=20; bh=efOOpSMJlbCWolL/QiwTYcz/IN6+kqDmzlbKjgUiv80=; b=SORLgoiirieOFrNAe13fAB++cM9eQY2atTAI5bTFAfYVMZed0DqZhxW7mqpuaS0mK0Vuynvb goM/s3Uk2Uen7fDjxZT26A3qNUvudJBOHHImQaSm3ULH78iW4sOBj9j5; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org It is about answering the question: =20 If a hundered thousand of your customers are getting SPIT, complain, and threaten to change service providers, what can you do about it? If you can trace the problem to a given SP in the federation, then you can ask that SP to do something. If they don't you ostracize them, which reduces the value of their network. It would then be in their interest to address the problem. They can go elsewhere, but may eventually find them selves in federation only with other spammers. Age-old solution. Mike =20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Tuesday, April 17, 2007 1:07 PM > To: speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > On 2007/04/17 18:04, "Michael Hammer (mhammer)"=20 > wrote: > >=20 > > Eventually, the PSTN as backup will go away. >=20 > The TDM technology: yes. I'm not sure about the=20 > organisational structure. >=20 > > The issue here is trust and accountability of from whom one accepts=20 > > calls. >=20 > Yes. Plus the financial aspects (cf. termination fees). >=20 > > The same could be said for email. Folks are working on=20 > that, I think. >=20 > Oh, they've been working on that for ages now. The ratio of spam vs. > ham keeps increasing nevertheless. Where are we now? 80% SPAM? >=20 > Is this the success we can afford to emulate? >=20 > > I'd rather not get calls from systems that are purposely avoiding=20 > > accountability. They tend to be spammers. >=20 > Can you envision a system where this accountability works all=20 > over the globe? Across jurisdiction? Across cultures and=20 > economic systems? >=20 > Yes, I'd like to have such a system as well.=20 >=20 > This seems to be a rather non-trivial problem. Do you have=20 > concrete ideas on how this could be implemented? >=20 > /ol > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 14:07: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 1Hds5k-0004Ue-1H; Tue, 17 Apr 2007 14:07:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hds5j-0004UY-9e for speermint@ietf.org; Tue, 17 Apr 2007 14:07:47 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hds5i-0006DZ-NW for speermint@ietf.org; Tue, 17 Apr 2007 14:07:47 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 14:07:46 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57880811:sNHT59261812" 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 l3HI7kWO013446; Tue, 17 Apr 2007 14:07:46 -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 l3HI7Zls026777; Tue, 17 Apr 2007 18:07:46 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 14:07:38 -0400 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: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 14:07:37 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75661@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <4625038F.1030005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBFa4DL30pmqcyTEmD4AjYrPYkkwABSBhA References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <4624FB8F.7040408@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> <4625038F.1030005@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 17 Apr 2007 18:07:38.0703 (UTC) FILETIME=[48B155F0:01C7811B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6430; t=1176833266; x=1177697266; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=dRAXQ2mlYJ0rK6ZJjCcLUcNpChby3XaLtJDGSzgBxiQ=; b=zO1+3cpZDU8Mxrl3M/RbFWT6PsTJVPKgGBhbpT8M28Ygx8IYLYuIYjc317QoGMhQYvN5zuCM iAVrk/+GL+ZRKDJzvNs/PnrBeA0w3APpj1yE5iw4g0bFyED5W1E4lx4l; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org There are regulatory issues around malicious call identification and = rules about who can call and who can not call you, at least in the U.S. At the very least white-list mechanisms require one to have = authentication mechanisms that work across service providers with some = degree of mathematic certainty. Let's not muddy the waters with legacy charging and settlement rules. A = given federation may wish to include that, but others may choose not to. = Each could charge equally for their call half. :) Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Tuesday, April 17, 2007 1:28 PM > To: Michael Hammer (mhammer) > Cc: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > Paul, > >=20 > > This is not about stopping individual calls. It is about=20 > accountability for those calls. You may still get the call,=20 > but there can be consequences. > >=20 > > This is developing a network without the na=EFve assumption=20 > that everyone is trustworthy. The Internet itself assumed=20 > that and now some folks are questioning the wisdom of that=20 > fundamental assumption and wanting to design the next=20 > generation of Internet with different assumptions due to DDoS=20 > and Spam and other miscreant behavior. > >=20 > > This is in effect the PSTN redefining itself as an IP-based=20 > network. Should it follow that same na=EFve assumption? > >=20 > > Remember the definition of insanity: Doing the exact same=20 > thing over=20 > > again and expecting a different result. :) >=20 > I agree that we don't want the spam problems that have been=20 > aggravated by the assumptions of the email system. >=20 > But that doesn't mean that even the short term answer should=20 > be restriction to members of the old boys network. Some=20 > simple policies that customers can select would be a fine start. >=20 > If there are settlement issues, then it could be that part of=20 > the deal is that you must pay to accept calls from callers=20 > the SP has no settlement agreement with. >=20 > Paul >=20 > > Mike > >=20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, April 17, 2007 12:54 PM > >> To: Michael Hammer (mhammer) > >> Cc: Otmar Lendl; speermint@ietf.org > >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >> > >> > >> > >> Michael Hammer (mhammer) wrote: > >>> Otmar, > >>> > >>> Eventually, the PSTN as backup will go away. > >>> > >>> The issue here is trust and accountability of from whom=20 > one accepts=20 > >>> calls. > >>> > >>> The same could be said for email. Folks are working on > >> that, I think. > >>> I'd rather not get calls from systems that are purposely avoiding=20 > >>> accountability. They tend to be spammers. > >> It would be great to have that kind of control over who=20 > you receive=20 > >> calls from. But its *policy*, and the same policy is not right for=20 > >> everybody. > >> > >> In the case of spam, I'd rather get it all than have the=20 > decision of=20 > >> what I get be made by my service provider. Just think how bad it=20 > >> would be if the only way you could choose your spam filter was by=20 > >> which SP you signed up with. I'd like the same degree of=20 > control over=20 > >> VoIP and IM. > >> > >> Paul > >> > >>> Mike > >>> > >>> > >>>> -----Original Message----- > >>>> From: Otmar Lendl [mailto:lendl@nic.at] > >>>> Sent: Tuesday, April 17, 2007 11:55 AM > >>>> To: Paul Kyzivat (pkyzivat) > >>>> Cc: speermint@ietf.org > >>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >>>> > >>>> On 2007/04/17 17:04, Paul Kyzivat wrote: > >>>>> Otmar Lendl wrote: > >>>>>> * The email model has been (mostly) rejected by the real > >> life VoIP > >>>>>> deployments. The reason seems to be that most carriers > >> simply will > >>>>>> not accept incoming SIP calls from the wide open Internet. > >>>>> IMO this needs to change. Maybe it will take legislation, > >>>> or maybe the > >>>>> free market will fix it (if we ever get a free market), but > >>>> it needs > >>>>> to change. The SP ought to be the agent for the end user's > >>>> policies of > >>>>> whether to restrict the sources or destinations of calls. > >>>>> > >>>>> It may be that better guarantees of service can be given > >>>> when there is > >>>>> a peering agreement between source and destination. But=20 > it seems=20 > >>>>> absurd to enforce that the only alternative is no=20 > service at all. > >>>> IMHO the single most important reason for the current state of=20 > >>>> affairs is the fact that there *is* an alternative: the > >> PSTN. Walling > >>>> off your SIP service does not mean that your customers are not=20 > >>>> reachable. It only implies that calls have to be routed > >> via the PSTN. > >>>> That's the main difference to email: if you reject the > >> incoming SMTP > >>>> connection, then you don't get this email. > >>>> There is no automatic fallback to snail-mail. New entrants > >> into the > >>>> email space thus had no other choice but accept SMTP > >> connections from > >>>> almost all hosts on the Internet. Those are the rules of > >> email: you > >>>> can take them or risk losing your reachability. > >>>> > >>>> E.164 based VoIP is different: there has always been the=20 > PSTN as a=20 > >>>> backup, as a default interconnection fabric. > >>>> > >>>>> So it seems to me that the purpose of the peering > >>>> agreements ought to > >>>>> be to assist in obtaining the degree of service that the > >>>> caller is and > >>>>> callee desire, or coming as close as possible. > >>>> In an ideal world: yes.=20 > >>>> > >>>> For now, I'd settle for "peering agreement ought to make direct=20 > >>>> interconnection possible". > >>>> > >>>> /ol > >>>> -- > >>>> / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > >>>> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > >>>> \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > >>>> > >>>> _______________________________________________ > >>>> Speermint mailing list > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>> > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 17 14:11: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 1Hds95-0006jq-8m; Tue, 17 Apr 2007 14:11:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hds94-0006jf-13 for speermint@ietf.org; Tue, 17 Apr 2007 14:11:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hds93-00080L-Jf for speermint@ietf.org; Tue, 17 Apr 2007 14:11:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 14:11:11 -0400 X-IronPort-AV: i="4.14,419,1170651600"; d="scan'208"; a="57881584:sNHT1843974720" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HIBAoK024686; Tue, 17 Apr 2007 14:11:10 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HIB4H1008592; Tue, 17 Apr 2007 18:11:10 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 14:10:51 -0400 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: [Speermint] Re-making or Un-making the PSTN Date: Tue, 17 Apr 2007 14:10:50 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75663@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <4625038F.1030005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBFa4DL30pmqcyTEmD4AjYrPYkkwABeRZg References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <4624FB8F.7040408@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> <4625038F.1030005@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 17 Apr 2007 18:10:51.0548 (UTC) FILETIME=[BBA325C0:01C7811B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6094; t=1176833470; x=1177697470; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=VqD2k56RFiKEcAHlpM304ny9a5xtEv/MgQPAGLFF8lQ=; b=jOB1EIOyI9dZHf5JWfx/jOrryHl5GX1orffdmaYrZpuQ64mOYzzWsFcJBbbtCVGgxHM5xx2u NZz66jU7TaA8RTSQw2hob0a320eYLBE1V2JG23O/Msk6Lou0dULoE78J; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org p.s. The old boys network worked because each was held accountable for = the behavior it brought to the table. I suspect the club will expand, but decorum must be maintained. :) Mike =20 > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Tuesday, April 17, 2007 1:28 PM > To: Michael Hammer (mhammer) > Cc: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > Paul, > >=20 > > This is not about stopping individual calls. It is about=20 > accountability for those calls. You may still get the call,=20 > but there can be consequences. > >=20 > > This is developing a network without the na=EFve assumption=20 > that everyone is trustworthy. The Internet itself assumed=20 > that and now some folks are questioning the wisdom of that=20 > fundamental assumption and wanting to design the next=20 > generation of Internet with different assumptions due to DDoS=20 > and Spam and other miscreant behavior. > >=20 > > This is in effect the PSTN redefining itself as an IP-based=20 > network. Should it follow that same na=EFve assumption? > >=20 > > Remember the definition of insanity: Doing the exact same=20 > thing over=20 > > again and expecting a different result. :) >=20 > I agree that we don't want the spam problems that have been=20 > aggravated by the assumptions of the email system. >=20 > But that doesn't mean that even the short term answer should=20 > be restriction to members of the old boys network. Some=20 > simple policies that customers can select would be a fine start. >=20 > If there are settlement issues, then it could be that part of=20 > the deal is that you must pay to accept calls from callers=20 > the SP has no settlement agreement with. >=20 > Paul >=20 > > Mike > >=20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Tuesday, April 17, 2007 12:54 PM > >> To: Michael Hammer (mhammer) > >> Cc: Otmar Lendl; speermint@ietf.org > >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >> > >> > >> > >> Michael Hammer (mhammer) wrote: > >>> Otmar, > >>> > >>> Eventually, the PSTN as backup will go away. > >>> > >>> The issue here is trust and accountability of from whom=20 > one accepts=20 > >>> calls. > >>> > >>> The same could be said for email. Folks are working on > >> that, I think. > >>> I'd rather not get calls from systems that are purposely avoiding=20 > >>> accountability. They tend to be spammers. > >> It would be great to have that kind of control over who=20 > you receive=20 > >> calls from. But its *policy*, and the same policy is not right for=20 > >> everybody. > >> > >> In the case of spam, I'd rather get it all than have the=20 > decision of=20 > >> what I get be made by my service provider. Just think how bad it=20 > >> would be if the only way you could choose your spam filter was by=20 > >> which SP you signed up with. I'd like the same degree of=20 > control over=20 > >> VoIP and IM. > >> > >> Paul > >> > >>> Mike > >>> > >>> > >>>> -----Original Message----- > >>>> From: Otmar Lendl [mailto:lendl@nic.at] > >>>> Sent: Tuesday, April 17, 2007 11:55 AM > >>>> To: Paul Kyzivat (pkyzivat) > >>>> Cc: speermint@ietf.org > >>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >>>> > >>>> On 2007/04/17 17:04, Paul Kyzivat wrote: > >>>>> Otmar Lendl wrote: > >>>>>> * The email model has been (mostly) rejected by the real > >> life VoIP > >>>>>> deployments. The reason seems to be that most carriers > >> simply will > >>>>>> not accept incoming SIP calls from the wide open Internet. > >>>>> IMO this needs to change. Maybe it will take legislation, > >>>> or maybe the > >>>>> free market will fix it (if we ever get a free market), but > >>>> it needs > >>>>> to change. The SP ought to be the agent for the end user's > >>>> policies of > >>>>> whether to restrict the sources or destinations of calls. > >>>>> > >>>>> It may be that better guarantees of service can be given > >>>> when there is > >>>>> a peering agreement between source and destination. But=20 > it seems=20 > >>>>> absurd to enforce that the only alternative is no=20 > service at all. > >>>> IMHO the single most important reason for the current state of=20 > >>>> affairs is the fact that there *is* an alternative: the > >> PSTN. Walling > >>>> off your SIP service does not mean that your customers are not=20 > >>>> reachable. It only implies that calls have to be routed > >> via the PSTN. > >>>> That's the main difference to email: if you reject the > >> incoming SMTP > >>>> connection, then you don't get this email. > >>>> There is no automatic fallback to snail-mail. New entrants > >> into the > >>>> email space thus had no other choice but accept SMTP > >> connections from > >>>> almost all hosts on the Internet. Those are the rules of > >> email: you > >>>> can take them or risk losing your reachability. > >>>> > >>>> E.164 based VoIP is different: there has always been the=20 > PSTN as a=20 > >>>> backup, as a default interconnection fabric. > >>>> > >>>>> So it seems to me that the purpose of the peering > >>>> agreements ought to > >>>>> be to assist in obtaining the degree of service that the > >>>> caller is and > >>>>> callee desire, or coming as close as possible. > >>>> In an ideal world: yes.=20 > >>>> > >>>> For now, I'd settle for "peering agreement ought to make direct=20 > >>>> interconnection possible". > >>>> > >>>> /ol > >>>> -- > >>>> / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > >>>> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > >>>> \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > >>>> > >>>> _______________________________________________ > >>>> Speermint mailing list > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>> > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 03:41: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 1He4ml-0005dG-2U; Wed, 18 Apr 2007 03:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4mj-0005cq-4M for speermint@ietf.org; Wed, 18 Apr 2007 03:41:01 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He4mh-00066B-Ig for speermint@ietf.org; Wed, 18 Apr 2007 03:41:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 09:40:59 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> In-Reply-To: <4624E824.7010407@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBBYGDjgQ61+JSQZ+9C4kuJKKD4AAhs8VQ From: "Stastny Richard" To: "Paul Kyzivat" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Paul wrote > The SP ought to be the agent for the end user's policies of > whether to restrict the sources or destinations of calls. >=20 > It may be that better guarantees of service can be given when there is a > peering agreement between source and destination. But it seems absurd to > enforce that the only alternative is no service at all. This is what I always said and what is always forgotten in the=20 discussion: The service provider is acting as an agent of the end-user. If an end-user wants to accept calls from anywhere - fine If the end-user only accepts calls with proper identification - fine But this can only be evaluated after the service provider accepts the INVITE and looks up the profile of the requested user. Richard > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, April 17, 2007 5:31 PM > To: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Otmar Lendl wrote: > > On 2007/04/13 22:04, "Uzelac, Adam" > wrote: > >> As I sit here working on the VoIP use-case draft, I can't help but > >> thinking if we aren't just re-making the PSTN, instead of un-making it. > >> The crux of this issue lies with the routing. At some of the basic > >> constructs of next-hop routing decisions that border elements need to > >> do, these use-cases are starting to smell more and more like PSTN-based > >> routing look-ups. > > > > Not just PSTN routing. IP routing is another example. > > > > The source is IMHO the following: > > > > * With the email-model, no multihop L7 routing is needed: The source > > contacts the destination directly and relies on the underlying IP > > network to do the heavy lifting in terms of routing. > > > > * The email model has been (mostly) rejected by the real life > > VoIP deployments. The reason seems to be that most carriers > > simply will not accept incoming SIP calls from the wide open > > Internet. >=20 > IMO this needs to change. Maybe it will take legislation, or maybe the > free market will fix it (if we ever get a free market), but it needs to > change. The SP ought to be the agent for the end user's policies of > whether to restrict the sources or destinations of calls. >=20 > It may be that better guarantees of service can be given when there is a > peering agreement between source and destination. But it seems absurd to > enforce that the only alternative is no service at all. >=20 > So it seems to me that the purpose of the peering agreements ought to be > to assist in obtaining the degree of service that the caller is and > callee desire, or coming as close as possible. >=20 > Paul >=20 > > The rest follows: > > > > A source network cannot be sure that the destination network > > will accept INVITES it sends via the Internet. > > > > It thus needs to employ the help of "transit" services. > > > > Once there are competing operators who offer transit services, the set > > of carriers and their links form a text-book example of a graph. Go > > to any Networking 101 class to learn about solutions to such an old > > fashioned routing problem. > > > > ---- > > > > Summary: If GC/Level3/DT/ATT/... and all the other carriers can agree to > > directly accept calls from all VoIP operators (regardless of country of > > origin), and thus implicitly also from other operators with which they > > haven't signed a contract, THEN AND ONLY THEN can we avoid the routing > > problem. > > > > I consider this to be pretty unlikely. > > > > I've written up a draft on this topic which will be submitted to > > the archives soon. > > > > /ol >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 03:45: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 1He4qi-0000mw-Ra; Wed, 18 Apr 2007 03:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4qh-0000mk-7h for speermint@ietf.org; Wed, 18 Apr 2007 03:45:07 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He4qf-0000pT-NU for speermint@ietf.org; Wed, 18 Apr 2007 03:45:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 09:45:05 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E10@oefeg-s04.oefeg.loc> In-Reply-To: <20070417155431.GA30254@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBCLpEvn9zVhixR4mHO7hleMiLsAAhGTgA From: "Stastny Richard" To: "Otmar Lendl" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar wrote: > E.164 based VoIP is different: there has always been the PSTN as a > backup, as a default interconnection fabric. As you say, there HAS BEEN How long will the PSTN be available and what are you doing already now with video and IM? We should not look backwards (there may be lampposts ahead ;-),=20 we should look forward Richard > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, April 17, 2007 5:55 PM > To: Paul Kyzivat > Cc: speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > On 2007/04/17 17:04, Paul Kyzivat wrote: > > Otmar Lendl wrote: > > > > > >* The email model has been (mostly) rejected by the real life > > > VoIP deployments. The reason seems to be that most carriers > > > simply will not accept incoming SIP calls from the wide open > > > Internet. > > > > IMO this needs to change. Maybe it will take legislation, or maybe the > > free market will fix it (if we ever get a free market), but it needs to > > change. The SP ought to be the agent for the end user's policies of > > whether to restrict the sources or destinations of calls. > > > > It may be that better guarantees of service can be given when there is a > > peering agreement between source and destination. But it seems absurd to > > enforce that the only alternative is no service at all. >=20 > IMHO the single most important reason for the current state of affairs > is the fact that there *is* an alternative: the PSTN. Walling off your > SIP service does not mean that your customers are not reachable. It only > implies that calls have to be routed via the PSTN. >=20 > That's the main difference to email: if you reject the incoming SMTP > connection, then you don't get this email. There is no automatic > fallback to snail-mail. New entrants into the email space thus had no > other choice but accept SMTP connections from almost all hosts on the > Internet. Those are the rules of email: you can take them or risk losing > your reachability. >=20 > E.164 based VoIP is different: there has always been the PSTN as a > backup, as a default interconnection fabric. >=20 > > So it seems to me that the purpose of the peering agreements ought to be > > to assist in obtaining the degree of service that the caller is and > > callee desire, or coming as close as possible. >=20 > In an ideal world: yes. >=20 > For now, I'd settle for "peering agreement ought to make direct > interconnection possible". >=20 > /ol > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 03:47: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 1He4sw-00036U-J1; Wed, 18 Apr 2007 03:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4sv-00036L-99 for speermint@ietf.org; Wed, 18 Apr 2007 03:47:25 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He4su-0001zw-CE for speermint@ietf.org; Wed, 18 Apr 2007 03:47:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 09:47:22 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E12@oefeg-s04.oefeg.loc> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBCLz0NQxbYX7+TtylKcF4ifmhfQABnbVQAB+Yj4A= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Otmar Lendl" , "Paul Kyzivat \(pkyzivat\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael wrote: > I'd rather not get calls from systems that are purposely avoiding > accountability. They tend to be spammers. Agree But with you - do you mean you as an end-user or=20 you as a service provider? Richard > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > Sent: Tuesday, April 17, 2007 6:44 PM > To: Otmar Lendl; Paul Kyzivat (pkyzivat) > Cc: speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Otmar, >=20 > Eventually, the PSTN as backup will go away. >=20 > The issue here is trust and accountability of from whom one accepts > calls. >=20 > The same could be said for email. Folks are working on that, I think. >=20 > I'd rather not get calls from systems that are purposely avoiding > accountability. They tend to be spammers. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Otmar Lendl [mailto:lendl@nic.at] > > Sent: Tuesday, April 17, 2007 11:55 AM > > To: Paul Kyzivat (pkyzivat) > > Cc: speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > On 2007/04/17 17:04, Paul Kyzivat wrote: > > > Otmar Lendl wrote: > > > > > > > >* The email model has been (mostly) rejected by the real life > > > > VoIP deployments. The reason seems to be that most carriers > > > > simply will not accept incoming SIP calls from the wide open > > > > Internet. > > > > > > IMO this needs to change. Maybe it will take legislation, > > or maybe the > > > free market will fix it (if we ever get a free market), but > > it needs > > > to change. The SP ought to be the agent for the end user's > > policies of > > > whether to restrict the sources or destinations of calls. > > > > > > It may be that better guarantees of service can be given > > when there is > > > a peering agreement between source and destination. But it seems > > > absurd to enforce that the only alternative is no service at all. > > > > IMHO the single most important reason for the current state > > of affairs is the fact that there *is* an alternative: the > > PSTN. Walling off your SIP service does not mean that your > > customers are not reachable. It only implies that calls have > > to be routed via the PSTN. > > > > That's the main difference to email: if you reject the > > incoming SMTP connection, then you don't get this email. > > There is no automatic fallback to snail-mail. New entrants > > into the email space thus had no other choice but accept SMTP > > connections from almost all hosts on the Internet. Those are > > the rules of email: you can take them or risk losing your > > reachability. > > > > E.164 based VoIP is different: there has always been the PSTN > > as a backup, as a default interconnection fabric. > > > > > So it seems to me that the purpose of the peering > > agreements ought to > > > be to assist in obtaining the degree of service that the > > caller is and > > > callee desire, or coming as close as possible. > > > > In an ideal world: yes. > > > > For now, I'd settle for "peering agreement ought to make > > direct interconnection possible". > > > > /ol > > -- > > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 03:56: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 1He51g-0007Dq-5B; Wed, 18 Apr 2007 03:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He51f-0007Dl-AA for speermint@ietf.org; Wed, 18 Apr 2007 03:56:27 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He51d-0004DJ-Rg for speermint@ietf.org; Wed, 18 Apr 2007 03:56:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 09:56:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E16@oefeg-s04.oefeg.loc> In-Reply-To: <20070417170631.GB30254@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBEsb4klFbw/YbSv6Zd9wW+pFRkgAfB4aA From: "Stastny Richard" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar wrote: > This seems to be a rather non-trivial problem. Do you have concrete > ideas on how this could be implemented? Agreed But who wants to solve trivial problems ;-) Richard > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at] > Sent: Tuesday, April 17, 2007 7:07 PM > To: speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > On 2007/04/17 18:04, "Michael Hammer (mhammer)" wrote: > > > > Eventually, the PSTN as backup will go away. >=20 > The TDM technology: yes. I'm not sure about the organisational structure. >=20 > > The issue here is trust and accountability of from whom one accepts > > calls. >=20 > Yes. Plus the financial aspects (cf. termination fees). >=20 > > The same could be said for email. Folks are working on that, I think. >=20 > Oh, they've been working on that for ages now. The ratio of spam vs. > ham keeps increasing nevertheless. Where are we now? 80% SPAM? >=20 > Is this the success we can afford to emulate? >=20 > > I'd rather not get calls from systems that are purposely avoiding > > accountability. They tend to be spammers. >=20 > Can you envision a system where this accountability works all over the > globe? Across jurisdiction? Across cultures and economic systems? >=20 > Yes, I'd like to have such a system as well. >=20 > This seems to be a rather non-trivial problem. Do you have concrete > ideas on how this could be implemented? >=20 > /ol > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 04:44: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 1He5mU-0005SA-UI; Wed, 18 Apr 2007 04:44:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5mU-0005S5-2n for speermint@ietf.org; Wed, 18 Apr 2007 04:44:50 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He5mS-0007PK-LL for speermint@ietf.org; Wed, 18 Apr 2007 04:44:50 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id D162D4D1BF; Wed, 18 Apr 2007 10:44:43 +0200 (CEST) Date: Wed, 18 Apr 2007 10:44:43 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070418084443.GA14883@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20070417155431.GA30254@nic.at> <32755D354E6B65498C3BD9FD496C7D46646E10@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E10@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/18 09:04, Stastny Richard wrote: > Otmar wrote: > > E.164 based VoIP is different: there has always been the PSTN as a > > backup, as a default interconnection fabric. > > As you say, there HAS BEEN > > How long will the PSTN be available and what are you doing already > now with video and IM? > > We should not look backwards (there may be lampposts ahead ;-), > we should look forward We have to be aware that the protocols and standards we here in the IETF define will not per se define what the industry does. Each carrier will by itself decide whether to adopt the proposed solution. It may well be that we come up with a great proposal which would revolutionize the landscape and everybody will live happy ever after. But unless this system yields immediate benefits for the first handful of operators which decide to implement it, no one will make the plunge. In this case, carriers will not switch to open peering as that implies a loss of termination fee revenue. That would not matter if *everybody* moved to open peering at the same time. Both termination-fee and sender-keeps-all systems are stable states in the ecosystem. If the majority of carriers operate under one of these rules, then the rest are more or less forced to do the same. Managing a transition from one system to the other is *hard*. The only option I see is a regulator's mandate. I can't see it happening by pure market forces. The effect of the PSTN is similar: As long as it exists, it will affect the VoIP-peering choices carriers will take. And as long as these choices rely on the PSTN, I doubt that the PSTN (whether TDM-based or not does not matter) will go away. Summary: any plan that does not include a clear transition path (both technological and economical) from the current status quo will fail. We're not doing green-field design work, we have to take the current phone network and its ecosystem into consideration. [Just have a look at how IPv6 is doing. They're facing similar issues.] /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 10:05: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 1HeAnC-0001nW-Cj; Wed, 18 Apr 2007 10:05:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAnB-0001nQ-Nd for speermint@ietf.org; Wed, 18 Apr 2007 10:05:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAnB-0005Lc-9i for speermint@ietf.org; Wed, 18 Apr 2007 10:05:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 10:05:53 -0400 X-IronPort-AV: i="4.14,422,1170651600"; d="scan'208"; a="118834669:sNHT56200632" 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 l3IE5rap027645; Wed, 18 Apr 2007 10:05:53 -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 l3IE5llG018147; Wed, 18 Apr 2007 14:05:52 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:05:47 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 10:05:43 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBBYGDjgQ61+JSQZ+9C4kuJKKD4AAhs8VQAA17YHA= References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Paul Kyzivat \(pkyzivat\)" , "Otmar Lendl" , X-OriginalArrivalTime: 18 Apr 2007 14:05:47.0311 (UTC) FILETIME=[A9A463F0:01C781C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5012; t=1176905153; x=1177769153; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Stastny=20Richard=22=20, =0A=20=20=20= 20=20=20=20=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20, = 0A=20=20=20=20=20=20=20=20=22Otmar=20Lendl=22=20, =20; bh=uzG50rjHOzzgCngUfyHRvdGJFDM0QtgKNVYOacw3VWs=; b=VBxQyY+TUoyEk3YpYJpST77YeI0g0VwtTTzh0iFj4ww8urAr02h0IeO2Fw/cQfHmaaU7u/sb VlidLEW6n5jji3nO3ZdcJejXL3DDGJYVnyFK7jYdB4NlkhW5qZJEQuZv; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Richard, What happens when one end-user wants to receive from anywhere,=20 and everyone else doesn't want unsolicited garbage? Do you connect with known garbage spewing networks? The carrier has a responsibility to act in the interests of all the users. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, April 18, 2007 3:41 AM > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Paul wrote > > The SP ought to be the agent for the end user's policies of=20 > whether to=20 > > restrict the sources or destinations of calls. > >=20 > > It may be that better guarantees of service can be given=20 > when there is > a > > peering agreement between source and destination. But it=20 > seems absurd > to > > enforce that the only alternative is no service at all. >=20 > This is what I always said and what is always forgotten in the > discussion: The service provider is acting as an agent of the=20 > end-user. If an end-user wants to accept calls from anywhere=20 > - fine If the end-user only accepts calls with proper=20 > identification - fine >=20 > But this can only be evaluated after the service provider=20 > accepts the INVITE and looks up the profile of the requested user. >=20 > Richard >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, April 17, 2007 5:31 PM > > To: Otmar Lendl; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > >=20 > >=20 > >=20 > > Otmar Lendl wrote: > > > On 2007/04/13 22:04, "Uzelac, Adam"=20 > > > wrote: > > >> As I sit here working on the VoIP use-case draft, I=20 > can't help but=20 > > >> thinking if we aren't just re-making the PSTN, instead=20 > of un-making > it. > > >> The crux of this issue lies with the routing. At some=20 > of the basic=20 > > >> constructs of next-hop routing decisions that border=20 > elements need > to > > >> do, these use-cases are starting to smell more and more like > PSTN-based > > >> routing look-ups. > > > > > > Not just PSTN routing. IP routing is another example. > > > > > > The source is IMHO the following: > > > > > > * With the email-model, no multihop L7 routing is needed:=20 > The source > > > contacts the destination directly and relies on the=20 > underlying IP > > > network to do the heavy lifting in terms of routing. > > > > > > * The email model has been (mostly) rejected by the real life > > > VoIP deployments. The reason seems to be that most carriers > > > simply will not accept incoming SIP calls from the wide open > > > Internet. > >=20 > > IMO this needs to change. Maybe it will take legislation,=20 > or maybe the=20 > > free market will fix it (if we ever get a free market), but it needs > to > > change. The SP ought to be the agent for the end user's policies of=20 > > whether to restrict the sources or destinations of calls. > >=20 > > It may be that better guarantees of service can be given=20 > when there is > a > > peering agreement between source and destination. But it=20 > seems absurd > to > > enforce that the only alternative is no service at all. > >=20 > > So it seems to me that the purpose of the peering=20 > agreements ought to > be > > to assist in obtaining the degree of service that the caller is and=20 > > callee desire, or coming as close as possible. > >=20 > > Paul > >=20 > > > The rest follows: > > > > > > A source network cannot be sure that the destination network will=20 > > > accept INVITES it sends via the Internet. > > > > > > It thus needs to employ the help of "transit" services. > > > > > > Once there are competing operators who offer transit services, the > set > > > of carriers and their links form a text-book example of a=20 > graph. Go=20 > > > to any Networking 101 class to learn about solutions to=20 > such an old=20 > > > fashioned routing problem. > > > > > > ---- > > > > > > Summary: If GC/Level3/DT/ATT/... and all the other carriers can > agree to > > > directly accept calls from all VoIP operators (regardless=20 > of country > of > > > origin), and thus implicitly also from other operators with which > they > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the > routing > > > problem. > > > > > > I consider this to be pretty unlikely. > > > > > > I've written up a draft on this topic which will be=20 > submitted to the=20 > > > archives soon. > > > > > > /ol > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 10:11: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 1HeAsJ-0004Xd-MT; Wed, 18 Apr 2007 10:11:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAsG-0004Ww-PO for speermint@ietf.org; Wed, 18 Apr 2007 10:11:08 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAsF-0007y9-H9 for speermint@ietf.org; Wed, 18 Apr 2007 10:11:08 -0400 Received: by nz-out-0506.google.com with SMTP id z6so155188nzd for ; Wed, 18 Apr 2007 07:11:07 -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:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=O7w213Y8JbCkKvj9eCIGwFG5VuiBzmZIH5XyWKQj+0lMiZU7ofOhOBzMmHNNy8O4KCPMbk4qC4T4il40FeB3X6tCJ2hwEVk20RI6KHyIv+viKFfI3qof7ZUSde++Jec4LBf9AIsQ57YjanjGQVc+UI3/sOsxTirFiYs/bOLhveI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ATxVSSkaLLad4oRIUMVVpZz1svEiWE7yOitlWFOZNHhVAPfq8I9Mb5AFnNJANXsCAAo1XBAcg1J5/6yuMFJ4PYi39JN0DGNyUj2E6aSSZu317QXN6+Cawp+Ywpc1hrfCdMmeoAK5OuD+yidREj8N5bERDvHp0Ib7CIcpWOiwo10= Received: by 10.114.150.1 with SMTP id x1mr252798wad.1176905466392; Wed, 18 Apr 2007 07:11:06 -0700 (PDT) Received: by 10.114.124.7 with HTTP; Wed, 18 Apr 2007 07:11:06 -0700 (PDT) Message-ID: <894e079b0704180711i643ddcb2jcb7e4711e3d0833e@mail.gmail.com> Date: Wed, 18 Apr 2007 10:11:06 -0400 From: "Medhavi Bhatia" To: "Otmar Lendl" , speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN In-Reply-To: <20070418084443.GA14883@nic.at> MIME-Version: 1.0 References: <20070417155431.GA30254@nic.at> <32755D354E6B65498C3BD9FD496C7D46646E10@oefeg-s04.oefeg.loc> <20070418084443.GA14883@nic.at> X-Google-Sender-Auth: 3b169e47fccb854e X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1869698324==" Errors-To: speermint-bounces@ietf.org --===============1869698324== Content-Type: multipart/alternative; boundary="----=_Part_75274_32525930.1176905466293" ------=_Part_75274_32525930.1176905466293 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > We have to be aware that the protocols and standards we here in the IETF > define will not per se define what the industry does. Each carrier will > by itself decide whether to adopt the proposed solution. > > It may well be that we come up with a great proposal which would > revolutionize the landscape and everybody will live happy ever after. > But unless this system yields immediate benefits for the first handful > of operators which decide to implement it, no one will make the plunge. > > In this case, carriers will not switch to open peering as that > implies a loss of termination fee revenue. That would not matter > if *everybody* moved to open peering at the same time. > > I think there is something wrong in this argument, even though it sounds quite practical. The flaw seems to me that we are creating a vicious circle here. Once the standard is there, it creates more incentives for the industry to use it and spiral downwards. Business models which use the technology only become more ingrained and "solid". ------=_Part_75274_32525930.1176905466293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

We have to be aware that the protocols and standards we here in the IETF
define will not per se define what the industry does. Each carrier will
by itself decide whether to adopt the proposed solution.

It may well be that we come up with a great proposal which would
revolutionize the landscape and everybody will live happy ever after.
But unless this system yields immediate benefits for the first handful
of operators which decide to implement it, no one will make the plunge.

In this case, carriers will not switch to open peering as that
implies a loss of termination fee revenue. That would not matter
if *everybody* moved to open peering at the same time.


I think there is something wrong in this argument, even though it sounds quite practical. The flaw seems to me that we are creating a vicious circle here. Once the standard is there, it creates more incentives for the industry to use it and spiral downwards. Business models which use the technology only become more ingrained and "solid".
------=_Part_75274_32525930.1176905466293-- --===============1869698324== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1869698324==-- From speermint-bounces@ietf.org Wed Apr 18 10:20: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 1HeB1F-0001fr-7W; Wed, 18 Apr 2007 10:20:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeB1D-0001fh-Th for speermint@ietf.org; Wed, 18 Apr 2007 10:20:23 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeB1D-0001hm-GX for speermint@ietf.org; Wed, 18 Apr 2007 10:20:23 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 2AA4F96A0; Wed, 18 Apr 2007 10:20:21 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 10:20:20 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 10:20:16 -0400 Message-ID: In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBBYGDjgQ61+JSQZ+9C4kuJKKD4AAhs8VQAA17YHAAAEsCUA== References: <4624E824.7010407@cisco.com><32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> From: "Uzelac, Adam" To: "Michael Hammer (mhammer)" , "Stastny Richard" , "Paul Kyzivat (pkyzivat)" , "Otmar Lendl" , X-OriginalArrivalTime: 18 Apr 2007 14:20:20.0890 (UTC) FILETIME=[B255F7A0:01C781C4] X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Don't a connect to a known-garbage-spewing network today called the Internet? Not to sound coy or not, I am thinking along the same lines as Paul K. - that being, there's a certain amount of responsibility as end-users to bear the burden of "spew reduction". I think that it's more of a shared responsibility between the end-users and the SP.=20 Adam =20 > -----Original Message----- > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]=20 > Sent: Wednesday, April 18, 2007 10:06 AM > To: Stastny Richard; Paul Kyzivat (pkyzivat); Otmar Lendl;=20 > speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Richard, >=20 > What happens when one end-user wants to receive from=20 > anywhere, and everyone else doesn't want unsolicited garbage? >=20 > Do you connect with known garbage spewing networks? >=20 > The carrier has a responsibility to act in the interests of=20 > all the users. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, April 18, 2007 3:41 AM > > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > >=20 > > Paul wrote > > > The SP ought to be the agent for the end user's policies of > > whether to > > > restrict the sources or destinations of calls. > > >=20 > > > It may be that better guarantees of service can be given > > when there is > > a > > > peering agreement between source and destination. But it > > seems absurd > > to > > > enforce that the only alternative is no service at all. > >=20 > > This is what I always said and what is always forgotten in the > > discussion: The service provider is acting as an agent of the=20 > > end-user. If an end-user wants to accept calls from anywhere > > - fine If the end-user only accepts calls with proper=20 > identification -=20 > > fine > >=20 > > But this can only be evaluated after the service provider=20 > accepts the=20 > > INVITE and looks up the profile of the requested user. > >=20 > > Richard > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, April 17, 2007 5:31 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > >=20 > > >=20 > > >=20 > > > Otmar Lendl wrote: > > > > On 2007/04/13 22:04, "Uzelac, Adam"=20 > > > > > wrote: > > > >> As I sit here working on the VoIP use-case draft, I > > can't help but > > > >> thinking if we aren't just re-making the PSTN, instead > > of un-making > > it. > > > >> The crux of this issue lies with the routing. At some > > of the basic > > > >> constructs of next-hop routing decisions that border > > elements need > > to > > > >> do, these use-cases are starting to smell more and more like > > PSTN-based > > > >> routing look-ups. > > > > > > > > Not just PSTN routing. IP routing is another example. > > > > > > > > The source is IMHO the following: > > > > > > > > * With the email-model, no multihop L7 routing is needed:=20 > > The source > > > > contacts the destination directly and relies on the > > underlying IP > > > > network to do the heavy lifting in terms of routing. > > > > > > > > * The email model has been (mostly) rejected by the real life > > > > VoIP deployments. The reason seems to be that most carriers > > > > simply will not accept incoming SIP calls from the wide open > > > > Internet. > > >=20 > > > IMO this needs to change. Maybe it will take legislation, > > or maybe the > > > free market will fix it (if we ever get a free market),=20 > but it needs > > to > > > change. The SP ought to be the agent for the end user's=20 > policies of=20 > > > whether to restrict the sources or destinations of calls. > > >=20 > > > It may be that better guarantees of service can be given > > when there is > > a > > > peering agreement between source and destination. But it > > seems absurd > > to > > > enforce that the only alternative is no service at all. > > >=20 > > > So it seems to me that the purpose of the peering > > agreements ought to > > be > > > to assist in obtaining the degree of service that the=20 > caller is and=20 > > > callee desire, or coming as close as possible. > > >=20 > > > Paul > > >=20 > > > > The rest follows: > > > > > > > > A source network cannot be sure that the destination=20 > network will=20 > > > > accept INVITES it sends via the Internet. > > > > > > > > It thus needs to employ the help of "transit" services. > > > > > > > > Once there are competing operators who offer transit=20 > services, the > > set > > > > of carriers and their links form a text-book example of a > > graph. Go > > > > to any Networking 101 class to learn about solutions to > > such an old > > > > fashioned routing problem. > > > > > > > > ---- > > > > > > > > Summary: If GC/Level3/DT/ATT/... and all the other carriers can > > agree to > > > > directly accept calls from all VoIP operators (regardless > > of country > > of > > > > origin), and thus implicitly also from other operators=20 > with which > > they > > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the > > routing > > > > problem. > > > > > > > > I consider this to be pretty unlikely. > > > > > > > > I've written up a draft on this topic which will be > > submitted to the > > > > archives soon. > > > > > > > > /ol > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 10:22: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 1HeB35-0002Qk-14; Wed, 18 Apr 2007 10:22:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeB33-0002QS-PX for speermint@ietf.org; Wed, 18 Apr 2007 10:22:17 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeB31-00025g-E8 for speermint@ietf.org; Wed, 18 Apr 2007 10:22:17 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id AE5824D1C6; Wed, 18 Apr 2007 16:22:14 +0200 (CEST) Date: Wed, 18 Apr 2007 16:22:14 +0200 From: Otmar Lendl To: Medhavi Bhatia Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070418142214.GA21863@nic.at> Mail-Followup-To: Otmar Lendl , Medhavi Bhatia , speermint@ietf.org References: <20070417155431.GA30254@nic.at> <32755D354E6B65498C3BD9FD496C7D46646E10@oefeg-s04.oefeg.loc> <20070418084443.GA14883@nic.at> <894e079b0704180711i643ddcb2jcb7e4711e3d0833e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <894e079b0704180711i643ddcb2jcb7e4711e3d0833e@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/18 16:04, Medhavi Bhatia wrote: > > > > > >We have to be aware that the protocols and standards we here in the IETF > >define will not per se define what the industry does. Each carrier will > >by itself decide whether to adopt the proposed solution. > > > >It may well be that we come up with a great proposal which would > >revolutionize the landscape and everybody will live happy ever after. > >But unless this system yields immediate benefits for the first handful > >of operators which decide to implement it, no one will make the plunge. > > > >In this case, carriers will not switch to open peering as that > >implies a loss of termination fee revenue. That would not matter > >if *everybody* moved to open peering at the same time. > > > > > I think there is something wrong in this argument, even though it sounds > quite practical. The flaw seems to me that we are creating a vicious circle > here. Once the standard is there, it creates more incentives for the > industry to use it and spiral downwards. Business models which use the > technology only become more ingrained and "solid". There is no need to be that pessimistic. This argument implies that we need to thing about a transition strategy. e.g. that the standard works in a world where the old and the new co-exist. Thinking only about "this is how the world should operate" is not enough. There needs to be viable path from the status quo towards that vision. For the example with the settlement regimes: The protocol needs to be flexible enough so that sender-keeps-all federations and termination-fee federations can co-exist without danger to the carriers. The market will then decide which type of federation will see more traffic. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 10:42: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 1HeBMi-0008BF-Vs; Wed, 18 Apr 2007 10:42:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBMh-00089L-4S for speermint@ietf.org; Wed, 18 Apr 2007 10:42:35 -0400 Received: from web90602.mail.mud.yahoo.com ([216.252.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeBMg-0000hz-GL for speermint@ietf.org; Wed, 18 Apr 2007 10:42:35 -0400 Received: (qmail 52110 invoked by uid 60001); 18 Apr 2007 14:42:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=g8TsBiYNWxFmRsa+f+WaLcPAo0WZkfE71XC7ITygniDnZy3rbPba/xMZJRxgOj2nzUdZQrqbDBmih5xTl1Yp96Gbi8vA+P7PVA+87+VZKWkc0kfusuNB2yustANYx4AZkHhZb+1J6EmRm/FhYri5VAS7L8bt6B5Ij+TTz1e4mTU=; X-YMail-OSG: ADzeCcUVM1mC1c5hxo7qsjWkZy7JXT6XNVQFQ563Owmi3A.3E79vp3Qqf5QQzdGuxA-- Received: from [67.169.93.180] by web90602.mail.mud.yahoo.com via HTTP; Wed, 18 Apr 2007 07:42:33 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Wed, 18 Apr 2007 07:42:33 -0700 (PDT) From: Sukanta ganguly Subject: Re: [Speermint] Re-making or Un-making the PSTN To: Medhavi Bhatia , Otmar Lendl , speermint@ietf.org MIME-Version: 1.0 Message-ID: <811656.51634.qm@web90602.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441592076==" Errors-To: speermint-bounces@ietf.org --===============0441592076== Content-Type: multipart/alternative; boundary="0-912148093-1176907353=:51634" --0-912148093-1176907353=:51634 Content-Type: text/plain; charset=ascii I second that. If we define something which is un-usable for the businesses then the whole value of defining a standard is beaten. We do noat have to go to a 100% consensus building model, but a majority of the standard should be implementable and deployable. There is nothing wrong with having extensions defined and developed for particular cases, but they are extensions and not the core. SG ----- Original Message ---- From: Medhavi Bhatia To: Otmar Lendl ; speermint@ietf.org Sent: Wednesday, April 18, 2007 7:11:06 AM Subject: Re: [Speermint] Re-making or Un-making the PSTN We have to be aware that the protocols and standards we here in the IETF define will not per se define what the industry does. Each carrier will by itself decide whether to adopt the proposed solution. It may well be that we come up with a great proposal which would revolutionize the landscape and everybody will live happy ever after. But unless this system yields immediate benefits for the first handful of operators which decide to implement it, no one will make the plunge. In this case, carriers will not switch to open peering as that implies a loss of termination fee revenue. That would not matter if *everybody* moved to open peering at the same time. I think there is something wrong in this argument, even though it sounds quite practical. The flaw seems to me that we are creating a vicious circle here. Once the standard is there, it creates more incentives for the industry to use it and spiral downwards. Business models which use the technology only become more ingrained and "solid". _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-912148093-1176907353=:51634 Content-Type: text/html; charset=ascii
I second that. If we define something which is un-usable for the businesses then the whole value of defining a standard is beaten. We do noat have to go to a 100% consensus building model, but a majority of the standard should be implementable and deployable. There is nothing wrong with having extensions defined and developed for particular cases, but they are extensions and not the core.
 
 
SG 

----- Original Message ----
From: Medhavi Bhatia <mbhatia@3clogic.com>
To: Otmar Lendl <lendl@nic.at>; speermint@ietf.org
Sent: Wednesday, April 18, 2007 7:11:06 AM
Subject: Re: [Speermint] Re-making or Un-making the PSTN


We have to be aware that the protocols and standards we here in the IETF
define will not per se define what the industry does. Each carrier will
by itself decide whether to adopt the proposed solution.

It may well be that we come up with a great proposal which would
revolutionize the landscape and everybody will live happy ever after.
But unless this system yields immediate benefits for the first handful
of operators which decide to implement it, no one will make the plunge.

In this case, carriers will not switch to open peering as that
implies a loss of termination fee revenue. That would not matter
if *everybody* moved to open peering at the same time.


I think there is something wrong in this argument, even though it sounds quite practical. The flaw seems to me that we are creating a vicious circle here. Once the standard is there, it creates more incentives for the industry to use it and spiral downwards. Business models which use the technology only become more ingrained and "solid".
_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-912148093-1176907353=:51634-- --===============0441592076== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0441592076==-- From speermint-bounces@ietf.org Wed Apr 18 10: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 1HeBUS-0005wP-DV; Wed, 18 Apr 2007 10:50:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBUR-0005wG-Nf for speermint@ietf.org; Wed, 18 Apr 2007 10:50:35 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBUQ-0003RM-EN for speermint@ietf.org; Wed, 18 Apr 2007 10:50:35 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 0CAA94D1C6; Wed, 18 Apr 2007 16:50:34 +0200 (CEST) Date: Wed, 18 Apr 2007 16:50:34 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070418145033.GB21863@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20070417150930.GA29145@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070417150930.GA29145@nic.at> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/17 17:04, Otmar Lendl wrote: > > I've written up a draft on this topic which will be submitted to > the archives soon. I finally submitted the draft. If you don't want to wait for it to make it to the archives, have a look at: http://www.enum.at/ietf/draft-lendl-speermint-background-00.txt http://www.enum.at/ietf/draft-lendl-speermint-background-00.html Let the discussion begin. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 11:40: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 1HeCGf-0007Ra-88; Wed, 18 Apr 2007 11:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCGd-0007RV-93 for speermint@ietf.org; Wed, 18 Apr 2007 11:40:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCGa-0006XR-No for speermint@ietf.org; Wed, 18 Apr 2007 11:40:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 11:40:21 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="118844806:sNHT86834264" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3IFeKJ5023429; Wed, 18 Apr 2007 11:40:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IFdrH3029048; Wed, 18 Apr 2007 15:40:20 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 11:40:03 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 11:40:03 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBBYGDjgQ61+JSQZ+9C4kuJKKD4AAhs8VQAA17YHAAAEsCUAAC6HFA References: <4624E824.7010407@cisco.com><32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> From: "Michael Hammer \(mhammer\)" To: "Uzelac, Adam" , "Stastny Richard" , "Paul Kyzivat \(pkyzivat\)" , "Otmar Lendl" , X-OriginalArrivalTime: 18 Apr 2007 15:40:03.0141 (UTC) FILETIME=[D4C78F50:01C781CF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7480; t=1176910820; x=1177774820; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Uzelac, =20Adam=22=20, =0A=20=20= 20=20=20=20=20=20=22Stastny=20Richard=22=20, =0A= 20=20=20=20=20=20=20=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20, =0A=20=20=20=20=20=20=20=20=22Otmar=20Lendl=22=20, =2 0; bh=ngioBIV1Obvp2On35U0/c8s2x5RQs/SWbAcLRX5/l/w=; b=b7d5xxLGiuS1QNZRk2oQkAwfHlKnivIEJH/+B7hi/PzHsApCOhVbOqlg/841kNIJpedFTU/Z AF3IyWngP5DDeCqC1UaOTgrAadv9Cu4IYTwk46v7Kwim3V6Dd1wpGOhw; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Adam, The Internet moves packets. The question is when communicating over the Internet between VoIP platforms, I may want to have some authentication mechanisms in place to enable the called user to have white list control (by way of example). If a network, in its own policy, refuses to support any means of identifying the caller, even if it is as "anonymous, contact me later if there is problem with this particular user", are you saying I should submit my network to abuse? I am not masochistic and assume each network has the right to protect itself and its users, as it sees fit. I also assume the customers will judge the trade-offs made. Mike > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, April 18, 2007 10:20 AM > To: Michael Hammer (mhammer); Stastny Richard; Paul Kyzivat=20 > (pkyzivat); Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Don't a connect to a known-garbage-spewing network today=20 > called the Internet? Not to sound coy or not, I am thinking=20 > along the same lines as Paul K. - that being, there's a=20 > certain amount of responsibility as end-users to bear the=20 > burden of "spew reduction". I think that it's more of a=20 > shared responsibility between the end-users and the SP.=20 >=20 > Adam =20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, April 18, 2007 10:06 AM > > To: Stastny Richard; Paul Kyzivat (pkyzivat); Otmar Lendl;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > >=20 > > Richard, > >=20 > > What happens when one end-user wants to receive from anywhere, and=20 > > everyone else doesn't want unsolicited garbage? > >=20 > > Do you connect with known garbage spewing networks? > >=20 > > The carrier has a responsibility to act in the interests of all the=20 > > users. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, April 18, 2007 3:41 AM > > > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > >=20 > > > Paul wrote > > > > The SP ought to be the agent for the end user's policies of > > > whether to > > > > restrict the sources or destinations of calls. > > > >=20 > > > > It may be that better guarantees of service can be given > > > when there is > > > a > > > > peering agreement between source and destination. But it > > > seems absurd > > > to > > > > enforce that the only alternative is no service at all. > > >=20 > > > This is what I always said and what is always forgotten in the > > > discussion: The service provider is acting as an agent of the=20 > > > end-user. If an end-user wants to accept calls from anywhere > > > - fine If the end-user only accepts calls with proper > > identification - > > > fine > > >=20 > > > But this can only be evaluated after the service provider > > accepts the > > > INVITE and looks up the profile of the requested user. > > >=20 > > > Richard > > >=20 > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Tuesday, April 17, 2007 5:31 PM > > > > To: Otmar Lendl; speermint@ietf.org > > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > >=20 > > > >=20 > > > >=20 > > > > Otmar Lendl wrote: > > > > > On 2007/04/13 22:04, "Uzelac, Adam"=20 > > > > > > > wrote: > > > > >> As I sit here working on the VoIP use-case draft, I > > > can't help but > > > > >> thinking if we aren't just re-making the PSTN, instead > > > of un-making > > > it. > > > > >> The crux of this issue lies with the routing. At some > > > of the basic > > > > >> constructs of next-hop routing decisions that border > > > elements need > > > to > > > > >> do, these use-cases are starting to smell more and more like > > > PSTN-based > > > > >> routing look-ups. > > > > > > > > > > Not just PSTN routing. IP routing is another example. > > > > > > > > > > The source is IMHO the following: > > > > > > > > > > * With the email-model, no multihop L7 routing is needed:=20 > > > The source > > > > > contacts the destination directly and relies on the > > > underlying IP > > > > > network to do the heavy lifting in terms of routing. > > > > > > > > > > * The email model has been (mostly) rejected by the real life > > > > > VoIP deployments. The reason seems to be that most carriers > > > > > simply will not accept incoming SIP calls from the wide open > > > > > Internet. > > > >=20 > > > > IMO this needs to change. Maybe it will take legislation, > > > or maybe the > > > > free market will fix it (if we ever get a free market), > > but it needs > > > to > > > > change. The SP ought to be the agent for the end user's > > policies of > > > > whether to restrict the sources or destinations of calls. > > > >=20 > > > > It may be that better guarantees of service can be given > > > when there is > > > a > > > > peering agreement between source and destination. But it > > > seems absurd > > > to > > > > enforce that the only alternative is no service at all. > > > >=20 > > > > So it seems to me that the purpose of the peering > > > agreements ought to > > > be > > > > to assist in obtaining the degree of service that the > > caller is and > > > > callee desire, or coming as close as possible. > > > >=20 > > > > Paul > > > >=20 > > > > > The rest follows: > > > > > > > > > > A source network cannot be sure that the destination > > network will > > > > > accept INVITES it sends via the Internet. > > > > > > > > > > It thus needs to employ the help of "transit" services. > > > > > > > > > > Once there are competing operators who offer transit > > services, the > > > set > > > > > of carriers and their links form a text-book example of a > > > graph. Go > > > > > to any Networking 101 class to learn about solutions to > > > such an old > > > > > fashioned routing problem. > > > > > > > > > > ---- > > > > > > > > > > Summary: If GC/Level3/DT/ATT/... and all the other=20 > carriers can > > > agree to > > > > > directly accept calls from all VoIP operators (regardless > > > of country > > > of > > > > > origin), and thus implicitly also from other operators > > with which > > > they > > > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the > > > routing > > > > > problem. > > > > > > > > > > I consider this to be pretty unlikely. > > > > > > > > > > I've written up a draft on this topic which will be > > > submitted to the > > > > > archives soon. > > > > > > > > > > /ol > > > >=20 > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 11:43: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 1HeCJH-0001dF-Jn; Wed, 18 Apr 2007 11:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCJG-0001dA-Ai for speermint@ietf.org; Wed, 18 Apr 2007 11:43:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCJF-0007dw-MB for speermint@ietf.org; Wed, 18 Apr 2007 11:43:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2007 08:43:04 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="137310638:sNHT55544139" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3IFh4In016354; Wed, 18 Apr 2007 11:43:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IFgVGx029826; Wed, 18 Apr 2007 15:43:04 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); Wed, 18 Apr 2007 11:42:54 -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); Wed, 18 Apr 2007 11:42:53 -0400 Message-ID: <46263C7D.7040708@cisco.com> Date: Wed, 18 Apr 2007 11:42:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 15:42:53.0770 (UTC) FILETIME=[3A7B7AA0:01C781D0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5410; t=1176910984; x=1177774984; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Michael=20Hammer=20(mhammer)=22=20; bh=uVEap5QMxEuDXLYq4W3XI20GxGw7HtA0CnU0rtVMHlg=; b=txRf0BAuSGbxwapWwyICN3lNVj9apEFHsiciAUPEXTl1zv1JxEeqOzcFhj9rsDwzGEfVIzeF VE29xp4SxhtUM+YHt0DeZz9cY3WEa+Zkxe+XXkY+L1pCn7I3P2is1rOp; 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: 7e439b86d3292ef5adf93b694a43a576 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Richard, > > What happens when one end-user wants to receive from anywhere, > and everyone else doesn't want unsolicited garbage? > > Do you connect with known garbage spewing networks? > > The carrier has a responsibility to act in the interests of all the > users. It would be quite reasonable for the provider to have an optional (perhaps default) filter policy that rejects calls from untrusted sources (with trust defined by the SP). Its just that this needs to be applied on a per target basis rather than on a per-SP basis. Admittedly if the SP has 10m subscribers and only one of them wants this then they probably won't be incented to do it. But I think there will be more than that who want it. Paul > Mike > > >> -----Original Message----- >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >> Sent: Wednesday, April 18, 2007 3:41 AM >> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org >> Subject: RE: [Speermint] Re-making or Un-making the PSTN >> >> Paul wrote >>> The SP ought to be the agent for the end user's policies of >> whether to >>> restrict the sources or destinations of calls. >>> >>> It may be that better guarantees of service can be given >> when there is >> a >>> peering agreement between source and destination. But it >> seems absurd >> to >>> enforce that the only alternative is no service at all. >> This is what I always said and what is always forgotten in the >> discussion: The service provider is acting as an agent of the >> end-user. If an end-user wants to accept calls from anywhere >> - fine If the end-user only accepts calls with proper >> identification - fine >> >> But this can only be evaluated after the service provider >> accepts the INVITE and looks up the profile of the requested user. >> >> Richard >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, April 17, 2007 5:31 PM >>> To: Otmar Lendl; speermint@ietf.org >>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>> >>> >>> >>> Otmar Lendl wrote: >>>> On 2007/04/13 22:04, "Uzelac, Adam" >> >>> wrote: >>>>> As I sit here working on the VoIP use-case draft, I >> can't help but >>>>> thinking if we aren't just re-making the PSTN, instead >> of un-making >> it. >>>>> The crux of this issue lies with the routing. At some >> of the basic >>>>> constructs of next-hop routing decisions that border >> elements need >> to >>>>> do, these use-cases are starting to smell more and more like >> PSTN-based >>>>> routing look-ups. >>>> Not just PSTN routing. IP routing is another example. >>>> >>>> The source is IMHO the following: >>>> >>>> * With the email-model, no multihop L7 routing is needed: >> The source >>>> contacts the destination directly and relies on the >> underlying IP >>>> network to do the heavy lifting in terms of routing. >>>> >>>> * The email model has been (mostly) rejected by the real life >>>> VoIP deployments. The reason seems to be that most carriers >>>> simply will not accept incoming SIP calls from the wide open >>>> Internet. >>> IMO this needs to change. Maybe it will take legislation, >> or maybe the >>> free market will fix it (if we ever get a free market), but it needs >> to >>> change. The SP ought to be the agent for the end user's policies of >>> whether to restrict the sources or destinations of calls. >>> >>> It may be that better guarantees of service can be given >> when there is >> a >>> peering agreement between source and destination. But it >> seems absurd >> to >>> enforce that the only alternative is no service at all. >>> >>> So it seems to me that the purpose of the peering >> agreements ought to >> be >>> to assist in obtaining the degree of service that the caller is and >>> callee desire, or coming as close as possible. >>> >>> Paul >>> >>>> The rest follows: >>>> >>>> A source network cannot be sure that the destination network will >>>> accept INVITES it sends via the Internet. >>>> >>>> It thus needs to employ the help of "transit" services. >>>> >>>> Once there are competing operators who offer transit services, the >> set >>>> of carriers and their links form a text-book example of a >> graph. Go >>>> to any Networking 101 class to learn about solutions to >> such an old >>>> fashioned routing problem. >>>> >>>> ---- >>>> >>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can >> agree to >>>> directly accept calls from all VoIP operators (regardless >> of country >> of >>>> origin), and thus implicitly also from other operators with which >> they >>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the >> routing >>>> problem. >>>> >>>> I consider this to be pretty unlikely. >>>> >>>> I've written up a draft on this topic which will be >> submitted to the >>>> archives soon. >>>> >>>> /ol >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint >> > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 11:49: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 1HeCP0-0006wa-Lr; Wed, 18 Apr 2007 11:49:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCOz-0006wT-3Y for speermint@ietf.org; Wed, 18 Apr 2007 11:49:01 -0400 Received: from web90603.mail.mud.yahoo.com ([216.252.100.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeCOe-0000Vj-Ln for speermint@ietf.org; Wed, 18 Apr 2007 11:49:01 -0400 Received: (qmail 99442 invoked by uid 60001); 18 Apr 2007 15:48:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=qmJDvsSN1cNdXWfV4mLN0riIChKPDL/JnLYQKGQtVnFu07y/MJ9ThFJAngnNI39drWjPKLZVJxeyrH9Nwh1bh/21+VFUdt2AC+thnjc2i97R4BSnPWM7Fz6NsCcirzhsm6OS6SCT4lGwsLkpUgwgHa8ETraH6W2JIVrGbnTwOQM=; X-YMail-OSG: fHz1sVcVM1lCsLasLe2EGW80kTExHnhDcChrxIYtQa1p.t319vXqPtNOcaBFn9NdHzzN.OS3MGGJyrqvH1_MC8wMPuENkU9v8MrA Received: from [67.169.93.180] by web90603.mail.mud.yahoo.com via HTTP; Wed, 18 Apr 2007 08:48:39 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Wed, 18 Apr 2007 08:48:39 -0700 (PDT) From: Sukanta ganguly Subject: Re: [Speermint] Re-making or Un-making the PSTN To: "Michael Hammer \(mhammer\)" , "Uzelac, Adam" , Stastny Richard , "Paul Kyzivat \(pkyzivat\)" , Otmar Lendl , speermint@ietf.org MIME-Version: 1.0 Message-ID: <894647.98955.qm@web90603.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1730860503==" Errors-To: speermint-bounces@ietf.org --===============1730860503== Content-Type: multipart/alternative; boundary="0-664242385-1176911319=:98955" --0-664242385-1176911319=:98955 Content-Type: text/plain; charset=ascii Mike, I understand the point that you are trying to make here. What is your suggestion? Are you suggesting that some higher level sender checks at a higher than layer 3/4 needs to be performed so that a decision is made at the application level whether the connection needs to be accepted or not? Many VOIP applications and infrastructure provider provides these are their value-add already. SG ----- Original Message ---- From: Michael Hammer (mhammer) To: "Uzelac, Adam" ; Stastny Richard ; Paul Kyzivat (pkyzivat) ; Otmar Lendl ; speermint@ietf.org Sent: Wednesday, April 18, 2007 8:40:03 AM Subject: RE: [Speermint] Re-making or Un-making the PSTN Adam, The Internet moves packets. The question is when communicating over the Internet between VoIP platforms, I may want to have some authentication mechanisms in place to enable the called user to have white list control (by way of example). If a network, in its own policy, refuses to support any means of identifying the caller, even if it is as "anonymous, contact me later if there is problem with this particular user", are you saying I should submit my network to abuse? I am not masochistic and assume each network has the right to protect itself and its users, as it sees fit. I also assume the customers will judge the trade-offs made. Mike > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Wednesday, April 18, 2007 10:20 AM > To: Michael Hammer (mhammer); Stastny Richard; Paul Kyzivat > (pkyzivat); Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > Don't a connect to a known-garbage-spewing network today > called the Internet? Not to sound coy or not, I am thinking > along the same lines as Paul K. - that being, there's a > certain amount of responsibility as end-users to bear the > burden of "spew reduction". I think that it's more of a > shared responsibility between the end-users and the SP. > > Adam > > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, April 18, 2007 10:06 AM > > To: Stastny Richard; Paul Kyzivat (pkyzivat); Otmar Lendl; > > speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > > > Richard, > > > > What happens when one end-user wants to receive from anywhere, and > > everyone else doesn't want unsolicited garbage? > > > > Do you connect with known garbage spewing networks? > > > > The carrier has a responsibility to act in the interests of all the > > users. > > > > Mike > > > > > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, April 18, 2007 3:41 AM > > > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > > > > > Paul wrote > > > > The SP ought to be the agent for the end user's policies of > > > whether to > > > > restrict the sources or destinations of calls. > > > > > > > > It may be that better guarantees of service can be given > > > when there is > > > a > > > > peering agreement between source and destination. But it > > > seems absurd > > > to > > > > enforce that the only alternative is no service at all. > > > > > > This is what I always said and what is always forgotten in the > > > discussion: The service provider is acting as an agent of the > > > end-user. If an end-user wants to accept calls from anywhere > > > - fine If the end-user only accepts calls with proper > > identification - > > > fine > > > > > > But this can only be evaluated after the service provider > > accepts the > > > INVITE and looks up the profile of the requested user. > > > > > > Richard > > > > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Tuesday, April 17, 2007 5:31 PM > > > > To: Otmar Lendl; speermint@ietf.org > > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > > > > > > > > > > > > > Otmar Lendl wrote: > > > > > On 2007/04/13 22:04, "Uzelac, Adam" > > > > > > > wrote: > > > > >> As I sit here working on the VoIP use-case draft, I > > > can't help but > > > > >> thinking if we aren't just re-making the PSTN, instead > > > of un-making > > > it. > > > > >> The crux of this issue lies with the routing. At some > > > of the basic > > > > >> constructs of next-hop routing decisions that border > > > elements need > > > to > > > > >> do, these use-cases are starting to smell more and more like > > > PSTN-based > > > > >> routing look-ups. > > > > > > > > > > Not just PSTN routing. IP routing is another example. > > > > > > > > > > The source is IMHO the following: > > > > > > > > > > * With the email-model, no multihop L7 routing is needed: > > > The source > > > > > contacts the destination directly and relies on the > > > underlying IP > > > > > network to do the heavy lifting in terms of routing. > > > > > > > > > > * The email model has been (mostly) rejected by the real life > > > > > VoIP deployments. The reason seems to be that most carriers > > > > > simply will not accept incoming SIP calls from the wide open > > > > > Internet. > > > > > > > > IMO this needs to change. Maybe it will take legislation, > > > or maybe the > > > > free market will fix it (if we ever get a free market), > > but it needs > > > to > > > > change. The SP ought to be the agent for the end user's > > policies of > > > > whether to restrict the sources or destinations of calls. > > > > > > > > It may be that better guarantees of service can be given > > > when there is > > > a > > > > peering agreement between source and destination. But it > > > seems absurd > > > to > > > > enforce that the only alternative is no service at all. > > > > > > > > So it seems to me that the purpose of the peering > > > agreements ought to > > > be > > > > to assist in obtaining the degree of service that the > > caller is and > > > > callee desire, or coming as close as possible. > > > > > > > > Paul > > > > > > > > > The rest follows: > > > > > > > > > > A source network cannot be sure that the destination > > network will > > > > > accept INVITES it sends via the Internet. > > > > > > > > > > It thus needs to employ the help of "transit" services. > > > > > > > > > > Once there are competing operators who offer transit > > services, the > > > set > > > > > of carriers and their links form a text-book example of a > > > graph. Go > > > > > to any Networking 101 class to learn about solutions to > > > such an old > > > > > fashioned routing problem. > > > > > > > > > > ---- > > > > > > > > > > Summary: If GC/Level3/DT/ATT/... and all the other > carriers can > > > agree to > > > > > directly accept calls from all VoIP operators (regardless > > > of country > > > of > > > > > origin), and thus implicitly also from other operators > > with which > > > they > > > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the > > > routing > > > > > problem. > > > > > > > > > > I consider this to be pretty unlikely. > > > > > > > > > > I've written up a draft on this topic which will be > > > submitted to the > > > > > archives soon. > > > > > > > > > > /ol > > > > > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-664242385-1176911319=:98955 Content-Type: text/html; charset=ascii
Mike,
    I understand the point that you are trying to make here. What is your suggestion? Are you suggesting that some higher level sender checks at a higher than layer 3/4 needs to be performed so that a decision is made at the application level whether the connection needs to be accepted or not? Many VOIP applications and infrastructure provider provides these are their value-add already.
 
SG
    

----- Original Message ----
From: Michael Hammer (mhammer) <mhammer@cisco.com>
To: "Uzelac, Adam" <Adam.Uzelac@globalcrossing.com>; Stastny Richard <Richard.Stastny@oefeg.at>; Paul Kyzivat (pkyzivat) <pkyzivat@cisco.com>; Otmar Lendl <lendl@nic.at>; speermint@ietf.org
Sent: Wednesday, April 18, 2007 8:40:03 AM
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Adam,

The Internet moves packets.  The question is when communicating over the
Internet between VoIP platforms, I may want to have some authentication
mechanisms in place to enable the called user to have white list control
(by way of example).

If a network, in its own policy, refuses to support any means of
identifying the caller, even if it is as "anonymous, contact me later if
there is problem with this particular user", are you saying I should
submit my network to abuse?

I am not masochistic and assume each network has the right to protect
itself and its users, as it sees fit.  I also assume the customers will
judge the trade-offs made.

Mike


> -----Original Message-----
> From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]
> Sent: Wednesday, April 18, 2007 10:20 AM
> To: Michael Hammer (mhammer); Stastny Richard; Paul Kyzivat
> (pkyzivat); Otmar Lendl; speermint@ietf.org
> Subject: RE: [Speermint] Re-making or Un-making the PSTN
>
> Don't a connect to a known-garbage-spewing network today
> called the Internet?  Not to sound coy or not, I am thinking
> along the same lines as Paul K. - that being, there's a
> certain amount of responsibility as end-users to bear the
> burden of "spew reduction".  I think that it's more of a
> shared responsibility between the end-users and the SP.
>
> Adam  
>
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> > Sent: Wednesday, April 18, 2007 10:06 AM
> > To: Stastny Richard; Paul Kyzivat (pkyzivat); Otmar Lendl;
> > speermint@ietf.org
> > Subject: RE: [Speermint] Re-making or Un-making the PSTN
> >
> > Richard,
> >
> > What happens when one end-user wants to receive from anywhere, and
> > everyone else doesn't want unsolicited garbage?
> >
> > Do you connect with known garbage spewing networks?
> >
> > The carrier has a responsibility to act in the interests of all the
> > users.
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> > > Sent: Wednesday, April 18, 2007 3:41 AM
> > > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org
> > > Subject: RE: [Speermint] Re-making or Un-making the PSTN
> > >
> > > Paul wrote
> > > > The SP ought to be the agent for the end user's policies of
> > > whether to
> > > > restrict the sources or destinations of calls.
> > > >
> > > > It may be that better guarantees of service can be given
> > > when there is
> > > a
> > > > peering agreement between source and destination. But it
> > > seems absurd
> > > to
> > > > enforce that the only alternative is no service at all.
> > >
> > > This is what I always said and what is always forgotten in the
> > > discussion: The service provider is acting as an agent of the
> > > end-user. If an end-user wants to accept calls from anywhere
> > > - fine If the end-user only accepts calls with proper
> > identification -
> > > fine
> > >
> > > But this can only be evaluated after the service provider
> > accepts the
> > > INVITE and looks up the profile of the requested user.
> > >
> > > Richard
> > >
> > > > -----Original Message-----
> > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> > > > Sent: Tuesday, April 17, 2007 5:31 PM
> > > > To: Otmar Lendl; speermint@ietf.org
> > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN
> > > >
> > > >
> > > >
> > > > Otmar Lendl wrote:
> > > > > On 2007/04/13 22:04, "Uzelac, Adam"
> > > <Adam.Uzelac@globalcrossing.com>
> > > > wrote:
> > > > >> As I sit here working on the VoIP use-case draft, I
> > > can't help but
> > > > >> thinking if we aren't just re-making the PSTN, instead
> > > of un-making
> > > it.
> > > > >> The crux of this issue lies with the routing.  At some
> > > of the basic
> > > > >> constructs of next-hop routing decisions that border
> > > elements need
> > > to
> > > > >> do, these use-cases are starting to smell more and more like
> > > PSTN-based
> > > > >> routing look-ups.
> > > > >
> > > > > Not just PSTN routing. IP routing is another example.
> > > > >
> > > > > The source is IMHO the following:
> > > > >
> > > > > * With the email-model, no multihop L7 routing is needed:
> > > The source
> > > > >   contacts the destination directly and relies on the
> > > underlying IP
> > > > >   network to do the heavy lifting in terms of routing.
> > > > >
> > > > > * The email model has been (mostly) rejected by the real life
> > > > >   VoIP deployments. The reason seems to be that most carriers
> > > > >   simply will not accept incoming SIP calls from the wide open
> > > > >   Internet.
> > > >
> > > > IMO this needs to change. Maybe it will take legislation,
> > > or maybe the
> > > > free market will fix it (if we ever get a free market),
> > but it needs
> > > to
> > > > change. The SP ought to be the agent for the end user's
> > policies of
> > > > whether to restrict the sources or destinations of calls.
> > > >
> > > > It may be that better guarantees of service can be given
> > > when there is
> > > a
> > > > peering agreement between source and destination. But it
> > > seems absurd
> > > to
> > > > enforce that the only alternative is no service at all.
> > > >
> > > > So it seems to me that the purpose of the peering
> > > agreements ought to
> > > be
> > > > to assist in obtaining the degree of service that the
> > caller is and
> > > > callee desire, or coming as close as possible.
> > > >
> > > >     Paul
> > > >
> > > > > The rest follows:
> > > > >
> > > > > A source network cannot be sure that the destination
> > network will
> > > > > accept INVITES it sends via the Internet.
> > > > >
> > > > > It thus needs to employ the help of "transit" services.
> > > > >
> > > > > Once there are competing operators who offer transit
> > services, the
> > > set
> > > > > of carriers and their links form a text-book example of a
> > > graph. Go
> > > > > to any Networking 101 class to learn about solutions to
> > > such an old
> > > > > fashioned routing problem.
> > > > >
> > > > > ----
> > > > >
> > > > > Summary: If GC/Level3/DT/ATT/... and all the other
> carriers can
> > > agree to
> > > > > directly accept calls from all VoIP operators (regardless
> > > of country
> > > of
> > > > > origin), and thus implicitly also from other operators
> > with which
> > > they
> > > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the
> > > routing
> > > > > problem.
> > > > >
> > > > > I consider this to be pretty unlikely.
> > > > >
> > > > > I've written up a draft on this topic which will be
> > > submitted to the
> > > > > archives soon.
> > > > >
> > > > > /ol
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > Speermint@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> >
> > _______________________________________________
> > Speermint mailing list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
>

_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-664242385-1176911319=:98955-- --===============1730860503== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============1730860503==-- From speermint-bounces@ietf.org Wed Apr 18 12:01: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 1HeCan-0007IG-Tn; Wed, 18 Apr 2007 12:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCan-0007IB-6t for speermint@ietf.org; Wed, 18 Apr 2007 12:01:13 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCam-0004ia-JU for speermint@ietf.org; Wed, 18 Apr 2007 12:01:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2007 09:01:12 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="370480071:sNHT60307036" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3IG1Bl7025143; Wed, 18 Apr 2007 12:01:11 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IG16Gj005292; Wed, 18 Apr 2007 16:01:11 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:01:06 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 12:01:06 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75A24@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <46263C7D.7040708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB0DrA9Uzx5EVhQnuwV/dZTFPcKgAAJhIQ References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <46263C7D.7040708@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 18 Apr 2007 16:01:06.0804 (UTC) FILETIME=[C5FB3B40:01C781D2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6528; t=1176912071; x=1177776071; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=lnr7yFAEf/gj5A4Q5Xkpg8LYNFvL2/CXuFKD8A97V2g=; b=cihkIj8/SoeMW7LIyDbnNzEYBuVC1mK75LZ6dL9DeySLbyE5AAMQQ+e9kgKbz760HeZIXKYo DztWo6X+6X0ROAHK+iJD7MtBI7ESAU6h4BNG3X9IKhlPA/gtxKbyE6RC; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Paul, Yes. I am hoping that service providers can agree on some set of operating rules/practices that enable the finer grain control to happen. The problem comes if a particular SP doesn't want to operate with any degree of civility. The high level goal for me is that the PSTN has a certain level of trust and moving to a level of trust as problematic as that of email seems like a step in the wrong direction. Mike =20 > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Wednesday, April 18, 2007 11:43 AM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > Richard, > >=20 > > What happens when one end-user wants to receive from anywhere, and=20 > > everyone else doesn't want unsolicited garbage? > >=20 > > Do you connect with known garbage spewing networks? > >=20 > > The carrier has a responsibility to act in the interests of all the=20 > > users. >=20 > It would be quite reasonable for the provider to have an=20 > optional (perhaps default) filter policy that rejects calls=20 > from untrusted sources (with trust defined by the SP). Its=20 > just that this needs to be applied on a per target basis=20 > rather than on a per-SP basis. >=20 > Admittedly if the SP has 10m subscribers and only one of them=20 > wants this then they probably won't be incented to do it. But=20 > I think there will be more than that who want it. >=20 > Paul >=20 >=20 > > Mike > >=20 > >=20 > >> -----Original Message----- > >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >> Sent: Wednesday, April 18, 2007 3:41 AM > >> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > >> Subject: RE: [Speermint] Re-making or Un-making the PSTN > >> > >> Paul wrote > >>> The SP ought to be the agent for the end user's policies of > >> whether to > >>> restrict the sources or destinations of calls. > >>> > >>> It may be that better guarantees of service can be given > >> when there is > >> a > >>> peering agreement between source and destination. But it > >> seems absurd > >> to > >>> enforce that the only alternative is no service at all. > >> This is what I always said and what is always forgotten in the > >> discussion: The service provider is acting as an agent of the=20 > >> end-user. If an end-user wants to accept calls from anywhere > >> - fine If the end-user only accepts calls with proper=20 > identification=20 > >> - fine > >> > >> But this can only be evaluated after the service provider=20 > accepts the=20 > >> INVITE and looks up the profile of the requested user. > >> > >> Richard > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>> Sent: Tuesday, April 17, 2007 5:31 PM > >>> To: Otmar Lendl; speermint@ietf.org > >>> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >>> > >>> > >>> > >>> Otmar Lendl wrote: > >>>> On 2007/04/13 22:04, "Uzelac, Adam"=20 > >> > >>> wrote: > >>>>> As I sit here working on the VoIP use-case draft, I > >> can't help but > >>>>> thinking if we aren't just re-making the PSTN, instead > >> of un-making > >> it. > >>>>> The crux of this issue lies with the routing. At some > >> of the basic > >>>>> constructs of next-hop routing decisions that border > >> elements need > >> to > >>>>> do, these use-cases are starting to smell more and more like > >> PSTN-based > >>>>> routing look-ups. > >>>> Not just PSTN routing. IP routing is another example. > >>>> > >>>> The source is IMHO the following: > >>>> > >>>> * With the email-model, no multihop L7 routing is needed:=20 > >> The source > >>>> contacts the destination directly and relies on the > >> underlying IP > >>>> network to do the heavy lifting in terms of routing. > >>>> > >>>> * The email model has been (mostly) rejected by the real life > >>>> VoIP deployments. The reason seems to be that most carriers > >>>> simply will not accept incoming SIP calls from the wide open > >>>> Internet. > >>> IMO this needs to change. Maybe it will take legislation, > >> or maybe the > >>> free market will fix it (if we ever get a free market),=20 > but it needs > >> to > >>> change. The SP ought to be the agent for the end user's=20 > policies of=20 > >>> whether to restrict the sources or destinations of calls. > >>> > >>> It may be that better guarantees of service can be given > >> when there is > >> a > >>> peering agreement between source and destination. But it > >> seems absurd > >> to > >>> enforce that the only alternative is no service at all. > >>> > >>> So it seems to me that the purpose of the peering > >> agreements ought to > >> be > >>> to assist in obtaining the degree of service that the=20 > caller is and=20 > >>> callee desire, or coming as close as possible. > >>> > >>> Paul > >>> > >>>> The rest follows: > >>>> > >>>> A source network cannot be sure that the destination=20 > network will=20 > >>>> accept INVITES it sends via the Internet. > >>>> > >>>> It thus needs to employ the help of "transit" services. > >>>> > >>>> Once there are competing operators who offer transit=20 > services, the > >> set > >>>> of carriers and their links form a text-book example of a > >> graph. Go > >>>> to any Networking 101 class to learn about solutions to > >> such an old > >>>> fashioned routing problem. > >>>> > >>>> ---- > >>>> > >>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can > >> agree to > >>>> directly accept calls from all VoIP operators (regardless > >> of country > >> of > >>>> origin), and thus implicitly also from other operators with which > >> they > >>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the > >> routing > >>>> problem. > >>>> > >>>> I consider this to be pretty unlikely. > >>>> > >>>> I've written up a draft on this topic which will be > >> submitted to the > >>>> archives soon. > >>>> > >>>> /ol > >>> _______________________________________________ > >>> Speermint mailing list > >>> Speermint@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/speermint > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > >> > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:03: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 1HeCco-0000sB-7a; Wed, 18 Apr 2007 12:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCcm-0000ry-PX for speermint@ietf.org; Wed, 18 Apr 2007 12:03:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCcl-0005MO-Qy for speermint@ietf.org; Wed, 18 Apr 2007 12:03:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 12:02:42 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208,217"; a="118846015:sNHT91882821636" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3IG2fVG001896; Wed, 18 Apr 2007 12:02:41 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IG2aGf005641; Wed, 18 Apr 2007 16:02:41 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:02:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 12:02:40 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75A27@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <894647.98955.qm@web90603.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB0R0oXKDFAiKeSqy7IlEGhy325QAAddxg References: <894647.98955.qm@web90603.mail.mud.yahoo.com> From: "Michael Hammer \(mhammer\)" To: "Sukanta ganguly" , "Uzelac, Adam" , "Stastny Richard" , "Paul Kyzivat \(pkyzivat\)" , "Otmar Lendl" , X-OriginalArrivalTime: 18 Apr 2007 16:02:40.0976 (UTC) FILETIME=[FE1CBD00:01C781D2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=24823; t=1176912161; x=1177776161; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Sukanta=20ganguly=22=20, =0A=20=20=20=20=20= 20=20=20=22Uzelac, =20Adam=22=20, =0A=20=20= 20=20=20=20=20=20=22Stastny=20Richard=22=20, =0A= 20=20=20=20=20=20=20=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20, =0A=20=20=20=20=20=20=20=20=22Otmar=20Lendl=22=20, =2 0; bh=L7cB3XOBFuuR58urbyJdIVxWp4bYLttodP6ej/TZLkQ=; b=gJEK9vdWJyo4DpD/KMwnjNLzP7LAR/TBPb/r9o67BITpht/cdZT4/t6WNUB8M864TOIABvwR PPIlPxJU2HNQce1CzxV1zTmJHSNQdk+nXvZRZqp6QJXza/K11wG8gWk2; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: d9951f061208886fc6ada4b24aa6f98d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032927468==" Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0032927468== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C781D2.FDDE5D87" This is a multi-part message in MIME format. ------_=_NextPart_001_01C781D2.FDDE5D87 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am suggesting we don't lose that value-add. =20 Mike =20 ________________________________ From: Sukanta ganguly [mailto:sganguly@yahoo.com]=20 Sent: Wednesday, April 18, 2007 11:49 AM To: Michael Hammer (mhammer); Uzelac, Adam; Stastny Richard; Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN =09 =09 Mike, I understand the point that you are trying to make here. What is your suggestion? Are you suggesting that some higher level sender checks at a higher than layer 3/4 needs to be performed so that a decision is made at the application level whether the connection needs to be accepted or not? Many VOIP applications and infrastructure provider provides these are their value-add already. =20 SG =20 =09 =09 ----- Original Message ---- From: Michael Hammer (mhammer) To: "Uzelac, Adam" ; Stastny Richard ; Paul Kyzivat (pkyzivat) ; Otmar Lendl ; speermint@ietf.org Sent: Wednesday, April 18, 2007 8:40:03 AM Subject: RE: [Speermint] Re-making or Un-making the PSTN =09 =09 Adam, =09 The Internet moves packets. The question is when communicating over the Internet between VoIP platforms, I may want to have some authentication mechanisms in place to enable the called user to have white list control (by way of example). =09 If a network, in its own policy, refuses to support any means of identifying the caller, even if it is as "anonymous, contact me later if there is problem with this particular user", are you saying I should submit my network to abuse? =09 I am not masochistic and assume each network has the right to protect itself and its users, as it sees fit. I also assume the customers will judge the trade-offs made. =09 Mike =09 =09 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Wednesday, April 18, 2007 10:20 AM > To: Michael Hammer (mhammer); Stastny Richard; Paul Kyzivat=20 > (pkyzivat); Otmar Lendl; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Don't a connect to a known-garbage-spewing network today=20 > called the Internet? Not to sound coy or not, I am thinking=20 > along the same lines as Paul K. - that being, there's a=20 > certain amount of responsibility as end-users to bear the=20 > burden of "spew reduction". I think that it's more of a=20 > shared responsibility between the end-users and the SP.=20 >=20 > Adam =20 >=20 > > -----Original Message----- > > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com] > > Sent: Wednesday, April 18, 2007 10:06 AM > > To: Stastny Richard; Paul Kyzivat (pkyzivat); Otmar Lendl;=20 > > speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > >=20 > > Richard, > >=20 > > What happens when one end-user wants to receive from anywhere, and=20 > > everyone else doesn't want unsolicited garbage? > >=20 > > Do you connect with known garbage spewing networks? > >=20 > > The carrier has a responsibility to act in the interests of all the=20 > > users. > >=20 > > Mike > >=20 > >=20 > > > -----Original Message----- > > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > > Sent: Wednesday, April 18, 2007 3:41 AM > > > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > >=20 > > > Paul wrote > > > > The SP ought to be the agent for the end user's policies of > > > whether to > > > > restrict the sources or destinations of calls. > > > >=20 > > > > It may be that better guarantees of service can be given > > > when there is > > > a > > > > peering agreement between source and destination. But it > > > seems absurd > > > to > > > > enforce that the only alternative is no service at all. > > >=20 > > > This is what I always said and what is always forgotten in the > > > discussion: The service provider is acting as an agent of the=20 > > > end-user. If an end-user wants to accept calls from anywhere > > > - fine If the end-user only accepts calls with proper > > identification - > > > fine > > >=20 > > > But this can only be evaluated after the service provider > > accepts the > > > INVITE and looks up the profile of the requested user. > > >=20 > > > Richard > > >=20 > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sent: Tuesday, April 17, 2007 5:31 PM > > > > To: Otmar Lendl; speermint@ietf.org > > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > >=20 > > > >=20 > > > >=20 > > > > Otmar Lendl wrote: > > > > > On 2007/04/13 22:04, "Uzelac, Adam"=20 > > > > > > > wrote: > > > > >> As I sit here working on the VoIP use-case draft, I > > > can't help but > > > > >> thinking if we aren't just re-making the PSTN, instead > > > of un-making > > > it. > > > > >> The crux of this issue lies with the routing. At some > > > of the basic > > > > >> constructs of next-hop routing decisions that border > > > elements need > > > to > > > > >> do, these use-cases are starting to smell more and more like > > > PSTN-based > > > > >> routing look-ups. > > > > > > > > > > Not just PSTN routing. IP routing is another example. > > > > > > > > > > The source is IMHO the following: > > > > > > > > > > * With the email-model, no multihop L7 routing is needed:=20 > > > The source > > > > > contacts the destination directly and relies on the > > > underlying IP > > > > > network to do the heavy lifting in terms of routing. > > > > > > > > > > * The email model has been (mostly) rejected by the real life > > > > > VoIP deployments. The reason seems to be that most carriers > > > > > simply will not accept incoming SIP calls from the wide open > > > > > Internet. > > > >=20 > > > > IMO this needs to change. Maybe it will take legislation, > > > or maybe the > > > > free market will fix it (if we ever get a free market), > > but it needs > > > to > > > > change. The SP ought to be the agent for the end user's > > policies of > > > > whether to restrict the sources or destinations of calls. > > > >=20 > > > > It may be that better guarantees of service can be given > > > when there is > > > a > > > > peering agreement between source and destination. But it > > > seems absurd > > > to > > > > enforce that the only alternative is no service at all. > > > >=20 > > > > So it seems to me that the purpose of the peering > > > agreements ought to > > > be > > > > to assist in obtaining the degree of service that the > > caller is and > > > > callee desire, or coming as close as possible. > > > >=20 > > > > Paul > > > >=20 > > > > > The rest follows: > > > > > > > > > > A source network cannot be sure that the destination > > network will > > > > > accept INVITES it sends via the Internet. > > > > > > > > > > It thus needs to employ the help of "transit" services. > > > > > > > > > > Once there are competing operators who offer transit > > services, the > > > set > > > > > of carriers and their links form a text-book example of a > > > graph. Go > > > > > to any Networking 101 class to learn about solutions to > > > such an old > > > > > fashioned routing problem. > > > > > > > > > > ---- > > > > > > > > > > Summary: If GC/Level3/DT/ATT/... and all the other=20 > carriers can > > > agree to > > > > > directly accept calls from all VoIP operators (regardless > > > of country > > > of > > > > > origin), and thus implicitly also from other operators > > with which > > > they > > > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the > > > routing > > > > > problem. > > > > > > > > > > I consider this to be pretty unlikely. > > > > > > > > > > I've written up a draft on this topic which will be > > > submitted to the > > > > > archives soon. > > > > > > > > > > /ol > > > >=20 > > > > _______________________________________________ > > > > Speermint mailing list > > > > Speermint@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > >=20 > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 =09 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint ________________________________ Ahhh...imagining that irresistible "new car" smell? Check out new cars at Yahoo! Autos. =20 ------_=_NextPart_001_01C781D2.FDDE5D87 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I am suggesting we don't lose that = value-add.
 
Mike
 

From: Sukanta ganguly=20 [mailto:sganguly@yahoo.com]
Sent: Wednesday, April 18, 2007 = 11:49=20 AM
To: Michael Hammer (mhammer); Uzelac, Adam; Stastny = Richard; Paul=20 Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org
Subject: = Re:=20 [Speermint] Re-making or Un-making the PSTN

Mike,    =20 I understand the point that you are trying to make here. What is your=20 suggestion? Are you suggesting that some higher level sender checks at = a=20 higher than layer 3/4 needs to be performed so that a decision is made = at the=20 application level whether the connection needs to be accepted or not? = Many=20 VOIP applications and infrastructure provider provides these are their = value-add already.   SG     =20

-----=20 Original Message ----
From: Michael Hammer (mhammer)=20 <mhammer@cisco.com>
To: "Uzelac, Adam"=20 <Adam.Uzelac@globalcrossing.com>; Stastny Richard=20 <Richard.Stastny@oefeg.at>; Paul Kyzivat (pkyzivat)=20 <pkyzivat@cisco.com>; Otmar Lendl <lendl@nic.at>;=20 speermint@ietf.org
Sent: Wednesday, April 18, 2007 8:40:03 = AM
Subject:=20 RE: [Speermint] Re-making or Un-making the PSTN

Adam,

The Internet moves packets.  The question = is when=20 communicating over the
Internet between VoIP platforms, I may want = to have=20 some authentication
mechanisms in place to enable the called user = to have=20 white list control
(by way of example).

If a network, in its = own=20 policy, refuses to support any means of
identifying the caller, = even if it=20 is as "anonymous, contact me later if
there is problem with this = particular=20 user", are you saying I should
submit my network to abuse?

I = am not=20 masochistic and assume each network has the right to protect
itself = and its=20 users, as it sees fit.  I also assume the customers = will
judge=20 the trade-offs made.

Mike


> -----Original=20 Message-----
> From: Uzelac, Adam=20 [mailto:Adam.Uzelac@globalcrossing.com]
> Sent: Wednesday, = April 18,=20 2007 10:20 AM
> To: Michael Hammer (mhammer); Stastny Richard; = Paul=20 Kyzivat
> (pkyzivat); Otmar Lendl; speermint@ietf.org
> = Subject:=20 RE: [Speermint] Re-making or Un-making the PSTN
>
> Don't = a=20 connect to a known-garbage-spewing network today
> called the=20 Internet?  Not to sound coy or not, I am thinking
> = along the=20 same lines as Paul K. - that being, there's a
> certain amount = of=20 responsibility as end-users to bear the
> burden of "spew=20 reduction".  I think that it's more of a
> shared=20 responsibility between the end-users and the SP.
>
>=20 Adam  
>
> > -----Original = Message-----
> >=20 From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> > = Sent:=20 Wednesday, April 18, 2007 10:06 AM
> > To: Stastny Richard; = Paul=20 Kyzivat (pkyzivat); Otmar Lendl;
> > = speermint@ietf.org
> >=20 Subject: RE: [Speermint] Re-making or Un-making the PSTN
> > =
>=20 > Richard,
> >
> > What happens when one = end-user wants=20 to receive from anywhere, and
> > everyone else doesn't want = unsolicited garbage?
> >
> > Do you connect with = known=20 garbage spewing networks?
> >
> > The carrier has a = responsibility to act in the interests of all the
> > = users.
>=20 >
> > Mike
> >
> >
> > >=20 -----Original Message-----
> > > From: Stastny Richard=20 [mailto:Richard.Stastny@oefeg.at]
> > > Sent: Wednesday, = April 18,=20 2007 3:41 AM
> > > To: Paul Kyzivat (pkyzivat); Otmar = Lendl;=20 speermint@ietf.org
> > > Subject: RE: [Speermint] = Re-making or=20 Un-making the PSTN
> > >
> > > Paul = wrote
>=20 > > > The SP ought to be the agent for the end user's = policies=20 of
> > > whether to
> > > > restrict the = sources or=20 destinations of calls.
> > > >
> > > > = It may=20 be that better guarantees of service can be given
> > > = when there=20 is
> > > a
> > > > peering agreement = between source=20 and destination. But it
> > > seems absurd
> > = >=20 to
> > > > enforce that the only alternative is no = service at=20 all.
> > >
> > > This is what I always said = and what=20 is always forgotten in the
> > > discussion: The service = provider=20 is acting as an agent of the
> > > end-user. If an = end-user wants=20 to accept calls from anywhere
> > > - fine If the end-user = only=20 accepts calls with proper
> > identification -
> > = >=20 fine
> > >
> > > But this can only be = evaluated after=20 the service provider
> > accepts the
> > > INVITE = and=20 looks up the profile of the requested user.
> > >
> = >=20 > Richard
> > >
> > > > -----Original=20 Message-----
> > > > From: Paul Kyzivat=20 [mailto:pkyzivat@cisco.com]
> > > > Sent: Tuesday, = April 17,=20 2007 5:31 PM
> > > > To: Otmar Lendl;=20 speermint@ietf.org
> > > > Subject: Re: [Speermint] = Re-making=20 or Un-making the PSTN
> > > >
> > > > =
>=20 > > >
> > > > Otmar Lendl wrote:
> > = >=20 > > On 2007/04/13 22:04, "Uzelac, Adam"
> > >=20 <Adam.Uzelac@globalcrossing.com>
> > > > = wrote:
>=20 > > > >> As I sit here working on the VoIP use-case = draft,=20 I
> > > can't help but
> > > > >> = thinking if=20 we aren't just re-making the PSTN, instead
> > > of=20 un-making
> > > it.
> > > > >> The = crux of=20 this issue lies with the routing.  At some
> > > = of the=20 basic
> > > > >> constructs of next-hop routing = decisions=20 that border
> > > elements need
> > > = to
> >=20 > > >> do, these use-cases are starting to smell more and = more=20 like
> > > PSTN-based
> > > > >> = routing=20 look-ups.
> > > > >
> > > > > Not = just=20 PSTN routing. IP routing is another example.
> > > >=20 >
> > > > > The source is IMHO the = following:
>=20 > > > >
> > > > > * With the = email-model, no=20 multihop L7 routing is needed:
> > > The source
> = > >=20 > >   contacts the destination directly and relies on=20 the
> > > underlying IP
> > > > = >  =20 network to do the heavy lifting in terms of routing.
> > > = >=20 >
> > > > > * The email model has been (mostly) = rejected=20 by the real life
> > > > >   VoIP = deployments. The=20 reason seems to be that most carriers
> > > > = >  =20 simply will not accept incoming SIP calls from the wide open
> = > >=20 > >   Internet.
> > > >
> > = > >=20 IMO this needs to change. Maybe it will take legislation,
> > = > or=20 maybe the
> > > > free market will fix it (if we ever = get a=20 free market),
> > but it needs
> > > to
> = > >=20 > change. The SP ought to be the agent for the end user's
> = >=20 policies of
> > > > whether to restrict the sources or=20 destinations of calls.
> > > >
> > > > = It may=20 be that better guarantees of service can be given
> > > = when there=20 is
> > > a
> > > > peering agreement = between source=20 and destination. But it
> > > seems absurd
> > = >=20 to
> > > > enforce that the only alternative is no = service at=20 all.
> > > >
> > > > So it seems to me = that the=20 purpose of the peering
> > > agreements ought to
> = > >=20 be
> > > > to assist in obtaining the degree of service = that=20 the
> > caller is and
> > > > callee desire, = or coming=20 as close as possible.
> > > >
> > > >=20     Paul
> > > >
> > > = >=20 > The rest follows:
> > > > >
> > > = > >=20 A source network cannot be sure that the destination
> > = network=20 will
> > > > > accept INVITES it sends via the=20 Internet.
> > > > >
> > > > > It = thus=20 needs to employ the help of "transit" services.
> > > > = >
> > > > > Once there are competing operators = who offer=20 transit
> > services, the
> > > set
> > = >=20 > > of carriers and their links form a text-book example of = a
>=20 > > graph. Go
> > > > > to any Networking 101 = class to=20 learn about solutions to
> > > such an old
> > = > >=20 > fashioned routing problem.
> > > > >
> = > >=20 > > ----
> > > > >
> > > > > = Summary: If GC/Level3/DT/ATT/... and all the other
> carriers=20 can
> > > agree to
> > > > > directly = accept=20 calls from all VoIP operators (regardless
> > > of = country
>=20 > > of
> > > > > origin), and thus implicitly = also=20 from other operators
> > with which
> > > = they
>=20 > > > > haven't signed a contract, THEN AND ONLY THEN can = we avoid=20 the
> > > routing
> > > > > = problem.
>=20 > > > >
> > > > > I consider this to be = pretty=20 unlikely.
> > > > >
> > > > > I've = written=20 up a draft on this topic which will be
> > > submitted to=20 the
> > > > > archives soon.
> > > >=20 >
> > > > > /ol
> > > >
> = > >=20 > _______________________________________________
> > > = >=20 Speermint mailing list
> > > > = Speermint@ietf.org
> >=20 > > https://www1.ietf.org/mailman/listinfo/speermint
&= gt;=20 > >
> > >=20 _______________________________________________
> > > = Speermint=20 mailing list
> > > Speermint@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
&= gt;=20 > >
> >
> >=20 _______________________________________________
> > Speermint = mailing=20 list
> > Speermint@ietf.org
> > https://www1.ietf.org/mailman/listinfo/speermint
&= gt;=20 >
>=20

_______________________________________________
Speermint = mailing=20 list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint


Ahhh...imagining that irresistible "new car" smell?
Check out new=20 cars at Yahoo! Autos. ------_=_NextPart_001_01C781D2.FDDE5D87-- --===============0032927468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --===============0032927468==-- From speermint-bounces@ietf.org Wed Apr 18 12:17: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 1HeCqo-00011w-Oz; Wed, 18 Apr 2007 12:17:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCqn-00011r-SO for speermint@ietf.org; Wed, 18 Apr 2007 12:17:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCqm-00017E-Hz for speermint@ietf.org; Wed, 18 Apr 2007 12:17:45 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 18 Apr 2007 09:17:44 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="412773627:sNHT47773648" 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 l3IGHifF030072; Wed, 18 Apr 2007 09:17:44 -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 l3IGHCAU011922; Wed, 18 Apr 2007 16:17:39 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); Wed, 18 Apr 2007 12:17:23 -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); Wed, 18 Apr 2007 12:17:23 -0400 Message-ID: <46264492.4010109@cisco.com> Date: Wed, 18 Apr 2007 12:17:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com><32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 16:17:23.0327 (UTC) FILETIME=[0C08D0F0:01C781D5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1441; t=1176913064; x=1177777064; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20; bh=Dbn5PYKqY8jEIHUVd/bQX0dWvn7qEc5vJFrzGEfKv9A=; b=CLim0JKjMUEmzte7QJ85RWj3EYgV+3ek6UFhw7nchNc6Gp12RQblSDT8mmn2T4dXox+hfJ15 xfhQokGY86Gi5dz45JMe99fzlFy457G1zTozyGf1Gzd2gj/x28+wtQ+d; 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: 97adf591118a232206bdb5a27b217034 Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Adam, > > The Internet moves packets. The question is when communicating over the > Internet between VoIP platforms, I may want to have some authentication > mechanisms in place to enable the called user to have white list control > (by way of example). > > If a network, in its own policy, refuses to support any means of > identifying the caller, even if it is as "anonymous, contact me later if > there is problem with this particular user", are you saying I should > submit my network to abuse? If your network receives an incoming request and cannot acccurately identify the caller, then it can simply treat the caller identification as "unknown". Callee policies can then reject calls with unknown identification if they wish. > I am not masochistic and assume each network has the right to protect > itself and its users, as it sees fit. I also assume the customers will > judge the trade-offs made. If there was an open market, where I could choose a "big brother" provider that filters my traffic, or a lenient provider that allows me to make my own filtering rules, then I wouldn't have too much of a problem. But it seems that we aren't likely to have that. Also, what about the flip side of this. Is the SP "protecting the customers" by preventing them from calling a destination when it has no service agreement with that destination? Paul _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:20: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 1HeCt4-0003kS-LJ; Wed, 18 Apr 2007 12:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCt3-0003kN-Qf for speermint@ietf.org; Wed, 18 Apr 2007 12:20:05 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCt3-0001mQ-CY for speermint@ietf.org; Wed, 18 Apr 2007 12:20:05 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l3IGK3oK007313; Wed, 18 Apr 2007 16:20:03 GMT Subject: RE: [Speermint] Re-making or Un-making the PSTN From: Daryl Malas To: "Michael Hammer (mhammer)" In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain Date: Wed, 18 Apr 2007 10:33:25 -0600 Message-Id: <1176914005.17141.151.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I saw earlier the comment that an end-user wouldn't want to change SP's just to change the level of filtering (if I recall correctly). I find this interesting considering most open-email providers (e.g. Yahoo, Google, AOL, etc.) provide, on behalf of, their subscribers spam filtering. If you don't like Google's spam filter, you can either shut it off completely (in comes the garbage) or go to Yahoo, for example. Isn't this exactly the situation you were suggesting would be bad in VoIP environments? Isn't this the example correlation you are making regarding the email world? BTW, if an email arrives a little late to a end-user, due to a spam blast on an email server, then no on really cares that much. They just think, "Oh well...the internet is slow again." If someone child is getting a "fast busy" trying to call home, because someone is "spamming" their home phone....how do you think that will fly? --Daryl On Wed, 2007-04-18 at 10:05 -0400, Michael Hammer (mhammer) wrote: > Richard, > > What happens when one end-user wants to receive from anywhere, > and everyone else doesn't want unsolicited garbage? > > Do you connect with known garbage spewing networks? > > The carrier has a responsibility to act in the interests of all the > users. > > Mike > > > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Wednesday, April 18, 2007 3:41 AM > > To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > > > Paul wrote > > > The SP ought to be the agent for the end user's policies of > > whether to > > > restrict the sources or destinations of calls. > > > > > > It may be that better guarantees of service can be given > > when there is > > a > > > peering agreement between source and destination. But it > > seems absurd > > to > > > enforce that the only alternative is no service at all. > > > > This is what I always said and what is always forgotten in the > > discussion: The service provider is acting as an agent of the > > end-user. If an end-user wants to accept calls from anywhere > > - fine If the end-user only accepts calls with proper > > identification - fine > > > > But this can only be evaluated after the service provider > > accepts the INVITE and looks up the profile of the requested user. > > > > Richard > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > Sent: Tuesday, April 17, 2007 5:31 PM > > > To: Otmar Lendl; speermint@ietf.org > > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > > > > > > > > > Otmar Lendl wrote: > > > > On 2007/04/13 22:04, "Uzelac, Adam" > > > > > wrote: > > > >> As I sit here working on the VoIP use-case draft, I > > can't help but > > > >> thinking if we aren't just re-making the PSTN, instead > > of un-making > > it. > > > >> The crux of this issue lies with the routing. At some > > of the basic > > > >> constructs of next-hop routing decisions that border > > elements need > > to > > > >> do, these use-cases are starting to smell more and more like > > PSTN-based > > > >> routing look-ups. > > > > > > > > Not just PSTN routing. IP routing is another example. > > > > > > > > The source is IMHO the following: > > > > > > > > * With the email-model, no multihop L7 routing is needed: > > The source > > > > contacts the destination directly and relies on the > > underlying IP > > > > network to do the heavy lifting in terms of routing. > > > > > > > > * The email model has been (mostly) rejected by the real life > > > > VoIP deployments. The reason seems to be that most carriers > > > > simply will not accept incoming SIP calls from the wide open > > > > Internet. > > > > > > IMO this needs to change. Maybe it will take legislation, > > or maybe the > > > free market will fix it (if we ever get a free market), but it needs > > to > > > change. The SP ought to be the agent for the end user's policies of > > > whether to restrict the sources or destinations of calls. > > > > > > It may be that better guarantees of service can be given > > when there is > > a > > > peering agreement between source and destination. But it > > seems absurd > > to > > > enforce that the only alternative is no service at all. > > > > > > So it seems to me that the purpose of the peering > > agreements ought to > > be > > > to assist in obtaining the degree of service that the caller is and > > > callee desire, or coming as close as possible. > > > > > > Paul > > > > > > > The rest follows: > > > > > > > > A source network cannot be sure that the destination network will > > > > accept INVITES it sends via the Internet. > > > > > > > > It thus needs to employ the help of "transit" services. > > > > > > > > Once there are competing operators who offer transit services, the > > set > > > > of carriers and their links form a text-book example of a > > graph. Go > > > > to any Networking 101 class to learn about solutions to > > such an old > > > > fashioned routing problem. > > > > > > > > ---- > > > > > > > > Summary: If GC/Level3/DT/ATT/... and all the other carriers can > > agree to > > > > directly accept calls from all VoIP operators (regardless > > of country > > of > > > > origin), and thus implicitly also from other operators with which > > they > > > > haven't signed a contract, THEN AND ONLY THEN can we avoid the > > routing > > > > problem. > > > > > > > > I consider this to be pretty unlikely. > > > > > > > > I've written up a draft on this topic which will be > > submitted to the > > > > archives soon. > > > > > > > > /ol > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:24: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 1HeCxL-0006Xe-0w; Wed, 18 Apr 2007 12:24:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCxJ-0006WI-Rj for speermint@ietf.org; Wed, 18 Apr 2007 12:24:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCxJ-0002ga-8B for speermint@ietf.org; Wed, 18 Apr 2007 12:24:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2007 09:24:29 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="370486525:sNHT59269870" 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 l3IGOR94003110; Wed, 18 Apr 2007 12:24:27 -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 l3IGO0lq029235; Wed, 18 Apr 2007 16:24:27 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); Wed, 18 Apr 2007 12:24:16 -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); Wed, 18 Apr 2007 12:24:16 -0400 Message-ID: <4626462F.5030104@cisco.com> Date: Wed, 18 Apr 2007 12:24:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <46263C7D.7040708@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A24@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E75A24@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 16:24:16.0180 (UTC) FILETIME=[021D2F40:01C781D6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6872; t=1176913467; x=1177777467; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Michael=20Hammer=20(mhammer)=22=20; bh=objz3XeFHXECwJspf0VTQ/wkPCaXTG8Q/XpFwOCib70=; b=Y60jkKvIK0lcOQ7Yb6Ay/IzHqLGx+NZesuROIHZeb1TYXMYRvGSTSS8+F1hbew2oD6j2PTbJ OvcIqaqGt0MlIohfb1f3Dpf4YDqjQtPQwHJ3+yVYWSCsNNU6SIeBUA3B; 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: 16c9da4896bf5539ae3547c6c25f06a0 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Paul, > > Yes. I am hoping that service providers can agree on some set of > operating rules/practices that enable the finer grain control to happen. > The problem comes if a particular SP doesn't want to operate with any > degree of civility. I may or may not agree with you depending on exactly what you mean. If one SP mounts a DoS attack on another then it makes sense to blacklist it. But if it simply doesn't provide some unusual sort of identity information, or doesn't support settlement, then I think it should be the option for the target user to make the decision. Paul > The high level goal for me is that the PSTN has a certain level of trust > and moving to a level of trust as problematic as that of email seems > like a step in the wrong direction. > > Mike > > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Wednesday, April 18, 2007 11:43 AM >> To: Michael Hammer (mhammer) >> Cc: Stastny Richard; Otmar Lendl; speermint@ietf.org >> Subject: Re: [Speermint] Re-making or Un-making the PSTN >> >> >> >> Michael Hammer (mhammer) wrote: >>> Richard, >>> >>> What happens when one end-user wants to receive from anywhere, and >>> everyone else doesn't want unsolicited garbage? >>> >>> Do you connect with known garbage spewing networks? >>> >>> The carrier has a responsibility to act in the interests of all the >>> users. >> It would be quite reasonable for the provider to have an >> optional (perhaps default) filter policy that rejects calls >> from untrusted sources (with trust defined by the SP). Its >> just that this needs to be applied on a per target basis >> rather than on a per-SP basis. >> >> Admittedly if the SP has 10m subscribers and only one of them >> wants this then they probably won't be incented to do it. But >> I think there will be more than that who want it. >> >> Paul >> >> >>> Mike >>> >>> >>>> -----Original Message----- >>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>> Sent: Wednesday, April 18, 2007 3:41 AM >>>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org >>>> Subject: RE: [Speermint] Re-making or Un-making the PSTN >>>> >>>> Paul wrote >>>>> The SP ought to be the agent for the end user's policies of >>>> whether to >>>>> restrict the sources or destinations of calls. >>>>> >>>>> It may be that better guarantees of service can be given >>>> when there is >>>> a >>>>> peering agreement between source and destination. But it >>>> seems absurd >>>> to >>>>> enforce that the only alternative is no service at all. >>>> This is what I always said and what is always forgotten in the >>>> discussion: The service provider is acting as an agent of the >>>> end-user. If an end-user wants to accept calls from anywhere >>>> - fine If the end-user only accepts calls with proper >> identification >>>> - fine >>>> >>>> But this can only be evaluated after the service provider >> accepts the >>>> INVITE and looks up the profile of the requested user. >>>> >>>> Richard >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Tuesday, April 17, 2007 5:31 PM >>>>> To: Otmar Lendl; speermint@ietf.org >>>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>>>> >>>>> >>>>> >>>>> Otmar Lendl wrote: >>>>>> On 2007/04/13 22:04, "Uzelac, Adam" >>>> >>>>> wrote: >>>>>>> As I sit here working on the VoIP use-case draft, I >>>> can't help but >>>>>>> thinking if we aren't just re-making the PSTN, instead >>>> of un-making >>>> it. >>>>>>> The crux of this issue lies with the routing. At some >>>> of the basic >>>>>>> constructs of next-hop routing decisions that border >>>> elements need >>>> to >>>>>>> do, these use-cases are starting to smell more and more like >>>> PSTN-based >>>>>>> routing look-ups. >>>>>> Not just PSTN routing. IP routing is another example. >>>>>> >>>>>> The source is IMHO the following: >>>>>> >>>>>> * With the email-model, no multihop L7 routing is needed: >>>> The source >>>>>> contacts the destination directly and relies on the >>>> underlying IP >>>>>> network to do the heavy lifting in terms of routing. >>>>>> >>>>>> * The email model has been (mostly) rejected by the real life >>>>>> VoIP deployments. The reason seems to be that most carriers >>>>>> simply will not accept incoming SIP calls from the wide open >>>>>> Internet. >>>>> IMO this needs to change. Maybe it will take legislation, >>>> or maybe the >>>>> free market will fix it (if we ever get a free market), >> but it needs >>>> to >>>>> change. The SP ought to be the agent for the end user's >> policies of >>>>> whether to restrict the sources or destinations of calls. >>>>> >>>>> It may be that better guarantees of service can be given >>>> when there is >>>> a >>>>> peering agreement between source and destination. But it >>>> seems absurd >>>> to >>>>> enforce that the only alternative is no service at all. >>>>> >>>>> So it seems to me that the purpose of the peering >>>> agreements ought to >>>> be >>>>> to assist in obtaining the degree of service that the >> caller is and >>>>> callee desire, or coming as close as possible. >>>>> >>>>> Paul >>>>> >>>>>> The rest follows: >>>>>> >>>>>> A source network cannot be sure that the destination >> network will >>>>>> accept INVITES it sends via the Internet. >>>>>> >>>>>> It thus needs to employ the help of "transit" services. >>>>>> >>>>>> Once there are competing operators who offer transit >> services, the >>>> set >>>>>> of carriers and their links form a text-book example of a >>>> graph. Go >>>>>> to any Networking 101 class to learn about solutions to >>>> such an old >>>>>> fashioned routing problem. >>>>>> >>>>>> ---- >>>>>> >>>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can >>>> agree to >>>>>> directly accept calls from all VoIP operators (regardless >>>> of country >>>> of >>>>>> origin), and thus implicitly also from other operators with which >>>> they >>>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the >>>> routing >>>>>> problem. >>>>>> >>>>>> I consider this to be pretty unlikely. >>>>>> >>>>>> I've written up a draft on this topic which will be >>>> submitted to the >>>>>> archives soon. >>>>>> >>>>>> /ol >>>>> _______________________________________________ >>>>> Speermint mailing list >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>> _______________________________________________ >>>> Speermint mailing list >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint >>>> > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:25: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 1HeCy3-0007Z2-Bw; Wed, 18 Apr 2007 12:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCy2-0007Yx-A0 for speermint@ietf.org; Wed, 18 Apr 2007 12:25:14 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCy0-0003DC-O5 for speermint@ietf.org; Wed, 18 Apr 2007 12:25:14 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l3IGPBoK008635; Wed, 18 Apr 2007 16:25:11 GMT Subject: RE: [Speermint] Re-making or Un-making the PSTN From: Daryl Malas To: "Michael Hammer (mhammer)" In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <4624FB8F.7040408@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=utf-8 Date: Wed, 18 Apr 2007 10:38:33 -0600 Message-Id: <1176914313.17141.157.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by f4bb49-05.idc1.level3.com id l3IGPBoK008635 X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org IMO, I think the PSTN becoming IP-enabled is far more likely than the PSTN becoming an extension of the Internet. What I think we are doing here is adding capabilities, which can exist in an IP world that the TDM-PSTN cannot or would not want to adopt if it even wanted to. I think this is what we are trying to do. Sure we might dabble with open end-to-end (e.g. P2P, etc.), stuff, but I believe the IP-PSTN (;-)) will exist in a highly regulated walled off arena for quite some time. Many efficiencies and capabilities can be made to make it much better by the work we are doing though, in the mean time. On Tue, 2007-04-17 at 13:13 -0400, Michael Hammer (mhammer) wrote: > Paul, >=20 > This is not about stopping individual calls. It is about accountabilit= y for those calls. You may still get the call, but there can be conseque= nces. >=20 > This is developing a network without the na=C3=AFve assumption that eve= ryone is trustworthy. The Internet itself assumed that and now some folk= s are questioning the wisdom of that fundamental assumption and wanting t= o design the next generation of Internet with different assumptions due t= o DDoS and Spam and other miscreant behavior. >=20 > This is in effect the PSTN redefining itself as an IP-based network. S= hould it follow that same na=C3=AFve assumption? >=20 > Remember the definition of insanity: Doing the exact same thing over ag= ain and expecting a different result. :) >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat (pkyzivat)=20 > > Sent: Tuesday, April 17, 2007 12:54 PM > > To: Michael Hammer (mhammer) > > Cc: Otmar Lendl; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > >=20 > >=20 > >=20 > > Michael Hammer (mhammer) wrote: > > > Otmar, > > >=20 > > > Eventually, the PSTN as backup will go away. > > >=20 > > > The issue here is trust and accountability of from whom one accepts= =20 > > > calls. > > >=20 > > > The same could be said for email. Folks are working on=20 > > that, I think. > > >=20 > > > I'd rather not get calls from systems that are purposely avoiding=20 > > > accountability. They tend to be spammers. > >=20 > > It would be great to have that kind of control over who you=20 > > receive calls from. But its *policy*, and the same policy is=20 > > not right for everybody. > >=20 > > In the case of spam, I'd rather get it all than have the=20 > > decision of what I get be made by my service provider. Just=20 > > think how bad it would be if the only way you could choose=20 > > your spam filter was by which SP you signed up with. I'd like=20 > > the same degree of control over VoIP and IM. > >=20 > > Paul > >=20 > > > Mike > > >=20 > > >=20 > > >> -----Original Message----- > > >> From: Otmar Lendl [mailto:lendl@nic.at] > > >> Sent: Tuesday, April 17, 2007 11:55 AM > > >> To: Paul Kyzivat (pkyzivat) > > >> Cc: speermint@ietf.org > > >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > > >> > > >> On 2007/04/17 17:04, Paul Kyzivat wrote: > > >>> Otmar Lendl wrote: > > >>>> * The email model has been (mostly) rejected by the real=20 > > life VoIP=20 > > >>>> deployments. The reason seems to be that most carriers =20 > > simply will=20 > > >>>> not accept incoming SIP calls from the wide open Internet. > > >>> IMO this needs to change. Maybe it will take legislation, > > >> or maybe the > > >>> free market will fix it (if we ever get a free market), but > > >> it needs > > >>> to change. The SP ought to be the agent for the end user's > > >> policies of > > >>> whether to restrict the sources or destinations of calls. > > >>> > > >>> It may be that better guarantees of service can be given > > >> when there is > > >>> a peering agreement between source and destination. But it seems=20 > > >>> absurd to enforce that the only alternative is no service at all. > > >> IMHO the single most important reason for the current state of=20 > > >> affairs is the fact that there *is* an alternative: the=20 > > PSTN. Walling=20 > > >> off your SIP service does not mean that your customers are not=20 > > >> reachable. It only implies that calls have to be routed=20 > > via the PSTN. > > >> > > >> That's the main difference to email: if you reject the=20 > > incoming SMTP=20 > > >> connection, then you don't get this email. > > >> There is no automatic fallback to snail-mail. New entrants=20 > > into the=20 > > >> email space thus had no other choice but accept SMTP=20 > > connections from=20 > > >> almost all hosts on the Internet. Those are the rules of=20 > > email: you=20 > > >> can take them or risk losing your reachability. > > >> > > >> E.164 based VoIP is different: there has always been the PSTN as a= =20 > > >> backup, as a default interconnection fabric. > > >> > > >>> So it seems to me that the purpose of the peering > > >> agreements ought to > > >>> be to assist in obtaining the degree of service that the > > >> caller is and > > >>> callee desire, or coming as close as possible. > > >> In an ideal world: yes.=20 > > >> > > >> For now, I'd settle for "peering agreement ought to make direct=20 > > >> interconnection possible". > > >> > > >> /ol > > >> -- > > >> / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > > >> | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > > >> \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > > >> > > >> _______________________________________________ > > >> Speermint mailing list > > >> Speermint@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/speermint > > >> > > >=20 > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:28: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 1HeD1G-0001ew-Jh; Wed, 18 Apr 2007 12:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeD1F-0001er-Nu for speermint@ietf.org; Wed, 18 Apr 2007 12:28:33 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeD1E-0003vl-Cy for speermint@ietf.org; Wed, 18 Apr 2007 12:28:33 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l3IGS2oK009177; Wed, 18 Apr 2007 16:28:02 GMT Subject: Re: [Speermint] Re-making or Un-making the PSTN From: Daryl Malas To: Paul Kyzivat In-Reply-To: <46264492.4010109@cisco.com> References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> <46264492.4010109@cisco.com> Content-Type: text/plain Date: Wed, 18 Apr 2007 10:41:24 -0600 Message-Id: <1176914484.17141.161.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl , "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Comments in-line... n Wed, 2007-04-18 at 12:17 -0400, Paul Kyzivat wrote: > > Michael Hammer (mhammer) wrote: > > Adam, > > > > The Internet moves packets. The question is when communicating over the > > Internet between VoIP platforms, I may want to have some authentication > > mechanisms in place to enable the called user to have white list control > > (by way of example). > > > > If a network, in its own policy, refuses to support any means of > > identifying the caller, even if it is as "anonymous, contact me later if > > there is problem with this particular user", are you saying I should > > submit my network to abuse? > > If your network receives an incoming request and cannot acccurately > identify the caller, then it can simply treat the caller identification > as "unknown". Callee policies can then reject calls with unknown > identification if they wish. > > > I am not masochistic and assume each network has the right to protect > > itself and its users, as it sees fit. I also assume the customers will > > judge the trade-offs made. > > If there was an open market, where I could choose a "big brother" > provider that filters my traffic, or a lenient provider that allows me > to make my own filtering rules, then I wouldn't have too much of a > problem. But it seems that we aren't likely to have that. > > Also, what about the flip side of this. Is the SP "protecting the > customers" by preventing them from calling a destination when it has no > service agreement with that destination? > FYi...The PSTN does this today...carriers block their customers from calling some NPA's that have a bad reputation for seriously ripping off customers of 100's of dollars. I would believe this would continue to occur whether it's IP or not. > Paul > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:37: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 1HeDA6-00007c-2g; Wed, 18 Apr 2007 12:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDA4-00007X-DW for speermint@ietf.org; Wed, 18 Apr 2007 12:37:40 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDA2-0006FE-Vz for speermint@ietf.org; Wed, 18 Apr 2007 12:37:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2007 09:37:22 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="370491366:sNHT41889747402" 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 l3IGbK3E010004; Wed, 18 Apr 2007 12:37:20 -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 l3IGaflo003234; Wed, 18 Apr 2007 16:37:20 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); Wed, 18 Apr 2007 12:37: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); Wed, 18 Apr 2007 12:37:20 -0400 Message-ID: <4626493F.6030805@cisco.com> Date: Wed, 18 Apr 2007 12:37:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Daryl Malas Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <1176914005.17141.151.camel@montag.eng.level3.com> In-Reply-To: <1176914005.17141.151.camel@montag.eng.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 16:37:20.0077 (UTC) FILETIME=[D55A5FD0:01C781D7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6903; t=1176914240; x=1177778240; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20Daryl=20Malas=20; bh=g8JpGU1UTktz1LUddXosWXV87smP+kD8VPopnoevLFI=; b=v8kNdIOSGwe4VkQMpp9kf+s4FbwogRfPE17IWoRMhFmBRvl7y+1LAobjRyLS1veAtqBDWK/m TPXtGkYE25wk3doAwHPloA4w244yOEBqbwtYFYxROLjuvk2/b3WV4dBA; 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: 93df555cbdbcdae9621e5b95d44b301e Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl Malas wrote: > I saw earlier the comment that an end-user wouldn't want to change SP's > just to change the level of filtering (if I recall correctly). I find > this interesting considering most open-email providers (e.g. Yahoo, > Google, AOL, etc.) provide, on behalf of, their subscribers spam > filtering. If you don't like Google's spam filter, you can either shut > it off completely (in comes the garbage) or go to Yahoo, for example. > Isn't this exactly the situation you were suggesting would be bad in > VoIP environments? Isn't this the example correlation you are making > regarding the email world? Its not analogous, because you *can* shut the filtering off. Then you can implement your own filter using your own rules. It seems that for SIP peering as being discussed you won't have any option to turn it off. Ideally there would be some simple rule-based filters that could be *optionally* enabled for the target account to minimize the traffic that gets sent all the way to the phone. > BTW, if an email arrives a little late to a end-user, due to a spam > blast on an email server, then no on really cares that much. They just > think, "Oh well...the internet is slow again." If someone child is > getting a "fast busy" trying to call home, because someone is "spamming" > their home phone....how do you think that will fly? As I mentioned, I don't object to a SP blocking a DoS attack. (As long as it is careful how that is defined.) I realize that is in some sense a spam filter, but it seems qualitatively different to me. Paul > --Daryl > > On Wed, 2007-04-18 at 10:05 -0400, Michael Hammer (mhammer) wrote: >> Richard, >> >> What happens when one end-user wants to receive from anywhere, >> and everyone else doesn't want unsolicited garbage? >> >> Do you connect with known garbage spewing networks? >> >> The carrier has a responsibility to act in the interests of all the >> users. >> >> Mike >> >> >>> -----Original Message----- >>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>> Sent: Wednesday, April 18, 2007 3:41 AM >>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org >>> Subject: RE: [Speermint] Re-making or Un-making the PSTN >>> >>> Paul wrote >>>> The SP ought to be the agent for the end user's policies of >>> whether to >>>> restrict the sources or destinations of calls. >>>> >>>> It may be that better guarantees of service can be given >>> when there is >>> a >>>> peering agreement between source and destination. But it >>> seems absurd >>> to >>>> enforce that the only alternative is no service at all. >>> This is what I always said and what is always forgotten in the >>> discussion: The service provider is acting as an agent of the >>> end-user. If an end-user wants to accept calls from anywhere >>> - fine If the end-user only accepts calls with proper >>> identification - fine >>> >>> But this can only be evaluated after the service provider >>> accepts the INVITE and looks up the profile of the requested user. >>> >>> Richard >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, April 17, 2007 5:31 PM >>>> To: Otmar Lendl; speermint@ietf.org >>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>>> >>>> >>>> >>>> Otmar Lendl wrote: >>>>> On 2007/04/13 22:04, "Uzelac, Adam" >>> >>>> wrote: >>>>>> As I sit here working on the VoIP use-case draft, I >>> can't help but >>>>>> thinking if we aren't just re-making the PSTN, instead >>> of un-making >>> it. >>>>>> The crux of this issue lies with the routing. At some >>> of the basic >>>>>> constructs of next-hop routing decisions that border >>> elements need >>> to >>>>>> do, these use-cases are starting to smell more and more like >>> PSTN-based >>>>>> routing look-ups. >>>>> Not just PSTN routing. IP routing is another example. >>>>> >>>>> The source is IMHO the following: >>>>> >>>>> * With the email-model, no multihop L7 routing is needed: >>> The source >>>>> contacts the destination directly and relies on the >>> underlying IP >>>>> network to do the heavy lifting in terms of routing. >>>>> >>>>> * The email model has been (mostly) rejected by the real life >>>>> VoIP deployments. The reason seems to be that most carriers >>>>> simply will not accept incoming SIP calls from the wide open >>>>> Internet. >>>> IMO this needs to change. Maybe it will take legislation, >>> or maybe the >>>> free market will fix it (if we ever get a free market), but it needs >>> to >>>> change. The SP ought to be the agent for the end user's policies of >>>> whether to restrict the sources or destinations of calls. >>>> >>>> It may be that better guarantees of service can be given >>> when there is >>> a >>>> peering agreement between source and destination. But it >>> seems absurd >>> to >>>> enforce that the only alternative is no service at all. >>>> >>>> So it seems to me that the purpose of the peering >>> agreements ought to >>> be >>>> to assist in obtaining the degree of service that the caller is and >>>> callee desire, or coming as close as possible. >>>> >>>> Paul >>>> >>>>> The rest follows: >>>>> >>>>> A source network cannot be sure that the destination network will >>>>> accept INVITES it sends via the Internet. >>>>> >>>>> It thus needs to employ the help of "transit" services. >>>>> >>>>> Once there are competing operators who offer transit services, the >>> set >>>>> of carriers and their links form a text-book example of a >>> graph. Go >>>>> to any Networking 101 class to learn about solutions to >>> such an old >>>>> fashioned routing problem. >>>>> >>>>> ---- >>>>> >>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can >>> agree to >>>>> directly accept calls from all VoIP operators (regardless >>> of country >>> of >>>>> origin), and thus implicitly also from other operators with which >>> they >>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the >>> routing >>>>> problem. >>>>> >>>>> I consider this to be pretty unlikely. >>>>> >>>>> I've written up a draft on this topic which will be >>> submitted to the >>>>> archives soon. >>>>> >>>>> /ol >>>> _______________________________________________ >>>> Speermint mailing list >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint >>> _______________________________________________ >>> Speermint mailing list >>> Speermint@ietf.org >>> https://www1.ietf.org/mailman/listinfo/speermint >>> >> _______________________________________________ >> Speermint mailing list >> Speermint@ietf.org >> https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:56: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 1HeDSk-0003Xf-Fg; Wed, 18 Apr 2007 12:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSi-0003WB-2F for speermint@ietf.org; Wed, 18 Apr 2007 12:56:56 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDSE-0002jM-0I for speermint@ietf.org; Wed, 18 Apr 2007 12:56:27 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2007 09:56:25 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="137337343:sNHT58217427" 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 l3IGuOJL019080; Wed, 18 Apr 2007 12:56:24 -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 l3IGuElS008901; Wed, 18 Apr 2007 16:56:24 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); Wed, 18 Apr 2007 12:56: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); Wed, 18 Apr 2007 12:56:19 -0400 Message-ID: <46264DB3.30101@cisco.com> Date: Wed, 18 Apr 2007 12:56:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <1176914005.17141.151.camel@montag.eng.level3.com> <4626493F.6030805@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A6A@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E75A6A@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 16:56:19.0983 (UTC) FILETIME=[7CCA39F0:01C781DA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7981; t=1176915384; x=1177779384; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Michael=20Hammer=20(mhammer)=22=20; bh=RL8/fStVuS5pUViW6YFtObJ4yw2ed8g7Dj1co3bNY8Q=; b=eLmDtnf6bqezRCI0gP+H0SAxiv96Wve6GRGYOBXxm2z+TMAbA0YYk98brfj01Sn2qiszWSb6 WyY3u6stg8DWc3qIupyAf31IwWnvthUNeXidDPbo4hrlvU6sHDFfcT2l; 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: bcd240e64c427d3d3617cfc704e7fd7f Cc: Otmar Lendl , Stastny Richard , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > Filters are only as good as the information upon which to filter. > > Garbage in, garbage out. The carrier should be free to tag the message with contextual info, such as that this is from an unknown and untrusted source, and the filter can choose to act based on that. Paul > Mike > > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Wednesday, April 18, 2007 12:37 PM >> To: Daryl Malas >> Cc: Michael Hammer (mhammer); Stastny Richard; Otmar Lendl; >> speermint@ietf.org >> Subject: Re: [Speermint] Re-making or Un-making the PSTN >> >> >> >> Daryl Malas wrote: >>> I saw earlier the comment that an end-user wouldn't want to change >>> SP's just to change the level of filtering (if I recall >> correctly). I >>> find this interesting considering most open-email providers (e.g. >>> Yahoo, Google, AOL, etc.) provide, on behalf of, their subscribers >>> spam filtering. If you don't like Google's spam filter, you can >>> either shut it off completely (in comes the garbage) or go >> to Yahoo, for example. >>> Isn't this exactly the situation you were suggesting would >> be bad in >>> VoIP environments? Isn't this the example correlation you >> are making >>> regarding the email world? >> Its not analogous, because you *can* shut the filtering off. >> Then you can implement your own filter using your own rules. >> >> It seems that for SIP peering as being discussed you won't >> have any option to turn it off. >> >> Ideally there would be some simple rule-based filters that could be >> *optionally* enabled for the target account to minimize the >> traffic that gets sent all the way to the phone. >> >>> BTW, if an email arrives a little late to a end-user, due to a spam >>> blast on an email server, then no on really cares that much. They >>> just think, "Oh well...the internet is slow again." If >> someone child >>> is getting a "fast busy" trying to call home, because >> someone is "spamming" >>> their home phone....how do you think that will fly? >> As I mentioned, I don't object to a SP blocking a DoS attack. >> (As long as it is careful how that is defined.) I realize >> that is in some sense a spam filter, but it seems >> qualitatively different to me. >> >> Paul >> >>> --Daryl >>> >>> On Wed, 2007-04-18 at 10:05 -0400, Michael Hammer (mhammer) wrote: >>>> Richard, >>>> >>>> What happens when one end-user wants to receive from anywhere, and >>>> everyone else doesn't want unsolicited garbage? >>>> >>>> Do you connect with known garbage spewing networks? >>>> >>>> The carrier has a responsibility to act in the interests >> of all the >>>> users. >>>> >>>> Mike >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>> Sent: Wednesday, April 18, 2007 3:41 AM >>>>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org >>>>> Subject: RE: [Speermint] Re-making or Un-making the PSTN >>>>> >>>>> Paul wrote >>>>>> The SP ought to be the agent for the end user's policies of >>>>> whether to >>>>>> restrict the sources or destinations of calls. >>>>>> >>>>>> It may be that better guarantees of service can be given >>>>> when there is >>>>> a >>>>>> peering agreement between source and destination. But it >>>>> seems absurd >>>>> to >>>>>> enforce that the only alternative is no service at all. >>>>> This is what I always said and what is always forgotten in the >>>>> discussion: The service provider is acting as an agent of the >>>>> end-user. If an end-user wants to accept calls from anywhere >>>>> - fine If the end-user only accepts calls with proper >> identification >>>>> - fine >>>>> >>>>> But this can only be evaluated after the service provider accepts >>>>> the INVITE and looks up the profile of the requested user. >>>>> >>>>> Richard >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: Tuesday, April 17, 2007 5:31 PM >>>>>> To: Otmar Lendl; speermint@ietf.org >>>>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>>>>> >>>>>> >>>>>> >>>>>> Otmar Lendl wrote: >>>>>>> On 2007/04/13 22:04, "Uzelac, Adam" >>>>> >>>>>> wrote: >>>>>>>> As I sit here working on the VoIP use-case draft, I >>>>> can't help but >>>>>>>> thinking if we aren't just re-making the PSTN, instead >>>>> of un-making >>>>> it. >>>>>>>> The crux of this issue lies with the routing. At some >>>>> of the basic >>>>>>>> constructs of next-hop routing decisions that border >>>>> elements need >>>>> to >>>>>>>> do, these use-cases are starting to smell more and more like >>>>> PSTN-based >>>>>>>> routing look-ups. >>>>>>> Not just PSTN routing. IP routing is another example. >>>>>>> >>>>>>> The source is IMHO the following: >>>>>>> >>>>>>> * With the email-model, no multihop L7 routing is needed: >>>>> The source >>>>>>> contacts the destination directly and relies on the >>>>> underlying IP >>>>>>> network to do the heavy lifting in terms of routing. >>>>>>> >>>>>>> * The email model has been (mostly) rejected by the real life >>>>>>> VoIP deployments. The reason seems to be that most carriers >>>>>>> simply will not accept incoming SIP calls from the wide open >>>>>>> Internet. >>>>>> IMO this needs to change. Maybe it will take legislation, >>>>> or maybe the >>>>>> free market will fix it (if we ever get a free market), but it >>>>>> needs >>>>> to >>>>>> change. The SP ought to be the agent for the end user's >> policies of >>>>>> whether to restrict the sources or destinations of calls. >>>>>> >>>>>> It may be that better guarantees of service can be given >>>>> when there is >>>>> a >>>>>> peering agreement between source and destination. But it >>>>> seems absurd >>>>> to >>>>>> enforce that the only alternative is no service at all. >>>>>> >>>>>> So it seems to me that the purpose of the peering >>>>> agreements ought to >>>>> be >>>>>> to assist in obtaining the degree of service that the >> caller is and >>>>>> callee desire, or coming as close as possible. >>>>>> >>>>>> Paul >>>>>> >>>>>>> The rest follows: >>>>>>> >>>>>>> A source network cannot be sure that the destination >> network will >>>>>>> accept INVITES it sends via the Internet. >>>>>>> >>>>>>> It thus needs to employ the help of "transit" services. >>>>>>> >>>>>>> Once there are competing operators who offer transit >> services, the >>>>> set >>>>>>> of carriers and their links form a text-book example of a >>>>> graph. Go >>>>>>> to any Networking 101 class to learn about solutions to >>>>> such an old >>>>>>> fashioned routing problem. >>>>>>> >>>>>>> ---- >>>>>>> >>>>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can >>>>> agree to >>>>>>> directly accept calls from all VoIP operators (regardless >>>>> of country >>>>> of >>>>>>> origin), and thus implicitly also from other operators >> with which >>>>> they >>>>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the >>>>> routing >>>>>>> problem. >>>>>>> >>>>>>> I consider this to be pretty unlikely. >>>>>>> >>>>>>> I've written up a draft on this topic which will be >>>>> submitted to the >>>>>>> archives soon. >>>>>>> >>>>>>> /ol >>>>>> _______________________________________________ >>>>>> Speermint mailing list >>>>>> Speermint@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>> _______________________________________________ >>>>> Speermint mailing list >>>>> Speermint@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>> >>>> _______________________________________________ >>>> Speermint mailing list >>>> Speermint@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:57: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 1HeDSt-0003fl-3L; Wed, 18 Apr 2007 12:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSl-0003X5-Sv for speermint@ietf.org; Wed, 18 Apr 2007 12:56:59 -0400 Received: from unknown-230-det.globalcrossing.com ([64.208.159.230] helo=mailsrv.ams.gblxint.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDOe-0001G9-TR for speermint@ietf.org; Wed, 18 Apr 2007 12:52:46 -0400 Received: from w3uspdy20.ams.gblxint.com (w3uspdy20.ams.gblxint.com [10.60.51.55]) by mailsrv.ams.gblxint.com (Postfix) with ESMTP id 4FB9595CD; Wed, 18 Apr 2007 12:52:42 -0400 (EDT) Received: from EVS2.ams.gblxint.com ([10.60.51.59]) by w3uspdy20.ams.gblxint.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:52:41 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 12:52:41 -0400 Message-ID: In-Reply-To: <1176914313.17141.157.camel@montag.eng.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB1ioeP5CYOk4dQpWfRuQegZ3pAwAA4V7A References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com><20070417155431.GA30254@nic.at><072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com><4624FB8F.7040408@cisco.com><072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> <1176914313.17141.157.camel@montag.eng.level3.com> From: "Uzelac, Adam" To: "Daryl Malas" , "Michael Hammer (mhammer)" X-OriginalArrivalTime: 18 Apr 2007 16:52:41.0952 (UTC) FILETIME=[FAD55600:01C781D9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I read this as a vote that the Speermint activities are a re-making, possibly with added stuff, but a re-making nonetheless, of the PSTN - versus un-making. Did I read this incorrectly? Adam=20 > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net]=20 > Sent: Wednesday, April 18, 2007 12:39 PM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org; Otmar Lendl > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > IMO, I think the PSTN becoming IP-enabled is far more likely=20 > than the PSTN becoming an extension of the Internet. What I=20 > think we are doing here is adding capabilities, which can=20 > exist in an IP world that the TDM-PSTN cannot or would not=20 > want to adopt if it even wanted to. I think this is what we=20 > are trying to do. Sure we might dabble with open end-to-end=20 > (e.g. P2P, etc.), stuff, but I believe the IP-PSTN (;-)) will=20 > exist in a highly regulated walled off arena for quite some=20 > time. Many efficiencies and capabilities can be made to make=20 > it much better by the work we are doing though, in the mean time. >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:57: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 1HeDT2-0003yT-GJ; Wed, 18 Apr 2007 12:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSo-0003ae-GF for speermint@ietf.org; Wed, 18 Apr 2007 12:57:03 -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 1HeDLg-0000lL-9e for speermint@ietf.org; Wed, 18 Apr 2007 12:49:40 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 18 Apr 2007 09:49:39 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="479198751:sNHT63836008" 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 l3IGncIQ015839; Wed, 18 Apr 2007 12:49:38 -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 l3IGnYlK006775; Wed, 18 Apr 2007 16:49:38 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:48:57 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 12:48:53 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75A6A@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <4626493F.6030805@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB19WIm5BViN1hTFOP3X0xibAXoQAAYfiA References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <1176914005.17141.151.camel@montag.eng.level3.com> <4626493F.6030805@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" , "Daryl Malas" X-OriginalArrivalTime: 18 Apr 2007 16:48:57.0929 (UTC) FILETIME=[754E2390:01C781D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7833; t=1176914978; x=1177778978; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20, =0A=20= 20=20=20=20=20=20=20=22Daryl=20Malas=22=20; bh=0WejdKJX4Kl6GReUqLlY16Zof37zYbfI4vg8IhQ0zOI=; b=yI3HTD4jwBUcx0sEraMeCf1N1YgyBFQXfoweOeJsLmUOI0lQ6PKdz+d4N8QAXyhhcqhOQSdu 8GnyPHPdcLfK3boUaQ2kFmtD437NETE2Gk5Ggc0O1QL83S9UZMGyJYHd; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Filters are only as good as the information upon which to filter. Garbage in, garbage out. Mike > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Wednesday, April 18, 2007 12:37 PM > To: Daryl Malas > Cc: Michael Hammer (mhammer); Stastny Richard; Otmar Lendl;=20 > speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Daryl Malas wrote: > > I saw earlier the comment that an end-user wouldn't want to change=20 > > SP's just to change the level of filtering (if I recall=20 > correctly). I=20 > > find this interesting considering most open-email providers (e.g.=20 > > Yahoo, Google, AOL, etc.) provide, on behalf of, their subscribers=20 > > spam filtering. If you don't like Google's spam filter, you can=20 > > either shut it off completely (in comes the garbage) or go=20 > to Yahoo, for example. > > Isn't this exactly the situation you were suggesting would=20 > be bad in=20 > > VoIP environments? Isn't this the example correlation you=20 > are making=20 > > regarding the email world? >=20 > Its not analogous, because you *can* shut the filtering off.=20 > Then you can implement your own filter using your own rules. >=20 > It seems that for SIP peering as being discussed you won't=20 > have any option to turn it off. >=20 > Ideally there would be some simple rule-based filters that could be > *optionally* enabled for the target account to minimize the=20 > traffic that gets sent all the way to the phone. >=20 > > BTW, if an email arrives a little late to a end-user, due to a spam=20 > > blast on an email server, then no on really cares that much. They=20 > > just think, "Oh well...the internet is slow again." If=20 > someone child=20 > > is getting a "fast busy" trying to call home, because=20 > someone is "spamming" > > their home phone....how do you think that will fly? >=20 > As I mentioned, I don't object to a SP blocking a DoS attack.=20 > (As long as it is careful how that is defined.) I realize=20 > that is in some sense a spam filter, but it seems=20 > qualitatively different to me. >=20 > Paul >=20 > > --Daryl > >=20 > > On Wed, 2007-04-18 at 10:05 -0400, Michael Hammer (mhammer) wrote: > >> Richard, > >> > >> What happens when one end-user wants to receive from anywhere, and=20 > >> everyone else doesn't want unsolicited garbage? > >> > >> Do you connect with known garbage spewing networks? > >> > >> The carrier has a responsibility to act in the interests=20 > of all the=20 > >> users. > >> > >> Mike > >> > >> > >>> -----Original Message----- > >>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >>> Sent: Wednesday, April 18, 2007 3:41 AM > >>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > >>> Subject: RE: [Speermint] Re-making or Un-making the PSTN > >>> > >>> Paul wrote > >>>> The SP ought to be the agent for the end user's policies of > >>> whether to > >>>> restrict the sources or destinations of calls. > >>>> > >>>> It may be that better guarantees of service can be given > >>> when there is > >>> a > >>>> peering agreement between source and destination. But it > >>> seems absurd > >>> to > >>>> enforce that the only alternative is no service at all. > >>> This is what I always said and what is always forgotten in the > >>> discussion: The service provider is acting as an agent of the=20 > >>> end-user. If an end-user wants to accept calls from anywhere > >>> - fine If the end-user only accepts calls with proper=20 > identification=20 > >>> - fine > >>> > >>> But this can only be evaluated after the service provider accepts=20 > >>> the INVITE and looks up the profile of the requested user. > >>> > >>> Richard > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Tuesday, April 17, 2007 5:31 PM > >>>> To: Otmar Lendl; speermint@ietf.org > >>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >>>> > >>>> > >>>> > >>>> Otmar Lendl wrote: > >>>>> On 2007/04/13 22:04, "Uzelac, Adam"=20 > >>> > >>>> wrote: > >>>>>> As I sit here working on the VoIP use-case draft, I > >>> can't help but > >>>>>> thinking if we aren't just re-making the PSTN, instead > >>> of un-making > >>> it. > >>>>>> The crux of this issue lies with the routing. At some > >>> of the basic > >>>>>> constructs of next-hop routing decisions that border > >>> elements need > >>> to > >>>>>> do, these use-cases are starting to smell more and more like > >>> PSTN-based > >>>>>> routing look-ups. > >>>>> Not just PSTN routing. IP routing is another example. > >>>>> > >>>>> The source is IMHO the following: > >>>>> > >>>>> * With the email-model, no multihop L7 routing is needed:=20 > >>> The source > >>>>> contacts the destination directly and relies on the > >>> underlying IP > >>>>> network to do the heavy lifting in terms of routing. > >>>>> > >>>>> * The email model has been (mostly) rejected by the real life > >>>>> VoIP deployments. The reason seems to be that most carriers > >>>>> simply will not accept incoming SIP calls from the wide open > >>>>> Internet. > >>>> IMO this needs to change. Maybe it will take legislation, > >>> or maybe the > >>>> free market will fix it (if we ever get a free market), but it=20 > >>>> needs > >>> to > >>>> change. The SP ought to be the agent for the end user's=20 > policies of=20 > >>>> whether to restrict the sources or destinations of calls. > >>>> > >>>> It may be that better guarantees of service can be given > >>> when there is > >>> a > >>>> peering agreement between source and destination. But it > >>> seems absurd > >>> to > >>>> enforce that the only alternative is no service at all. > >>>> > >>>> So it seems to me that the purpose of the peering > >>> agreements ought to > >>> be > >>>> to assist in obtaining the degree of service that the=20 > caller is and=20 > >>>> callee desire, or coming as close as possible. > >>>> > >>>> Paul > >>>> > >>>>> The rest follows: > >>>>> > >>>>> A source network cannot be sure that the destination=20 > network will=20 > >>>>> accept INVITES it sends via the Internet. > >>>>> > >>>>> It thus needs to employ the help of "transit" services. > >>>>> > >>>>> Once there are competing operators who offer transit=20 > services, the > >>> set > >>>>> of carriers and their links form a text-book example of a > >>> graph. Go > >>>>> to any Networking 101 class to learn about solutions to > >>> such an old > >>>>> fashioned routing problem. > >>>>> > >>>>> ---- > >>>>> > >>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can > >>> agree to > >>>>> directly accept calls from all VoIP operators (regardless > >>> of country > >>> of > >>>>> origin), and thus implicitly also from other operators=20 > with which > >>> they > >>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the > >>> routing > >>>>> problem. > >>>>> > >>>>> I consider this to be pretty unlikely. > >>>>> > >>>>> I've written up a draft on this topic which will be > >>> submitted to the > >>>>> archives soon. > >>>>> > >>>>> /ol > >>>> _______________________________________________ > >>>> Speermint mailing list > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > >>> _______________________________________________ > >>> Speermint mailing list > >>> Speermint@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/speermint > >>> > >> _______________________________________________ > >> Speermint mailing list > >> Speermint@ietf.org > >> https://www1.ietf.org/mailman/listinfo/speermint > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:57: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 1HeDT6-00046A-2O; Wed, 18 Apr 2007 12:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSt-0003ae-5V for speermint@ietf.org; Wed, 18 Apr 2007 12:57:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDHT-0008Oc-SW for speermint@ietf.org; Wed, 18 Apr 2007 12:45:22 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2007 12:45:20 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="57974118:sNHT72372108" 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 l3IGjJOD022591; Wed, 18 Apr 2007 12:45:19 -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 l3IGjAlQ005621; Wed, 18 Apr 2007 16:45:19 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:45:14 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 12:45:09 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75A63@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <4626462F.5030104@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB1gK8G14TZFK/RnSGV1dcAUhTwwAAslgg References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <46263C7D.7040708@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A24@xmb-rtp-20b.amer.cisco.com> <4626462F.5030104@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 18 Apr 2007 16:45:14.0132 (UTC) FILETIME=[EFE96D40:01C781D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7748; t=1176914719; x=1177778719; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=wWVZdnoBG9h2k4Bl8JGC5CUu2IM5jo1yX4t/As4QH24=; b=b4QlrFUYiElNDSknNb9WhxjQO8QHM+xb4g2CsUUMUdu/fuvaP4xw+FzTgO/H7lBYIez+CivK ioRtJwNzQ0E7gqrwtmd/GlFbysP3Ph7CH5ByibV23s2rcOFg9TEUU0XC; Authentication-Results: rtp-dkim-1; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I hope that the IETF defines mechanisms such that they are not deemed "unusual". Mike =20 > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Wednesday, April 18, 2007 12:24 PM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > Michael Hammer (mhammer) wrote: > > Paul, > >=20 > > Yes. I am hoping that service providers can agree on some set of=20 > > operating rules/practices that enable the finer grain=20 > control to happen. > > The problem comes if a particular SP doesn't want to=20 > operate with any=20 > > degree of civility. >=20 > I may or may not agree with you depending on exactly what you mean. >=20 > If one SP mounts a DoS attack on another then it makes sense=20 > to blacklist it. But if it simply doesn't provide some=20 > unusual sort of identity information, or doesn't support=20 > settlement, then I think it should be the option for the=20 > target user to make the decision. >=20 > Paul >=20 > > The high level goal for me is that the PSTN has a certain level of=20 > > trust and moving to a level of trust as problematic as that=20 > of email=20 > > seems like a step in the wrong direction. > >=20 > > Mike > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Wednesday, April 18, 2007 11:43 AM > >> To: Michael Hammer (mhammer) > >> Cc: Stastny Richard; Otmar Lendl; speermint@ietf.org > >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >> > >> > >> > >> Michael Hammer (mhammer) wrote: > >>> Richard, > >>> > >>> What happens when one end-user wants to receive from=20 > anywhere, and=20 > >>> everyone else doesn't want unsolicited garbage? > >>> > >>> Do you connect with known garbage spewing networks? > >>> > >>> The carrier has a responsibility to act in the interests=20 > of all the=20 > >>> users. > >> It would be quite reasonable for the provider to have an optional=20 > >> (perhaps default) filter policy that rejects calls from untrusted=20 > >> sources (with trust defined by the SP). Its just that this=20 > needs to=20 > >> be applied on a per target basis rather than on a per-SP basis. > >> > >> Admittedly if the SP has 10m subscribers and only one of=20 > them wants=20 > >> this then they probably won't be incented to do it. But I=20 > think there=20 > >> will be more than that who want it. > >> > >> Paul > >> > >> > >>> Mike > >>> > >>> > >>>> -----Original Message----- > >>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >>>> Sent: Wednesday, April 18, 2007 3:41 AM > >>>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > >>>> Subject: RE: [Speermint] Re-making or Un-making the PSTN > >>>> > >>>> Paul wrote > >>>>> The SP ought to be the agent for the end user's policies of > >>>> whether to > >>>>> restrict the sources or destinations of calls. > >>>>> > >>>>> It may be that better guarantees of service can be given > >>>> when there is > >>>> a > >>>>> peering agreement between source and destination. But it > >>>> seems absurd > >>>> to > >>>>> enforce that the only alternative is no service at all. > >>>> This is what I always said and what is always forgotten in the > >>>> discussion: The service provider is acting as an agent of the=20 > >>>> end-user. If an end-user wants to accept calls from anywhere > >>>> - fine If the end-user only accepts calls with proper > >> identification > >>>> - fine > >>>> > >>>> But this can only be evaluated after the service provider > >> accepts the > >>>> INVITE and looks up the profile of the requested user. > >>>> > >>>> Richard > >>>> > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>> Sent: Tuesday, April 17, 2007 5:31 PM > >>>>> To: Otmar Lendl; speermint@ietf.org > >>>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >>>>> > >>>>> > >>>>> > >>>>> Otmar Lendl wrote: > >>>>>> On 2007/04/13 22:04, "Uzelac, Adam"=20 > >>>> > >>>>> wrote: > >>>>>>> As I sit here working on the VoIP use-case draft, I > >>>> can't help but > >>>>>>> thinking if we aren't just re-making the PSTN, instead > >>>> of un-making > >>>> it. > >>>>>>> The crux of this issue lies with the routing. At some > >>>> of the basic > >>>>>>> constructs of next-hop routing decisions that border > >>>> elements need > >>>> to > >>>>>>> do, these use-cases are starting to smell more and more like > >>>> PSTN-based > >>>>>>> routing look-ups. > >>>>>> Not just PSTN routing. IP routing is another example. > >>>>>> > >>>>>> The source is IMHO the following: > >>>>>> > >>>>>> * With the email-model, no multihop L7 routing is needed:=20 > >>>> The source > >>>>>> contacts the destination directly and relies on the > >>>> underlying IP > >>>>>> network to do the heavy lifting in terms of routing. > >>>>>> > >>>>>> * The email model has been (mostly) rejected by the real life > >>>>>> VoIP deployments. The reason seems to be that most carriers > >>>>>> simply will not accept incoming SIP calls from the wide open > >>>>>> Internet. > >>>>> IMO this needs to change. Maybe it will take legislation, > >>>> or maybe the > >>>>> free market will fix it (if we ever get a free market), > >> but it needs > >>>> to > >>>>> change. The SP ought to be the agent for the end user's > >> policies of > >>>>> whether to restrict the sources or destinations of calls. > >>>>> > >>>>> It may be that better guarantees of service can be given > >>>> when there is > >>>> a > >>>>> peering agreement between source and destination. But it > >>>> seems absurd > >>>> to > >>>>> enforce that the only alternative is no service at all. > >>>>> > >>>>> So it seems to me that the purpose of the peering > >>>> agreements ought to > >>>> be > >>>>> to assist in obtaining the degree of service that the > >> caller is and > >>>>> callee desire, or coming as close as possible. > >>>>> > >>>>> Paul > >>>>> > >>>>>> The rest follows: > >>>>>> > >>>>>> A source network cannot be sure that the destination > >> network will > >>>>>> accept INVITES it sends via the Internet. > >>>>>> > >>>>>> It thus needs to employ the help of "transit" services. > >>>>>> > >>>>>> Once there are competing operators who offer transit > >> services, the > >>>> set > >>>>>> of carriers and their links form a text-book example of a > >>>> graph. Go > >>>>>> to any Networking 101 class to learn about solutions to > >>>> such an old > >>>>>> fashioned routing problem. > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can > >>>> agree to > >>>>>> directly accept calls from all VoIP operators (regardless > >>>> of country > >>>> of > >>>>>> origin), and thus implicitly also from other operators=20 > with which > >>>> they > >>>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the > >>>> routing > >>>>>> problem. > >>>>>> > >>>>>> I consider this to be pretty unlikely. > >>>>>> > >>>>>> I've written up a draft on this topic which will be > >>>> submitted to the > >>>>>> archives soon. > >>>>>> > >>>>>> /ol > >>>>> _______________________________________________ > >>>>> Speermint mailing list > >>>>> Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>> _______________________________________________ > >>>> Speermint mailing list > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>> > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:57: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 1HeDT9-0004Ca-7w; Wed, 18 Apr 2007 12:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDT3-0003qz-9W for speermint@ietf.org; Wed, 18 Apr 2007 12:57:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDET-0007fM-8Q for speermint@ietf.org; Wed, 18 Apr 2007 12:42:14 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2007 09:42:12 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="370492780:sNHT49041404" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3IGgBnX012394; Wed, 18 Apr 2007 12:42:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IGfrHD016615; Wed, 18 Apr 2007 16:42:11 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:41:52 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 12:41:38 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75A5F@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <46264492.4010109@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB1Qw3QmZBQzdNTh6UGJxvkybBvgAAqaBQ References: <4624E824.7010407@cisco.com><32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> <46264492.4010109@cisco.com> From: "Michael Hammer \(mhammer\)" To: "Paul Kyzivat \(pkyzivat\)" X-OriginalArrivalTime: 18 Apr 2007 16:41:52.0867 (UTC) FILETIME=[77F2D330:01C781D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=907; t=1176914531; x=1177778531; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Paul=20Kyzivat=20\(pkyzivat\)=22=20; bh=kgC5L+muuf1GeEKDcIi/VmUyJMM+u2hPUAChu345SYk=; b=nI/3/D3u+PAdUH3K4N+wfuX2cWHTxJuGaY95FfavnQxvsq48OMhvTkzNqjUC4ad3cHDG7EDk /7ohtG865ntmABv73Do4+mi9gr71dU60p/TfrvtA7AS6Yq/oCxAGxF+s; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat (pkyzivat)=20 > Sent: Wednesday, April 18, 2007 12:17 PM > To: Michael Hammer (mhammer) > Cc: Uzelac, Adam; Stastny Richard; Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN [snip] =20 > Also, what about the flip side of this. Is the SP "protecting=20 > the customers" by preventing them from calling a destination=20 > when it has no service agreement with that destination? >=20 > Paul I would hope not. But, the route to get there may require some common middleman carrier who has a relationship with both the originating and terminating networks. This raises an interesting question though, as to the symmetricity of the direction of calls allowed and how such an SP intermediates. Also, are you assuming some form of regulation that requires SPs to interconnect? :) Mike _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 12:59: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 1HeDSo-0003bV-T1; Wed, 18 Apr 2007 12:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSk-0003Wt-1r for speermint@ietf.org; Wed, 18 Apr 2007 12:56:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDQe-0001zg-Mv for speermint@ietf.org; Wed, 18 Apr 2007 12:54:49 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2007 12:54:48 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="57974599:sNHT48297604" 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 l3IGsm2W026986; Wed, 18 Apr 2007 12:54:48 -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 l3IGsglY008248; Wed, 18 Apr 2007 16:54:48 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); Wed, 18 Apr 2007 12:54:25 -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); Wed, 18 Apr 2007 12:54:24 -0400 Message-ID: <46264D40.4010706@cisco.com> Date: Wed, 18 Apr 2007 12:54:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com><32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> <46264492.4010109@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A5F@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302E75A5F@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 16:54:24.0693 (UTC) FILETIME=[38125E50:01C781DA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1374; t=1176915288; x=1177779288; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Michael=20Hammer=20(mhammer)=22=20; bh=h8YEW9HctrmgfftlLFnMr/zZ8nYn16LyIliGjjyb95Y=; b=PAFk0cOsGIDtD2oBP18dyAQe7HmO1bsRNDCmKxtIQYbaLtLU5ysXgYBufES9XiUx+9noqwC6 4B3Mu3x08BRCBh66kV87eLVKXXx+E3Jr1ClRZC/v+UfFKdqDrnalCAJz; 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > > >> -----Original Message----- >> From: Paul Kyzivat (pkyzivat) >> Sent: Wednesday, April 18, 2007 12:17 PM >> To: Michael Hammer (mhammer) >> Cc: Uzelac, Adam; Stastny Richard; Otmar Lendl; speermint@ietf.org >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > > [snip] > >> Also, what about the flip side of this. Is the SP "protecting >> the customers" by preventing them from calling a destination >> when it has no service agreement with that destination? >> >> Paul > > I would hope not. But, the route to get there may require some common > middleman carrier who has a relationship with both the originating and > terminating networks. This raises an interesting question though, as to > the symmetricity of the direction of calls allowed and how such an SP > intermediates. Yes. Asymetric calling would get lots of complaints. ("What do you mean I can't call back?") > Also, are you assuming some form of regulation that requires SPs to > interconnect? :) I'm not assuming anything. Whatever it takes. Ideally this would happen via the open market, but that currently appears unlikely. Regulation is a possibility, though in the current climate (in the USA anyway) it seems unlikely to happen. This seems somewhat analogous to the Carterphone ruling. Paul _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 13:00: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 1HeDWC-0005OR-IW; Wed, 18 Apr 2007 13:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDT2-0003bQ-Kl for speermint@ietf.org; Wed, 18 Apr 2007 12:57:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDEz-0007iL-5v for speermint@ietf.org; Wed, 18 Apr 2007 12:42:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 18 Apr 2007 09:42:44 -0700 X-IronPort-AV: i="4.14,423,1170662400"; d="scan'208"; a="137331113:sNHT57179772" 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 l3IGghb9012562; Wed, 18 Apr 2007 12:42:43 -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 l3IGgdlI004820; Wed, 18 Apr 2007 16:42:43 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); Wed, 18 Apr 2007 12:42:38 -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); Wed, 18 Apr 2007 12:42:37 -0400 Message-ID: <46264A7D.4000804@cisco.com> Date: Wed, 18 Apr 2007 12:42:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Daryl Malas Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> <46264492.4010109@cisco.com> <1176914484.17141.161.camel@montag.eng.level3.com> In-Reply-To: <1176914484.17141.161.camel@montag.eng.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 16:42:37.0874 (UTC) FILETIME=[92C65920:01C781D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1114; t=1176914563; x=1177778563; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20Daryl=20Malas=20; bh=ENwPfNuJ3VFOLMUJoGINouVlF0M8oKC/S6S7s5rrzyk=; b=b2zo+FWme1tfqK00yf67Wc7CyNAHLU16dBn819vxfMOUg8XCL8lxMgxFFsQ2a4LPZXHC+x4n 1b60ZFE03SJAgm8L7yfRacpoQToplWryR1r3BzdA9w0JlQ2Swje43KUt; 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl , "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl Malas wrote: >> Also, what about the flip side of this. Is the SP "protecting the >> customers" by preventing them from calling a destination when it has no >> service agreement with that destination? >> > FYi...The PSTN does this today...carriers block their customers from > calling some NPA's that have a bad reputation for seriously ripping off > customers of 100's of dollars. I would believe this would continue to > occur whether it's IP or not. That is only relevant because of settlement agreements that allow the callee to impose a bill on the caller. As has been mentioned elsewhere, opening up to calling or being called by anybody means that, at least in cases where there is no peering agreement there can be no settlement, and so no financial risk to the caller if the call is allowed. So all that would be needed is to refuse to establish a settlement agreement with those "evil" carriers. In cases where there is a peering agreement there could still be settlement. Presumably this would be for value added, such as guaranteed bandwidth. Paul _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 13:02: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 1HeDYY-0000ZK-ED; Wed, 18 Apr 2007 13:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDYW-0000ZA-WA for speermint@ietf.org; Wed, 18 Apr 2007 13:02:57 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDYW-0004hs-GB for speermint@ietf.org; Wed, 18 Apr 2007 13:02:56 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l3IH2qoK017164; Wed, 18 Apr 2007 17:02:52 GMT Subject: Re: [Speermint] Re-making or Un-making the PSTN From: Daryl Malas To: Paul Kyzivat In-Reply-To: <46264DB3.30101@cisco.com> References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <1176914005.17141.151.camel@montag.eng.level3.com> <4626493F.6030805@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A6A@xmb-rtp-20b.amer.cisco.com> <46264DB3.30101@cisco.com> Content-Type: text/plain Date: Wed, 18 Apr 2007 11:16:14 -0600 Message-Id: <1176916574.17141.166.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org So, you are saying the carrier would insert into the PAI header or From field a calling name of "Unknown Caller" or similar? Wow...I can think of a lot of ways very valid calls get tagged with something like this in the PSTN's CNAM methodology. Do we think we would be able to improve on these databases with IP? (That's not sarcastic...I'm actually asking the questions genuinely.) On Wed, 2007-04-18 at 12:56 -0400, Paul Kyzivat wrote: > > Michael Hammer (mhammer) wrote: > > Filters are only as good as the information upon which to filter. > > > > Garbage in, garbage out. > > The carrier should be free to tag the message with contextual info, such > as that this is from an unknown and untrusted source, and the filter can > choose to act based on that. > > Paul > > > Mike > > > > > >> -----Original Message----- > >> From: Paul Kyzivat (pkyzivat) > >> Sent: Wednesday, April 18, 2007 12:37 PM > >> To: Daryl Malas > >> Cc: Michael Hammer (mhammer); Stastny Richard; Otmar Lendl; > >> speermint@ietf.org > >> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >> > >> > >> > >> Daryl Malas wrote: > >>> I saw earlier the comment that an end-user wouldn't want to change > >>> SP's just to change the level of filtering (if I recall > >> correctly). I > >>> find this interesting considering most open-email providers (e.g. > >>> Yahoo, Google, AOL, etc.) provide, on behalf of, their subscribers > >>> spam filtering. If you don't like Google's spam filter, you can > >>> either shut it off completely (in comes the garbage) or go > >> to Yahoo, for example. > >>> Isn't this exactly the situation you were suggesting would > >> be bad in > >>> VoIP environments? Isn't this the example correlation you > >> are making > >>> regarding the email world? > >> Its not analogous, because you *can* shut the filtering off. > >> Then you can implement your own filter using your own rules. > >> > >> It seems that for SIP peering as being discussed you won't > >> have any option to turn it off. > >> > >> Ideally there would be some simple rule-based filters that could be > >> *optionally* enabled for the target account to minimize the > >> traffic that gets sent all the way to the phone. > >> > >>> BTW, if an email arrives a little late to a end-user, due to a spam > >>> blast on an email server, then no on really cares that much. They > >>> just think, "Oh well...the internet is slow again." If > >> someone child > >>> is getting a "fast busy" trying to call home, because > >> someone is "spamming" > >>> their home phone....how do you think that will fly? > >> As I mentioned, I don't object to a SP blocking a DoS attack. > >> (As long as it is careful how that is defined.) I realize > >> that is in some sense a spam filter, but it seems > >> qualitatively different to me. > >> > >> Paul > >> > >>> --Daryl > >>> > >>> On Wed, 2007-04-18 at 10:05 -0400, Michael Hammer (mhammer) wrote: > >>>> Richard, > >>>> > >>>> What happens when one end-user wants to receive from anywhere, and > >>>> everyone else doesn't want unsolicited garbage? > >>>> > >>>> Do you connect with known garbage spewing networks? > >>>> > >>>> The carrier has a responsibility to act in the interests > >> of all the > >>>> users. > >>>> > >>>> Mike > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >>>>> Sent: Wednesday, April 18, 2007 3:41 AM > >>>>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org > >>>>> Subject: RE: [Speermint] Re-making or Un-making the PSTN > >>>>> > >>>>> Paul wrote > >>>>>> The SP ought to be the agent for the end user's policies of > >>>>> whether to > >>>>>> restrict the sources or destinations of calls. > >>>>>> > >>>>>> It may be that better guarantees of service can be given > >>>>> when there is > >>>>> a > >>>>>> peering agreement between source and destination. But it > >>>>> seems absurd > >>>>> to > >>>>>> enforce that the only alternative is no service at all. > >>>>> This is what I always said and what is always forgotten in the > >>>>> discussion: The service provider is acting as an agent of the > >>>>> end-user. If an end-user wants to accept calls from anywhere > >>>>> - fine If the end-user only accepts calls with proper > >> identification > >>>>> - fine > >>>>> > >>>>> But this can only be evaluated after the service provider accepts > >>>>> the INVITE and looks up the profile of the requested user. > >>>>> > >>>>> Richard > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: Tuesday, April 17, 2007 5:31 PM > >>>>>> To: Otmar Lendl; speermint@ietf.org > >>>>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN > >>>>>> > >>>>>> > >>>>>> > >>>>>> Otmar Lendl wrote: > >>>>>>> On 2007/04/13 22:04, "Uzelac, Adam" > >>>>> > >>>>>> wrote: > >>>>>>>> As I sit here working on the VoIP use-case draft, I > >>>>> can't help but > >>>>>>>> thinking if we aren't just re-making the PSTN, instead > >>>>> of un-making > >>>>> it. > >>>>>>>> The crux of this issue lies with the routing. At some > >>>>> of the basic > >>>>>>>> constructs of next-hop routing decisions that border > >>>>> elements need > >>>>> to > >>>>>>>> do, these use-cases are starting to smell more and more like > >>>>> PSTN-based > >>>>>>>> routing look-ups. > >>>>>>> Not just PSTN routing. IP routing is another example. > >>>>>>> > >>>>>>> The source is IMHO the following: > >>>>>>> > >>>>>>> * With the email-model, no multihop L7 routing is needed: > >>>>> The source > >>>>>>> contacts the destination directly and relies on the > >>>>> underlying IP > >>>>>>> network to do the heavy lifting in terms of routing. > >>>>>>> > >>>>>>> * The email model has been (mostly) rejected by the real life > >>>>>>> VoIP deployments. The reason seems to be that most carriers > >>>>>>> simply will not accept incoming SIP calls from the wide open > >>>>>>> Internet. > >>>>>> IMO this needs to change. Maybe it will take legislation, > >>>>> or maybe the > >>>>>> free market will fix it (if we ever get a free market), but it > >>>>>> needs > >>>>> to > >>>>>> change. The SP ought to be the agent for the end user's > >> policies of > >>>>>> whether to restrict the sources or destinations of calls. > >>>>>> > >>>>>> It may be that better guarantees of service can be given > >>>>> when there is > >>>>> a > >>>>>> peering agreement between source and destination. But it > >>>>> seems absurd > >>>>> to > >>>>>> enforce that the only alternative is no service at all. > >>>>>> > >>>>>> So it seems to me that the purpose of the peering > >>>>> agreements ought to > >>>>> be > >>>>>> to assist in obtaining the degree of service that the > >> caller is and > >>>>>> callee desire, or coming as close as possible. > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>>> The rest follows: > >>>>>>> > >>>>>>> A source network cannot be sure that the destination > >> network will > >>>>>>> accept INVITES it sends via the Internet. > >>>>>>> > >>>>>>> It thus needs to employ the help of "transit" services. > >>>>>>> > >>>>>>> Once there are competing operators who offer transit > >> services, the > >>>>> set > >>>>>>> of carriers and their links form a text-book example of a > >>>>> graph. Go > >>>>>>> to any Networking 101 class to learn about solutions to > >>>>> such an old > >>>>>>> fashioned routing problem. > >>>>>>> > >>>>>>> ---- > >>>>>>> > >>>>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can > >>>>> agree to > >>>>>>> directly accept calls from all VoIP operators (regardless > >>>>> of country > >>>>> of > >>>>>>> origin), and thus implicitly also from other operators > >> with which > >>>>> they > >>>>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the > >>>>> routing > >>>>>>> problem. > >>>>>>> > >>>>>>> I consider this to be pretty unlikely. > >>>>>>> > >>>>>>> I've written up a draft on this topic which will be > >>>>> submitted to the > >>>>>>> archives soon. > >>>>>>> > >>>>>>> /ol > >>>>>> _______________________________________________ > >>>>>> Speermint mailing list > >>>>>> Speermint@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>>> _______________________________________________ > >>>>> Speermint mailing list > >>>>> Speermint@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/speermint > >>>>> > >>>> _______________________________________________ > >>>> Speermint mailing list > >>>> Speermint@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 13: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 1HeDbx-00040y-0E; Wed, 18 Apr 2007 13:06:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDbv-0003uO-Vv for speermint@ietf.org; Wed, 18 Apr 2007 13:06:27 -0400 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDbu-0005Et-Ld for speermint@ietf.org; Wed, 18 Apr 2007 13:06:27 -0400 Received: from montag.eng.level3.com (montag.eng.l3.com [10.1.68.57]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id l3IH5uoK017795; Wed, 18 Apr 2007 17:05:57 GMT Subject: RE: [Speermint] Re-making or Un-making the PSTN From: Daryl Malas To: "Uzelac, Adam" In-Reply-To: References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com> <20070417155431.GA30254@nic.at> <072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com> <4624FB8F.7040408@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> <1176914313.17141.157.camel@montag.eng.level3.com> Content-Type: text/plain Date: Wed, 18 Apr 2007 11:19:18 -0600 Message-Id: <1176916759.17141.169.camel@montag.eng.level3.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I want to respond to this carefully, because my knee jerk reaction is to say, "No. I wasn't trying to say we are re-making the PSTN." However, I think aspects of the PSTN will be inherently added to the peering architecture. I'll provide a more thought out answer later when I have more time. --Daryl On Wed, 2007-04-18 at 12:52 -0400, Uzelac, Adam wrote: > I read this as a vote that the Speermint activities are a re-making, > possibly with added stuff, but a re-making nonetheless, of the PSTN - > versus un-making. Did I read this incorrectly? > > Adam > > > -----Original Message----- > > From: Daryl Malas [mailto:daryl@level3.net] > > Sent: Wednesday, April 18, 2007 12:39 PM > > To: Michael Hammer (mhammer) > > Cc: speermint@ietf.org; Otmar Lendl > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > > > IMO, I think the PSTN becoming IP-enabled is far more likely > > than the PSTN becoming an extension of the Internet. What I > > think we are doing here is adding capabilities, which can > > exist in an IP world that the TDM-PSTN cannot or would not > > want to adopt if it even wanted to. I think this is what we > > are trying to do. Sure we might dabble with open end-to-end > > (e.g. P2P, etc.), stuff, but I believe the IP-PSTN (;-)) will > > exist in a highly regulated walled off arena for quite some > > time. Many efficiencies and capabilities can be made to make > > it much better by the work we are doing though, in the mean time. > > > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 13:45: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 1HeEDq-0006f8-7U; Wed, 18 Apr 2007 13:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEDp-0006f3-RH for speermint@ietf.org; Wed, 18 Apr 2007 13:45:37 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEDn-0005kV-Fz for speermint@ietf.org; Wed, 18 Apr 2007 13:45:37 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 729764D1CE; Wed, 18 Apr 2007 19:45:34 +0200 (CEST) Date: Wed, 18 Apr 2007 19:45:34 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070418174533.GA28553@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com> <46264492.4010109@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A5F@xmb-rtp-20b.amer.cisco.com> <46264D40.4010706@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46264D40.4010706@cisco.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/18 18:04, Paul Kyzivat wrote: > Michael Hammer (mhammer) wrote: > > >Also, are you assuming some form of regulation that requires SPs to > >interconnect? :) > > I'm not assuming anything. Whatever it takes. Ideally this would happen > via the open market, but that currently appears unlikely. Regulation is > a possibility, though in the current climate (in the USA anyway) it > seems unlikely to happen. fyi, the Austrian regulator requires that all (normal) Austrian numbers must be reachable from all Austrian carriers. They usually don't interfere how the carriers arrange this (except some financial matters plus obligations put on the incumbent). /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 14:42: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 1HeF6q-00006x-Md; Wed, 18 Apr 2007 14:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeF6p-0008VK-8X for speermint@ietf.org; Wed, 18 Apr 2007 14:42:27 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeF6n-0001oa-R6 for speermint@ietf.org; Wed, 18 Apr 2007 14:42:27 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l3IIffnT025609; Wed, 18 Apr 2007 11:41:49 -0700 From: "Richard Shockey" To: "'Uzelac, Adam'" , "'Daryl Malas'" , "'Michael Hammer \(mhammer\)'" References: <20070417150930.GA29145@nic.at> <4624E824.7010407@cisco.com><20070417155431.GA30254@nic.at><072C5B76F7CEAB488172C6F64B30B5E302E12EB8@xmb-rtp-20b.amer.cisco.com><4624FB8F.7040408@cisco.com><072C5B76F7CEAB488172C6F64B30B5E302E12EFE@xmb-rtp-20b.amer.cisco.com> <1176914313.17141.157.camel@montag.eng.level3.com> In-Reply-To: Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 14:35:06 -0400 Message-ID: <01f101c781e8$4c6917a0$e53b46e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceB1ioeP5CYOk4dQpWfRuQegZ3pAwAA4V7AAANlIBA= Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: speermint@ietf.org, 'Otmar Lendl' X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org You might think that but just a reminder from the charter. "The most focused deliverables of SPEERMINT are best current practices regarding exchange of real-time sessions among VoIP and other real-time application service providers and, in particular, how such calls are routed." I love a good discussion as much as the next person but I'm not sure of our competency to deal with Layer 8-10 issues. Remember SPIT issues are specifically NOT part of the WG charter. Something interesting would be what are the minimum authentication and authorization techniques necessary for SIP service provider A to trust, route and terminate SIP traffic from Service Provider B. Something we tried to do in SIPConnect BTW. -----Original Message----- From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] Sent: Wednesday, April 18, 2007 12:53 PM To: Daryl Malas; Michael Hammer (mhammer) Cc: speermint@ietf.org; Otmar Lendl Subject: RE: [Speermint] Re-making or Un-making the PSTN I read this as a vote that the Speermint activities are a re-making, possibly with added stuff, but a re-making nonetheless, of the PSTN - versus un-making. Did I read this incorrectly? Adam > -----Original Message----- > From: Daryl Malas [mailto:daryl@level3.net] > Sent: Wednesday, April 18, 2007 12:39 PM > To: Michael Hammer (mhammer) > Cc: speermint@ietf.org; Otmar Lendl > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > IMO, I think the PSTN becoming IP-enabled is far more likely > than the PSTN becoming an extension of the Internet. What I > think we are doing here is adding capabilities, which can > exist in an IP world that the TDM-PSTN cannot or would not > want to adopt if it even wanted to. I think this is what we > are trying to do. Sure we might dabble with open end-to-end > (e.g. P2P, etc.), stuff, but I believe the IP-PSTN (;-)) will > exist in a highly regulated walled off arena for quite some > time. Many efficiencies and capabilities can be made to make > it much better by the work we are doing though, in the mean time. > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 15:25: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 1HeFmm-0006yM-7H; Wed, 18 Apr 2007 15:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFmk-0006yH-R9 for speermint@ietf.org; Wed, 18 Apr 2007 15:25:46 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFmk-0000JU-6r for speermint@ietf.org; Wed, 18 Apr 2007 15:25:46 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 15:25:47 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="118864541:sNHT68279854" 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 l3IJPkIv012972; Wed, 18 Apr 2007 15:25:46 -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 l3IJPelW004683; Wed, 18 Apr 2007 19:25:45 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); Wed, 18 Apr 2007 15:25:44 -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); Wed, 18 Apr 2007 15:25:44 -0400 Message-ID: <462670B5.8010706@cisco.com> Date: Wed, 18 Apr 2007 15:25:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Daryl Malas Subject: Re: [Speermint] Re-making or Un-making the PSTN References: <4624E824.7010407@cisco.com> <32755D354E6B65498C3BD9FD496C7D46646E0E@oefeg-s04.oefeg.loc> <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com> <1176914005.17141.151.camel@montag.eng.level3.com> <4626493F.6030805@cisco.com> <072C5B76F7CEAB488172C6F64B30B5E302E75A6A@xmb-rtp-20b.amer.cisco.com> <46264DB3.30101@cisco.com> <1176916574.17141.166.camel@montag.eng.level3.com> In-Reply-To: <1176916574.17141.166.camel@montag.eng.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2007 19:25:44.0297 (UTC) FILETIME=[5BEFFD90:01C781EF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10773; t=1176924346; x=1177788346; 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[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20Daryl=20Malas=20; bh=Yv+qLbvFv0I7CY7r+JnCvGby5uZIqO/u/gY6JaMLJDg=; b=I1dpAm+zkVd99nCBi2Ix3qT2dBt+m+qMd5YkMld6kYA6wPKAIFaWIB/JtP4mobP6kue+Jiab f5Y7ODasEB+4XIz3VzYZC5sn99/2i+PUvhMWxLa4Pgl2G5UlR8D05XMF; 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: 8d89ee9312a95de8ee48d1c94511f1bb Cc: Stastny Richard , speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Daryl Malas wrote: > So, you are saying the carrier would insert into the PAI header or From > field a calling name of "Unknown Caller" or similar? Wow...I can think > of a lot of ways very valid calls get tagged with something like this in > the PSTN's CNAM methodology. I wasn't trying to suggest anything specific. I only meant that if the SP has information that might be useful for a filter decision, it could make it available in some way to the user provided (or chosen or configured) filter. If the filter does its matching against the message then adding info to the message would be a good way to make it available. Certain attributes of the peering agreement, if any, might be useful information to provide. (With the simple presence or absence of a peering agreement being a most basic example of this.) "Reputation" information about the source (which might include having received DoS attacks from this source) might also be useful. Whether to take this info into account when filtering would then be up to the recipient or his agent running within the SP. The CNAM mechanism is only applicable for phone numbers. How it fits into this is TBD. But something else is needed when the addresses aren't phone numbers. Also, CNAM only applies to the actual caller and callee. Here info about the previous hop of the request is likely to be as, or more, important. > Do we think we would be able to improve on these databases with IP? > (That's not sarcastic...I'm actually asking the questions genuinely.) These seem largely orthogonal to me. For instance SP1 may have a peering agreement with SP2, including agreements to support transitive trust of PAI, and agreements that the sender will only include PAI when it can in fact vouch for the validity of the ID. When SP2 receives a message from SP1 it might honor the PAI if present. If SP2 receives a message over an insecure connection from a source with which it has no peering agreement, it will likely remove any PAI that is present, and add none. Or it may add an Unknown Caller PAI as you suggest. It might also add some other header with info indicating that the reputation of this source is low due to recent DoS attacks from it. Paul > On Wed, 2007-04-18 at 12:56 -0400, Paul Kyzivat wrote: >> Michael Hammer (mhammer) wrote: >>> Filters are only as good as the information upon which to filter. >>> >>> Garbage in, garbage out. >> The carrier should be free to tag the message with contextual info, such >> as that this is from an unknown and untrusted source, and the filter can >> choose to act based on that. >> >> Paul >> >>> Mike >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat (pkyzivat) >>>> Sent: Wednesday, April 18, 2007 12:37 PM >>>> To: Daryl Malas >>>> Cc: Michael Hammer (mhammer); Stastny Richard; Otmar Lendl; >>>> speermint@ietf.org >>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>>> >>>> >>>> >>>> Daryl Malas wrote: >>>>> I saw earlier the comment that an end-user wouldn't want to change >>>>> SP's just to change the level of filtering (if I recall >>>> correctly). I >>>>> find this interesting considering most open-email providers (e.g. >>>>> Yahoo, Google, AOL, etc.) provide, on behalf of, their subscribers >>>>> spam filtering. If you don't like Google's spam filter, you can >>>>> either shut it off completely (in comes the garbage) or go >>>> to Yahoo, for example. >>>>> Isn't this exactly the situation you were suggesting would >>>> be bad in >>>>> VoIP environments? Isn't this the example correlation you >>>> are making >>>>> regarding the email world? >>>> Its not analogous, because you *can* shut the filtering off. >>>> Then you can implement your own filter using your own rules. >>>> >>>> It seems that for SIP peering as being discussed you won't >>>> have any option to turn it off. >>>> >>>> Ideally there would be some simple rule-based filters that could be >>>> *optionally* enabled for the target account to minimize the >>>> traffic that gets sent all the way to the phone. >>>> >>>>> BTW, if an email arrives a little late to a end-user, due to a spam >>>>> blast on an email server, then no on really cares that much. They >>>>> just think, "Oh well...the internet is slow again." If >>>> someone child >>>>> is getting a "fast busy" trying to call home, because >>>> someone is "spamming" >>>>> their home phone....how do you think that will fly? >>>> As I mentioned, I don't object to a SP blocking a DoS attack. >>>> (As long as it is careful how that is defined.) I realize >>>> that is in some sense a spam filter, but it seems >>>> qualitatively different to me. >>>> >>>> Paul >>>> >>>>> --Daryl >>>>> >>>>> On Wed, 2007-04-18 at 10:05 -0400, Michael Hammer (mhammer) wrote: >>>>>> Richard, >>>>>> >>>>>> What happens when one end-user wants to receive from anywhere, and >>>>>> everyone else doesn't want unsolicited garbage? >>>>>> >>>>>> Do you connect with known garbage spewing networks? >>>>>> >>>>>> The carrier has a responsibility to act in the interests >>>> of all the >>>>>> users. >>>>>> >>>>>> Mike >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>>>>>> Sent: Wednesday, April 18, 2007 3:41 AM >>>>>>> To: Paul Kyzivat (pkyzivat); Otmar Lendl; speermint@ietf.org >>>>>>> Subject: RE: [Speermint] Re-making or Un-making the PSTN >>>>>>> >>>>>>> Paul wrote >>>>>>>> The SP ought to be the agent for the end user's policies of >>>>>>> whether to >>>>>>>> restrict the sources or destinations of calls. >>>>>>>> >>>>>>>> It may be that better guarantees of service can be given >>>>>>> when there is >>>>>>> a >>>>>>>> peering agreement between source and destination. But it >>>>>>> seems absurd >>>>>>> to >>>>>>>> enforce that the only alternative is no service at all. >>>>>>> This is what I always said and what is always forgotten in the >>>>>>> discussion: The service provider is acting as an agent of the >>>>>>> end-user. If an end-user wants to accept calls from anywhere >>>>>>> - fine If the end-user only accepts calls with proper >>>> identification >>>>>>> - fine >>>>>>> >>>>>>> But this can only be evaluated after the service provider accepts >>>>>>> the INVITE and looks up the profile of the requested user. >>>>>>> >>>>>>> Richard >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> Sent: Tuesday, April 17, 2007 5:31 PM >>>>>>>> To: Otmar Lendl; speermint@ietf.org >>>>>>>> Subject: Re: [Speermint] Re-making or Un-making the PSTN >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Otmar Lendl wrote: >>>>>>>>> On 2007/04/13 22:04, "Uzelac, Adam" >>>>>>> >>>>>>>> wrote: >>>>>>>>>> As I sit here working on the VoIP use-case draft, I >>>>>>> can't help but >>>>>>>>>> thinking if we aren't just re-making the PSTN, instead >>>>>>> of un-making >>>>>>> it. >>>>>>>>>> The crux of this issue lies with the routing. At some >>>>>>> of the basic >>>>>>>>>> constructs of next-hop routing decisions that border >>>>>>> elements need >>>>>>> to >>>>>>>>>> do, these use-cases are starting to smell more and more like >>>>>>> PSTN-based >>>>>>>>>> routing look-ups. >>>>>>>>> Not just PSTN routing. IP routing is another example. >>>>>>>>> >>>>>>>>> The source is IMHO the following: >>>>>>>>> >>>>>>>>> * With the email-model, no multihop L7 routing is needed: >>>>>>> The source >>>>>>>>> contacts the destination directly and relies on the >>>>>>> underlying IP >>>>>>>>> network to do the heavy lifting in terms of routing. >>>>>>>>> >>>>>>>>> * The email model has been (mostly) rejected by the real life >>>>>>>>> VoIP deployments. The reason seems to be that most carriers >>>>>>>>> simply will not accept incoming SIP calls from the wide open >>>>>>>>> Internet. >>>>>>>> IMO this needs to change. Maybe it will take legislation, >>>>>>> or maybe the >>>>>>>> free market will fix it (if we ever get a free market), but it >>>>>>>> needs >>>>>>> to >>>>>>>> change. The SP ought to be the agent for the end user's >>>> policies of >>>>>>>> whether to restrict the sources or destinations of calls. >>>>>>>> >>>>>>>> It may be that better guarantees of service can be given >>>>>>> when there is >>>>>>> a >>>>>>>> peering agreement between source and destination. But it >>>>>>> seems absurd >>>>>>> to >>>>>>>> enforce that the only alternative is no service at all. >>>>>>>> >>>>>>>> So it seems to me that the purpose of the peering >>>>>>> agreements ought to >>>>>>> be >>>>>>>> to assist in obtaining the degree of service that the >>>> caller is and >>>>>>>> callee desire, or coming as close as possible. >>>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>>> The rest follows: >>>>>>>>> >>>>>>>>> A source network cannot be sure that the destination >>>> network will >>>>>>>>> accept INVITES it sends via the Internet. >>>>>>>>> >>>>>>>>> It thus needs to employ the help of "transit" services. >>>>>>>>> >>>>>>>>> Once there are competing operators who offer transit >>>> services, the >>>>>>> set >>>>>>>>> of carriers and their links form a text-book example of a >>>>>>> graph. Go >>>>>>>>> to any Networking 101 class to learn about solutions to >>>>>>> such an old >>>>>>>>> fashioned routing problem. >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> >>>>>>>>> Summary: If GC/Level3/DT/ATT/... and all the other carriers can >>>>>>> agree to >>>>>>>>> directly accept calls from all VoIP operators (regardless >>>>>>> of country >>>>>>> of >>>>>>>>> origin), and thus implicitly also from other operators >>>> with which >>>>>>> they >>>>>>>>> haven't signed a contract, THEN AND ONLY THEN can we avoid the >>>>>>> routing >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> I consider this to be pretty unlikely. >>>>>>>>> >>>>>>>>> I've written up a draft on this topic which will be >>>>>>> submitted to the >>>>>>>>> archives soon. >>>>>>>>> >>>>>>>>> /ol >>>>>>>> _______________________________________________ >>>>>>>> Speermint mailing list >>>>>>>> Speermint@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>>>> _______________________________________________ >>>>>>> Speermint mailing list >>>>>>> Speermint@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/speermint >>>>>>> >>>>>> _______________________________________________ >>>>>> Speermint mailing list >>>>>> Speermint@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Apr 18 16:35: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 1HeGrs-0002mC-Ol; Wed, 18 Apr 2007 16:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeGrr-0002m7-OT for speermint@ietf.org; Wed, 18 Apr 2007 16:35:07 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeGrq-0000al-Ei for speermint@ietf.org; Wed, 18 Apr 2007 16:35:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2007 16:34:51 -0400 X-IronPort-AV: i="4.14,423,1170651600"; d="scan'208"; a="58000159:sNHT41410617168" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3IKYonM023338; Wed, 18 Apr 2007 16:34:50 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3IKYoGf029444; Wed, 18 Apr 2007 20:34:50 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 16:34:43 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Wed, 18 Apr 2007 16:34:39 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302E75C03@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <20070418174533.GA28553@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceB4WVYisazG2+ISISRUeOlgxNzaAAF2gGQ References: <072C5B76F7CEAB488172C6F64B30B5E302E7590D@xmb-rtp-20b.amer.cisco.com><072C5B76F7CEAB488172C6F64B30B5E302E759E9@xmb-rtp-20b.amer.cisco.com><46264492.4010109@cisco.com><072C5B76F7CEAB488172C6F64B30B5E302E75A5F@xmb-rtp-20b.amer.cisco.com><46264D40.4010706@cisco.com> <20070418174533.GA28553@nic.at> From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , X-OriginalArrivalTime: 18 Apr 2007 20:34:43.0910 (UTC) FILETIME=[FF56CE60:01C781F8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1509; t=1176928490; x=1177792490; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Otmar=20Lendl=22=20,=20; bh=Zc1RFz8ji6Sq2/u89VrODmVH6pu/YXSKLCS9wtw7zqo=; b=CiPa/8+W8wXkAHDQO96z9p6KVZ9wM2WZfiCikzbE4viuEGT5aIsXrCPgCwoVnv7BDOinwnNl 74yAWL+fNbplXdBCRp4wOI3jEfvP52uCuhTA0IIGeFL1a6YCRd7VpxRA; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org In the US, some service providers do not consider themselves carriers,=20 to be free from certain regulatory requirements. Mike =20 > -----Original Message----- > From: Otmar Lendl [mailto:lendl@nic.at]=20 > Sent: Wednesday, April 18, 2007 1:46 PM > To: speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > On 2007/04/18 18:04, Paul Kyzivat wrote: > > Michael Hammer (mhammer) wrote: > >=20 > > >Also, are you assuming some form of regulation that=20 > requires SPs to=20 > > >interconnect? :) > >=20 > > I'm not assuming anything. Whatever it takes. Ideally this would=20 > > happen via the open market, but that currently appears unlikely.=20 > > Regulation is a possibility, though in the current climate=20 > (in the USA=20 > > anyway) it seems unlikely to happen. >=20 > fyi, the Austrian regulator requires that all (normal)=20 > Austrian numbers must be reachable from all Austrian carriers. >=20 > They usually don't interfere how the carriers arrange this=20 > (except some financial matters plus obligations put on the incumbent). >=20 > /ol > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 19 10:28: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 1HeXcn-0007Il-5V; Thu, 19 Apr 2007 10:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeXcm-0007IL-22 for speermint@ietf.org; Thu, 19 Apr 2007 10:28:40 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeXck-0001ww-Ov for speermint@ietf.org; Thu, 19 Apr 2007 10:28:40 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 4CE474D1E7; Thu, 19 Apr 2007 16:28:27 +0200 (CEST) Date: Thu, 19 Apr 2007 16:28:27 +0200 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070419142826.GA16325@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <1176914313.17141.157.camel@montag.eng.level3.com> <01f101c781e8$4c6917a0$e53b46e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01f101c781e8$4c6917a0$e53b46e0$@us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/18 20:04, Richard Shockey wrote: > > I love a good discussion as much as the next person but I'm not sure of our > competency to deal with Layer 8-10 issues. Agreed. We just need to make sure that whatever rules these layers come up with can be implemented on layers 5-7 with the tools we are trying to develop. > Something interesting would be what are the minimum authentication and > authorization techniques necessary for SIP service provider A to trust, > route and terminate SIP traffic from Service Provider B. That's certainly the crux of the problem. > Something we tried to do in SIPConnect BTW. Can you summarize the results? /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 19 12:00: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 1HeZ3l-00014I-9l; Thu, 19 Apr 2007 12:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeZ3V-0000SL-8U for speermint@ietf.org; Thu, 19 Apr 2007 12:00:21 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeZ3T-0000b3-Q1 for speermint@ietf.org; Thu, 19 Apr 2007 12:00:21 -0400 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l3JG08C1026356; Thu, 19 Apr 2007 09:00:12 -0700 From: "Richard Shockey" To: "'Otmar Lendl'" , References: <1176914313.17141.157.camel@montag.eng.level3.com> <01f101c781e8$4c6917a0$e53b46e0$@us> <20070419142826.GA16325@nic.at> In-Reply-To: <20070419142826.GA16325@nic.at> Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Thu, 19 Apr 2007 12:00:07 -0400 Message-ID: <005201c7829b$cd895620$689c0260$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AceCjwbWq9yVqS87SpWe3wQrGeZ4lAAC5J3w Content-Language: en-us X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Thursday, April 19, 2007 10:28 AM To: speermint@ietf.org Subject: Re: [Speermint] Re-making or Un-making the PSTN On 2007/04/18 20:04, Richard Shockey wrote: > > I love a good discussion as much as the next person but I'm not sure of our > competency to deal with Layer 8-10 issues. Agreed. We just need to make sure that whatever rules these layers come up with can be implemented on layers 5-7 with the tools we are trying to develop. > Something interesting would be what are the minimum authentication and > authorization techniques necessary for SIP service provider A to trust, > route and terminate SIP traffic from Service Provider B. That's certainly the crux of the problem. > Something we tried to do in SIPConnect BTW. Can you summarize the results? The Charter http://www.sipforum.org/content/view/179/213/ The Specification... http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,83 /Itemid,75/ The attempt was a simple "profile" of how a PBX could interconnect with a service provider network for the purpose of session termination. No new standards were developed P-Asserted Identity is used, TLS must be supported ..but the problem statement address is pretty similar between the interconnection of a PBX to a Service Provider Domain and a SP to SP transaction. The issue is how do networks interconnect or "peer" with each other. Peering BTW does not in my mind imply "settlement free" those are bilateral agreements between capitalistic elements singular or federated and totally outside the scope of this WG. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 19 16:14: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 1Hed1K-0008Fz-2I; Thu, 19 Apr 2007 16:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hed1I-0008FX-8x for speermint@ietf.org; Thu, 19 Apr 2007 16:14:20 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hed1G-0007Af-UG for speermint@ietf.org; Thu, 19 Apr 2007 16:14:20 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6DFFE4D1ED; Thu, 19 Apr 2007 22:14:18 +0200 (CEST) Date: Thu, 19 Apr 2007 22:14:18 +0200 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20070419201418.GA31504@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org FYI: On 2007/04/19 00:04, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Background and Assumptions of the Speermint WG > Author(s) : O. Lendl > Filename : draft-lendl-speermint-background-00.txt > Pages : 15 > Date : 2007-4-18 > > This documents provides background for the Speermint WG. It is > intended to spur discussion about the goals of this WG and tries to > provide guidance on what kind of work is needed to facilitate > widespread SIP-based peering of telephony networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lendl-speermint-background-00.txt As the abstract states: this draft is supposed to generate some discussion on the basic assumption regarding the environment in which the speermint WG operates. Some of the points are sure to be contentious. /ol (reaching for the asbestos underwear) -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 19 16:52: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 1Hedbm-0007aG-F6; Thu, 19 Apr 2007 16:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hedbl-0007Zf-N2 for speermint@ietf.org; Thu, 19 Apr 2007 16:52:01 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hedbk-0007TB-B7 for speermint@ietf.org; Thu, 19 Apr 2007 16:52:01 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JKprnb010284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 16:51:53 -0400 (EDT) In-Reply-To: <20070419201418.GA31504@nic.at> References: <20070419201418.GA31504@nic.at> 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: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Date: Thu, 19 Apr 2007 16:53:10 -0400 To: Otmar Lendl X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org "As anybody on the Internet can contact any destination domain, no business relationship between sender and destination domain is required. This implies that there is no settlement: No money is changing hands because of such a communication." While no money *needs* to change hands, nothing prevents a callee from requesting such funds as a condition of accepting the call (or even the caller forwarding the response and completing the call). Indeed, extensions such as OSP allow for this type of model, but there are many other models. * Apparently, the real world did not choose to implement and deploy SIP and ENUM as initially envisioned by their inventors. In other words: the motivation for Speermint is the failure of the world to conform to the original IETF vision of SIP based real-time communication. * It is not clear to me that this is a choice as such, but could at least partially be a rational decision due to the small number of VoIP customers, compared to the total number of E.164 owners. If only 10% of call destinations use SIP, a carrier incurs a lot of complexity and not much financial gain from direct peering. Thus, it doesn't necessarily follow that this is a long-term failure as the ratio increases. Direct SIP connectivity among second-tier VoIP providers seems at least somewhat common, although primarily based on * codes, rather than DNS resolution (which has more to do with the current UA GUI issues than protocol or trust problems.) "is needed between communication partners, thus no termination fees can be collected." This is logical fallacy. Just because a particular thing is not needed, it does not follow that it cannot be supported. Nothing prevents me from being reachable via 3263 AND charging you to talk to me (naturally, assuming some kind of settlement or collection mechanism). "The SIP identity standard (RFC 4474) uses a different approach (certificate-based, end-to-end) than what is current practice in the telco space (transitive trust)." This is not true. In many instances, telcos connect directly (customer of A talks to customer of B). This is not fundamentally different from A (with cert issued by a mutually-trusted CA) calling B (with cert). In both telco and SIP cases, A and B assert the identity of their customers indirectly, i.e., B needs to trust A that it can actually verify the identity of their customers. On Apr 19, 2007, at 4:14 PM, Otmar Lendl wrote: > > FYI: > > On 2007/04/19 00:04, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Background and Assumptions of the Speermint WG >> Author(s) : O. Lendl >> Filename : draft-lendl-speermint-background-00.txt >> Pages : 15 >> Date : 2007-4-18 >> >> This documents provides background for the Speermint WG. It is >> intended to spur discussion about the goals of this WG and >> tries to >> provide guidance on what kind of work is needed to facilitate >> widespread SIP-based peering of telephony networks. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-lendl-speermint- >> background-00.txt > > As the abstract states: this draft is supposed to generate some > discussion on the basic assumption regarding the environment in > which the speermint WG operates. > > Some of the points are sure to be contentious. > > /ol (reaching for the asbestos underwear) > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 19 17:02: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 1HedmA-0002yG-9u; Thu, 19 Apr 2007 17:02:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hedm8-0002y6-Jb for speermint@ietf.org; Thu, 19 Apr 2007 17:02:44 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hedm6-0000eX-2A for speermint@ietf.org; Thu, 19 Apr 2007 17:02:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Date: Thu, 19 Apr 2007 23:02:43 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D83@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Thread-Index: AceCv1cabqqWjli5SjGqH97tp+FfuwABY1ad References: <20070419201418.GA31504@nic.at> From: "Stastny Richard" To: "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Otmar, =20 thanx for this document, it is very useful and raises a lot if isssues. =20 IMO one central point is the following sentence: =20 "In order to place calls, some alternative to RFC 3263 needs to be developed which accommodates the needs of carriers." =20 Ok, beside that GSMA is using RFC3263 in IPX DNS, do you have ANY idea what this alternative could be or look like? =20 Maybe we also have to define first: 1. What the needs of the carriers are 2. What the options (methods) are to support this needs 3. We should also define what a "carrier" is, or better who is allowed to participate in peering (I am talking here mainly about enterprises, but also about end-users = that are running a proxy) So basically we are back (what I said a year ago) to define the minimum requiriments for a "service provider" to be trusted and also the minimum requirements for the peering protocol =20 Richard ________________________________ Von: Otmar Lendl [mailto:lendl@nic.at] Gesendet: Do 19.04.2007 22:14 An: speermint@ietf.org Betreff: [Speermint] Re: I-D = ACTION:draft-lendl-speermint-background-00.txt FYI: On 2007/04/19 00:04, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Background and Assumptions of the Speermint WG > Author(s) : O. Lendl > Filename : draft-lendl-speermint-background-00.txt > Pages : 15 > Date : 2007-4-18 > =20 > This documents provides background for the Speermint WG. It is > intended to spur discussion about the goals of this WG and tries to > provide guidance on what kind of work is needed to facilitate > widespread SIP-based peering of telephony networks. > > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-lendl-speermint-background-00.t= xt As the abstract states: this draft is supposed to generate some discussion on the basic assumption regarding the environment in which the speermint WG operates. Some of the points are sure to be contentious. /ol (reaching for the asbestos underwear) -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Apr 19 17:48: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 1HeeTr-0007Ew-EK; Thu, 19 Apr 2007 17:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeTq-0007EU-AS for speermint@ietf.org; Thu, 19 Apr 2007 17:47:54 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeTo-0000NW-Uv for speermint@ietf.org; Thu, 19 Apr 2007 17:47:54 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 19 Apr 2007 14:47:52 -0700 X-IronPort-AV: i="4.14,429,1170662400"; d="scan'208"; a="711275687:sNHT35704780" 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: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Date: Thu, 19 Apr 2007 17:47:50 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280847DC90@proton.jnpr.net> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D83@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Thread-Index: AceCv1cabqqWjli5SjGqH97tp+FfuwABY1adAAF0j0A= From: "Reinaldo Penno" To: "Stastny Richard" , "Otmar Lendl" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Yes, you are right. We are back to the same questions as before. It seems something out of Monty Phython's "Meaning of Life". (;-)=20 We are still struggling with the definition of a carrier vs. sp vs. something else. Given this indefinition we are not sure if speermint applies to carriers, sp, vsp, etc. After we define this somebody will ask if the requirements are different, the same, and exactly which one of these players want. Then there is the whole notion of BCP vs. building something new and it goes on and on. We are still struggling with the notion of routing to a URI (how, should we tackle this or not, etc). Do we assume E.164 numbers or only SIP URIs, how people will charge this or others, etc IMHO I believe we should take a step back, look at the charter, maybe decleare some problems "real" but out of the scope for now, try to come up with a (laundry) list of of things we find missing in the existing drafts. We can then update/consolidate/what have you and go from there. Thanks, Reinaldo > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, April 19, 2007 2:03 PM > To: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re: I-D=20 > ACTION:draft-lendl-speermint-background-00.txt >=20 > Otmar, > =20 > thanx for this document, it is very useful and raises a lot=20 > if isssues. > =20 > IMO one central point is the following sentence: > =20 > "In order to place calls, some alternative to RFC 3263 needs to be > developed which accommodates the needs of carriers." > =20 > Ok, beside that GSMA is using RFC3263 in IPX DNS, do you have=20 > ANY idea what this alternative could be or look like? > =20 > Maybe we also have to define first: > 1. What the needs of the carriers are > 2. What the options (methods) are to support this needs 3. We=20 > should also define what a "carrier" is, or better who is=20 > allowed to participate in peering (I am talking here mainly=20 > about enterprises, but also about end-users that are running=20 > a proxy) So basically we are back (what I said a year ago) to=20 > define the minimum requiriments for a "service provider" to=20 > be trusted and also the minimum requirements for the peering protocol > =20 > Richard >=20 > ________________________________ >=20 > Von: Otmar Lendl [mailto:lendl@nic.at] > Gesendet: Do 19.04.2007 22:14 > An: speermint@ietf.org > Betreff: [Speermint] Re: I-D=20 > ACTION:draft-lendl-speermint-background-00.txt >=20 >=20 >=20 >=20 > FYI: >=20 > On 2007/04/19 00:04, Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > > > > Title : Background and Assumptions of the=20 > Speermint WG > > Author(s) : O. Lendl > > Filename : draft-lendl-speermint-background-00.txt > > Pages : 15 > > Date : 2007-4-18 > > =20 > > This documents provides background for the Speermint WG. It is > > intended to spur discussion about the goals of this WG=20 > and tries to > > provide guidance on what kind of work is needed to facilitate > > widespread SIP-based peering of telephony networks. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-lendl-speermint-background-0 > > 0.txt >=20 > As the abstract states: this draft is supposed to generate=20 > some discussion on the basic assumption regarding the=20 > environment in which the speermint WG operates. >=20 > Some of the points are sure to be contentious. >=20 > /ol (reaching for the asbestos underwear) > -- > / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ > | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | > \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Apr 20 07:36: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 1HerPe-0002FN-MW; Fri, 20 Apr 2007 07:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerPd-00027i-7i for speermint@ietf.org; Fri, 20 Apr 2007 07:36:25 -0400 Received: from smtp.iptel.org ([213.192.59.67] helo=mail.iptel.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HerPb-0006es-U3 for speermint@ietf.org; Fri, 20 Apr 2007 07:36:25 -0400 Received: by mail.iptel.org (Postfix, from userid 103) id 9A0D71810C0F; Fri, 20 Apr 2007 13:36:24 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on mail.iptel.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.192.30.175] (unknown [213.192.30.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.iptel.org (Postfix) with ESMTP id E0F1E1810C48; Fri, 20 Apr 2007 13:36:23 +0200 (CEST) Message-ID: <4628A5B6.6070209@iptel.org> Date: Fri, 20 Apr 2007 13:36:22 +0200 From: Jan Janak User-Agent: Icedove 1.5.0.10 (X11/20070307) MIME-Version: 1.0 To: Otmar Lendl , speermint@ietf.org Subject: Re: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt References: <20070419201418.GA31504@nic.at> In-Reply-To: <20070419201418.GA31504@nic.at> X-Enigmail-Version: 0.94.2.0 OpenPGP: id=F8190A31 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > Section 3.1 > > The number of SIP users who are reachable via the open Internet using > RFC 3263 is miniscule when compared to the number of SIP based > telephones in operation today. Pretty much all the ITSPs I have tried over last couple of years would accept INVITE requests coming from the public internet as long as it is destined to one of their subscribers. This also means that all their subscribers (SIP users) are reachable from the open internet. From my experience the reachability problem disappears if you use a user agent that is capable of "dialing" full SIP URIs. Isn't the reachability problem of SIP telephones you mentioned in the I-D caused primarily by the lack of ENUM deployment and fragmented ENUM trees, rather than the failure of the email model for SIP? > Email is non-interactive: filters can be deployed to detect spam > by the content of the mail before the recipient is alerted. That > is not possible for SPIT: content is only available after the > recipient has picked up the phone. A number of SPIT mitigation > strategies have been proposed over the last years, their > effectiveness is yet untested. Spammers often use techniques that make content-filtering inefficient (such as messages send as picture attachments) and in such cases spam filters can only rely on the information from message headers, just like in spit. I think that the main difference between spam and spit is that ringing phones are much more intrusive than unsolicited email messages and that's also probably the reason why ITSPs consider deploying draconian measures, such as restricting the reachability of subscribers. Jan. _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Apr 21 13:41: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 1HfJaK-0003j0-88; Sat, 21 Apr 2007 13:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfJaJ-0003iv-PG for speermint@ietf.org; Sat, 21 Apr 2007 13:41:19 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfJaJ-0001VR-DN for speermint@ietf.org; Sat, 21 Apr 2007 13:41:19 -0400 Received: from ([10.52.116.30]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.31983878; Sat, 21 Apr 2007 13:41:05 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Apr 2007 13:41:05 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Sat, 21 Apr 2007 13:41:03 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201602B6D@PACDCEXCMB04.cable.comcast.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinA= References: <825730.76940.qm@web90606.mail.mud.yahoo.com> From: "Livingood, Jason" To: "Uzelac, Adam" , "Sukanta ganguly" , X-OriginalArrivalTime: 21 Apr 2007 17:41:05.0486 (UTC) FILETIME=[3CB6B6E0:01C7843C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org At some point isn't Bob a SP representing Bob? =20 Jason=20 > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com]=20 > Sent: Monday, April 16, 2007 11:48 AM > To: Sukanta ganguly; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > The point that I am trying to make is that the SIP Peering=20 > models being drawn up here rely too much on the SP=20 > representing Bob. Bob should be able to represent himself=20 > and how the world can reach him without the help of a service=20 > provider. There are numerous and well documented reasons=20 > that Bill might want a SP to represent him, for services like=20 > authentication, anti-SPIT, etc - but Bill should have another option. > Speermint is gaining more and more of a PSTN coloring in it's=20 > attempt to create universal connectivity by NOT using the=20 > PSTN. There's some irony in that. >=20 > -AU=20 >=20 > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Friday, April 13, 2007 10:01 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > >=20 > > Adam, > > I am not sure I follow your complication. The fact that=20 > there are=20 > > two federation of Bob's uri (according to your > > example) should provide Alice a way to find Bob's uri. Are you=20 > > concerned about Alice's discovery of Bob's uri? The border element=20 > > will do that. In that manner it is no different than a classical IP=20 > > route discovery with a router. > > If no deterministic way of finding out the uri ownership can be=20 > > concluded then the next hop makes this attempt. That is the most=20 > > logical way of doing unless their is uniform and well understood=20 > > global master. This happens to be how PSTN does it and hence no=20 > > difference. > >=20 > >=20 > > SG > >=20 > > ----- Original Message ---- > > From: "Uzelac, Adam" > > To: speermint@ietf.org > > Sent: Friday, April 13, 2007 1:18:44 PM > > Subject: [Speermint] Re-making or Un-making the PSTN > >=20 > >=20 > > As I sit here working on the VoIP use-case draft, I can't help but=20 > > thinking if we aren't just re-making the PSTN, instead of un-making=20 > > it. > > The crux of this issue lies with the routing. At some of the basic=20 > > constructs of next-hop routing decisions that border=20 > elements need to=20 > > do, these use-cases are starting to smell more and more like=20 > > PSTN-based routing look-ups. A simple determination of who=20 > owns the=20 > > SIP-URI of the intended recipient can not be determined=20 > definitively,=20 > > so it's just punted off to the next chain in the link. The=20 > ultimate=20 > > end-point determination needs to occur before the next-hop decision=20 > > can be made. > > If we then consider B2BUAs in the mix, it's more likely=20 > than not that=20 > > the original calling and called parties are changed. > > I realize some of this changes due to local policy, but that still=20 > > doesn't get to the root of the problem. > >=20 > > For instance, say there were 2 federations where Bob registered his=20 > > SIP-URI, so that according to members of both federation,=20 > to reach bob=20 > > sessions should be targeted to bob@company.com. Now if=20 > Alice is part=20 > > of a an external domain to those federations, and with both feds=20 > > "advertising" > > reachablity to Bob, how does Alice determine next-hop? > > Basically, who owns Bob's uri? =20 > >=20 > > If we were to bring ENUM into the discussion, it even get's=20 > worse more=20 > > wrought with concern due to starting with regulated e164. I just=20 > > sharing out some thoughts. > >=20 > > -AU > >=20 > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > >=20 > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around=20 > > http://mail.yahoo.com > >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Apr 21 13:46: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 1HfJev-0001Bv-F0; Sat, 21 Apr 2007 13:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfJeu-0001Ac-Ec for speermint@ietf.org; Sat, 21 Apr 2007 13:46:04 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfJet-0002QB-8A for speermint@ietf.org; Sat, 21 Apr 2007 13:46:04 -0400 Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.2859920; Sat, 21 Apr 2007 13:45:49 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Apr 2007 13:45:49 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Sat, 21 Apr 2007 13:45:48 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <20070417150930.GA29145@nic.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceBAnxTtfDMW1kkTGCiqxE/oNCukADOhDCQ References: <20070417150930.GA29145@nic.at> From: "Livingood, Jason" To: "Otmar Lendl" , X-OriginalArrivalTime: 21 Apr 2007 17:45:49.0758 (UTC) FILETIME=[E6272DE0:01C7843C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > * The email model has been (mostly) rejected by the real life > VoIP deployments. The reason seems to be that most carriers > simply will not accept incoming SIP calls from the wide open > Internet. This is rehashing another arguement that we tried to close awhile ago. Recall we will address several stages of peering: direct/bi-lateral, multi-lateral/federated, and then open/public Internet. It is natural that most SPs will start with the first and move to the last. How long it takes to get there is anyone's guess, but we'll try to address each of those use cases. We've already said this several times, so why does this point keep coming up? Do some people just not like that SPs won't start at the end? =20 Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Apr 21 14: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 1HfJzk-0003RQ-9Y; Sat, 21 Apr 2007 14:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfJzi-0003RL-Aw for speermint@ietf.org; Sat, 21 Apr 2007 14:07:34 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfJzg-0001cj-Go for speermint@ietf.org; Sat, 21 Apr 2007 14:07:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: [Speermint] Re-making or Un-making the PSTN Date: Sat, 21 Apr 2007 20:03:21 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D84@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinAAAMoihQ== References: <825730.76940.qm@web90606.mail.mud.yahoo.com> <45AEC6EF95942140888406588E1A660201602B6D@PACDCEXCMB04.cable.comcast.com> From: "Stastny Richard" To: "Livingood, Jason" , "Uzelac, Adam" , "Sukanta ganguly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org > At some point isn't Bob a SP representing Bob?=20 =20 Yes =20 The basic question here is what Bob has to do to be accepted by other SP. =20 Ok, he can start to make bilateral agreements with all other billions of Bob's, be this may not be a useful option. Again,=20 what are the minimum requirements for an adminstrative domain to be accepted in a federation? Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Sa 21.04.2007 19:41 An: Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Betreff: RE: [Speermint] Re-making or Un-making the PSTN At some point isn't Bob a SP representing Bob?=20 Jason > -----Original Message----- > From: Uzelac, Adam [mailto:Adam.Uzelac@globalcrossing.com] > Sent: Monday, April 16, 2007 11:48 AM > To: Sukanta ganguly; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > The point that I am trying to make is that the SIP Peering > models being drawn up here rely too much on the SP > representing Bob. Bob should be able to represent himself > and how the world can reach him without the help of a service > provider. There are numerous and well documented reasons > that Bill might want a SP to represent him, for services like > authentication, anti-SPIT, etc - but Bill should have another option. > Speermint is gaining more and more of a PSTN coloring in it's > attempt to create universal connectivity by NOT using the > PSTN. There's some irony in that. > > -AU > > > -----Original Message----- > > From: Sukanta ganguly [mailto:sganguly@yahoo.com] > > Sent: Friday, April 13, 2007 10:01 PM > > To: Uzelac, Adam; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > Adam, > > I am not sure I follow your complication. The fact that > there are > > two federation of Bob's uri (according to your > > example) should provide Alice a way to find Bob's uri. Are you > > concerned about Alice's discovery of Bob's uri? The border element > > will do that. In that manner it is no different than a classical IP > > route discovery with a router. > > If no deterministic way of finding out the uri ownership can be > > concluded then the next hop makes this attempt. That is the most > > logical way of doing unless their is uniform and well understood > > global master. This happens to be how PSTN does it and hence no > > difference. > > > > > > SG > > > > ----- Original Message ---- > > From: "Uzelac, Adam" > > To: speermint@ietf.org > > Sent: Friday, April 13, 2007 1:18:44 PM > > Subject: [Speermint] Re-making or Un-making the PSTN > > > > > > As I sit here working on the VoIP use-case draft, I can't help but > > thinking if we aren't just re-making the PSTN, instead of un-making > > it. > > The crux of this issue lies with the routing. At some of the basic > > constructs of next-hop routing decisions that border > elements need to > > do, these use-cases are starting to smell more and more like > > PSTN-based routing look-ups. A simple determination of who > owns the > > SIP-URI of the intended recipient can not be determined > definitively, > > so it's just punted off to the next chain in the link. The > ultimate > > end-point determination needs to occur before the next-hop decision > > can be made. > > If we then consider B2BUAs in the mix, it's more likely > than not that > > the original calling and called parties are changed. > > I realize some of this changes due to local policy, but that still > > doesn't get to the root of the problem. > > > > For instance, say there were 2 federations where Bob registered his > > SIP-URI, so that according to members of both federation, > to reach bob > > sessions should be targeted to bob@company.com. Now if > Alice is part > > of a an external domain to those federations, and with both feds > > "advertising" > > reachablity to Bob, how does Alice determine next-hop? > > Basically, who owns Bob's uri?=20 > > > > If we were to bring ENUM into the discussion, it even get's > worse more > > wrought with concern due to starting with regulated e164. I just > > sharing out some thoughts. > > > > -AU > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sat Apr 21 20:45: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 1HfQCu-0006xu-Ij; Sat, 21 Apr 2007 20:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfQCt-0006xp-Cc for speermint@ietf.org; Sat, 21 Apr 2007 20:45:35 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfQCs-0007Gt-5v for speermint@ietf.org; Sat, 21 Apr 2007 20:45:35 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 21 Apr 2007 20:45:33 -0400 id 01588439.462AB02D.00005943 In-Reply-To: <45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com> References: <20070417150930.GA29145@nic.at> <45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Re-making or Un-making the PSTN Date: Sat, 21 Apr 2007 20:45:32 -0400 To: "Livingood, Jason" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Apr 21, 2007, at 1:45 PM, Livingood, Jason wrote: > This is rehashing another arguement that we tried to close awhile ago. > Recall we will address several stages of peering: direct/bi-lateral, > multi-lateral/federated, and then open/public Internet. It is natural > that most SPs will start with the first and move to the last. How > long > it takes to get there is anyone's guess, but we'll try to address each > of those use cases. We've already said this several times, so why > does > this point keep coming up? Do some people just not like that SPs > won't > start at the end? Being that I am one of the dim bulbs that asked this question some time ago after it had been answered some time before that, I think the reason it keeps coming up is that the answer you gave above is not easy to find. One has to wade in to long email threads of esoteric conversations on peering to find that there is a conclusion. It would be great if the charter or milestones hinted at this, but they don't. Short of that, perhaps the chairs can, in a separate email thread, state that the working group will address these different stages and lay out a timetable or method for doing so. Hopefully that would stop this from coming up over and over again. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 08:27: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 1Hfxdf-0005au-On; Mon, 23 Apr 2007 08:27:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfxde-0005ap-Mz for speermint@ietf.org; Mon, 23 Apr 2007 08:27:26 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hfxdc-0000ea-Te for speermint@ietf.org; Mon, 23 Apr 2007 08:27:26 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 6005C4D251; Mon, 23 Apr 2007 14:27:19 +0200 (CEST) Date: Mon, 23 Apr 2007 14:27:19 +0200 From: Otmar Lendl To: Henning Schulzrinne Subject: Re: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Message-ID: <20070423122719.GA31752@nic.at> Mail-Followup-To: Otmar Lendl , Henning Schulzrinne , speermint@ietf.org References: <20070419201418.GA31504@nic.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/19 22:04, Henning Schulzrinne wrote: > "As anybody on the Internet can contact any destination domain, no > business relationship between sender and destination domain is > required. This implies that there is no settlement: No money is > changing hands because of such a communication." > > While no money *needs* to change hands, nothing prevents a callee > from requesting such funds as a condition of accepting the call (or > even the caller forwarding the response and completing the call). > Indeed, extensions such as OSP allow for this type of model, but > there are many other models. My argument is about the reasons why the email model failed to catch on in the carrier-level VoIP world. What you're proposing here is an addition to the email model, with adds settlement to the picture in the hope that this is the missing piece. That's fair and could be a good idea, but I wouldn't call the result the "email-model" any more. The ominous lack of any real world OSP deployments maybe a bad sign, though. Please note that I did not propose a new "Interconnection model" in this draft: this draft just documents why two existing models (namely email and pstn) are not suitable. So yes: please come up with ideas on what changes we need to the email model in order to make up a workable solution for VSPs. > * Apparently, the real world did not choose to implement and deploy > SIP and ENUM as initially envisioned by their inventors. In other > words: the motivation for Speermint is the failure of the world to > conform to the original IETF vision of SIP based real-time > communication. * > > It is not clear to me that this is a choice as such, but could at > least partially be a rational decision due to the small number of > VoIP customers, compared to the total number of E.164 owners. If only > 10% of call destinations use SIP, a carrier incurs a lot of > complexity and not much financial gain from direct peering. That argument is true with respect to peering arrangements. You don't address the lack of open SIP URIs in the typical PSTN-replacement services, though. > Thus, it doesn't necessarily follow that this is a long-term failure > as the ratio increases. We will see. Up to now I don't see the big VoIP operators (MSOs, Vonage, UPC, ...) starting to hand out Internet-reachable URIs. > Direct SIP connectivity among second-tier VoIP > providers seems at least somewhat common, although primarily based on > * codes, rather than DNS resolution (which has more to do with the > current UA GUI issues than protocol or trust problems.) The * codes seem to be a US-specific thing, I don't encounter them with operators in Austria. I think they are a symptom of not using E.164 numbers (e.g. the +1 747 numbers sipphone is using) plus the non-availability of 1.e164.arpa. > > "is needed between communication partners, thus no termination fees > can be collected." > > This is logical fallacy. Just because a particular thing is not > needed, it does not follow that it cannot be supported. Nothing > prevents me from being reachable via 3263 AND charging you to talk to > me (naturally, assuming some kind of settlement or collection > mechanism). Sorry, I have to return the logical fallacy charge. Once you have a settlement between parties (however indirect the billing is), this is per definition a business relationship. Thus, once a VSPs requires settlement, it requires a business relationship. As stated above, I don't think this should still be labeled "the email model". Again, I don't think we're that much in disagreement on the facts, but only on the terminology. For me, "email model" and "settlement" just doesn't go together. > > "The SIP identity standard (RFC 4474) uses a different approach > (certificate-based, end-to-end) than what is current practice in > the telco space (transitive trust)." > > This is not true. In many instances, telcos connect directly > (customer of A talks to customer of B). This is not fundamentally > different from A (with cert issued by a mutually-trusted CA) calling > B (with cert). In both telco and SIP cases, A and B assert the > identity of their customers indirectly, i.e., B needs to trust A that > it can actually verify the identity of their customers. If only two parties are involved, the difference may indeed be negligible. Once you have a call traversing three networks then the difference is clear: Consider A -> B -> C In the PSTN case, B trusts the callerID from A and thus forwards it to C which trusts B. C doesn't even know that the call did not originate in B's network. Thus C has just the option to either trust the callerID it receives in ISUP messages from B's switches (and thus whomever B trusts) or not. In the SIP Identity scenario, unless B re-signs the SIP message, this is no the case. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 09: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 1Hfz4q-0005QK-04; Mon, 23 Apr 2007 09:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfz4p-0005Q1-83 for speermint@ietf.org; Mon, 23 Apr 2007 09:59:35 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfz4n-0005Y1-NP for speermint@ietf.org; Mon, 23 Apr 2007 09:59:35 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 87DF94D251; Mon, 23 Apr 2007 15:59:30 +0200 (CEST) Date: Mon, 23 Apr 2007 15:59:30 +0200 From: Otmar Lendl To: Stastny Richard Subject: Re: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Message-ID: <20070423135930.GB31752@nic.at> Mail-Followup-To: Otmar Lendl , Stastny Richard , speermint@ietf.org References: <20070419201418.GA31504@nic.at> <32755D354E6B65498C3BD9FD496C7D466B1D83@oefeg-s04.oefeg.loc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D83@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/19 23:04, Stastny Richard wrote: > Otmar, > > thanx for this document, it is very useful and raises a lot if isssues. The idea was to condense a lot of mailing list arguments into one neat document. > IMO one central point is the following sentence: > > "In order to place calls, some alternative to RFC 3263 needs to be > developed which accommodates the needs of carriers." > > Ok, beside that GSMA is using RFC3263 in IPX DNS, As far as I know, they aren't. The last time I heard a presentation on the IPX, there was a lot of talk about "hubs" which are basically peering aggregators. Pure RFC3263 is thus just for destination networks with which a direct peering relation has been established. Which means: RFC3263 is just used in one part of the next hop determination, and it is not the complete algorithm. > do you have ANY idea what this alternative could be or look like? Sure. Based on my experience here it is rather pointless to re-interate my proposal until we've reached agreement on the requirements. > Maybe we also have to define first: Yes. That's what's IMHO really needed. There are actually very simple answers to your questions: > 1. What the needs of the carriers are * Have full control on with whom he peers. * This decision can range from - open peering (I peer with everybody) - manual peering only (I only peer with others I have manually selected) - peer with everybody for whom someone I trust vouches for - peer with everybody who agrees to my settlement terms - peer with everybody who qualifies according to some technical criteria - peer with everybody I'm legally required to do - peer with everybody who can provide sufficient ranking in a specific distributed reputation system - peer with everybody who is using some certified hard/software for peering - peer over private infrastructures - peer only using some sort of mediated peering arrangement Any combination of these criteria must be possible. * Must support both E.164 and URI-based calls * As automatic as possible. In other words: whatever criteria the lawyers/CFOs/CEOs/Techies of a VSP can come up with, the protocol must support in a unified way. > 2. What the options (methods) are to support this needs hm? > 3. We should also define what a "carrier" is, or better > who is allowed to participate in peering > (I am talking here mainly about enterprises, but also about end-users that are > running a proxy) There is absolutely no need to define this. In practice, a commercial VSP will just make different choices regarding with whom he will peer as compared to an enterprise VoIP installation. The BGP protocol doesn't a have a variant for Tier-0 networks and one for multi-homed enterprises. These terms are irrelevant to the protocol. We MUST strive for the same: The same toolbox must be good enough for everybody, regardless of what label some want to put on them. Never ever should the IETF define who is "allowed to participate in peering". That decision MUST reside only with the potential peering partners. Example: If Global Crossing wants to peer with my private Asterisk PBX which just hosts my phone at home plus the softphone on my laptop, then good for them (and for me). If two VSPs peer with each other it should just be because these two AGREE to peer with each other. As it is likely that not everybody will talk to everybody else, there will be transit operators. This is just something we have to allow for in the protocol. *Who* will play that role is not something the IETF is supposed to solve. If that is a viable business, then someone will fill the role. If everybody else suddenly converts to direct peering, then this business model will cease to be viable. So what? I can hardly find a topic with should be of less concern to the IETF. > So basically we are back (what I said a year ago) to define > the minimum requiriments for a "service provider" to be trusted > and also the minimum requirements for the peering protocol I think this is the wrong approach. The question of whom a VSP trusts enough to peer with him, is solely in the purview of that VSP. The only topic the IETF can solve is the technical protocol with which VSPs can * learn who the destination VSP is * learn more about that VSP to determine whether the peering requirements of that destination VSP allows for a direct call. We really *really* must make sure that the IETF defines only the machinery which control the peering decision. The control-levers of said machinery MUST firmly stay in the hands of the organization running this network. Everything else is doomed to fail. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 10: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 1HfzW3-0007jv-GF; Mon, 23 Apr 2007 10:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfzW2-0007jq-Dn for speermint@ietf.org; Mon, 23 Apr 2007 10:27:42 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfzW0-0007OQ-VG for speermint@ietf.org; Mon, 23 Apr 2007 10:27:42 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 70D9C4D251; Mon, 23 Apr 2007 16:27:40 +0200 (CEST) Date: Mon, 23 Apr 2007 16:27:40 +0200 From: Otmar Lendl To: Jan Janak Subject: Re: [Speermint] Re: I-D ACTION:draft-lendl-speermint-background-00.txt Message-ID: <20070423142740.GC31752@nic.at> Mail-Followup-To: Otmar Lendl , Jan Janak , speermint@ietf.org References: <20070419201418.GA31504@nic.at> <4628A5B6.6070209@iptel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4628A5B6.6070209@iptel.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/20 13:04, Jan Janak wrote: > > Section 3.1 > > > > The number of SIP users who are reachable via the open Internet using > > RFC 3263 is miniscule when compared to the number of SIP based > > telephones in operation today. > > Pretty much all the ITSPs I have tried over last couple of years > would accept INVITE requests coming from the public internet as long > as it is destined to one of their subscribers. This also means that > all their subscribers (SIP users) are reachable from the open > internet. Yes, your average "let's take ser, a cisco media gateway and let's play ITSP" service will have open URIs. I really doubt that the majority of SIP users are using such services. Where are the numbers really? * PBXs Most new PBX deployments are VoIP based these days (though usually not SIP). When we shopped around for one recently, we had troubles finding any vendor whose product was designed to do SIP on the open Internet. We got mostly blank stares. * Cable networks These guys go for triple-play (TV, Internet, Telephony) in a huge way. Those are the companies who sign up more users in a month than what all the second-tier services have in total. * Alternative carriers using a NGN style device. Often the user isn't even told that his IAD contains a SIP ATA, let alone a SIP URI. > From my experience the reachability problem disappears if you use > a user agent that is capable of "dialing" full SIP URIs. > > Isn't the reachability problem of SIP telephones you mentioned in the > I-D caused primarily by the lack of ENUM deployment and fragmented > ENUM trees, rather than the failure of the email model for SIP? The lack of ENUM certainly doesn't help. Consider e.g. the Netherlands: I find quotes like "IP telephony services now account for around 30% of the Dutch voice market." For all I know, UPC Netherlands, Casema, MultiKabel, Essent and CaiW account for most of these users. I haven't seen any published way of calling their users via SIP. Have you? > > Email is non-interactive: filters can be deployed to detect spam > > by the content of the mail before the recipient is alerted. That > > is not possible for SPIT: content is only available after the > > recipient has picked up the phone. A number of SPIT mitigation > > strategies have been proposed over the last years, their > > effectiveness is yet untested. > > Spammers often use techniques that make content-filtering inefficient > (such as messages send as picture attachments) and in such cases > spam filters can only rely on the information from message headers, > just like in spit. I think that the main difference between spam and > spit is that ringing phones are much more intrusive than unsolicited > email messages and that's also probably the reason why ITSPs consider > deploying draconian measures, such as restricting the reachability of > subscribers. Agreed. That's why solving the SPAM/SPIT problem is even more important with VoIP than with email. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 13:28: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 1Hg2Kp-0002jV-7A; Mon, 23 Apr 2007 13:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Ko-0002jP-Iz for speermint@ietf.org; Mon, 23 Apr 2007 13:28:18 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2Kn-0008Py-Bx for speermint@ietf.org; Mon, 23 Apr 2007 13:28:18 -0400 Received: from ([24.40.15.92]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.6807973; Mon, 23 Apr 2007 13:27:48 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 13:27:48 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 13:27:46 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201602C86@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D84@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinAAAMoihQBjUJFw References: <825730.76940.qm@web90606.mail.mud.yahoo.com><45AEC6EF95942140888406588E1A660201602B6D@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D466B1D84@oefeg-s04.oefeg.loc> From: "Livingood, Jason" To: "Stastny Richard" , "Uzelac, Adam" , "Sukanta ganguly" , X-OriginalArrivalTime: 23 Apr 2007 17:27:48.0148 (UTC) FILETIME=[B64A1740:01C785CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > Again, > what are the minimum requirements for an adminstrative domain=20 > to be accepted in a federation? >=20 > Richard Why isn't that the private business of a given federation and, therefore, totally out of scope for the WG? Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 13:30: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 1Hg2Mc-0003hp-2p; Mon, 23 Apr 2007 13:30:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Ma-0003he-M0 for speermint@ietf.org; Mon, 23 Apr 2007 13:30:08 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2MZ-0000mW-DZ for speermint@ietf.org; Mon, 23 Apr 2007 13:30:08 -0400 Received: from ([10.195.246.152]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.42198256; Mon, 23 Apr 2007 13:29:42 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 13:29:42 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 13:29:41 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceEd5M3AzzC7bIvT66cP6yl/17oVABVT8mQ References: <20070417150930.GA29145@nic.at> <45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com> <02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> From: "Livingood, Jason" To: "Andrew Newton" X-OriginalArrivalTime: 23 Apr 2007 17:29:42.0594 (UTC) FILETIME=[FA812A20:01C785CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Okay - =20 > Being that I am one of the dim bulbs that asked this question=20 > some time ago after it had been answered some time before=20 > that, I think the reason it keeps coming up is that the=20 > answer you gave above is not easy to find. One has to wade=20 > in to long email threads of esoteric conversations on peering=20 > to find that there is a conclusion. It would be great if the=20 > charter or milestones hinted at this, but they don't. Short=20 > of that, perhaps the chairs can, in a separate email thread,=20 > state that the working group will address these different=20 > stages and lay out a timetable or method for doing so. =20 > Hopefully that would stop this from coming up over and over again. >=20 > -andy >=20 Okay - Here it is from my message to the list on 16 Feb 2007: * There are 3 likely stages or levels of deployment that should be accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open Internet). Depending upon the implementer, the maturity of their app/business/users/regulations/etc., one may make sense. In general, the lifecycle is Direct --> Federated --> Open. It is impossible for us to predict or guide when the market or implementers will go to each stage; we should try to describe how to do each and let implementers figure out the rest. This also recognizes that this is not a battle of direct vs. federated vs. open, as each has a place and a role. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 13:41: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 1Hg2XZ-0003M9-1C; Mon, 23 Apr 2007 13:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2XX-0003JC-5D for speermint@ietf.org; Mon, 23 Apr 2007 13:41:27 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg2XV-000303-Lb for speermint@ietf.org; Mon, 23 Apr 2007 13:41:27 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 23 Apr 2007 10:41: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 l3NHf4Sd006736; Mon, 23 Apr 2007 10:41:09 -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 l3NHedI9001928; Mon, 23 Apr 2007 10:40:39 -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 10:41:02 -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: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 10:40:28 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D226F63CE@namail5.corp.adobe.com> In-Reply-To: <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceEd5M3AzzC7bIvT66cP6yl/17oVABVT8mQAABRpMA= References: <20070417150930.GA29145@nic.at><45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com><02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> From: "Henry Sinnreich" To: "Livingood, Jason" , , "Otmar Lendl" X-OriginalArrivalTime: 23 Apr 2007 17:41:02.0439 (UTC) FILETIME=[8FB94770:01C785CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jason, This makes a lot of sense. Thanks for the good guidance. Just keep presence, IM and multimedia in mind :-) Henry -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, April 23, 2007 12:30 PM To: Andrew Newton Cc: speermint@ietf.org; Otmar Lendl Subject: RE: [Speermint] Re-making or Un-making the PSTN Okay - Here it is from my message to the list on 16 Feb 2007: * There are 3 likely stages or levels of deployment that should be accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open Internet). Depending upon the implementer, the maturity of their app/business/users/regulations/etc., one may make sense. In general, the lifecycle is Direct --> Federated --> Open. It is impossible for us to predict or guide when the market or implementers will go to each stage; we should try to describe how to do each and let implementers figure out the rest. This also recognizes that this is not a battle of direct vs. federated vs. open, as each has a place and a role. Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 13:44: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 1Hg2aU-0006um-Aq; Mon, 23 Apr 2007 13:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2aT-0006u5-AB for speermint@ietf.org; Mon, 23 Apr 2007 13:44:29 -0400 Received: from paoakoavas10.cable.comcast.com ([208.17.35.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2aR-0003aZ-Ty for speermint@ietf.org; Mon, 23 Apr 2007 13:44:29 -0400 Received: from ([10.195.246.152]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.32017763; Mon, 23 Apr 2007 13:44:13 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 13:44:13 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 13:44:11 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201602CA6@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D226F63CE@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceEd5M3AzzC7bIvT66cP6yl/17oVABVT8mQAABRpMAAACzckA== References: <20070417150930.GA29145@nic.at><45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com><02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> <24CCCC428EFEA2469BF046DB3C7A8D226F63CE@namail5.corp.adobe.com> From: "Livingood, Jason" To: "Henry Sinnreich" , , "Otmar Lendl" X-OriginalArrivalTime: 23 Apr 2007 17:44:13.0015 (UTC) FILETIME=[0150DE70:01C785CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Agreed! And from that same Feb email: * This recognizes that VoIP (TN-based URIs and voice apps) and IM (username-based URIs and various apps) have very different use cases and requirements. Continuing to try to jam them together is counter-productive. Separating them will accelerate each track of work. * This recognizes that it is not for us to decide if TN or name-based URIs win/lose in the end. We work to accomodate applications that use both; the market and implementers will ultimately decide upon success or failure. JL=20 > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 > Sent: Monday, April 23, 2007 1:40 PM > To: Livingood, Jason; speermint@ietf.org; Otmar Lendl > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Jason, >=20 > This makes a lot of sense. Thanks for the good guidance. >=20 > Just keep presence, IM and multimedia in mind :-) >=20 > Henry >=20 > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, April 23, 2007 12:30 PM > To: Andrew Newton > Cc: speermint@ietf.org; Otmar Lendl > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Okay - Here it is from my message to the list on 16 Feb 2007: >=20 > * There are 3 likely stages or levels of deployment that should be > accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open=20 > Internet). > Depending upon the implementer, the maturity of their=20 > app/business/users/regulations/etc., one may make sense. In=20 > general, the lifecycle is Direct --> Federated --> Open. It=20 > is impossible for us to predict or guide when the market or=20 > implementers will go to each stage; we should try to describe=20 > how to do each and let implementers figure out the rest. =20 > This also recognizes that this is not a battle of direct vs.=20 > federated vs. open, as each has a place and a role. >=20 > Jason >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 14:10: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 1Hg2zU-0004U1-3Q; Mon, 23 Apr 2007 14:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2zS-0004Tw-NB for speermint@ietf.org; Mon, 23 Apr 2007 14:10:18 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2zR-0001Cn-Fb for speermint@ietf.org; Mon, 23 Apr 2007 14:10:18 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Apr 2007 14:10:16 -0400 id 01588112.462CF688.0000577C In-Reply-To: <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> References: <20070417150930.GA29145@nic.at> <45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com> <02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <267560BF-E6A5-4E17-9123-E7F6D9DE2681@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 14:10:15 -0400 To: "Livingood, Jason" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jason, This sounds good. I'll note that when I asked about this last year, I was under the impression that there was a priority order for doing the work: direct, then federation, then open. I see there is no such priority order now, which I think is a good thing. How do you envision each of these stages being addressed simultaneously in the drafts under consideration? Should each draft have an applicability statement about each stage? The method for addressing these stages was what I was daftly hinting at. -andy On Apr 23, 2007, at 1:29 PM, Livingood, Jason wrote: > Okay - > >> Being that I am one of the dim bulbs that asked this question >> some time ago after it had been answered some time before >> that, I think the reason it keeps coming up is that the >> answer you gave above is not easy to find. One has to wade >> in to long email threads of esoteric conversations on peering >> to find that there is a conclusion. It would be great if the >> charter or milestones hinted at this, but they don't. Short >> of that, perhaps the chairs can, in a separate email thread, >> state that the working group will address these different >> stages and lay out a timetable or method for doing so. >> Hopefully that would stop this from coming up over and over again. >> >> -andy >> > > Okay - Here it is from my message to the list on 16 Feb 2007: > > * There are 3 likely stages or levels of deployment that should be > accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open > Internet). > Depending upon the implementer, the maturity of their > app/business/users/regulations/etc., one may make sense. In general, > the lifecycle is Direct --> Federated --> Open. It is impossible > for us > to predict or guide when the market or implementers will go to each > stage; we should try to describe how to do each and let implementers > figure out the rest. This also recognizes that this is not a > battle of > direct vs. federated vs. open, as each has a place and a role. > > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 15:40: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 1Hg4Ow-0003KV-VS; Mon, 23 Apr 2007 15:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Ow-0003KQ-5x for speermint@ietf.org; Mon, 23 Apr 2007 15:40:42 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4Ou-0002F5-UO for speermint@ietf.org; Mon, 23 Apr 2007 15:40:42 -0400 Received: from ([24.40.15.118]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.6815800; Mon, 23 Apr 2007 15:40:26 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:40:26 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 15:40:25 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602017519C9@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <267560BF-E6A5-4E17-9123-E7F6D9DE2681@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceF0rIUilHb91XYSdSP4GOTS3cr7AADHfpA References: <20070417150930.GA29145@nic.at> <45AEC6EF95942140888406588E1A660201602B6E@PACDCEXCMB04.cable.comcast.com> <02AD3405-4BC7-49EF-B2C2-8408BCE067D5@hxr.us> <45AEC6EF95942140888406588E1A660201602C8E@PACDCEXCMB04.cable.comcast.com> <267560BF-E6A5-4E17-9123-E7F6D9DE2681@hxr.us> From: "Livingood, Jason" To: "Andrew Newton" X-OriginalArrivalTime: 23 Apr 2007 19:40:26.0306 (UTC) FILETIME=[3DB8A220:01C785DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: speermint@ietf.org, Otmar Lendl X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org The way we address each is by having use cases for each... Without use cases, it won't move ahead. Jason=20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Monday, April 23, 2007 2:10 PM > To: Livingood, Jason > Cc: Otmar Lendl; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 > Jason, >=20 > This sounds good. I'll note that when I asked about this=20 > last year, I was under the impression that there was a=20 > priority order for doing the work: direct, then federation,=20 > then open. I see there is no such priority order now, which=20 > I think is a good thing. >=20 > How do you envision each of these stages being addressed=20 > simultaneously in the drafts under consideration? Should=20 > each draft have an applicability statement about each stage? =20 > The method for addressing these stages was what I was daftly=20 > hinting at. >=20 > -andy >=20 > On Apr 23, 2007, at 1:29 PM, Livingood, Jason wrote: >=20 > > Okay - > > > >> Being that I am one of the dim bulbs that asked this question > >> some time ago after it had been answered some time before > >> that, I think the reason it keeps coming up is that the > >> answer you gave above is not easy to find. One has to wade > >> in to long email threads of esoteric conversations on peering > >> to find that there is a conclusion. It would be great if the > >> charter or milestones hinted at this, but they don't. Short > >> of that, perhaps the chairs can, in a separate email thread, > >> state that the working group will address these different > >> stages and lay out a timetable or method for doing so. > >> Hopefully that would stop this from coming up over and over again. > >> > >> -andy > >> > > > > Okay - Here it is from my message to the list on 16 Feb 2007: > > > > * There are 3 likely stages or levels of deployment that should be > > accomodated: DIRECT, FEDERATED, and OPEN (e.g., over the open =20 > > Internet). > > Depending upon the implementer, the maturity of their > > app/business/users/regulations/etc., one may make sense. =20 > In general, > > the lifecycle is Direct --> Federated --> Open. It is impossible =20 > > for us > > to predict or guide when the market or implementers will go to each > > stage; we should try to describe how to do each and let implementers > > figure out the rest. This also recognizes that this is not a =20 > > battle of > > direct vs. federated vs. open, as each has a place and a role. > > > > Jason >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 16:07: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 1Hg4pD-00015R-D6; Mon, 23 Apr 2007 16:07:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4pC-00015I-Kv for speermint@ietf.org; Mon, 23 Apr 2007 16:07:50 -0400 Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4pB-0000GF-D7 for speermint@ietf.org; Mon, 23 Apr 2007 16:07:50 -0400 Received: from ([10.52.116.30]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.42205337; Mon, 23 Apr 2007 15:52:34 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 15:52:34 -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 15:52:33 -0400 Message-ID: <45AEC6EF95942140888406588E1A6602017519D4@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [wg-business] IETF-68 Minutes Uploaded Thread-Index: AceF4O/W5nHnZG6PT0KQ3bHHc+tOUQ== From: "Livingood, Jason" To: X-OriginalArrivalTime: 23 Apr 2007 19:52:34.0263 (UTC) FILETIME=[EF9E0E70:01C785E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Speermint] [wg-business] IETF-68 Minutes Uploaded X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thanks to Alex, our minutes have just been uploaded. They are available at http://www3.ietf.org/proceedings/07mar/minutes/speermint.txt Regards Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Apr 23 19:20: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 1Hg7pe-0005Mp-Pv; Mon, 23 Apr 2007 19:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg7pc-0005Mk-Tl for speermint@ietf.org; Mon, 23 Apr 2007 19:20:28 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg7pb-0006gs-Lj for speermint@ietf.org; Mon, 23 Apr 2007 19:20:28 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3NNKP621733; Mon, 23 Apr 2007 23:20:25 GMT 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: [Speermint] Re-making or Un-making the PSTN Date: Mon, 23 Apr 2007 19:20:24 -0400 Message-ID: In-Reply-To: <45AEC6EF95942140888406588E1A660201602C86@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinAAAMoihQBjUJFwAAYNo5A= References: <825730.76940.qm@web90606.mail.mud.yahoo.com><45AEC6EF95942140888406588E1A660201602B6D@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D466B1D84@oefeg-s04.oefeg.loc> <45AEC6EF95942140888406588E1A660201602C86@PACDCEXCMB04.cable.comcast.com> From: "James McEachern" To: "Livingood, Jason" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Thank you Jason. I've been wondering the same thing myself, while reading this endless "meaning of life" digression. Jim=20 -----Original Message----- From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]=20 Sent: Monday, April 23, 2007 1:28 PM To: Stastny Richard; Uzelac, Adam; Sukanta ganguly; speermint@ietf.org Subject: RE: [Speermint] Re-making or Un-making the PSTN =20 > -----Original Message----- > Again, > what are the minimum requirements for an adminstrative domain=20 > to be accepted in a federation? >=20 > Richard Why isn't that the private business of a given federation and, therefore, totally out of scope for the WG? Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 06:38: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 1HgIQC-0006MO-Qn; Tue, 24 Apr 2007 06:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIQB-0006MI-J9 for speermint@ietf.org; Tue, 24 Apr 2007 06:38:55 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgIQ9-0005DL-7K for speermint@ietf.org; Tue, 24 Apr 2007 06:38:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 12:38:53 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> In-Reply-To: <45AEC6EF95942140888406588E1A660201602C86@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinAAAMoihQBjUJFwACPriXA= From: "Stastny Richard" To: "Livingood, Jason" , "Uzelac, Adam" , "Sukanta ganguly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jason, > > Again, > > what are the minimum requirements for an adminstrative domain > > to be accepted in a federation? > > > > Richard >=20 > Why isn't that the private business of a given federation and, > therefore, totally out of scope for the WG? Bi-lateral is out-of-scope Federation is out-of-scope And the open Internet is dealt with in RFC3263? So what are we doing in Speermint? Richard > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Monday, April 23, 2007 7:28 PM > To: Stastny Richard; Uzelac, Adam; Sukanta ganguly; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 >=20 >=20 > > -----Original Message----- > > Again, > > what are the minimum requirements for an adminstrative domain > > to be accepted in a federation? > > > > Richard >=20 > Why isn't that the private business of a given federation and, > therefore, totally out of scope for the WG? >=20 > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 07:08: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 1HgIsW-0006Ry-Bz; Tue, 24 Apr 2007 07:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIsU-0006Rt-V3 for speermint@ietf.org; Tue, 24 Apr 2007 07:08:10 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgIsT-0001NL-OG for speermint@ietf.org; Tue, 24 Apr 2007 07:08:10 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 07:08:07 -0400 id 015880BA.462DE517.00002D83 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 07:08:06 -0400 To: "Stastny Richard" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Uzelac, Adam" , "Livingood, Jason" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Apr 24, 2007, at 6:38 AM, Stastny Richard wrote: > Bi-lateral is out-of-scope > Federation is out-of-scope If you mean these are out-of-scope based on Jason's comments about the minimum requirements being the private business of a federation, then perhaps you misunderstood the remark. SPEERMINT can still work on a set of BCPs for these relationships, from which private peering relationships can pick and choose. For instance, if SPEERMINT produces BCPs on ENUM and TLS, a private federation could decide to use the ENUM BCP but not the TLS BCP (because perhaps they have blue- wire security instead). Of course, if that's not what was meant by any of this, then I'm at a loss too. > And the open Internet is dealt with in RFC3263? For viable open peering, more is probably needed than 3263. And here, I think SPEERMINT can say that open peering MUST have x, y, and z. For instance, open peering MUST use TLS. > So what are we doing in Speermint? That's how I understand it. If I've got it wrong, hopefully I'll be corrected. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 07:14: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 1HgIyb-00056V-ON; Tue, 24 Apr 2007 07:14:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIyb-00054p-28 for speermint@ietf.org; Tue, 24 Apr 2007 07:14:29 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgIyZ-0003Zc-9J for speermint@ietf.org; Tue, 24 Apr 2007 07:14:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 13:14:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E5A@oefeg-s04.oefeg.loc> In-Reply-To: <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceGYNnn0L8+xKouTRGePXOCPXfGlwAAE2Mw From: "Stastny Richard" To: "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Uzelac, Adam" , "Livingood, Jason" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Andy, That is exactly what I meant: >=20 > On Apr 24, 2007, at 6:38 AM, Stastny Richard wrote: >=20 > > Bi-lateral is out-of-scope > > Federation is out-of-scope >=20 > If you mean these are out-of-scope based on Jason's comments about > the minimum requirements being the private business of a federation, > then perhaps you misunderstood the remark. SPEERMINT can still work > on a set of BCPs for these relationships, from which private peering > relationships can pick and choose. For instance, if SPEERMINT > produces BCPs on ENUM and TLS, a private federation could decide to > use the ENUM BCP but not the TLS BCP (because perhaps they have blue- > wire security instead). >=20 > Of course, if that's not what was meant by any of this, then I'm at a > loss too. >=20 > > And the open Internet is dealt with in RFC3263? >=20 > For viable open peering, more is probably needed than 3263. And > here, I think SPEERMINT can say that open peering MUST have x, y, and > z. For instance, open peering MUST use TLS. This is exactly what I understand with minimum requirements >=20 > > So what are we doing in Speermint? >=20 > That's how I understand it. If I've got it wrong, hopefully I'll be > corrected. >=20 > -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 09:42: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 1HgLHz-0004Sn-V0; Tue, 24 Apr 2007 09:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLHz-0004Si-92 for speermint@ietf.org; Tue, 24 Apr 2007 09:42:39 -0400 Received: from pacdcimo02.cable.comcast.com ([24.40.8.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgLHy-0001vx-0y for speermint@ietf.org; Tue, 24 Apr 2007 09:42:39 -0400 Received: from ([24.40.15.92]) by pacdcimo02.cable.comcast.com with ESMTP id KP-GZL85.6833674; Tue, 24 Apr 2007 09:42:22 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:42:22 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 09:42:20 -0400 Message-ID: <45AEC6EF95942140888406588E1A660201751AB7@PACDCEXCMB04.cable.comcast.com> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinAAAMoihQBjUJFwACPriXAABlKDMA== References: <45AEC6EF95942140888406588E1A660201602C86@PACDCEXCMB04.cable.comcast.com> <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> From: "Livingood, Jason" To: "Stastny Richard" , "Uzelac, Adam" , "Sukanta ganguly" , X-OriginalArrivalTime: 24 Apr 2007 13:42:22.0520 (UTC) FILETIME=[62CCCB80:01C78676] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org I think you are misunderstanding what I am saying. Bi-lateral, federated, and open are all IN SCOPE. What is NOT in scope, IMHO, is what the "minimum requirements for an administrative domain to be accepted in a federation" should be. Why is this out of scope? It is a business issue - not a technology standards issue. For example, XYZ Enterprise Federation Inc. may only admit enterprises. And ABC Education Federation Inc. may only admit universities. And RS Global Peering Exchange Inc. may only admit service providers of 1M customers or greater. And JL Tiny Net Federation Inc. may only admit small businesses and individual user domains. How these federations choose to select/allow domains to participate is the private business of those federations. Jason > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, April 24, 2007 6:39 AM > To: Livingood, Jason; Uzelac, Adam; Sukanta ganguly;=20 > speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > Jason, > > > Again, > > > what are the minimum requirements for an adminstrative=20 > domain to be=20 > > > accepted in a federation? > > > > > > Richard > >=20 > > Why isn't that the private business of a given federation and,=20 > > therefore, totally out of scope for the WG? >=20 > Bi-lateral is out-of-scope > Federation is out-of-scope > And the open Internet is dealt with in RFC3263? >=20 > So what are we doing in Speermint? >=20 > Richard >=20 > > -----Original Message----- > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > Sent: Monday, April 23, 2007 7:28 PM > > To: Stastny Richard; Uzelac, Adam; Sukanta ganguly;=20 > speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > >=20 > >=20 > >=20 > > > -----Original Message----- > > > Again, > > > what are the minimum requirements for an adminstrative=20 > domain to be=20 > > > accepted in a federation? > > > > > > Richard > >=20 > > Why isn't that the private business of a given federation and,=20 > > therefore, totally out of scope for the WG? > >=20 > > Jason >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 10:00: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 1HgLYy-0000m2-UR; Tue, 24 Apr 2007 10:00:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLYx-0000lq-Io for speermint@ietf.org; Tue, 24 Apr 2007 10:00:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgLYx-0007SX-5J for speermint@ietf.org; Tue, 24 Apr 2007 10:00:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2007 10:00:11 -0400 X-IronPort-AV: i="4.14,448,1170651600"; d="scan'208"; a="58470694:sNHT51294896" 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 l3OE0AE8018931; Tue, 24 Apr 2007 10:00:10 -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 l3ODxwlG000551; Tue, 24 Apr 2007 14:00:10 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 09:59:52 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 09:59:50 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceGYORhHWPJmazcRgm981AFxlPOqQAFvGww References: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" , "Stastny Richard" X-OriginalArrivalTime: 24 Apr 2007 13:59:52.0401 (UTC) FILETIME=[D493EC10:01C78678] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2485; t=1177423210; x=1178287210; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Andrew=20Newton=22=20, =0A=20=20=20=20=20=20=20=20= 22Stastny=20Richard=22=20; bh=ABdjJmzk+Hfi9AOZloeEaDv3xSWufHKBjIRQ4/C72dY=; b=Dgzgk0ITHtnDeYIxb38LYmS2TqjiTp3ysEUDmUQZ0wMyI0Wtc9jpVZK4PRqd8tuNMQrE7Yza QyLse9SMGccqVx/p7nueYJ8xpmKi28obSeRJtUARamJIzO0abDefuVXv; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: speermint@ietf.org, "Uzelac, Adam" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Geez, you guys need to get some fresh air and sunshine. Whether the relationship between peers is bilateral or multilateral is not that relevant. What is important is being able to discover whether a potential peer has a relationship or not with you. The nature of the relationship can be defined fully elsewhere, what is needed is the toolset which allows the peers to do discovery and to connect in a secure manner or not, as they see fit. =20 Some of these issues, such as billing and charging, are secondary. They may or may not, and do so in different ways. The question is whether there is a means of identifying what those various aspects are. Try layering this. The underlying layer enables the exchange of policy documents, irrespective of what is in the policy documents. Later, someone can hash out the policies. Mike > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Tuesday, April 24, 2007 7:08 AM > To: Stastny Richard > Cc: Uzelac, Adam; Livingood,Jason; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > On Apr 24, 2007, at 6:38 AM, Stastny Richard wrote: >=20 > > Bi-lateral is out-of-scope > > Federation is out-of-scope >=20 > If you mean these are out-of-scope based on Jason's comments=20 > about the minimum requirements being the private business of=20 > a federation, then perhaps you misunderstood the remark. =20 > SPEERMINT can still work on a set of BCPs for these=20 > relationships, from which private peering relationships can=20 > pick and choose. For instance, if SPEERMINT produces BCPs on=20 > ENUM and TLS, a private federation could decide to use the=20 > ENUM BCP but not the TLS BCP (because perhaps they have blue-=20 > wire security instead). >=20 > Of course, if that's not what was meant by any of this, then=20 > I'm at a loss too. >=20 > > And the open Internet is dealt with in RFC3263? >=20 > For viable open peering, more is probably needed than 3263. =20 > And here, I think SPEERMINT can say that open peering MUST=20 > have x, y, and z. For instance, open peering MUST use TLS. >=20 > > So what are we doing in Speermint? >=20 > That's how I understand it. If I've got it wrong, hopefully=20 > I'll be corrected. >=20 > -andy >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 10:07: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 1HgLgH-0001Ja-JR; Tue, 24 Apr 2007 10:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLgG-0001G7-FU for speermint@ietf.org; Tue, 24 Apr 2007 10:07:44 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgLgE-0001JB-T9 for speermint@ietf.org; Tue, 24 Apr 2007 10:07:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 16:07:44 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E5C@oefeg-s04.oefeg.loc> In-Reply-To: <45AEC6EF95942140888406588E1A660201751AB7@PACDCEXCMB04.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: Acd+ONszwSga3WXZTZiCcqqe+LYe/ACBQ9gAAP+RinAAAMoihQBjUJFwACPriXAABlKDMAAA0Pig From: "Stastny Richard" To: "Livingood, Jason" , "Uzelac, Adam" , "Sukanta ganguly" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org Jason Maybe we are meaning the same anyway I do not have any idea why you think I mean with minimum requirements how many customers a SP may have I am talking about technical requirements or what you may call it. The IETF is defining protocols, some of them must be used and some may be used (SIP is full of options) Speermint does not develop protocols, but BCPs If we say that it is recommended that SP use TLS for interconnection I called this a minimum requirement. Maybe you call this something else My idea is that we select a group of "protocols" and "options" and recommend their usage. Richard > -----Original Message----- > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Tuesday, April 24, 2007 3:42 PM > To: Stastny Richard; Uzelac, Adam; Sukanta ganguly; speermint@ietf.org > Subject: RE: [Speermint] Re-making or Un-making the PSTN >=20 > I think you are misunderstanding what I am saying. Bi-lateral, > federated, and open are all IN SCOPE. >=20 > What is NOT in scope, IMHO, is what the "minimum requirements for an > administrative domain to be accepted in a federation" should be. >=20 > Why is this out of scope? It is a business issue - not a technology > standards issue. For example, XYZ Enterprise Federation Inc. may only > admit enterprises. And ABC Education Federation Inc. may only admit > universities. And RS Global Peering Exchange Inc. may only admit > service providers of 1M customers or greater. And JL Tiny Net > Federation Inc. may only admit small businesses and individual user > domains. How these federations choose to select/allow domains to > participate is the private business of those federations. >=20 > Jason >=20 > > -----Original Message----- > > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > > Sent: Tuesday, April 24, 2007 6:39 AM > > To: Livingood, Jason; Uzelac, Adam; Sukanta ganguly; > > speermint@ietf.org > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > > > Jason, > > > > Again, > > > > what are the minimum requirements for an adminstrative > > domain to be > > > > accepted in a federation? > > > > > > > > Richard > > > > > > Why isn't that the private business of a given federation and, > > > therefore, totally out of scope for the WG? > > > > Bi-lateral is out-of-scope > > Federation is out-of-scope > > And the open Internet is dealt with in RFC3263? > > > > So what are we doing in Speermint? > > > > Richard > > > > > -----Original Message----- > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > > > Sent: Monday, April 23, 2007 7:28 PM > > > To: Stastny Richard; Uzelac, Adam; Sukanta ganguly; > > speermint@ietf.org > > > Subject: RE: [Speermint] Re-making or Un-making the PSTN > > > > > > > > > > > > > -----Original Message----- > > > > Again, > > > > what are the minimum requirements for an adminstrative > > domain to be > > > > accepted in a federation? > > > > > > > > Richard > > > > > > Why isn't that the private business of a given federation and, > > > therefore, totally out of scope for the WG? > > > > > > Jason > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 10:17: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 1HgLpq-0006RV-Cj; Tue, 24 Apr 2007 10:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLpp-0006RO-5D for speermint@ietf.org; Tue, 24 Apr 2007 10:17:37 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgLpn-0004Ia-LR for speermint@ietf.org; Tue, 24 Apr 2007 10:17:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 16:17:37 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E5D@oefeg-s04.oefeg.loc> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceGYORhHWPJmazcRgm981AFxlPOqQAFvGwwAACzcwA= From: "Stastny Richard" To: "Michael Hammer \(mhammer\)" , "Andrew Newton" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: speermint@ietf.org, "Uzelac, Adam" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org >=20 > Geez, you guys need to get some fresh air and sunshine. Maybe you are right, or maybe we had too much sun ;-) >=20 > Whether the relationship between peers is bilateral or multilateral is > not that relevant. What is important is being able to discover whether > a potential peer has a relationship or not with you. The nature of the > relationship can be defined fully elsewhere, what is needed is the > toolset which allows the peers to do discovery and to connect in a > secure manner or not, as they see fit. I agree, maybe I should call my minimum requirements a toolset where the SP and federation may choose from. This is more general. >=20 > Some of these issues, such as billing and charging, are secondary. They > may or may not, and do so in different ways. The question is whether > there is a means of identifying what those various aspects are. Try > layering this. The underlying layer enables the exchange of policy > documents, irrespective of what is in the policy documents. Later, > someone can hash out the policies. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Tuesday, April 24, 2007 7:08 AM > > To: Stastny Richard > > Cc: Uzelac, Adam; Livingood,Jason; speermint@ietf.org > > Subject: Re: [Speermint] Re-making or Un-making the PSTN > > > > > > On Apr 24, 2007, at 6:38 AM, Stastny Richard wrote: > > > > > Bi-lateral is out-of-scope > > > Federation is out-of-scope > > > > If you mean these are out-of-scope based on Jason's comments > > about the minimum requirements being the private business of > > a federation, then perhaps you misunderstood the remark. > > SPEERMINT can still work on a set of BCPs for these > > relationships, from which private peering relationships can > > pick and choose. For instance, if SPEERMINT produces BCPs on > > ENUM and TLS, a private federation could decide to use the > > ENUM BCP but not the TLS BCP (because perhaps they have blue- > > wire security instead). > > > > Of course, if that's not what was meant by any of this, then > > I'm at a loss too. > > > > > And the open Internet is dealt with in RFC3263? > > > > For viable open peering, more is probably needed than 3263. > > And here, I think SPEERMINT can say that open peering MUST > > have x, y, and z. For instance, open peering MUST use TLS. > > > > > So what are we doing in Speermint? > > > > That's how I understand it. If I've got it wrong, hopefully > > I'll be corrected. > > > > -andy > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 10:20: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 1HgLsw-0007Qe-M3; Tue, 24 Apr 2007 10:20:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgLsu-0007QL-Vr for speermint@ietf.org; Tue, 24 Apr 2007 10:20:48 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgLst-00055X-O4 for speermint@ietf.org; Tue, 24 Apr 2007 10:20:48 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 10:20:40 -0400 id 01588179.462E1238.000054A0 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> References: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5114EAE6-95D0-4AAA-9114-8C1C73019256@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 10:20:39 -0400 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Apr 24, 2007, at 9:59 AM, Michael Hammer ((mhammer)) wrote: > Geez, you guys need to get some fresh air and sunshine. I can't argue with that. :) > Whether the relationship between peers is bilateral or multilateral is > not that relevant. What is important is being able to discover > whether > a potential peer has a relationship or not with you. The nature of > the > relationship can be defined fully elsewhere, what is needed is the > toolset which allows the peers to do discovery and to connect in a > secure manner or not, as they see fit. The use of the terms "bilateral" and "multilateral" are probably not sufficient to describe the relationships. By using those terms, I was speaking of pre-arranged peering relationships that are almost always centered around a contract being signed. In those cases, you can bet your bottom dollar that we know who the next-hop peer is. Discovery seems to be something that is more akin to the open model. Certainly, if we sign a contract to peer with another entity, we don't want to "discover" the policies of that agreement after the fact and via a daemon process. > Some of these issues, such as billing and charging, are secondary. > They > may or may not, and do so in different ways. The question is whether > there is a means of identifying what those various aspects are. Try > layering this. The underlying layer enables the exchange of policy > documents, irrespective of what is in the policy documents. Later, > someone can hash out the policies. Personally, I'm a little skeptical of policy discovery, and I think it is only applicable to open peering at best. But if there are people who believe it is workable, then I see no harm in attempting to do it. I do disagree with "someone can hash out the policies" later. I think we are best served by understanding what those policies are now. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 14:15: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 1HgPYF-00065G-So; Tue, 24 Apr 2007 14:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPYD-0005wx-Tj for speermint@ietf.org; Tue, 24 Apr 2007 14:15:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgPYC-0002cP-Jx for speermint@ietf.org; Tue, 24 Apr 2007 14:15:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2007 14:15:41 -0400 X-IronPort-AV: i="4.14,448,1170651600"; d="scan'208"; a="58502380:sNHT54414368" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3OIFe13027621; Tue, 24 Apr 2007 14:15:40 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3OIF7H1026459; Tue, 24 Apr 2007 18:15:40 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 14:15:35 -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 Subject: RE: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 14:15:30 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E302EE291B@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <5114EAE6-95D0-4AAA-9114-8C1C73019256@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Re-making or Un-making the PSTN Thread-Index: AceGe8efbFq9d5hiT8uhCwdy75sndgAH+vzg References: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> <5114EAE6-95D0-4AAA-9114-8C1C73019256@hxr.us> From: "Michael Hammer \(mhammer\)" To: "Andrew Newton" X-OriginalArrivalTime: 24 Apr 2007 18:15:35.0621 (UTC) FILETIME=[8DD97F50:01C7869C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3471; t=1177438540; x=1178302540; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mhammer@cisco.com; z=From:=20=22Michael=20Hammer=20\(mhammer\)=22=20 |Subject:=20RE=3A=20[Speermint]=20Re-making=20or=20Un-making=20the=20PSTN |Sender:=20 |To:=20=22Andrew=20Newton=22=20; bh=paoKozZX5rTw050UF/ZntlMJLc74ytZd3rwHsrikz40=; b=ysomk/mlroUSSwiWJrYTfv/tTz0PFSURTpJoSopAeoTXFZGOtSyhwJmmr2ygYfB56kHm68R7 tp8mk132oCSJ5vHqDHFYYo92sXMM0SS36+wntsHusfxx/lkiTUvG2qm/; Authentication-Results: rtp-dkim-2; header.From=mhammer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org =20 > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us]=20 > Sent: Tuesday, April 24, 2007 10:21 AM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; Uzelac, Adam; Livingood,Jason; speermint@ietf.org > Subject: Re: [Speermint] Re-making or Un-making the PSTN >=20 >=20 > On Apr 24, 2007, at 9:59 AM, Michael Hammer ((mhammer)) wrote: >=20 > > Geez, you guys need to get some fresh air and sunshine. >=20 > I can't argue with that. :) >=20 > > Whether the relationship between peers is bilateral or=20 > multilateral is=20 > > not that relevant. What is important is being able to discover=20 > > whether a potential peer has a relationship or not with you. The=20 > > nature of the relationship can be defined fully elsewhere, what is=20 > > needed is the toolset which allows the peers to do discovery and to=20 > > connect in a secure manner or not, as they see fit. >=20 > The use of the terms "bilateral" and "multilateral" are=20 > probably not sufficient to describe the relationships. By=20 > using those terms, I was speaking of pre-arranged peering=20 > relationships that are almost always centered around a=20 > contract being signed. In those cases, you can bet your=20 > bottom dollar that we know who the next-hop peer is. If the contract is between an association and a thousand peers that come and go (in business out of business), then at any given time you may not have complete knowledge of the set of peers with current contracts. You don't really care. You just want to know at setup time that they are valid, perhaps as proven by a current certificate and not on CRL. =20 > Discovery seems to be something that is more akin to the open=20 > model. =20 > Certainly, if we sign a contract to peer with another entity,=20 > we don't want to "discover" the policies of that agreement=20 > after the fact and via a daemon process. The contract and policies would be known in advance. But, you may be involved in several disjoint multilateral groups. So, you need to discover which group, and thus which policies and contract are in effect. It could also be that the same two peers belong to the same two multilateral groups and a choice is possible. =20 > > Some of these issues, such as billing and charging, are=20 > secondary. =20 > > They > > may or may not, and do so in different ways. The question=20 > is whether=20 > > there is a means of identifying what those various aspects=20 > are. Try=20 > > layering this. The underlying layer enables the exchange of policy=20 > > documents, irrespective of what is in the policy documents. Later,=20 > > someone can hash out the policies. >=20 > Personally, I'm a little skeptical of policy discovery, and I=20 > think it is only applicable to open peering at best. But if=20 > there are people who believe it is workable, then I see no=20 > harm in attempting to do it. I do disagree with "someone can=20 > hash out the policies" =20 > later. I think we are best served by understanding what=20 > those policies are now. I am not totally sure what "open" means, but I assume it has some ad-hoc nature that would require a man in the loop to make decisions, or perhaps the variable types are defined, but specific values not known until the policy advertisement tells you exactly what the per-minute charge would be to connect, for example. Mike >=20 >=20 > -andy >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 14: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 1HgQ0G-0005ep-4f; Tue, 24 Apr 2007 14:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgQ0E-0005eH-ST for speermint@ietf.org; Tue, 24 Apr 2007 14:44:38 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgQ0D-00074V-AD for speermint@ietf.org; Tue, 24 Apr 2007 14:44:38 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 14:44:30 -0400 id 01588374.462E500E.00001417 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E302EE291B@xmb-rtp-20b.amer.cisco.com> References: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> <5114EAE6-95D0-4AAA-9114-8C1C73019256@hxr.us> <072C5B76F7CEAB488172C6F64B30B5E302EE291B@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <068E841E-6AAF-43E0-9021-A92C253CAE4D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Speermint] Re-making or Un-making the PSTN Date: Tue, 24 Apr 2007 14:44:30 -0400 To: "Michael Hammer \"((mhammer))" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , "Livingood, Jason" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On Apr 24, 2007, at 2:15 PM, Michael Hammer ((mhammer)) wrote: > If the contract is between an association and a thousand peers that > come > and go (in business out of business), then at any given time you > may not > have complete knowledge of the set of peers with current > contracts. You > don't really care. You just want to know at setup time that they are > valid, perhaps as proven by a current certificate and not on CRL. That depends upon the multilateral relationship. I believe all the commercial ones require the use of their proxies or a common IP fabric, so something like TLS isn't necessary. If you are talking more about clubs, then yes. But I'm unaware of how big a problem it is for the Nantucket Women's League VSP Coalition to talk to the Fairbanks Youth Scouting VoIP Association. :) > The contract and policies would be known in advance. But, you may be > involved in several disjoint multilateral groups. So, you need to > discover which group, and thus which policies and contract are in > effect. It could also be that the same two peers belong to the > same two > multilateral groups and a choice is possible. Umm... yeah. I don't think any sane VSP would enter into a dynamically changing contractual agreement as you've described. That seems a little far fetched to me. As for choices between two peers, we do that today. It is a matter of local policy. > I am not totally sure what "open" means, but I assume it has some > ad-hoc > nature that would require a man in the loop to make decisions, or > perhaps the variable types are defined, but specific values not known > until the policy advertisement tells you exactly what the per-minute > charge would be to connect, for example. If it means a man-in-the-loop, then we might as well drop the idea. And per-minute charging means you signed a contract somewhere, which means it isn't open peering. -andy _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Apr 24 15:50: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 1HgR1b-0007q6-9W; Tue, 24 Apr 2007 15:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgR1W-0007pT-Rk; Tue, 24 Apr 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgR1W-0004OM-Ir; Tue, 24 Apr 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 89EEE32939; Tue, 24 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HgR1W-00017k-EL; Tue, 24 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-flows-02.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Routing Architecture Message Flows Author(s) : R. Penno, et al. Filename : draft-ietf-speermint-flows-02.txt Pages : 31 Date : 2007-4-24 This draft provides the message flows associated with the SPEERMINT, SIP Peering and Multimedia Interconnect, routing architecture. This document provides examples of many different message flows relative to varying peering scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-flows-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-flows-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-flows-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-24115732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-flows-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-flows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-24115732.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Tue Apr 24 15:50: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 1HgR2F-0000Dq-Vi; Tue, 24 Apr 2007 15:50:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgR21-00087h-6c; Tue, 24 Apr 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgR20-0003eO-OH; Tue, 24 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id A9008175E6; Tue, 24 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HgR1W-00017e-DA; Tue, 24 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 24 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-architecture-03.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : SPEERMINT Peering Architecture Author(s) : R. Penno, et al. Filename : draft-ietf-speermint-architecture-03.txt Pages : 19 Date : 2007-4-24 This document defines the SPEERMINT peering architecture, its functional components and peering interface functions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-speermint-architecture-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-speermint-architecture-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-24113659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-speermint-architecture-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-speermint-architecture-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-24113659.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint --NextPart-- From speermint-bounces@ietf.org Tue Apr 24 16:03: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 1HgREh-0002E0-L4; Tue, 24 Apr 2007 16:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgREg-00028j-Cf for speermint@ietf.org; Tue, 24 Apr 2007 16:03:38 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgREf-0007iW-34 for speermint@ietf.org; Tue, 24 Apr 2007 16:03:38 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 446514D271; Tue, 24 Apr 2007 22:03:36 +0200 (CEST) Date: Tue, 24 Apr 2007 22:03:36 +0200 From: Otmar Lendl To: Andrew Newton Subject: Re: [Speermint] Re-making or Un-making the PSTN Message-ID: <20070424200335.GA12422@nic.at> Mail-Followup-To: Otmar Lendl , Andrew Newton , "Michael Hammer ((mhammer))" , speermint@ietf.org, Stastny Richard , "Uzelac, Adam" , "Livingood, Jason" References: <32755D354E6B65498C3BD9FD496C7D46646E58@oefeg-s04.oefeg.loc> <5E978BF9-349E-4142-893D-045623B47C03@hxr.us> <072C5B76F7CEAB488172C6F64B30B5E302EE2728@xmb-rtp-20b.amer.cisco.com> <5114EAE6-95D0-4AAA-9114-8C1C73019256@hxr.us> <072C5B76F7CEAB488172C6F64B30B5E302EE291B@xmb-rtp-20b.amer.cisco.com> <068E841E-6AAF-43E0-9021-A92C253CAE4D@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <068E841E-6AAF-43E0-9021-A92C253CAE4D@hxr.us> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Stastny Richard , speermint@ietf.org, "Livingood, Jason" , "Uzelac, Adam" X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: speermint-bounces@ietf.org On 2007/04/24 20:04, Andrew Newton wrote: > On Apr 24, 2007, at 2:15 PM, Michael Hammer ((mhammer)) wrote: > Umm... yeah. I don't think any sane VSP would enter into a > dynamically changing contractual agreement as you've described. That > seems a little far fetched to me. My guess is that this depends a lot on the type of VSP: A commercial VoIP operator whose main business is dealing with termination fees vs. charges to customers may have completely different peering policies than a commercial enterprise VoIP installation which has no incentive to charge business partners for incoming calls. The former will be judicious with whom it wants to peer and under which terms. The latter will be rather open to incoming calls as long as it has assurances that abuse will be minimal and that the peering is of mutual benefit. /ol -- / Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 \ | nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H | \ http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg / _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint