From speermint-bounces@ietf.org Wed Jan 04 16:34:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGHP-00045r-O8; Wed, 04 Jan 2006 16:34:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGHO-00045m-J6 for speermint@megatron.ietf.org; Wed, 04 Jan 2006 16:34:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06391 for ; Wed, 4 Jan 2006 16:33:32 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuGMw-0003xp-4x for speermint@ietf.org; Wed, 04 Jan 2006 16:40:31 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k04LYZcu026450 for ; Wed, 4 Jan 2006 13:34:35 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k04LYZpI026449 for speermint@ietf.org; Wed, 4 Jan 2006 13:34:35 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 4 Jan 2006 13:34:35 -0800 From: David Meyer To: speermint@ietf.org Message-ID: <20060104213435.GA26442@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Speermint] testing 1 2 3 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="===============1210311424==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============1210311424== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline test --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDvD9rORgD1qCZ2KcRAuXpAKCDgP4EAVPBn0eZUZnmpTHk+3OOrACfdmqL 31HJC3dLdXPV6X5ebRRMlM8= =k1rM -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- --===============1210311424== 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 --===============1210311424==-- From speermint-bounces@ietf.org Thu Jan 05 09:43:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWKZ-0004F5-4Y; Thu, 05 Jan 2006 09:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWKX-0004Er-Mc for speermint@megatron.ietf.org; Thu, 05 Jan 2006 09:43:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22187 for ; Thu, 5 Jan 2006 09:41:49 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWQE-0004o2-Cq for speermint@ietf.org; Thu, 05 Jan 2006 09:48:59 -0500 Received: from [10.31.13.193] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k05EhWsx019506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2006 06:43:33 -0800 Message-ID: <43BD2FE5.3090108@shockey.us> Date: Thu, 05 Jan 2006 09:40:37 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: speermint@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Speermint] test 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org please ignore ... -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 12:46:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZBt-0002q1-G2; Thu, 05 Jan 2006 12:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuZBq-0002o7-5W; Thu, 05 Jan 2006 12:46:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16405; Thu, 5 Jan 2006 12:45:02 -0500 (EST) Received: from smartmx-04.inode.at ([213.229.60.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuZHS-0003rr-Tg; Thu, 05 Jan 2006 12:52:13 -0500 Received: from [81.223.16.194] (port=4591 helo=mah9.inode.at) by smartmx-04.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EuZBb-00024j-TE; Thu, 05 Jan 2006 18:46:04 +0100 Message-Id: <6.2.5.6.2.20060105183823.05668bd0@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2006 18:45:51 +0100 To: Richard Shockey , David Meyer From: Michael Haberler In-Reply-To: <43BC0917.4010901@shockey.us> References: <6.2.5.6.2.20051229161919.08110568@inode.at> <200512292231.RAA26485@ietf.org> <20060103234601.GA3434@1-4-5.net> <43BC0917.4010901@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-2A2DBA9 X-Spam-Score: 0.8 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org At 18:42 04.01.2006, Richard Shockey wrote: >David Meyer wrote: >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: >> >>>This is seems to be an excellent approach and I suggest we discuss it on the >>>list and close at the 65 IETF meeting in March. > > >This is a general question for the list in general. > >Presuming you could query a network for its VoIP peering policy. > >What data on terms and conditions of peering would one need to encapsulate? here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >_____________________________________________________________________________ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 13:40:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua29-0002Rk-CG; Thu, 05 Jan 2006 13:40:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eua27-0002Qq-2G; Thu, 05 Jan 2006 13:40:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24749; Thu, 5 Jan 2006 13:39:03 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eua7o-0005wt-Kb; Thu, 05 Jan 2006 13:46:15 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 05 Jan 2006 10:40:07 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05Ie6jt026177; Thu, 5 Jan 2006 10:40:07 -0800 (PST) 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.211); Thu, 5 Jan 2006 13:40:06 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 5 Jan 2006 13:40:05 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3EF39FB@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYSIClLAV0sSq29TFyYQ9QarFeRaQABze2A From: "Michael Hammer \(mhammer\)" To: "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 05 Jan 2006 18:40:06.0585 (UTC) FILETIME=[72CF4A90:01C61227] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Is this another way of asking if a domain can have only a single policy? Mike =20 > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Michael Haberler > Sent: Thursday, January 05, 2006 12:46 PM > To: Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org;=20 > voipeer@lists.uoregon.edu > Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing=20 > SIP PeeringPolicy >=20 > At 18:42 04.01.2006, Richard Shockey wrote: >=20 > >David Meyer wrote: > >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > >> > >>>This is seems to be an excellent approach and I suggest we=20 > discuss it=20 > >>>on the list and close at the 65 IETF meeting in March. > > > > > >This is a general question for the list in general. > > > >Presuming you could query a network for its VoIP peering policy. > > > >What data on terms and conditions of peering would one need=20 > to encapsulate? >=20 >=20 > here's what we could think of - terms and conditions=20 > basically come from the following four realms: >=20 > * Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS >=20 > * Contractual > - Do I need to sign a contract (with whomever) beforehand? >=20 > * Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. >=20 > * Financial > - No settlement? > - If yes, how. >=20 > Note that we are NOT proposing to auto-detect, auto-match=20 > this full gamut of policy elements - we need to finish this=20 > in time; auto-matching legal & regulatory aspects is out of=20 > scope for us. >=20 > Another general question is the following: Is the peering=20 > policy a function of the recipient's domain, or one of the=20 > full URI? In other words, is peering done one the domain=20 > level (and thus equal to all users ain that domain) or do we=20 > need to support policies which differ amongst users? >=20 >=20 > Michael Haberler > Otmar Lendl >=20 >=20 >=20 >=20 >=20 >=20 > >-- > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > >46000 Center Oak Plaza - Sterling, VA 20166 > >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > >ENUM +87810-13313-31331 > >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > >Fax: +1 815.333.1237 > > or > > > > ; =20 > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_____________________________________________________________ > __________ > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=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 Thu Jan 05 13:58:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaJG-0006NY-Ps; Thu, 05 Jan 2006 13:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaJE-0006MK-9J; Thu, 05 Jan 2006 13:58:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26726; Thu, 5 Jan 2006 13:56:44 -0500 (EST) Received: from smartmx-09.inode.at ([213.229.60.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaOw-0006da-MA; Thu, 05 Jan 2006 14:03:56 -0500 Received: from [81.223.16.194] (port=4643 helo=mah9.inode.at) by smartmx-09.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EuaJA-0003Hy-V5; Thu, 05 Jan 2006 19:57:57 +0100 Message-Id: <6.2.5.6.2.20060105195222.05bb4690@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2006 19:57:50 +0100 To: "Michael Hammer \(mhammer\)" From: Michael Haberler Subject: RE: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3EF39FB@xmb-rtp-20b.amer.ci sco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3EF39FB@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B1F139B X-Spam-Score: 2.2 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org At 19:40 05.01.2006, Michael Hammer \(mhammer\) wrote: >Is this another way of asking if a domain can have only a single policy? > >Mike no, it's the list of issues which we believe one would consider when defining a policy as per draft-lendl-sip-peering-policy-00.txt: - a policy is tacked onto a federation, be it explicit or ad-hoc - a domain may publish an arbitrary number of federations -Michael > > > > -----Original Message----- > > From: speermint-bounces@ietf.org > > [mailto:speermint-bounces@ietf.org] On Behalf Of Michael Haberler > > Sent: Thursday, January 05, 2006 12:46 PM > > To: Richard Shockey; David Meyer > > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; > > voipeer@lists.uoregon.edu > > Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing > > SIP PeeringPolicy > > > > At 18:42 04.01.2006, Richard Shockey wrote: > > > > >David Meyer wrote: > > >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: > > >> > > >>>This is seems to be an excellent approach and I suggest we > > discuss it > > >>>on the list and close at the 65 IETF meeting in March. > > > > > > > > >This is a general question for the list in general. > > > > > >Presuming you could query a network for its VoIP peering policy. > > > > > >What data on terms and conditions of peering would one need > > to encapsulate? > > > > > > here's what we could think of - terms and conditions > > basically come from the following four realms: > > > > * Technical > > - What SIP transport is required? _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 16:33:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euck9-00011W-6I; Thu, 05 Jan 2006 16:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucDn-0002hU-2T for speermint@megatron.ietf.org; Thu, 05 Jan 2006 16:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13992 for ; Thu, 5 Jan 2006 15:59:14 -0500 (EST) Message-Id: <200601052059.PAA13992@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EucJX-0003Wg-5O for speermint@ietf.org; Thu, 05 Jan 2006 16:06:27 -0500 Received: (qmail 26913 invoked by uid 510); 5 Jan 2006 16:14:41 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.34):. Processed in 0.858455 secs); 05 Jan 2006 21:14:41 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in 0.858455 secs Process 26908) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Thu, 05 Jan 2006 21:14:40 +0000 From: "Henry Sinnreich" To: "'Michael Haberler'" , "'Richard Shockey'" , "'David Meyer'" Date: Thu, 5 Jan 2006 15:00:17 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYSIioIHXyqa8jxTuysPakUOVRXywAFLqsw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.5.6.2.20060105183823.05668bd0@inode.at> X-Antivirus-MYDOMAIN-Message-ID: <113649568083526908@mail.pulver.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 05 Jan 2006 16:33:55 -0500 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org A scalable approach must include peering policies that can be matched without human intervention. Today, it is best effort QoS with no other strings attached. It will be interesting to see if it possible to have anything else better than best effort: Maybe some DSCP to start with. A DSCP for QoS may be a good start for interdomain VoIP. What other policies could be automated for matching by machines? I would avoid having a big registrar in the sky, other than DNS and ENUM, since otherwise we will be back to politics again. Besides: Everybody will want to be this registrar :-) Also known as a settlement house. We could end up with just as many settlement providers as there are VoIP islands. The latest count is 552 at http://www.myvoipprovider.com/ Starting with ENUM/DNS discovery as you have proposed and DiffServ between consenting peering VoIP providers would be a great accomplishment by this WG! Thanks, Henry -----Original Message----- From: Michael Haberler [mailto:mah@inode.at] Sent: Thursday, January 05, 2006 11:46 AM To: Richard Shockey; David Meyer Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at; speermint@ietf.org Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy At 18:42 04.01.2006, Richard Shockey wrote: >David Meyer wrote: >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: >> >>>This is seems to be an excellent approach and I suggest we discuss it on the >>>list and close at the 65 IETF meeting in March. > > >This is a general question for the list in general. > >Presuming you could query a network for its VoIP peering policy. > >What data on terms and conditions of peering would one need to encapsulate? here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >___________________________________________________________________________ __ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 16:33:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euck9-000120-Fm; Thu, 05 Jan 2006 16:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EucZY-0004ez-14; Thu, 05 Jan 2006 16:23:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21648; Thu, 5 Jan 2006 16:21:42 -0500 (EST) Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound2-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EucfH-00066h-Po; Thu, 05 Jan 2006 16:28:57 -0500 Received: from outbound2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-res-R.bigfish.com (Postfix) with ESMTP id 39B0816B5D6; Thu, 5 Jan 2006 21:22:15 +0000 (UTC) Received: from mail42-res-R.bigfish.com (unknown [172.18.16.1]) by outbound2-res.bigfish.com (Postfix) with ESMTP id 2E67A16B5EE; Thu, 5 Jan 2006 21:22:15 +0000 (UTC) Received: from mail42-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail42-res-R.bigfish.com (Postfix) with ESMTP id 22262884F96; Thu, 5 Jan 2006 21:22:15 +0000 (UTC) X-BigFish: V Received: by mail42-res (MessageSwitch) id 1136496108933617_30972; Thu, 5 Jan 2006 21:21:48 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail42-res.bigfish.com (Postfix) with ESMTP id C143F86844E; Thu, 5 Jan 2006 21:21:48 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id k05LLm93025802; Thu, 5 Jan 2006 15:21:48 -0600 (CST) Received: from plswg01a.ad.sprint.com (PLSWG01A.corp.sprint.com [10.214.11.47]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k05LLlx14210; Thu, 5 Jan 2006 15:21:47 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg01a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 15:21:47 -0600 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: Thu, 5 Jan 2006 15:20:58 -0600 Message-ID: <978886E57CC1D64EAFAC157B98E36F9E03B63E41@PLSWB08C.ad.sprint.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIehxht7gcx+xTzSKmNLqj2eyDwAGvdaQ From: "Khan, Sohel Q [CTO]" To: "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 05 Jan 2006 21:21:47.0727 (UTC) FILETIME=[092415F0:01C6123E] X-Spam-Score: 0.8 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 05 Jan 2006 16:33:55 -0500 Cc: enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org =20 We also need to address: how does a mobile user enjoy the outcome of his home admin-domain policy when the he is visiting a foreign admin-domain that implements a different policy. -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler Sent: Thursday, January 05, 2006 11:46 AM To: Richard Shockey; David Meyer Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at; speermint@ietf.org Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; =20 ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >_______________________________________________________________________ >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html ________________________________________________________________________ _____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 16:56:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eud5z-0007Vq-J5; Thu, 05 Jan 2006 16:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eud5v-0007V0-EB; Thu, 05 Jan 2006 16:56:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27692; Thu, 5 Jan 2006 16:55:10 -0500 (EST) Received: from smartmx-03.inode.at ([213.229.60.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EudBd-0008BY-9T; Thu, 05 Jan 2006 17:02:24 -0500 Received: from [81.223.16.194] (port=4816 helo=mah9.inode.at) by smartmx-03.inode.at with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Eud5j-0001pR-Ar; Thu, 05 Jan 2006 22:56:15 +0100 Message-Id: <6.2.5.6.2.20060105222928.05bce9c0@inode.at> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Jan 2006 22:56:02 +0100 To: "Khan, Sohel Q [CTO]" , "Richard Shockey" , "David Meyer" From: Michael Haberler In-Reply-To: <978886E57CC1D64EAFAC157B98E36F9E03B63E41@PLSWB08C.ad.sprin t.com> References: <978886E57CC1D64EAFAC157B98E36F9E03B63E41@PLSWB08C.ad.sprint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B1F139B X-Spam-Score: 0.8 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: enum@ietf.org, speermint@ietf.org, voipeer@lists.uoregon.edu Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org At 22:20 05.01.2006, Khan, Sohel Q [CTO] wrote: > >We also need to address: how does a mobile user enjoy the outcome of his >home admin-domain policy when the he is visiting a foreign admin-domain >that implements a different policy. Sohel, we're just having very modest goals here - addressing the basic problem of interworking between ITAD's represented by SIP domains without assuming the whole world runs open URIs, with acceptable management load and in finite time (this year, that is). The GSM association is a quite good example for a federation, which sets rules for traffic between their members. Why dont you guys just go for that and be done? I understand that IMS roaming is a bit of a home-grown challenge but I would be very hesitant to take on fixing it on the plate in this working group. We need to sort this out though wether that's in scope - what is the WG opinion here? -Michael >-----Original Message----- >From: owner-voipeer@lists.uoregon.edu >[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler >Sent: Thursday, January 05, 2006 11:46 AM >To: Richard Shockey; David Meyer >Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; >lendl@nic.at; speermint@ietf.org >Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > >here's what we could think of - terms and conditions basically come >from the following four realms: > >* Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS > >* Contractual > - Do I need to sign a contract (with whomever) beforehand? > >* Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. > >* Financial > - No settlement? > - If yes, how. > >Note that we are NOT proposing to auto-detect, auto-match this full >gamut of policy elements - we need to finish this in time; auto-matching >legal & regulatory aspects is out of scope for us. > >Another general question is the following: Is the peering policy a >function of the recipient's domain, or one of the full URI? In other >words, is peering done one the domain level (and thus equal to all users >ain that domain) or do we need to support policies which differ amongst >users? > > >Michael Haberler >Otmar Lendl > > > > > > > >-- > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. > >46000 Center Oak Plaza - Sterling, VA 20166 > >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com > >ENUM +87810-13313-31331 > >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 > >Fax: +1 815.333.1237 > > or > > > > ; > ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >_______________________________________________________________________ > >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > >________________________________________________________________________ >_____ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 18:06:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueC4-0004sm-Vi; Thu, 05 Jan 2006 18:06:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueC2-0004sD-7n; Thu, 05 Jan 2006 18:06:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07006; Thu, 5 Jan 2006 18:05:34 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EueHn-0002Uj-HU; Thu, 05 Jan 2006 18:12:48 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Fri, 6 Jan 2006 00:10:21 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4751@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYSIehxht7gcx+xTzSKmNLqj2eyDwAGvdaQAAPUvsA= From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-Spam-Score: 0.8 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, voipeer@lists.uoregon.edu 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org =20 >We also need to address: how does a mobile user enjoy the outcome of = his >home admin-domain policy when the he is visiting a foreign admin-domain >that implements a different policy. First someone needs to explain to me what "visiting a foreign domain" means on the public Internet. I always register with my home domain. I may use a different access, but I am always contacted via my home domain, using my home profile. I would consider it very strange if e.g. the Mariott in New York where I = am currently connected would screen my incoming calls depending on THEIR = policy Richard ________________________________ Von: speermint-bounces@ietf.org im Auftrag von Khan, Sohel Q [CTO] Gesendet: Do 05.01.2006 22:20 An: Michael Haberler; Richard Shockey; David Meyer Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; = voipeer@lists.uoregon.edu Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = PeeringPolicy We also need to address: how does a mobile user enjoy the outcome of his home admin-domain policy when the he is visiting a foreign admin-domain that implements a different policy. -----Original Message----- From: owner-voipeer@lists.uoregon.edu [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler Sent: Thursday, January 05, 2006 11:46 AM To: Richard Shockey; David Meyer Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; lendl@nic.at; speermint@ietf.org Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >_______________________________________________________________________ >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html ________________________________________________________________________ _____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ 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 Jan 05 18:17:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueM0-0001aT-PT; Thu, 05 Jan 2006 18:17:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EueLy-0001Zl-Jl; Thu, 05 Jan 2006 18:17:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08564; Thu, 5 Jan 2006 18:15:51 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EueRk-0002tr-MS; Thu, 05 Jan 2006 18:23:05 -0500 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 Date: Fri, 6 Jan 2006 00:20:50 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4 From: "Stastny Richard" To: "Michael Haberler" , "Richard Shockey" , "David Meyer" X-Spam-Score: 0.8 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, voipeer@lists.uoregon.edu Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org >Another general question is the following: Is the peering policy a >function of the recipient's domain, or one of the full URI? In other >words, is peering done one the domain level (and thus equal to all >users ain that domain) or do we need to support policies which differ = amongst >users? This is a very interesting point I am considering since some time. Basically the final decision which calls one wants to accept is an end-users decision. If I as an end-user decide to accept a call from anybody, this is my decision. The policy in the lendl I-D is only for the whole domain, a policy on a single URI level is possible here only by giving always the weakest policy, which would be the "." and = therefore useless. On the other hand, with ENUM a policy for a single E.164 number=20 would be possible. Any ideas how to extend this to URIs? Richard ________________________________ Von: enum-bounces@ietf.org im Auftrag von Michael Haberler Gesendet: Do 05.01.2006 18:45 An: Richard Shockey; David Meyer Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; lendl@nic.at; = voipeer@lists.uoregon.edu Betreff: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy At 18:42 04.01.2006, Richard Shockey wrote: >David Meyer wrote: >>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote: >> >>>This is seems to be an excellent approach and I suggest we discuss it = on the >>>list and close at the 65 IETF meeting in March. > > >This is a general question for the list in general. > >Presuming you could query a network for its VoIP peering policy. > >What data on terms and conditions of peering would one need to = encapsulate? here's what we could think of - terms and conditions basically come from the following four realms: * Technical - What SIP transport is required? - SIP extensions? URI conventions? Privacy? Caller-ID? - Anti SPIT measures. - QoS * Contractual - Do I need to sign a contract (with whomever) beforehand? * Regulatory - Is a certain legal status required? E.g. only registered Communication Service Providers may initiate calls. - E.g. sender must conform to local CALEA or other rules. * Financial - No settlement? - If yes, how. Note that we are NOT proposing to auto-detect, auto-match this full gamut of policy elements - we need to finish this in time; auto-matching legal & regulatory aspects is out of scope for us. Another general question is the following: Is the peering policy a function of the recipient's domain, or one of the full URI? In other words, is peering done one the domain level (and thus equal to all users ain that domain) or do we need to support policies which differ = amongst users? Michael Haberler Otmar Lendl >-- > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >Richard Shockey, Director - Member of Technical Staff >NeuStar Inc. >46000 Center Oak Plaza - Sterling, VA 20166 >sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >ENUM +87810-13313-31331 >PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >Fax: +1 815.333.1237 > or > > ; ><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >________________________________________________________________________= _____ >List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 18:36:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eueey-0007Ra-Ng; Thu, 05 Jan 2006 18:36:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eueev-0007R3-92; Thu, 05 Jan 2006 18:36:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11087; Thu, 5 Jan 2006 18:35:25 -0500 (EST) Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Euekb-0003au-0H; Thu, 05 Jan 2006 18:42:36 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id 4EB7F78420; Thu, 5 Jan 2006 23:35:47 +0000 (GMT) In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4751@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4751@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: lconroy Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 5 Jan 2006 23:35:54 +0000 To: "Stastny Richard" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.8 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "Khan, Sohel Q \[CTO\]" , 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Hi Richard, folks, ... but, then again, the Marriot doesn't charge you to receive calls. When looking at IMS, I am reminded of the following quote: "In C++ it's harder to shoot yourself in the foot, but when you do, =20 you blow off your whole leg." =97 Bjarne Stroustrup. Re. the draft - which is what this thread WAS about... IMO, it's an excellent start - lots of fixmes, but a solid base on =20 which to build. As mentioned by others, I also wonder about whether or not a domain =20 is the atomic level for a particular federated policy. This SEEMs to be =20 appropriate, but I can't picture every possible scenario. I AM reminded of the discussion a few years back on the phone context =20= for the tel: URL. At least for SIP peering as discussed in the draft, one may have =20= a simpler problem to solve, and SIP does use a domain as an atomic element: One is going to talk to a server, and through SRVs and the whacky =20 load-balancing NAPTRs, that/those server(s) claim to be authoritative for that =20 domain's SIP processing, so I think it/they will apply a consistent policy ***FOR =20 PEERING***. This is different from an individual recipient's policies; I would =20 assume that executing those policies is a job for the end user (or his/her agent). IMHO, executing Individual policies is way out of scope for ENUM, and =20= speermint, and anything else that is dealing purely with peering. If that =20 Individual's device has registered with a different domain, then it's no surprise if a =20 different policy is applied. Peering had better work on IMS, or GSMA have not been doing their job =20= - either way, how is this the IETF's problem? all the best & happy new year, Lawrence On 5 Jan 2006, at 23:10, Stastny Richard wrote: >> We also need to address: how does a mobile user enjoy the outcome =20 >> of his >> home admin-domain policy when the he is visiting a foreign admin-=20 >> domain >> that implements a different policy. > > First someone needs to explain to me what "visiting a foreign domain" > means on the public Internet. > > I always register with my home domain. I may use a different access, > but I am always contacted via my home domain, using my home profile. > > I would consider it very strange if e.g. the Mariott in New York =20 > where I am > currently connected would screen my incoming calls depending on =20 > THEIR policy > > Richard > > > ________________________________ > > Von: speermint-bounces@ietf.org im Auftrag von Khan, Sohel Q [CTO] > Gesendet: Do 05.01.2006 22:20 > An: Michael Haberler; Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; =20 > voipeer@lists.uoregon.edu > Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP =20 > PeeringPolicy > > > > > We also need to address: how does a mobile user enjoy the outcome =20 > of his > home admin-domain policy when the he is visiting a foreign admin-=20 > domain > that implements a different policy. > > > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler > Sent: Thursday, January 05, 2006 11:46 AM > To: Richard Shockey; David Meyer > Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; > lendl@nic.at; speermint@ietf.org > Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > > here's what we could think of - terms and conditions basically come > from the following four realms: > > * Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS > > * Contractual > - Do I need to sign a contract (with whomever) beforehand? > > * Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. > > * Financial > - No settlement? > - If yes, how. > > Note that we are NOT proposing to auto-detect, auto-match this full > gamut of policy elements - we need to finish this in time; auto-=20 > matching > legal & regulatory aspects is out of scope for us. > > Another general question is the following: Is the peering policy a > function of the recipient's domain, or one of the full URI? In other > words, is peering done one the domain level (and thus equal to all =20 > users > ain that domain) or do we need to support policies which differ =20 > amongst > users? > > > Michael Haberler > Otmar Lendl > > > > > > >> -- >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >> ENUM +87810-13313-31331 >> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >> Fax: +1 815.333.1237 >> or >> >> ; >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> _____________________________________________________________________=20= >> __ >> ______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > ______________________________________________________________________=20= > __ > _____ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 19:21:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufMi-0004Pg-Dq; Thu, 05 Jan 2006 19:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufMf-0004PV-Hf; Thu, 05 Jan 2006 19:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17336; Thu, 5 Jan 2006 19:20:35 -0500 (EST) Received: from h139-142-184-176.roothosts.com ([139.142.184.176] helo=wodka.aus-biz.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EufSO-0005oV-SB; Thu, 05 Jan 2006 19:27:50 -0500 Received: from [192.168.1.101] (cpe-24-95-54-117.columbus.res.rr.com [24.95.54.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Duane Groth", Issuer "CAcert Class 3 Root" (not verified)) by wodka.aus-biz.com (Postfix) with ESMTP id 7028CE872; Thu, 5 Jan 2006 19:21:25 -0500 (EST) Message-ID: <43BDB7B9.2050902@e164.org> Date: Thu, 05 Jan 2006 19:20:09 -0500 From: Duane User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Stastny Richard wrote: > On the other hand, with ENUM a policy for a single E.164 number > would be possible. > > Any ideas how to extend this to URIs? most things in NAPTR are similar to: x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+HTTP" "!.*!HTTP://www.example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+MAILTO" "!.*!MAILTO:user@example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+ADDRESS" "!.*!ADDRESS:/CN=Fred Smith/STREET=123 Xyz St/L=Bedrock/ST=RA/C=Gondwana Land/PC=123456789!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+SIP" "!^\\+13609681666$!sip:user@example.com!" . Wouldn't be hard to do something like this, but incorporate the end users connection preferences similar to the document posted earlier. -- Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 19:29:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufTZ-0007ZJ-K9; Thu, 05 Jan 2006 19:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufTX-0007ZA-3x for speermint@megatron.ietf.org; Thu, 05 Jan 2006 19:28:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17718 for ; Thu, 5 Jan 2006 19:27:43 -0500 (EST) Message-Id: <200601060027.TAA17718@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EufZJ-00060F-LO for speermint@ietf.org; Thu, 05 Jan 2006 19:34:58 -0500 Received: (qmail 20208 invoked by uid 510); 5 Jan 2006 19:43:08 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(24.1.142.34):. Processed in 1.188403 secs); 06 Jan 2006 00:43:08 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(24.1.142.34):. Processed in 1.188403 secs Process 20203) Received: from c-24-1-142-34.hsd1.tx.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@24.1.142.34) by 192.246.69.184 with SMTP; Fri, 06 Jan 2006 00:43:07 +0000 From: "Henry Sinnreich" To: "'lconroy'" , "'Stastny Richard'" Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 5 Jan 2006 18:28:46 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYSUs4JEzQvKJE/R/2tsF0GO47V2wABRKRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Antivirus-MYDOMAIN-Message-ID: <113650818783520203@mail.pulver.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, "'Khan, Sohel Q \[CTO\]'" , speermint@ietf.org X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org >Peering had better work on IMS, or GSMA have not been doing their job >- either way, >how is this the IETF's problem? Correct! I believe this sums it up. Thanks, Henry -----Original Message----- From: lconroy [mailto:lconroy@insensate.co.uk] Sent: Thursday, January 05, 2006 5:36 PM To: Stastny Richard Cc: Khan, Sohel Q [CTO]; Michael Haberler; Richard Shockey; David Meyer; enum@ietf.org; Henry Sinnreich; speermint@ietf.org; voipeer@lists.uoregon.edu Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Hi Richard, folks, ... but, then again, the Marriot doesn't charge you to receive calls. When looking at IMS, I am reminded of the following quote: "In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." - Bjarne Stroustrup. Re. the draft - which is what this thread WAS about... IMO, it's an excellent start - lots of fixmes, but a solid base on which to build. As mentioned by others, I also wonder about whether or not a domain is the atomic level for a particular federated policy. This SEEMs to be appropriate, but I can't picture every possible scenario. I AM reminded of the discussion a few years back on the phone context for the tel: URL. At least for SIP peering as discussed in the draft, one may have a simpler problem to solve, and SIP does use a domain as an atomic element: One is going to talk to a server, and through SRVs and the whacky load-balancing NAPTRs, that/those server(s) claim to be authoritative for that domain's SIP processing, so I think it/they will apply a consistent policy ***FOR PEERING***. This is different from an individual recipient's policies; I would assume that executing those policies is a job for the end user (or his/her agent). IMHO, executing Individual policies is way out of scope for ENUM, and speermint, and anything else that is dealing purely with peering. If that Individual's device has registered with a different domain, then it's no surprise if a different policy is applied. Peering had better work on IMS, or GSMA have not been doing their job - either way, how is this the IETF's problem? all the best & happy new year, Lawrence On 5 Jan 2006, at 23:10, Stastny Richard wrote: >> We also need to address: how does a mobile user enjoy the outcome >> of his >> home admin-domain policy when the he is visiting a foreign admin- >> domain >> that implements a different policy. > > First someone needs to explain to me what "visiting a foreign domain" > means on the public Internet. > > I always register with my home domain. I may use a different access, > but I am always contacted via my home domain, using my home profile. > > I would consider it very strange if e.g. the Mariott in New York > where I am > currently connected would screen my incoming calls depending on > THEIR policy > > Richard > > > ________________________________ > > Von: speermint-bounces@ietf.org im Auftrag von Khan, Sohel Q [CTO] > Gesendet: Do 05.01.2006 22:20 > An: Michael Haberler; Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; > voipeer@lists.uoregon.edu > Betreff: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP > PeeringPolicy > > > > > We also need to address: how does a mobile user enjoy the outcome > of his > home admin-domain policy when the he is visiting a foreign admin- > domain > that implements a different policy. > > > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Michael Haberler > Sent: Thursday, January 05, 2006 11:46 AM > To: Richard Shockey; David Meyer > Cc: Henry Sinnreich; voipeer@lists.uoregon.edu; enum@ietf.org; > lendl@nic.at; speermint@ietf.org > Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > > here's what we could think of - terms and conditions basically come > from the following four realms: > > * Technical > - What SIP transport is required? > - SIP extensions? URI conventions? Privacy? Caller-ID? > - Anti SPIT measures. > - QoS > > * Contractual > - Do I need to sign a contract (with whomever) beforehand? > > * Regulatory > - Is a certain legal status required? E.g. only registered > Communication Service Providers may initiate calls. > - E.g. sender must conform to local CALEA or other rules. > > * Financial > - No settlement? > - If yes, how. > > Note that we are NOT proposing to auto-detect, auto-match this full > gamut of policy elements - we need to finish this in time; auto- > matching > legal & regulatory aspects is out of scope for us. > > Another general question is the following: Is the peering policy a > function of the recipient's domain, or one of the full URI? In other > words, is peering done one the domain level (and thus equal to all > users > ain that domain) or do we need to support policies which differ > amongst > users? > > > Michael Haberler > Otmar Lendl > > > > > > >> -- >> >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. >> 46000 Center Oak Plaza - Sterling, VA 20166 >> sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com >> ENUM +87810-13313-31331 >> PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 >> Fax: +1 815.333.1237 >> or >> >> ; >> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> _____________________________________________________________________ >> __ >> ______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > ______________________________________________________________________ > __ > _____ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > > > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www1.ietf.org/mailman/listinfo/speermint > > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 05 19:38:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eufcq-0002ML-5J; Thu, 05 Jan 2006 19:38:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EufUf-0007rF-0U; Thu, 05 Jan 2006 19:30:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17784; Thu, 5 Jan 2006 19:28:52 -0500 (EST) Received: from mail126.messagelabs.com ([216.82.254.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EufaL-00061l-SN; Thu, 05 Jan 2006 19:36:07 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-14.tower-126.messagelabs.com!1136507386!11656473!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17460 invoked from network); 6 Jan 2006 00:29:49 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-126.messagelabs.com with SMTP; 6 Jan 2006 00:29:49 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 43AED14A000FB57D; Thu, 5 Jan 2006 19:29:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jan 2006 18:29:44 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170DE0C005@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSV1rh5iTjPd0wRYqV54ZwVCzzSQAAIBfw From: "Dolly, Martin C" To: "Duane" , "Stastny Richard" X-Spam-Score: 0.6 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Thu, 05 Jan 2006 19:38:34 -0500 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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="===============1902185569==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1902185569== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61258.4A769CFF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61258.4A769CFF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 I was curious, being there is so much marketing advertising (via links) = on these e-mail lists, whether I can put a plug in for my brothers = printing businsess, or is that the line where this e-amil list draws the = line between technical versus "other" on this list? =20 Cheers, =20 Martin -----Original Message----- From: owner-voipeer@lists.uoregon.edu = [mailto:owner-voipeer@lists.uoregon.edu]On Behalf Of Duane Sent: Thursday, January 05, 2006 7:20 PM To: Stastny Richard Cc: Michael Haberler; Richard Shockey; David Meyer; enum@ietf.org; Henry = Sinnreich; speermint@ietf.org; lendl@nic.at; voipeer@lists.uoregon.edu Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Stastny Richard wrote: > On the other hand, with ENUM a policy for a single E.164 number=20 > would be possible. >=20 > Any ideas how to extend this to URIs? most things in NAPTR are similar to: x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+HTTP"=20 "!.*!HTTP://www.example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+MAILTO"=20 "!.*!MAILTO: user@example.com!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+ADDRESS"=20 "!.*!ADDRESS:/CN=3DFred Smith/STREET=3D123 Xyz = St/L=3DBedrock/ST=3DRA/C=3DGondwana=20 Land/PC=3D123456789!" . x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" "E2U+SIP"=20 "!^\\ +13609681666$!sip: user@example.com!" . Wouldn't be hard to do something like this, but incorporate the end=20 users connection preferences similar to the document posted earlier. --=20 Best regards, Duane http://www.cacert.org - Free Security Certificates http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://happysnapper.com.au - Sell your photos over the net! http://e164.org - Using Enum.164 to interconnect asterisk servers "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." _________________________________________________________________________= ____ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html ------_=_NextPart_001_01C61258.4A769CFF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering = Policy
Hello,
 
I was=20 curious, being there is so much marketing advertising (via links) on = these=20 e-mail lists, whether I can put a plug in for my brothers printing = businsess, or=20 is that the line where this e-amil list draws the line between technical = versus=20 "other" on this list?
 
Cheers,
 
Martin
-----Original Message-----
From:=20 owner-voipeer@lists.uoregon.edu = [mailto:owner-voipeer@lists.uoregon.edu]On=20 Behalf Of Duane
Sent: Thursday, January 05, 2006 7:20=20 PM
To: Stastny Richard
Cc: Michael Haberler; = Richard=20 Shockey; David Meyer; enum@ietf.org; Henry Sinnreich; = speermint@ietf.org;=20 lendl@nic.at; voipeer@lists.uoregon.edu
Subject: Re: [Enum] = RE:=20 [voipeer] I-D: Publishing SIP Peering = Policy

Stastny=20 Richard wrote:

> On the other hand, with ENUM a policy for a = single=20 E.164 number
> would be possible.
>
> Any ideas = how to=20 extend this to URIs?

most things in NAPTR are similar=20 to:

x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" = "E2U+HTTP"=20
"!.*!HTTP://www.example.com!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. = 600 IN=20 NAPTR 100 10 "u" "E2U+MAILTO"
"!.*!MAILTO:user@example.com!"=20 .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN NAPTR 100 10 "u" = "E2U+ADDRESS"=20
"!.*!ADDRESS:/CN=3DFred Smith/STREET=3D123 Xyz = St/L=3DBedrock/ST=3DRA/C=3DGondwana=20
Land/PC=3D123456789!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN = NAPTR 100=20 10 "u" "E2U+SIP"
"!^\\+13609681666$!sip:user@example.com!" = .

Wouldn't be=20 hard to do something like this, but incorporate the end
users = connection=20 preferences similar to the document posted earlier.

-- =

Best=20 regards,
Duane

http://www.cacert.org - Free = Security=20 Certificates
http://www.nodedb.com -=20 Think globally, network locally
http://www.sydneywireless.com = -=20 Telecommunications Freedom
http://happysnapper.com.au - = Sell your=20 photos over the net!
http://e164.org - Using=20 Enum.164 to interconnect asterisk servers

"In the long run the=20 pessimist may be proved right,
but the optimist has a better time = on the=20 = trip."
_______________________________________________________________= ______________
List=20 Archive: http://darkwing.uor= egon.edu/~llynch/voipeer/
User=20 Tools: http://darkwing= .uoregon.edu/~llynch/voipeer.html
= ------_=_NextPart_001_01C61258.4A769CFF-- --===============1902185569== 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 --===============1902185569==-- From speermint-bounces@ietf.org Fri Jan 06 12:32:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvRd-0006pt-CM; Fri, 06 Jan 2006 12:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuvRa-0006n7-JE; Fri, 06 Jan 2006 12:32:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16716; Fri, 6 Jan 2006 12:30:46 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuvXW-0000UC-GN; Fri, 06 Jan 2006 12:38:10 -0500 Received: from ([10.20.62.13]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16105273; Fri, 06 Jan 2006 12:31:22 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 Jan 2006 12:31:21 -0500 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: Fri, 6 Jan 2006 12:31:20 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39D6A@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZA= From: "Livingood, Jason" To: "Stastny Richard" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 06 Jan 2006 17:31:21.0922 (UTC) FILETIME=[02BB6A20:01C612E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org > >Another general question is the following: Is the peering policy a=20 > >function of the recipient's domain, or one of the full URI? In other=20 > >words, is peering done one the domain level (and thus equal to all=20 > >users ain that domain) or do we need to support policies=20 > which differ=20 > >amongst users? >=20 > This is a very interesting point I am considering since some time. >=20 > Basically the final decision which calls one wants to accept=20 > is an end-users decision. If I as an end-user decide to=20 > accept a call from anybody, this is my decision. The policy=20 > in the lendl I-D is only for the whole domain, a policy on a=20 > single URI level is possible here only by giving always the=20 > weakest policy, which would be the "." and therefore useless. (BTW, have not read this I-D in full yet.) In a given domain you could have several service types, differentiated perhaps by using sub-domains. Each of these may have differing QoS expectations, costs, and associated peering policies. Seems like it is whatever is to the right of the @ in the URI. In the same way that you associate certain resource records for a domain and different ones for each sub-domain -- control of which can be delegated out, say to an enterprise, then you could presumably do the same here. (I'd leave examination of the user portion of the URI, to the left of the @ sign, to the application that answers the callflow rather than burdening the DNS with such complexity, as with email where you find MX records in the DNS and the SMTP server looks at the user name and determines proper treatment once a message is received.) For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations:=20 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) I like the discussion so far... Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 06 13:03:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euvw2-00024Q-Ol; Fri, 06 Jan 2006 13:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euvw1-00024I-KU for speermint@megatron.ietf.org; Fri, 06 Jan 2006 13:03:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18791 for ; Fri, 6 Jan 2006 13:02:13 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Euw1w-0001P5-7C for speermint@ietf.org; Fri, 06 Jan 2006 13:09:37 -0500 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 Date: Fri, 6 Jan 2006 19:07:07 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4759@oefeg-s04.oefeg.loc> Thread-Topic: Publishing SIP Peering Policy and user provided URIs Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZAAAaa3kw== From: "Stastny Richard" To: "Livingood, Jason" , "Michael Haberler" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: speermint@ietf.org Subject: [Speermint] Publishing SIP Peering Policy and user provided URIs 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org We should not forget the equivalent of "number portability", which is user provided URIs within the context of the peering policy.=20 Especially companies will like to keep their domain for SIP URIs like for e-mail, even if the SIP service is provided by a service provider e.g. IP centrex. =20 What is the proposed way to implement this? =20 e.g a company wants to keep sip:foo@company.com hosted by a service provider sip:foo@provider.net =20 Richard ________________________________ Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Gesendet: Fr 06.01.2006 18:31 An: Stastny Richard; Michael Haberler; Richard Shockey; David Meyer Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; lendl@nic.at Betreff: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > >Another general question is the following: Is the peering policy a > >function of the recipient's domain, or one of the full URI? In other > >words, is peering done one the domain level (and thus equal to all > >users ain that domain) or do we need to support policies > which differ > >amongst users? > > This is a very interesting point I am considering since some time. > > Basically the final decision which calls one wants to accept > is an end-users decision. If I as an end-user decide to > accept a call from anybody, this is my decision. The policy > in the lendl I-D is only for the whole domain, a policy on a > single URI level is possible here only by giving always the > weakest policy, which would be the "." and therefore useless. (BTW, have not read this I-D in full yet.) In a given domain you could have several service types, differentiated perhaps by using sub-domains. Each of these may have differing QoS expectations, costs, and associated peering policies. Seems like it is whatever is to the right of the @ in the URI. In the same way that you associate certain resource records for a domain and different ones for each sub-domain -- control of which can be delegated out, say to an enterprise, then you could presumably do the same here. (I'd leave examination of the user portion of the URI, to the left of the @ sign, to the application that answers the callflow rather than burdening the DNS with such complexity, as with email where you find MX records in the DNS and the SMTP server looks at the user name and determines proper treatment once a message is received.) For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations: 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) I like the discussion so far... Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 06 13:18:04 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwA8-00073v-3N; Fri, 06 Jan 2006 13:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwA6-00073V-HZ for speermint@megatron.ietf.org; Fri, 06 Jan 2006 13:18:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19792 for ; Fri, 6 Jan 2006 13:16:46 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwG2-0001qE-JL for speermint@ietf.org; Fri, 06 Jan 2006 13:24:10 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Jan 2006 10:17:51 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,339,1131350400"; d="scan'208"; a="19156919:sNHT24896034" 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 k06IHSJx011214; Fri, 6 Jan 2006 13:17:48 -0500 (EST) 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.211); Fri, 6 Jan 2006 13:17:37 -0500 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] Publishing SIP Peering Policy and user provided URIs Date: Fri, 6 Jan 2006 13:17:27 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3EF3D70@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] Publishing SIP Peering Policy and user provided URIs Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZAAAaa3kwAAX5dQ From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Livingood, Jason" , "Michael Haberler" X-OriginalArrivalTime: 06 Jan 2006 18:17:37.0901 (UTC) FILETIME=[795831D0:01C612ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Can we back up one and ask where is this URI coming from? My initial reaction to the question below is that the URI of the target and the URI of the routing hop may be two different things and contained in two different SIP message elements, e.g. Request-URI v. Route URI. Is there a mental architectural picture behind this that has not been described yet? BTW, the use of sub-domain vice just saying domains below helps address the confusion of my earlier question that was hinting at the need for some discriminator for identifying policies when more than one exists per domain. Mike > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Stastny Richard > Sent: Friday, January 06, 2006 1:07 PM > To: Livingood, Jason; Michael Haberler > Cc: speermint@ietf.org > Subject: [Speermint] Publishing SIP Peering Policy and user=20 > provided URIs >=20 > We should not forget the equivalent of "number portability",=20 > which is user provided URIs within the context of the peering policy.=20 > Especially companies will like to keep their domain for SIP=20 > URIs like for e-mail, even if the SIP service is provided by=20 > a service provider e.g. IP centrex. > =20 > What is the proposed way to implement this? > =20 > e.g a company wants to keep sip:foo@company.com hosted by a=20 > service provider sip:foo@provider.net > =20 > Richard >=20 > ________________________________ >=20 > Von: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Gesendet: Fr 06.01.2006 18:31 > An: Stastny Richard; Michael Haberler; Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; lendl@nic.at > Betreff: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >=20 >=20 >=20 > > >Another general question is the following: Is the peering policy a=20 > > >function of the recipient's domain, or one of the full=20 > URI? In other=20 > > >words, is peering done one the domain level (and thus equal to all=20 > > >users ain that domain) or do we need to support policies > > which differ > > >amongst users? > > > > This is a very interesting point I am considering since some time. > > > > Basically the final decision which calls one wants to accept is an=20 > > end-users decision. If I as an end-user decide to accept a=20 > call from=20 > > anybody, this is my decision. The policy in the lendl I-D=20 > is only for=20 > > the whole domain, a policy on a single URI level is=20 > possible here only=20 > > by giving always the weakest policy, which would be the "." and=20 > > therefore useless. >=20 > (BTW, have not read this I-D in full yet.) >=20 > In a given domain you could have several service types,=20 > differentiated perhaps by using sub-domains. Each of these=20 > may have differing QoS expectations, costs, and associated=20 > peering policies. Seems like it is whatever is to the right=20 > of the @ in the URI. In the same way that you associate=20 > certain resource records for a domain and different ones for=20 > each sub-domain -- control of which can be delegated out, say=20 > to an enterprise, then you could presumably do the same here.=20 > (I'd leave examination of the user portion of the URI, to=20 > the left of the @ sign, to the application that answers the=20 > callflow rather than burdening the DNS with such complexity,=20 > as with email where you find MX records in the DNS and the=20 > SMTP server looks at the user name and determines proper=20 > treatment once a message is received.) For example even=20 > within a domain you may want a few sub-domains and these may=20 > well have very different associated policies, and security=20 > and QoS expectations: >=20 > 12159817813@foo.bar > - general flat-rate consumer voip service >=20 > 12159817600@smb.foo.bar > - small-medium sized business voip, may involve=20 > IP-PBXs as endpoints, whatever >=20 > 12159817601@enterprise.foo.bar > - enterprise customers with higher QoS expectations >=20 > 12159817602@free.foo.bar > - free im & voip application service with=20 > best-efforts QoS (meaning no QoS) >=20 > I like the discussion so far... >=20 > Jason >=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 Jan 06 13:20:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwCa-0007kc-Su; Fri, 06 Jan 2006 13:20:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuwCY-0007k1-U4; Fri, 06 Jan 2006 13:20:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19977; Fri, 6 Jan 2006 13:19:18 -0500 (EST) Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuwIT-0001uu-W9; Fri, 06 Jan 2006 13:26:43 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com; Fri, 6 Jan 2006 13:19:35 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006010613193432410 ; Fri, 06 Jan 2006 13:19:34 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Fri, 6 Jan 2006 13:19:34 -0500 Message-Id: <84E5D7F15F52D34DA84C9C90ACE6554F622BEF@0591-its-exmp01.us.saic.com> From: "Roy, Radhika R." To: "Livingood, Jason" , Stastny Richard , Michael Haberler , Richard Shockey , David Meyer Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peer ingPolicy Date: Fri, 6 Jan 2006 13:19:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: enum@ietf.org, 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="===============0630440676==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0630440676== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C612ED.B6EAE4AB" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C612ED.B6EAE4AB Content-Type: text/plain; charset="iso-8859-1" Please see inline [RRR]. For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations: 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) [RRR] Domain name cannot be associated with any specific services per URL/URI standards. It is true that a domain may have many sub-domains. [RRR] Certain other mechanisms need to be found out to associate with services, NOT directly in domain name URLs/URIs. ------_=_NextPart_001_01C612ED.B6EAE4AB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = PeeringPolicy

Please see inline [RRR].

For example even within a domain

you may want a few sub-domains and these may well have very = different

associated policies, and security and QoS expectations: =

12159817813@foo.bar

        - general flat-rate consumer voip = service

12159817600@smb.foo.bar

        - small-medium sized business voip, = may involve IP-PBXs as

endpoints, whatever

12159817601@enterprise.foo.bar

        - enterprise customers with higher = QoS expectations

12159817602@free.foo.bar

        - free im & voip application = service with best-efforts QoS

(meaning no QoS)

[RRR]  Domain name cannot = be associated with any specific services per URL/URI = standards. It is true that a domain may have many = sub-domains.

[RRR] Certain other mechanisms need to be found out to = associate with services, NOT directly in domain name = URLs/URIs. =

------_=_NextPart_001_01C612ED.B6EAE4AB-- --===============0630440676== 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 --===============0630440676==-- From speermint-bounces@ietf.org Sun Jan 08 23:28:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvoeN-0000OU-1c; Sun, 08 Jan 2006 23:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvoeK-0000Nd-Fd; Sun, 08 Jan 2006 23:28:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13432; Sun, 8 Jan 2006 23:27:33 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Evoki-0007HI-R5; Sun, 08 Jan 2006 23:35:31 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k094SMj13582; Sun, 8 Jan 2006 23:28:22 -0500 (EST) 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 Date: Sun, 8 Jan 2006 23:28:19 -0500 Message-ID: Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZAAbPS90A== From: "James McEachern" To: "Livingood, Jason" , "Stastny Richard" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I'm not sure I follow this completely, but it seems to suggest that an = enterprise customer would not be able to get high quality when making a = call (inter-domain) to someone who subscribed to "general flat-rate = consumer voip" - even if the enterprise user was making the call, and = willing to pay for it. This seems counter-intuitive to me. Jim=20 -----Original Message----- From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On Behalf Of = Livingood, Jason Sent: Friday, January 06, 2006 12:31 PM (BTW, have not read this I-D in full yet.) In a given domain you could have several service types, differentiated perhaps by using sub-domains. Each of these may have differing QoS expectations, costs, and associated peering policies. Seems like it is whatever is to the right of the @ in the URI. In the same way that you associate certain resource records for a domain and different ones for each sub-domain -- control of which can be delegated out, say to an enterprise, then you could presumably do the same here. (I'd leave examination of the user portion of the URI, to the left of the @ sign, to the application that answers the callflow rather than burdening the DNS with such complexity, as with email where you find MX records in the DNS and the SMTP server looks at the user name and determines proper treatment once a message is received.) For example even within a domain you may want a few sub-domains and these may well have very different associated policies, and security and QoS expectations:=20 12159817813@foo.bar - general flat-rate consumer voip service 12159817600@smb.foo.bar - small-medium sized business voip, may involve IP-PBXs as endpoints, whatever 12159817601@enterprise.foo.bar - enterprise customers with higher QoS expectations 12159817602@free.foo.bar - free im & voip application service with best-efforts QoS (meaning no QoS) I like the discussion so far... Jason _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 09 11:19:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evzk9-0006OR-JL; Mon, 09 Jan 2006 11:19:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evzk8-0006OG-Ar for speermint@megatron.ietf.org; Mon, 09 Jan 2006 11:19:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28592 for ; Mon, 9 Jan 2006 11:18:17 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvzqZ-0002Q7-BG for speermint@ietf.org; Mon, 09 Jan 2006 11:26:21 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 1DFD91A488; Mon, 9 Jan 2006 17:19:04 +0100 (CET) Date: Mon, 9 Jan 2006 17:19:04 +0100 From: Otmar Lendl To: Stastny Richard Message-ID: <20060109161904.GG9002@nic.at> References: <32755D354E6B65498C3BD9FD496C7D462C4759@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4759@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: speermint@ietf.org, "Livingood, Jason" Subject: [Speermint] Re: Publishing SIP Peering Policy and user provided URIs 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org On 2006/01/06 19:01, Stastny Richard wrote: > We should not forget the equivalent of "number portability", which > is user provided URIs within the context of the peering policy. > Especially companies will like to keep their domain for SIP > URIs like for e-mail, even if the SIP service is provided by a > service provider e.g. IP centrex. > > What is the proposed way to implement this? > > e.g a company wants to keep sip:foo@company.com > hosted by a service provider sip:foo@provider.net > This is a very valid question. There certainly will be a SRV entry in the customer's domain which points to the sip-proxy of the provider. (Just as in the email case the MX records have to point to the provider's mail-servers.) As the draft stands now, the SIP peering NAPTRs inside the customer's domain need to mirror those of the provider's domain. This is indeed inconvenient as any change in the peering policy triggers an update in all customer domains. We see three possible ways to solve this: a) The DDDS way: Instead of company.com. IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:domainkeys!" . the NAPTR in the customer's domain use non-terminal NAPTRs to refer the querying sip-server to the entries of the provider. e.g. something like this: company.com. IN NAPTR 20 50 "n" "D2P+SIP" "" provider.net. provider.net. IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:domainkeys!" . b) Go the route the SPF (for email, the marid WG) took: Define some "include" mechanism which tells the querier to recurse to some other domain and merge the entries found there with the one found in this domain. c) Don't take the domain of the SIP uri, but the one of the SIP proxy as determined by a RFC 3263 - NAPTRs or SRV lookups. ---- I think a) is a the best choice. Comments? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 09 12:36:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0x0-000739-PU; Mon, 09 Jan 2006 12:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew0wx-0006x1-Vg; Mon, 09 Jan 2006 12:36:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05873; Mon, 9 Jan 2006 12:35:36 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew13T-0005Nc-Ib; Mon, 09 Jan 2006 12:43:42 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id DBEB81A488; Mon, 9 Jan 2006 18:36:43 +0100 (CET) Date: Mon, 9 Jan 2006 18:36:43 +0100 From: Otmar Lendl To: Stastny Richard Message-ID: <20060109173643.GA15301@nic.at> Mail-Followup-To: Otmar Lendl , Stastny Richard , Michael Haberler , Richard Shockey , David Meyer , enum@ietf.org, Henry Sinnreich , speermint@ietf.org, voipeer@lists.uoregon.edu References: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4752@oefeg-s04.oefeg.loc> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, speermint@ietf.org Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org [I will stop crossposting to the voipeer and enum@ietf lists, IMHO this belongs to the speermint list.] On 2006/01/06 00:01, Stastny Richard wrote: > >Another general question is the following: Is the peering policy a > >function of the recipient's domain, or one of the full URI? In other > >words, is peering done one the domain level (and thus equal to all > >users ain that domain) or do we need to support policies which differ amongst > >users? > > This is a very interesting point I am considering since some time. > > Basically the final decision which calls one wants to accept is an > end-users decision. If I as an end-user decide to accept a call from > anybody, this is my decision. The policy in the lendl I-D is only > for the whole domain, a policy on a single URI level is possible here > only by giving always the weakest policy, which would be the "." and therefore > useless. Right now in the PSTN, we have peering policies on a carrier-level and individual per-subscriber policies as well. E.g. consider the various call-blocking feature US-based carriers have deployed over the last years to combat telemarketers and anonymous calls. As far as I know, such individual blocks are internal to a carrier and not announced to others. The same can be implemented in a SIP setting: The domain policies tell you that the destination network will talk to you over IP, but then there still is the option to block the call inside the destination network for any reason. The only new part here is that we might need an additional SIP error code indicating "I blocked this call, you might try some other route" (in contrast to "This user is not available at all") Such user-specific blocks could be implements purely on the user's SIP device. As Jason wrote, if you really want to run separate policies for a set of users for inter-provider routing, then you can use different domains. > On the other hand, with ENUM a policy for a single E.164 number > would be possible. Yes, but one design criteria was independence from E.164 numbers. The scheme needs to work in a pure SIP world as well. > Any ideas how to extend this to URIs? Do we really need to? In the email world this isn't done, too. All current protocols regarding proxy and transport selection for SIP are only based on the domain. I don't want to diverge from that model. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 09 13:20:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1cx-0002h7-TG; Mon, 09 Jan 2006 13:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew1cu-0002gK-4R for speermint@megatron.ietf.org; Mon, 09 Jan 2006 13:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09427 for ; Mon, 9 Jan 2006 13:18:56 -0500 (EST) Message-Id: <200601091818.NAA09427@ietf.org> Received: from mail.pulver.com ([192.246.69.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew1jR-0006uZ-Dc for speermint@ietf.org; Mon, 09 Jan 2006 13:27:01 -0500 Received: (qmail 27205 invoked by uid 510); 9 Jan 2006 13:35:35 -0500 Received: from henry@pulver.com by mail.pulver.com by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.72. spamassassin: 2.63. Clear:RC:1(67.187.111.112):. Processed in 0.880192 secs); 09 Jan 2006 18:35:35 -0000 X-Antivirus-MYDOMAIN-Mail-From: henry@pulver.com via mail.pulver.com X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(67.187.111.112):. Processed in 0.880192 secs Process 27199) Received: from c-67-187-111-112.hsd1.wa.comcast.net (HELO 1AB764895C324D3) (henry@pulver.com@67.187.111.112) by 192.246.69.184 with SMTP; Mon, 09 Jan 2006 18:35:34 +0000 From: "Henry Sinnreich" To: "'Otmar Lendl'" Date: Mon, 9 Jan 2006 12:19:37 -0600 Organization: pulver.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYVRXNrHjJG2MNVSEqjMWgcqdsOSQAAGprg In-Reply-To: <20060109173643.GA15301@nic.at> X-Antivirus-MYDOMAIN-Message-ID: <113683173483527199@mail.pulver.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: henry@pulver.com List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Otmar, You say: >All current protocols regarding proxy and transport selection for SIP >are only based on the domain. I don't want to diverge from that model. What business has the broadband provider to mess with the user preferences? Users and enterprises pay for a certain bandwidth and hopefully will have the choice to pay extra for Diff Serv and that's the end of it. If one domain has DiffServ and the other does not, it's up to the users to continue the call or switch over to some other networks, such as mobile or PSTN. And also to tell the other party to please subscribe to better broadband :-) What do you think? Thanks, Henry -----Original Message----- From: Otmar Lendl [mailto:lendl@nic.at] Sent: Monday, January 09, 2006 11:37 AM To: Stastny Richard Cc: Michael Haberler; Richard Shockey; David Meyer; enum@ietf.org; Henry Sinnreich; speermint@ietf.org; voipeer@lists.uoregon.edu Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy [I will stop crossposting to the voipeer and enum@ietf lists, IMHO this belongs to the speermint list.] On 2006/01/06 00:01, Stastny Richard wrote: > >Another general question is the following: Is the peering policy a > >function of the recipient's domain, or one of the full URI? In other > >words, is peering done one the domain level (and thus equal to all > >users ain that domain) or do we need to support policies which differ amongst > >users? > > This is a very interesting point I am considering since some time. > > Basically the final decision which calls one wants to accept is an > end-users decision. If I as an end-user decide to accept a call from > anybody, this is my decision. The policy in the lendl I-D is only > for the whole domain, a policy on a single URI level is possible here > only by giving always the weakest policy, which would be the "." and therefore > useless. Right now in the PSTN, we have peering policies on a carrier-level and individual per-subscriber policies as well. E.g. consider the various call-blocking feature US-based carriers have deployed over the last years to combat telemarketers and anonymous calls. As far as I know, such individual blocks are internal to a carrier and not announced to others. The same can be implemented in a SIP setting: The domain policies tell you that the destination network will talk to you over IP, but then there still is the option to block the call inside the destination network for any reason. The only new part here is that we might need an additional SIP error code indicating "I blocked this call, you might try some other route" (in contrast to "This user is not available at all") Such user-specific blocks could be implements purely on the user's SIP device. As Jason wrote, if you really want to run separate policies for a set of users for inter-provider routing, then you can use different domains. > On the other hand, with ENUM a policy for a single E.164 number > would be possible. Yes, but one design criteria was independence from E.164 numbers. The scheme needs to work in a pure SIP world as well. > Any ideas how to extend this to URIs? Do we really need to? In the email world this isn't done, too. All current protocols regarding proxy and transport selection for SIP are only based on the domain. I don't want to diverge from that model. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 09 17:17:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5Ka-00064h-Ne; Mon, 09 Jan 2006 17:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5KX-00062U-J0; Mon, 09 Jan 2006 17:17:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03279; Mon, 9 Jan 2006 17:16:12 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew5R3-00084y-1H; Mon, 09 Jan 2006 17:24:19 -0500 Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16162258; Mon, 09 Jan 2006 17:17:05 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 17:17:05 -0500 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: Mon, 9 Jan 2006 17:17:04 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A39DCE@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYSIIxivB/KLFp4Tdi7u73Kbrrf4wALLUt4ACXHqZAAbPS90AA0bcRQ From: "Livingood, Jason" To: "James McEachern" , "Stastny Richard" , "Michael Haberler" , "Richard Shockey" , "David Meyer" X-OriginalArrivalTime: 09 Jan 2006 22:17:05.0482 (UTC) FILETIME=[6C5452A0:01C6156A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org The items listed were for example purposes. I just wanted to illustrate that a provider may wish to vary VoIP peering policies by sub-domain rather than having just one policy at the domain level. I just listed quick examples for each sub-domain, segmented by some illustrative customer types (SMB, enterprise, consumer, etc.). And w/r/t my enterprise example, I actually meant to indicate that they had very high QoS expectations and policies, but no matter... ;-) Jason > -----Original Message----- > From: James McEachern [mailto:jmce@nortel.com]=20 > Sent: Sunday, January 08, 2006 11:28 PM > To: Livingood, Jason; Stastny Richard; Michael Haberler;=20 > Richard Shockey; David Meyer > Cc: enum@ietf.org; Henry Sinnreich; speermint@ietf.org; lendl@nic.at > Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >=20 > I'm not sure I follow this completely, but it seems to=20 > suggest that an enterprise customer would not be able to get=20 > high quality when making a call (inter-domain) to someone who=20 > subscribed to "general flat-rate consumer voip" - even if the=20 > enterprise user was making the call, and willing to pay for=20 > it. This seems counter-intuitive to me. >=20 > Jim=20 >=20 > -----Original Message----- > From: enum-bounces@ietf.org [mailto:enum-bounces@ietf.org] On=20 > Behalf Of Livingood, Jason > Sent: Friday, January 06, 2006 12:31 PM >=20 >=20 > (BTW, have not read this I-D in full yet.) >=20 > In a given domain you could have several service types,=20 > differentiated perhaps by using sub-domains. Each of these=20 > may have differing QoS expectations, costs, and associated=20 > peering policies. Seems like it is whatever is to the right=20 > of the @ in the URI. In the same way that you associate=20 > certain resource records for a domain and different ones for=20 > each sub-domain -- control of which can be delegated out, say=20 > to an enterprise, then you could presumably do the same here.=20 > (I'd leave examination of the user portion of the URI, to=20 > the left of the @ sign, to the application that answers the=20 > callflow rather than burdening the DNS with such complexity,=20 > as with email where you find MX records in the DNS and the=20 > SMTP server looks at the user name and determines proper=20 > treatment once a message is received.) For example even=20 > within a domain you may want a few sub-domains and these may=20 > well have very different associated policies, and security=20 > and QoS expectations:=20 >=20 > 12159817813@foo.bar > - general flat-rate consumer voip service >=20 > 12159817600@smb.foo.bar > - small-medium sized business voip, may involve IP-PBXs=20 > as endpoints, whatever >=20 > 12159817601@enterprise.foo.bar > - enterprise customers with higher QoS expectations >=20 > 12159817602@free.foo.bar > - free im & voip application service with best-efforts=20 > QoS (meaning no QoS) >=20 > I like the discussion so far... >=20 > Jason _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 09 18:05:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew65N-00057W-Er; Mon, 09 Jan 2006 18:05:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew65J-00055W-V3; Mon, 09 Jan 2006 18:05:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06374; Mon, 9 Jan 2006 18:04:34 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ew6Bt-000116-Ep; Mon, 09 Jan 2006 18:12:42 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 80B861A606; Tue, 10 Jan 2006 00:05:40 +0100 (CET) Date: Tue, 10 Jan 2006 00:05:40 +0100 From: Otmar Lendl To: Henry Sinnreich Message-ID: <20060109230539.GH9002@nic.at> Mail-Followup-To: Otmar Lendl , Henry Sinnreich , 'Michael Haberler' , 'Richard Shockey' , 'David Meyer' , enum@ietf.org, speermint@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' References: <20060109173643.GA15301@nic.at> <200601091820.k09IK6Wx049276@mx5.univie.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601091820.k09IK6Wx049276@mx5.univie.ac.at> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: enum@ietf.org, voipeer@lists.uoregon.edu, 'Stastny Richard' , speermint@ietf.org Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org On 2006/01/09 19:01, Henry Sinnreich wrote: > Otmar, > > You say: > > >All current protocols regarding proxy and transport selection for SIP > >are only based on the domain. I don't want to diverge from that model. > > What business has the broadband provider to mess with the user preferences? > Users and enterprises pay for a certain bandwidth and hopefully will have > the choice to pay extra for Diff Serv and that's the end of it. In an ideal world, yes. > If one domain has DiffServ and the other does not, it's up to the users to > continue the call or switch over to some other networks, such as mobile or > PSTN. And also to tell the other party to please subscribe to better > broadband :-) > > What do you think? > My problem with this idea is that "domain" in the sense of SIP-servers is an application layer notion. DiffServ is a layer 3 issue. My layer 3 network does not neccessarily know which applications I run over them. If my ISP also acts as my SIP provider, then yes: one can link these two layers into one integrated QoS solution. AFAIK this is one of the aims of the IMS. One of the local Austrian ISPs uses this for his VoIP service: they use separate VLANs/QoS planes for their VoIP offering. My private playground is quite different: I use an Asterisk installation on a box (the same one I write this mail on) colocated at ISP A whereas my SIP-phone at home is connected via ISP B. The gateway to the PSTN is operated by a commercial provider who uses ISP C. If you add my ENUM nameservers, you get one more ISP into the picture. To top it off, I could add a SIP line to my office phone which would bring our office connectivity into the game were we basically run own multihomed network. I really don't know how to get seamless QoS in such a setting. (As you mentioned before: layer3 networks can't just trust each other's DiffServ settings.) /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 11:41:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewj21-0002Jz-C3; Wed, 11 Jan 2006 11:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewj1z-0002Jj-SS for speermint@megatron.ietf.org; Wed, 11 Jan 2006 11:41:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25074 for ; Wed, 11 Jan 2006 11:39:43 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewj8q-00004u-0o for speermint@ietf.org; Wed, 11 Jan 2006 11:48:13 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 8D92E1A3D1; Wed, 11 Jan 2006 17:40:32 +0100 (CET) Date: Wed, 11 Jan 2006 17:40:32 +0100 From: Otmar Lendl To: speermint@ietf.org Message-ID: <20060111164032.GA28218@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Speermint] Revising draft-lendl-sip-peering-policy-00 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Based on the feedback I've received from the IETF lists (Thanks!) and local discussions, I plan restructure the SIP policy draft quite substantially. Before I really flesh things out I'd like to get some more feedback on whether I'm on the right path. This is the plan: * Split up the draft along similar lines as the ENUM RFC. A separate document containing the problem statement and defining the terminology would be really helpful to offload a lot of content. Who is be willing to co-author this one? * The first I-D will describe the general framework and the resolution algorithm. (This is the one similar to RFC 3761) I'm not quite sure yet whether to formulate it as a DDDS application or not. This I-D will define an algorithm on how to map an FQDN to a list of URI-sets and how to interpret those. The algorithm is close to the one described in draft-lendl-sip-peering-policy-00.txt: For the application protocol "SIP", do: 1) Get all NAPTR records residing in the input domain whose service field matches "D2P+SIP(:.*)?" and where the flag is either empty or "u". 2) If there is a record with an empty flag (""), then use the replacement field as the new input and recurse. 3) If no matching NAPTRs were found, revert to old rules. 4) Group (and sort) all NAPTRs found by "order". 5) Loop over these sets of NAPTR records (lowest order first): 5a) Evaluate the regex to get an URI for each NAPTR. 5b) Interpret each URI as a requirement according to the subsequent I-D which define sub-types for the service-field. Unknown sub-types are considered to be unfulfilled. 5c) If all requirements as defined by the NAPTRs of one set can be fulfilled then the algorithm terminates with a positive result. 6) If the algorithm arrives here then no connection is possible. NAPTRs according to this I-D must have either flag empty "" and contain a valid FQDN in the replacement field or flag "u" in which case the regexp must be of the form "!.*!!", i.e. always unconditionally map the input to an URI. This I-D must also (again similar to RFC3761) define how subsequent RFCs can specify the interpretation rules for new sup-types. * A second I-D describes NAPTRs defining federation memberships for this framework. It uses sub-type "federation", thus in the context of SIP peering we get "D2P+SIP:federation" as service field. As a change to the current draft, federations names are no longer FQDNs, but URIs. Thus we need a convention for those. (maybe urn:ietf:speermint:feds:XXXXX) Such a rule is fulfilled if the originating network is a member in the indicated federation. This I-D must also define the URI for the "Open Internet"- federation. (The set of RFC 3263 - compliant SIP-servers) * A third I-D defining technical restrictions. Sub-type is "tech", thus e.g. "D2P+SIP:tech". The URIs identify standards, e.g. RFCs: urn:ietf:rfc: (or whatever the official urn is) W3C: http://www.w3.org/2000/09/xmldsig#enveloped-signature I-Ds: http://www.ietf.org/internet-drafts/draft-ietf-XXXX.txt Any XML namespace registered by IANA [...] Such a policy rule is fulfilled if the sending network supports the referenced standard. * Fancy XML policy languages fit also nicely into this system, the SAML/XACML crowd could also define their subtype, e.g. "XACML". Thus a service field "D2P+SIP:XACML" would lead to a http: URL linking to the actual XACML rules document. Such an I-D needs to be clear how to construct the "Request" and "Context" objects to which these Rules are then applied. Comments? /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 12:07:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjRE-0002ED-EI; Wed, 11 Jan 2006 12:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjRD-0002E5-3X; Wed, 11 Jan 2006 12:07:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27020; Wed, 11 Jan 2006 12:05:47 -0500 (EST) 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 1EwjY9-0000zw-Om; Wed, 11 Jan 2006 12:14:18 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 11 Jan 2006 09:06:57 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0BH6iR2026991; Wed, 11 Jan 2006 09:06:56 -0800 (PST) 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.211); Wed, 11 Jan 2006 12:06:55 -0500 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: Wed, 11 Jan 2006 12:06:54 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYVcXSrzRNkn9vZQlyTqzaipt4R0wBXneKA From: "Michael Hammer \(mhammer\)" To: "Otmar Lendl" , "Henry Sinnreich" X-OriginalArrivalTime: 11 Jan 2006 17:06:55.0342 (UTC) FILETIME=[6CA5D0E0:01C616D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , speermint@ietf.org Subject: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org There MUST be some association of IP layer protocol elements to L5 traffic needs, such as low delay, packet loss etc. If the L5 need is real-time transmission, and that translates to a DSCP marking, then the IP network needs to meet that need one way or another or very simply the real-time service breaks. The alternative is that the peering always must include both L5 and L3 and you get a half-step instead of full-step in evolution from PSTN to IP. Put another way, is it really necessary to have L5 transit networks? If you insist that L3 always be paired with L5 for real-time, that is what you get. Mike > -----Original Message----- > From: owner-voipeer@lists.uoregon.edu=20 > [mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl > Sent: Monday, January 09, 2006 6:06 PM > To: Henry Sinnreich > Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer';=20 > enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu;=20 > 'Stastny Richard' > Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >=20 > On 2006/01/09 19:01, Henry Sinnreich wrote: > > Otmar, > >=20 > > You say: > >=20 > > >All current protocols regarding proxy and transport=20 > selection for SIP=20 > > >are only based on the domain. I don't want to diverge from=20 > that model. > >=20 > > What business has the broadband provider to mess with the=20 > user preferences? > > Users and enterprises pay for a certain bandwidth and=20 > hopefully will=20 > > have the choice to pay extra for Diff Serv and that's the end of it. >=20 > In an ideal world, yes. >=20 > > If one domain has DiffServ and the other does not, it's up to the=20 > > users to continue the call or switch over to some other=20 > networks, such=20 > > as mobile or PSTN. And also to tell the other party to please=20 > > subscribe to better broadband :-) > >=20 > > What do you think? > >=20 >=20 > My problem with this idea is that "domain" in the sense of=20 > SIP-servers is an application layer notion. >=20 > DiffServ is a layer 3 issue. My layer 3 network does not=20 > neccessarily know which applications I run over them. >=20 > If my ISP also acts as my SIP provider, then yes: one can=20 > link these two layers into one integrated QoS solution. AFAIK=20 > this is one of the aims of the IMS. One of the local Austrian=20 > ISPs uses this for his VoIP service: they use separate=20 > VLANs/QoS planes for their VoIP offering. >=20 > My private playground is quite different: I use an Asterisk=20 > installation on a box (the same one I write this mail on)=20 > colocated at ISP A whereas my SIP-phone at home is connected=20 > via ISP B. The gateway to the PSTN is operated by a=20 > commercial provider who uses ISP C. > If you add my ENUM nameservers, you get one more ISP into the picture. > To top it off, I could add a SIP line to my office phone=20 > which would bring our office connectivity into the game were=20 > we basically run own multihomed network. >=20 > I really don't know how to get seamless QoS in such a setting. >=20 > (As you mentioned before: layer3 networks can't just trust=20 > each other's DiffServ settings.) >=20 > /ol > -- > < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >=20 > ______________________________________________________________ > _______________ > List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 12:34:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewjs0-0004PL-N8; Wed, 11 Jan 2006 12:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewjrz-0004PA-8k; Wed, 11 Jan 2006 12:34:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29007; Wed, 11 Jan 2006 12:33:26 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewjyt-0001pp-Nk; Wed, 11 Jan 2006 12:41:58 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0BHYrx6013551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2006 09:34:54 -0800 Message-ID: <43C54193.3000202@shockey.us> Date: Wed, 11 Jan 2006 12:34:11 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" References: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, Stastny Richard , speermint@ietf.org Subject: [Speermint] Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then the > IP network needs to meet that need one way or another or very simply the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? If > you insist that L3 always be paired with L5 for real-time, that is what > you get. > > Mike > I dont disagree and this is exactly the point Dave Oran made in BC but I recall the general consensus in the room was that that specific problem was out of scope for speermint now but that the proposed solution should be able to accomodiate this requirement in the future. Which is why some form of general purpose XML based admission control mechanism seems interesting here. As part of that admission control protocol would be information on network state in order to permit the peering parties to judge whether interconnection ( under these terms at these points )is even possible. > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 12:47:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewk3o-00013K-LV; Wed, 11 Jan 2006 12:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewk3n-000133-Dy for speermint@megatron.ietf.org; Wed, 11 Jan 2006 12:46:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29705 for ; Wed, 11 Jan 2006 12:45:39 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwkAj-0002CA-AT for speermint@ietf.org; Wed, 11 Jan 2006 12:54:10 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0BHlQgL015156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2006 09:47:28 -0800 Message-ID: <43C54483.1040904@shockey.us> Date: Wed, 11 Jan 2006 12:46:43 -0500 From: Richard Shockey User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Otmar Lendl Subject: Re: [Speermint] Revising draft-lendl-sip-peering-policy-00 References: <20060111164032.GA28218@nic.at> In-Reply-To: <20060111164032.GA28218@nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Otmar Lendl wrote: > Based on the feedback I've received from the IETF lists (Thanks!) > and local discussions, I plan restructure the SIP policy draft > quite substantially. > > Before I really flesh things out I'd like to get some more feedback on > whether I'm on the right path. > > This is the plan: > > * Split up the draft along similar lines as the ENUM RFC. > > A separate document containing the problem statement and > defining the terminology would be really helpful to offload > a lot of content. Who is be willing to co-author this one? I think the problem statement and current termonology draft could be merged. > > * The first I-D will describe the general framework and the > resolution algorithm. (This is the one similar to RFC 3761) > > I'm not quite sure yet whether to formulate it as a DDDS > application or not. I think you should. > > This I-D will define an algorithm on how to map an FQDN > to a list of URI-sets and how to interpret those. > > The algorithm is close to the one described in > draft-lendl-sip-peering-policy-00.txt: > > For the application protocol "SIP", do: > > 1) Get all NAPTR records residing in the input domain > whose service field matches "D2P+SIP(:.*)?" and where > the flag is either empty or "u". If you want define a new Enumservice field based on D2P vs E2U you will have to define this as a new DDDS. > > 2) If there is a record with an empty flag (""), then > use the replacement field as the new input and > recurse. Correct. > > 3) If no matching NAPTRs were found, revert to old rules. > > 4) Group (and sort) all NAPTRs found by "order". > > 5) Loop over these sets of NAPTR records (lowest order first): > > 5a) Evaluate the regex to get an URI for each NAPTR. > 5b) Interpret each URI as a requirement according to > the subsequent I-D which define sub-types for the > service-field. Unknown sub-types are considered > to be unfulfilled. > 5c) If all requirements as defined by the NAPTRs of one > set can be fulfilled then the algorithm terminates > with a positive result. > > 6) If the algorithm arrives here then no connection is possible. > > NAPTRs according to this I-D must have either flag empty "" > and contain a valid FQDN in the replacement field or flag "u" > in which case the regexp must be of the form "!.*!!", > i.e. always unconditionally map the input to an URI. > > This I-D must also (again similar to RFC3761) define how > subsequent RFCs can specify the interpretation rules for > new sup-types. > > * A second I-D describes NAPTRs defining federation memberships > for this framework. > > It uses sub-type "federation", thus in the context of SIP > peering we get "D2P+SIP:federation" as service field. just use D2P+sip:fed:(uritype) NAPTR records are getting large as it is. IN theory you can string out the enumservice field out as long as you need > > As a change to the current draft, federations names are > no longer FQDNs, but URIs. Thus we need a convention for > those. (maybe urn:ietf:speermint:feds:XXXXX) > > Such a rule is fulfilled if the originating network > is a member in the indicated federation. > > This I-D must also define the URI for the "Open Internet"- > federation. (The set of RFC 3263 - compliant SIP-servers) > > * A third I-D defining technical restrictions. > > Sub-type is "tech", thus e.g. "D2P+SIP:tech". tech:(URI) there may be more that one way to retrieve the same policy set as in ftp vs http etc. > > The URIs identify standards, e.g. > > RFCs: urn:ietf:rfc: (or whatever the official urn is) > W3C: http://www.w3.org/2000/09/xmldsig#enveloped-signature > I-Ds: http://www.ietf.org/internet-drafts/draft-ietf-XXXX.txt > Any XML namespace registered by IANA > [...] > > Such a policy rule is fulfilled if the sending network supports the > referenced standard. > > * Fancy XML policy languages fit also nicely into this system, the > SAML/XACML crowd could also define their subtype, e.g. "XACML". http:xacml IMHO > > Thus a service field "D2P+SIP:XACML" would lead to a > http: URL linking to the actual XACML rules document. > > Such an I-D needs to be clear how to construct the "Request" and > "Context" objects to which these Rules are then applied. > > Comments? > > /ol -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 13:02:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkIo-0005QH-H1; Wed, 11 Jan 2006 13:02:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwkIm-0005Q9-Az; Wed, 11 Jan 2006 13:02:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00826; Wed, 11 Jan 2006 13:01:05 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwkPe-0002eD-7l; Wed, 11 Jan 2006 13:09:37 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k0BHwIV10056; Wed, 11 Jan 2006 12:58:18 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 13:01:54 -0500 Received: from [127.0.0.1] ([47.130.16.144] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 13:01:53 -0500 Message-ID: <43C5480B.4080906@nortel.com> Date: Wed, 11 Jan 2006 13:01:47 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5F5B0@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 18:01:54.0048 (UTC) FILETIME=[1AD46800:01C616D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: enum@ietf.org, voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org The MSF is defining a scenario they hope to demonstrate, where media paths cross different domains from signalling. The signalling may be of the form visited originating network - home originating network - home terminating network - visited terminating network. This typical scenario is an obvious example of L5 transit. Then the media path is optimized to run directly between the visited networks, possibly by way of a different transit network offering QoS based on diffserv markings at the egress points of the visited networks. L5 and L3 are linked in the originating and terminating visited networks, but not in between. Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then the > IP network needs to meet that need one way or another or very simply the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? If > you insist that L3 always be paired with L5 for real-time, that is what > you get. > > Mike > > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > > _______________________________________________ > 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 Jan 11 13:42:47 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewkvn-00081j-2Z; Wed, 11 Jan 2006 13:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewkvl-00081C-HV; Wed, 11 Jan 2006 13:42:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02763; Wed, 11 Jan 2006 13:41:25 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ewl2g-0003dE-KY; Wed, 11 Jan 2006 13:49:57 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Wed, 11 Jan 2006 19:46:09 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C476A@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYW2apwuUX7HvisSN++NFgJzGXxcwABNBJ9 From: "Stastny Richard" To: "Tom-PT Taylor" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: enum@ietf.org, speermint@ietf.org, voipeer@lists.uoregon.edu 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Again =20 Can anybody please explain to me what the term "visited" originating or = terminating network means on L5 =20 Both end-users are registered at their respective home networks (aka SIP servers). I always thought the SIP model is a trapezoid and=20 not a hexagon =20 QoS happens at or below L3 and should be negotiated by the end-user with his acces provider. =20 Richard ________________________________ Von: Tom-PT Taylor [mailto:taylor@nortel.com] Gesendet: Mi 11.01.2006 19:01 An: Michael Hammer (mhammer) Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; = voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = Peering Policy The MSF is defining a scenario they hope to demonstrate, where media paths cross different domains from signalling. The signalling may be of the form visited originating network - home originating network - home terminating network - visited terminating network. This typical scenario is an obvious example of L5 transit. Then the media path is optimized to run directly between the visited networks, possibly by way of a different transit network offering QoS based on diffserv markings at the egress points of the visited networks. L5 and L3 are linked in the originating and terminating visited networks, but not in between. Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then = the > IP network needs to meet that need one way or another or very simply = the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of = full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? = If > you insist that L3 always be paired with L5 for real-time, that is = what > you get. > > Mike > > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > > _______________________________________________ > 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 Jan 11 14:12:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlOh-0000WH-W6; Wed, 11 Jan 2006 14:12:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwlOf-0000WC-Jx for speermint@megatron.ietf.org; Wed, 11 Jan 2006 14:12:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04548 for ; Wed, 11 Jan 2006 14:11:16 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwlVb-0004TO-2k for speermint@ietf.org; Wed, 11 Jan 2006 14:19:49 -0500 Received: from zcarhxp0.corp.nortel.com (zcarhxp0.corp.nortel.com [47.129.230.91]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0BJC3i00384; Wed, 11 Jan 2006 14:12:04 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 14:12:03 -0500 Received: from [127.0.0.1] ([47.130.16.144] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 14:12:03 -0500 Message-ID: <43C5587D.8030004@nortel.com> Date: Wed, 11 Jan 2006 14:11:57 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <32755D354E6B65498C3BD9FD496C7D462C476A@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C476A@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 19:12:03.0149 (UTC) FILETIME=[E7A63FD0:01C616E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org I have no problem explaining this term. One example might be if I were trying to make a call from within my corporate network (the visited originating network), through my service provider (the home originating network), etc. To get out of my corporate network my client locates a SIP proxy in that network, which then forwards the call to the peering point of my service provider (which has a relationship with my corporate network that allows this to happen). I'm sure other examples come to mind. Stastny Richard wrote: > Again > > Can anybody please explain to me what the term "visited" originating or terminating > network means on L5 > > Both end-users are registered at their respective home networks > (aka SIP servers). I always thought the SIP model is a trapezoid and > not a hexagon > > QoS happens at or below L3 and should be negotiated by > the end-user with his acces provider. > > Richard > > ________________________________ > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Mi 11.01.2006 19:01 > An: Michael Hammer (mhammer) > Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > > > > The MSF is defining a scenario they hope to demonstrate, where media > paths cross different domains from signalling. The signalling may be of > the form visited originating network - home originating network - home > terminating network - visited terminating network. This typical > scenario is an obvious example of L5 transit. Then the media path is > optimized to run directly between the visited networks, possibly by way > of a different transit network offering QoS based on diffserv markings > at the egress points of the visited networks. > > L5 and L3 are linked in the originating and terminating visited > networks, but not in between. > > Michael Hammer (mhammer) wrote: > >>There MUST be some association of IP layer protocol elements to L5 >>traffic needs, such as low delay, packet loss etc. If the L5 need is >>real-time transmission, and that translates to a DSCP marking, then the >>IP network needs to meet that need one way or another or very simply the >>real-time service breaks. The alternative is that the peering always >>must include both L5 and L3 and you get a half-step instead of full-step >>in evolution from PSTN to IP. >> >>Put another way, is it really necessary to have L5 transit networks? If >>you insist that L3 always be paired with L5 for real-time, that is what >>you get. >> >>Mike >> >> >> >> >>>-----Original Message----- >>>From: owner-voipeer@lists.uoregon.edu >>>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>>Sent: Monday, January 09, 2006 6:06 PM >>>To: Henry Sinnreich >>>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>>'Stastny Richard' >>>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >>> >>>On 2006/01/09 19:01, Henry Sinnreich wrote: >>> >>> >>>>Otmar, >>>> >>>>You say: >>>> >>>> >>>> >>>>>All current protocols regarding proxy and transport >>> >>>selection for SIP >>> >>> >>>>>are only based on the domain. I don't want to diverge from >>> >>>that model. >>> >>> >>>>What business has the broadband provider to mess with the >>> >>>user preferences? >>> >>> >>>>Users and enterprises pay for a certain bandwidth and >>> >>>hopefully will >>> >>> >>>>have the choice to pay extra for Diff Serv and that's the end of it. >>> >>>In an ideal world, yes. >>> >>> >>> >>>>If one domain has DiffServ and the other does not, it's up to the >>>>users to continue the call or switch over to some other >>> >>>networks, such >>> >>> >>>>as mobile or PSTN. And also to tell the other party to please >>>>subscribe to better broadband :-) >>>> >>>>What do you think? >>>> >>> >>>My problem with this idea is that "domain" in the sense of >>>SIP-servers is an application layer notion. >>> >>>DiffServ is a layer 3 issue. My layer 3 network does not >>>neccessarily know which applications I run over them. >>> >>>If my ISP also acts as my SIP provider, then yes: one can >>>link these two layers into one integrated QoS solution. AFAIK >>>this is one of the aims of the IMS. One of the local Austrian >>>ISPs uses this for his VoIP service: they use separate >>>VLANs/QoS planes for their VoIP offering. >>> >>>My private playground is quite different: I use an Asterisk >>>installation on a box (the same one I write this mail on) >>>colocated at ISP A whereas my SIP-phone at home is connected >>>via ISP B. The gateway to the PSTN is operated by a >>>commercial provider who uses ISP C. >>>If you add my ENUM nameservers, you get one more ISP into the picture. >>>To top it off, I could add a SIP line to my office phone >>>which would bring our office connectivity into the game were >>>we basically run own multihomed network. >>> >>>I really don't know how to get seamless QoS in such a setting. >>> >>>(As you mentioned before: layer3 networks can't just trust >>>each other's DiffServ settings.) >>> >>>/ol >>>-- >>>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>>______________________________________________________________ >>>_______________ >>>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >>> >> >> >>_______________________________________________ >>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 Jan 11 14:55:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm4T-0002iE-SX; Wed, 11 Jan 2006 14:55:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm4S-0002g8-AB for speermint@megatron.ietf.org; Wed, 11 Jan 2006 14:55:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07708 for ; Wed, 11 Jan 2006 14:54:27 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmBP-0005dN-De for speermint@ietf.org; Wed, 11 Jan 2006 15:03:00 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k0BJtMP7018566; Wed, 11 Jan 2006 11:55:22 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k0BJtMY8018565; Wed, 11 Jan 2006 11:55:22 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 11 Jan 2006 11:55:22 -0800 From: David Meyer To: Richard Shockey Subject: Re: [Speermint] Revising draft-lendl-sip-peering-policy-00 Message-ID: <20060111195522.GA18508@1-4-5.net> References: <20060111164032.GA28218@nic.at> <43C54483.1040904@shockey.us> Mime-Version: 1.0 In-Reply-To: <43C54483.1040904@shockey.us> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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="===============0195688283==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============0195688283== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2006 at 12:46:43PM -0500, Richard Shockey wrote: > Otmar Lendl wrote: > >Based on the feedback I've received from the IETF lists (Thanks!) > >and local discussions, I plan restructure the SIP policy draft > >quite substantially. > > > >Before I really flesh things out I'd like to get some more feedback on > >whether I'm on the right path.=20 > > > >This is the plan: > > > >* Split up the draft along similar lines as the ENUM RFC.=20 > > > > A separate document containing the problem statement and > > defining the terminology would be really helpful to offload > > a lot of content. Who is be willing to co-author this one? >=20 > I think the problem statement and current termonology draft could be=20 > merged. Actually, that's not a bad idea. Omar? I can take a whack at that and post a revision of draft-...terminology if we find consensus to merge the problem statement with the terminology draft. > >* The first I-D will describe the general framework and the > > resolution algorithm. (This is the one similar to RFC 3761) > > > > I'm not quite sure yet whether to formulate it as a DDDS > > application or not. >=20 > I think you should. Again, not a bad idea. Dave --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDxWKqORgD1qCZ2KcRAsh5AJ4z0QO2jUXTpH2aR9AojRLiWbfg3QCfdkqh Qa4L4dh3FSI0eTA5GUB0ZKk= =qOlW -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- --===============0195688283== 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 --===============0195688283==-- From speermint-bounces@ietf.org Wed Jan 11 14:59:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm7o-0004Nq-2j; Wed, 11 Jan 2006 14:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewm7m-0004Ml-25 for speermint@megatron.ietf.org; Wed, 11 Jan 2006 14:59:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08207 for ; Wed, 11 Jan 2006 14:57:53 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwmEi-0005l1-R1 for speermint@ietf.org; Wed, 11 Jan 2006 15:06:26 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Wed, 11 Jan 2006 21:00:13 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C476E@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYW43ZfG6LN/HFJQZqvv+XjQOHTUwABivh6 From: "Stastny Richard" To: "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org > I'm sure other examples come to mind. May I help you: 3GPP and TISPAN IMS ;-) I always thought the IETF is specifying the Internet Richard ________________________________ Von: Tom-PT Taylor [mailto:taylor@nortel.com] Gesendet: Mi 11.01.2006 20:11 An: Stastny Richard Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu; = speermint@ietf.org Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = Peering Policy I have no problem explaining this term. One example might be if I were trying to make a call from within my corporate network (the visited originating network), through my service provider (the home originating network), etc. To get out of my corporate network my client locates a SIP proxy in that network, which then forwards the call to the peering point of my service provider (which has a relationship with my corporate network that allows this to happen). I'm sure other examples come to mind. Stastny Richard wrote: > Again >=20 > Can anybody please explain to me what the term "visited" originating = or terminating > network means on L5 >=20 > Both end-users are registered at their respective home networks > (aka SIP servers). I always thought the SIP model is a trapezoid and > not a hexagon >=20 > QoS happens at or below L3 and should be negotiated by > the end-user with his acces provider. >=20 > Richard > > ________________________________ > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Mi 11.01.2006 19:01 > An: Michael Hammer (mhammer) > Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; = voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = Peering Policy > > > > The MSF is defining a scenario they hope to demonstrate, where media > paths cross different domains from signalling. The signalling may be = of > the form visited originating network - home originating network - home > terminating network - visited terminating network. This typical > scenario is an obvious example of L5 transit. Then the media path is > optimized to run directly between the visited networks, possibly by = way > of a different transit network offering QoS based on diffserv markings > at the egress points of the visited networks. > > L5 and L3 are linked in the originating and terminating visited > networks, but not in between. > > Michael Hammer (mhammer) wrote: > >>There MUST be some association of IP layer protocol elements to L5 >>traffic needs, such as low delay, packet loss etc. If the L5 need is >>real-time transmission, and that translates to a DSCP marking, then = the >>IP network needs to meet that need one way or another or very simply = the >>real-time service breaks. The alternative is that the peering always >>must include both L5 and L3 and you get a half-step instead of = full-step >>in evolution from PSTN to IP. >> >>Put another way, is it really necessary to have L5 transit networks? = If >>you insist that L3 always be paired with L5 for real-time, that is = what >>you get. >> >>Mike >> >> >> >> >>>-----Original Message----- >>>From: owner-voipeer@lists.uoregon.edu >>>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>>Sent: Monday, January 09, 2006 6:06 PM >>>To: Henry Sinnreich >>>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>>'Stastny Richard' >>>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >>> >>>On 2006/01/09 19:01, Henry Sinnreich wrote: >>> >>> >>>>Otmar, >>>> >>>>You say: >>>> >>>> >>>> >>>>>All current protocols regarding proxy and transport >>> >>>selection for SIP >>> >>> >>>>>are only based on the domain. I don't want to diverge from >>> >>>that model. >>> >>> >>>>What business has the broadband provider to mess with the >>> >>>user preferences? >>> >>> >>>>Users and enterprises pay for a certain bandwidth and >>> >>>hopefully will >>> >>> >>>>have the choice to pay extra for Diff Serv and that's the end of it. >>> >>>In an ideal world, yes. >>> >>> >>> >>>>If one domain has DiffServ and the other does not, it's up to the >>>>users to continue the call or switch over to some other >>> >>>networks, such >>> >>> >>>>as mobile or PSTN. And also to tell the other party to please >>>>subscribe to better broadband :-) >>>> >>>>What do you think? >>>> >>> >>>My problem with this idea is that "domain" in the sense of >>>SIP-servers is an application layer notion. >>> >>>DiffServ is a layer 3 issue. My layer 3 network does not >>>neccessarily know which applications I run over them. >>> >>>If my ISP also acts as my SIP provider, then yes: one can >>>link these two layers into one integrated QoS solution. AFAIK >>>this is one of the aims of the IMS. One of the local Austrian >>>ISPs uses this for his VoIP service: they use separate >>>VLANs/QoS planes for their VoIP offering. >>> >>>My private playground is quite different: I use an Asterisk >>>installation on a box (the same one I write this mail on) >>>colocated at ISP A whereas my SIP-phone at home is connected >>>via ISP B. The gateway to the PSTN is operated by a >>>commercial provider who uses ISP C. >>>If you add my ENUM nameservers, you get one more ISP into the = picture. >>>To top it off, I could add a SIP line to my office phone >>>which would bring our office connectivity into the game were >>>we basically run own multihomed network. >>> >>>I really don't know how to get seamless QoS in such a setting. >>> >>>(As you mentioned before: layer3 networks can't just trust >>>each other's DiffServ settings.) >>> >>>/ol >>>-- >>>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>>______________________________________________________________ >>>_______________ >>>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >>> >> >> >>_______________________________________________ >>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 Jan 11 15:20:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmS3-0002cz-7b; Wed, 11 Jan 2006 15:20:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmS1-0002co-A4 for speermint@megatron.ietf.org; Wed, 11 Jan 2006 15:20:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09937 for ; Wed, 11 Jan 2006 15:18:48 -0500 (EST) Received: from outbound-ash.frontbridge.com ([206.16.192.249] helo=outbound2-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmYz-0006IJ-GC for speermint@ietf.org; Wed, 11 Jan 2006 15:27:21 -0500 Received: from outbound2-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-ash-R.bigfish.com (Postfix) with ESMTP id E7482270B0A; Wed, 11 Jan 2006 20:19:55 +0000 (UTC) Received: from mail57-ash-R.bigfish.com (unknown [172.18.2.1]) by outbound2-ash.bigfish.com (Postfix) with ESMTP id E57E6270A35; Wed, 11 Jan 2006 20:19:55 +0000 (UTC) Received: from mail57-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail57-ash-R.bigfish.com (Postfix) with ESMTP id D60595EA7B4; Wed, 11 Jan 2006 20:19:55 +0000 (UTC) X-BigFish: V Received: by mail57-ash (MessageSwitch) id 1137010795695541_27815; Wed, 11 Jan 2006 20:19:55 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail57-ash.bigfish.com (Postfix) with ESMTP id 90D965EA758; Wed, 11 Jan 2006 20:19:55 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id k0BKJt1t021872; Wed, 11 Jan 2006 14:19:55 -0600 (CST) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id k0BKJso00356; Wed, 11 Jan 2006 14:19:54 -0600 (CST) Received: from PLSWB08C.ad.sprint.com ([208.10.70.243]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 14:19:54 -0600 Received: from 10.214.74.102 ([10.214.74.102]) by PLSWB08C.ad.sprint.com ([208.10.70.245]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jan 2006 20:19:54 +0000 MIME-Version: 1.0 From: "Khan, Sohel Q [CTO]" Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Message-ID: <02b501c616ec$6247819a$664ad60a@ad.sprint.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2006 14:20:02 -0600 Importance: normal X-Priority: 3 thread-topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy To: "Stastny Richard" , "Tom-PT Taylor" thread-index: AcYW43ZfG6LN/HFJQZqvv+XjQOHTUwABivh6AACwAqM= X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-OriginalArrivalTime: 11 Jan 2006 20:19:54.0885 (UTC) FILETIME=[6297DB50:01C616EC] X-Spam-Score: 0.8 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Internet is evolving! New Internet vs. Old Internet. In new Internet you can use terms such as foreign and home network. Sohel Khan, Ph.D. Sprint-Nextel -----Original Message----- From: "Stastny Richard" To: "Tom-PT Taylor" Cc: "voipeer@lists.uoregon.edu" ; = "speermint@ietf.org" Sent: 1/11/06 1:59 PM Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = PeeringPolicy > I'm sure other examples come to mind. May I help you: 3GPP and TISPAN IMS ;-) I always thought the IETF is specifying the Internet Richard ________________________________ Von: Tom-PT Taylor [mailto:taylor@nortel.com] Gesendet: Mi 11.01.2006 20:11 An: Stastny Richard Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu; = speermint@ietf.org Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = Peering Policy I have no problem explaining this term. One example might be if I were trying to make a call from within my corporate network (the visited originating network), through my service provider (the home originating network), etc. To get out of my corporate network my client locates a SIP proxy in that network, which then forwards the call to the peering point of my service provider (which has a relationship with my corporate network that allows this to happen). I'm sure other examples come to mind. Stastny Richard wrote: > Again >=20 > Can anybody please explain to me what the term "visited" originating = or terminating > network means on L5 >=20 > Both end-users are registered at their respective home networks > (aka SIP servers). I always thought the SIP model is a trapezoid and > not a hexagon >=20 > QoS happens at or below L3 and should be negotiated by > the end-user with his acces provider. >=20 > Richard > > ________________________________ > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Mi 11.01.2006 19:01 > An: Michael Hammer (mhammer) > Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; = voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = Peering Policy > > > > The MSF is defining a scenario they hope to demonstrate, where media > paths cross different domains from signalling. The signalling may be = of > the form visited originating network - home originating network - home > terminating network - visited terminating network. This typical > scenario is an obvious example of L5 transit. Then the media path is > optimized to run directly between the visited networks, possibly by = way > of a different transit network offering QoS based on diffserv markings > at the egress points of the visited networks. > > L5 and L3 are linked in the originating and terminating visited > networks, but not in between. > > Michael Hammer (mhammer) wrote: > >>There MUST be some association of IP layer protocol elements to L5 >>traffic needs, such as low delay, packet loss etc. If the L5 need is >>real-time transmission, and that translates to a DSCP marking, then = the >>IP network needs to meet that need one way or another or very simply = the >>real-time service breaks. The alternative is that the peering always >>must include both L5 and L3 and you get a half-step instead of = full-step >>in evolution from PSTN to IP. >> >>Put another way, is it really necessary to have L5 transit networks? = If >>you insist that L3 always be paired with L5 for real-time, that is = what >>you get. >> >>Mike >> >> >> >> >>>-----Original Message----- >>>From: owner-voipeer@lists.uoregon.edu >>>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>>Sent: Monday, January 09, 2006 6:06 PM >>>To: Henry Sinnreich >>>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>>'Stastny Richard' >>>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >>> >>>On 2006/01/09 19:01, Henry Sinnreich wrote: >>> >>> >>>>Otmar, >>>> >>>>You say: >>>> >>>> >>>> >>>>>All current protocols regarding proxy and transport >>> >>>selection for SIP >>> >>> >>>>>are only based on the domain. I don't want to diverge from >>> >>>that model. >>> >>> >>>>What business has the broadband provider to mess with the >>> >>>user preferences? >>> >>> >>>>Users and enterprises pay for a certain bandwidth and >>> >>>hopefully will >>> >>> >>>>have the choice to pay extra for Diff Serv and that's the end of it. >>> >>>In an ideal world, yes. >>> >>> >>> >>>>If one domain has DiffServ and the other does not, it's up to the >>>>users to continue the call or switch over to some other >>> >>>networks, such >>> >>> >>>>as mobile or PSTN. And also to tell the other party to please >>>>subscribe to better broadband :-) >>>> >>>>What do you think? >>>> >>> >>>My problem with this idea is that "domain" in the sense of >>>SIP-servers is an application layer notion. >>> >>>DiffServ is a layer 3 issue. My layer 3 network does not >>>neccessarily know which applications I run over them. >>> >>>If my ISP also acts as my SIP provider, then yes: one can >>>link these two layers into one integrated QoS solution. AFAIK >>>this is one of the aims of the IMS. One of the local Austrian >>>ISPs uses this for his VoIP service: they use separate >>>VLANs/QoS planes for their VoIP offering. >>> >>>My private playground is quite different: I use an Asterisk >>>installation on a box (the same one I write this mail on) >>>colocated at ISP A whereas my SIP-phone at home is connected >>>via ISP B. The gateway to the PSTN is operated by a >>>commercial provider who uses ISP C. >>>If you add my ENUM nameservers, you get one more ISP into the = picture. >>>To top it off, I could add a SIP line to my office phone >>>which would bring our office connectivity into the game were >>>we basically run own multihomed network. >>> >>>I really don't know how to get seamless QoS in such a setting. >>> >>>(As you mentioned before: layer3 networks can't just trust >>>each other's DiffServ settings.) >>> >>>/ol >>>-- >>>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>>______________________________________________________________ >>>_______________ >>>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >>> >> >> >>_______________________________________________ >>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 Jan 11 15:32:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmdV-0005Ih-3b; Wed, 11 Jan 2006 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmdS-0005IU-OC for speermint@megatron.ietf.org; Wed, 11 Jan 2006 15:31:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10589 for ; Wed, 11 Jan 2006 15:30:37 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwmkQ-0006cP-9c for speermint@ietf.org; Wed, 11 Jan 2006 15:39:11 -0500 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 Date: Wed, 11 Jan 2006 21:32:42 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4772@oefeg-s04.oefeg.loc> Thread-Topic: NGIN? Thread-Index: AcYW43ZfG6LN/HFJQZqvv+XjQOHTUwABivh6AACwAqMAAHKHoQ== From: "Stastny Richard" To: "Khan, Sohel Q [CTO]" , "Tom-PT Taylor" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu, speermint@ietf.org Subject: [Speermint] NGIN? 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Sohel Khan, Ph.D. wrote > Internet is evolving! New Internet vs. Old Internet. > In new Internet you can use terms such as foreign and home network. New Internet? New Generation InterNet? NGIN? Richard Stastny =20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 15:43:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmoR-0000Kq-Bl; Wed, 11 Jan 2006 15:43:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwmoP-0000HO-K9 for speermint@megatron.ietf.org; Wed, 11 Jan 2006 15:43:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11305 for ; Wed, 11 Jan 2006 15:41:56 -0500 (EST) Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwmvO-0006xs-0U for speermint@ietf.org; Wed, 11 Jan 2006 15:50:30 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 0005C1A3D1; Wed, 11 Jan 2006 21:43:06 +0100 (CET) Date: Wed, 11 Jan 2006 21:43:06 +0100 From: Otmar Lendl To: speermint@ietf.org Subject: Re: [Speermint] Revising draft-lendl-sip-peering-policy-00 Message-ID: <20060111204306.GA5755@nic.at> Mail-Followup-To: Otmar Lendl , speermint@ietf.org References: <20060111164032.GA28218@nic.at> <43C54483.1040904@shockey.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C54483.1040904@shockey.us> User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org On 2006/01/11 18:01, Richard Shockey wrote: > Otmar Lendl wrote: > > > >* The first I-D will describe the general framework and the > > resolution algorithm. (This is the one similar to RFC 3761) > > > > I'm not quite sure yet whether to formulate it as a DDDS > > application or not. > > I think you should. > The algorithm is close enough, but I'm not sure whether my idea of combining several rules (the ones with the same order field) into one boolean expression fits into the DDDS algorithm. > > > > This I-D will define an algorithm on how to map an FQDN > > to a list of URI-sets and how to interpret those. > > > > The algorithm is close to the one described in > > draft-lendl-sip-peering-policy-00.txt: > > > > For the application protocol "SIP", do: > > > > 1) Get all NAPTR records residing in the input domain > > whose service field matches "D2P+SIP(:.*)?" and where > > the flag is either empty or "u". > > If you want define a new Enumservice field based on D2P vs E2U you will > have to define this as a new DDDS. > This is completely independent of ENUM. It's a sister protocol and as such it will borrow only some ideas from RFC 3271. This will either be a new DDDS application or just some algorithm which makes use of NAPTR records and some ideas from DDDS. (As I read it, RFC 3263 isn't a full featured DDDS either.) > > > > 3) If no matching NAPTRs were found, revert to old rules. > > > > 4) Group (and sort) all NAPTRs found by "order". > > > > 5) Loop over these sets of NAPTR records (lowest order first): > > > > 5a) Evaluate the regex to get an URI for each NAPTR. > > 5b) Interpret each URI as a requirement according to > > the subsequent I-D which define sub-types for the > > service-field. Unknown sub-types are considered > > to be unfulfilled. > > 5c) If all requirements as defined by the NAPTRs of one > > set can be fulfilled then the algorithm terminates > > with a positive result. ---------------^^^^^^^^ This is the part where I'm not sure whether that's compatible with the generic DDDS algorithm. > > It uses sub-type "federation", thus in the context of SIP > > peering we get "D2P+SIP:federation" as service field. > > just use D2P+sip:fed:(uritype) NAPTR records are getting large as it is. > IN theory you can string out the enumservice field out as long as you > need "fed" or "federation" doesn't matter. The service field ("enumservice" is a mis-nomer here, we're in 3402 language, not 3671) is used to select the NAPTRs used for this DDDS application from the ones used for others. My thinking here was: "D2P" We're a "Domain to Policy" application "SIP" We're trying to find policy as applies to SIP (in contrast to e.g. "SMTP" which could be used to publish email acceptance policy.) "fed" This is a federation membership rule as defined by RFC xxxx. As the right hand side URI acts as a ID and not as URL, I don't see the necessity to include the uri-type in the service field. > >* A third I-D defining technical restrictions. > > > > Sub-type is "tech", thus e.g. "D2P+SIP:tech". > > tech:(URI) there may be more that one way to retrieve the same policy > set as in ftp vs http etc. I don't see the need to actually retrieve the standards here. The URIs only act as the unique identifier of a standard and no application will every try to retrieve the standardisation document. Consider them like XML namespace-URIs. They are just IDs. > >* Fancy XML policy languages fit also nicely into this system, the > > SAML/XACML crowd could also define their subtype, e.g. "XACML". > > http:xacml IMHO > > > > > Thus a service field "D2P+SIP:XACML" would lead to a > > http: URL linking to the actual XACML rules document. As we're dealing with real URLs here it makes sense to include the protocol used to retrieve the document. I'd go for xacml:http, though. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 11 16:24:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwnRo-0006pC-Aw; Wed, 11 Jan 2006 16:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwnRm-0006k0-AR for speermint@megatron.ietf.org; Wed, 11 Jan 2006 16:23:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15346 for ; Wed, 11 Jan 2006 16:22:36 -0500 (EST) Received: from mail120.messagelabs.com ([216.82.255.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwnYf-0000Lk-Pm for speermint@ietf.org; Wed, 11 Jan 2006 16:31:11 -0500 X-VirusChecked: Checked X-Env-Sender: ppfautz@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1137014609!11908691!2 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 31431 invoked from network); 11 Jan 2006 21:23:41 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (134.24.146.4) by server-2.tower-120.messagelabs.com with SMTP; 11 Jan 2006 21:23:41 -0000 Received: from ACCLUST02EVS1.ugd.att.com (135.37.16.8) by attrh2i.attrh.att.com (7.2.052) id 4380ACBE006C7BC6; Wed, 11 Jan 2006 16:23:40 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Wed, 11 Jan 2006 16:22:41 -0500 Message-ID: <34DA635B184A644DA4588E260EC0A25A0BE867BF@ACCLUST02EVS1.ugd.att.com> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYW2apwuUX7HvisSN++NFgJzGXxcwABNBJ9AAWDlEA= From: "Pfautz, Penn L, NEO" To: "Stastny Richard" , "Tom-PT Taylor" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org If I think IMS, as best I understand it, the P-CSCF in the visited network gets and stays involved in SIP signaling. I haven't quite thought out what that means to VoIP peering. Presumably the peering relationship is still between the home networks of originator and terminator. -----Original Message----- From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Stastny Richard Sent: Wednesday, January 11, 2006 1:46 PM To: Tom-PT Taylor; Michael Hammer (mhammer) Cc: enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Again =20 Can anybody please explain to me what the term "visited" originating or terminating network means on L5 =20 Both end-users are registered at their respective home networks (aka SIP servers). I always thought the SIP model is a trapezoid and=20 not a hexagon =20 QoS happens at or below L3 and should be negotiated by the end-user with his acces provider. =20 Richard ________________________________ Von: Tom-PT Taylor [mailto:taylor@nortel.com] Gesendet: Mi 11.01.2006 19:01 An: Michael Hammer (mhammer) Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy The MSF is defining a scenario they hope to demonstrate, where media paths cross different domains from signalling. The signalling may be of the form visited originating network - home originating network - home terminating network - visited terminating network. This typical scenario is an obvious example of L5 transit. Then the media path is optimized to run directly between the visited networks, possibly by way of a different transit network offering QoS based on diffserv markings at the egress points of the visited networks. L5 and L3 are linked in the originating and terminating visited networks, but not in between. Michael Hammer (mhammer) wrote: > There MUST be some association of IP layer protocol elements to L5 > traffic needs, such as low delay, packet loss etc. If the L5 need is > real-time transmission, and that translates to a DSCP marking, then the > IP network needs to meet that need one way or another or very simply the > real-time service breaks. The alternative is that the peering always > must include both L5 and L3 and you get a half-step instead of full-step > in evolution from PSTN to IP. > > Put another way, is it really necessary to have L5 transit networks? If > you insist that L3 always be paired with L5 for real-time, that is what > you get. > > Mike > > > >>-----Original Message----- >>From: owner-voipeer@lists.uoregon.edu >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl >>Sent: Monday, January 09, 2006 6:06 PM >>To: Henry Sinnreich >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; >>'Stastny Richard' >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy >> >>On 2006/01/09 19:01, Henry Sinnreich wrote: >> >>>Otmar, >>> >>>You say: >>> >>> >>>>All current protocols regarding proxy and transport >> >>selection for SIP >> >>>>are only based on the domain. I don't want to diverge from >> >>that model. >> >>>What business has the broadband provider to mess with the >> >>user preferences? >> >>>Users and enterprises pay for a certain bandwidth and >> >>hopefully will >> >>>have the choice to pay extra for Diff Serv and that's the end of it. >> >>In an ideal world, yes. >> >> >>>If one domain has DiffServ and the other does not, it's up to the >>>users to continue the call or switch over to some other >> >>networks, such >> >>>as mobile or PSTN. And also to tell the other party to please >>>subscribe to better broadband :-) >>> >>>What do you think? >>> >> >>My problem with this idea is that "domain" in the sense of >>SIP-servers is an application layer notion. >> >>DiffServ is a layer 3 issue. My layer 3 network does not >>neccessarily know which applications I run over them. >> >>If my ISP also acts as my SIP provider, then yes: one can >>link these two layers into one integrated QoS solution. AFAIK >>this is one of the aims of the IMS. One of the local Austrian >>ISPs uses this for his VoIP service: they use separate >>VLANs/QoS planes for their VoIP offering. >> >>My private playground is quite different: I use an Asterisk >>installation on a box (the same one I write this mail on) >>colocated at ISP A whereas my SIP-phone at home is connected >>via ISP B. The gateway to the PSTN is operated by a >>commercial provider who uses ISP C. >>If you add my ENUM nameservers, you get one more ISP into the picture. >>To top it off, I could add a SIP line to my office phone >>which would bring our office connectivity into the game were >>we basically run own multihomed network. >> >>I really don't know how to get seamless QoS in such a setting. >> >>(As you mentioned before: layer3 networks can't just trust >>each other's DiffServ settings.) >> >>/ol >>-- >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > >>______________________________________________________________ >>_______________ >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html >> > > > _______________________________________________ > 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 Thu Jan 12 03:52:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwyCY-0004Zd-Qp; Thu, 12 Jan 2006 03:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwyCW-0004Z1-NT for speermint@megatron.ietf.org; Thu, 12 Jan 2006 03:52:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02328 for ; Thu, 12 Jan 2006 03:51:34 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwyJZ-0004vC-R3 for speermint@ietf.org; Thu, 12 Jan 2006 04:00:15 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 12 Jan 2006 09:56:29 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2330@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYW2apwuUX7HvisSN++NFgJzGXxcwABNBJ9AAWDlEAAF4BxIA== From: "Stastny Richard" To: "Pfautz, Penn L, NEO" , "Tom-PT Taylor" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Penn wrote: > If I think IMS, as best I understand it, the P-CSCF in the visited > network gets and stays involved in SIP signaling. As long as only L5 signalling/peering is involved, I have no problem with This. This would be equivalent to the enterprise example by Tom The real goal of IMS is also to introduce L3 peering in the same way: the media stream is also tromboned from the originating visited network to the visited destination network via the two home networks. This would keep the existing vertical silo philosophy intact also on IP-based networks. The arguments brought forward are QoS, LI, etc., the real answer is money (the roaming rip-off) Today, if your home network is in Austria and you are roaming in Germany (or the US) and call somebody also from Austria standing beside you, the Call is routed via the two home networks, so both parties pay an international call each including additional roaming charges.=20 Technically a local call would do, and this could easily be implemented since more then 10 years, but the work was stopped by the MOs (I was involved in tromboning prevention in the early 90ties) Same if you access the Internet via GPRS/UMTS while roaming: the connection to the Internet is not done by the visiting network, it is tunnelled though=20 the visited network to the home network and delivered there (as one can easily see from the IP address (just to charge you 10 Euro per MB data) This is what they call the New Internet Remark: Roaming is not such an issue for the US, but in Europe you are always roaming. The equivalent in the US would be roaming by state: The providers have state licences and if your home provider is in New York, you would have to pay roaming charges if you are in New Jersey. > I haven't quite thought out what that means to VoIP peering. Presumably > the peering relationship is still between the home networks of > originator and terminator. Yes, L5 AND L3 Richard > -----Original Message----- > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > Sent: Wednesday, January 11, 2006 10:23 PM > To: Stastny Richard; Tom-PT Taylor; Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP > PeeringPolicy >=20 > If I think IMS, as best I understand it, the P-CSCF in the visited > network gets and stays involved in SIP signaling. > I haven't quite thought out what that means to VoIP peering. Presumably > the peering relationship is still between the home networks of > originator and terminator. >=20 > -----Original Message----- > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On > Behalf Of Stastny Richard > Sent: Wednesday, January 11, 2006 1:46 PM > To: Tom-PT Taylor; Michael Hammer (mhammer) > Cc: enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu > Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP > PeeringPolicy >=20 > Again >=20 > Can anybody please explain to me what the term "visited" originating or > terminating > network means on L5 >=20 > Both end-users are registered at their respective home networks > (aka SIP servers). I always thought the SIP model is a trapezoid and > not a hexagon >=20 > QoS happens at or below L3 and should be negotiated by > the end-user with his acces provider. >=20 > Richard >=20 > ________________________________ >=20 > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Mi 11.01.2006 19:01 > An: Michael Hammer (mhammer) > Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org; > voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP > Peering Policy >=20 >=20 >=20 > The MSF is defining a scenario they hope to demonstrate, where media > paths cross different domains from signalling. The signalling may be of > the form visited originating network - home originating network - home > terminating network - visited terminating network. This typical > scenario is an obvious example of L5 transit. Then the media path is > optimized to run directly between the visited networks, possibly by way > of a different transit network offering QoS based on diffserv markings > at the egress points of the visited networks. >=20 > L5 and L3 are linked in the originating and terminating visited > networks, but not in between. >=20 > Michael Hammer (mhammer) wrote: > > There MUST be some association of IP layer protocol elements to L5 > > traffic needs, such as low delay, packet loss etc. If the L5 need is > > real-time transmission, and that translates to a DSCP marking, then > the > > IP network needs to meet that need one way or another or very simply > the > > real-time service breaks. The alternative is that the peering always > > must include both L5 and L3 and you get a half-step instead of > full-step > > in evolution from PSTN to IP. > > > > Put another way, is it really necessary to have L5 transit networks? > If > > you insist that L3 always be paired with L5 for real-time, that is > what > > you get. > > > > Mike > > > > > > > >>-----Original Message----- > >>From: owner-voipeer@lists.uoregon.edu > >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl > >>Sent: Monday, January 09, 2006 6:06 PM > >>To: Henry Sinnreich > >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer'; > >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu; > >>'Stastny Richard' > >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy > >> > >>On 2006/01/09 19:01, Henry Sinnreich wrote: > >> > >>>Otmar, > >>> > >>>You say: > >>> > >>> > >>>>All current protocols regarding proxy and transport > >> > >>selection for SIP > >> > >>>>are only based on the domain. I don't want to diverge from > >> > >>that model. > >> > >>>What business has the broadband provider to mess with the > >> > >>user preferences? > >> > >>>Users and enterprises pay for a certain bandwidth and > >> > >>hopefully will > >> > >>>have the choice to pay extra for Diff Serv and that's the end of it. > >> > >>In an ideal world, yes. > >> > >> > >>>If one domain has DiffServ and the other does not, it's up to the > >>>users to continue the call or switch over to some other > >> > >>networks, such > >> > >>>as mobile or PSTN. And also to tell the other party to please > >>>subscribe to better broadband :-) > >>> > >>>What do you think? > >>> > >> > >>My problem with this idea is that "domain" in the sense of > >>SIP-servers is an application layer notion. > >> > >>DiffServ is a layer 3 issue. My layer 3 network does not > >>neccessarily know which applications I run over them. > >> > >>If my ISP also acts as my SIP provider, then yes: one can > >>link these two layers into one integrated QoS solution. AFAIK > >>this is one of the aims of the IMS. One of the local Austrian > >>ISPs uses this for his VoIP service: they use separate > >>VLANs/QoS planes for their VoIP offering. > >> > >>My private playground is quite different: I use an Asterisk > >>installation on a box (the same one I write this mail on) > >>colocated at ISP A whereas my SIP-phone at home is connected > >>via ISP B. The gateway to the PSTN is operated by a > >>commercial provider who uses ISP C. > >>If you add my ENUM nameservers, you get one more ISP into the picture. > >>To top it off, I could add a SIP line to my office phone > >>which would bring our office connectivity into the game were > >>we basically run own multihomed network. > >> > >>I really don't know how to get seamless QoS in such a setting. > >> > >>(As you mentioned before: layer3 networks can't just trust > >>each other's DiffServ settings.) > >> > >>/ol > >>-- > >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > > >>______________________________________________________________ > >>_______________ > >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > >> > > > > > > _______________________________________________ > > Speermint mailing list > > Speermint@ietf.org > > https://www1.ietf.org/mailman/listinfo/speermint > > > > >=20 >=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 Thu Jan 12 11:31:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5MC-00055v-RK; Thu, 12 Jan 2006 11:31:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5MA-00055l-RK for speermint@megatron.ietf.org; Thu, 12 Jan 2006 11:31:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28959 for ; Thu, 12 Jan 2006 11:30:00 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex5TJ-0000zy-GQ for speermint@ietf.org; Thu, 12 Jan 2006 11:38:46 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2006 08:31:13 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0CGV7jv006550; Thu, 12 Jan 2006 08:31:09 -0800 (PST) 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.211); Thu, 12 Jan 2006 11:31:07 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Thu, 12 Jan 2006 11:31:06 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5F94C@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYW43ZfG6LN/HFJQZqvv+XjQOHTUwABivh6ACq2zIA= From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Tom-PT Taylor" X-OriginalArrivalTime: 12 Jan 2006 16:31:07.0811 (UTC) FILETIME=[97085730:01C61795] X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Richard, There will be a need to blend terms from the legacy cellular world with the target NGN/IMS/??? architecture to lead participants from the known to the unknown. WRT the visited v. home, and the need for customized services and features, the originating L5 "network" should always be the originator's home IMS servers, and the terminating L5 "network" should always be the terminator's home IMS servers. This supports the concept that the service is independent of the access network technology, in which I include the 3GPP (GSM) v. 3GPP2 (ANSI-41/CDMA) cellular visited networks. A user should be able to roam/handover across multiple access network types, to include WiFi and WiMax. There are a variety of technologies in play, and we need to account for all of them in this brave new world of convergence. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, January 11, 2006 3:00 PM > To: Tom-PT Taylor > Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu;=20 > speermint@ietf.org > Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP Peering Policy >=20 > > I'm sure other examples come to mind. >=20 > May I help you: 3GPP and TISPAN IMS ;-) >=20 > I always thought the IETF is specifying the Internet >=20 > Richard >=20 > ________________________________ >=20 > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > Gesendet: Mi 11.01.2006 20:11 > An: Stastny Richard > Cc: Michael Hammer (mhammer); voipeer@lists.uoregon.edu;=20 > speermint@ietf.org > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP Peering Policy >=20 >=20 >=20 > I have no problem explaining this term. One example might be=20 > if I were trying to make a call from within my corporate=20 > network (the visited originating network), through my service=20 > provider (the home originating network), etc. To get out of=20 > my corporate network my client locates a SIP proxy in that=20 > network, which then forwards the call to the peering point of=20 > my service provider (which has a relationship with my=20 > corporate network that allows this to happen). >=20 > I'm sure other examples come to mind. >=20 > Stastny Richard wrote: > > Again > >=20 > > Can anybody please explain to me what the term "visited"=20 > originating=20 > > or terminating network means on L5 > >=20 > > Both end-users are registered at their respective home=20 > networks (aka=20 > > SIP servers). I always thought the SIP model is a trapezoid=20 > and not a=20 > > hexagon > >=20 > > QoS happens at or below L3 and should be negotiated by the end-user=20 > > with his acces provider. > >=20 > > Richard > > > > ________________________________ > > > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > > Gesendet: Mi 11.01.2006 19:01 > > An: Michael Hammer (mhammer) > > Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org;=20 > > voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org > > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP=20 > > Peering Policy > > > > > > > > The MSF is defining a scenario they hope to demonstrate,=20 > where media=20 > > paths cross different domains from signalling. The=20 > signalling may be=20 > > of the form visited originating network - home originating=20 > network -=20 > > home terminating network - visited terminating network. =20 > This typical=20 > > scenario is an obvious example of L5 transit. Then the=20 > media path is=20 > > optimized to run directly between the visited networks, possibly by=20 > > way of a different transit network offering QoS based on diffserv=20 > > markings at the egress points of the visited networks. > > > > L5 and L3 are linked in the originating and terminating visited=20 > > networks, but not in between. > > > > Michael Hammer (mhammer) wrote: > > > >>There MUST be some association of IP layer protocol elements to L5=20 > >>traffic needs, such as low delay, packet loss etc. If the=20 > L5 need is=20 > >>real-time transmission, and that translates to a DSCP marking, then=20 > >>the IP network needs to meet that need one way or another or very=20 > >>simply the real-time service breaks. The alternative is that the=20 > >>peering always must include both L5 and L3 and you get a half-step=20 > >>instead of full-step in evolution from PSTN to IP. > >> > >>Put another way, is it really necessary to have L5 transit=20 > networks? =20 > >>If you insist that L3 always be paired with L5 for=20 > real-time, that is=20 > >>what you get. > >> > >>Mike > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: owner-voipeer@lists.uoregon.edu=20 > >>>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl > >>>Sent: Monday, January 09, 2006 6:06 PM > >>>To: Henry Sinnreich > >>>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer';=20 > >>>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu;=20 > >>>'Stastny Richard' > >>>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP=20 > Peering Policy > >>> > >>>On 2006/01/09 19:01, Henry Sinnreich wrote: > >>> > >>> > >>>>Otmar, > >>>> > >>>>You say: > >>>> > >>>> > >>>> > >>>>>All current protocols regarding proxy and transport > >>> > >>>selection for SIP > >>> > >>> > >>>>>are only based on the domain. I don't want to diverge from > >>> > >>>that model. > >>> > >>> > >>>>What business has the broadband provider to mess with the > >>> > >>>user preferences? > >>> > >>> > >>>>Users and enterprises pay for a certain bandwidth and > >>> > >>>hopefully will > >>> > >>> > >>>>have the choice to pay extra for Diff Serv and that's the=20 > end of it. > >>> > >>>In an ideal world, yes. > >>> > >>> > >>> > >>>>If one domain has DiffServ and the other does not, it's up to the=20 > >>>>users to continue the call or switch over to some other > >>> > >>>networks, such > >>> > >>> > >>>>as mobile or PSTN. And also to tell the other party to please=20 > >>>>subscribe to better broadband :-) > >>>> > >>>>What do you think? > >>>> > >>> > >>>My problem with this idea is that "domain" in the sense of=20 > >>>SIP-servers is an application layer notion. > >>> > >>>DiffServ is a layer 3 issue. My layer 3 network does not=20 > neccessarily=20 > >>>know which applications I run over them. > >>> > >>>If my ISP also acts as my SIP provider, then yes: one can=20 > link these=20 > >>>two layers into one integrated QoS solution. AFAIK this is=20 > one of the=20 > >>>aims of the IMS. One of the local Austrian ISPs uses this for his=20 > >>>VoIP service: they use separate VLANs/QoS planes for their VoIP=20 > >>>offering. > >>> > >>>My private playground is quite different: I use an Asterisk=20 > >>>installation on a box (the same one I write this mail on)=20 > colocated=20 > >>>at ISP A whereas my SIP-phone at home is connected via ISP B. The=20 > >>>gateway to the PSTN is operated by a commercial provider=20 > who uses ISP=20 > >>>C. > >>>If you add my ENUM nameservers, you get one more ISP into=20 > the picture. > >>>To top it off, I could add a SIP line to my office phone=20 > which would=20 > >>>bring our office connectivity into the game were we=20 > basically run own=20 > >>>multihomed network. > >>> > >>>I really don't know how to get seamless QoS in such a setting. > >>> > >>>(As you mentioned before: layer3 networks can't just trust each=20 > >>>other's DiffServ settings.) > >>> > >>>/ol > >>>-- > >>>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >=20 > >>>______________________________________________________________ > >>>_______________ > >>>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > >>>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > >>> > >> > >> > >>_______________________________________________ > >>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 Thu Jan 12 11:36:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5R1-0007I0-VU; Thu, 12 Jan 2006 11:36:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex5Qz-0007He-JI for speermint@megatron.ietf.org; Thu, 12 Jan 2006 11:36:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29459 for ; Thu, 12 Jan 2006 11:34:59 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex5Y7-0001Cn-Uc for speermint@ietf.org; Thu, 12 Jan 2006 11:43:44 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 12 Jan 2006 08:36:11 -0800 X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="248683547:sNHT39792030" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0CGZwWp027004; Thu, 12 Jan 2006 08:36:10 -0800 (PST) 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.211); Thu, 12 Jan 2006 11:36:10 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 12 Jan 2006 11:36:09 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5F95C@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYW2apwuUX7HvisSN++NFgJzGXxcwABNBJ9AAWDlEAAF4BxIAAQ19nw From: "Michael Hammer \(mhammer\)" To: "Stastny Richard" , "Pfautz, Penn L, NEO" , "Tom-PT Taylor" X-OriginalArrivalTime: 12 Jan 2006 16:36:10.0341 (UTC) FILETIME=[4B5AC150:01C61796] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org It would provide a better user experience if the L3 and L5 peering could be only loosely coupled so that the media and signaling paths are not so tightly bound and the media path takes the shortest geographically, least number of L3 networks path. Mike > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Thursday, January 12, 2006 3:56 AM > To: Pfautz, Penn L, NEO; Tom-PT Taylor; Michael Hammer (mhammer) > Cc: speermint@ietf.org > Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP PeeringPolicy >=20 > Penn wrote: > > If I think IMS, as best I understand it, the P-CSCF in the visited=20 > > network gets and stays involved in SIP signaling. >=20 > As long as only L5 signalling/peering is involved, I have no=20 > problem with This. This would be equivalent to the enterprise=20 > example by Tom >=20 > The real goal of IMS is also to introduce L3 peering in the same way: > the > media stream is also tromboned from the originating visited=20 > network to the visited destination network via the two home networks. >=20 > This would keep the existing vertical silo philosophy intact=20 > also on IP-based networks. The arguments brought forward are=20 > QoS, LI, etc., the real answer is money (the roaming rip-off) >=20 > Today, if your home network is in Austria and you are roaming=20 > in Germany (or the US) and call somebody also from Austria=20 > standing beside you, the Call is routed via the two home=20 > networks, so both parties pay an international call each=20 > including additional roaming charges.=20 >=20 > Technically a local call would do, and this could easily be=20 > implemented since more then 10 years, but the work was=20 > stopped by the MOs (I was involved in tromboning prevention=20 > in the early 90ties) >=20 > Same if you access the Internet via GPRS/UMTS while roaming:=20 > the connection to the Internet is not done by the visiting=20 > network, it is tunnelled though the visited network to the=20 > home network and delivered there (as one can easily see from=20 > the IP address (just to charge you 10 Euro per MB data) >=20 > This is what they call the New Internet >=20 > Remark: Roaming is not such an issue for the US, but in=20 > Europe you are always roaming. The equivalent in the US would=20 > be roaming by state: > The providers have state licences and if your home provider=20 > is in New York, you would have to pay roaming charges if you=20 > are in New Jersey. >=20 > > I haven't quite thought out what that means to VoIP peering. > Presumably > > the peering relationship is still between the home networks of=20 > > originator and terminator. >=20 > Yes, L5 AND L3 >=20 > Richard >=20 > > -----Original Message----- > > From: Pfautz, Penn L, NEO [mailto:ppfautz@att.com] > > Sent: Wednesday, January 11, 2006 10:23 PM > > To: Stastny Richard; Tom-PT Taylor; Michael Hammer (mhammer) > > Cc: speermint@ietf.org > > Subject: RE: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP=20 > > PeeringPolicy > >=20 > > If I think IMS, as best I understand it, the P-CSCF in the visited=20 > > network gets and stays involved in SIP signaling. > > I haven't quite thought out what that means to VoIP peering. > Presumably > > the peering relationship is still between the home networks of=20 > > originator and terminator. > >=20 > > -----Original Message----- > > From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] > On > > Behalf Of Stastny Richard > > Sent: Wednesday, January 11, 2006 1:46 PM > > To: Tom-PT Taylor; Michael Hammer (mhammer) > > Cc: enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu > > Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP=20 > > PeeringPolicy > >=20 > > Again > >=20 > > Can anybody please explain to me what the term "visited" originating > or > > terminating > > network means on L5 > >=20 > > Both end-users are registered at their respective home=20 > networks (aka=20 > > SIP servers). I always thought the SIP model is a trapezoid=20 > and not a=20 > > hexagon > >=20 > > QoS happens at or below L3 and should be negotiated by the end-user=20 > > with his acces provider. > >=20 > > Richard > >=20 > > ________________________________ > >=20 > > Von: Tom-PT Taylor [mailto:taylor@nortel.com] > > Gesendet: Mi 11.01.2006 19:01 > > An: Michael Hammer (mhammer) > > Cc: Otmar Lendl; Henry Sinnreich; enum@ietf.org;=20 > > voipeer@lists.uoregon.edu; Stastny Richard; speermint@ietf.org > > Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP=20 > > Peering Policy > >=20 > >=20 > >=20 > > The MSF is defining a scenario they hope to demonstrate,=20 > where media=20 > > paths cross different domains from signalling. The signalling may be > of > > the form visited originating network - home originating=20 > network - home=20 > > terminating network - visited terminating network. This typical=20 > > scenario is an obvious example of L5 transit. Then the=20 > media path is=20 > > optimized to run directly between the visited networks, possibly by > way > > of a different transit network offering QoS based on=20 > diffserv markings=20 > > at the egress points of the visited networks. > >=20 > > L5 and L3 are linked in the originating and terminating visited=20 > > networks, but not in between. > >=20 > > Michael Hammer (mhammer) wrote: > > > There MUST be some association of IP layer protocol=20 > elements to L5=20 > > > traffic needs, such as low delay, packet loss etc. If the L5 need > is > > > real-time transmission, and that translates to a DSCP=20 > marking, then > > the > > > IP network needs to meet that need one way or another or=20 > very simply > > the > > > real-time service breaks. The alternative is that the peering > always > > > must include both L5 and L3 and you get a half-step instead of > > full-step > > > in evolution from PSTN to IP. > > > > > > Put another way, is it really necessary to have L5=20 > transit networks? > > If > > > you insist that L3 always be paired with L5 for real-time, that is > > what > > > you get. > > > > > > Mike > > > > > > > > > > > >>-----Original Message----- > > >>From: owner-voipeer@lists.uoregon.edu=20 > > >>[mailto:owner-voipeer@lists.uoregon.edu] On Behalf Of Otmar Lendl > > >>Sent: Monday, January 09, 2006 6:06 PM > > >>To: Henry Sinnreich > > >>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer';=20 > > >>enum@ietf.org; speermint@ietf.org; voipeer@lists.uoregon.edu;=20 > > >>'Stastny Richard' > > >>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP=20 > Peering Policy > > >> > > >>On 2006/01/09 19:01, Henry Sinnreich wrote: > > >> > > >>>Otmar, > > >>> > > >>>You say: > > >>> > > >>> > > >>>>All current protocols regarding proxy and transport > > >> > > >>selection for SIP > > >> > > >>>>are only based on the domain. I don't want to diverge from > > >> > > >>that model. > > >> > > >>>What business has the broadband provider to mess with the > > >> > > >>user preferences? > > >> > > >>>Users and enterprises pay for a certain bandwidth and > > >> > > >>hopefully will > > >> > > >>>have the choice to pay extra for Diff Serv and that's the end of > it. > > >> > > >>In an ideal world, yes. > > >> > > >> > > >>>If one domain has DiffServ and the other does not, it's=20 > up to the=20 > > >>>users to continue the call or switch over to some other > > >> > > >>networks, such > > >> > > >>>as mobile or PSTN. And also to tell the other party to please=20 > > >>>subscribe to better broadband :-) > > >>> > > >>>What do you think? > > >>> > > >> > > >>My problem with this idea is that "domain" in the sense of=20 > > >>SIP-servers is an application layer notion. > > >> > > >>DiffServ is a layer 3 issue. My layer 3 network does not=20 > > >>neccessarily know which applications I run over them. > > >> > > >>If my ISP also acts as my SIP provider, then yes: one can=20 > link these=20 > > >>two layers into one integrated QoS solution. AFAIK this is one of=20 > > >>the aims of the IMS. One of the local Austrian ISPs uses this for=20 > > >>his VoIP service: they use separate VLANs/QoS planes for=20 > their VoIP=20 > > >>offering. > > >> > > >>My private playground is quite different: I use an Asterisk=20 > > >>installation on a box (the same one I write this mail on)=20 > colocated=20 > > >>at ISP A whereas my SIP-phone at home is connected via ISP B. The=20 > > >>gateway to the PSTN is operated by a commercial provider who uses=20 > > >>ISP C. > > >>If you add my ENUM nameservers, you get one more ISP into the > picture. > > >>To top it off, I could add a SIP line to my office phone=20 > which would=20 > > >>bring our office connectivity into the game were we basically run=20 > > >>own multihomed network. > > >> > > >>I really don't know how to get seamless QoS in such a setting. > > >> > > >>(As you mentioned before: layer3 networks can't just trust each=20 > > >>other's DiffServ settings.) > > >> > > >>/ol > > >>-- > > >>< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >=20 > > >>______________________________________________________________ > > >>_______________ > > >>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/ > > >>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html > > >> > > > > > > > > > _______________________________________________ > > > Speermint mailing list > > > Speermint@ietf.org > > > https://www1.ietf.org/mailman/listinfo/speermint > > > > > > > >=20 > >=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 Thu Jan 12 15:27:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex92q-0007er-5E; Thu, 12 Jan 2006 15:27:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex92n-0007dx-Kc for speermint@megatron.ietf.org; Thu, 12 Jan 2006 15:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15471 for ; Thu, 12 Jan 2006 15:26:15 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex99w-0008K2-22 for speermint@ietf.org; Thu, 12 Jan 2006 15:35:02 -0500 Received: from zinnhxm0.corp.nortel.com (zinnhxm0.corp.nortel.com [47.153.200.77]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0CKR2P17687; Thu, 12 Jan 2006 15:27:02 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zinnhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jan 2006 07:27:01 +1100 Received: from [127.0.0.1] ([47.130.16.124] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 15:26:57 -0500 Message-ID: <43C6BB8C.6030508@nortel.com> Date: Thu, 12 Jan 2006 15:26:52 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <072C5B76F7CEAB488172C6F64B30B5E3F5F94C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5F94C@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2006 20:26:57.0869 (UTC) FILETIME=[891FD7D0:01C617B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org L5 peering happens at every network boundary, not just the one at the centre of the call path. In the example I gave three peering relationships are needed. Michael Hammer (mhammer) wrote: > Richard, > > There will be a need to blend terms from the legacy cellular world with > the target NGN/IMS/??? architecture to lead participants from the known > to the unknown. > > WRT the visited v. home, and the need for customized services and > features, the originating L5 "network" should always be the originator's > home IMS servers, and the terminating L5 "network" should always be the > terminator's home IMS servers. This supports the concept that the > service is independent of the access network technology, in which I > include the 3GPP (GSM) v. 3GPP2 (ANSI-41/CDMA) cellular visited > networks. A user should be able to roam/handover across multiple access > network types, to include WiFi and WiMax. > > There are a variety of technologies in play, and we need to account for > all of them in this brave new world of convergence. > > Mike > > > ... _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 15:37:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9Cb-00022Q-MH; Thu, 12 Jan 2006 15:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9Ca-00021q-JG for speermint@megatron.ietf.org; Thu, 12 Jan 2006 15:37:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16008 for ; Thu, 12 Jan 2006 15:36:22 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9Jg-00009L-VN for speermint@ietf.org; Thu, 12 Jan 2006 15:45:09 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Jan 2006 15:37:30 -0500 X-IronPort-AV: i="3.99,360,1131339600"; d="scan'208"; a="80146118:sNHT32917160" 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 k0CKbK6N020680; Thu, 12 Jan 2006 15:37:27 -0500 (EST) 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.211); Thu, 12 Jan 2006 15:37:16 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Thu, 12 Jan 2006 15:37:23 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5FA91@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYXtpsRK4vJ4VXYRLeTBzMWVrY0WAAAUPbw From: "Michael Hammer \(mhammer\)" To: "Tom-PT Taylor" X-OriginalArrivalTime: 12 Jan 2006 20:37:16.0797 (UTC) FILETIME=[FA08C2D0:01C617B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Tom, Not following this. If the network boundary is between a L3+L5 network to a L3-only network, how does the L5 peering work? Mike =20 > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Sent: Thursday, January 12, 2006 3:27 PM > To: Michael Hammer (mhammer) > Cc: Stastny Richard; voipeer@lists.uoregon.edu; speermint@ietf.org > Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP Peering Policy >=20 > L5 peering happens at every network boundary, not just the=20 > one at the centre of the call path. In the example I gave=20 > three peering relationships are needed. >=20 > Michael Hammer (mhammer) wrote: > > Richard, > >=20 > > There will be a need to blend terms from the legacy cellular world=20 > > with the target NGN/IMS/??? architecture to lead=20 > participants from the=20 > > known to the unknown. > >=20 > > WRT the visited v. home, and the need for customized services and=20 > > features, the originating L5 "network" should always be the=20 > > originator's home IMS servers, and the terminating L5=20 > "network" should=20 > > always be the terminator's home IMS servers. This supports the=20 > > concept that the service is independent of the access network=20 > > technology, in which I include the 3GPP (GSM) v. 3GPP2=20 > (ANSI-41/CDMA)=20 > > cellular visited networks. A user should be able to roam/handover=20 > > across multiple access network types, to include WiFi and WiMax. > >=20 > > There are a variety of technologies in play, and we need to account=20 > > for all of them in this brave new world of convergence. > >=20 > > Mike > >=20 > >=20 > >=20 > ... >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 15:52:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9RE-0006U4-Hu; Thu, 12 Jan 2006 15:52:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9RC-0006TW-OQ for speermint@megatron.ietf.org; Thu, 12 Jan 2006 15:52:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17557 for ; Thu, 12 Jan 2006 15:51:28 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55] helo=zrtps0kn.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex9YK-0000kx-AX for speermint@ietf.org; Thu, 12 Jan 2006 16:00:15 -0500 Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0CKqFt20226; Thu, 12 Jan 2006 15:52:15 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zharhxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 20:52:08 +0000 Received: from [127.0.0.1] ([47.130.16.124] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 15:52:05 -0500 Message-ID: <43C6C170.7080908@nortel.com> Date: Thu, 12 Jan 2006 15:52:00 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <072C5B76F7CEAB488172C6F64B30B5E3F5FA91@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5FA91@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2006 20:52:06.0047 (UTC) FILETIME=[0C118AF0:01C617BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Network 1 contains the calling host and an outgoing proxy. Network 2 contains the caller's home server. Network 3 contains the called party home server. Network 4 contains the called host and an incoming proxy. Of course there must be L3 paths between all these networks to carry the signalling. That may involve direct L3 peering or indirect routing via other networks. Media takes the short way, from Network 1 to Network 4. Again, that may involve direct L3 peering between those two networks, or indirect routing via one or more backbone networks. Michael Hammer (mhammer) wrote: > Tom, > > Not following this. > > If the network boundary is between a L3+L5 network to a L3-only > network, how does the L5 peering work? > > Mike > > > >>-----Original Message----- >>From: Tom-PT Taylor [mailto:taylor@nortel.com] >>Sent: Thursday, January 12, 2006 3:27 PM >>To: Michael Hammer (mhammer) >>Cc: Stastny Richard; voipeer@lists.uoregon.edu; speermint@ietf.org >>Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: >>Publishing SIP Peering Policy >> >>L5 peering happens at every network boundary, not just the >>one at the centre of the call path. In the example I gave >>three peering relationships are needed. >> >>Michael Hammer (mhammer) wrote: >> >>>Richard, >>> >>>There will be a need to blend terms from the legacy cellular world >>>with the target NGN/IMS/??? architecture to lead >> >>participants from the >> >>>known to the unknown. >>> >>>WRT the visited v. home, and the need for customized services and >>>features, the originating L5 "network" should always be the >>>originator's home IMS servers, and the terminating L5 >> >>"network" should >> >>>always be the terminator's home IMS servers. This supports the >>>concept that the service is independent of the access network >>>technology, in which I include the 3GPP (GSM) v. 3GPP2 >> >>(ANSI-41/CDMA) >> >>>cellular visited networks. A user should be able to roam/handover >>>across multiple access network types, to include WiFi and WiMax. >>> >>>There are a variety of technologies in play, and we need to account >>>for all of them in this brave new world of convergence. >>> >>>Mike >>> >>> >>> >> >>... >> > > > _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 16:29:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExA0W-0001w8-5o; Thu, 12 Jan 2006 16:29:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExA0U-0001vK-3w for speermint@megatron.ietf.org; Thu, 12 Jan 2006 16:29:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25606 for ; Thu, 12 Jan 2006 16:27:55 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExA7b-0003yy-9X for speermint@ietf.org; Thu, 12 Jan 2006 16:36:42 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2006 13:29:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="19629991:sNHT25948924" 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 k0CLST6d029143; Thu, 12 Jan 2006 16:28:59 -0500 (EST) 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.211); Thu, 12 Jan 2006 16:28:39 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Date: Thu, 12 Jan 2006 16:28:54 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5FAC6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy Thread-Index: AcYXvDHSvgqqI2nDRFmD6m+Vri+7pQAAoz1g From: "Michael Hammer \(mhammer\)" To: "Tom-PT Taylor" X-OriginalArrivalTime: 12 Jan 2006 21:28:39.0723 (UTC) FILETIME=[2799EFB0:01C617BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Thanks, that clarifies the picture for me. I was focusing on how "transit" L3-only domains know how to support the "needs" of the L5 networks, but do so without having to deal with more than L3 protocol elements. L5 peering can treat any intermediate L3 networks as just a (invisible) transport pipe between the proxies. Mike > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Sent: Thursday, January 12, 2006 3:52 PM > To: Michael Hammer (mhammer) > Cc: voipeer@lists.uoregon.edu; speermint@ietf.org > Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP Peering Policy >=20 > Network 1 contains the calling host and an outgoing proxy. > Network 2 contains the caller's home server. > Network 3 contains the called party home server. > Network 4 contains the called host and an incoming proxy. >=20 > Of course there must be L3 paths between all these networks=20 > to carry the signalling. That may involve direct L3 peering=20 > or indirect routing via other networks. >=20 > Media takes the short way, from Network 1 to Network 4. =20 > Again, that may involve direct L3 peering between those two=20 > networks, or indirect routing via one or more backbone networks. >=20 > Michael Hammer (mhammer) wrote: > > Tom, > >=20 > > Not following this. > >=20 > > If the network boundary is between a L3+L5 network to a L3-only=20 > > network, how does the L5 peering work? > >=20 > > Mike > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Tom-PT Taylor [mailto:taylor@nortel.com] > >>Sent: Thursday, January 12, 2006 3:27 PM > >>To: Michael Hammer (mhammer) > >>Cc: Stastny Richard; voipeer@lists.uoregon.edu; speermint@ietf.org > >>Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > >>Publishing SIP Peering Policy > >> > >>L5 peering happens at every network boundary, not just the=20 > one at the=20 > >>centre of the call path. In the example I gave three peering=20 > >>relationships are needed. > >> > >>Michael Hammer (mhammer) wrote: > >> > >>>Richard, > >>> > >>>There will be a need to blend terms from the legacy cellular world=20 > >>>with the target NGN/IMS/??? architecture to lead > >> > >>participants from the > >> > >>>known to the unknown. > >>> > >>>WRT the visited v. home, and the need for customized services and=20 > >>>features, the originating L5 "network" should always be the=20 > >>>originator's home IMS servers, and the terminating L5 > >> > >>"network" should > >> > >>>always be the terminator's home IMS servers. This supports the=20 > >>>concept that the service is independent of the access network=20 > >>>technology, in which I include the 3GPP (GSM) v. 3GPP2 > >> > >>(ANSI-41/CDMA) > >> > >>>cellular visited networks. A user should be able to roam/handover=20 > >>>across multiple access network types, to include WiFi and WiMax. > >>> > >>>There are a variety of technologies in play, and we need=20 > to account=20 > >>>for all of them in this brave new world of convergence. > >>> > >>>Mike > >>> > >>> > >>> > >> > >>... > >> > >=20 > >=20 > >=20 >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 17:07:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExAbW-00015X-Pg; Thu, 12 Jan 2006 17:07:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExAbU-00013I-3S for speermint@megatron.ietf.org; Thu, 12 Jan 2006 17:07:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29766 for ; Thu, 12 Jan 2006 17:06:09 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExAiZ-0005ie-Mx for speermint@ietf.org; Thu, 12 Jan 2006 17:14:57 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k0CM6uP09453; Thu, 12 Jan 2006 17:06:56 -0500 (EST) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 16:06:56 -0600 Received: from [127.0.0.1] ([47.130.16.124] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 17:06:54 -0500 Message-ID: <43C6D2F9.5000503@nortel.com> Date: Thu, 12 Jan 2006 17:06:49 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Hammer (mhammer)" Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy References: <072C5B76F7CEAB488172C6F64B30B5E3F5FAC6@xmb-rtp-20b.amer.cisco.com> In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5FAC6@xmb-rtp-20b.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2006 22:06:54.0929 (UTC) FILETIME=[7FA69410:01C617C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: voipeer@lists.uoregon.edu, 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org AFAIK the L3 problem is handled by SLAs, pre-provisioned pipes, and diffserv marking at network egress to request a particular QoS for the packets concerned. Michael Hammer (mhammer) wrote: > Thanks, that clarifies the picture for me. I was focusing on how > "transit" L3-only domains know how to support the "needs" of the L5 > networks, but do so without having to deal with more than L3 protocol > elements. L5 peering can treat any intermediate L3 networks as just a > (invisible) transport pipe between the proxies. > > Mike > > > >>-----Original Message----- >>From: Tom-PT Taylor [mailto:taylor@nortel.com] >>Sent: Thursday, January 12, 2006 3:52 PM >>To: Michael Hammer (mhammer) >>Cc: voipeer@lists.uoregon.edu; speermint@ietf.org >>Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: >>Publishing SIP Peering Policy >> >>Network 1 contains the calling host and an outgoing proxy. >>Network 2 contains the caller's home server. >>Network 3 contains the called party home server. >>Network 4 contains the called host and an incoming proxy. >> >>Of course there must be L3 paths between all these networks >>to carry the signalling. That may involve direct L3 peering >>or indirect routing via other networks. >> >>Media takes the short way, from Network 1 to Network 4. >>Again, that may involve direct L3 peering between those two >>networks, or indirect routing via one or more backbone networks. >> ... _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 18:03:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBTB-0001A3-Rj; Thu, 12 Jan 2006 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBT8-000186-Io for speermint@megatron.ietf.org; Thu, 12 Jan 2006 18:03:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03413 for ; Thu, 12 Jan 2006 18:01:36 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExBaF-0007OU-Rk for speermint@ietf.org; Thu, 12 Jan 2006 18:10:23 -0500 Received: from [64.101.173.213] ([64.101.173.213]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k0CN8rhn018593 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 12 Jan 2006 17:08:55 -0600 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3F5F95C@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3F5F95C@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Thu, 12 Jan 2006 17:02:40 -0600 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org On Jan 12, 2006, at 10:36 AM, Michael Hammer ((mhammer)) wrote: > It would provide a better user experience if the L3 and L5 peering > could > be only loosely coupled so that the media and signaling paths are > not so > tightly bound and the media path takes the shortest geographically, > least number of L3 networks path. This sounds good, and I think we've had a general agreement to not tightly bind L5 routing to L3 routing. Incidental binding is of course going to occur, since However, it may be worth considering that L3 peering often doesn't follow the model of "shortest geographically, least number of L3 networks path". L3 peering often follows elaborate rules of business policy including termination/origination ratios, contract or SLA agreements, route redundancy exercise, etc. -- Dean _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 18:14:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBei-0005OI-Gs; Thu, 12 Jan 2006 18:14:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExBeh-0005OB-RR for speermint@megatron.ietf.org; Thu, 12 Jan 2006 18:14:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04373 for ; Thu, 12 Jan 2006 18:13:35 -0500 (EST) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ExBlq-0007pJ-U5 for speermint@ietf.org; Thu, 12 Jan 2006 18:22:22 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Fri, 13 Jan 2006 00:18:25 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4776@oefeg-s04.oefeg.loc> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYXzOKwt+METbHxQOGQI5bUmXQoHgAAJd87 From: "Stastny Richard" To: "Dean Willis" , "Michael Hammer \(mhammer\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org >However, it may be worth considering that L3 peering often doesn't=20 >follow the model of "shortest geographically, least number of L3=20 >networks path". >L3 peering often follows elaborate rules of business policy including=20 >termination/origination ratios, contract or SLA agreements, route=20 >redundancy exercise, etc. If I come back to Toms example >Network 1 contains the calling host and an outgoing proxy. >Network 2 contains the caller's home server. >Network 3 contains the called party home server. >Network 4 contains the called host and an incoming proxy. If network 1 and 4 are corporate networks, NATed and/or behind a = Firewall, then the L3 "peering" is 1,2,3,4 If network 1 and 4 are featuring public IP addresses, then the L3 is completely independent and depending on peering agreements between the providers. Richard ________________________________ Von: Dean Willis [mailto:dean.willis@softarmor.com] Gesendet: Fr 13.01.2006 00:02 An: Michael Hammer (mhammer) Cc: Stastny Richard; Pfautz, Penn L, NEO; Tom-PT Taylor; = speermint@ietf.org Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP = PeeringPolicy On Jan 12, 2006, at 10:36 AM, Michael Hammer ((mhammer)) wrote: > It would provide a better user experience if the L3 and L5 peering=20 > could > be only loosely coupled so that the media and signaling paths are=20 > not so > tightly bound and the media path takes the shortest geographically, > least number of L3 networks path. This sounds good, and I think we've had a general agreement to not=20 tightly bind L5 routing to L3 routing. Incidental binding is of=20 course going to occur, since However, it may be worth considering that L3 peering often doesn't=20 follow the model of "shortest geographically, least number of L3=20 networks path". L3 peering often follows elaborate rules of business policy including=20 termination/origination ratios, contract or SLA agreements, route=20 redundancy exercise, etc. -- Dean _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Thu Jan 12 19:27:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCnH-0000p0-PH; Thu, 12 Jan 2006 19:27:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCnG-0000ov-3q for speermint@megatron.ietf.org; Thu, 12 Jan 2006 19:27:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12859 for ; Thu, 12 Jan 2006 19:26:29 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCuS-000340-6u for speermint@ietf.org; Thu, 12 Jan 2006 19:35:17 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k0D0RScd001700; Thu, 12 Jan 2006 16:27:28 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k0D0RJaZ001696; Thu, 12 Jan 2006 16:27:19 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 12 Jan 2006 16:27:19 -0800 From: David Meyer To: Dean Willis Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Message-ID: <20060113002719.GA1680@1-4-5.net> References: <072C5B76F7CEAB488172C6F64B30B5E3F5F95C@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 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: , Content-Type: multipart/mixed; boundary="===============1272883429==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============1272883429== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > L3 peering often follows elaborate rules of business policy including =20 > termination/origination ratios, contract or SLA agreements, route =20 > redundancy exercise, etc. Exactly. Dave --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDxvPnORgD1qCZ2KcRAv7CAJ0WSQNqh38r1eisHHVncVErnxP+yQCbBS4+ unMngCpcANTeKdXfYvF5J40= =SiGn -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- --===============1272883429== 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 --===============1272883429==-- From speermint-bounces@ietf.org Thu Jan 12 19:31:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCqU-00028f-7G; Thu, 12 Jan 2006 19:31:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCqS-00028a-TI for speermint@megatron.ietf.org; Thu, 12 Jan 2006 19:31:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13034 for ; Thu, 12 Jan 2006 19:29:47 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExCxc-0003Au-Tz for speermint@ietf.org; Thu, 12 Jan 2006 19:38:36 -0500 Received: from [68.165.240.35] (h-68-165-240-35.mclnva23.covad.net [68.165.240.35]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id k0D0VTTs007677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2006 16:31:31 -0800 Message-ID: <43C6F4B8.6030404@shockey.us> Date: Thu, 12 Jan 2006 19:30:48 -0500 From: Richard Shockey User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy References: <072C5B76F7CEAB488172C6F64B30B5E3F5F95C@xmb-rtp-20b.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: richard@shockey.us X-Spam-Score: 0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Dean Willis wrote: > > On Jan 12, 2006, at 10:36 AM, Michael Hammer ((mhammer)) wrote: > >> It would provide a better user experience if the L3 and L5 peering could >> be only loosely coupled so that the media and signaling paths are not so >> tightly bound and the media path takes the shortest geographically, >> least number of L3 networks path. > > This sounds good, and I think we've had a general agreement to not > tightly bind L5 routing to L3 routing. Incidental binding is of course > going to occur, since > > However, it may be worth considering that L3 peering often doesn't > follow the model of "shortest geographically, least number of L3 > networks path". > This again was Dave Oran point in Vancouver. There are clearly user requirements for L3 to L5 linkage but do we want/need to go there right now. -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Fri Jan 13 08:28:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOyQ-0003k1-Ct; Fri, 13 Jan 2006 08:28:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExOyO-0003jn-29 for speermint@megatron.ietf.org; Fri, 13 Jan 2006 08:28:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05263 for ; Fri, 13 Jan 2006 08:26:46 -0500 (EST) 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 1ExP5g-00039c-4S for speermint@ietf.org; Fri, 13 Jan 2006 08:35:42 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 13 Jan 2006 05:27:57 -0800 X-IronPort-AV: i="3.99,365,1131350400"; d="scan'208"; a="391424714:sNHT33065860" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0DDRtjt014941; Fri, 13 Jan 2006 05:27:56 -0800 (PST) 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.211); Fri, 13 Jan 2006 08:27:55 -0500 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: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Date: Fri, 13 Jan 2006 08:27:54 -0500 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3F5FBB6@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP PeeringPolicy Thread-Index: AcYX2CRmM4LmZoN9RYyoYzsRZLJubwAbGo4A From: "Michael Hammer \(mhammer\)" To: "David Meyer" , "Dean Willis" X-OriginalArrivalTime: 13 Jan 2006 13:27:55.0376 (UTC) FILETIME=[29719F00:01C61845] X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org But, it would be interesting to know how the previous designs that assumed BE traffic are meeting or not meeting the needs of real-time traffic. Currently, my home VoIP service is being impacted repeatedly by these same current L3 arrangements (I suspect). Mike > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net]=20 > Sent: Thursday, January 12, 2006 7:27 PM > To: Dean Willis > Cc: Michael Hammer (mhammer); Stastny Richard; speermint@ietf.org > Subject: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D:=20 > Publishing SIP PeeringPolicy >=20 > > L3 peering often follows elaborate rules of business policy=20 > including=20 > > termination/origination ratios, contract or SLA agreements, route=20 > > redundancy exercise, etc. >=20 > Exactly. >=20 > Dave >=20 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Wed Jan 18 09:28:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzEIF-0002Tg-Ct; Wed, 18 Jan 2006 09:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez1I2-0004V9-PC for speermint@megatron.ietf.org; Tue, 17 Jan 2006 19:35:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15861 for ; Tue, 17 Jan 2006 19:33:40 -0500 (EST) Received: from [159.226.7.151] (helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ez1Pk-0001On-MH for speermint@ietf.org; Tue, 17 Jan 2006 19:43:35 -0500 Received: (eyou send program); Wed, 18 Jan 2006 08:33:39 +0800 Message-ID: <337544419.13718@cnnic.cn> X-EYOUMAIL-SMTPAUTH: fengw@cnnic.cn Received: from unknown (HELO taurus) (159.226.6.125) by 159.226.7.151 with SMTP; Wed, 18 Jan 2006 08:33:39 +0800 Date: Wed, 18 Jan 2006 08:33:53 +0800 From: "Wang Feng" To: "speermint" X-mailer: Foxmail 5.0 beta1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 18 Jan 2006 09:28:10 -0500 Subject: [Speermint] subscribe 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org speermint, thanks, Wang Feng fengw@cnnic.cn 2006-01-18 _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Mon Jan 23 11:11:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14Hy-00076t-EH; Mon, 23 Jan 2006 11:11:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14Hw-0006y3-J2 for speermint@megatron.ietf.org; Mon, 23 Jan 2006 11:11:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29974 for ; Mon, 23 Jan 2006 11:09:50 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14RA-0003Mu-87 for speermint@ietf.org; Mon, 23 Jan 2006 11:21:01 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k0NGAxF27229 for ; Mon, 23 Jan 2006 11:10:59 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006012311110213186 for ; Mon, 23 Jan 2006 11:11:02 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Jan 2006 11:11:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jan 2006 11:11:02 -0500 Message-ID: Thread-Topic: Status of SPEERMINT WG Creation? Thread-Index: AcYgN567LoCZbXeXQpKv8ALQ5I5HNw== From: "Haluska, John J" To: X-OriginalArrivalTime: 23 Jan 2006 16:11:02.0718 (UTC) FILETIME=[9B48FDE0:01C62037] X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Speermint] Status of SPEERMINT WG Creation? 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="===============1100281491==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============1100281491== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62037.9AE9631D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62037.9AE9631D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello=20 =20 Does anyone know the status of the SPEERMINT working group creation? I don't see it in the minutes of any of the IESG teleconferences, nor is it on the current agenda (for the 2 Feb teleconference). I thought there was a limit of 2 BOF meetings, so I'm not sure what can/will happen at IETF65, unless simply changing the name of the BOF from VOIPEER to SPEERMINT gives another 2 meetings. =20 =20 John Haluska =20 =20 =20 =20 ------_=_NextPart_001_01C62037.9AE9631D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

Does anyone know the status of the SPEERMINT working = group creation?  I don’t see it in the minutes of any of  = the  IESG teleconferences, nor is it  on the current agenda (for the 2 = Feb teleconference). I thought there was a limit of 2 BOF meetings, so = I’m not sure what can/will happen at IETF65, unless simply changing the name = of the BOF from VOIPEER to SPEERMINT gives another 2 = meetings.

 

 

John Haluska

 

 

 

 

=00 ------_=_NextPart_001_01C62037.9AE9631D-- --===============1100281491== 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 --===============1100281491==-- From speermint-bounces@ietf.org Mon Jan 23 11:27:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14XO-0001cc-Mh; Mon, 23 Jan 2006 11:27:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F14XM-0001cT-EV for speermint@megatron.ietf.org; Mon, 23 Jan 2006 11:27:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00768 for ; Mon, 23 Jan 2006 11:25:55 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F14gi-0003pT-U3 for speermint@ietf.org; Mon, 23 Jan 2006 11:37:06 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k0NGREVt031587; Mon, 23 Jan 2006 08:27:14 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k0NGRDpa031586; Mon, 23 Jan 2006 08:27:13 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 23 Jan 2006 08:27:13 -0800 From: David Meyer To: "Haluska, John J" Subject: Re: [Speermint] Status of SPEERMINT WG Creation? Message-ID: <20060123162713.GA31541@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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="===============2066881990==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============2066881990== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John, > Does anyone know the status of the SPEERMINT working group creation? I > don't see it in the minutes of any of the IESG teleconferences, nor is > it on the current agenda (for the 2 Feb teleconference). I thought > there was a limit of 2 BOF meetings, so I'm not sure what can/will > happen at IETF65, unless simply changing the name of the BOF from > VOIPEER to SPEERMINT gives another 2 meetings. We're not planning another BOF (and I would hope that the name change would not trigger the availablity of another 2 BOFs, since we all know what's going on here).=20 That being said, the IESG did discuss the charter on the January 19, 2006 telechat. I'll leave it to our ADs to fill in the details of that.=20 Dave --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFD1QPhORgD1qCZ2KcRAqf9AJ0cy/K6wE2CeoUm6+MiDfEa4IzQsQCfRL8q lLCuY6L9iXf40SrnqSRjmIw= =0IDs -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- --===============2066881990== 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 --===============2066881990==-- From speermint-bounces@ietf.org Tue Jan 24 09:13:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1OvD-0002kh-Kz; Tue, 24 Jan 2006 09:13:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1OvB-0002jV-2z for speermint@megatron.ietf.org; Tue, 24 Jan 2006 09:13:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14330 for ; Tue, 24 Jan 2006 09:11:41 -0500 (EST) Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1P4Z-0003U6-Qk for speermint@ietf.org; Tue, 24 Jan 2006 09:23:06 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k0OECuq10023; Tue, 24 Jan 2006 09:12:56 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006012409125932406 ; Tue, 24 Jan 2006 09:12:59 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 Jan 2006 09:12:59 -0500 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] Status of SPEERMINT WG Creation? Date: Tue, 24 Jan 2006 09:12:59 -0500 Message-ID: Thread-Topic: [Speermint] Status of SPEERMINT WG Creation? Thread-Index: AcYgOeqSP3SLGFH9RAKJBJr0JT5ynAAtfezw From: "Haluska, John J" To: , X-OriginalArrivalTime: 24 Jan 2006 14:12:59.0914 (UTC) FILETIME=[48049EA0:01C620F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Dave Thanks for your reply. Do you have any idea when and through what mechanism (w.g. this list, IETF Announce list, IESG minutes posting, etc) we can expect to learn the outcome of the IESG discussion? John Haluska -----Original Message----- From: dmm@1-4-5.net [mailto:dmm@1-4-5.net]=20 Sent: Monday, January 23, 2006 11:27 AM To: Haluska, John J Cc: speermint@ietf.org Subject: Re: [Speermint] Status of SPEERMINT WG Creation? John, > Does anyone know the status of the SPEERMINT working group creation? I > don't see it in the minutes of any of the IESG teleconferences, nor is > it on the current agenda (for the 2 Feb teleconference). I thought > there was a limit of 2 BOF meetings, so I'm not sure what can/will > happen at IETF65, unless simply changing the name of the BOF from > VOIPEER to SPEERMINT gives another 2 meetings. We're not planning another BOF (and I would hope that the name change would not trigger the availablity of another 2 BOFs, since we all know what's going on here).=20 That being said, the IESG did discuss the charter on the January 19, 2006 telechat. I'll leave it to our ADs to fill in the details of that.=20 Dave _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Tue Jan 24 10:17:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1PvA-0000ug-V8; Tue, 24 Jan 2006 10:17:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Pv9-0000uV-DG for speermint@megatron.ietf.org; Tue, 24 Jan 2006 10:17:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19063 for ; Tue, 24 Jan 2006 10:15:52 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Q4h-0005se-TU for speermint@ietf.org; Tue, 24 Jan 2006 10:27:17 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k0OFGvVY029383; Tue, 24 Jan 2006 07:16:57 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k0OFGvMM029382; Tue, 24 Jan 2006 07:16:57 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 24 Jan 2006 07:16:57 -0800 From: David Meyer To: "Haluska, John J" Subject: Re: [Speermint] Status of SPEERMINT WG Creation? Message-ID: <20060124151657.GA29333@1-4-5.net> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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="===============1686205724==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============1686205724== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2006 at 09:12:59AM -0500, Haluska, John J wrote: > Dave >=20 > Thanks for your reply. Do you have any idea when and through what > mechanism (w.g. this list, IETF Announce list, IESG minutes posting, > etc) we can expect to learn the outcome of the IESG discussion? My understanding is that we will see an announcement on the announce list in the few days. Dave --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFD1kTpORgD1qCZ2KcRApA0AJ95X1xB0WVvnXiDRkIP0LAGdQZkpwCfX2s7 WtQkhjHnA5ngVW3cXgZewSA= =77Wq -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- --===============1686205724== 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 --===============1686205724==-- From speermint-bounces@ietf.org Fri Jan 27 11:50:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2WoC-0001Po-79; Fri, 27 Jan 2006 11:50:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Wo9-0001Pf-Sb for speermint@megatron.ietf.org; Fri, 27 Jan 2006 11:50:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25560 for ; Fri, 27 Jan 2006 11:49:12 -0500 (EST) Received: from host18-98.pool875.interbusiness.it ([87.5.98.18] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F2WyK-0005wC-IA for speermint@ietf.org; Fri, 27 Jan 2006 12:01:18 -0500 Message-ID: <000001c6238b$91316e80$0100007f@localhost> From: "Diego Green" To: Date: Fri, 27 Jan 2006 17:50:14 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Speermint] 0EM Software 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="===============0729854024==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org This is a multi-part message in MIME format. --===============0729854024== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6238B.9098D800" This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6238B.9098D800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable.TOP.10.NEW.TITLES.ON.SALE.NOW!.1.Office.Pro.2003.2.Adobe.Photoshop.9.0.3.Windows.XP.Pro.4.Adobe.Acrobat.7.Pro.5.Flash.MX.2004.6.Corel.Draw.12.7.Norton.Antivirus.2005.8.Windows.2003.Se ListPrice: $550.00 OurPrice: $69.95 YouSave: $480.05 ( 87%) Availability: Available for INSTANT download! Sales Rank: #1 Average Customer Review: (based on 49 reviews) -------------------------------------------------------------------------------- Microsoft Windows XP Professional by Microsoft ListPrice: $200.00 OurPrice: $49.95 YouSave: $150.05 ( 75%) Availability: Available for INSTANT download! Sales Rank: #2 Average Customer Review: (based on 31 reviews) -------------------------------------------------------------------------------- Adobe Photoshop CS2 V 9.0 by Adobe ListPrice: $599.00 OurPrice: $69.95 YouSave: $529.05 ( 88%) Availability: Available for INSTANT download! Sales Rank: #3 Average Customer Review: (based on 40 reviews) -------------------------------------------------------------------------------- ------=_NextPart_000_0001_01C6238B.9098D800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Software

TOP 10 NEW TITLES

 ON SALE NOW!

  1 Office Pro 2003
  2 Adobe Photoshop 9.0
  3 Windows XP Pro
  4 Adobe Acrobat 7 Pro
  5 Flash MX 2004
  6 Corel Draw 12
  7 Norton Antivirus 2005
  8 Windows 2003 Server
  9 Alias Maya 6 Wavefrt
  10 Adobe Illustrator 11
  See more by this manufacturer
    Microsoft
    Symantec
    Adobe

Microsoft Office Professional Edition 2003
   by Microsoft

ListPrice: $550.00
OurPrice: $69.95
YouSave: $480.05 ( 87%)



Availability: Available for INSTANT download!
!


Sales Rank: #1
Average Customer Review: 3D"5
(based on 47 reviews)

Microsoft Windows XP Professional
   by Microsoft

ListPrice: $200.00
OurPrice: $49.95
YouSave: $150.05 ( 75%)



Availability: Available for INSTANT download!


Sales Rank: #2
Average Customer Review: 3D"5
(based on 47 reviews)!

Adobe Photoshop CS2 V 9.0
   by Adobe

ListPrice: $599.00
OurPrice: $69.95
YouSave: $529.05 ( 88%)



Availability: Available for INSTANT download!


Sales Rank: #3
Average Customer Review: 3D"5
(based on 45 reviews)

------=_NextPart_000_0001_01C6238B.9098D800-- --===============0729854024== 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 --===============0729854024==-- From speermint-bounces@ietf.org Fri Jan 27 13:42:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2YYY-0006oi-M6; Fri, 27 Jan 2006 13:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2YYX-0006oY-Em for speermint@megatron.ietf.org; Fri, 27 Jan 2006 13:42:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03890 for ; Fri, 27 Jan 2006 13:41:11 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2Yik-00014u-0U for speermint@ietf.org; Fri, 27 Jan 2006 13:53:18 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id k0RIgZd8004735; Fri, 27 Jan 2006 10:42:35 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id k0RIgZvo004733; Fri, 27 Jan 2006 10:42:35 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 27 Jan 2006 10:42:35 -0800 From: David Meyer To: speermint@ietf.org Message-ID: <20060127184235.GA4712@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Subject: [Speermint] FYI -- [iesg-secretary@ietf.org: WG Review: Session PEERing for Multimedia INTerconnect (speermint)] 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="===============1789514850==" Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org --===============1789514850== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from IESG Secretary ----- > From: IESG Secretary > To: new-work@ietf.org > Cc:=20 > Subject: WG Review: Session PEERing for Multimedia INTerconnect (speermin= t)=20 > Date: Fri, 27 Jan 2006 13:39:12 -0500 >=20 > A new IETF working group has been proposed in the Real-time Applications = and > Infrastruture Area Directors Area. The IESG has not made any determinati= on=20 > as yet. The following draft charter was submitted, and is provided for= =20 > informational purposes only. Please send your comments to the IESG maili= ng=20 > list (iesg@ietf.org) by February 1st. >=20 > +++ >=20 > Session PEERing for Multimedia INTerconnect (speermint)=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > Current Status: Proposed Working Group >=20 > Chair(s): > TBD >=20 > Real-time Applications and Infrastruture Area Directors > TBD >=20 > Real-time Applications and Infrastructure Area Advisor: > Allison Mankin >=20 > Mailing Lists: > General Discussion: speermint@ietf.org > To Subscribe: speermint-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/speermint/inde= x.html >=20 > Description of Working Group: >=20 > The term "VoIP Peering" has historically been used to describe > inter-provider network interconnect and the delivery of voice > calls over interconnection points. While voice calls are the > primary motivation for this today, other forms of real-time > communications are and will continue to evolve as natural > additions to such peering. Therefore, the focus of this working > group is best generalized to describe calls as sessions, and to > note that that such communications are inherently real-time in > nature. >=20 > SPEERMINT focuses architectures to identify, signal, and route > delay-sensitive (real-time) communication sessions at the > application level ("layer 5"). These sessions use the SIP > signaling protocol to enable peering between two or more > administrative domains over IP networks. Where these domains > peer, or meet, the establishment of trust, security, and a > resistance to abuse and attack are all important > considerations. >=20 > Note that the term "Layer 5 network" is used here to refer to > the interconnection between application layer entities such as > SIP servers, as opposed to interconnection at the IP network > layer. However, in order to achieve real-time Session PEERing, > both signaling and media flows must be taken into > consideration. In addition, the working group recognizes that > there will be use cases that require SPEERMINT to focus on the > interaction between the application layer and lower network > layers, or the dependence of specific application layer use > cases on lower layers, so SPEERMINT will have to be prepared to > solve these problems as they arise. >=20 > More specifically, SPEERMINT focuses on real-time session > routing architectures for "layer 5" networks and their associated > use cases. Deliverables here include the specification of the various > types of application flows, such as signaling and media flows, in > such networks, and includes both trunking and peer-to-peer > flows. In addition, SPEERMINT considers and documents requirements > for the feedback of operational conditions (e.g., congestion control) > that enables the application of dynamic policy and recognizes > that various mechanisms for achieving this should be studied as > a potential part of any architecture. In future, as its initial > work completes and the requirements become known, SPEERMINT may seek > rechartering to consider various mechanism to support applying > Quality of Service mechanisms, or to invoke layer 2 and layer 3 > peering in an architecturally sound way in support of real-time > Session PEERING. A charter discussion would consider how to > work with mechanisms developed by other working groups, selecting > and integrating those, but as stated, first the initial milestones > must be completed. >=20 > 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. SPEERMINT will recognize that some of these > providers also control underlying access networks > (facilities-based), while others do not (not facilities-based), > and this fact may present various additional requirements or > use cases for consideration. The working group will develop > one or more use case documents to record the varieties of > the practices, as well as use this recognition as a guide to > maintaining the greatest possible separation of the application > layer from lower layers. >=20 > The SPEERMINT work plan is related to and distinct from the work > plans of the ENUM and SIPPING working groups. While the > the ENUM Working Group is primarily concerned > with the structure and lookup of data for the translation of > E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with > the use of the resulting URI data, as well as non-ENUM-derived > URI data, for use in signaling and routing of real-time > sessions. The SIPPING WG produced the original document in > this area (RFC 3824). The future work in this area will be > produced by SPEERMINT, but RFC 3427, the SIP change process will > be followed as needed. >=20 > Issues that are out of scope for SPEERMINT include:=20 >=20 > o Interoperability, and NITS/profiling of existing protocols > such as SIP, RTP, and SRTP, >=20 > o SPIT prevention. Note, however, that other working groups > may release relevant specifications that become required or > are referenced by various SPEERMINT uses cases and BCPs, >=20 > o Routing of sessions which are not signaled using SIP. In > particular, SPEERMINT is constrained to consider only those > scenarios in which call routing is signaled using the SIP > protocol and addressed by SIP or SIPS URIs. E.164 numbers and > other national or private formats may only be used as defined > within the SIP protocols, and=20 >=20 > o H.323 >=20 > In the goals and milestones, "submit" means to submit the document to the= IESG for publication. >=20 > --- >=20 > Goals and Milestones: >=20 > Jul 2006 Submit SPEERMINT terminology I-D (Informational). >=20 > Sept 2006 Submit I-D defining the SPEERMINT routing architecture > (Informational). >=20 > Dec 2006 Submit I-D defining the message flows associated with the > SPEERMINT routing architecture (Informational). >=20 > Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified > by RFC 3263 (BCP). >=20 > Mar 2007 Submit I-D on the minimum set of requirements for SIP-based > VoIP interconnection (BCP). >=20 > Jul 2007 Submit I-D specifying the use of addressing forms and providing > strong identities (BCP). >=20 > Jul 2007 Submit I-D(s) on use cases (BCP). >=20 > Jul 2007 Propose re-chartering for any additional efforts/considerations,= =20 > or propose conclusion of working group (following approval of > last documents) >=20 >=20 > Input internet-drafts: > draft-meyer-voipeer-terminology-01.txt >=20 > Request For Comments: > None ----- End forwarded message ----- --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFD2mmbORgD1qCZ2KcRAhYnAJ477Y5Jtz7Ymc+8QRWlxJskCYZ58gCeJbg8 ZkXDkWXu6u7c23gNgjzK8OA= =qeI3 -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- --===============1789514850== 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 --===============1789514850==-- From speermint-bounces@ietf.org Fri Jan 27 16:20:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2b12-0008Uh-Lt; Fri, 27 Jan 2006 16:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2b0u-0008Tq-Sp; Fri, 27 Jan 2006 16:20:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17339; Fri, 27 Jan 2006 16:18:40 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2bB9-0006yg-6S; Fri, 27 Jan 2006 16:30:47 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F2b0q-0000cW-KN; Fri, 27 Jan 2006 16:20:08 -0500 Content-Type: text/plain Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Fri, 27 Jan 2006 16:20:08 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: speermint@ietf.org Subject: [Speermint] WG Review: Session PEERing for Multimedia INTerconnect (speermint) X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org A new IETF working group has been proposed in the Real-time Applications and Infrastruture Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by February 1st. +++ Session PEERing for Multimedia INTerconnect (speermint) ======================================================== Current Status: Proposed Working Group Chair(s): TBD Real-time Applications and Infrastruture Area Directors TBD Real-time Applications and Infrastructure Area Advisor: Allison Mankin Mailing Lists: General Discussion: speermint@ietf.org To Subscribe: speermint-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/speermint/index.html Description of Working Group: The term "VoIP Peering" has historically been used to describe inter-provider network interconnect and the delivery of voice calls over interconnection points. While voice calls are the primary motivation for this today, other forms of real-time communications are and will continue to evolve as natural additions to such peering. Therefore, the focus of this working group is best generalized to describe calls as sessions, and to note that that such communications are inherently real-time in nature. SPEERMINT focuses architectures to identify, signal, and route delay-sensitive (real-time) communication sessions at the application level ("layer 5"). These sessions use the SIP signaling protocol to enable peering between two or more administrative domains over IP networks. Where these domains peer, or meet, the establishment of trust, security, and a resistance to abuse and attack are all important considerations. Note that the term "Layer 5 network" is used here to refer to the interconnection between application layer entities such as SIP servers, as opposed to interconnection at the IP network layer. However, in order to achieve real-time Session PEERing, both signaling and media flows must be taken into consideration. In addition, the working group recognizes that there will be use cases that require SPEERMINT to focus on the interaction between the application layer and lower network layers, or the dependence of specific application layer use cases on lower layers, so SPEERMINT will have to be prepared to solve these problems as they arise. More specifically, SPEERMINT focuses on real-time session routing architectures for "layer 5" networks and their associated use cases. Deliverables here include the specification of the various types of application flows, such as signaling and media flows, in such networks, and includes both trunking and peer-to-peer flows. In addition, SPEERMINT considers and documents requirements for the feedback of operational conditions (e.g., congestion control) that enables the application of dynamic policy and recognizes that various mechanisms for achieving this should be studied as a potential part of any architecture. In future, as its initial work completes and the requirements become known, SPEERMINT may seek rechartering to consider various mechanism to support applying Quality of Service mechanisms, or to invoke layer 2 and layer 3 peering in an architecturally sound way in support of real-time Session PEERING. A charter discussion would consider how to work with mechanisms developed by other working groups, selecting and integrating those, but as stated, first the initial milestones must be completed. 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. SPEERMINT will recognize that some of these providers also control underlying access networks (facilities-based), while others do not (not facilities-based), and this fact may present various additional requirements or use cases for consideration. The working group will develop one or more use case documents to record the varieties of the practices, as well as use this recognition as a guide to maintaining the greatest possible separation of the application layer from lower layers. The SPEERMINT work plan is related to and distinct from the work plans of the ENUM and SIPPING working groups. While the the ENUM Working Group is primarily concerned with the structure and lookup of data for the translation of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the use of the resulting URI data, as well as non-ENUM-derived URI data, for use in signaling and routing of real-time sessions. The SIPPING WG produced the original document in this area (RFC 3824). The future work in this area will be produced by SPEERMINT, but RFC 3427, the SIP change process will be followed as needed. Issues that are out of scope for SPEERMINT include: o Interoperability, and NITS/profiling of existing protocols such as SIP, RTP, and SRTP, o SPIT prevention. Note, however, that other working groups may release relevant specifications that become required or are referenced by various SPEERMINT uses cases and BCPs, o Routing of sessions which are not signaled using SIP. In particular, SPEERMINT is constrained to consider only those scenarios in which call routing is signaled using the SIP protocol and addressed by SIP or SIPS URIs. E.164 numbers and other national or private formats may only be used as defined within the SIP protocols, and o H.323 In the goals and milestones, "submit" means to submit the document to the IESG for publication. --- Goals and Milestones: Jul 2006 Submit SPEERMINT terminology I-D (Informational). Sept 2006 Submit I-D defining the SPEERMINT routing architecture (Informational). Dec 2006 Submit I-D defining the message flows associated with the SPEERMINT routing architecture (Informational). Jan 2007 Submit I-D on the use of DNS SRV and NAPTR records as specified by RFC 3263 (BCP). Mar 2007 Submit I-D on the minimum set of requirements for SIP-based VoIP interconnection (BCP). Jul 2007 Submit I-D specifying the use of addressing forms and providing strong identities (BCP). Jul 2007 Submit I-D(s) on use cases (BCP). Jul 2007 Propose re-chartering for any additional efforts/considerations, or propose conclusion of working group (following approval of last documents) Input internet-drafts: draft-meyer-voipeer-terminology-01.txt Request For Comments: None _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jan 29 07:47:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3By1-0007o4-O5; Sun, 29 Jan 2006 07:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Bxz-0007nI-Nr; Sun, 29 Jan 2006 07:47:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25789; Sun, 29 Jan 2006 07:45:34 -0500 (EST) Received: from [219.149.246.165] (helo=34FC6768) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F3C7z-0006hd-Fj; Sun, 29 Jan 2006 07:58:04 -0500 Delivered-To: proceedings@ietf.org Received: from (helo=heroesan.flothow.de) by societe.kundenserver.de with asmtp (TLSv9:EDH-RSA-DES-CBC2-SHA:777) (Exim 3.35 #1) id 15siDF-009VL-00 for rt-iolnealqypbx@cari.com.my; Sun, 29 Jan 2006 06:46:45 -0600 From: "Amado Snyder" Message-Id: <200410031450.i93SahTw002752@www1.gmail.com> To: proceedings@ietf.org Date: Sun, 29 Jan 2006 06:46:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA25789 Cc: speermint@ietf.org, rps@ietf.org, dcp@ietf.org Subject: [Speermint] invasion 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org You've seen it on =9360 Minutes=94 and read the BBC News report =85 now f= ind out just what everyone is talking about and get yourself some Hoodia = Maximum Strength today! Suppress your appetite and feel full and satisfied all day long Increase your energy level hr-white.com kqyou eaaeush syd _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jan 29 10:07:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3E8y-0001Q6-2K; Sun, 29 Jan 2006 10:07:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3E8w-0001Pp-Fh for speermint@megatron.ietf.org; Sun, 29 Jan 2006 10:07:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03460 for ; Sun, 29 Jan 2006 10:05:22 -0500 (EST) Received: from paoakoavas09.cable.comcast.com ([208.17.35.58] helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3EJL-00024A-K3 for speermint@ietf.org; Sun, 29 Jan 2006 10:17:52 -0500 Received: from ([10.20.9.172]) by paoakoavas09.cable.comcast.com with ESMTP id KP-TDCH7.16645590; Sun, 29 Jan 2006 10:06:24 -0500 Received: from PACDCEXCMB01.cable.comcast.com ([10.20.10.113]) by PACDCEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 10:06:03 -0500 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] invasion Date: Sun, 29 Jan 2006 10:06:03 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302A3A001@PACDCEXCMB01.cable.comcast.com> Thread-Topic: [Speermint] invasion Thread-Index: AcYk0r3ZfnaP6ZYjTUO0ROYerIHaWwAEpRtw From: "Livingood, Jason" To: X-OriginalArrivalTime: 29 Jan 2006 15:06:03.0620 (UTC) FILETIME=[85B85A40:01C624E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Apologies to the list. We're trying to sort out how a few pieces of spam are making their way to the list (from non-subscribers). Bear with us. Thanks Jason > -----Original Message----- > From: speermint-bounces@ietf.org=20 > [mailto:speermint-bounces@ietf.org] On Behalf Of Amado Snyder > Sent: Sunday, January 29, 2006 7:47 AM > To: proceedings@ietf.org > Cc: speermint@ietf.org; rps@ietf.org; dcp@ietf.org > Subject: [Speermint] invasion >=20 >=20 > You've seen it on "60 Minutes" and read the BBC News report ...=20 > now find out just what everyone is talking about and get=20 > yourself some Hoodia Maximum Strength today! >=20 > Suppress your appetite and feel full and satisfied all day=20 > long Increase your energy level >=20 > hr-white.com >=20 > kqyou eaaeush syd >=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 Sun Jan 29 12:47:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Gdj-00059s-5U; Sun, 29 Jan 2006 12:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Gdg-00059g-Vs for speermint@megatron.ietf.org; Sun, 29 Jan 2006 12:47:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14128 for ; Sun, 29 Jan 2006 12:45:14 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3Gnz-0006Sg-5z for speermint@ietf.org; Sun, 29 Jan 2006 12:57:46 -0500 Received: from [61.143.135.36] (helo=4C6C6260) by mx2.foretec.com with smtp (Exim 4.24) id 1F3Gd9-0000QZ-AC for speermint@ietf.org; Sun, 29 Jan 2006 12:46:32 -0500 Received: with libation (ZS1.0.0; list NSPR); Sun, 29 Jan 2006 09:45:55 -0800 Received: from MTUS.bard.peanut.com (derelict.devout.com) by haley.com (8.12.1/8.12.9) with SMTP id h974V73v017281 Date: Sun, 29 Jan 2006 09:45:55 -0800 From: "Shelby Pereira" To: announce@ietf.org, owner@ietf.org, speermint@ietf.org Message-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Speermint] Find a sexoholic tonight 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org Offering you a service that helps people get laid! A bunch of sex-addicts are in your area, wanting to hook up! No lame pickup lines, no flowers, no walks on the beach, people here just care about sex ;) Oh, and just to let you know, over 60% of our members already got laid! http://www.hookup-now.net/nr/ _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint From speermint-bounces@ietf.org Sun Jan 29 22:47:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Q0z-0001P3-Fp; Sun, 29 Jan 2006 22:47:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Q0x-0001OQ-Bw for speermint@megatron.ietf.org; Sun, 29 Jan 2006 22:47:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22701 for ; Sun, 29 Jan 2006 22:45:55 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3QBT-0005b8-7k for speermint@ietf.org; Sun, 29 Jan 2006 22:58:32 -0500 Received: from [192.168.2.102] (c-24-1-177-214.hsd1.tx.comcast.net [24.1.177.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k0U3rhCF012583 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 29 Jan 2006 21:53:44 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Speermint] Find a sexoholic tonight Date: Sun, 29 Jan 2006 21:47:18 -0600 To: Shelby Pereira X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit 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: , Sender: speermint-bounces@ietf.org Errors-To: speermint-bounces@ietf.org On Jan 29, 2006, at 11:45 AM, Shelby Pereira wrote: > Offering you a service that helps people get laid! > A bunch of sex-addicts are in your area, wanting to hook up! > Well, I guess this is just another sort of peering-policy. Do they have enum records? -- Dean _______________________________________________ Speermint mailing list Speermint@ietf.org https://www1.ietf.org/mailman/listinfo/speermint