From fluffy@fluffy.im Sun Feb 5 16:27:15 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64A621F858E for ; Sun, 5 Feb 2012 16:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=-1.128, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnQAIXM5VTBS for ; Sun, 5 Feb 2012 16:27:15 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1C21F8550 for ; Sun, 5 Feb 2012 16:27:14 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1590035pbc.31 for ; Sun, 05 Feb 2012 16:27:14 -0800 (PST) Received: by 10.68.225.4 with SMTP id rg4mr42253931pbc.111.1328488034468; Sun, 05 Feb 2012 16:27:14 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id o7sm35135853pbq.8.2012.02.05.16.27.12 (version=SSLv3 cipher=OTHER); Sun, 05 Feb 2012 16:27:13 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <1327954476.49537.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Sun, 5 Feb 2012 17:27:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca> <1327954476.49537.YahooMailNeo@web162002.mail.bf1.yahoo.com> To: Sohel Khan X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 00:27:15 -0000 That makes a lot of sense to me. Do we need a proposal that shows how to = do that and where to put it in SIP? =20 On Jan 30, 2012, at 1:14 PM, Sohel Khan wrote: > Thanks Cullen. > Actually, in my opinion, providers neither will add a SPID nor will = add a known deterministic number. > Instead, providers will implement a stochastic model, and will add a = private encrypted number so that only a provider can decrypt its own = identity in the chain. > =20 > Regards, Sohel Khan > From: Cullen Jennings > To: Sohel Khan =20 > Cc: "dispatch@ietf.org" =20 > Sent: Friday, January 27, 2012 1:56 PM > Subject: Re: [dispatch] SPID Sequence and Loop Detection >=20 >=20 > When doing least cost routing, my experience has been that if A = delivers the call to B that B will then send to C, B wants to hide this = fact from C and certainly wants to hide from A that they the call went = to C. Otherwise B gets cut out and A and C just set up a peering deal = directly.=20 >=20 > So I worry a scheme like this would not work as B's SBC would be = configured to remove this.=20 >=20 >=20 > On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >=20 > > SIP calls routing in an infinite loop in a subset of networks is a = known phenomenon. > > Various SIP methods exist today may be used to detect and mitigate = loops. Operational engineers would like to see a method that indicates = the sequence of providers=92 IDs in the call path. Based on the input = from the operational engineers, we are proposing a new SIP header to detect SIP routing loop. This method is preferred by the = operational engineers of large providers=92 networks. > > =20 > > Assume that a SIP call originating from provider Alpha (SPID: = 77777777) and traversing through provider Bravo (SPID: 55555555), = Charlie (SPID: 33333333), and looping back to Alpha. > > =20 > > With the new method, the SIP INVITE contains the new header SPID = sequence {33333333, 55555555, 77777777}. > > =20 > > If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} = arrives to Alpha=92s network, Alpha will detect 77777777 in the SPID = sequence and conclude that a loop has occurred. > > =20 > > In the above use case, an example =93SPID-sequence=94 header is as = follows: > > SPID-Sequence:;index=3D1; > > SPID-Sequence:;index=3D1.1; > > SPID-Sequence:;index=3D1.2; > > =20 > > A provider wishing not to divulge its SPID, may insert a private or = a blank value. =20 > > SPID-Sequence:;index=3D1; > > SPID-Sequence:;index=3D1.1; > > SPID-Sequence:;index=3D1.2 > > SPID-Sequence:;index=3D1.3; > > A provider should not delete any value from the SPID sequence unless = the SPID is its own. > > We had some discussion in the DISPATCH meetings on ideas such as = this. We would need a broader community support and help to initiate a = work in IETF RTC WG on SPID sequence. > > Please let us know your opinion. > > =20 > >=20 > > =20 > > Regards, Sohel Khan > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 >=20 From D.Malas@cablelabs.com Tue Feb 7 09:08:40 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FACB21F8849 for ; Tue, 7 Feb 2012 09:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifde2reaY9Fx for ; Tue, 7 Feb 2012 09:08:39 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id EEF7221F85F1 for ; Tue, 7 Feb 2012 09:08:28 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q17H7rY7015961; Tue, 7 Feb 2012 10:08:27 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 07 Feb 2012 10:07:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 7 Feb 2012 10:06:18 -0700 From: Daryl Malas To: Cullen Jennings , Sohel Khan Date: Tue, 7 Feb 2012 10:06:16 -0700 Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: Aczlus5wCuEYhKDMRaWFv+eMO+ylXA== Message-ID: In-Reply-To: <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:08:40 -0000 Cullen's point here is very valid. Service Providers acting as an IXC never want to indicate their service provider relationships to their customers. They create interconnects to many service providers to maintain the lowest termination costs in order to increase their margins for LD termination. Sohel describes a real problem. In telecommunication networks, it seems as though we have many different carrier identification mechanisms already defined. I am leery of creating yet another, even if it is encrypted. I would be more inclined to look at existing loop detection mechanisms and see if they will work either: - as currently defined, - need to be extended or - need to be enforced (aka not blocked or reset by a B2BUA). --Daryl On 1/27/12 11:56 AM, "Cullen Jennings" wrote: > >When doing least cost routing, my experience has been that if A delivers >the call to B that B will then send to C, B wants to hide this fact from >C and certainly wants to hide from A that they the call went to C. >Otherwise B gets cut out and A and C just set up a peering deal directly. > >So I worry a scheme like this would not work as B's SBC would be >configured to remove this. > > >On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: > >> SIP calls routing in an infinite loop in a subset of networks is a >>known phenomenon. >> Various SIP methods exist today may be used to detect and mitigate >>loops. Operational engineers would like to see a method that indicates >>the sequence of providers=B9 IDs in the call path. Based on the input fro= m >>the operational engineers, we are proposing a new SIP header >Sequence> to detect SIP routing loop. This method is preferred by the >>operational engineers of large providers=B9 networks. >> =20 >> Assume that a SIP call originating from provider Alpha (SPID: 77777777) >>and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: >>33333333), and looping back to Alpha. >> =20 >> With the new method, the SIP INVITE contains the new header SPID >>sequence {33333333, 55555555, 77777777}. >> =20 >> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>arrives to Alpha=B9s network, Alpha will detect 77777777 in the SPID >>sequence and conclude that a loop has occurred. >> =20 >> In the above use case, an example =B3SPID-sequence=B2 header is as follo= ws: >> SPID-Sequence:;index=3D1; >> SPID-Sequence:;index=3D1.1; >> SPID-Sequence:;index=3D1.2; >> =20 >> A provider wishing not to divulge its SPID, may insert a private or a >>blank value. =20 >> SPID-Sequence:;index=3D1; >> SPID-Sequence:;index=3D1.1; >> SPID-Sequence:;index=3D1.2 >> SPID-Sequence:;index=3D1.3; >> A provider should not delete any value from the SPID sequence unless >>the SPID is its own. >> We had some discussion in the DISPATCH meetings on ideas such as this. >>We would need a broader community support and help to initiate a work in >>IETF RTC WG on SPID sequence. >> Please let us know your opinion. >> =20 >>=20 >> =20 >> Regards, Sohel Khan >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From D.Malas@cablelabs.com Tue Feb 7 09:22:32 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4C921F851D for ; Tue, 7 Feb 2012 09:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvIB+PYVGi-t for ; Tue, 7 Feb 2012 09:22:31 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9A94921F851B for ; Tue, 7 Feb 2012 09:22:31 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q17H7rYD015961; Tue, 7 Feb 2012 10:22:29 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 07 Feb 2012 10:07:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 7 Feb 2012 10:18:32 -0700 From: Daryl Malas To: Hadriel Kaplan , "dispatch@ietf.org list" Date: Tue, 7 Feb 2012 10:18:27 -0700 Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AczlvIOfzdeUe6V4SKyJyl0srX4Jog== Message-ID: In-Reply-To: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:22:32 -0000 Hadriel et al, I support this work, and the result of the work "may" address the issue Sohel has described regarding SSP loop detection. We have all discussed on many occasions how B2BUA's tend to cause challenges in SIP networks. While we will not be the enforcers of the documents defined here, SSP's can request compliance. Compliance will provide them an increased level of interoperability, troubleshooting and supported SIP functionality (or UA capability). =20 Regards, Daryl On 1/24/12 12:15 AM, "Hadriel Kaplan" wrote: >Howdy, >As instructed by DISPATCH chairs, I am re-posting the STRAW Charter >Proposal, as a topic for the Paris meeting. >The proposed charter is as follows: > >Description of STRAW Working Group >=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 >Name: Sip Traversal Required for Applications to Work (STRAW) > >Problem Statement: >Within the context of the SIP protocol and architecture, a Back-to-Back >User Agent (B2BUA) is any SIP device in the logical path between two User >Agents performing a role beyond that of a Proxy as defined in RFC 3261. >The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >in order to terminate dead sessions by generating BYEs; or it may be a >3PCC-style agent only modifying SDP; or it may be a Session Border >Controller performing such functions as in RFC 5853; or it may be an >Enterprise PBX terminating REFERs and such; or it may be a complete UAS >and UAC implementation with a PRI loopback in-between. > >In its most extreme form, the scope of the SIP protocol ends at the UAS >of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >practice, however, users expect some SIP protocol aspects to go beyond >the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >if the B2BUA was not an end unto itself; this is similar to the >expectation that emails work when they cross from POP and IMAP to/from >SMTP. > >It is impossible to normatively define all the behaviors of B2BUAs in >general, or even subsets of them such as SBCs. Unlike consumer NATs, >B2BUAs perform widely varying functions for purposes which may be unique >to their environment, unique to their architecture, or unique to the >wishes of their administrator. Instead of defining all things a given >type of B2BUA must do, a more practical objective would be to define what >very few things any B2BUA must do to make a specific SIP mechanism work, >and let the market decide whether to do those things. > >The name of this working group reflects that practical objective: if >there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >be passed through that straw and used on each side. Or viewed another >way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >circuit, and if we could extend ISDN, what information would we carry in >ISDN across the PRI for a specific SIP mechanism to work end-to-end. > >For example, the WG could produce a document which specifies that the >Max-Forwards header field value should be copied and decremented across >the B2BUA, if the B2BUA wishes to prevent loops. Administrators could >then tell their B2BUA vendors to comply with the document, if the >administrator so wishes. > >Objectives: >The objectives of the STRAW Working Group are to publish normative >documents which define which SIP header fields, parameters, MIME bodies, >body content fields/information, or media-plane characteristics are >required to traverse between the User Agent "sides" of a B2BUA for >specific functions to work. > >Deliverables would indicate which types of B2BUAs would apply or not. >For example, a document defining the requirements for end-to-end >DTLS-SRTP would not apply to B2BUAs which terminate media, such as >transcoders or recorders. > >The intention of this WG is to document such requirements in separate >documents, per SIP or media function, instead of as one document for all >functions. That will both reduce the time to publication, as well a >provide B2BUA administrators and manufacturers with simple >comply/no-comply criteria. > > >Initial Deliverables: >1) A taxonomy document defining role-types of B2BUAs, as a reference for >other deliverables. >2) A document defining the requirements for B2BUAs with respect to loop >detection/prevention. >3) A document defining the requirements for B2BUAs to support end-to-end >and hop-by-hop media-loopback test calls. >4) A document defining the requirements for B2BUAs to support DTLS-SRTP >(RFC 5764) end-to-end. >5) A document defining the requirements for B2BUAs to support STUN >connectivity checks end-to-end. > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From nikos.leontsinis@oteglobe.gr Tue Feb 7 10:35:27 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9328B21F88DA for ; Tue, 7 Feb 2012 10:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5MpIGYQnGqs for ; Tue, 7 Feb 2012 10:35:26 -0800 (PST) Received: from SIROS.OTEGLOBE.GR (siros.oteglobe.gr [62.75.1.217]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF2F21F88D6 for ; Tue, 7 Feb 2012 10:35:26 -0800 (PST) Received: from SIROSMB.OTEGLOBE.GR ([192.168.0.230]) by SIROS.OTEGLOBE.GR ([fe80::e8c2:54e0:f3b8:c92a%10]) with mapi; Tue, 7 Feb 2012 20:35:15 +0200 From: "Leontsinis, Nikos" To: Daryl Malas , Cullen Jennings , Sohel Khan Date: Tue, 7 Feb 2012 20:35:13 +0200 Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: Aczlus5wCuEYhKDMRaWFv+eMO+ylXAAC6oX6 Message-ID: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> References: <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca>, In-Reply-To: Accept-Language: en-US, el-GR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, el-GR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 18:35:27 -0000 I am not 100% sure about this. On some environments say IPX this can be des= irable it is written in the contract I will send you traffic to USA FIXED and you are obliged to route it to carrier B. This is the area wh= ere the SPID could make sense. /nikos ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Da= ryl Malas [D.Malas@cablelabs.com] Sent: Tuesday, February 07, 2012 7:06 PM To: Cullen Jennings; Sohel Khan Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection Cullen's point here is very valid. Service Providers acting as an IXC never want to indicate their service provider relationships to their customers. They create interconnects to many service providers to maintain the lowest termination costs in order to increase their margins for LD termination. Sohel describes a real problem. In telecommunication networks, it seems as though we have many different carrier identification mechanisms already defined. I am leery of creating yet another, even if it is encrypted. I would be more inclined to look at existing loop detection mechanisms and see if they will work either: - as currently defined, - need to be extended or - need to be enforced (aka not blocked or reset by a B2BUA). --Daryl On 1/27/12 11:56 AM, "Cullen Jennings" wrote: > >When doing least cost routing, my experience has been that if A delivers >the call to B that B will then send to C, B wants to hide this fact from >C and certainly wants to hide from A that they the call went to C. >Otherwise B gets cut out and A and C just set up a peering deal directly. > >So I worry a scheme like this would not work as B's SBC would be >configured to remove this. > > >On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: > >> SIP calls routing in an infinite loop in a subset of networks is a >>known phenomenon. >> Various SIP methods exist today may be used to detect and mitigate >>loops. Operational engineers would like to see a method that indicates >>the sequence of providers=B9 IDs in the call path. Based on the input fro= m >>the operational engineers, we are proposing a new SIP header >Sequence> to detect SIP routing loop. This method is preferred by the >>operational engineers of large providers=B9 networks. >> >> Assume that a SIP call originating from provider Alpha (SPID: 77777777) >>and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: >>33333333), and looping back to Alpha. >> >> With the new method, the SIP INVITE contains the new header SPID >>sequence {33333333, 55555555, 77777777}. >> >> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>arrives to Alpha=B9s network, Alpha will detect 77777777 in the SPID >>sequence and conclude that a loop has occurred. >> >> In the above use case, an example =B3SPID-sequence=B2 header is as follo= ws: >> SPID-Sequence:;index=3D1; >> SPID-Sequence:;index=3D1.1; >> SPID-Sequence:;index=3D1.2; >> >> A provider wishing not to divulge its SPID, may insert a private or a >>blank value. >> SPID-Sequence:;index=3D1; >> SPID-Sequence:;index=3D1.1; >> SPID-Sequence:;index=3D1.2 >> SPID-Sequence:;index=3D1.3; >> A provider should not delete any value from the SPID sequence unless >>the SPID is its own. >> We had some discussion in the DISPATCH meetings on ideas such as this. >>We would need a broader community support and help to initiate a work in >>IETF RTC WG on SPID sequence. >> Please let us know your opinion. >> >> >> >> Regards, Sohel Khan >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch DISCLAIMER: This electronic mail message is intended exclusively for the individual or = entity to which it is addressed. This message, together with any attachment= , may contain confidential and legally privileged information. Any views, o= pinions or conclusions expressed in this message are those of the individua= l sender and do not necessarily reflect the views of OTEGLOBE. Any unauthor= ized review, use, printing, copying, retention, disclosure or distribution = is strictly prohibited. If you have received this message in error, please = immediately advise the sender by reply email message to the sender and dele= te all copies of this message. OTEGLOBE cannot accept any responsibility fo= r the accuracy or completeness of this message as it has been transmitted o= ver a public network. If you suspect that the message may have been interce= pted or amended in any way please contact the sender. Thank you. From D.Malas@cablelabs.com Tue Feb 7 11:04:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A844421F880E for ; Tue, 7 Feb 2012 11:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.586 X-Spam-Level: X-Spam-Status: No, score=-99.586 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyYlrMgROwLG for ; Tue, 7 Feb 2012 11:04:50 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E523021F8572 for ; Tue, 7 Feb 2012 11:04:49 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q17J4nsM030827; Tue, 7 Feb 2012 12:04:49 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 07 Feb 2012 12:04:49 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 7 Feb 2012 12:04:49 -0700 From: Daryl Malas To: "Leontsinis, Nikos" , Cullen Jennings , Sohel Khan Date: Tue, 7 Feb 2012 12:04:46 -0700 Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: Aczly1z0k7xjmdPsSGKGHCTf2Pwg7w== Message-ID: In-Reply-To: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:04:50 -0000 Tm90aWNlIEkgc3BlY2lmaWNhbGx5IHNhaWQsICJTZXJ2aWNlIFByb3ZpZGVycyBhY3RpbmcgYXMg YW4gSVhDIG5ldmVyIHdhbnQNCnRvIGluZGljYXRlIHRoZWlyIHNlcnZpY2UgcHJvdmlkZXIgcmVs YXRpb25zaGlwcyB0byB0aGVpciBjdXN0b21lcnMuIg0KVGhpcyBkb2VzIG5vdCBwcmVjbHVkZSBh IGNvbnRyYWN0dWFsIGFncmVlbWVudCBiZXR3ZWVuIHR3byBTU1BzLg0KDQoNCk9uIDIvNy8xMiAx MTozNSBBTSwgIkxlb250c2luaXMsIE5pa29zIiA8bmlrb3MubGVvbnRzaW5pc0BvdGVnbG9iZS5n cj4NCndyb3RlOg0KDQo+SSBhbSBub3QgMTAwJSBzdXJlIGFib3V0IHRoaXMuIE9uIHNvbWUgZW52 aXJvbm1lbnRzIHNheSBJUFggdGhpcyBjYW4gYmUNCj5kZXNpcmFibGUgaXQgaXMgd3JpdHRlbiBp biB0aGUgY29udHJhY3QgSSB3aWxsIHNlbmQgeW91IHRyYWZmaWMgdG8NCj5VU0EgRklYRUQgYW5k IHlvdSBhcmUgb2JsaWdlZCB0byByb3V0ZSBpdCB0byBjYXJyaWVyIEIuIFRoaXMgaXMgdGhlIGFy ZWENCj53aGVyZSB0aGUgU1BJRCBjb3VsZCBtYWtlIHNlbnNlLg0KPg0KPg0KPi9uaWtvcw0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnIFtkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cj5EYXJ5bCBNYWxhcyBbRC5NYWxhc0BjYWJsZWxhYnMuY29tXQ0KPlNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDA3LCAyMDEyIDc6MDYgUE0NCj5UbzogQ3VsbGVuIEplbm5pbmdzOyBTb2hlbCBLaGFu DQo+Q2M6IGRpc3BhdGNoQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtkaXNwYXRjaF0gU1BJRCBT ZXF1ZW5jZSBhbmQgTG9vcCBEZXRlY3Rpb24NCj4NCj5DdWxsZW4ncyBwb2ludCBoZXJlIGlzIHZl cnkgdmFsaWQuICBTZXJ2aWNlIFByb3ZpZGVycyBhY3RpbmcgYXMgYW4gSVhDDQo+bmV2ZXIgd2Fu dCB0byBpbmRpY2F0ZSB0aGVpciBzZXJ2aWNlIHByb3ZpZGVyIHJlbGF0aW9uc2hpcHMgdG8gdGhl aXINCj5jdXN0b21lcnMuICBUaGV5IGNyZWF0ZSBpbnRlcmNvbm5lY3RzIHRvIG1hbnkgc2Vydmlj ZSBwcm92aWRlcnMgdG8NCj5tYWludGFpbiB0aGUgbG93ZXN0IHRlcm1pbmF0aW9uIGNvc3RzIGlu IG9yZGVyIHRvIGluY3JlYXNlIHRoZWlyIG1hcmdpbnMNCj5mb3IgTEQgdGVybWluYXRpb24uICBT b2hlbCBkZXNjcmliZXMgYSByZWFsIHByb2JsZW0uDQo+DQo+SW4gdGVsZWNvbW11bmljYXRpb24g bmV0d29ya3MsIGl0IHNlZW1zIGFzIHRob3VnaCB3ZSBoYXZlIG1hbnkgZGlmZmVyZW50DQo+Y2Fy cmllciBpZGVudGlmaWNhdGlvbiBtZWNoYW5pc21zIGFscmVhZHkgZGVmaW5lZC4gIEkgYW0gbGVl cnkgb2YgY3JlYXRpbmcNCj55ZXQgYW5vdGhlciwgZXZlbiBpZiBpdCBpcyBlbmNyeXB0ZWQuICBJ IHdvdWxkIGJlIG1vcmUgaW5jbGluZWQgdG8gbG9vayBhdA0KPmV4aXN0aW5nIGxvb3AgZGV0ZWN0 aW9uIG1lY2hhbmlzbXMgYW5kIHNlZSBpZiB0aGV5IHdpbGwgd29yayBlaXRoZXI6DQo+LSBhcyBj dXJyZW50bHkgZGVmaW5lZCwNCj4tIG5lZWQgdG8gYmUgZXh0ZW5kZWQgb3INCj4tIG5lZWQgdG8g YmUgZW5mb3JjZWQgKGFrYSBub3QgYmxvY2tlZCBvciByZXNldCBieSBhIEIyQlVBKS4NCj4NCj4t LURhcnlsDQo+DQo+T24gMS8yNy8xMiAxMTo1NiBBTSwgIkN1bGxlbiBKZW5uaW5ncyIgPGZsdWZm eUBpaWkuY2E+IHdyb3RlOg0KPg0KPj4NCj4+V2hlbiBkb2luZyBsZWFzdCBjb3N0IHJvdXRpbmcs IG15IGV4cGVyaWVuY2UgaGFzIGJlZW4gdGhhdCBpZiBBIGRlbGl2ZXJzDQo+PnRoZSBjYWxsIHRv IEIgdGhhdCBCIHdpbGwgdGhlbiBzZW5kIHRvIEMsIEIgd2FudHMgdG8gaGlkZSB0aGlzIGZhY3Qg ZnJvbQ0KPj5DIGFuZCBjZXJ0YWlubHkgd2FudHMgdG8gaGlkZSBmcm9tIEEgdGhhdCB0aGV5IHRo ZSBjYWxsIHdlbnQgdG8gQy4NCj4+T3RoZXJ3aXNlIEIgZ2V0cyBjdXQgb3V0IGFuZCBBIGFuZCBD IGp1c3Qgc2V0IHVwIGEgcGVlcmluZyBkZWFsIGRpcmVjdGx5Lg0KPj4NCj4+U28gSSB3b3JyeSBh IHNjaGVtZSBsaWtlIHRoaXMgd291bGQgbm90IHdvcmsgYXMgQidzIFNCQyB3b3VsZCBiZQ0KPj5j b25maWd1cmVkIHRvIHJlbW92ZSB0aGlzLg0KPj4NCj4+DQo+Pk9uIEphbiAyMywgMjAxMiwgYXQg MTo1MCBQTSwgU29oZWwgS2hhbiB3cm90ZToNCj4+DQo+Pj4gU0lQIGNhbGxzIHJvdXRpbmcgaW4g YW4gaW5maW5pdGUgbG9vcCBpbiBhIHN1YnNldCBvZiBuZXR3b3JrcyBpcyBhDQo+Pj5rbm93biBw aGVub21lbm9uLg0KPj4+IFZhcmlvdXMgU0lQIG1ldGhvZHMgZXhpc3QgdG9kYXkgbWF5IGJlIHVz ZWQgdG8gZGV0ZWN0IGFuZCBtaXRpZ2F0ZQ0KPj4+bG9vcHMuIE9wZXJhdGlvbmFsIGVuZ2luZWVy cyB3b3VsZCBsaWtlIHRvIHNlZSBhIG1ldGhvZCB0aGF0IGluZGljYXRlcw0KPj4+dGhlIHNlcXVl bmNlIG9mIHByb3ZpZGVyc6n2IElEcyBpbiB0aGUgY2FsbCBwYXRoLiBCYXNlZCBvbiB0aGUgaW5w dXQgZnJvbQ0KPj4+dGhlIG9wZXJhdGlvbmFsIGVuZ2luZWVycywgd2UgYXJlIHByb3Bvc2luZyBh IG5ldyBTSVAgaGVhZGVyIDxTUElEDQo+Pj5TZXF1ZW5jZT4gdG8gZGV0ZWN0IFNJUCByb3V0aW5n IGxvb3AuIFRoaXMgbWV0aG9kIGlzIHByZWZlcnJlZCBieSB0aGUNCj4+Pm9wZXJhdGlvbmFsIGVu Z2luZWVycyBvZiBsYXJnZSBwcm92aWRlcnOp9iBuZXR3b3Jrcy4NCj4+Pg0KPj4+IEFzc3VtZSB0 aGF0IGEgU0lQIGNhbGwgb3JpZ2luYXRpbmcgZnJvbSBwcm92aWRlciBBbHBoYSAoU1BJRDogNzc3 Nzc3NzcpDQo+Pj5hbmQgdHJhdmVyc2luZyB0aHJvdWdoIHByb3ZpZGVyIEJyYXZvIChTUElEOiA1 NTU1NTU1NSksIENoYXJsaWUgKFNQSUQ6DQo+Pj4zMzMzMzMzMyksIGFuZCBsb29waW5nIGJhY2sg dG8gQWxwaGEuDQo+Pj4NCj4+PiBXaXRoIHRoZSBuZXcgbWV0aG9kLCB0aGUgU0lQIElOVklURSBj b250YWlucyB0aGUgbmV3IGhlYWRlciBTUElEDQo+Pj5zZXF1ZW5jZSB7MzMzMzMzMzMsIDU1NTU1 NTU1LCA3Nzc3Nzc3N30uDQo+Pj4NCj4+PiBJZiBhIFNJUCBJTlZJVEUgd2l0aCBTUElEIHNlcXVl bmNlIHszMzMzMzMzMywgNTU1NTU1NTUsIDc3Nzc3Nzc3fQ0KPj4+YXJyaXZlcyB0byBBbHBoYan2 cyBuZXR3b3JrLCBBbHBoYSB3aWxsIGRldGVjdCA3Nzc3Nzc3NyBpbiB0aGUgU1BJRA0KPj4+c2Vx dWVuY2UgYW5kIGNvbmNsdWRlIHRoYXQgYSBsb29wIGhhcyBvY2N1cnJlZC4NCj4+Pg0KPj4+IElu IHRoZSBhYm92ZSB1c2UgY2FzZSwgYW4gZXhhbXBsZSCp+FNQSUQtc2VxdWVuY2Wp9yBoZWFkZXIg aXMgYXMgZm9sbG93czoNCj4+PiBTUElELVNlcXVlbmNlOjxzaXA6MzMzMzMzMzM+O2luZGV4PTE7 DQo+Pj4gU1BJRC1TZXF1ZW5jZTo8c2lwOjU1NTU1NTU1PjtpbmRleD0xLjE7DQo+Pj4gU1BJRC1T ZXF1ZW5jZTo8c2lwOjc3Nzc3Nzc3PjtpbmRleD0xLjI7DQo+Pj4NCj4+PiBBIHByb3ZpZGVyIHdp c2hpbmcgbm90IHRvIGRpdnVsZ2UgaXRzIFNQSUQsIG1heSBpbnNlcnQgYSBwcml2YXRlIG9yIGEN Cj4+PmJsYW5rIHZhbHVlLg0KPj4+IFNQSUQtU2VxdWVuY2U6PHNpcDozMzMzMzMzMz47aW5kZXg9 MTsNCj4+PiBTUElELVNlcXVlbmNlOjxzaXA6NTU1NTU1NTU+O2luZGV4PTEuMTsNCj4+PiBTUElE LVNlcXVlbmNlOjxzaXA6Nzc3Nzc3Nzc+O2luZGV4PTEuMg0KPj4+IFNQSUQtU2VxdWVuY2U6PHNp cDpQUklWQVRFPjtpbmRleD0xLjM7DQo+Pj4gQSBwcm92aWRlciBzaG91bGQgbm90IGRlbGV0ZSBh bnkgdmFsdWUgZnJvbSB0aGUgU1BJRCBzZXF1ZW5jZSB1bmxlc3MNCj4+PnRoZSBTUElEIGlzIGl0 cyBvd24uDQo+Pj4gV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBpbiB0aGUgRElTUEFUQ0ggbWVldGlu Z3Mgb24gaWRlYXMgc3VjaCBhcyB0aGlzLg0KPj4+V2Ugd291bGQgbmVlZCBhIGJyb2FkZXIgY29t bXVuaXR5IHN1cHBvcnQgYW5kIGhlbHAgdG8gaW5pdGlhdGUgYSB3b3JrIGluDQo+Pj5JRVRGIFJU QyBXRyBvbiBTUElEIHNlcXVlbmNlLg0KPj4+IFBsZWFzZSBsZXQgdXMga25vdyB5b3VyIG9waW5p b24uDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gUmVnYXJkcywgU29oZWwgS2hhbg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gZGlzcGF0Y2ggbWFp bGluZyBsaXN0DQo+Pj4gZGlzcGF0Y2hAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5kaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+ZGlz cGF0Y2hAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aXNwYXRjaA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+ZGlzcGF0Y2hAaWV0Zi5vcmcNCj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQo+DQo+RElTQ0xBSU1F UjoNCj5UaGlzIGVsZWN0cm9uaWMgbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5 IGZvciB0aGUgaW5kaXZpZHVhbA0KPm9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQu IFRoaXMgbWVzc2FnZSwgdG9nZXRoZXIgd2l0aCBhbnkNCj5hdHRhY2htZW50LCBtYXkgY29udGFp biBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4NCj5Bbnkg dmlld3MsIG9waW5pb25zIG9yIGNvbmNsdXNpb25zIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mDQo+dGhlIGluZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgbmVjZXNzYXJp bHkgcmVmbGVjdCB0aGUgdmlld3Mgb2YNCj5PVEVHTE9CRS4gQW55IHVuYXV0aG9yaXplZCByZXZp ZXcsIHVzZSwgcHJpbnRpbmcsIGNvcHlpbmcsIHJldGVudGlvbiwNCj5kaXNjbG9zdXJlIG9yIGRp c3RyaWJ1dGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZA0K PnRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IGFkdmlzZSB0aGUgc2Vu ZGVyIGJ5IHJlcGx5DQo+ZW1haWwgbWVzc2FnZSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxs IGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuDQo+T1RFR0xPQkUgY2Fubm90IGFjY2VwdCBhbnkgcmVz cG9uc2liaWxpdHkgZm9yIHRoZSBhY2N1cmFjeSBvcg0KPmNvbXBsZXRlbmVzcyBvZiB0aGlzIG1l c3NhZ2UgYXMgaXQgaGFzIGJlZW4gdHJhbnNtaXR0ZWQgb3ZlciBhIHB1YmxpYw0KPm5ldHdvcmsu IElmIHlvdSBzdXNwZWN0IHRoYXQgdGhlIG1lc3NhZ2UgbWF5IGhhdmUgYmVlbiBpbnRlcmNlcHRl ZCBvcg0KPmFtZW5kZWQgaW4gYW55IHdheSBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyLiBUaGFu ayB5b3UuDQoNCg== From mary.ietf.barnes@gmail.com Tue Feb 7 11:10:56 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18EF21F8878 for ; Tue, 7 Feb 2012 11:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.61 X-Spam-Level: X-Spam-Status: No, score=-103.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG9H6Vc7Te4y for ; Tue, 7 Feb 2012 11:10:55 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D22E21F8877 for ; Tue, 7 Feb 2012 11:10:54 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so5360613vcb.31 for ; Tue, 07 Feb 2012 11:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=g5g2Ch3KvBg337OU5f5Au2TQGWSrCrRhhJtR7Gu8znA=; b=lY/vX6fynVV0PtGVbRAqS5L7aoT0jIyFVfmql30OQ6WFotvRe3Z5CSa15EWAI0T0tc gGXIcoAHu8bLg3HUlK+kwRdTyRNw55S7/QHNt1O9fLGlOLptZxXrz4E9iBBx8viOh+MA f6RxYybAIrqxFL9KtC5q05ONmDskVt1Sz9KEo= MIME-Version: 1.0 Received: by 10.52.35.148 with SMTP id h20mr11068215vdj.21.1328641854218; Tue, 07 Feb 2012 11:10:54 -0800 (PST) Received: by 10.52.114.200 with HTTP; Tue, 7 Feb 2012 11:10:54 -0800 (PST) Date: Tue, 7 Feb 2012 13:10:54 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , rai-ads@tools.ietf.org Subject: [dispatch] Topics for DISPATCH @ IETF-83 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:10:56 -0000 Hi all, Based on the maturity of the proposals and WG discussions, the following two topics are proposed for the DISPATCH WG session at IETF-83: - STRAW (Hadriel): http://www.ietf.org/mail-archive/web/dispatch/current/msg04061.html - MESS (Magnus or Bo): http://www.ietf.org/mail-archive/web/dispatch/current/msg04055.html We will post a preliminary agenda shortly. Note, that the following topics were put forth, but they need more feedback and/or further refinement: - Load Balancing: http://www.ietf.org/mail-archive/web/dispatch/current/msg04060.html - SPID Sequence and Loop detection: http://www.ietf.org/mail-archive/web/dispatch/current/msg04058.html The following topics are being dispatched as follows: - Overlay for RELOAD - to be discussed/considered in P2PSIP WG http://www.ietf.org/mail-archive/web/dispatch/current/msg04052.html - XCON indicator - to be considered for AD sponsorship: http://www.ietf.org/mail-archive/web/dispatch/current/msg04054.html Thanks, Mary. From sohel_khan777@yahoo.com Tue Feb 7 11:29:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3621F887E for ; Tue, 7 Feb 2012 11:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6ibBZepYkQz for ; Tue, 7 Feb 2012 11:29:03 -0800 (PST) Received: from nm37-vm5.bullet.mail.bf1.yahoo.com (nm37-vm5.bullet.mail.bf1.yahoo.com [72.30.238.205]) by ietfa.amsl.com (Postfix) with SMTP id 877A621F887D for ; Tue, 7 Feb 2012 11:29:03 -0800 (PST) Received: from [98.139.215.142] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 19:29:00 -0000 Received: from [98.139.212.207] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 19:29:00 -0000 Received: from [127.0.0.1] by omp1016.mail.bf1.yahoo.com with NNFMP; 07 Feb 2012 19:29:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 452340.12900.bm@omp1016.mail.bf1.yahoo.com Received: (qmail 770 invoked by uid 60001); 7 Feb 2012 19:29:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1328642940; bh=BwDocDgcwY5uklZCC8QaqJQB5XVDU51x8UUmfPCxr6E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dkr0dAlXKnza2/G0sOIkwBStB4beNWJUz6WYefkgsJZngUnHECa+ZX9s7HlaFtqP7V+seFA2EeaKC33PjrnM+dryjDIx8n2s3mjwlL8LX3B39btGO+mBi7LJyO/qGHKLE3bA1l9zP2xcO4BZHK4HSLgAaiZykdwBM8zc50rskYE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G1+y2zuxlEjz8FjgRJjLEPAyl5yHy7Chc9i/N6cHmDJJ+GfmQbPdO8PMRLYzawclobAmMNndZ8pYRKVFSlfibeopvl5AY/cNLl7OoF3syo+m+7TJQYjBXIYDK1f/oBKV7iPmmq6uA9h45NMfHWtR3vMPjnL+2Nvz3H+FNvJtBaE=; X-YMail-OSG: G6EP4_sVM1mrtocS6yzn8bGqEU76dm9o7Ybzx88Cx4yXMm5 5Z1p14IBzHuP0lP0O1LkFKWioGbyVRUws_s5om70TbBiJ.j3nzYXUndUcnmt LsOF35s1kUeMBtHOUyao48gKJ2ixZaJpRzOG2fJ69WHTkGPagwWh3bfszHx. rfbYmp4.qML5TI8bbJKRtnhs4fDtljhpiEpxeOpV5cuizieQ9z315djq2hgI Ky2pBDX36_DibuNNbTKlHBPClT_hY1oRdjt2iyc0VTQV1dRI73ApMQ4looHs xZxJJ_u1JZRb0I6d.QNEHcTZpSRg15rbFS2qDkndKXS7DJ1oQ1PGeDRqgA0t 1ZaEJcoJvesURlGMn0VM1U2ib4hk8myQCMIBHgiLOiQcTIY50bWEZ8wooMlh PUB9ui_KVzz6dKNwNJE6Kll8GuZzPe_d4pqaAmisDb7wB6GnI42NwDTiEgUQ HSAERQLQ.mYEH6Ovk629kr_7vl2H0hWWt4FudMRGd8pn1f.oT8u8- Received: from [68.87.42.110] by web162005.mail.bf1.yahoo.com via HTTP; Tue, 07 Feb 2012 11:29:00 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> Message-ID: <1328642940.95857.YahooMailNeo@web162005.mail.bf1.yahoo.com> Date: Tue, 7 Feb 2012 11:29:00 -0800 (PST) From: Sohel Khan To: Daryl Malas , "Leontsinis, Nikos" , Cullen Jennings In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1328350513-495744018-1328642940=:95857" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:29:05 -0000 ---1328350513-495744018-1328642940=:95857 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Daryl.=0AThe assertion may or may not be true.=0AIn my opinion, duri= ng the trouble shooting calls operations from all providers attend the call= and aware of all the service providers for a calls. In addition, please no= te that in my proposal, a provider not intending to disclose its informatio= n may add a random number to hide its identity.=0A=A0=0A=0ARegards, Sohel K= han=0A=0A=0A________________________________=0AFrom: Daryl Malas =0ATo: "Leontsinis, Nikos" ; Cul= len Jennings ; Sohel Khan =0ACc: "= dispatch@ietf.org" =0ASent: Tuesday, February 7, 2012 2= :04 PM=0ASubject: Re: [dispatch] SPID Sequence and Loop Detection=0A=0ANoti= ce I specifically said, "Service Providers acting as an IXC never want=0Ato= indicate their service provider relationships to their customers."=0AThis = does not preclude a contractual agreement between two SSPs.=0A=0A=0AOn 2/7/= 12 11:35 AM, "Leontsinis, Nikos" =0Awrote:=0A= =0A>I am not 100% sure about this. On some environments say IPX this can be= =0A>desirable it is written in the contract I will send you traffic to=0A>U= SA FIXED and you are obliged to route it to carrier B. This is the area=0A>= where the SPID could make sense.=0A>=0A>=0A>/nikos=0A>_____________________= ___________________=0A>From: dispatch-bounces@ietf.org [dispatch-bounces@ie= tf.org] On Behalf Of=0A>Daryl Malas [D.Malas@cablelabs.com]=0A>Sent: Tuesda= y, February 07, 2012 7:06 PM=0A>To: Cullen Jennings; Sohel Khan=0A>Cc: disp= atch@ietf.org=0A>Subject: Re: [dispatch] SPID Sequence and Loop Detection= =0A>=0A>Cullen's point here is very valid.=A0 Service Providers acting as a= n IXC=0A>never want to indicate their service provider relationships to the= ir=0A>customers.=A0 They create interconnects to many service providers to= =0A>maintain the lowest termination costs in order to increase their margin= s=0A>for LD termination.=A0 Sohel describes a real problem.=0A>=0A>In telec= ommunication networks, it seems as though we have many different=0A>carrier= identification mechanisms already defined.=A0 I am leery of creating=0A>ye= t another, even if it is encrypted.=A0 I would be more inclined to look at= =0A>existing loop detection mechanisms and see if they will work either:=0A= >- as currently defined,=0A>- need to be extended or=0A>- need to be enforc= ed (aka not blocked or reset by a B2BUA).=0A>=0A>--Daryl=0A>=0A>On 1/27/12 = 11:56 AM, "Cullen Jennings" wrote:=0A>=0A>>=0A>>When doing = least cost routing, my experience has been that if A delivers=0A>>the call = to B that B will then send to C, B wants to hide this fact from=0A>>C and c= ertainly wants to hide from A that they the call went to C.=0A>>Otherwise B= gets cut out and A and C just set up a peering deal directly.=0A>>=0A>>So = I worry a scheme like this would not work as B's SBC would be=0A>>configure= d to remove this.=0A>>=0A>>=0A>>On Jan 23, 2012, at 1:50 PM, Sohel Khan wro= te:=0A>>=0A>>> SIP calls routing in an infinite loop in a subset of network= s is a=0A>>>known phenomenon.=0A>>> Various SIP methods exist today may be = used to detect and mitigate=0A>>>loops. Operational engineers would like to= see a method that indicates=0A>>>the sequence of providers=B9 IDs in the c= all path. Based on the input from=0A>>>the operational engineers, we are pr= oposing a new SIP header >>Sequence> to detect SIP routing loop. T= his method is preferred by the=0A>>>operational engineers of large provider= s=B9 networks.=0A>>>=0A>>> Assume that a SIP call originating from provider= Alpha (SPID: 77777777)=0A>>>and traversing through provider Bravo (SPID: 5= 5555555), Charlie (SPID:=0A>>>33333333), and looping back to Alpha.=0A>>>= =0A>>> With the new method, the SIP INVITE contains the new header SPID=0A>= >>sequence {33333333, 55555555, 77777777}.=0A>>>=0A>>> If a SIP INVITE with= SPID sequence {33333333, 55555555, 77777777}=0A>>>arrives to Alpha=B9s net= work, Alpha will detect 77777777 in the SPID=0A>>>sequence and conclude tha= t a loop has occurred.=0A>>>=0A>>> In the above use case, an example =B3SPI= D-sequence=B2 header is as follows:=0A>>> SPID-Sequence:;inde= x=3D1;=0A>>> SPID-Sequence:;index=3D1.1;=0A>>> SPID-Sequence:= ;index=3D1.2;=0A>>>=0A>>> A provider wishing not to divulge i= ts SPID, may insert a private or a=0A>>>blank value.=0A>>> SPID-Sequence:;index=3D1;=0A>>> SPID-Sequence:;index=3D1.1;=0A>= >> SPID-Sequence:;index=3D1.2=0A>>> SPID-Sequence:;index=3D1.3;=0A>>> A provider should not delete any value from the SPID = sequence unless=0A>>>the SPID is its own.=0A>>> We had some discussion in t= he DISPATCH meetings on ideas such as this.=0A>>>We would need a broader co= mmunity support and help to initiate a work in=0A>>>IETF RTC WG on SPID seq= uence.=0A>>> Please let us know your opinion.=0A>>>=0A>>>=0A>>>=0A>>> Regar= ds, Sohel Khan=0A>>> _______________________________________________=0A>>> = dispatch mailing list=0A>>> dispatch@ietf.org=0A>>> https://www.ietf.org/ma= ilman/listinfo/dispatch =0A>>=0A>>_________________________________________= ______=0A>>dispatch mailing list=0A>>dispatch@ietf.org=0A>>https://www.ietf= .org/mailman/listinfo/dispatch =0A>=0A>____________________________________= ___________=0A>dispatch mailing list=0A>dispatch@ietf.org=0A>https://www.ie= tf.org/mailman/listinfo/dispatch =0A>=0A>=0A>DISCLAIMER:=0A>This electronic= mail message is intended exclusively for the individual=0A>or entity to wh= ich it is addressed. This message, together with any=0A>attachment, may con= tain confidential and legally privileged information.=0A>Any views, opinion= s or conclusions expressed in this message are those of=0A>the individual s= ender and do not necessarily reflect the views of=0A>OTEGLOBE. Any unauthor= ized review, use, printing, copying, retention,=0A>disclosure or distributi= on is strictly prohibited. If you have received=0A>this message in error, p= lease immediately advise the sender by reply=0A>email message to the sender= and delete all copies of this message.=0A>OTEGLOBE cannot accept any respo= nsibility for the accuracy or=0A>completeness of this message as it has bee= n transmitted over a public=0A>network. If you suspect that the message may= have been intercepted or=0A>amended in any way please contact the sender. = Thank you. ---1328350513-495744018-1328642940=:95857 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Daryl.
The assertion may or= may not be true.
In my opinion, durin= g the trouble shooting calls operations from all providers attend the call = and aware of all the service providers for a calls. In addition, please not= e that in my proposal, a provider not intending to disclose its information= may add a random number to hide its identity.
 
 
Regards, Sohel Khan
From:= Daryl Malas <D.Malas@cablelabs.com>
To: "Leontsinis, Nikos" <nikos.leontsinis@= oteglobe.gr>; Cullen Jennings <fluffy@iii.ca>; Sohel Khan <sohe= l_khan777@yahoo.com>
Cc:= "dispatch@ietf.org" <dispatch@ietf.org>
Sent: Tuesday, February 7, 2012 2:04 PM
<= SPAN style=3D"FONT-WEIGHT: bold">Subject: Re: [dispatch] SPID Se= quence and Loop Detection

Notice I specifically said, "= Service Providers acting as an IXC never want
to indicate their service provide= r relationships to their customers."
This does not preclude a contractua= l agreement between two SSPs.


On 2/7/12 11:35 AM, "Leontsinis, N= ikos" <nikos.leontsinis@oteglobe.gr>
wrot= e:

>I am not 100% sure about this. On some environments say IPX t= his can be
>desirable it is written in the contract I will send you t= raffic to
>USA FIXED and you are obliged to route it to carrier B. Th= is is the area
>where the SPID could make sense.
>
>
&= gt;/nikos
>________________________________________
>From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org= ] On Behalf Of
>Daryl Malas [D.Malas@cablelabs.com]
>= ;Sent: Tuesday, February 07, 2012 7:06 PM
>To: Cullen Jennings; Sohel= Khan
>Cc: dispatch@ietf.org
>Subject: Re: [dispatch] SPID S= equence and Loop Detection
>
>Cullen's point here is very valid= .  Service Providers acting as an IXC
>never want to indicate th= eir service provider relationships to their
>customers.  They cr= eate interconnects to many service providers to
>maintain the lowest = termination costs in order to increase their margins
>for LD terminat= ion.  Sohel describes a real problem.
>
>In telecommunicat= ion networks, it seems as though we have many different
>carrier identification mechanisms already defined.  I am leery of creating>yet another, even if it is encrypted.  I would be more inclined t= o look at
>existing loop detection mechanisms and see if they will wo= rk either:
>- as currently defined,
>- need to be extended or>- need to be enforced (aka not blocked or reset by a B2BUA).
><= BR>>--Daryl
>
>On 1/27/12 11:56 AM, "Cullen Jennings" <fluffy@iii.= ca> wrote:
>
>>
>>When doing least cost rout= ing, my experience has been that if A delivers
>>the call to B tha= t B will then send to C, B wants to hide this fact from
>>C and ce= rtainly wants to hide from A that they the call went to C.
>>Other= wise B gets cut out and A and C just set up a peering deal directly.
>= ;>
>>So I worry a scheme like this would not work as B's SBC would be
>>configured to remove this.
>>
>>
= >>On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote:
>>
>&= gt;> SIP calls routing in an infinite loop in a subset of networks is a<= BR>>>>known phenomenon.
>>> Various SIP methods exist = today may be used to detect and mitigate
>>>loops. Operational = engineers would like to see a method that indicates
>>>the sequ= ence of providers=B9 IDs in the call path. Based on the input from
>&= gt;>the operational engineers, we are proposing a new SIP header <SPI= D
>>>Sequence> to detect SIP routing loop. This method is pr= eferred by the
>>>operational engineers of large providers=B9 n= etworks.
>>>
>>> Assume that a SIP call originating= from provider Alpha (SPID: 77777777)
>>>and traversing through= provider Bravo (SPID: 55555555), Charlie (SPID:
>>>33333333), and looping back to Alpha.
>>>= ;
>>> With the new method, the SIP INVITE contains the new head= er SPID
>>>sequence {33333333, 55555555, 77777777}.
>>= >
>>> If a SIP INVITE with SPID sequence {33333333, 55555555= , 77777777}
>>>arrives to Alpha=B9s network, Alpha will detect = 77777777 in the SPID
>>>sequence and conclude that a loop has o= ccurred.
>>>
>>> In the above use case, an example = =B3SPID-sequence=B2 header is as follows:
>>> SPID-Sequence:<= ;sip:33333333>;index=3D1;
>>> SPID-Sequence:<sip:55555555= >;index=3D1.1;
>>> SPID-Sequence:<sip:77777777>;index= =3D1.2;
>>>
>>> A provider wishing not to divulge i= ts SPID, may insert a private or a
>>>blank value.
>>&= gt; SPID-Sequence:<sip:33333333>;index=3D1;
>>> SPID-Sequence:<sip:55555555>;index=3D1.1;
>>> SPID-Seque= nce:<sip:77777777>;index=3D1.2
>>> SPID-Sequence:<sip:= PRIVATE>;index=3D1.3;
>>> A provider should not delete any v= alue from the SPID sequence unless
>>>the SPID is its own.
&= gt;>> We had some discussion in the DISPATCH meetings on ideas such a= s this.
>>>We would need a broader community support and help t= o initiate a work in
>>>IETF RTC WG on SPID sequence.
>&g= t;> Please let us know your opinion.
>>>
>>>
= >>>
>>> Regards, Sohel Khan
>>> __________= _____________________________________
>>> dispatch mailing list=
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>= ;>
>>_______________________________________________
>>= ;dispatch mailing list
>>dispatch@ietf.org
>>https:/= /www.ietf.org/mailman/listinfo/dispatch
>
>_______________= ________________________________
>dispatch mailing list
>dispatc= h@ietf.org
>https://www.ietf.org/mailman/listinfo/dispatch >
>
>DISCLAIMER:
>This electronic mail message is in= tended exclusively for the individual
>or entity to which it is addre= ssed. This message, together with any
>attachment, may contain confid= ential and legally privileged information.
>Any views, opinions or conclusions = expressed in this message are those of
>the individual sender and do = not necessarily reflect the views of
>OTEGLOBE. Any unauthorized revi= ew, use, printing, copying, retention,
>disclosure or distribution is= strictly prohibited. If you have received
>this message in error, pl= ease immediately advise the sender by reply
>email message to the sen= der and delete all copies of this message.
>OTEGLOBE cannot accept an= y responsibility for the accuracy or
>completeness of this message as= it has been transmitted over a public
>network. If you suspect that = the message may have been intercepted or
>amended in any way please c= ontact the sender. Thank you.



---1328350513-495744018-1328642940=:95857-- From richard@shockey.us Tue Feb 7 16:31:59 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5E121F86FA for ; Tue, 7 Feb 2012 16:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DL-hwY1b70V1 for ; Tue, 7 Feb 2012 16:31:58 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 27E5921F86F8 for ; Tue, 7 Feb 2012 16:31:58 -0800 (PST) Received: (qmail 10965 invoked by uid 0); 8 Feb 2012 00:31:57 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 8 Feb 2012 00:31:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=YYH13RG0yid+YIHCkaInqAcV4q7sQAQ/d28DT9gOewo=; b=d4BhDuugj/j1+AooFv5EZU7xLuxZ5Yg/Z7QKbTWQBLbfYcMrta5NngiEvO103MU4OGqDjLnA+toSiDqIlLzV9OvVn6Fw4lys/wSJfWohoSLGnanKNU6s71AmnEFLuupA; Received: from pool-96-255-226-191.washdc.fios.verizon.net ([96.255.226.191] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RuvS0-0006nq-Ml; Tue, 07 Feb 2012 17:31:57 -0700 From: "Richard Shockey" To: "'Daryl Malas'" , "'Leontsinis, Nikos'" , "'Cullen Jennings'" , "'Sohel Khan'" References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> In-Reply-To: Date: Tue, 7 Feb 2012 19:31:56 -0500 Message-ID: <010101cce5f9$10d3b8b0$327b2a10$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczly1z0k7xjmdPsSGKGHCTf2Pwg7wAK9UQw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.191 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 00:31:59 -0000 Ok .. but the basics are essential. I want to commend to all of you the concept of a Universal SPID embodied = in this draft.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identif= ier -urn-01.txt It needs work and input from everyone here, but the core issue here is identification of issues along the session path especially as it = transits across national boundaries or transit intermediaries. =20 What is the malfunction that we can't agree on a tracing mechanism. = Session ID for goodness sake. DO IT. Charter the damn thing.=20 It may seem trivial. Its not. Especially if you are a regulator looking = at how to create competitive transit markets. Do you all want another = Shockey lecture on what the national regulators are up to ??? =20 Sohel to his eternal credit is starting to identify the larger problem = of the End of POTS. I've avoided proposing a RAI Directorate on End of Life (EOL) issues = with TDM but it's coming.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Daryl Malas Sent: Tuesday, February 07, 2012 2:05 PM To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection Notice I specifically said, "Service Providers acting as an IXC never = want to indicate their service provider relationships to their customers." This does not preclude a contractual agreement between two SSPs. On 2/7/12 11:35 AM, "Leontsinis, Nikos" wrote: >I am not 100% sure about this. On some environments say IPX this can be >desirable it is written in the contract I will send you traffic to >USA FIXED and you are obliged to route it to carrier B. This is the = area >where the SPID could make sense. > > >/nikos >________________________________________ >From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf = Of >Daryl Malas [D.Malas@cablelabs.com] >Sent: Tuesday, February 07, 2012 7:06 PM >To: Cullen Jennings; Sohel Khan >Cc: dispatch@ietf.org >Subject: Re: [dispatch] SPID Sequence and Loop Detection > >Cullen's point here is very valid. Service Providers acting as an IXC >never want to indicate their service provider relationships to their >customers. They create interconnects to many service providers to >maintain the lowest termination costs in order to increase their = margins >for LD termination. Sohel describes a real problem. > >In telecommunication networks, it seems as though we have many = different >carrier identification mechanisms already defined. I am leery of = creating >yet another, even if it is encrypted. I would be more inclined to look = at >existing loop detection mechanisms and see if they will work either: >- as currently defined, >- need to be extended or >- need to be enforced (aka not blocked or reset by a B2BUA). > >--Daryl > >On 1/27/12 11:56 AM, "Cullen Jennings" wrote: > >> >>When doing least cost routing, my experience has been that if A = delivers >>the call to B that B will then send to C, B wants to hide this fact = from >>C and certainly wants to hide from A that they the call went to C. >>Otherwise B gets cut out and A and C just set up a peering deal = directly. >> >>So I worry a scheme like this would not work as B's SBC would be >>configured to remove this. >> >> >>On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >> >>> SIP calls routing in an infinite loop in a subset of networks is a >>>known phenomenon. >>> Various SIP methods exist today may be used to detect and mitigate >>>loops. Operational engineers would like to see a method that = indicates >>>the sequence of providers=B9 IDs in the call path. Based on the input = from >>>the operational engineers, we are proposing a new SIP header >>Sequence> to detect SIP routing loop. This method is preferred by the >>>operational engineers of large providers=B9 networks. >>> >>> Assume that a SIP call originating from provider Alpha (SPID: = 77777777) >>>and traversing through provider Bravo (SPID: 55555555), Charlie = (SPID: >>>33333333), and looping back to Alpha. >>> >>> With the new method, the SIP INVITE contains the new header SPID >>>sequence {33333333, 55555555, 77777777}. >>> >>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>arrives to Alpha=B9s network, Alpha will detect 77777777 in the SPID >>>sequence and conclude that a loop has occurred. >>> >>> In the above use case, an example =B3SPID-sequence=B2 header is as = follows: >>> SPID-Sequence:;index=3D1; >>> SPID-Sequence:;index=3D1.1; >>> SPID-Sequence:;index=3D1.2; >>> >>> A provider wishing not to divulge its SPID, may insert a private or = a >>>blank value. >>> SPID-Sequence:;index=3D1; >>> SPID-Sequence:;index=3D1.1; >>> SPID-Sequence:;index=3D1.2 >>> SPID-Sequence:;index=3D1.3; >>> A provider should not delete any value from the SPID sequence unless >>>the SPID is its own. >>> We had some discussion in the DISPATCH meetings on ideas such as = this. >>>We would need a broader community support and help to initiate a work = in >>>IETF RTC WG on SPID sequence. >>> Please let us know your opinion. >>> >>> >>> >>> Regards, Sohel Khan >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > > >DISCLAIMER: >This electronic mail message is intended exclusively for the individual >or entity to which it is addressed. This message, together with any >attachment, may contain confidential and legally privileged = information. >Any views, opinions or conclusions expressed in this message are those = of >the individual sender and do not necessarily reflect the views of >OTEGLOBE. Any unauthorized review, use, printing, copying, retention, >disclosure or distribution is strictly prohibited. If you have received >this message in error, please immediately advise the sender by reply >email message to the sender and delete all copies of this message. >OTEGLOBE cannot accept any responsibility for the accuracy or >completeness of this message as it has been transmitted over a public >network. If you suspect that the message may have been intercepted or >amended in any way please contact the sender. Thank you. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From bill.wu@huawei.com Tue Feb 7 18:38:49 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B6111E809B for ; Tue, 7 Feb 2012 18:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz4IpztCi7Jb for ; Tue, 7 Feb 2012 18:38:48 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3E11E8080 for ; Tue, 7 Feb 2012 18:38:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ1009DHZB7CJ@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 08 Feb 2012 10:37:55 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ10067DZB2WA@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 08 Feb 2012 10:37:55 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGX76276; Wed, 08 Feb 2012 10:36:59 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 10:36:19 +0800 Received: from w53375q (10.138.41.130) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 08 Feb 2012 10:36:53 +0800 Date: Wed, 08 Feb 2012 10:36:50 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Daryl Malas , Hadriel Kaplan , dispatch@ietf.org Message-id: <926D069DD32240AAB8354FAD4DC25BF9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 02:38:49 -0000 +1 The deliverables focusing on requirements are reasonable to me. It seems early to go to the solution scope given various existing approaches that may work in some cases and break in others. I like to see this work going ahead. Regards! -Qin ----- Original Message ----- From: "Daryl Malas" To: "Hadriel Kaplan" ; Sent: Wednesday, February 08, 2012 1:18 AM Subject: Re: [dispatch] STRAW Charter Proposal > Hadriel et al, > > I support this work, and the result of the work "may" address the issue > Sohel has described regarding SSP loop detection. We have all discussed > on many occasions how B2BUA's tend to cause challenges in SIP networks. > While we will not be the enforcers of the documents defined here, SSP's > can request compliance. Compliance will provide them an increased level > of interoperability, troubleshooting and supported SIP functionality (or > UA capability). > > Regards, > > Daryl > > On 1/24/12 12:15 AM, "Hadriel Kaplan" wrote: > >>Howdy, >>As instructed by DISPATCH chairs, I am re-posting the STRAW Charter >>Proposal, as a topic for the Paris meeting. >>The proposed charter is as follows: >> >>Description of STRAW Working Group >>==================================== >>Name: Sip Traversal Required for Applications to Work (STRAW) >> >>Problem Statement: >>Within the context of the SIP protocol and architecture, a Back-to-Back >>User Agent (B2BUA) is any SIP device in the logical path between two User >>Agents performing a role beyond that of a Proxy as defined in RFC 3261. >>The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >>in order to terminate dead sessions by generating BYEs; or it may be a >>3PCC-style agent only modifying SDP; or it may be a Session Border >>Controller performing such functions as in RFC 5853; or it may be an >>Enterprise PBX terminating REFERs and such; or it may be a complete UAS >>and UAC implementation with a PRI loopback in-between. >> >>In its most extreme form, the scope of the SIP protocol ends at the UAS >>of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >>practice, however, users expect some SIP protocol aspects to go beyond >>the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as >>if the B2BUA was not an end unto itself; this is similar to the >>expectation that emails work when they cross from POP and IMAP to/from >>SMTP. >> >>It is impossible to normatively define all the behaviors of B2BUAs in >>general, or even subsets of them such as SBCs. Unlike consumer NATs, >>B2BUAs perform widely varying functions for purposes which may be unique >>to their environment, unique to their architecture, or unique to the >>wishes of their administrator. Instead of defining all things a given >>type of B2BUA must do, a more practical objective would be to define what >>very few things any B2BUA must do to make a specific SIP mechanism work, >>and let the market decide whether to do those things. >> >>The name of this working group reflects that practical objective: if >>there were a thin straw between the SIP UAS and UAC of a B2BUA, what must >>be passed through that straw and used on each side. Or viewed another >>way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >>circuit, and if we could extend ISDN, what information would we carry in >>ISDN across the PRI for a specific SIP mechanism to work end-to-end. >> >>For example, the WG could produce a document which specifies that the >>Max-Forwards header field value should be copied and decremented across >>the B2BUA, if the B2BUA wishes to prevent loops. Administrators could >>then tell their B2BUA vendors to comply with the document, if the >>administrator so wishes. >> >>Objectives: >>The objectives of the STRAW Working Group are to publish normative >>documents which define which SIP header fields, parameters, MIME bodies, >>body content fields/information, or media-plane characteristics are >>required to traverse between the User Agent "sides" of a B2BUA for >>specific functions to work. >> >>Deliverables would indicate which types of B2BUAs would apply or not. >>For example, a document defining the requirements for end-to-end >>DTLS-SRTP would not apply to B2BUAs which terminate media, such as >>transcoders or recorders. >> >>The intention of this WG is to document such requirements in separate >>documents, per SIP or media function, instead of as one document for all >>functions. That will both reduce the time to publication, as well a >>provide B2BUA administrators and manufacturers with simple >>comply/no-comply criteria. >> >> >>Initial Deliverables: >>1) A taxonomy document defining role-types of B2BUAs, as a reference for >>other deliverables. >>2) A document defining the requirements for B2BUAs with respect to loop >>detection/prevention. >>3) A document defining the requirements for B2BUAs to support end-to-end >>and hop-by-hop media-loopback test calls. >>4) A document defining the requirements for B2BUAs to support DTLS-SRTP >>(RFC 5764) end-to-end. >>5) A document defining the requirements for B2BUAs to support STUN >>connectivity checks end-to-end. >> >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From zhengyli@cisco.com Tue Feb 7 21:15:21 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9813621F86AD for ; Tue, 7 Feb 2012 21:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDLf1F+hsjMV for ; Tue, 7 Feb 2012 21:15:20 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id B37CA21F86A4 for ; Tue, 7 Feb 2012 21:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=6177; q=dns/txt; s=iport; t=1328678114; x=1329887714; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=E28lu/unjWuCaDV4fpQOmY44n50uYBMX5bnsbo71O6o=; b=MpaxelGXCp9TNVR+7utM9YlMWWHD2P1p/EgUdKB6FoLL3E90s9LFAddi e7C/UiJldCrIJiODT+qa6+MDsQaqQbv5eDJtOLazrXMqzMRpImT3Tgd92 SVXJYb2tc2q+AIrG7YpHeLCmoBi8Y3L+sZZiLlIFc4+lT22xNQIycQZ+4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHEEMk9Io8UY/2dsb2JhbABDsGWBcgEBAQQBAQEPAScCATEXBwgOAwEDAQEBVSIGCAYBEhsHh2OaLAGebASLSAEqBgELAQgFAwMJhDAVg1kEiESMaIVYjRI X-IronPort-AV: E=Sophos;i="4.73,382,1325462400"; d="scan'208";a="5061458" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 08 Feb 2012 05:15:12 +0000 Received: from [64.104.169.82] ([64.104.169.82]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q185F9Du001366; Wed, 8 Feb 2012 05:15:10 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 08 Feb 2012 13:15:08 +0800 From: Rockson Li To: Qin Wu , Daryl Malas , Hadriel Kaplan , Message-ID: Thread-Topic: [dispatch] STRAW Charter Proposal In-Reply-To: <926D069DD32240AAB8354FAD4DC25BF9@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:15:21 -0000 +1 I support this work. B2BUA is used a lot in real world. But there's no any normative documents on its behavior, which causes numerous interop issue. -Rockson On 2/8/12 10:36 AM, "Qin Wu" wrote: >+1 >The deliverables focusing on requirements are reasonable to me. It seems >early to go >to the solution scope given various existing approaches that may work in >some cases and >break in others. > >I like to see this work going ahead. > >Regards! >-Qin >----- Original Message ----- >From: "Daryl Malas" >To: "Hadriel Kaplan" ; >Sent: Wednesday, February 08, 2012 1:18 AM >Subject: Re: [dispatch] STRAW Charter Proposal > > >> Hadriel et al, >> >> I support this work, and the result of the work "may" address the issue >> Sohel has described regarding SSP loop detection. We have all discussed >> on many occasions how B2BUA's tend to cause challenges in SIP networks. >> While we will not be the enforcers of the documents defined here, SSP's >> can request compliance. Compliance will provide them an increased level >> of interoperability, troubleshooting and supported SIP functionality (or >> UA capability). >> >> Regards, >> >> Daryl >> >> On 1/24/12 12:15 AM, "Hadriel Kaplan" wrote: >> >>>Howdy, >>>As instructed by DISPATCH chairs, I am re-posting the STRAW Charter >>>Proposal, as a topic for the Paris meeting. >>>The proposed charter is as follows: >>> >>>Description of STRAW Working Group >>>==================================== >>>Name: Sip Traversal Required for Applications to Work (STRAW) >>> >>>Problem Statement: >>>Within the context of the SIP protocol and architecture, a Back-to-Back >>>User Agent (B2BUA) is any SIP device in the logical path between two >>>User >>>Agents performing a role beyond that of a Proxy as defined in RFC 3261. >>>The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA >>>in order to terminate dead sessions by generating BYEs; or it may be a >>>3PCC-style agent only modifying SDP; or it may be a Session Border >>>Controller performing such functions as in RFC 5853; or it may be an >>>Enterprise PBX terminating REFERs and such; or it may be a complete UAS >>>and UAC implementation with a PRI loopback in-between. >>> >>>In its most extreme form, the scope of the SIP protocol ends at the UAS >>>of the B2BUA, and a new SIP protocol scope begins on its UAC side. In >>>practice, however, users expect some SIP protocol aspects to go beyond >>>the scope of the B2BUA's UAS side, and be traversed onto its UAC side, >>>as >>>if the B2BUA was not an end unto itself; this is similar to the >>>expectation that emails work when they cross from POP and IMAP to/from >>>SMTP. >>> >>>It is impossible to normatively define all the behaviors of B2BUAs in >>>general, or even subsets of them such as SBCs. Unlike consumer NATs, >>>B2BUAs perform widely varying functions for purposes which may be unique >>>to their environment, unique to their architecture, or unique to the >>>wishes of their administrator. Instead of defining all things a given >>>type of B2BUA must do, a more practical objective would be to define >>>what >>>very few things any B2BUA must do to make a specific SIP mechanism work, >>>and let the market decide whether to do those things. >>> >>>The name of this working group reflects that practical objective: if >>>there were a thin straw between the SIP UAS and UAC of a B2BUA, what >>>must >>>be passed through that straw and used on each side. Or viewed another >>>way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback >>>circuit, and if we could extend ISDN, what information would we carry in >>>ISDN across the PRI for a specific SIP mechanism to work end-to-end. >>> >>>For example, the WG could produce a document which specifies that the >>>Max-Forwards header field value should be copied and decremented across >>>the B2BUA, if the B2BUA wishes to prevent loops. Administrators could >>>then tell their B2BUA vendors to comply with the document, if the >>>administrator so wishes. >>> >>>Objectives: >>>The objectives of the STRAW Working Group are to publish normative >>>documents which define which SIP header fields, parameters, MIME bodies, >>>body content fields/information, or media-plane characteristics are >>>required to traverse between the User Agent "sides" of a B2BUA for >>>specific functions to work. >>> >>>Deliverables would indicate which types of B2BUAs would apply or not. >>>For example, a document defining the requirements for end-to-end >>>DTLS-SRTP would not apply to B2BUAs which terminate media, such as >>>transcoders or recorders. >>> >>>The intention of this WG is to document such requirements in separate >>>documents, per SIP or media function, instead of as one document for all >>>functions. That will both reduce the time to publication, as well a >>>provide B2BUA administrators and manufacturers with simple >>>comply/no-comply criteria. >>> >>> >>>Initial Deliverables: >>>1) A taxonomy document defining role-types of B2BUAs, as a reference for >>>other deliverables. >>>2) A document defining the requirements for B2BUAs with respect to loop >>>detection/prevention. >>>3) A document defining the requirements for B2BUAs to support end-to-end >>>and hop-by-hop media-loopback test calls. >>>4) A document defining the requirements for B2BUAs to support DTLS-SRTP >>>(RFC 5764) end-to-end. >>>5) A document defining the requirements for B2BUAs to support STUN >>>connectivity checks end-to-end. >>> >>> >>>_______________________________________________ >>>dispatch mailing list >>>dispatch@ietf.org >>>https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From pravindran@sonusnet.com Tue Feb 7 23:03:59 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7420A21F8596 for ; Tue, 7 Feb 2012 23:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpIocby9fUi5 for ; Tue, 7 Feb 2012 23:03:58 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFC421F8594 for ; Tue, 7 Feb 2012 23:03:58 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1874TdV001299; Wed, 8 Feb 2012 02:04:29 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 02:03:41 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 12:33:45 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 12:33:45 +0530 From: "Ravindran, Parthasarathi" To: Rockson Li , Qin Wu , Daryl Malas , Hadriel Kaplan , "dispatch@ietf.org" Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHM2mf5LnZ1j84CGUegN4A8YOcfr5YxZ/6AgAD41E3//89qAIAAd4rg Date: Wed, 8 Feb 2012 07:03:43 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E03DF53@inba-mail01.sonusnet.com> References: <926D069DD32240AAB8354FAD4DC25BF9@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 07:03:45.0867 (UTC) FILETIME=[CCAD69B0:01CCE62F] Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:03:59 -0000 +1 I like to see this charter moving forward.... Lot of SIP related RFC are written from SIP UA perspective which is not ver= y clear for B2BUA implementation. We will discuss in detail about the miles= tone before IETF-83 dispatch meeting Thanks Partha >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >Behalf Of Rockson Li >Sent: Wednesday, February 08, 2012 10:45 AM >To: Qin Wu; Daryl Malas; Hadriel Kaplan; dispatch@ietf.org >Subject: Re: [dispatch] STRAW Charter Proposal > >+1 >I support this work. >B2BUA is used a lot in real world. >But there's no any normative documents on its behavior, which causes >numerous interop issue. > >-Rockson >On 2/8/12 10:36 AM, "Qin Wu" wrote: > >>+1 >>The deliverables focusing on requirements are reasonable to me. It >>seems early to go to the solution scope given various existing >>approaches that may work in some cases and break in others. >> >>I like to see this work going ahead. >> >>Regards! >>-Qin >>----- Original Message ----- >>From: "Daryl Malas" >>To: "Hadriel Kaplan" ; >>Sent: Wednesday, February 08, 2012 1:18 AM >>Subject: Re: [dispatch] STRAW Charter Proposal >> >> >>> Hadriel et al, >>> >>> I support this work, and the result of the work "may" address the >>> issue Sohel has described regarding SSP loop detection. We have all >>> discussed on many occasions how B2BUA's tend to cause challenges in >SIP networks. >>> While we will not be the enforcers of the documents defined here, >>> SSP's can request compliance. Compliance will provide them an >>> increased level of interoperability, troubleshooting and supported >>> SIP functionality (or UA capability). >>> >>> Regards, >>> >>> Daryl >>> >>> On 1/24/12 12:15 AM, "Hadriel Kaplan" wrote: >>> >>>>Howdy, >>>>As instructed by DISPATCH chairs, I am re-posting the STRAW Charter >>>>Proposal, as a topic for the Paris meeting. >>>>The proposed charter is as follows: >>>> >>>>Description of STRAW Working Group >>>>=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 >>>>Name: Sip Traversal Required for Applications to Work (STRAW) >>>> >>>>Problem Statement: >>>>Within the context of the SIP protocol and architecture, a >>>>Back-to-Back User Agent (B2BUA) is any SIP device in the logical path >>>>between two User Agents performing a role beyond that of a Proxy as >>>>defined in RFC 3261. >>>>The B2BUA may be as simple as a session-stateful Proxy becoming a >>>>B2BUA in order to terminate dead sessions by generating BYEs; or it >>>>may be a 3PCC-style agent only modifying SDP; or it may be a Session >>>>Border Controller performing such functions as in RFC 5853; or it may >>>>be an Enterprise PBX terminating REFERs and such; or it may be a >>>>complete UAS and UAC implementation with a PRI loopback in-between. >>>> >>>>In its most extreme form, the scope of the SIP protocol ends at the >>>>UAS of the B2BUA, and a new SIP protocol scope begins on its UAC >>>>side. In practice, however, users expect some SIP protocol aspects >>>>to go beyond the scope of the B2BUA's UAS side, and be traversed onto >>>>its UAC side, as if the B2BUA was not an end unto itself; this is >>>>similar to the expectation that emails work when they cross from POP >>>>and IMAP to/from SMTP. >>>> >>>>It is impossible to normatively define all the behaviors of B2BUAs in >>>>general, or even subsets of them such as SBCs. Unlike consumer NATs, >>>>B2BUAs perform widely varying functions for purposes which may be >>>>unique to their environment, unique to their architecture, or unique >>>>to the wishes of their administrator. Instead of defining all things >>>>a given type of B2BUA must do, a more practical objective would be to >>>>define what very few things any B2BUA must do to make a specific SIP >>>>mechanism work, and let the market decide whether to do those things. >>>> >>>>The name of this working group reflects that practical objective: if >>>>there were a thin straw between the SIP UAS and UAC of a B2BUA, what >>>>must be passed through that straw and used on each side. Or viewed >>>>another way, if a B2BUA were in fact a UAS and UAC connected with a >>>>PRI loopback circuit, and if we could extend ISDN, what information >>>>would we carry in ISDN across the PRI for a specific SIP mechanism to >>>>work end-to-end. >>>> >>>>For example, the WG could produce a document which specifies that the >>>>Max-Forwards header field value should be copied and decremented >>>>across the B2BUA, if the B2BUA wishes to prevent loops. >>>>Administrators could then tell their B2BUA vendors to comply with the >>>>document, if the administrator so wishes. >>>> >>>>Objectives: >>>>The objectives of the STRAW Working Group are to publish normative >>>>documents which define which SIP header fields, parameters, MIME >>>>bodies, body content fields/information, or media-plane >>>>characteristics are required to traverse between the User Agent >>>>"sides" of a B2BUA for specific functions to work. >>>> >>>>Deliverables would indicate which types of B2BUAs would apply or not. >>>>For example, a document defining the requirements for end-to-end >>>>DTLS-SRTP would not apply to B2BUAs which terminate media, such as >>>>transcoders or recorders. >>>> >>>>The intention of this WG is to document such requirements in separate >>>>documents, per SIP or media function, instead of as one document for >>>>all functions. That will both reduce the time to publication, as >>>>well a provide B2BUA administrators and manufacturers with simple >>>>comply/no-comply criteria. >>>> >>>> >>>>Initial Deliverables: >>>>1) A taxonomy document defining role-types of B2BUAs, as a reference >>>>for other deliverables. >>>>2) A document defining the requirements for B2BUAs with respect to >>>>loop detection/prevention. >>>>3) A document defining the requirements for B2BUAs to support >>>>end-to-end and hop-by-hop media-loopback test calls. >>>>4) A document defining the requirements for B2BUAs to support >>>>DTLS-SRTP (RFC 5764) end-to-end. >>>>5) A document defining the requirements for B2BUAs to support STUN >>>>connectivity checks end-to-end. >>>> >>>> >>>>_______________________________________________ >>>>dispatch mailing list >>>>dispatch@ietf.org >>>>https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From hs@123.org Wed Feb 8 01:19:50 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226B721F869A for ; Wed, 8 Feb 2012 01:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la0XD31TM5Yn for ; Wed, 8 Feb 2012 01:19:49 -0800 (PST) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id A369E21F864F for ; Wed, 8 Feb 2012 01:19:46 -0800 (PST) X-RZG-AUTH: :JH8HfU+kYd9xQ6m0ynnj9hHxvZXYXks+pm8dQxa2PdmCs29gND9cXwZXB+HVO4Db X-RZG-CLASS-ID: mo05 Received: from [10.58.238.13] ([82.113.98.13]) by smtp.strato.de (jimi mo63) (RZmta 27.6 SBL|AUTH) with ESMTPA id 202ee1o188JagG for ; Wed, 8 Feb 2012 10:19:17 +0100 (MET) Message-ID: <4F323E13.5060008@123.org> Date: Wed, 08 Feb 2012 10:19:15 +0100 From: Hendrik Scholz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> In-Reply-To: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 09:19:50 -0000 Hi Hadriel, +1 I support this work and am happy to contribute. In addition to the identified work items there could be a document on 'how to allow custom headers/data to pass through STRAW-enabled B2BUAs'. The rationale for me is that even if we cannot agree on a SPID mechanism which may disclose too much private information for some use cases there may be federations of carriers which want to have this information. In a nutshell SBCs may be instructed to pass all data in SIP headers with a (to be defined) STRAW prefix from the UAS to the UAC side and vice versa. Cheers, Hendrik -- Hendrik Scholz From mperumal@cisco.com Wed Feb 8 02:14:08 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C608F21F8587 for ; Wed, 8 Feb 2012 02:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAdH+I2+u5xK for ; Wed, 8 Feb 2012 02:14:07 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id A2C2121F8585 for ; Wed, 8 Feb 2012 02:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4852; q=dns/txt; s=iport; t=1328696047; x=1329905647; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=PU02eOSCIan9DZ2BnHytYtzPK18Tlv3pM5ERRVY02Oo=; b=Y/mGDF43Mx1xfbXH/DmfrRo1u/GTLrbnAFI9SOigkIR35CWqUb6AReQu GZ0dlZgJmeB0hEjtu4WrV9n5yFzoIcpSVeSeCQLjvYrxNs7JiVDEjM0MK Q7P0MHLtePkKh7bO01daeE2yHyt9uQS8vIwqUZrW35vA4UHFVJepe8Zel 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EANVJMk9Io8UY/2dsb2JhbABDsGmBcgEBAQQBAQEPAR0KNBcEAgEIDgMBAwEBCwYXAQYBJh8DBggCBAEKCAgBGYdjmjwBnnKLOQ4sBgEtDAKEMoJ2YwSIRJ9N X-IronPort-AV: E=Sophos;i="4.73,383,1325462400"; d="scan'208";a="5086000" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 08 Feb 2012 10:14:04 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q18AE44E005711; Wed, 8 Feb 2012 10:14:04 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 15:44:04 +0530 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, 8 Feb 2012 15:44:01 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020787304C@XMB-BGL-414.cisco.com> In-Reply-To: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] STRAW Charter Proposal Thread-Index: AQHM2mf5LnZ1j84CGUegN4A8YOcfr5Yy3HbQ References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 08 Feb 2012 10:14:04.0653 (UTC) FILETIME=[62CDE1D0:01CCE64A] Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:14:09 -0000 +1 Seems like a stepping stone for what I was trying to advocate back in 2010: http://www.ietf.org/mail-archive/web/dispatch/current/msg02097.html Would be happy to contribute.. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan |Sent: Tuesday, January 24, 2012 12:46 PM |To: dispatch@ietf.org list |Subject: [dispatch] STRAW Charter Proposal | |Howdy, |As instructed by DISPATCH chairs, I am re-posting the STRAW Charter Proposal, as a topic for the Paris |meeting. |The proposed charter is as follows: | |Description of STRAW Working Group |=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 |Name: Sip Traversal Required for Applications to Work (STRAW) | |Problem Statement: |Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP |device in the logical path between two User Agents performing a role beyond that of a Proxy as defined |in RFC 3261. The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to |terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it |may be a Session Border Controller performing such functions as in RFC 5853; or it may be an |Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a |PRI loopback in-between. | |In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP |protocol scope begins on its UAC side. In practice, however, users expect some SIP protocol aspects |to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA |was not an end unto itself; this is similar to the expectation that emails work when they cross from |POP and IMAP to/from SMTP. | |It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them |such as SBCs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be |unique to their environment, unique to their architecture, or unique to the wishes of their |administrator. Instead of defining all things a given type of B2BUA must do, a more practical |objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism |work, and let the market decide whether to do those things. | |The name of this working group reflects that practical objective: if there were a thin straw between |the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side. Or |viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and |if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP |mechanism to work end-to-end. | |For example, the WG could produce a document which specifies that the Max-Forwards header field value |should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent loops. |Administrators could then tell their B2BUA vendors to comply with the document, if the administrator |so wishes. | |Objectives: |The objectives of the STRAW Working Group are to publish normative documents which define which SIP |header fields, parameters, MIME bodies, body content fields/information, or media-plane |characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific |functions to work. | |Deliverables would indicate which types of B2BUAs would apply or not. For example, a document |defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, |such as transcoders or recorders. | |The intention of this WG is to document such requirements in separate documents, per SIP or media |function, instead of as one document for all functions. That will both reduce the time to |publication, as well a provide B2BUA administrators and manufacturers with simple comply/no-comply |criteria. | | |Initial Deliverables: |1) A taxonomy document defining role-types of B2BUAs, as a reference for other deliverables. |2) A document defining the requirements for B2BUAs with respect to loop detection/prevention. |3) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback |test calls. |4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end. |5) A document defining the requirements for B2BUAs to support STUN connectivity checks end-to-end. | | |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Wed Feb 8 12:11:44 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB0121E802E for ; Wed, 8 Feb 2012 12:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.195 X-Spam-Level: X-Spam-Status: No, score=-99.195 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmriluz-n542 for ; Wed, 8 Feb 2012 12:11:43 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 3165821F8542 for ; Wed, 8 Feb 2012 12:11:43 -0800 (PST) Received: (qmail 5665 invoked by uid 0); 8 Feb 2012 20:11:31 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy3.bluehost.com with SMTP; 8 Feb 2012 20:11:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=bxz/jgWeaN3rk/rYF2xoxPjbnjTcmYHWFWQbO0ltrOA=; b=My3A4k1PX3Vub5t0LFbxoMw0Csderq8QvSq5DaZRcvU4t9JM3GRnxbvI5lax9jtUaJQZ0F66QLU8z17Q4Rre4m/TCz+yWCnEJt7kB0eSjmGc/h7ei5tHX1oHw9SABq5j; Received: from pool-96-255-226-191.washdc.fios.verizon.net ([96.255.226.191] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RvDrV-0006n6-TS; Wed, 08 Feb 2012 13:11:30 -0700 From: "Richard Shockey" To: , Date: Wed, 8 Feb 2012 15:11:28 -0500 Message-ID: <010801cce69d$d89f8a50$89de9ef0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0109_01CCE673.EFC98250" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczmlP65nX95PO7ERrqcjJNwqNxi3gACJsow Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.255.226.191 authed with richard@shockey.us} Subject: [dispatch] SIPNOC US 2012 Call for Presentations X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:11:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0109_01CCE673.EFC98250 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Subject: SIPNOC US 2012 Call for Presentations =20 LinkedIn Groups * Group: The SIP Forum * Subject: SIPNOC US 2012 Call for Presentations=20 The SIP Forum is holding its second SIP Network Operators Conference = =E2=80=93 SIPNOC US 2012 -- on June 25th to the 27th, 2012, at the Hyatt = Dulles Hotel in Herndon, Virginia. For more information about SIPNOC US 2012, including the preliminary = schedule of events and other important details about the conference, = please visit http://www.sipnoc.org . The SIPNOC US 2012 Program Committee is now seeking proposals for = presentations, panels, or BOFs (Birds-Of-a-Feather) for the SIPNOC US = 2012 program. We invite presentations highlighting issues relating to = SIP deployments. Operators are encouraged to present on successes, = issues, and concerns found in their deployments. Vendors are encouraged = to work with operators to present real-world deployment experiences. Full details of the submission process and policies, as well as SIPNOC = US 2012 Program dates of interest, can be found at: http://www.sipforum.org/content/view/374/275/=20 EARLY BIRD REGISTRATION DEADLINE EXTENDED!=20 Take Advantage of Special Savings Now Before They Disappear! The regular individual registration fee for SIPNOC US 2012 attendance is = $895 for two full days of conference activities. This fee will cover = admittance to all conference sessions, presentations, keynotes, = breakfast, lunch, dinners and breaks, as well as a welcome reception on = the evening before the event begins, and a special evening networking = reception on the first day of the event. For a limited time, you can take advantage of a special early-bird = discounted price of $695 =E2=80=93 a $200 discount off the regular = attendance fee. This special rate expires on March 1, 2012, so register = today to lock in your savings! To register at this very special rate, please visit = http://www.regonline.com/sipnocus2012 . SIP Forum Full Members Save Even More! For individuals of companies that = are active Full Members of the SIP Forum, a special early-bird price of = $445 is being offered =E2=80=93 a discount of more than 50% off the = regular conference rate -- and exclusive full member-only discounts will = be offered for a variety of special SIPNOC US 2012 sponsorship packages. = In order to obtain this special Full Member pricing =E2=80=93 good until = March 1, 2012, please contact Marc Robins, SIP Forum President and = Managing Director, for the discount code. Marc can be reached at = +1-203-829-6307 or marc.robins@sipforum.org.=20 SIPNOC US 2012 Hotel Reservations The SIP Forum has negotiated a nicely discounted room rate of $169/night = at the four-star Hyatt Dulles Hotel. This rate includes in-room WiFi = Internet access! Other valuable benefits include a free shuttle bus to = and from Dulles Airport and free parking in the hotel parking lot. The cut-off date to receive this great rate is June 4, 2012. Reservation = requests made after the cut-off date will be based on availability at = the hotel's prevailing rates. So take advantage of this great offer now = and register for your stay at the Hyatt Dulles using the following Web = link: https://resweb.passkey.com/go/SIPNOCUS2012 . SIPNOC US 2012 Sponsorship Opportunities If you are interested in a corporate sponsorship of the event, please = contact Marc Robins, SIP Forum President and Managing Director, for = detailed information about available sponsorship opportunities. Marc can = be reached at +1-203-829-6307 or marc.robins@sipforum.org. ****************************************** For more information about SIPNOC US 2012, please visit www.sipnoc.org = or email sipnocinfo@sipforum.org=20 Posted By Marc Robins=20 =09 =09 =09 =20 ------=_NextPart_000_0109_01CCE673.EFC98250 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Subject: SIPNOC US = 2012 Call for Presentations

 

L= inkedIn Groups<= o:p>

  • Group: The = SIP Forum
  • Subject: = SIPNOC US 2012 Call for Presentations =

The SIP Forum = is holding its second SIP Network Operators Conference =E2=80=93 SIPNOC = US 2012 -- on June 25th to the 27th, 2012, at the Hyatt Dulles Hotel in = Herndon, Virginia.

For more information about SIPNOC US 2012, including the = preliminary schedule of events and other important details about the = conference, please visit http://www.sipnoc.org .

The SIPNOC US 2012 = Program Committee is now seeking proposals for presentations, panels, or = BOFs (Birds-Of-a-Feather) for the SIPNOC US 2012 program. We invite = presentations highlighting issues relating to SIP deployments. Operators = are encouraged to present on successes, issues, and concerns found in = their deployments. Vendors are encouraged to work with operators to = present real-world deployment experiences.

Full details of the submission process and policies, as = well as SIPNOC US 2012 Program dates of interest, can be found = at:
http://www.sipforum.org/content/view/374/275/ =

EARLY BIRD REGISTRATION DEADLINE EXTENDED! =

Take Advantage of Special Savings Now = Before They Disappear!

The regular = individual registration fee for SIPNOC US 2012 attendance is $895 for = two full days of conference activities. This fee will cover admittance = to all conference sessions, presentations, keynotes, breakfast, lunch, = dinners and breaks, as well as a welcome reception on the evening before = the event begins, and a special evening networking reception on the = first day of the event.

For a limited = time, you can take advantage of a special early-bird discounted price of = $695 =E2=80=93 a $200 discount off the regular attendance fee. This = special rate expires on March 1, 2012, so register today to lock in your = savings!

To register at this very = special rate, please visit http://www.regonline.com/sipnocus2012 .

SIP Forum Full Members = Save Even More! For individuals of companies that are active Full = Members of the SIP Forum, a special early-bird price of $445 is being = offered =E2=80=93 a discount of more than 50% off the regular conference = rate -- and exclusive full member-only discounts will be offered for a = variety of special SIPNOC US 2012 sponsorship packages. =

In order to obtain this special Full = Member pricing =E2=80=93 good until March 1, 2012, please contact Marc = Robins, SIP Forum President and Managing Director, for the discount = code. Marc can be reached at +1-203-829-6307 or = marc.robins@sipforum.org.

SIPNOC US = 2012 Hotel Reservations

The SIP Forum = has negotiated a nicely discounted room rate of $169/night at the = four-star Hyatt Dulles Hotel. This rate includes in-room WiFi Internet = access! Other valuable benefits include a free shuttle bus to and from = Dulles Airport and free parking in the hotel parking = lot.

The cut-off date to receive this = great rate is June 4, 2012. Reservation requests made after the cut-off = date will be based on availability at the hotel's prevailing rates. So = take advantage of this great offer now and register for your stay at the = Hyatt Dulles using the following Web link: https://resweb.passkey.com/go/SIPNOCUS2012 .

SIPNOC US 2012 = Sponsorship Opportunities

If you are = interested in a corporate sponsorship of the event, please contact Marc = Robins, SIP Forum President and Managing Director, for detailed = information about available sponsorship opportunities. Marc can be = reached at +1-203-829-6307 or = marc.robins@sipforum.org.

******************************************

For more information about SIPNOC US 2012, please visit = www.sipnoc.org or email sipnocinfo@sipforum.org
= Posted By Marc Robins =

 

------=_NextPart_000_0109_01CCE673.EFC98250-- From pp3129@att.com Fri Feb 17 08:45:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0621E8017 for ; Fri, 17 Feb 2012 08:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Te14e-WoarG for ; Fri, 17 Feb 2012 08:45:19 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8954D21F85ED for ; Fri, 17 Feb 2012 08:45:18 -0800 (PST) X-Env-Sender: pp3129@att.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1329497116!16137011!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21780 invoked from network); 17 Feb 2012 16:45:16 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Feb 2012 16:45:16 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1HGjks6009081; Fri, 17 Feb 2012 11:45:46 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1HGjcas008869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 11:45:39 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint01.pst.cso.att.com (RSA Interceptor); Fri, 17 Feb 2012 11:44:56 -0500 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([169.254.5.149]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Fri, 17 Feb 2012 11:44:56 -0500 From: "PFAUTZ, PENN L" To: Richard Shockey , "'Daryl Malas'" , "'Leontsinis, Nikos'" , "'Cullen Jennings'" , "'Sohel Khan'" Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: Aczly1z0k7xjmdPsSGKGHCTf2Pwg7wAK9UQwAeb/ibA= Date: Fri, 17 Feb 2012 16:44:56 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> In-Reply-To: <010101cce5f9$10d3b8b0$327b2a10$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.160.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 16:45:24 -0000 I've submitted a new version of the SPID I-D Rich referred to below. Per di= spatch at the Quebec meeting it's for discussion on the RAI list. It differs from the previous version in asking the RIRs rather than IANA di= rectly to handle registrations. (This is to minimize junk registrations and= provide a whois service) Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Richard Shockey Sent: Tuesday, February 07, 2012 7:32 PM To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel Khan' Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection Ok .. but the basics are essential. I want to commend to all of you the concept of a Universal SPID embodied in this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifie= r -urn-01.txt It needs work and input from everyone here, but the core issue here is identification of issues along the session path especially as it transits across national boundaries or transit intermediaries. What is the malfunction that we can't agree on a tracing mechanism. Session ID for goodness sake. DO IT. Charter the damn thing. It may seem trivial. Its not. Especially if you are a regulator looking at how to create competitive transit markets. Do you all want another Shockey lecture on what the national regulators are up to ??? Sohel to his eternal credit is starting to identify the larger problem of the End of POTS. I've avoided proposing a RAI Directorate on End of Life (EOL) issues with TDM but it's coming. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Daryl Malas Sent: Tuesday, February 07, 2012 2:05 PM To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection Notice I specifically said, "Service Providers acting as an IXC never want to indicate their service provider relationships to their customers." This does not preclude a contractual agreement between two SSPs. On 2/7/12 11:35 AM, "Leontsinis, Nikos" wrote: >I am not 100% sure about this. On some environments say IPX this can be >desirable it is written in the contract I will send you traffic to >USA FIXED and you are obliged to route it to carrier B. This is the area >where the SPID could make sense. > > >/nikos >________________________________________ >From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of >Daryl Malas [D.Malas@cablelabs.com] >Sent: Tuesday, February 07, 2012 7:06 PM >To: Cullen Jennings; Sohel Khan >Cc: dispatch@ietf.org >Subject: Re: [dispatch] SPID Sequence and Loop Detection > >Cullen's point here is very valid. Service Providers acting as an IXC >never want to indicate their service provider relationships to their >customers. They create interconnects to many service providers to >maintain the lowest termination costs in order to increase their margins >for LD termination. Sohel describes a real problem. > >In telecommunication networks, it seems as though we have many different >carrier identification mechanisms already defined. I am leery of creating >yet another, even if it is encrypted. I would be more inclined to look at >existing loop detection mechanisms and see if they will work either: >- as currently defined, >- need to be extended or >- need to be enforced (aka not blocked or reset by a B2BUA). > >--Daryl > >On 1/27/12 11:56 AM, "Cullen Jennings" wrote: > >> >>When doing least cost routing, my experience has been that if A delivers >>the call to B that B will then send to C, B wants to hide this fact from >>C and certainly wants to hide from A that they the call went to C. >>Otherwise B gets cut out and A and C just set up a peering deal directly. >> >>So I worry a scheme like this would not work as B's SBC would be >>configured to remove this. >> >> >>On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >> >>> SIP calls routing in an infinite loop in a subset of networks is a >>>known phenomenon. >>> Various SIP methods exist today may be used to detect and mitigate >>>loops. Operational engineers would like to see a method that indicates >>>the sequence of providers=B9 IDs in the call path. Based on the input fr= om >>>the operational engineers, we are proposing a new SIP header >>Sequence> to detect SIP routing loop. This method is preferred by the >>>operational engineers of large providers=B9 networks. >>> >>> Assume that a SIP call originating from provider Alpha (SPID: 77777777) >>>and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: >>>33333333), and looping back to Alpha. >>> >>> With the new method, the SIP INVITE contains the new header SPID >>>sequence {33333333, 55555555, 77777777}. >>> >>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>arrives to Alpha=B9s network, Alpha will detect 77777777 in the SPID >>>sequence and conclude that a loop has occurred. >>> >>> In the above use case, an example =B3SPID-sequence=B2 header is as foll= ows: >>> SPID-Sequence:;index=3D1; >>> SPID-Sequence:;index=3D1.1; >>> SPID-Sequence:;index=3D1.2; >>> >>> A provider wishing not to divulge its SPID, may insert a private or a >>>blank value. >>> SPID-Sequence:;index=3D1; >>> SPID-Sequence:;index=3D1.1; >>> SPID-Sequence:;index=3D1.2 >>> SPID-Sequence:;index=3D1.3; >>> A provider should not delete any value from the SPID sequence unless >>>the SPID is its own. >>> We had some discussion in the DISPATCH meetings on ideas such as this. >>>We would need a broader community support and help to initiate a work in >>>IETF RTC WG on SPID sequence. >>> Please let us know your opinion. >>> >>> >>> >>> Regards, Sohel Khan >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >>_______________________________________________ >>dispatch mailing list >>dispatch@ietf.org >>https://www.ietf.org/mailman/listinfo/dispatch > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > > >DISCLAIMER: >This electronic mail message is intended exclusively for the individual >or entity to which it is addressed. This message, together with any >attachment, may contain confidential and legally privileged information. >Any views, opinions or conclusions expressed in this message are those of >the individual sender and do not necessarily reflect the views of >OTEGLOBE. Any unauthorized review, use, printing, copying, retention, >disclosure or distribution is strictly prohibited. If you have received >this message in error, please immediately advise the sender by reply >email message to the sender and delete all copies of this message. >OTEGLOBE cannot accept any responsibility for the accuracy or >completeness of this message as it has been transmitted over a public >network. If you suspect that the message may have been intercepted or >amended in any way please contact the sender. Thank you. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Peter.Dawes@vodafone.com Mon Feb 20 09:21:40 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4677E21F876E for ; Mon, 20 Feb 2012 09:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmAM9RpYgkJT for ; Mon, 20 Feb 2012 09:21:34 -0800 (PST) Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78F21F876F for ; Mon, 20 Feb 2012 09:21:33 -0800 (PST) Received: from mailint03 (localhost [127.0.0.1]) by mailout03 (Postfix) with ESMTP id 96F95116B0C for ; Mon, 20 Feb 2012 18:21:31 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint03 (Postfix) with ESMTPS id 893E9116B09; Mon, 20 Feb 2012 18:21:31 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 18:21:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Feb 2012 18:21:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Revised Proposed Session-ID Charter Thread-Index: Aczv8SHJQ7YezixqSP6CSJz6Zq9JLg== From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 20 Feb 2012 17:21:05.0279 (UTC) FILETIME=[06D828F0:01CCEFF4] Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:21:40 -0000 Hello Laura, All, The topic of Session-ID has interest from both IETF, 3GPP, and the Open Mobile Alliance (OMA) and I am keen to contribute to any new WG. I have just re-submitted my session-id related draft to label it "dispatch" (not "sipping" as previously).=20 http://datatracker.ietf.org/doc/draft-dawes-dispatch-debug/=20 To help track the various requirements and proposals, clause " 3. Related Drafts and Specifications" has been added with a list of other drafts (currently 5) and non-IETF specifications (currently 2) that I am aware of related to this topic. I hope we can proceed soon with the work. Regards, Peter Message: 2 Date: Fri, 23 Dec 2011 14:45:49 +0100 From: Laura Liess To: "Paul E. Jones" Cc: dispatch@ietf.org Subject: Re: [dispatch] Revised Proposed Session-ID Charter Message-ID: =09 Content-Type: text/plain; charset=3Dwindows-1252 Paul, We already had a consensus in Dispatch that this work is needed and that there are enough people willing to contribute. There were objections to the initial charter but, as you already pointed out, the current charter text seems to have reached general acceptance. I suggest you ask Gonzalo how to proceed to start the WG. Laura 2011/12/19 Paul E. Jones : > Folks, > > > > I?ve not seen much discussion on this topic over the past month.? Even > so, I?ve not seen any objection to proceeding work.? The only concern=20 > raised recently is around the definition of the word ?session?, to=20 > which we?re proposing to make that a part of the first deliverable. > > > > What do we need to do in order to move this work forward? > > > > Paul > > > > PS ? The charter text that seems to have reached general acceptance is > below > > > > > > End-to-end Session Identifier in SIP (charter proposal) > > > > The end-to-end Session Identifier in SIP-based multimedia=20 > communication networks refers to the ability for endpoints,=20 > intermediate devices, and management and monitoring system to identify > and correlate SIP messages and dialogs of the same higher-level=20 > end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. > > > > Unfortunately, there are a number of factors that contribute to the=20 > fact that the current dialog identifiers defined in SIP is not=20 > suitable for end-to-end session identification. Perhaps the most=20 > important factor worth describing is that in real-world deployments=20 > Back-to-Back User Agents > (B2BUAs) devices like Session Border Controllers (SBC) often change=20 > the call identifiers (e.g., the From-tag and To-tag that are used in=20 > conjunction with the Call-ID header to make the dialog-id) as the=20 > session signaling passes through. > > > > An end-to-end Session Identifier should allow the possibility to=20 > identify the communication session from the point of origin, passing=20 > through any number of intermediaries, to the ultimate point of=20 > termination. It should have the same aim as the From-tag, To-tag and=20 > Call-ID conjunction, but should not be mangled by intermediaries.?=20 > Consideration must be given to the fact that the entities involved in=20 > a communication session might change as a result of service=20 > interaction in the network, such as call transfers, joins, etc. > > > > A SIP end-to-end Session Identifier has been considered as possible=20 > solution of different use cases like troubleshooting, billing, session > tracking, session recording, media and signaling correlation, and so=20 > forth.? Some of these requirements have also been identified and come=20 > directly from other Existing working group within the RAI area (e.g. SIPRec, Splices). > > > > Moreover, other standards organizations have identified the need for=20 > SIP and > H.323 to carry the same "session ID" value(s) so that it is possible=20 > to identify a call end-to end even when performing interworking=20 > between protocols. > > > > The working group will produce the following deliverables: > > > > 1. A requirement and use case document with key consideration for SIP=20 > Session End-to-End Identification, including the definition of a "session" > > > > 2. Specification of new end-to-end Session Identifier mechanism > > > > Goal and Milestone: > > > > August 2012 - Requirement and use case document sent to the IESG > (Informational) > > > > March 2013 - Specification of the new mechanism sent to the IESG (PS) > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > ------------------------------ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch End of dispatch Digest, Vol 33, Issue 14 **************************************** From paulej@packetizer.com Mon Feb 20 11:12:14 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854B921F8738 for ; Mon, 20 Feb 2012 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb5Hem7AtP2s for ; Mon, 20 Feb 2012 11:12:09 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B929221F86DF for ; Mon, 20 Feb 2012 11:12:09 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q1KJC6nx005429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Feb 2012 14:12:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1329765128; bh=xs8zkb9cfDE0piH8Zk5wL5fJ+Vv/LDauloUJO4u3IE4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=N3bX3MDfmcvS3oMFQTMXTj+SJcKzLG3VyW6OpyH4FjVyHMkRzUkMFMfEm34kQY249 IARV1g///6oiQ3h6bVCKt+nPtvXGVLfUPRPKoyDyKJMh7gnkl4PSHLaBvndMsS65xR tLaKV/uNQF7/+gNU2yTQLkmCs1TVEDb7hQ/WI4Kw= From: "Paul E. Jones" To: "'Dawes, Peter, VF-Group'" , References: In-Reply-To: Date: Mon, 20 Feb 2012 14:12:15 -0500 Message-ID: <026901ccf003$8f063aa0$ad12afe0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFuH+2Dh9+77xg5TjYrG8plMP4/MpcDxxpQ Content-Language: en-us Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 19:12:14 -0000 Peter, I looked over the draft quickly (so perhaps I missed it), but how does Alice learn the address of d1.foocorp.com? Paul > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com] > Sent: Monday, February 20, 2012 12:21 PM > To: dispatch@ietf.org > Cc: laura.liess.dt@googlemail.com; paulej@packetizer.com > Subject: Re: [dispatch] Revised Proposed Session-ID Charter > > Hello Laura, All, > The topic of Session-ID has interest from both IETF, 3GPP, and the Open > Mobile Alliance (OMA) and I am keen to contribute to any new WG. I have > just re-submitted my session-id related draft to label it "dispatch" > (not "sipping" as previously). > > http://datatracker.ietf.org/doc/draft-dawes-dispatch-debug/ > > To help track the various requirements and proposals, clause " 3. > Related Drafts and Specifications" has been added with a list of other > drafts (currently 5) and non-IETF specifications (currently 2) that I am > aware of related to this topic. I hope we can proceed soon with the work. > > Regards, > Peter From andrew.hutton@siemens-enterprise.com Tue Feb 21 06:14:01 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E0621F87B1 for ; Tue, 21 Feb 2012 06:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq9tWDyY6vT4 for ; Tue, 21 Feb 2012 06:13:57 -0800 (PST) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id DC57821F859B for ; Tue, 21 Feb 2012 06:13:56 -0800 (PST) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 35A1A1EB8433; Tue, 21 Feb 2012 15:13:55 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 21 Feb 2012 15:13:55 +0100 From: "Hutton, Andrew" To: Hadriel Kaplan , "dispatch@ietf.org list" Date: Tue, 21 Feb 2012 15:13:53 +0100 Thread-Topic: STRAW Charter Proposal Thread-Index: AQHM2mf5LnZ1j84CGUegN4A8YOcfr5ZHj+Xw Message-ID: <101C6067BEC68246B0C3F6843BCCC1E31294224AAB@MCHP058A.global-ad.net> References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> In-Reply-To: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:14:01 -0000 Hi Hadriel / Dispatch, I like the charter and think that the approach of picking some reasonably m= anageable topics which cover existing problem areas or areas of current int= erest is the right approach. I would be happy to contribute to this work. Sorry took so long to get round to reading the dispatch list. Regards Andy > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: 24 January 2012 07:16 > To: dispatch@ietf.org list > Subject: [dispatch] STRAW Charter Proposal >=20 > Howdy, > As instructed by DISPATCH chairs, I am re-posting the STRAW Charter > Proposal, as a topic for the Paris meeting. > The proposed charter is as follows: >=20 > Description of STRAW Working Group > =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 > Name: Sip Traversal Required for Applications to Work (STRAW) >=20 > Problem Statement: > Within the context of the SIP protocol and architecture, a Back-to-Back > User Agent (B2BUA) is any SIP device in the logical path between two > User Agents performing a role beyond that of a Proxy as defined in RFC > 3261. The B2BUA may be as simple as a session-stateful Proxy becoming > a B2BUA in order to terminate dead sessions by generating BYEs; or it > may be a 3PCC-style agent only modifying SDP; or it may be a Session > Border Controller performing such functions as in RFC 5853; or it may > be an Enterprise PBX terminating REFERs and such; or it may be a > complete UAS and UAC implementation with a PRI loopback in-between. >=20 > In its most extreme form, the scope of the SIP protocol ends at the UAS > of the B2BUA, and a new SIP protocol scope begins on its UAC side. In > practice, however, users expect some SIP protocol aspects to go beyond > the scope of the B2BUA's UAS side, and be traversed onto its UAC side, > as if the B2BUA was not an end unto itself; this is similar to the > expectation that emails work when they cross from POP and IMAP to/from > SMTP. >=20 > It is impossible to normatively define all the behaviors of B2BUAs in > general, or even subsets of them such as SBCs. Unlike consumer NATs, > B2BUAs perform widely varying functions for purposes which may be > unique to their environment, unique to their architecture, or unique to > the wishes of their administrator. Instead of defining all things a > given type of B2BUA must do, a more practical objective would be to > define what very few things any B2BUA must do to make a specific SIP > mechanism work, and let the market decide whether to do those things. >=20 > The name of this working group reflects that practical objective: if > there were a thin straw between the SIP UAS and UAC of a B2BUA, what > must be passed through that straw and used on each side. Or viewed > another way, if a B2BUA were in fact a UAS and UAC connected with a PRI > loopback circuit, and if we could extend ISDN, what information would > we carry in ISDN across the PRI for a specific SIP mechanism to work > end-to-end. >=20 > For example, the WG could produce a document which specifies that the > Max-Forwards header field value should be copied and decremented across > the B2BUA, if the B2BUA wishes to prevent loops. Administrators could > then tell their B2BUA vendors to comply with the document, if the > administrator so wishes. >=20 > Objectives: > The objectives of the STRAW Working Group are to publish normative > documents which define which SIP header fields, parameters, MIME > bodies, body content fields/information, or media-plane characteristics > are required to traverse between the User Agent "sides" of a B2BUA for > specific functions to work. >=20 > Deliverables would indicate which types of B2BUAs would apply or not. > For example, a document defining the requirements for end-to-end DTLS- > SRTP would not apply to B2BUAs which terminate media, such as > transcoders or recorders. >=20 > The intention of this WG is to document such requirements in separate > documents, per SIP or media function, instead of as one document for > all functions. That will both reduce the time to publication, as well > a provide B2BUA administrators and manufacturers with simple comply/no- > comply criteria. >=20 >=20 > Initial Deliverables: > 1) A taxonomy document defining role-types of B2BUAs, as a reference > for other deliverables. > 2) A document defining the requirements for B2BUAs with respect to loop > detection/prevention. > 3) A document defining the requirements for B2BUAs to support end-to- > end and hop-by-hop media-loopback test calls. > 4) A document defining the requirements for B2BUAs to support DTLS-SRTP > (RFC 5764) end-to-end. > 5) A document defining the requirements for B2BUAs to support STUN > connectivity checks end-to-end. >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Peter.Dawes@vodafone.com Tue Feb 21 06:58:16 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8086521F8857 for ; Tue, 21 Feb 2012 06:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZZA+T5XkPOQ for ; Tue, 21 Feb 2012 06:58:12 -0800 (PST) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by ietfa.amsl.com (Postfix) with ESMTP id 5BCFE21F884F for ; Tue, 21 Feb 2012 06:58:12 -0800 (PST) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id B12C72149E1 for ; Tue, 21 Feb 2012 15:58:10 +0100 (CET) Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint02 (Postfix) with ESMTPS id 9DC65214977; Tue, 21 Feb 2012 15:58:10 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 15:57:44 +0100 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: Tue, 21 Feb 2012 15:58:09 +0100 Message-ID: In-Reply-To: <026901ccf003$8f063aa0$ad12afe0$@packetizer.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Revised Proposed Session-ID Charter Thread-Index: AQFuH+2Dh9+77xg5TjYrG8plMP4/MpcDxxpQgAFKkiA= References: <026901ccf003$8f063aa0$ad12afe0$@packetizer.com> From: "Dawes, Peter, VF-Group" To: "Paul E. Jones" , X-OriginalArrivalTime: 21 Feb 2012 14:57:44.0083 (UTC) FILETIME=[2A8B8E30:01CCF0A9] Subject: Re: [dispatch] Revised Proposed Session-ID Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:58:16 -0000 Hi Paul, Thanks for reading the draft. It is expected (clause 6.) that the configuration framework in RFC 6080 will be used with a profile type of "User Profile", so subscription to d1.foocorp.com would be as below (from RFC 6080). Regards, Peter (RFC 6080) 5.1.4.3. User Profile Type To create a Subscription URI to request the user profile on behalf of a user, the device needs to know the user's AoR. This can be statically or dynamically configured on the device (e.g., user input, or propagated as part of the device profile). Similar to device profiles, the content and propagation of user profiles may differ, based on deployment scenarios (i.e., users belonging to the same domain may -- or may not -- be provided the same profile). To create a Subscription URI, the following rules apply: Petrie & Channabasappa Standards Track [Page 21] RFC 6080 SIP Configuration Framework March 2011 o The device MUST set the Request-URI to the user AoR. o The device MUST populate the From field with the user AoR. An authoritative SIP proxy for a SIP provider's network that receives a profile enrollment request for the user profile type will route based on the Event Header field values, thus allowing a subscription to the user's AoR to be routed to the appropriate PDS. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: 20 February 2012 19:12 To: Dawes, Peter, VF-Group; dispatch@ietf.org Cc: laura.liess.dt@googlemail.com Subject: RE: [dispatch] Revised Proposed Session-ID Charter Peter, I looked over the draft quickly (so perhaps I missed it), but how does Alice learn the address of d1.foocorp.com? Paul > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com] > Sent: Monday, February 20, 2012 12:21 PM > To: dispatch@ietf.org > Cc: laura.liess.dt@googlemail.com; paulej@packetizer.com > Subject: Re: [dispatch] Revised Proposed Session-ID Charter >=20 > Hello Laura, All, > The topic of Session-ID has interest from both IETF, 3GPP, and the=20 > Open Mobile Alliance (OMA) and I am keen to contribute to any new WG.=20 > I have just re-submitted my session-id related draft to label it "dispatch" > (not "sipping" as previously). >=20 > http://datatracker.ietf.org/doc/draft-dawes-dispatch-debug/ >=20 > To help track the various requirements and proposals, clause " 3. > Related Drafts and Specifications" has been added with a list of other > drafts (currently 5) and non-IETF specifications (currently 2) that I=20 > am aware of related to this topic. I hope we can proceed soon with the work. >=20 > Regards, > Peter From fluffy@iii.ca Wed Feb 22 16:16:21 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F2321F855A for ; Wed, 22 Feb 2012 16:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7O+PrUZCPBu for ; Wed, 22 Feb 2012 16:16:20 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1A93021F8577 for ; Wed, 22 Feb 2012 16:16:18 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CEB4622E257; Wed, 22 Feb 2012 19:16:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Wed, 22 Feb 2012 17:16:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> To: "PFAUTZ, PENN L" X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 00:16:21 -0000 I don't get how this is better than an ITAD formatted to be 8 digits = long with leading zeros.=20 On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: > I've submitted a new version of the SPID I-D Rich referred to below. = Per dispatch at the Quebec meeting it's for discussion on the RAI list. > It differs from the previous version in asking the RIRs rather than = IANA directly to handle registrations. (This is to minimize junk = registrations and provide a whois service) >=20 > Penn Pfautz > AT&T Access Management > +1-732-420-4962 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Richard Shockey > Sent: Tuesday, February 07, 2012 7:32 PM > To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel = Khan' > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SPID Sequence and Loop Detection >=20 > Ok .. but the basics are essential. >=20 > I want to commend to all of you the concept of a Universal SPID = embodied in > this draft. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifi= er > -urn-01.txt >=20 > It needs work and input from everyone here, but the core issue here is > identification of issues along the session path especially as it = transits > across national boundaries or transit intermediaries. >=20 > What is the malfunction that we can't agree on a tracing mechanism. = Session > ID for goodness sake. DO IT. Charter the damn thing. >=20 > It may seem trivial. Its not. Especially if you are a regulator = looking at > how to create competitive transit markets. Do you all want another = Shockey > lecture on what the national regulators are up to ??? >=20 > Sohel to his eternal credit is starting to identify the larger problem = of > the End of POTS. >=20 > I've avoided proposing a RAI Directorate on End of Life (EOL) issues = with > TDM but it's coming. >=20 >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf > Of Daryl Malas > Sent: Tuesday, February 07, 2012 2:05 PM > To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SPID Sequence and Loop Detection >=20 > Notice I specifically said, "Service Providers acting as an IXC never = want > to indicate their service provider relationships to their customers." > This does not preclude a contractual agreement between two SSPs. >=20 >=20 > On 2/7/12 11:35 AM, "Leontsinis, Nikos" > wrote: >=20 >> I am not 100% sure about this. On some environments say IPX this can = be >> desirable it is written in the contract I will send you traffic to >> USA FIXED and you are obliged to route it to carrier B. This is the = area >> where the SPID could make sense. >>=20 >>=20 >> /nikos >> ________________________________________ >> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf = Of >> Daryl Malas [D.Malas@cablelabs.com] >> Sent: Tuesday, February 07, 2012 7:06 PM >> To: Cullen Jennings; Sohel Khan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>=20 >> Cullen's point here is very valid. Service Providers acting as an = IXC >> never want to indicate their service provider relationships to their >> customers. They create interconnects to many service providers to >> maintain the lowest termination costs in order to increase their = margins >> for LD termination. Sohel describes a real problem. >>=20 >> In telecommunication networks, it seems as though we have many = different >> carrier identification mechanisms already defined. I am leery of = creating >> yet another, even if it is encrypted. I would be more inclined to = look at >> existing loop detection mechanisms and see if they will work either: >> - as currently defined, >> - need to be extended or >> - need to be enforced (aka not blocked or reset by a B2BUA). >>=20 >> --Daryl >>=20 >> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>=20 >>>=20 >>> When doing least cost routing, my experience has been that if A = delivers >>> the call to B that B will then send to C, B wants to hide this fact = from >>> C and certainly wants to hide from A that they the call went to C. >>> Otherwise B gets cut out and A and C just set up a peering deal = directly. >>>=20 >>> So I worry a scheme like this would not work as B's SBC would be >>> configured to remove this. >>>=20 >>>=20 >>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>=20 >>>> SIP calls routing in an infinite loop in a subset of networks is a >>>> known phenomenon. >>>> Various SIP methods exist today may be used to detect and mitigate >>>> loops. Operational engineers would like to see a method that = indicates >>>> the sequence of providers=B9 IDs in the call path. Based on the = input from >>>> the operational engineers, we are proposing a new SIP header >>> Sequence> to detect SIP routing loop. This method is preferred by = the >>>> operational engineers of large providers=B9 networks. >>>>=20 >>>> Assume that a SIP call originating from provider Alpha (SPID: = 77777777) >>>> and traversing through provider Bravo (SPID: 55555555), Charlie = (SPID: >>>> 33333333), and looping back to Alpha. >>>>=20 >>>> With the new method, the SIP INVITE contains the new header SPID >>>> sequence {33333333, 55555555, 77777777}. >>>>=20 >>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>> arrives to Alpha=B9s network, Alpha will detect 77777777 in the = SPID >>>> sequence and conclude that a loop has occurred. >>>>=20 >>>> In the above use case, an example =B3SPID-sequence=B2 header is as = follows: >>>> SPID-Sequence:;index=3D1; >>>> SPID-Sequence:;index=3D1.1; >>>> SPID-Sequence:;index=3D1.2; >>>>=20 >>>> A provider wishing not to divulge its SPID, may insert a private or = a >>>> blank value. >>>> SPID-Sequence:;index=3D1; >>>> SPID-Sequence:;index=3D1.1; >>>> SPID-Sequence:;index=3D1.2 >>>> SPID-Sequence:;index=3D1.3; >>>> A provider should not delete any value from the SPID sequence = unless >>>> the SPID is its own. >>>> We had some discussion in the DISPATCH meetings on ideas such as = this. >>>> We would need a broader community support and help to initiate a = work in >>>> IETF RTC WG on SPID sequence. >>>> Please let us know your opinion. >>>>=20 >>>>=20 >>>>=20 >>>> Regards, Sohel Khan >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >> DISCLAIMER: >> This electronic mail message is intended exclusively for the = individual >> or entity to which it is addressed. This message, together with any >> attachment, may contain confidential and legally privileged = information. >> Any views, opinions or conclusions expressed in this message are = those of >> the individual sender and do not necessarily reflect the views of >> OTEGLOBE. Any unauthorized review, use, printing, copying, retention, >> disclosure or distribution is strictly prohibited. If you have = received >> this message in error, please immediately advise the sender by reply >> email message to the sender and delete all copies of this message. >> OTEGLOBE cannot accept any responsibility for the accuracy or >> completeness of this message as it has been transmitted over a public >> network. If you suspect that the message may have been intercepted or >> amended in any way please contact the sender. Thank you. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Wed Feb 22 16:34:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9381921F861C for ; Wed, 22 Feb 2012 16:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH9FeLF-8ecc for ; Wed, 22 Feb 2012 16:34:02 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3C421F861B for ; Wed, 22 Feb 2012 16:34:01 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 22 Feb 2012 19:33:58 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Wed, 22 Feb 2012 19:33:58 -0500 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: AQHM8cBhzYImTwtvFE+EVE08WCRFt5ZJoij7 Date: Thu, 23 Feb 2012 00:33:57 +0000 Message-ID: <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com>, <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> In-Reply-To: <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 00:34:03 -0000 Because it costs money. A small annual fee, to keep contact freshness and= discourage junk. Sent from my iPhone On Feb 22, 2012, at 7:16 PM, "Cullen Jennings" wrote: >=20 > I don't get how this is better than an ITAD formatted to be 8 digits long= with leading zeros.=20 >=20 >=20 >=20 > On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: >=20 >> I've submitted a new version of the SPID I-D Rich referred to below. Per= dispatch at the Quebec meeting it's for discussion on the RAI list. >> It differs from the previous version in asking the RIRs rather than IANA= directly to handle registrations. (This is to minimize junk registrations = and provide a whois service) >>=20 >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Be= half Of Richard Shockey >> Sent: Tuesday, February 07, 2012 7:32 PM >> To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel Khan' >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>=20 >> Ok .. but the basics are essential. >>=20 >> I want to commend to all of you the concept of a Universal SPID embodied= in >> this draft. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identi= fier >> -urn-01.txt >>=20 >> It needs work and input from everyone here, but the core issue here is >> identification of issues along the session path especially as it transit= s >> across national boundaries or transit intermediaries. >>=20 >> What is the malfunction that we can't agree on a tracing mechanism. Sess= ion >> ID for goodness sake. DO IT. Charter the damn thing. >>=20 >> It may seem trivial. Its not. Especially if you are a regulator looking = at >> how to create competitive transit markets. Do you all want another Shock= ey >> lecture on what the national regulators are up to ??? >>=20 >> Sohel to his eternal credit is starting to identify the larger problem o= f >> the End of POTS. >>=20 >> I've avoided proposing a RAI Directorate on End of Life (EOL) issues wit= h >> TDM but it's coming. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Be= half >> Of Daryl Malas >> Sent: Tuesday, February 07, 2012 2:05 PM >> To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>=20 >> Notice I specifically said, "Service Providers acting as an IXC never wa= nt >> to indicate their service provider relationships to their customers." >> This does not preclude a contractual agreement between two SSPs. >>=20 >>=20 >> On 2/7/12 11:35 AM, "Leontsinis, Nikos" >> wrote: >>=20 >>> I am not 100% sure about this. On some environments say IPX this can be >>> desirable it is written in the contract I will send you traffic to >>> USA FIXED and you are obliged to route it to carrier B. This is the are= a >>> where the SPID could make sense. >>>=20 >>>=20 >>> /nikos >>> ________________________________________ >>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf O= f >>> Daryl Malas [D.Malas@cablelabs.com] >>> Sent: Tuesday, February 07, 2012 7:06 PM >>> To: Cullen Jennings; Sohel Khan >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>=20 >>> Cullen's point here is very valid. Service Providers acting as an IXC >>> never want to indicate their service provider relationships to their >>> customers. They create interconnects to many service providers to >>> maintain the lowest termination costs in order to increase their margin= s >>> for LD termination. Sohel describes a real problem. >>>=20 >>> In telecommunication networks, it seems as though we have many differen= t >>> carrier identification mechanisms already defined. I am leery of creat= ing >>> yet another, even if it is encrypted. I would be more inclined to look= at >>> existing loop detection mechanisms and see if they will work either: >>> - as currently defined, >>> - need to be extended or >>> - need to be enforced (aka not blocked or reset by a B2BUA). >>>=20 >>> --Daryl >>>=20 >>> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>>=20 >>>>=20 >>>> When doing least cost routing, my experience has been that if A delive= rs >>>> the call to B that B will then send to C, B wants to hide this fact fr= om >>>> C and certainly wants to hide from A that they the call went to C. >>>> Otherwise B gets cut out and A and C just set up a peering deal direct= ly. >>>>=20 >>>> So I worry a scheme like this would not work as B's SBC would be >>>> configured to remove this. >>>>=20 >>>>=20 >>>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>>=20 >>>>> SIP calls routing in an infinite loop in a subset of networks is a >>>>> known phenomenon. >>>>> Various SIP methods exist today may be used to detect and mitigate >>>>> loops. Operational engineers would like to see a method that indicate= s >>>>> the sequence of providers=B9 IDs in the call path. Based on the input= from >>>>> the operational engineers, we are proposing a new SIP header >>>> Sequence> to detect SIP routing loop. This method is preferred by the >>>>> operational engineers of large providers=B9 networks. >>>>>=20 >>>>> Assume that a SIP call originating from provider Alpha (SPID: 7777777= 7) >>>>> and traversing through provider Bravo (SPID: 55555555), Charlie (SPID= : >>>>> 33333333), and looping back to Alpha. >>>>>=20 >>>>> With the new method, the SIP INVITE contains the new header SPID >>>>> sequence {33333333, 55555555, 77777777}. >>>>>=20 >>>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>>> arrives to Alpha=B9s network, Alpha will detect 77777777 in the SPID >>>>> sequence and conclude that a loop has occurred. >>>>>=20 >>>>> In the above use case, an example =B3SPID-sequence=B2 header is as fo= llows: >>>>> SPID-Sequence:;index=3D1; >>>>> SPID-Sequence:;index=3D1.1; >>>>> SPID-Sequence:;index=3D1.2; >>>>>=20 >>>>> A provider wishing not to divulge its SPID, may insert a private or a >>>>> blank value. >>>>> SPID-Sequence:;index=3D1; >>>>> SPID-Sequence:;index=3D1.1; >>>>> SPID-Sequence:;index=3D1.2 >>>>> SPID-Sequence:;index=3D1.3; >>>>> A provider should not delete any value from the SPID sequence unless >>>>> the SPID is its own. >>>>> We had some discussion in the DISPATCH meetings on ideas such as this= . >>>>> We would need a broader community support and help to initiate a work= in >>>>> IETF RTC WG on SPID sequence. >>>>> Please let us know your opinion. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, Sohel Khan >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>> DISCLAIMER: >>> This electronic mail message is intended exclusively for the individual >>> or entity to which it is addressed. This message, together with any >>> attachment, may contain confidential and legally privileged information= . >>> Any views, opinions or conclusions expressed in this message are those = of >>> the individual sender and do not necessarily reflect the views of >>> OTEGLOBE. Any unauthorized review, use, printing, copying, retention, >>> disclosure or distribution is strictly prohibited. If you have received >>> this message in error, please immediately advise the sender by reply >>> email message to the sender and delete all copies of this message. >>> OTEGLOBE cannot accept any responsibility for the accuracy or >>> completeness of this message as it has been transmitted over a public >>> network. If you suspect that the message may have been intercepted or >>> amended in any way please contact the sender. Thank you. >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Wed Feb 22 16:46:14 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3758221E8013 for ; Wed, 22 Feb 2012 16:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIuewaxxjneK for ; Wed, 22 Feb 2012 16:46:13 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0056B21F84F1 for ; Wed, 22 Feb 2012 16:46:12 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 677FB22E259; Wed, 22 Feb 2012 19:46:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> Date: Wed, 22 Feb 2012 17:46:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com>, <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 00:46:14 -0000 Well it's a lot more than costs money - when I read ARIN policy to get = an AS, it not just $500 per year. I don't think I could get an AS = number.=20 So lets delve into this argument a bit deeper. What's the advantage in = this case of no junk registrations? Who care is someone that you will = never see a message from has a number?=20 It seems the primary difference is that it would keep certain types of = business locked out if they were unable to use protocols that needed one = of these numbers and they could not get one.=20 On Feb 22, 2012, at 5:33 PM, Hadriel Kaplan wrote: > Because it costs money. A small annual fee, to keep contact = freshness and discourage junk. >=20 > Sent from my iPhone >=20 > On Feb 22, 2012, at 7:16 PM, "Cullen Jennings" wrote: >=20 >>=20 >> I don't get how this is better than an ITAD formatted to be 8 digits = long with leading zeros.=20 >>=20 >>=20 >>=20 >> On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: >>=20 >>> I've submitted a new version of the SPID I-D Rich referred to below. = Per dispatch at the Quebec meeting it's for discussion on the RAI list. >>> It differs from the previous version in asking the RIRs rather than = IANA directly to handle registrations. (This is to minimize junk = registrations and provide a whois service) >>>=20 >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>>=20 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf Of Richard Shockey >>> Sent: Tuesday, February 07, 2012 7:32 PM >>> To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel = Khan' >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>=20 >>> Ok .. but the basics are essential. >>>=20 >>> I want to commend to all of you the concept of a Universal SPID = embodied in >>> this draft. >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifi= er >>> -urn-01.txt >>>=20 >>> It needs work and input from everyone here, but the core issue here = is >>> identification of issues along the session path especially as it = transits >>> across national boundaries or transit intermediaries. >>>=20 >>> What is the malfunction that we can't agree on a tracing mechanism. = Session >>> ID for goodness sake. DO IT. Charter the damn thing. >>>=20 >>> It may seem trivial. Its not. Especially if you are a regulator = looking at >>> how to create competitive transit markets. Do you all want another = Shockey >>> lecture on what the national regulators are up to ??? >>>=20 >>> Sohel to his eternal credit is starting to identify the larger = problem of >>> the End of POTS. >>>=20 >>> I've avoided proposing a RAI Directorate on End of Life (EOL) issues = with >>> TDM but it's coming. >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf >>> Of Daryl Malas >>> Sent: Tuesday, February 07, 2012 2:05 PM >>> To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>=20 >>> Notice I specifically said, "Service Providers acting as an IXC = never want >>> to indicate their service provider relationships to their = customers." >>> This does not preclude a contractual agreement between two SSPs. >>>=20 >>>=20 >>> On 2/7/12 11:35 AM, "Leontsinis, Nikos" = >>> wrote: >>>=20 >>>> I am not 100% sure about this. On some environments say IPX this = can be >>>> desirable it is written in the contract I will send you traffic to >>>> USA FIXED and you are obliged to route it to carrier B. This is the = area >>>> where the SPID could make sense. >>>>=20 >>>>=20 >>>> /nikos >>>> ________________________________________ >>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On = Behalf Of >>>> Daryl Malas [D.Malas@cablelabs.com] >>>> Sent: Tuesday, February 07, 2012 7:06 PM >>>> To: Cullen Jennings; Sohel Khan >>>> Cc: dispatch@ietf.org >>>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>>=20 >>>> Cullen's point here is very valid. Service Providers acting as an = IXC >>>> never want to indicate their service provider relationships to = their >>>> customers. They create interconnects to many service providers to >>>> maintain the lowest termination costs in order to increase their = margins >>>> for LD termination. Sohel describes a real problem. >>>>=20 >>>> In telecommunication networks, it seems as though we have many = different >>>> carrier identification mechanisms already defined. I am leery of = creating >>>> yet another, even if it is encrypted. I would be more inclined to = look at >>>> existing loop detection mechanisms and see if they will work = either: >>>> - as currently defined, >>>> - need to be extended or >>>> - need to be enforced (aka not blocked or reset by a B2BUA). >>>>=20 >>>> --Daryl >>>>=20 >>>> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>>>=20 >>>>>=20 >>>>> When doing least cost routing, my experience has been that if A = delivers >>>>> the call to B that B will then send to C, B wants to hide this = fact from >>>>> C and certainly wants to hide from A that they the call went to C. >>>>> Otherwise B gets cut out and A and C just set up a peering deal = directly. >>>>>=20 >>>>> So I worry a scheme like this would not work as B's SBC would be >>>>> configured to remove this. >>>>>=20 >>>>>=20 >>>>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>>>=20 >>>>>> SIP calls routing in an infinite loop in a subset of networks is = a >>>>>> known phenomenon. >>>>>> Various SIP methods exist today may be used to detect and = mitigate >>>>>> loops. Operational engineers would like to see a method that = indicates >>>>>> the sequence of providers=B9 IDs in the call path. Based on the = input from >>>>>> the operational engineers, we are proposing a new SIP header = >>>>> Sequence> to detect SIP routing loop. This method is preferred by = the >>>>>> operational engineers of large providers=B9 networks. >>>>>>=20 >>>>>> Assume that a SIP call originating from provider Alpha (SPID: = 77777777) >>>>>> and traversing through provider Bravo (SPID: 55555555), Charlie = (SPID: >>>>>> 33333333), and looping back to Alpha. >>>>>>=20 >>>>>> With the new method, the SIP INVITE contains the new header SPID >>>>>> sequence {33333333, 55555555, 77777777}. >>>>>>=20 >>>>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>>>> arrives to Alpha=B9s network, Alpha will detect 77777777 in the = SPID >>>>>> sequence and conclude that a loop has occurred. >>>>>>=20 >>>>>> In the above use case, an example =B3SPID-sequence=B2 header is = as follows: >>>>>> SPID-Sequence:;index=3D1; >>>>>> SPID-Sequence:;index=3D1.1; >>>>>> SPID-Sequence:;index=3D1.2; >>>>>>=20 >>>>>> A provider wishing not to divulge its SPID, may insert a private = or a >>>>>> blank value. >>>>>> SPID-Sequence:;index=3D1; >>>>>> SPID-Sequence:;index=3D1.1; >>>>>> SPID-Sequence:;index=3D1.2 >>>>>> SPID-Sequence:;index=3D1.3; >>>>>> A provider should not delete any value from the SPID sequence = unless >>>>>> the SPID is its own. >>>>>> We had some discussion in the DISPATCH meetings on ideas such as = this. >>>>>> We would need a broader community support and help to initiate a = work in >>>>>> IETF RTC WG on SPID sequence. >>>>>> Please let us know your opinion. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Regards, Sohel Khan >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>=20 >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>>=20 >>>> DISCLAIMER: >>>> This electronic mail message is intended exclusively for the = individual >>>> or entity to which it is addressed. This message, together with any >>>> attachment, may contain confidential and legally privileged = information. >>>> Any views, opinions or conclusions expressed in this message are = those of >>>> the individual sender and do not necessarily reflect the views of >>>> OTEGLOBE. Any unauthorized review, use, printing, copying, = retention, >>>> disclosure or distribution is strictly prohibited. If you have = received >>>> this message in error, please immediately advise the sender by = reply >>>> email message to the sender and delete all copies of this message. >>>> OTEGLOBE cannot accept any responsibility for the accuracy or >>>> completeness of this message as it has been transmitted over a = public >>>> network. If you suspect that the message may have been intercepted = or >>>> amended in any way please contact the sender. Thank you. >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From pp3129@att.com Wed Feb 22 16:55:58 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49021E801F for ; Wed, 22 Feb 2012 16:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8TjBtCIBzxh for ; Wed, 22 Feb 2012 16:55:57 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEF621E8019 for ; Wed, 22 Feb 2012 16:55:34 -0800 (PST) X-Env-Sender: pp3129@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1329958532!16983677!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30947 invoked from network); 23 Feb 2012 00:55:32 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Feb 2012 00:55:32 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1N0u2Wl016124; Wed, 22 Feb 2012 19:56:03 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1N0twbn016096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 19:55:58 -0500 Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by sflint01.pst.cso.att.com (RSA Interceptor); Wed, 22 Feb 2012 19:55:10 -0500 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([169.254.5.149]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 19:55:10 -0500 From: "PFAUTZ, PENN L" To: Cullen Jennings , Hadriel Kaplan Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: AQHM8cSNY16a6i9Hq0KzgYYPbT2wSpZJpl7Q Date: Thu, 23 Feb 2012 00:55:10 +0000 Message-ID: <38726EDA2109264987B45E29E758C4D6087083@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com>, <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.187.27] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 00:55:58 -0000 The intent is not to have a policy as restrictive as for AS numbers. What r= equirements should obtain beyond the fee is up for discussion which I encou= rage. I don't think a modest fee will discourage actual businesses as the f= ocus is on service providers as opposed to end users. (I expect some enterp= rises will want to join in - I don't have a problem with that). Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Cullen Jennings [mailto:fluffy@iii.ca] Sent: Wednesday, February 22, 2012 7:46 PM To: Hadriel Kaplan Cc: PFAUTZ, PENN L; dispatch@ietf.org list Subject: Re: [dispatch] SPID Sequence and Loop Detection Well it's a lot more than costs money - when I read ARIN policy to get an A= S, it not just $500 per year. I don't think I could get an AS number. So lets delve into this argument a bit deeper. What's the advantage in this= case of no junk registrations? Who care is someone that you will never see= a message from has a number? It seems the primary difference is that it would keep certain types of busi= ness locked out if they were unable to use protocols that needed one of the= se numbers and they could not get one. On Feb 22, 2012, at 5:33 PM, Hadriel Kaplan wrote: > Because it costs money. A small annual fee, to keep contact freshness a= nd discourage junk. > > Sent from my iPhone > > On Feb 22, 2012, at 7:16 PM, "Cullen Jennings" wrote: > >> >> I don't get how this is better than an ITAD formatted to be 8 digits lon= g with leading zeros. >> >> >> >> On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: >> >>> I've submitted a new version of the SPID I-D Rich referred to below. Pe= r dispatch at the Quebec meeting it's for discussion on the RAI list. >>> It differs from the previous version in asking the RIRs rather than IAN= A directly to handle registrations. (This is to minimize junk registrations= and provide a whois service) >>> >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On B= ehalf Of Richard Shockey >>> Sent: Tuesday, February 07, 2012 7:32 PM >>> To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel Khan' >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>> >>> Ok .. but the basics are essential. >>> >>> I want to commend to all of you the concept of a Universal SPID embodie= d in >>> this draft. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-ident= ifier >>> -urn-01.txt >>> >>> It needs work and input from everyone here, but the core issue here is >>> identification of issues along the session path especially as it transi= ts >>> across national boundaries or transit intermediaries. >>> >>> What is the malfunction that we can't agree on a tracing mechanism. Ses= sion >>> ID for goodness sake. DO IT. Charter the damn thing. >>> >>> It may seem trivial. Its not. Especially if you are a regulator looking= at >>> how to create competitive transit markets. Do you all want another Shoc= key >>> lecture on what the national regulators are up to ??? >>> >>> Sohel to his eternal credit is starting to identify the larger problem = of >>> the End of POTS. >>> >>> I've avoided proposing a RAI Directorate on End of Life (EOL) issues wi= th >>> TDM but it's coming. >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On B= ehalf >>> Of Daryl Malas >>> Sent: Tuesday, February 07, 2012 2:05 PM >>> To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>> >>> Notice I specifically said, "Service Providers acting as an IXC never w= ant >>> to indicate their service provider relationships to their customers." >>> This does not preclude a contractual agreement between two SSPs. >>> >>> >>> On 2/7/12 11:35 AM, "Leontsinis, Nikos" >>> wrote: >>> >>>> I am not 100% sure about this. On some environments say IPX this can b= e >>>> desirable it is written in the contract I will send you traffic to >>>> USA FIXED and you are obliged to route it to carrier B. This is the ar= ea >>>> where the SPID could make sense. >>>> >>>> >>>> /nikos >>>> ________________________________________ >>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf = Of >>>> Daryl Malas [D.Malas@cablelabs.com] >>>> Sent: Tuesday, February 07, 2012 7:06 PM >>>> To: Cullen Jennings; Sohel Khan >>>> Cc: dispatch@ietf.org >>>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>> >>>> Cullen's point here is very valid. Service Providers acting as an IXC >>>> never want to indicate their service provider relationships to their >>>> customers. They create interconnects to many service providers to >>>> maintain the lowest termination costs in order to increase their margi= ns >>>> for LD termination. Sohel describes a real problem. >>>> >>>> In telecommunication networks, it seems as though we have many differe= nt >>>> carrier identification mechanisms already defined. I am leery of crea= ting >>>> yet another, even if it is encrypted. I would be more inclined to loo= k at >>>> existing loop detection mechanisms and see if they will work either: >>>> - as currently defined, >>>> - need to be extended or >>>> - need to be enforced (aka not blocked or reset by a B2BUA). >>>> >>>> --Daryl >>>> >>>> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>>> >>>>> >>>>> When doing least cost routing, my experience has been that if A deliv= ers >>>>> the call to B that B will then send to C, B wants to hide this fact f= rom >>>>> C and certainly wants to hide from A that they the call went to C. >>>>> Otherwise B gets cut out and A and C just set up a peering deal direc= tly. >>>>> >>>>> So I worry a scheme like this would not work as B's SBC would be >>>>> configured to remove this. >>>>> >>>>> >>>>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>>> >>>>>> SIP calls routing in an infinite loop in a subset of networks is a >>>>>> known phenomenon. >>>>>> Various SIP methods exist today may be used to detect and mitigate >>>>>> loops. Operational engineers would like to see a method that indicat= es >>>>>> the sequence of providers=B9 IDs in the call path. Based on the inpu= t from >>>>>> the operational engineers, we are proposing a new SIP header >>>>> Sequence> to detect SIP routing loop. This method is preferred by th= e >>>>>> operational engineers of large providers=B9 networks. >>>>>> >>>>>> Assume that a SIP call originating from provider Alpha (SPID: 777777= 77) >>>>>> and traversing through provider Bravo (SPID: 55555555), Charlie (SPI= D: >>>>>> 33333333), and looping back to Alpha. >>>>>> >>>>>> With the new method, the SIP INVITE contains the new header SPID >>>>>> sequence {33333333, 55555555, 77777777}. >>>>>> >>>>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>>>> arrives to Alpha=B9s network, Alpha will detect 77777777 in the SPID >>>>>> sequence and conclude that a loop has occurred. >>>>>> >>>>>> In the above use case, an example =B3SPID-sequence=B2 header is as f= ollows: >>>>>> SPID-Sequence:;index=3D1; >>>>>> SPID-Sequence:;index=3D1.1; >>>>>> SPID-Sequence:;index=3D1.2; >>>>>> >>>>>> A provider wishing not to divulge its SPID, may insert a private or = a >>>>>> blank value. >>>>>> SPID-Sequence:;index=3D1; >>>>>> SPID-Sequence:;index=3D1.1; >>>>>> SPID-Sequence:;index=3D1.2 >>>>>> SPID-Sequence:;index=3D1.3; >>>>>> A provider should not delete any value from the SPID sequence unless >>>>>> the SPID is its own. >>>>>> We had some discussion in the DISPATCH meetings on ideas such as thi= s. >>>>>> We would need a broader community support and help to initiate a wor= k in >>>>>> IETF RTC WG on SPID sequence. >>>>>> Please let us know your opinion. >>>>>> >>>>>> >>>>>> >>>>>> Regards, Sohel Khan >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> DISCLAIMER: >>>> This electronic mail message is intended exclusively for the individua= l >>>> or entity to which it is addressed. This message, together with any >>>> attachment, may contain confidential and legally privileged informatio= n. >>>> Any views, opinions or conclusions expressed in this message are those= of >>>> the individual sender and do not necessarily reflect the views of >>>> OTEGLOBE. Any unauthorized review, use, printing, copying, retention, >>>> disclosure or distribution is strictly prohibited. If you have receive= d >>>> this message in error, please immediately advise the sender by reply >>>> email message to the sender and delete all copies of this message. >>>> OTEGLOBE cannot accept any responsibility for the accuracy or >>>> completeness of this message as it has been transmitted over a public >>>> network. If you suspect that the message may have been intercepted or >>>> amended in any way please contact the sender. Thank you. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Wed Feb 22 17:04:08 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA021E8013 for ; Wed, 22 Feb 2012 17:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUZf7XKSIiIj for ; Wed, 22 Feb 2012 17:04:07 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8D17C21F845C for ; Wed, 22 Feb 2012 17:04:07 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id dD3i1i0050vyq2s53D44wU; Thu, 23 Feb 2012 01:04:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id dD431i01Z07duvL3RD44CL; Thu, 23 Feb 2012 01:04:04 +0000 Message-ID: <4F459082.2040402@alum.mit.edu> Date: Wed, 22 Feb 2012 20:04:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> In-Reply-To: <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:04:08 -0000 On 2/22/12 7:16 PM, Cullen Jennings wrote: > > I don't get how this is better than an ITAD formatted to be 8 digits long with leading zeros. And I still don't see how either one is even remotely useful for loop detection. We have heard repeatedly that SPs feel they must keep the topology of their networks and the identity of their peers secret. But that will lead to removing/anonymizing the SPIDs in the request, just as Vias and Routes are anonymized. And then this won't work for loop detection. And we already have loop detection mechanisms, so why do we need another? Also, what is to prevent someone from forging SPIDs in a message? Thanks, Paul > On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: > >> I've submitted a new version of the SPID I-D Rich referred to below. Per dispatch at the Quebec meeting it's for discussion on the RAI list. >> It differs from the previous version in asking the RIRs rather than IANA directly to handle registrations. (This is to minimize junk registrations and provide a whois service) >> >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey >> Sent: Tuesday, February 07, 2012 7:32 PM >> To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel Khan' >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >> >> Ok .. but the basics are essential. >> >> I want to commend to all of you the concept of a Universal SPID embodied in >> this draft. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identifier >> -urn-01.txt >> >> It needs work and input from everyone here, but the core issue here is >> identification of issues along the session path especially as it transits >> across national boundaries or transit intermediaries. >> >> What is the malfunction that we can't agree on a tracing mechanism. Session >> ID for goodness sake. DO IT. Charter the damn thing. >> >> It may seem trivial. Its not. Especially if you are a regulator looking at >> how to create competitive transit markets. Do you all want another Shockey >> lecture on what the national regulators are up to ??? >> >> Sohel to his eternal credit is starting to identify the larger problem of >> the End of POTS. >> >> I've avoided proposing a RAI Directorate on End of Life (EOL) issues with >> TDM but it's coming. >> >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Daryl Malas >> Sent: Tuesday, February 07, 2012 2:05 PM >> To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >> >> Notice I specifically said, "Service Providers acting as an IXC never want >> to indicate their service provider relationships to their customers." >> This does not preclude a contractual agreement between two SSPs. >> >> >> On 2/7/12 11:35 AM, "Leontsinis, Nikos" >> wrote: >> >>> I am not 100% sure about this. On some environments say IPX this can be >>> desirable it is written in the contract I will send you traffic to >>> USA FIXED and you are obliged to route it to carrier B. This is the area >>> where the SPID could make sense. >>> >>> >>> /nikos >>> ________________________________________ >>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of >>> Daryl Malas [D.Malas@cablelabs.com] >>> Sent: Tuesday, February 07, 2012 7:06 PM >>> To: Cullen Jennings; Sohel Khan >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>> >>> Cullen's point here is very valid. Service Providers acting as an IXC >>> never want to indicate their service provider relationships to their >>> customers. They create interconnects to many service providers to >>> maintain the lowest termination costs in order to increase their margins >>> for LD termination. Sohel describes a real problem. >>> >>> In telecommunication networks, it seems as though we have many different >>> carrier identification mechanisms already defined. I am leery of creating >>> yet another, even if it is encrypted. I would be more inclined to look at >>> existing loop detection mechanisms and see if they will work either: >>> - as currently defined, >>> - need to be extended or >>> - need to be enforced (aka not blocked or reset by a B2BUA). >>> >>> --Daryl >>> >>> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>> >>>> >>>> When doing least cost routing, my experience has been that if A delivers >>>> the call to B that B will then send to C, B wants to hide this fact from >>>> C and certainly wants to hide from A that they the call went to C. >>>> Otherwise B gets cut out and A and C just set up a peering deal directly. >>>> >>>> So I worry a scheme like this would not work as B's SBC would be >>>> configured to remove this. >>>> >>>> >>>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>> >>>>> SIP calls routing in an infinite loop in a subset of networks is a >>>>> known phenomenon. >>>>> Various SIP methods exist today may be used to detect and mitigate >>>>> loops. Operational engineers would like to see a method that indicates >>>>> the sequence of providers¹ IDs in the call path. Based on the input from >>>>> the operational engineers, we are proposing a new SIP header>>>> Sequence> to detect SIP routing loop. This method is preferred by the >>>>> operational engineers of large providers¹ networks. >>>>> >>>>> Assume that a SIP call originating from provider Alpha (SPID: 77777777) >>>>> and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: >>>>> 33333333), and looping back to Alpha. >>>>> >>>>> With the new method, the SIP INVITE contains the new header SPID >>>>> sequence {33333333, 55555555, 77777777}. >>>>> >>>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>>> arrives to Alpha¹s network, Alpha will detect 77777777 in the SPID >>>>> sequence and conclude that a loop has occurred. >>>>> >>>>> In the above use case, an example ³SPID-sequence² header is as follows: >>>>> SPID-Sequence:;index=1; >>>>> SPID-Sequence:;index=1.1; >>>>> SPID-Sequence:;index=1.2; >>>>> >>>>> A provider wishing not to divulge its SPID, may insert a private or a >>>>> blank value. >>>>> SPID-Sequence:;index=1; >>>>> SPID-Sequence:;index=1.1; >>>>> SPID-Sequence:;index=1.2 >>>>> SPID-Sequence:;index=1.3; >>>>> A provider should not delete any value from the SPID sequence unless >>>>> the SPID is its own. >>>>> We had some discussion in the DISPATCH meetings on ideas such as this. >>>>> We would need a broader community support and help to initiate a work in >>>>> IETF RTC WG on SPID sequence. >>>>> Please let us know your opinion. >>>>> >>>>> >>>>> >>>>> Regards, Sohel Khan >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >>> DISCLAIMER: >>> This electronic mail message is intended exclusively for the individual >>> or entity to which it is addressed. This message, together with any >>> attachment, may contain confidential and legally privileged information. >>> Any views, opinions or conclusions expressed in this message are those of >>> the individual sender and do not necessarily reflect the views of >>> OTEGLOBE. Any unauthorized review, use, printing, copying, retention, >>> disclosure or distribution is strictly prohibited. If you have received >>> this message in error, please immediately advise the sender by reply >>> email message to the sender and delete all copies of this message. >>> OTEGLOBE cannot accept any responsibility for the accuracy or >>> completeness of this message as it has been transmitted over a public >>> network. If you suspect that the message may have been intercepted or >>> amended in any way please contact the sender. Thank you. >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Thu Feb 23 02:42:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23B21F8679 for ; Thu, 23 Feb 2012 02:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.186 X-Spam-Level: X-Spam-Status: No, score=-110.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vi8hW4ft0iR4 for ; Thu, 23 Feb 2012 02:42:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC3721F84FB for ; Thu, 23 Feb 2012 02:42:08 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-13-4f4617ffdb52 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 94.5D.01970.FF7164F4; Thu, 23 Feb 2012 11:42:07 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012 11:42:07 +0100 Message-ID: <4F4617FE.5010504@ericsson.com> Date: Thu, 23 Feb 2012 12:42:06 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] A comment on draft-kaplan-dispatch-b2bua-taxonomy-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 10:42:09 -0000 Hi, Section 3 of the draft says: > A typical centralized conference server, for example, is > not a B2BUA because it is the target UAS of multiple UACs, whereby > the UACs individually and independently initiate separate SIP > sessions to the central conference server. You may want to clarify whether or not a conference server receiving an INVITE and fanning out several INVITEs is a B2BUA (e.g., in a push-to-talk call). The mechanism used to establish such a conference is described in RFC 5366. It is the same mechanism as the one used to invoke inline transcoding, and the document says inline transcoders are B2BUAs. The difference is that in a conference, there is typically more than one outgoing INVITE request. The document needs to clarify whether for each of those legs, the conference server should be considered a B2BUA. Also, you may want to include an Abstract and expand acronyms on their first use. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Feb 23 02:57:05 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39D21F8646 for ; Thu, 23 Feb 2012 02:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.193 X-Spam-Level: X-Spam-Status: No, score=-110.193 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqoDrYxy6OIw for ; Thu, 23 Feb 2012 02:57:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 80AF721F862B for ; Thu, 23 Feb 2012 02:57:03 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-8a-4f461b7e75d0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.9A.27041.E7B164F4; Thu, 23 Feb 2012 11:57:02 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012 11:57:02 +0100 Message-ID: <4F461B7D.7090108@ericsson.com> Date: Thu, 23 Feb 2012 12:57:01 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] A comment on draft-kaplan-dispatch-b2bua-loop-detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 10:57:05 -0000 Hi, Section 4 of the draft says: http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-loop-detection-00#section-4 > 4. B2BUA Loop-Detection Behavior > > > A Proxy-B2BUA, as defined in [draft-b2bua-taxonomy], MUST implement > the loop-detection mechanism for the Via header field, as defined > for a Proxy in [RFC5393]. > > [Note: should we require all B2BUAs to perform Via-header loop- > detection as well, even if they themselves don't forward on the Via > headers?] This requirement needs to go beyond Proxy-B2BUAs. For example, a Signaling-only B2BUA that happens to inspect message bodies needs to be required to do loop detection as well. A better way to scope this requirement could be to say that all B2BUAs need to perform loop detection and then think of exceptions to the rule and specify them explicitly if needed. For example, the draft could say that all B2BUAs MUST perform loop detection *unless* they do not forward Via headers on. Or using positive language, the draft could say that all B2BUAs that forward Via headers on MUST perform loop detection. Cheers, Gonzalo From pkyzivat@alum.mit.edu Thu Feb 23 09:13:53 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDA521F87CF for ; Thu, 23 Feb 2012 09:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2fDKGih6RZW for ; Thu, 23 Feb 2012 09:13:52 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id E219321F87CB for ; Thu, 23 Feb 2012 09:13:51 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id dUJp1i00D1uE5Es55VDsHl; Thu, 23 Feb 2012 17:13:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id dVDr1i00k07duvL3cVDssR; Thu, 23 Feb 2012 17:13:52 +0000 Message-ID: <4F4673CE.5060407@alum.mit.edu> Date: Thu, 23 Feb 2012 12:13:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F4617FE.5010504@ericsson.com> In-Reply-To: <4F4617FE.5010504@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] A comment on draft-kaplan-dispatch-b2bua-taxonomy-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:13:53 -0000 IMO a conference focus is indeed a B2BUA. And there are other things with similar topology that aren't conference servers that have a similar signaling topology. Those B2BUAs that coordinate *2* sessions are simply an interesting special case of that. For instance, a device that does what Splices was interested in, by splitting a voice+video session into separate sessions to a voice device and a video device, has similar topology and might be considered a special case of a conference server. (But I had people argue with me that it is not a conference server.) And devices that coordinate more than two sessions can have many of the same roles that are described in this draft for the 1:1 case. And then there is another hybrid: half UA, half B2BUA. E.g. a device that takes an audio+video session on one side, terminates the audio itself, but delegates the video to a separate device via a separate sip session. Thanks, Paul On 2/23/12 5:42 AM, Gonzalo Camarillo wrote: > Hi, > > Section 3 of the draft says: > >> A typical centralized conference server, for example, is >> not a B2BUA because it is the target UAS of multiple UACs, whereby >> the UACs individually and independently initiate separate SIP >> sessions to the central conference server. > > You may want to clarify whether or not a conference server receiving an > INVITE and fanning out several INVITEs is a B2BUA (e.g., in a > push-to-talk call). The mechanism used to establish such a conference is > described in RFC 5366. It is the same mechanism as the one used to > invoke inline transcoding, and the document says inline transcoders are > B2BUAs. The difference is that in a conference, there is typically more > than one outgoing INVITE request. The document needs to clarify whether > for each of those legs, the conference server should be considered a B2BUA. > > Also, you may want to include an Abstract and expand acronyms on their > first use. > > Cheers, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From gonzalo.camarillo@ericsson.com Thu Feb 23 09:30:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD421F87D8 for ; Thu, 23 Feb 2012 09:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.215 X-Spam-Level: X-Spam-Status: No, score=-110.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvgMuT55HXZF for ; Thu, 23 Feb 2012 09:30:02 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2721F87BE for ; Thu, 23 Feb 2012 09:30:01 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-7b-4f467798928c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 38.31.01970.897764F4; Thu, 23 Feb 2012 18:30:01 +0100 (CET) Received: from [131.160.126.146] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Thu, 23 Feb 2012 18:30:00 +0100 Message-ID: <4F467798.1060805@ericsson.com> Date: Thu, 23 Feb 2012 19:30:00 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:30:03 -0000 Folks, as you know, we are in the process of chartering the SIP Session ID WG. As usual, we need an acronym for this new group. Any suggestions? Note that I will be making a decision about this real soon. I will take into consideration all the input I receive before that. Cheers, Gonzalo From mphmmr@gmail.com Thu Feb 23 09:58:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B2C21F87D3 for ; Thu, 23 Feb 2012 09:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.375 X-Spam-Level: X-Spam-Status: No, score=-3.375 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Muxb6wO44Neg for ; Thu, 23 Feb 2012 09:58:20 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9859021F87D0 for ; Thu, 23 Feb 2012 09:58:19 -0800 (PST) Received: by lahl5 with SMTP id l5so2089016lah.31 for ; Thu, 23 Feb 2012 09:58:18 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.152.123.68 as permitted sender) client-ip=10.152.123.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.152.123.68 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.152.123.68]) by 10.152.123.68 with SMTP id ly4mr2042747lab.13.1330019898693 (num_hops = 1); Thu, 23 Feb 2012 09:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oQ5mhXOEkudZJ3OGpZuRBCcVwph4iro273HS4tJ/B3I=; b=PtWMnJL8QAd9m5KIxbSKNLxpyuMB3X1bvhRSd7rN1VMSIxDnlwK6FtN/W+a3+W1LV0 vdOCI2zRPD3mc0ha63DeZkCLWbnDz47nqqTPbMBFoOzx0lq3Zmgl74RJKPmOSAeIJ6Ns 7zZIu12K2mMwfygxs46V31++yLJ1RYFJ/f504= MIME-Version: 1.0 Received: by 10.152.123.68 with SMTP id ly4mr1722217lab.13.1330019898623; Thu, 23 Feb 2012 09:58:18 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 23 Feb 2012 09:58:18 -0800 (PST) In-Reply-To: <4F467798.1060805@ericsson.com> References: <4F467798.1060805@ericsson.com> Date: Thu, 23 Feb 2012 12:58:18 -0500 Message-ID: From: Michael Hammer To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=f46d044268e09a05ae04b9a56394 Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 17:58:20 -0000 --f46d044268e09a05ae04b9a56394 Content-Type: text/plain; charset=ISO-8859-1 SID ? On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo < Gonzalo.Camarillo@ericsson.com> wrote: > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d044268e09a05ae04b9a56394 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable SID ?


On Thu, Feb 23, 2012 at 12:30 = PM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
=
Folks,

as you know, we are in the process of chartering the SIP Session ID WG.
As usual, we need an acronym for this new group. Any suggestions?

Note that I will be making a decision about this real soon. I will take
into consideration all the input I receive before that.

Cheers,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--f46d044268e09a05ae04b9a56394-- From mary.ietf.barnes@gmail.com Thu Feb 23 10:20:27 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A6521F86EA for ; Thu, 23 Feb 2012 10:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.63 X-Spam-Level: X-Spam-Status: No, score=-103.63 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAB972GAisEb for ; Thu, 23 Feb 2012 10:20:25 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2C21F86CB for ; Thu, 23 Feb 2012 10:20:25 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1186119vbb.31 for ; Thu, 23 Feb 2012 10:20:25 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.70.165 as permitted sender) client-ip=10.52.70.165; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.70.165 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.52.70.165]) by 10.52.70.165 with SMTP id n5mr1527098vdu.55.1330021225094 (num_hops = 1); Thu, 23 Feb 2012 10:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q27DxGCHrnT/ylZDBzx+nI9B7XaHiFAB0pVin4M05XY=; b=WYP6Nwy4oPpLTQVY/+SKoY44D9Ss5HdtcVo8AoamlXDnrWAz9IaFsjKfh4o2llK0EA zLuTpKeF4ZEqTYbNwejhJke9UL5yoGBIGm9C2xzwmn81NwdlnxW3JRGO9ei54D5RT17N J1CwUvbTfRhkaNuyrV7PMivBoXQqTIThWu1dc= MIME-Version: 1.0 Received: by 10.52.70.165 with SMTP id n5mr1259360vdu.55.1330021225037; Thu, 23 Feb 2012 10:20:25 -0800 (PST) Received: by 10.52.114.200 with HTTP; Thu, 23 Feb 2012 10:20:25 -0800 (PST) In-Reply-To: References: <4F467798.1060805@ericsson.com> Date: Thu, 23 Feb 2012 12:20:25 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=bcaec5015e53a97f4004b9a5b22b Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:20:27 -0000 --bcaec5015e53a97f4004b9a5b22b Content-Type: text/plain; charset=ISO-8859-1 Not a good idea for several reasons: 1) http://www.internetslang.com/SID-meaning-definition.asp 2) It stands for something that is one of the most devastating things a parent can experience (think about it). 3) It really doesn't lean towards any intuitive idea of what it's about. I can't come up with anything creative at this time other than the very basic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a dozen or more. Mary. On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer wrote: > SID ? > > > On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo < > Gonzalo.Camarillo@ericsson.com> wrote: > >> Folks, >> >> as you know, we are in the process of chartering the SIP Session ID WG. >> As usual, we need an acronym for this new group. Any suggestions? >> >> Note that I will be making a decision about this real soon. I will take >> into consideration all the input I receive before that. >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --bcaec5015e53a97f4004b9a5b22b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not a good idea for several reasons:
2) It stands for something that is one of t= he most devastating things a parent can experience (think about it).=A0
3) It really doesn't lean towards any intuitive idea of what it= 9;s about.

I can't come up with anything creat= ive at this time other than the very basic SIPSID (pronounced SIPS-ID). =A0= I'm sure Hadriel can concoct a dozen or more.=A0

Mary.=A0

On Th= u, Feb 23, 2012 at 11:58 AM, Michael Hammer <mphmmr@gmail.com> wrote:
SID ?


On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo &= lt;Gonz= alo.Camarillo@ericsson.com> wrote:
Folks,

as you know, we are in the process of chartering the SIP Session ID WG.
As usual, we need an acronym for this new group. Any suggestions?

Note that I will be making a decision about this real soon. I will take
into consideration all the input I receive before that.

Cheers,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--bcaec5015e53a97f4004b9a5b22b-- From dean.willis@softarmor.com Thu Feb 23 11:15:02 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44321F8818 for ; Thu, 23 Feb 2012 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMCJOnpYbJ33 for ; Thu, 23 Feb 2012 11:15:00 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F01321F86C3 for ; Thu, 23 Feb 2012 11:15:00 -0800 (PST) Received: by yhkk25 with SMTP id k25so891766yhk.31 for ; Thu, 23 Feb 2012 11:14:59 -0800 (PST) Received-SPF: pass (google.com: domain of dean.willis@softarmor.com designates 10.236.184.6 as permitted sender) client-ip=10.236.184.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dean.willis@softarmor.com designates 10.236.184.6 as permitted sender) smtp.mail=dean.willis@softarmor.com Received: from mr.google.com ([10.236.184.6]) by 10.236.184.6 with SMTP id r6mr5349729yhm.82.1330024499791 (num_hops = 1); Thu, 23 Feb 2012 11:14:59 -0800 (PST) Received: by 10.236.184.6 with SMTP id r6mr4325800yhm.82.1330024499737; Thu, 23 Feb 2012 11:14:59 -0800 (PST) Received: from [192.168.2.124] (cpe-66-25-15-110.tx.res.rr.com. [66.25.15.110]) by mx.google.com with ESMTPS id b6sm3687505anc.3.2012.02.23.11.14.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 11:14:58 -0800 (PST) References: <4F467798.1060805@ericsson.com> In-Reply-To: <4F467798.1060805@ericsson.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 23 Feb 2012 13:14:57 -0600 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmbkke0RpieOklMnt8s8xq5d79zKbDKPchMpEd8SA2BVODQLmPDl7G0Tk97czO3NwiMQjOi Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:15:02 -0000 On Feb 23, 2012, at 11:30 AM, Gonzalo Camarillo wrote: > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? INSIPID -- Dean From mphmmr@gmail.com Thu Feb 23 11:22:26 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB62621F8868 for ; Thu, 23 Feb 2012 11:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTzyxRUdIqMn for ; Thu, 23 Feb 2012 11:22:25 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1A21F885B for ; Thu, 23 Feb 2012 11:22:25 -0800 (PST) Received: by bkuw12 with SMTP id w12so1575622bku.31 for ; Thu, 23 Feb 2012 11:22:24 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.102.68 as permitted sender) client-ip=10.112.102.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.102.68 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.102.68]) by 10.112.102.68 with SMTP id fm4mr1184749lbb.7.1330024944262 (num_hops = 1); Thu, 23 Feb 2012 11:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=knjhHvmxc7nhCH22QhmajJZWGqp+6ASAi3BOwM3issw=; b=scG7bzWEBbZdh6t7kqEpr7ZU+ZUNFBE0K6pnJmoqmgEvE0dBFEeqQ0MBbR+10r3wzN 3Kke6Jnl8FD3AdL+Ye4ifqrF5UHKFoWibsJ1LIE/BA8xk8TuYmebxpqjMnW8Fh1fgC9C vo2dsBrQ00E4MfhEnjDhsf7z7dzvy1jy/LVXA= MIME-Version: 1.0 Received: by 10.112.102.68 with SMTP id fm4mr999299lbb.7.1330024944035; Thu, 23 Feb 2012 11:22:24 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 23 Feb 2012 11:22:23 -0800 (PST) In-Reply-To: References: <4F467798.1060805@ericsson.com> Date: Thu, 23 Feb 2012 14:22:23 -0500 Message-ID: From: Michael Hammer To: Mary Barnes Content-Type: multipart/alternative; boundary=14dae9d7128c54e7f004b9a690a6 Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:22:27 -0000 --14dae9d7128c54e7f004b9a690a6 Content-Type: text/plain; charset=ISO-8859-1 Session ID. Was just trying to keep it short and simple. Sorry, I was never into the drug scene. Also, if you google just about anything I am sure you can come up with a thousand non-technical meanings. CLUE doesn't give a single intuitive clue about what it is about, so not sure about your criteria. Mike On Thu, Feb 23, 2012 at 1:20 PM, Mary Barnes wrote: > Not a good idea for several reasons: > 1) http://www.internetslang.com/SID-meaning-definition.asp > 2) It stands for something that is one of the most devastating things a > parent can experience (think about it). > 3) It really doesn't lean towards any intuitive idea of what it's about. > > I can't come up with anything creative at this time other than the very > basic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a dozen or > more. > > Mary. > > On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer wrote: > >> SID ? >> >> >> On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo < >> Gonzalo.Camarillo@ericsson.com> wrote: >> >>> Folks, >>> >>> as you know, we are in the process of chartering the SIP Session ID WG. >>> As usual, we need an acronym for this new group. Any suggestions? >>> >>> Note that I will be making a decision about this real soon. I will take >>> into consideration all the input I receive before that. >>> >>> Cheers, >>> >>> Gonzalo >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > --14dae9d7128c54e7f004b9a690a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Session ID. =A0Was just trying to keep it short and simple.
Sorry,= I was never into the drug scene.
Also, if you google just about = anything I am sure you can come up with a thousand non-technical meanings.<= /div>
CLUE doesn't give a single intuitive clue about what it is about, = so not sure about your criteria.

Mike
On Thu, Feb 23, 2012 at 1:20 PM, Ma= ry Barnes <mary.ietf.barnes@gmail.com> wrote:
Not a good idea for several reasons:
1) = http://www.internetslang.com/SID-meaning-definition.asp
2) It stands for something that is one of the most devastating things = a parent can experience (think about it).=A0
3) It really doesn't lean towards any intuitive idea of what it= 9;s about.

I can't come up with anything creat= ive at this time other than the very basic SIPSID (pronounced SIPS-ID). =A0= I'm sure Hadriel can concoct a dozen or more.=A0

Mary.=A0

On Th= u, Feb 23, 2012 at 11:58 AM, Michael Hammer <mphmmr@gmail.com> wrote:
SID ?


On Thu, F= eb 23, 2012 at 12:30 PM, Gonzalo Camarillo <Gonzalo.Camarillo= @ericsson.com> wrote:
Folks,

as you know, we are in the process of chartering the SIP Session ID WG.
As usual, we need an acronym for this new group. Any suggestions?

Note that I will be making a decision about this real soon. I will take
into consideration all the input I receive before that.

Cheers,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--14dae9d7128c54e7f004b9a690a6-- From mphmmr@gmail.com Thu Feb 23 11:41:49 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0521F886B for ; Thu, 23 Feb 2012 11:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.409 X-Spam-Level: X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sx+wBZcaF7h for ; Thu, 23 Feb 2012 11:41:48 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05021F8878 for ; Thu, 23 Feb 2012 11:41:47 -0800 (PST) Received: by lahl5 with SMTP id l5so2212916lah.31 for ; Thu, 23 Feb 2012 11:41:44 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.112.84.1 as permitted sender) client-ip=10.112.84.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.112.84.1 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.112.84.1]) by 10.112.84.1 with SMTP id u1mr1207366lby.35.1330026104967 (num_hops = 1); Thu, 23 Feb 2012 11:41:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5vSbYb8MDfxijTyY+Q+rXRhLr6RVh0GCGmQAT+hKd64=; b=avbfNO15p9upCXyUzuepVogjv0g7h2acSQz1KCXiMOhmvML7pOZQySM9HQ8QvSqm7F SfdREyAkD4fuChSzSe9cUy8isOoyis+TK/RzmM0YB6Ov6LnDYbCXm94GhGOyxp34B4Bj C+lsSUjUI6CF9q4u7zUt7Yi6aB9HQcT+M0MW0= MIME-Version: 1.0 Received: by 10.112.84.1 with SMTP id u1mr1012433lby.35.1330026104782; Thu, 23 Feb 2012 11:41:44 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 23 Feb 2012 11:41:44 -0800 (PST) In-Reply-To: References: <4F467798.1060805@ericsson.com> Date: Thu, 23 Feb 2012 14:41:44 -0500 Message-ID: From: Michael Hammer To: Mary Barnes Content-Type: multipart/alternative; boundary=f46d0401729784813a04b9a6d513 Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:41:49 -0000 --f46d0401729784813a04b9a6d513 Content-Type: text/plain; charset=ISO-8859-1 p.s. Alternatively, you could call it Sidney. (Sid is short for that, which is what I was thinking at the time.) Hopefully that is not traumatic in any way. On Thu, Feb 23, 2012 at 2:22 PM, Michael Hammer wrote: > Session ID. Was just trying to keep it short and simple. > Sorry, I was never into the drug scene. > Also, if you google just about anything I am sure you can come up with a > thousand non-technical meanings. > CLUE doesn't give a single intuitive clue about what it is about, so not > sure about your criteria. > > Mike > > On Thu, Feb 23, 2012 at 1:20 PM, Mary Barnes wrote: > >> Not a good idea for several reasons: >> 1) http://www.internetslang.com/SID-meaning-definition.asp >> 2) It stands for something that is one of the most devastating things a >> parent can experience (think about it). >> 3) It really doesn't lean towards any intuitive idea of what it's about. >> >> I can't come up with anything creative at this time other than the very >> basic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a dozen or >> more. >> >> Mary. >> >> On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer wrote: >> >>> SID ? >>> >>> >>> On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo < >>> Gonzalo.Camarillo@ericsson.com> wrote: >>> >>>> Folks, >>>> >>>> as you know, we are in the process of chartering the SIP Session ID WG. >>>> As usual, we need an acronym for this new group. Any suggestions? >>>> >>>> Note that I will be making a decision about this real soon. I will take >>>> into consideration all the input I receive before that. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >> > --f46d0401729784813a04b9a6d513 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable p.s. Alternatively, you could call it Sidney. =A0(Sid is short for that, wh= ich is what I was thinking at the time.)
Hopefully that is not traumati= c in any way.


On Thu, Feb 23, 2012 a= t 2:22 PM, Michael Hammer <mphmmr@gmail.com> wrote:
Session ID. =A0Was just trying to keep it sh= ort and simple.
Sorry, I was never into the drug scene.
= Also, if you google just about anything I am sure you can come up with a th= ousand non-technical meanings.
CLUE doesn't give a single intuitive clue about what it is about, = so not sure about your criteria.

Mike

On Thu, Feb = 23, 2012 at 1:20 PM, Mary Barnes <mary.ietf.barnes@gmail.com&= gt; wrote:
Not a good idea for several reasons:
1) = http://www.internetslang.com/SID-meaning-definition.asp
2) It stands for something that is one of the most devastating things = a parent can experience (think about it).=A0
3) It really doesn't lean towards any intuitive idea of what it= 9;s about.

I can't come up with anything creat= ive at this time other than the very basic SIPSID (pronounced SIPS-ID). =A0= I'm sure Hadriel can concoct a dozen or more.=A0

Mary.=A0

On Th= u, Feb 23, 2012 at 11:58 AM, Michael Hammer <mphmmr@gmail.com> wrote:
SID ?


On Thu, F= eb 23, 2012 at 12:30 PM, Gonzalo Camarillo <Gonzalo.Camarillo= @ericsson.com> wrote:
Folks,

as you know, we are in the process of chartering the SIP Session ID WG.
As usual, we need an acronym for this new group. Any suggestions?

Note that I will be making a decision about this real soon. I will take
into consideration all the input I receive before that.

Cheers,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch




--f46d0401729784813a04b9a6d513-- From mphmmr@gmail.com Thu Feb 23 11:43:35 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDAE21F8881 for ; Thu, 23 Feb 2012 11:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.423 X-Spam-Level: X-Spam-Status: No, score=-3.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwU2ZBNQgPGU for ; Thu, 23 Feb 2012 11:43:35 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9A3621F8878 for ; Thu, 23 Feb 2012 11:43:34 -0800 (PST) Received: by lahl5 with SMTP id l5so2214811lah.31 for ; Thu, 23 Feb 2012 11:43:33 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.152.123.68 as permitted sender) client-ip=10.152.123.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.152.123.68 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.152.123.68]) by 10.152.123.68 with SMTP id ly4mr2313894lab.13.1330026213751 (num_hops = 1); Thu, 23 Feb 2012 11:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CCVjf2ejrGkP/f9SJAf3n+q2q9P4PrH9WaXuE5CRZUQ=; b=f9uzXv9dqyRk36bU20gXBlY0SgAqzgbMKmzZyf1COPL4+p+v8Shu3tT2WcWGvO6ybA OfBAtuQ1x8FiTQk3Qr+nC8IL/bqK41dq4PjEpXoNqoOq/hgK3RbnqFrSwH1JEv4Hp43t m8RpiuNRcDS/6ox9fwJDPaYJtkYe2IOAX/xAs= MIME-Version: 1.0 Received: by 10.152.123.68 with SMTP id ly4mr1956234lab.13.1330026213686; Thu, 23 Feb 2012 11:43:33 -0800 (PST) Received: by 10.112.104.70 with HTTP; Thu, 23 Feb 2012 11:43:33 -0800 (PST) In-Reply-To: <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> Date: Thu, 23 Feb 2012 14:43:33 -0500 Message-ID: From: Michael Hammer To: Dean Willis Content-Type: multipart/alternative; boundary=f46d044268e0023bc404b9a6dcda Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:43:36 -0000 --f46d044268e0023bc404b9a6dcda Content-Type: text/plain; charset=ISO-8859-1 Good one! On Thu, Feb 23, 2012 at 2:14 PM, Dean Willis wrote: > > On Feb 23, 2012, at 11:30 AM, Gonzalo Camarillo wrote: > > > Folks, > > > > as you know, we are in the process of chartering the SIP Session ID WG. > > As usual, we need an acronym for this new group. Any suggestions? > > > > INSIPID > > -- > Dean > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d044268e0023bc404b9a6dcda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good one!

On Thu, Feb 23, 2012 at 2:14 PM= , Dean Willis <dean.willis@softarmor.com> wrote:

On Feb 23, 2012, at 11:30 AM, Gonzalo Camarillo wrote:

> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?



INSIPID

--
Dean

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--f46d044268e0023bc404b9a6dcda-- From gsalguei@cisco.com Thu Feb 23 12:10:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82021F883D for ; Thu, 23 Feb 2012 12:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoqEtqp2Ze1i for ; Thu, 23 Feb 2012 12:10:03 -0800 (PST) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4200E21F8702 for ; Thu, 23 Feb 2012 12:10:00 -0800 (PST) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1NK9xQ5002365 for ; Thu, 23 Feb 2012 12:09:59 -0800 (PST) Received: from sjc-vpn4-1272.cisco.com (sjc-vpn4-1272.cisco.com [10.21.84.247]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q1NK9w8C008643; Thu, 23 Feb 2012 12:09:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_3105F7B8-0F82-4C1C-9577-922C6B58314E" From: Gonzalo Salgueiro In-Reply-To: <4F467798.1060805@ericsson.com> Date: Thu, 23 Feb 2012 15:09:58 -0500 Message-Id: <436B09F2-C78A-4AFF-B64F-1DA55484C591@cisco.com> References: <4F467798.1060805@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1257) Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 20:10:04 -0000 --Apple-Mail=_3105F7B8-0F82-4C1C-9577-922C6B58314E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sip ENd-to-end SEssion Identifier = SENSEI Thanks, Gonzalo On Feb 23, 2012, at 12:30 PM, Gonzalo Camarillo wrote: > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --Apple-Mail=_3105F7B8-0F82-4C1C-9577-922C6B58314E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Sip ENd-to-end SEssion Identifier = SENSEI

Thanks,

Gonzalo


On Feb 23, 2012, at 12:30 PM, Gonzalo Camarillo wrote:

Folks,

as you know, we are in the process of chartering the SIP Session ID WG.
As usual, we need an acronym for this new group. Any suggestions?

Note that I will be making a decision about this real soon. I will take
into consideration all the input I receive before that.

Cheers,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--Apple-Mail=_3105F7B8-0F82-4C1C-9577-922C6B58314E-- From jmpolk@cisco.com Thu Feb 23 13:01:34 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DEE21F8875 for ; Thu, 23 Feb 2012 13:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.781 X-Spam-Level: X-Spam-Status: No, score=-108.781 tagged_above=-999 required=5 tests=[AWL=1.818, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNhKBwa7vXkZ for ; Thu, 23 Feb 2012 13:01:33 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 308E621F886C for ; Thu, 23 Feb 2012 13:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=465; q=dns/txt; s=iport; t=1330030893; x=1331240493; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=0BU7dSofbSo5GBnujAB3wSfbLkfMnTsfMK39OxVvBuw=; b=IHGbklqZJaTrD+TUMpbHE2zPFtxKvFsC90Rp+OasZ22evL6I2zLy/cbf z3gJJpF/BF/Lru+d1w6C5S4LiMMfvcKYJlcxDEs6HrfdwZ59OqGfRvhWP AmdpDD4b0UO2mhM67MAMq/m846JZC5dazFTFSLH+r2bmHYmpyQB89E8gJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOynRk+rRDoJ/2dsb2JhbABEslOBB4FzAQEBBAEBAQ8BJQI0CxAHBBgeEBkOMAYBEiKHaKAdAZcABI05AgUJBAMMAgMNGgIBAgECAoUeAg8PAwQFChoSgzwEiE+fdQ X-IronPort-AV: E=Sophos;i="4.73,471,1325462400"; d="scan'208";a="32075673" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 23 Feb 2012 21:01:33 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1NL1WNo013085; Thu, 23 Feb 2012 21:01:32 GMT Message-Id: <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Feb 2012 15:01:30 -0600 To: Dean Willis , Gonzalo Camarillo From: "James M. Polk" In-Reply-To: <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:01:34 -0000 At 01:14 PM 2/23/2012, Dean Willis wrote: >On Feb 23, 2012, at 11:30 AM, Gonzalo Camarillo wrote: > > > Folks, > > > > as you know, we are in the process of chartering the SIP Session ID WG. > > As usual, we need an acronym for this new group. Any suggestions? > > > >INSIPID I like it! >-- >Dean > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Thu Feb 23 16:58:30 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D654F21F8627 for ; Thu, 23 Feb 2012 16:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj7ZCaC6F28H for ; Thu, 23 Feb 2012 16:58:29 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id BA01621F8623 for ; Thu, 23 Feb 2012 16:58:29 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta01.westchester.pa.mail.comcast.net with comcast id dc1Y1i0091ZXKqc51cyWis; Fri, 24 Feb 2012 00:58:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id dcyV1i00S07duvL3hcyVNt; Fri, 24 Feb 2012 00:58:30 +0000 Message-ID: <4F46E0B4.3020305@alum.mit.edu> Date: Thu, 23 Feb 2012 19:58:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> In-Reply-To: <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:58:30 -0000 +1 On 2/23/12 4:01 PM, James M. Polk wrote: > At 01:14 PM 2/23/2012, Dean Willis wrote: >> >> INSIPID > > I like it! From christian.1.schmidt@nsn.com Fri Feb 24 00:33:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D866721F86CF for ; Fri, 24 Feb 2012 00:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35MTs5tRbagO for ; Fri, 24 Feb 2012 00:33:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 887FC21F860F for ; Fri, 24 Feb 2012 00:32:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q1O8WaDC030162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Feb 2012 09:32:36 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q1O8WW0p023472; Fri, 24 Feb 2012 09:32:36 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 09:32:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF2CE.DB60B292" Date: Fri, 24 Feb 2012 09:32:33 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AczyV9Q8n6kpNTNhQe+d16skyhajtQAdo/Qg References: <4F467798.1060805@ericsson.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Mary Barnes" , "Michael Hammer" X-OriginalArrivalTime: 24 Feb 2012 08:32:34.0548 (UTC) FILETIME=[DB6D9B40:01CCF2CE] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8450 X-purgate-ID: 151667::1330072356-000015E0-26DF2544/0-0/0-0 Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:33:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF2CE.DB60B292 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What about SIDE? Session ID Extension. Somehow a topic on a border line. =20 Servus Christian =20 =20 =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Mary Barnes Sent: Thursday, February 23, 2012 7:20 PM To: Michael Hammer Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG =20 Not a good idea for several reasons: 1) http://www.internetslang.com/SID-meaning-definition.asp 2) It stands for something that is one of the most devastating things a parent can experience (think about it).=20 3) It really doesn't lean towards any intuitive idea of what it's about. =20 I can't come up with anything creative at this time other than the very basic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a dozen or more.=20 =20 Mary.=20 =20 On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer wrote: SID ? =20 On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo wrote: Folks, as you know, we are in the process of chartering the SIP Session ID WG. As usual, we need an acronym for this new group. Any suggestions? Note that I will be making a decision about this real soon. I will take into consideration all the input I receive before that. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------_=_NextPart_001_01CCF2CE.DB60B292 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What about SIDE?

Session ID Extension.

Somehow a topic on a border line.

 

Servus

Christian

 

 

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of ext Mary Barnes
Sent: Thursday, February 23, = 2012 7:20 PM
To: Michael Hammer
Cc: = DISPATCH
Subject: Re: [dispatch] Acronym for the SIP Session = ID WG

 

Not a good = idea for several reasons:

<= div>

2) It stands for something that is one of the = most devastating things a parent can experience (think about = it). 

3) It really = doesn't lean towards any intuitive idea of what it's = about.

 

I = can't come up with anything creative at this time other than the very = basic SIPSID (pronounced SIPS-ID).  I'm sure Hadriel can concoct a = dozen or more. 

 

Mary. 

 

On Thu, = Feb 23, 2012 at 11:58 AM, Michael Hammer <mphmmr@gmail.com> = wrote:

SID = ?

 

On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo = <Gonzalo.Camarillo@ericsson.com> = wrote:

Folks,

as you know, we = are in the process of chartering the SIP Session ID WG.
As usual, we = need an acronym for this new group. Any suggestions?

Note that I = will be making a decision about this real soon. I will take
into = consideration all the input I receive before = that.

Cheers,

Gonzalo
__________________________________= _____________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 


______________________________________= _________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 

------_=_NextPart_001_01CCF2CE.DB60B292-- From christer.holmberg@ericsson.com Fri Feb 24 00:50:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BAF21F884E for ; Fri, 24 Feb 2012 00:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g45Jau13PxL5 for ; Fri, 24 Feb 2012 00:50:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A90A521F87D0 for ; Fri, 24 Feb 2012 00:50:18 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-94-4f474f496672 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8F.40.27041.94F474F4; Fri, 24 Feb 2012 09:50:17 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Fri, 24 Feb 2012 09:50:17 +0100 From: Christer Holmberg To: "Schmidt, Christian 1. (NSN - DE/Munich)" , ext Mary Barnes , Michael Hammer Date: Fri, 24 Feb 2012 09:50:15 +0100 Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AczyV9Q8n6kpNTNhQe+d16skyhajtQAdo/QgAACRooA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> References: <4F467798.1060805@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:50:20 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable STROBA SomeThing we aRe fOrced to do Because of hAdriel's sbcs. ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Schmidt, Christian 1. (NSN - DE/Munich) Sent: 24. helmikuuta 2012 10:33 To: ext Mary Barnes; Michael Hammer Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG What about SIDE? Session ID Extension. Somehow a topic on a border line. Servus Christian From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of ext Mary Barnes Sent: Thursday, February 23, 2012 7:20 PM To: Michael Hammer Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Not a good idea for several reasons: 1) http://www.internetslang.com/SID-meaning-definition.asp 2) It stands for something that is one of the most devastating things a par= ent can experience (think about it). 3) It really doesn't lean towards any intuitive idea of what it's about. I can't come up with anything creative at this time other than the very bas= ic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a dozen or mo= re. Mary. On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer > wrote: SID ? On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo > wrote: Folks, as you know, we are in the process of chartering the SIP Session ID WG. As usual, we need an acronym for this new group. Any suggestions? Note that I will be making a decision about this real soon. I will take into consideration all the input I receive before that. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
STROBA
 
SomeThing we aRe fOrced to do Because = of=20 hAdriel's sbcs.
 
 
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Schmidt, Christian 1= .=20 (NSN - DE/Munich)
Sent: 24. helmikuuta 2012 10:33
To: e= xt=20 Mary Barnes; Michael Hammer
Cc: DISPATCH
Subject: Re:=20 [dispatch] Acronym for the SIP Session ID WG

What=20 about SIDE?

Session=20 ID Extension.

Somehow=20 a topic on a border line.

 

Servus

Christian

 

 

 

From:<= /B>=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf O= f=20 ext Mary Barnes
Sent: Thursday, February 23, 2012 7:20=20 PM
To: Michael Hammer
Cc: DISPATCH
Subject: R= e:=20 [dispatch] Acronym for the SIP Session ID WG

 

Not a good idea for several reasons:

1) http://www= .internetslang.com/SID-meaning-definition.asp

2) It stands for something that is one of the most=20 devastating things a parent can experience (think about=20 it). 

3) It really doesn't lean towards any intuitive idea o= f what=20 it's about.

 

I can't come up with anything creative at this time ot= her=20 than the very basic SIPSID (pronounced SIPS-ID).  I'm sure Hadriel can= =20 concoct a dozen or more. 

 

Mary. 

 

On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer <<= A=20 href=3D"mailto:mphmmr@gmail.com">mphmmr@gmail.com> wrote:=

SID ?

 

On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo &l= t;Gonzalo.Camarillo@ericsson.com> wrote:

Folks,

as you know, we are in the process of=20 chartering the SIP Session ID WG.
As usual, we need an acronym for this = new=20 group. Any suggestions?

Note that I will be making a decision about = this=20 real soon. I will take
into consideration all the input I receive before= =20 that.

Cheers,

Gonzalo
____________________________________= ___________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 


_________________________________________= ______
dispatch=20 mailing list
dispatch@ietf.org<= BR>https://www.ietf.org/mailman/listinfo/dispatch

 

--_000_7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8ESESSCMS0356e_-- From lconroy@insensate.co.uk Fri Feb 24 01:05:59 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5C421F88F1 for ; Fri, 24 Feb 2012 01:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxcLN1W3Zobc for ; Fri, 24 Feb 2012 01:05:58 -0800 (PST) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF2721F88EE for ; Fri, 24 Feb 2012 01:05:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id B0F9B54C5A8; Fri, 24 Feb 2012 09:05:56 +0000 (GMT) X-Virus-Scanned: amavisd-new at insensate.co.uk Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO2fYZqIoG8y; Fri, 24 Feb 2012 09:05:55 +0000 (GMT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 599AF54C59D; Fri, 24 Feb 2012 09:05:55 +0000 (GMT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 24 Feb 2012 09:05:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <57AB07CF-0911-4D86-BE39-DFFB12E158B0@insensate.co.uk> References: <4F467798.1060805@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: DISPATCH list Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:05:59 -0000 On 24 Feb 2012, at 08:50, Christer Holmberg wrote: > STROBA >=20 > SomeThing we aRe fOrced to do Because of hAdriel's sbcs. Hi Christer, folks, Were they to be jut Hadriel's SBCs, there would be no problem. They = SELL loads of these; that's the problem :). all the best, Lawrence From paulej@packetizer.com Fri Feb 24 05:15:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC25221F848A for ; Fri, 24 Feb 2012 05:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+ZrJ+MD70JD for ; Fri, 24 Feb 2012 05:15:29 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E0BFF21F8711 for ; Fri, 24 Feb 2012 05:15:25 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q1ODFL65014444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Feb 2012 08:15:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1330089322; bh=U7evgjGN9AYQ90J2SFQpZuy5FbO1ooB0jk3+j3D3ml0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=D/+esPCYUiiQRto5KsTvGtwJfko2Xq/CxEtoX5yCO5eN2dPibk7jdlgYPdTOqQHCV XzDR4bR9pYr9it+9zOi7luBY0MVbB5Ez3azhnafiNXpjPBP0c+nAQmU6esfYN+eUxB iujA2qolNqypEa/S7V2vzqm+ZUkCNkUcI1djFn9s= From: "Paul E. Jones" To: "'James M. Polk'" , "'Dean Willis'" , "'Gonzalo Camarillo'" References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> In-Reply-To: <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> Date: Fri, 24 Feb 2012 08:15:21 -0500 Message-ID: <003601ccf2f6$5d3a7310$17af5930$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLP6P1g4jdTOQV7xp8gbuxUjDYm0gG+HGiIAM1d4dyUMb5PQA== Content-Language: en-us Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 13:15:30 -0000 insipid (adj): Lacking qualities that excite, stimulate, or interest; dull. It does not sound so inspiring ;-) > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of James M. Polk > Sent: Thursday, February 23, 2012 4:02 PM > To: Dean Willis; Gonzalo Camarillo > Cc: DISPATCH > Subject: Re: [dispatch] Acronym for the SIP Session ID WG > > At 01:14 PM 2/23/2012, Dean Willis wrote: > > >On Feb 23, 2012, at 11:30 AM, Gonzalo Camarillo wrote: > > > > > Folks, > > > > > > as you know, we are in the process of chartering the SIP Session ID > WG. > > > As usual, we need an acronym for this new group. Any suggestions? > > > > > > > >INSIPID > > I like it! > > > >-- > >Dean > > > >_______________________________________________ > >dispatch mailing list > >dispatch@ietf.org > >https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@iii.ca Fri Feb 24 08:06:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D972A21F8835 for ; Fri, 24 Feb 2012 08:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTg9WExKKQPm for ; Fri, 24 Feb 2012 08:06:03 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 652E321F8866 for ; Fri, 24 Feb 2012 08:06:03 -0800 (PST) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CA15922E1EB for ; Fri, 24 Feb 2012 11:06:02 -0500 (EST) From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 24 Feb 2012 09:06:02 -0700 References: <20120223211112.22619.51348.idtracker@ietfa.amsl.com> To: "dispatch@ietf.org list" Message-Id: <40CA2D6F-27CC-485F-AA8B-58048F356265@iii.ca> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dispatch] Fwd: dispatch - Requested session has been scheduled for IETF 83 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:06:04 -0000 FYI on meeting time at IETF 83 - note this is *draft* and may change. Begin forwarded message: > dispatch Session 1 (2 hours) > Tuesday, Afternoon Session I 1300-1500 > Room Name: Maillot From pkyzivat@alum.mit.edu Fri Feb 24 08:53:46 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199D421F8813 for ; Fri, 24 Feb 2012 08:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ3Wub6v39jY for ; Fri, 24 Feb 2012 08:53:45 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1921F8807 for ; Fri, 24 Feb 2012 08:53:43 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id dr3n1i00727AodY58stkbl; Fri, 24 Feb 2012 16:53:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id dstk1i00C07duvL3fstk9m; Fri, 24 Feb 2012 16:53:44 +0000 Message-ID: <4F47C096.8050901@alum.mit.edu> Date: Fri, 24 Feb 2012 11:53:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> <003601ccf2f6$5d3a7310$17af5930$@packetizer.com> In-Reply-To: <003601ccf2f6$5d3a7310$17af5930$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:53:46 -0000 On 2/24/12 8:15 AM, Paul E. Jones wrote: > insipid (adj): Lacking qualities that excite, stimulate, or interest; dull. Yup. Works for me. :-) Thanks, Paul > It does not sound so inspiring ;-) From HKaplan@acmepacket.com Fri Feb 24 10:11:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E8C21F88F3 for ; Fri, 24 Feb 2012 10:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXYKz2I6PAcZ for ; Fri, 24 Feb 2012 10:11:07 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B9F0321F88EB for ; Fri, 24 Feb 2012 10:11:06 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Feb 2012 13:11:04 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Fri, 24 Feb 2012 13:11:04 -0500 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AQHM8x+raDTdVQQF/Umi91L2TqPEnw== Date: Fri, 24 Feb 2012 18:11:03 +0000 Message-ID: <62A9ED0E-C13E-410B-8610-F6F42E5E9693@acmepacket.com> References: <4F467798.1060805@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_62A9ED0EC13E410B8610F6F42E5E9693acmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:11:23 -0000 --_000_62A9ED0EC13E410B8610F6F42E5E9693acmepacketcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I know (or hope) you're joking, because this is NOT just because of Acme SB= Cs, or even SBCs in general. A vast majority of IP-PBXs, Call-Managers, App-Servers, etc., I've seen cha= nge the Call-ID. As well as all the other SBCs. -hadriel p.s. for the past 4 or 5 years or more Acme's SBCs have by *default* NOT ch= anged the Call-ID - it's just that most operators immediately change this s= etting to make it change the Call-ID anyway. And we can't remove the abili= ty to change it, or else we'll be removed and replaced by another SBC that = will. And I don't blame operators for having the SBC change the Call-ID; i= t's a security issue, and often the only way to make SIP work right. On Feb 24, 2012, at 3:50 AM, Christer Holmberg wrote: STROBA SomeThing we aRe fOrced to do Because of hAdriel's sbcs. ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Schmidt, Christian 1. (NSN - DE/Muni= ch) Sent: 24. helmikuuta 2012 10:33 To: ext Mary Barnes; Michael Hammer Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG What about SIDE? Session ID Extension. Somehow a topic on a border line. Servus Christian From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of ext Mary Barnes Sent: Thursday, February 23, 2012 7:20 PM To: Michael Hammer Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Not a good idea for several reasons: 1) http://www.internetslang.com/SID-meaning-definition.asp 2) It stands for something that is one of the most devastating things a par= ent can experience (think about it). 3) It really doesn't lean towards any intuitive idea of what it's about. I can't come up with anything creative at this time other than the very bas= ic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a dozen or mo= re. Mary. On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer > wrote: SID ? On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo > wrote: Folks, as you know, we are in the process of chartering the SIP Session ID WG. As usual, we need an acronym for this new group. Any suggestions? Note that I will be making a decision about this real soon. I will take into consideration all the input I receive before that. Cheers, Gonzalo _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_62A9ED0EC13E410B8610F6F42E5E9693acmepacketcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <48B2037AF51F6342A5C5F46F990D55A6@acmepacket.com> Content-Transfer-Encoding: quoted-printable

I know (or hope) you're joking, because this is NOT just because of Ac= me SBCs, or even SBCs in general.
A vast majority of IP-PBXs, Call-Managers, App-Servers, etc., I've see= n change the Call-ID.  As well as all the other SBCs.

-hadriel
p.s. for the past 4 or 5 years or more Acme's SBCs have by *default* N= OT changed the Call-ID - it's just that most operators immediately change t= his setting to make it change the Call-ID anyway.  And we can't remove= the ability to change it, or else we'll be removed and replaced by another SBC that will.  And I don't blame = operators for having the SBC change the Call-ID; it's a security issue, and= often the only way to make SIP work right.


On Feb 24, 2012, at 3:50 AM, Christer Holmberg wrote:

 
STROBA
 
SomeThing we aRe fOrced to do Because of hAdriel's= sbcs.
 
 
 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ie= tf.org] On Behalf Of Schmidt, C= hristian 1. (NSN - DE/Munich)
Sent: 24. helmikuu= ta 2012 10:33
To: ext Mary Barne= s; Michael Hammer
Cc: DISPATCH
Subject: Re: [disp= atch] Acronym for the SIP Session ID WG

What about SIDE?
Session ID Extension.
Somehow a topic on a border line.
 
Servus
Christian
 
 
 
From:=  dispatch-bounces@ietf.org <= /span>[mailto:dispatch-bounces@ietf.org] On Behalf Of ext Mary B= arnes
Sent: Thursday, Fe= bruary 23, 2012 7:20 PM
To: Michael Hammer=
Cc: DISPATCH
Subject: Re: [disp= atch] Acronym for the SIP Session ID WG
 
Not a good idea for several reasons:
2) It stands for something that is one of the most devastating things a par= ent can experience (think about it). 
3) It really doesn't lean towards any intuitive idea of what it's about.
 
I can't come up with anything creative at this time other than the very bas= ic SIPSID (pronounced SIPS-ID).  I'm sure Hadriel can concoct a dozen = or more. 
 
Mary. 
 
On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer <mphmmr@gm= ail.com> wrote:
SID ?

 

On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
Folks,

as you know, we are in the process of chartering the SIP Session ID WG.
As usual, we need an acronym for this new group. Any suggestions?

Note that I will be making a decision about this real soon. I will take
into consideration all the input I receive before that.

Cheers,

Gonzalo
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/= mailman/listinfo/dispatch
 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/= mailman/listinfo/dispatch

 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/d= ispatch

--_000_62A9ED0EC13E410B8610F6F42E5E9693acmepacketcom_-- From pkyzivat@alum.mit.edu Fri Feb 24 10:34:34 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D931221F8731 for ; Fri, 24 Feb 2012 10:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehMcnXV4LbEj for ; Fri, 24 Feb 2012 10:34:34 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id D9FD721F8713 for ; Fri, 24 Feb 2012 10:34:33 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta01.westchester.pa.mail.comcast.net with comcast id duVX1i0010xGWP851uaahU; Fri, 24 Feb 2012 18:34:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id duaZ1i01B07duvL3YuaaEJ; Fri, 24 Feb 2012 18:34:34 +0000 Message-ID: <4F47D838.6040404@alum.mit.edu> Date: Fri, 24 Feb 2012 13:34:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F467798.1060805@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> <62A9ED0E-C13E-410B-8610-F6F42E5E9693@acmepacket.com> In-Reply-To: <62A9ED0E-C13E-410B-8610-F6F42E5E9693@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:34:35 -0000 On 2/24/12 1:11 PM, Hadriel Kaplan wrote: > > I know (or hope) you're joking, because this is NOT just because of Acme > SBCs, or even SBCs in general. > A vast majority of IP-PBXs, Call-Managers, App-Servers, etc., I've seen > change the Call-ID. As well as all the other SBCs. > > -hadriel > p.s. for the past 4 or 5 years or more Acme's SBCs have by *default* NOT > changed the Call-ID - it's just that most operators immediately change > this setting to make it change the Call-ID anyway. And we can't remove > the ability to change it, or else we'll be removed and replaced by > another SBC that will. And I don't blame operators for having the SBC > change the Call-ID; it's a security issue, I know they think so. And I won't argue with their decision to do so. But I expect its more paranoia than justified. > and often the only way to > make SIP work right. I would like to hear more about this part. Thanks, Paul > On Feb 24, 2012, at 3:50 AM, Christer Holmberg wrote: > >> STROBA >> SomeThing we aRe fOrced to do Because of hAdriel's sbcs. >> >> ------------------------------------------------------------------------ >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org]*On Behalf >> Of*Schmidt, Christian 1. (NSN - DE/Munich) >> *Sent:*24. helmikuuta 2012 10:33 >> *To:*ext Mary Barnes; Michael Hammer >> *Cc:*DISPATCH >> *Subject:*Re: [dispatch] Acronym for the SIP Session ID WG >> >> What about SIDE? >> Session ID Extension. >> Somehow a topic on a border line. >> Servus >> Christian >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org]*On Behalf >> Of*ext Mary Barnes >> *Sent:*Thursday, February 23, 2012 7:20 PM >> *To:*Michael Hammer >> *Cc:*DISPATCH >> *Subject:*Re: [dispatch] Acronym for the SIP Session ID WG >> Not a good idea for several reasons: >> 1)http://www.internetslang.com/SID-meaning-definition.asp >> 2) It stands for something that is one of the most devastating things >> a parent can experience (think about it). >> 3) It really doesn't lean towards any intuitive idea of what it's about. >> I can't come up with anything creative at this time other than the >> very basic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a >> dozen or more. >> Mary. >> On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer > > wrote: >> SID ? >> >> On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo >> > > wrote: >> Folks, >> >> as you know, we are in the process of chartering the SIP Session ID WG. >> As usual, we need an acronym for this new group. Any suggestions? >> >> Note that I will be making a decision about this real soon. I will take >> into consideration all the input I receive before that. >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From keith.drage@alcatel-lucent.com Fri Feb 24 10:38:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DB221F86DA for ; Fri, 24 Feb 2012 10:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.344 X-Spam-Level: X-Spam-Status: No, score=-109.344 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjBZxihu8EkJ for ; Fri, 24 Feb 2012 10:38:03 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id ED56221F86C6 for ; Fri, 24 Feb 2012 10:38:02 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1OIbxme012399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 24 Feb 2012 19:37:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 24 Feb 2012 19:37:59 +0100 From: "DRAGE, Keith (Keith)" To: Gonzalo Camarillo , DISPATCH Date: Fri, 24 Feb 2012 19:37:58 +0100 Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AczyUNYmp3rKDCDnR1SmAR8K7brzCQA0nCLg Message-ID: References: <4F467798.1060805@ericsson.com> In-Reply-To: <4F467798.1060805@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:38:03 -0000 I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG >=20 > Folks, >=20 > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? >=20 > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. >=20 > Cheers, >=20 > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Fri Feb 24 10:57:02 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6221F87EA for ; Fri, 24 Feb 2012 10:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.627 X-Spam-Level: X-Spam-Status: No, score=-103.627 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIJtCuPPQsx9 for ; Fri, 24 Feb 2012 10:57:02 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88221F87CF for ; Fri, 24 Feb 2012 10:57:02 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2062030vcb.31 for ; Fri, 24 Feb 2012 10:57:01 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.91.193 as permitted sender) client-ip=10.52.91.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.91.193 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.52.91.193]) by 10.52.91.193 with SMTP id cg1mr2011088vdb.21.1330109821688 (num_hops = 1); Fri, 24 Feb 2012 10:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dbhn6y/GrMJjrRDzyoTpMNuzmXb1cZdtAxB3YnonhBg=; b=aMUX3PybIEovbLO8dPPC+sN/Q1LsZktS8dvI785rnRCRmBhvsUkhOpNfYb0i9Skcbf d6jzrmQ0hRAk9Q3BhDAONmhlkaIhD/aRKo7LiBvsFmMInyaM1SeSRy+F08ca2ODka2Ky rqm5T0cu1hel4zMzf5znLQW4IeMti2I8EMaNI= MIME-Version: 1.0 Received: by 10.52.91.193 with SMTP id cg1mr1589171vdb.21.1330109821597; Fri, 24 Feb 2012 10:57:01 -0800 (PST) Received: by 10.52.114.200 with HTTP; Fri, 24 Feb 2012 10:56:58 -0800 (PST) In-Reply-To: References: <4F467798.1060805@ericsson.com> Date: Fri, 24 Feb 2012 12:56:58 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=bcaec5015d236db7ca04b9ba5367 Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:57:02 -0000 --bcaec5015d236db7ca04b9ba5367 Content-Type: text/plain; charset=ISO-8859-1 Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). Personally, I would like have SIP somewhere in the WG name. I'm just waiting for Hadriel to come up with a list from which we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I see no reason why we don't call it by the name it currently appears as > in the agenda, i.e. > > sessionid > > At least it reminds me what it is about, which I am not getting from any > of the other suggestions so far posted. > > Keith > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Gonzalo Camarillo > > Sent: 23 February 2012 17:30 > > To: DISPATCH > > Subject: [dispatch] Acronym for the SIP Session ID WG > > > > Folks, > > > > as you know, we are in the process of chartering the SIP Session ID WG. > > As usual, we need an acronym for this new group. Any suggestions? > > > > Note that I will be making a decision about this real soon. I will take > > into consideration all the input I receive before that. > > > > Cheers, > > > > Gonzalo > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --bcaec5015d236db7ca04b9ba5367 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). = =A0Personally, I would =A0like have SIP somewhere in the WG name. =A0I'= m just waiting for Hadriel to come up with a list from which we can choose = one.

Mary.=A0

On Fri, Feb 24, 2012 at= 12:37 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> = wrote:
I see no reason why we don't call it by = the name it currently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted.

Keith

> -----Original Message-----
> From: dispatch-bounces@ie= tf.org [mailto:dispatch-bo= unces@ietf.org] On
> Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will tak= e
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--bcaec5015d236db7ca04b9ba5367-- From brett@broadsoft.com Fri Feb 24 11:17:49 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B6021F882E for ; Fri, 24 Feb 2012 11:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz4vRX-EXzTw for ; Fri, 24 Feb 2012 11:17:48 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 7F28521F8815 for ; Fri, 24 Feb 2012 11:17:48 -0800 (PST) Received: from CASUMHUB02.citservers.local (172.16.98.161) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 Feb 2012 11:19:01 -0800 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 24 Feb 2012 11:17:56 -0800 From: Brett Tate To: 'DISPATCH' Date: Fri, 24 Feb 2012 11:16:42 -0800 Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AQLP6P1g4jdTOQV7xp8gbuxUjDYm0gG+HGiIAM1d4dyUMb5PQIAAYUlQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1CC822D3@EXMBXCLUS01.citservers.local> References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> <201202232101.q1NL1WNo013085@mtv-core-4.cisco.com> <003601ccf2f6$5d3a7310$17af5930$@packetizer.com> In-Reply-To: <003601ccf2f6$5d3a7310$17af5930$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:17:49 -0000 > insipid (adj): Lacking qualities that excite, stimulate, or interest; > dull. >=20 > It does not sound so inspiring ;-) +1 for "insipid"; however the antonym is "sipid" in case some like it bette= r. From HKaplan@acmepacket.com Fri Feb 24 11:20:30 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E6921F86DB for ; Fri, 24 Feb 2012 11:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg6W7ONccsdZ for ; Fri, 24 Feb 2012 11:20:29 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFFF21F86B7 for ; Fri, 24 Feb 2012 11:20:29 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Feb 2012 14:20:27 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Fri, 24 Feb 2012 14:20:27 -0500 From: Hadriel Kaplan To: Mary Barnes Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AQHM8yld4jdTOQV7xp8gbuxUjDYm0g== Date: Fri, 24 Feb 2012 19:20:26 +0000 Message-ID: <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> References: <4F467798.1060805@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: multipart/alternative; boundary="_000_59E8BD136AAC4EF2BDE3F7785CCF71EBacmepacketcom_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:20:30 -0000 --_000_59E8BD136AAC4EF2BDE3F7785CCF71EBacmepacketcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oh I like INSIPID - it really is a boring topic, after all, and besides the= acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin= ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phr= ases. :) But if someone really wants one that will be easy to remember the purpose o= f, we could make it: Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID :) -hadriel On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). = Personally, I would like have SIP somewhere in the WG name. I'm just wai= ting for Hadriel to come up with a list from which we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) > wrote: I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG > > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_59E8BD136AAC4EF2BDE3F7785CCF71EBacmepacketcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <81F49DCBA8B2A3408B77F6E3C0444E5F@acmepacket.com> Content-Transfer-Encoding: quoted-printable

Oh I like INSIPID - it really is a boring topic, after all, and beside= s the acronym is not only the phrase "In SIP ID" but also an anag= ram for "I Spin ID", "I Snip ID", "I Pin IDs"= , "IP ID Sin" and probably other relevant phrases. :)

But if someone really wants one that will be easy to remember the purp= ose of, we could make it:
Correlation Attribute for Logically Linking Independent Dialogs =3D CA= LLID
:)

-hadriel


On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:

Because WGs are supposed to be limited to 8 chara= cters (MEDIACTRL goofed).  Personally, I would  like have SIP som= ewhere in the WG name.  I'm just waiting for Hadriel to come up with a= list from which we can choose one.

Mary. 

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (= Keith) <keith.drage@alcatel-l= ucent.com> wrote:
I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted.

Keith

> -----Original Message-----
> From: dispatch-bounces@ie= tf.org [mailto:dispatch-bo= unces@ietf.org] On
> Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will tak= e
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_59E8BD136AAC4EF2BDE3F7785CCF71EBacmepacketcom_-- From kpfleming@digium.com Fri Feb 24 14:05:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B1821F8772 for ; Fri, 24 Feb 2012 14:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oxmxvjMzRGc for ; Fri, 24 Feb 2012 14:05:56 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32921F8768 for ; Fri, 24 Feb 2012 14:05:56 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1S13H0-00040H-T7 for dispatch@ietf.org; Fri, 24 Feb 2012 16:05:54 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E019BD8006 for ; Fri, 24 Feb 2012 16:05:54 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXTGhJIsvrNt for ; Fri, 24 Feb 2012 16:05:54 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 83525D8002 for ; Fri, 24 Feb 2012 16:05:54 -0600 (CST) Message-ID: <4F4809C2.5060903@digium.com> Date: Fri, 24 Feb 2012 16:05:54 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F467798.1060805@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se> <62A9ED0E-C13E-410B-8610-F6F42E5E9693@acmepacket.com> In-Reply-To: <62A9ED0E-C13E-410B-8610-F6F42E5E9693@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 22:05:57 -0000 On 02/24/2012 12:11 PM, Hadriel Kaplan wrote: > > I know (or hope) you're joking, because this is NOT just because of Acme > SBCs, or even SBCs in general. > A vast majority of IP-PBXs, Call-Managers, App-Servers, etc., I've seen > change the Call-ID. As well as all the other SBCs. > > -hadriel > p.s. for the past 4 or 5 years or more Acme's SBCs have by *default* NOT > changed the Call-ID - it's just that most operators immediately change > this setting to make it change the Call-ID anyway. And we can't remove > the ability to change it, or else we'll be removed and replaced by > another SBC that will. And I don't blame operators for having the SBC > change the Call-ID; it's a security issue, and often the only way to > make SIP work right. Having just spent the better part of a day hacking on the callflow tool (from callflow.sourceforge.net) in order to better present some data for analyzing a problem... I was left with the more fundamental issue of identifying the four Call-IDs (from a 100MB packet capture) involved in a 3-way conference call (three phones, Asterisk in the middle). Having a well-supported way to link those four SIP sessions together would have been very helpful. On the topic at hand: I think INSIPID would be fine. I'll be there regardless. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From richard@shockey.us Sat Feb 25 07:43:37 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE8821F8643 for ; Sat, 25 Feb 2012 07:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnManPHHlu6I for ; Sat, 25 Feb 2012 07:43:36 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id D9D7221F84EC for ; Sat, 25 Feb 2012 07:43:35 -0800 (PST) Received: (qmail 7487 invoked by uid 0); 25 Feb 2012 15:43:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 25 Feb 2012 15:43:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=N7Mb8HbImw/bySpSDetSNcipe1bdAhNyZeXjlOADwBw=; b=ZI8iEIK8R5/Rrkn0HFW+Ewp1DP1N6NsbSlCnWmx2GPXW6+tEfQdROI0IDWPoU92plz9VTUneQO4wec1SiSoyqMYhBikIriMJgLB09DQGOnd7CkZF2RbeVK4b3INNVf0R; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S1JmX-00044d-Sz; Sat, 25 Feb 2012 08:43:34 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Cullen Jennings'" References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com>, <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> In-Reply-To: <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> Date: Sat, 25 Feb 2012 10:43:29 -0500 Message-ID: <01d401ccf3d4$3c3b3030$b4b19090$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AQHM8cBhzYImTwtvFE+EVE08WCRFt5ZJoij7gAQiwBA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 15:43:37 -0000 +1=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Hadriel Kaplan Sent: Wednesday, February 22, 2012 7:34 PM To: Cullen Jennings Cc: dispatch@ietf.org list Subject: Re: [dispatch] SPID Sequence and Loop Detection Because it costs money. A small annual fee, to keep contact freshness = and discourage junk. Sent from my iPhone On Feb 22, 2012, at 7:16 PM, "Cullen Jennings" wrote: >=20 > I don't get how this is better than an ITAD formatted to be 8 digits = long with leading zeros.=20 >=20 >=20 >=20 > On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: >=20 >> I've submitted a new version of the SPID I-D Rich referred to below. = Per dispatch at the Quebec meeting it's for discussion on the RAI list. >> It differs from the previous version in asking the RIRs rather than = IANA directly to handle registrations. (This is to minimize junk = registrations and provide a whois service) >>=20 >> Penn Pfautz >> AT&T Access Management >> +1-732-420-4962 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey >> Sent: Tuesday, February 07, 2012 7:32 PM >> To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel = Khan' >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>=20 >> Ok .. but the basics are essential. >>=20 >> I want to commend to all of you the concept of a Universal SPID = embodied in >> this draft. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identif= ier >> -urn-01.txt >>=20 >> It needs work and input from everyone here, but the core issue here = is >> identification of issues along the session path especially as it = transits >> across national boundaries or transit intermediaries. >>=20 >> What is the malfunction that we can't agree on a tracing mechanism. Session >> ID for goodness sake. DO IT. Charter the damn thing. >>=20 >> It may seem trivial. Its not. Especially if you are a regulator = looking at >> how to create competitive transit markets. Do you all want another Shockey >> lecture on what the national regulators are up to ??? >>=20 >> Sohel to his eternal credit is starting to identify the larger = problem of >> the End of POTS. >>=20 >> I've avoided proposing a RAI Directorate on End of Life (EOL) issues = with >> TDM but it's coming. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf >> Of Daryl Malas >> Sent: Tuesday, February 07, 2012 2:05 PM >> To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>=20 >> Notice I specifically said, "Service Providers acting as an IXC never want >> to indicate their service provider relationships to their customers." >> This does not preclude a contractual agreement between two SSPs. >>=20 >>=20 >> On 2/7/12 11:35 AM, "Leontsinis, Nikos" = >> wrote: >>=20 >>> I am not 100% sure about this. On some environments say IPX this can = be >>> desirable it is written in the contract I will send you traffic to >>> USA FIXED and you are obliged to route it to carrier B. This is the = area >>> where the SPID could make sense. >>>=20 >>>=20 >>> /nikos >>> ________________________________________ >>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On = Behalf Of >>> Daryl Malas [D.Malas@cablelabs.com] >>> Sent: Tuesday, February 07, 2012 7:06 PM >>> To: Cullen Jennings; Sohel Khan >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>=20 >>> Cullen's point here is very valid. Service Providers acting as an = IXC >>> never want to indicate their service provider relationships to their >>> customers. They create interconnects to many service providers to >>> maintain the lowest termination costs in order to increase their = margins >>> for LD termination. Sohel describes a real problem. >>>=20 >>> In telecommunication networks, it seems as though we have many = different >>> carrier identification mechanisms already defined. I am leery of creating >>> yet another, even if it is encrypted. I would be more inclined to = look at >>> existing loop detection mechanisms and see if they will work either: >>> - as currently defined, >>> - need to be extended or >>> - need to be enforced (aka not blocked or reset by a B2BUA). >>>=20 >>> --Daryl >>>=20 >>> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>>=20 >>>>=20 >>>> When doing least cost routing, my experience has been that if A delivers >>>> the call to B that B will then send to C, B wants to hide this fact from >>>> C and certainly wants to hide from A that they the call went to C. >>>> Otherwise B gets cut out and A and C just set up a peering deal directly. >>>>=20 >>>> So I worry a scheme like this would not work as B's SBC would be >>>> configured to remove this. >>>>=20 >>>>=20 >>>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>>=20 >>>>> SIP calls routing in an infinite loop in a subset of networks is a >>>>> known phenomenon. >>>>> Various SIP methods exist today may be used to detect and mitigate >>>>> loops. Operational engineers would like to see a method that = indicates >>>>> the sequence of providers=B9 IDs in the call path. Based on the = input from >>>>> the operational engineers, we are proposing a new SIP header >>>> Sequence> to detect SIP routing loop. This method is preferred by = the >>>>> operational engineers of large providers=B9 networks. >>>>>=20 >>>>> Assume that a SIP call originating from provider Alpha (SPID: 77777777) >>>>> and traversing through provider Bravo (SPID: 55555555), Charlie = (SPID: >>>>> 33333333), and looping back to Alpha. >>>>>=20 >>>>> With the new method, the SIP INVITE contains the new header SPID >>>>> sequence {33333333, 55555555, 77777777}. >>>>>=20 >>>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>>> arrives to Alpha=B9s network, Alpha will detect 77777777 in the = SPID >>>>> sequence and conclude that a loop has occurred. >>>>>=20 >>>>> In the above use case, an example =B3SPID-sequence=B2 header is as follows: >>>>> SPID-Sequence:;index=3D1; >>>>> SPID-Sequence:;index=3D1.1; >>>>> SPID-Sequence:;index=3D1.2; >>>>>=20 >>>>> A provider wishing not to divulge its SPID, may insert a private = or a >>>>> blank value. >>>>> SPID-Sequence:;index=3D1; >>>>> SPID-Sequence:;index=3D1.1; >>>>> SPID-Sequence:;index=3D1.2 >>>>> SPID-Sequence:;index=3D1.3; >>>>> A provider should not delete any value from the SPID sequence = unless >>>>> the SPID is its own. >>>>> We had some discussion in the DISPATCH meetings on ideas such as = this. >>>>> We would need a broader community support and help to initiate a = work in >>>>> IETF RTC WG on SPID sequence. >>>>> Please let us know your opinion. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards, Sohel Khan >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>> DISCLAIMER: >>> This electronic mail message is intended exclusively for the = individual >>> or entity to which it is addressed. This message, together with any >>> attachment, may contain confidential and legally privileged = information. >>> Any views, opinions or conclusions expressed in this message are = those of >>> the individual sender and do not necessarily reflect the views of >>> OTEGLOBE. Any unauthorized review, use, printing, copying, = retention, >>> disclosure or distribution is strictly prohibited. If you have = received >>> this message in error, please immediately advise the sender by reply >>> email message to the sender and delete all copies of this message. >>> OTEGLOBE cannot accept any responsibility for the accuracy or >>> completeness of this message as it has been transmitted over a = public >>> network. If you suspect that the message may have been intercepted = or >>> amended in any way please contact the sender. Thank you. >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Sat Feb 25 07:45:15 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7785921F85A5 for ; Sat, 25 Feb 2012 07:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.699 X-Spam-Level: X-Spam-Status: No, score=-98.699 tagged_above=-999 required=5 tests=[AWL=-1.796, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_PENIS1=3.592, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5egVIfwUWBUL for ; Sat, 25 Feb 2012 07:45:14 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 7461921F85A3 for ; Sat, 25 Feb 2012 07:45:14 -0800 (PST) Received: (qmail 5806 invoked by uid 0); 25 Feb 2012 15:45:12 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 25 Feb 2012 15:45:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=pnPhbFVJQ9U761Wnje+1k1sYOoYuqFum92cO3eKCxqo=; b=fY1mtaeqAYBjUVjM8JPmq5dsBU9uYLveewZrmZb3vZHgp4ypJNqiT/DQ1cydZZY391Dhhbn0qcu3iRdO58qgwwVkHzz1y90WnNJSRN0LDRnnwAs95jBFeS61VN69ihMP; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S1Jo6-00051H-MA; Sat, 25 Feb 2012 08:45:11 -0700 From: "Richard Shockey" To: "'PFAUTZ, PENN L'" , "'Cullen Jennings'" , "'Hadriel Kaplan'" References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com>, <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4EC361B8-792C-4B7C-9DEE-CE552FD15EB4@acmepacket.com> <38726EDA2109264987B45E29E758C4D6087083@MISOUT7MSGUSR9N.ITServices.sbc.com> In-Reply-To: <38726EDA2109264987B45E29E758C4D6087083@MISOUT7MSGUSR9N.ITServices.sbc.com> Date: Sat, 25 Feb 2012 10:45:10 -0500 Message-ID: <01d501ccf3d4$75e6ad50$61b407f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AQHM8cSNY16a6i9Hq0KzgYYPbT2wSpZJpl7QgAQev/A= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 15:45:15 -0000 Exactly .. no one is suggesting a restrictive policy here only a modest level of control. And we want a WHOIS. That is essential.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of PFAUTZ, PENN L Sent: Wednesday, February 22, 2012 7:55 PM To: Cullen Jennings; Hadriel Kaplan Cc: dispatch@ietf.org list Subject: Re: [dispatch] SPID Sequence and Loop Detection The intent is not to have a policy as restrictive as for AS numbers. = What requirements should obtain beyond the fee is up for discussion which I encourage. I don't think a modest fee will discourage actual businesses = as the focus is on service providers as opposed to end users. (I expect = some enterprises will want to join in - I don't have a problem with that). Penn Pfautz AT&T Access Management +1-732-420-4962 -----Original Message----- From: Cullen Jennings [mailto:fluffy@iii.ca] Sent: Wednesday, February 22, 2012 7:46 PM To: Hadriel Kaplan Cc: PFAUTZ, PENN L; dispatch@ietf.org list Subject: Re: [dispatch] SPID Sequence and Loop Detection Well it's a lot more than costs money - when I read ARIN policy to get = an AS, it not just $500 per year. I don't think I could get an AS number. So lets delve into this argument a bit deeper. What's the advantage in = this case of no junk registrations? Who care is someone that you will never = see a message from has a number? It seems the primary difference is that it would keep certain types of business locked out if they were unable to use protocols that needed one = of these numbers and they could not get one. On Feb 22, 2012, at 5:33 PM, Hadriel Kaplan wrote: > Because it costs money. A small annual fee, to keep contact = freshness and discourage junk. > > Sent from my iPhone > > On Feb 22, 2012, at 7:16 PM, "Cullen Jennings" wrote: > >> >> I don't get how this is better than an ITAD formatted to be 8 digits = long with leading zeros. >> >> >> >> On Feb 17, 2012, at 9:44 AM, PFAUTZ, PENN L wrote: >> >>> I've submitted a new version of the SPID I-D Rich referred to below. = Per dispatch at the Quebec meeting it's for discussion on the RAI list. >>> It differs from the previous version in asking the RIRs rather than = IANA directly to handle registrations. (This is to minimize junk = registrations and provide a whois service) >>> >>> Penn Pfautz >>> AT&T Access Management >>> +1-732-420-4962 >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf Of Richard Shockey >>> Sent: Tuesday, February 07, 2012 7:32 PM >>> To: 'Daryl Malas'; 'Leontsinis, Nikos'; 'Cullen Jennings'; 'Sohel = Khan' >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>> >>> Ok .. but the basics are essential. >>> >>> I want to commend to all of you the concept of a Universal SPID = embodied in >>> this draft. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-pfautz-service-provider-identif= ier >>> -urn-01.txt >>> >>> It needs work and input from everyone here, but the core issue here = is >>> identification of issues along the session path especially as it transits >>> across national boundaries or transit intermediaries. >>> >>> What is the malfunction that we can't agree on a tracing mechanism. Session >>> ID for goodness sake. DO IT. Charter the damn thing. >>> >>> It may seem trivial. Its not. Especially if you are a regulator = looking at >>> how to create competitive transit markets. Do you all want another Shockey >>> lecture on what the national regulators are up to ??? >>> >>> Sohel to his eternal credit is starting to identify the larger = problem of >>> the End of POTS. >>> >>> I've avoided proposing a RAI Directorate on End of Life (EOL) issues with >>> TDM but it's coming. >>> >>> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On Behalf >>> Of Daryl Malas >>> Sent: Tuesday, February 07, 2012 2:05 PM >>> To: Leontsinis, Nikos; Cullen Jennings; Sohel Khan >>> Cc: dispatch@ietf.org >>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>> >>> Notice I specifically said, "Service Providers acting as an IXC = never want >>> to indicate their service provider relationships to their = customers." >>> This does not preclude a contractual agreement between two SSPs. >>> >>> >>> On 2/7/12 11:35 AM, "Leontsinis, Nikos" = >>> wrote: >>> >>>> I am not 100% sure about this. On some environments say IPX this = can be >>>> desirable it is written in the contract I will send you traffic to >>>> USA FIXED and you are obliged to route it to carrier B. This is the area >>>> where the SPID could make sense. >>>> >>>> >>>> /nikos >>>> ________________________________________ >>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On = Behalf Of >>>> Daryl Malas [D.Malas@cablelabs.com] >>>> Sent: Tuesday, February 07, 2012 7:06 PM >>>> To: Cullen Jennings; Sohel Khan >>>> Cc: dispatch@ietf.org >>>> Subject: Re: [dispatch] SPID Sequence and Loop Detection >>>> >>>> Cullen's point here is very valid. Service Providers acting as an = IXC >>>> never want to indicate their service provider relationships to = their >>>> customers. They create interconnects to many service providers to >>>> maintain the lowest termination costs in order to increase their margins >>>> for LD termination. Sohel describes a real problem. >>>> >>>> In telecommunication networks, it seems as though we have many different >>>> carrier identification mechanisms already defined. I am leery of creating >>>> yet another, even if it is encrypted. I would be more inclined to = look at >>>> existing loop detection mechanisms and see if they will work = either: >>>> - as currently defined, >>>> - need to be extended or >>>> - need to be enforced (aka not blocked or reset by a B2BUA). >>>> >>>> --Daryl >>>> >>>> On 1/27/12 11:56 AM, "Cullen Jennings" wrote: >>>> >>>>> >>>>> When doing least cost routing, my experience has been that if A delivers >>>>> the call to B that B will then send to C, B wants to hide this = fact from >>>>> C and certainly wants to hide from A that they the call went to C. >>>>> Otherwise B gets cut out and A and C just set up a peering deal directly. >>>>> >>>>> So I worry a scheme like this would not work as B's SBC would be >>>>> configured to remove this. >>>>> >>>>> >>>>> On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: >>>>> >>>>>> SIP calls routing in an infinite loop in a subset of networks is = a >>>>>> known phenomenon. >>>>>> Various SIP methods exist today may be used to detect and = mitigate >>>>>> loops. Operational engineers would like to see a method that indicates >>>>>> the sequence of providers=B9 IDs in the call path. Based on the = input from >>>>>> the operational engineers, we are proposing a new SIP header = >>>>> Sequence> to detect SIP routing loop. This method is preferred by = the >>>>>> operational engineers of large providers=B9 networks. >>>>>> >>>>>> Assume that a SIP call originating from provider Alpha (SPID: 77777777) >>>>>> and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: >>>>>> 33333333), and looping back to Alpha. >>>>>> >>>>>> With the new method, the SIP INVITE contains the new header SPID >>>>>> sequence {33333333, 55555555, 77777777}. >>>>>> >>>>>> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >>>>>> arrives to Alpha=B9s network, Alpha will detect 77777777 in the = SPID >>>>>> sequence and conclude that a loop has occurred. >>>>>> >>>>>> In the above use case, an example =B3SPID-sequence=B2 header is = as follows: >>>>>> SPID-Sequence:;index=3D1; >>>>>> SPID-Sequence:;index=3D1.1; >>>>>> SPID-Sequence:;index=3D1.2; >>>>>> >>>>>> A provider wishing not to divulge its SPID, may insert a private = or a >>>>>> blank value. >>>>>> SPID-Sequence:;index=3D1; >>>>>> SPID-Sequence:;index=3D1.1; >>>>>> SPID-Sequence:;index=3D1.2 >>>>>> SPID-Sequence:;index=3D1.3; >>>>>> A provider should not delete any value from the SPID sequence = unless >>>>>> the SPID is its own. >>>>>> We had some discussion in the DISPATCH meetings on ideas such as this. >>>>>> We would need a broader community support and help to initiate a = work in >>>>>> IETF RTC WG on SPID sequence. >>>>>> Please let us know your opinion. >>>>>> >>>>>> >>>>>> >>>>>> Regards, Sohel Khan >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>>> >>>> DISCLAIMER: >>>> This electronic mail message is intended exclusively for the = individual >>>> or entity to which it is addressed. This message, together with any >>>> attachment, may contain confidential and legally privileged information. >>>> Any views, opinions or conclusions expressed in this message are = those of >>>> the individual sender and do not necessarily reflect the views of >>>> OTEGLOBE. Any unauthorized review, use, printing, copying, = retention, >>>> disclosure or distribution is strictly prohibited. If you have = received >>>> this message in error, please immediately advise the sender by = reply >>>> email message to the sender and delete all copies of this message. >>>> OTEGLOBE cannot accept any responsibility for the accuracy or >>>> completeness of this message as it has been transmitted over a = public >>>> network. If you suspect that the message may have been intercepted = or >>>> amended in any way please contact the sender. Thank you. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Sat Feb 25 07:50:37 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B4821F8613 for ; Sat, 25 Feb 2012 07:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.853 X-Spam-Level: X-Spam-Status: No, score=-98.853 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flYd50TfnWju for ; Sat, 25 Feb 2012 07:50:36 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id BDD5021F8610 for ; Sat, 25 Feb 2012 07:50:36 -0800 (PST) Received: (qmail 20801 invoked by uid 0); 25 Feb 2012 15:50:36 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 25 Feb 2012 15:50:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=NCMGwTD0FQreRZzaDoKbf+T2QhM8wjQZwnhRCdtQNd8=; b=Vm3MUL8F8BX49E3L6a+fFXLCyEJNH8QLn7ONXb6BTRD1MPqj8iaKm7oN+VN6Q7fLDR0VakXQAApbveoE2aLCkBuNTkDm9nZEc2/+RTvY2RrBJY5LHfkS6EPdKDX0irMg; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S1JtL-000860-CK; Sat, 25 Feb 2012 08:50:35 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> In-Reply-To: <4F459082.2040402@alum.mit.edu> Date: Sat, 25 Feb 2012 10:50:35 -0500 Message-ID: <01d601ccf3d5$37710880$a6531980$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Aczxxw1AZ1fsitT9TUaoiYOquuPeawCDYp0w Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 15:50:37 -0000 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, February 22, 2012 8:04 PM To: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection On 2/22/12 7:16 PM, Cullen Jennings wrote: > > I don't get how this is better than an ITAD formatted to be 8 digits long with leading zeros. And I still don't see how either one is even remotely useful for loop detection. We have heard repeatedly that SPs feel they must keep the topology of their networks and the identity of their peers secret. But that will lead to removing/anonymizing the SPIDs in the request, just as Vias and Routes are anonymized. And then this won't work for loop detection. And we already have loop detection mechanisms, so why do we need another? Also, what is to prevent someone from forging SPIDs in a message? [RS> ] [RS> ] One of the principal use cases for a global SPID this is International Interconnection of E.164 traffic or even domestic traffic in some national jurisdictions. As for forging SPID's we have the same problem with issues of Calling Number in one way SIP traffic over the PSTN in the US. People do bad things. The prevention mechanism is national law or regulation that defines what is in the headers and what cannot be modified as it might transverse a all IP Interconnected network using E.164 identifiers. Its called fines and jail. Thanks, Paul From richard@shockey.us Sat Feb 25 07:55:21 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF78E21F859B for ; Sat, 25 Feb 2012 07:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.441 X-Spam-Level: X-Spam-Status: No, score=-98.441 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBclGqdPA6O5 for ; Sat, 25 Feb 2012 07:55:21 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 115E621F850C for ; Sat, 25 Feb 2012 07:55:21 -0800 (PST) Received: (qmail 8405 invoked by uid 0); 25 Feb 2012 15:55:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com with SMTP; 25 Feb 2012 15:55:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=FD324xWcK+5y8utwpVLCdeW3h1ETnKEVNB/Dh+Gixsg=; b=jnRDrBayJXd5YhyhZhljCmf2jxBVge7yk+aFSePAsY4kP0ECGRJs9m/nTGxszrOL7aaCzFTqpOpNAX/R4e2fmxQTF+kJTZzdm8sVrw3HcbHqpYjVOUXzKIDy4aUSCnJ+; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S1Jxw-0003bQ-BS; Sat, 25 Feb 2012 08:55:20 -0700 From: "Richard Shockey" To: "'Dean Willis'" , "'Gonzalo Camarillo'" References: <4F467798.1060805@ericsson.com> <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> In-Reply-To: <9C7E9B16-5D5E-4F0E-930D-83E2F1AB2B69@softarmor.com> Date: Sat, 25 Feb 2012 10:55:20 -0500 Message-ID: <01da01ccf3d5$e147e270$a3d7a750$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AczyX3N432F4FAEuRp+cKjb2GFNI9ABdiUyA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 15:55:21 -0000 LOL good one Dean .. oh what the heck VODKA since we'll all need a DRINK(s) considering how long this topic has dragged on. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dean Willis Sent: Thursday, February 23, 2012 2:15 PM To: Gonzalo Camarillo Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG On Feb 23, 2012, at 11:30 AM, Gonzalo Camarillo wrote: > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? INSIPID -- Dean _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Sat Feb 25 07:57:52 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE321F8610 for ; Sat, 25 Feb 2012 07:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.558 X-Spam-Level: X-Spam-Status: No, score=-99.558 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXmYMEXDwIvd for ; Sat, 25 Feb 2012 07:57:50 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 755DA21F850C for ; Sat, 25 Feb 2012 07:57:50 -0800 (PST) Received: (qmail 2184 invoked by uid 0); 25 Feb 2012 15:57:49 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy2.bluehost.com with SMTP; 25 Feb 2012 15:57:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=iTItmtZJ3zlME7rzJJRlI8VVQ3YlKbWJ9Ob/+4O/jBQ=; b=XCFBj3t74nj5JCV0cDZ+qqNHK/662kDsnd7PsciIn96E+t93VCsSYka3lTDjkc9Lwv6Tn+eLXLL4A24wosXcXk71zEr593Jf9NEShLyquHbAtlx+7dUOO71NKqZOnNIV; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S1K0L-0005Kd-63; Sat, 25 Feb 2012 08:57:49 -0700 From: "Richard Shockey" To: "'Hadriel Kaplan'" , "'Mary Barnes'" References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> In-Reply-To: <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> Date: Sat, 25 Feb 2012 10:57:48 -0500 Message-ID: <01db01ccf3d6$39fe9bc0$adfbd340$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DC_01CCF3AC.512893C0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AQHM8yld4jdTOQV7xp8gbuxUjDYm0pZNxhMg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 15:57:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01DC_01CCF3AC.512893C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Outstanding . From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, February 24, 2012 2:20 PM To: Mary Barnes Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Oh I like INSIPID - it really is a boring topic, after all, and besides the acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phrases. :) But if someone really wants one that will be easy to remember the purpose of, we could make it: Correlation Attribute for Logically Linking Independent Dialogs = CALLID :) -hadriel On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). Personally, I would like have SIP somewhere in the WG name. I'm just waiting for Hadriel to come up with a list from which we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) wrote: I see no reason why we don't call it by the name it currently appears as in the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG > > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_01DC_01CCF3AC.512893C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Outstanding …

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Hadriel Kaplan
Sent: Friday, February 24, 2012 = 2:20 PM
To: Mary Barnes
Cc: = DISPATCH
Subject: Re: [dispatch] Acronym for the SIP Session = ID WG

 

 

Oh I like INSIPID - it really is a boring topic, after = all, and besides the acronym is not only the phrase "In SIP = ID" but also an anagram for "I Spin ID", "I Snip = ID", "I Pin IDs", "IP ID Sin" and probably = other relevant phrases. :)

 

But if someone really wants one that will be easy to = remember the purpose of, we could make it:

Correlation Attribute for Logically Linking = Independent Dialogs =3D CALLID

:)

 

-hadriel

 

 

On = Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:



Because = WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). =  Personally, I would  like have SIP somewhere in the WG name. =  I'm just waiting for Hadriel to come up with a list from which we = can choose one.

 

Mary. 

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) = <keith.drage@alcatel-lucent= .com> wrote:

I see no reason = why we don't call it by the name it currently appears as in the agenda, = i.e.

sessionid

At least it reminds me what it is about, = which I am not getting from any of the other suggestions so far = posted.

Keith


> -----Original Message-----
> From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.org] = On

> Behalf Of = Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: = DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID = WG
>
> Folks,
>
> as you know, we are in the = process of chartering the SIP Session ID WG.
> As usual, we need = an acronym for this new group. Any suggestions?
>
> Note = that I will be making a decision about this real soon. I will = take
> into consideration all the input I receive before = that.
>
> Cheers,
>
> Gonzalo
> = _______________________________________________
> dispatch mailing = list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_= ______________________________________________
dispatch mailing = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 

_______________________________________________
disp= atch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

 

------=_NextPart_000_01DC_01CCF3AC.512893C0-- From keith.drage@alcatel-lucent.com Sat Feb 25 16:34:49 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF54A21F849C for ; Sat, 25 Feb 2012 16:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.39 X-Spam-Level: X-Spam-Status: No, score=-109.39 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of+vjjAHLl6E for ; Sat, 25 Feb 2012 16:34:47 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06B21F84A0 for ; Sat, 25 Feb 2012 16:34:47 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1Q0Yhi5011172 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 26 Feb 2012 01:34:43 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Sun, 26 Feb 2012 01:34:42 +0100 From: "DRAGE, Keith (Keith)" To: Richard Shockey , "'Hadriel Kaplan'" , "'Mary Barnes'" Date: Sun, 26 Feb 2012 01:34:34 +0100 Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AQHM8yld4jdTOQV7xp8gbuxUjDYm0pZNxhMggACQX+A= Message-ID: References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> In-Reply-To: <01db01ccf3d6$39fe9bc0$adfbd340$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE224B5AD93FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 00:34:50 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE224B5AD93FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll work with CALLID Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Richard Shockey Sent: 25 February 2012 15:58 To: 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG Outstanding ... From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Hadriel Kaplan Sent: Friday, February 24, 2012 2:20 PM To: Mary Barnes Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Oh I like INSIPID - it really is a boring topic, after all, and besides the= acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin= ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phr= ases. :) But if someone really wants one that will be easy to remember the purpose o= f, we could make it: Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID :) -hadriel On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). = Personally, I would like have SIP somewhere in the WG name. I'm just wai= ting for Hadriel to come up with a list from which we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) > wrote: I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG > > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_EDC0A1AE77C57744B664A310A0B23AE224B5AD93FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll work with CALLID=

 

Keith

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: 25 February 2012 15:58=
To: 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acro= nym for the SIP Session ID WG

 

Outstanding &#= 8230;

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Friday, February 24, 2= 012 2:20 PM
To: Mary Barnes
Cc: DISPATCH
Subject: Re: [dispatch] Acro= nym for the SIP Session ID WG

 

 

Oh I like INSIPID - it really is a boring topic,= after all, and besides the acronym is not only the phrase "In SIP ID" b= ut also an anagram for "I Spin ID", "I Snip ID", "I P= in IDs", "IP ID Sin" and probably other relevant phrases. :)

 

But if someone really wants one that will be eas= y to remember the purpose of, we could make it:

Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID

:)

 

-hadriel

 

 

On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:<= o:p>

 

Because WGs are supposed to be limited to 8 char= acters (MEDIACTRL goofed).  Personally, I would  like have SIP somewhere= in the WG name.  I'm just waiting for Hadriel to come up with a list from which we can choose one.

 

Mary= . 

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (= Keith) <keith.drage@alcatel-l= ucent.com> wrote:

I see no reason why we don't call it by the name= it currently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted.

Keith


> -----Original Message-----
> From: dispatch-bounces@ie= tf.org [mailto:dispatch-bounces@ietf.= org] On

> Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will tak= e
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

_______________________________________________<= br> dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

--_000_EDC0A1AE77C57744B664A310A0B23AE224B5AD93FRMRSSXCHMBSC3d_-- From pkyzivat@alum.mit.edu Sat Feb 25 17:15:24 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D4C21F850C for ; Sat, 25 Feb 2012 17:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDeCAuUSEBK3 for ; Sat, 25 Feb 2012 17:15:23 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id E8D0321F8507 for ; Sat, 25 Feb 2012 17:15:21 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id eRCR1i0061swQuc5CRFMHR; Sun, 26 Feb 2012 01:15:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id eRFM1i00b07duvL3bRFMLD; Sun, 26 Feb 2012 01:15:21 +0000 Message-ID: <4F4987A7.5080804@alum.mit.edu> Date: Sat, 25 Feb 2012 20:15:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Richard Shockey References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> In-Reply-To: <01d601ccf3d5$37710880$a6531980$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 01:15:24 -0000 On 2/25/12 10:50 AM, Richard Shockey wrote: > Also, what is to prevent someone from forging SPIDs in a message? > [RS> ] > [RS> ] One of the principal use cases for a global SPID this is > International Interconnection of E.164 traffic or even domestic traffic in > some national jurisdictions. As for forging SPID's we have the same problem > with issues of Calling Number in one way SIP traffic over the PSTN in the > US. People do bad things. The prevention mechanism is national law or > regulation that defines what is in the headers and what cannot be modified > as it might transverse a all IP Interconnected network using E.164 > identifiers. Its called fines and jail. There's a lot of callerid forging going on, and AFAIK nobody is going to jail for it. In what countries are there laws about what sip headers can go into a sip message? Thanks, Paul From richard@shockey.us Sun Feb 26 12:36:55 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A3521F84F8 for ; Sun, 26 Feb 2012 12:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.538 X-Spam-Level: X-Spam-Status: No, score=-98.538 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65sjUrFCGeLR for ; Sun, 26 Feb 2012 12:36:55 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 02E9F21F84F2 for ; Sun, 26 Feb 2012 12:36:54 -0800 (PST) Received: (qmail 20479 invoked by uid 0); 26 Feb 2012 20:36:54 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy9.bluehost.com with SMTP; 26 Feb 2012 20:36:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=7+whmDmJyK2LQCmalKeRW8eWoRMmoUFJ4pnWdlBjuTw=; b=jD1KA0+KwShscuWwvQ6rC9zLm2dN//kPMZwtltUAcoNJXmBpSYiU78aWiC5bcSS7PA8T+ED0h6VY4jAF0LA9yPM6y82nuvEMmt+gunO6xh//GVQL53lcYjf4mf518SWf; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S1kpx-0003aQ-Or; Sun, 26 Feb 2012 13:36:54 -0700 From: "Richard Shockey" To: "'Paul Kyzivat'" , "'DISPATCH'" References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> In-Reply-To: <4F4987A7.5080804@alum.mit.edu> Date: Sun, 26 Feb 2012 15:36:53 -0500 Message-ID: <002a01ccf4c6$60bd1c50$223754f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz0JB0IFCEUDwqmQOG7sKnYfJnslgAn+pFw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 20:36:55 -0000 On 2/25/12 10:50 AM, Richard Shockey wrote: > Also, what is to prevent someone from forging SPIDs in a message? > [RS> ] > [RS> ] One of the principal use cases for a global SPID this is > International Interconnection of E.164 traffic or even domestic traffic in > some national jurisdictions. As for forging SPID's we have the same problem > with issues of Calling Number in one way SIP traffic over the PSTN in the > US. People do bad things. The prevention mechanism is national law or > regulation that defines what is in the headers and what cannot be modified > as it might transverse a all IP Interconnected network using E.164 > identifiers. Its called fines and jail. There's a lot of callerid forging going on, and AFAIK nobody is going to jail for it. [RS> ] Not yet , but given the level of screaming by the service providers on the fraudulent phantom traffic issue you can assume its coming. In what countries are there laws about what sip headers can go into a sip message? [RS> ] Right now the issue is related to traffic in both the US and Canada but I would guess most of the PTT's are experiencing the same issue. The FCC order on USF/ICC reform is very specific on the requirement for non modification of charge number or calling party number in the signaling path.. aka the SIP headers when applicable. A fair amount of this goes away with bill and keep but you can assume you'll see a bunch of new "requirements" be imposed as a transition to all SIP Interconnection for real time communications occurs over the next decade. Thanks, Paul From pravindran@sonusnet.com Sun Feb 26 23:17:20 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8E21E8015 for ; Sun, 26 Feb 2012 23:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GABvmS-ys-am for ; Sun, 26 Feb 2012 23:17:18 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 44A9D21F8501 for ; Sun, 26 Feb 2012 23:17:18 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q1R7HvjY005217; Mon, 27 Feb 2012 02:17:57 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 02:17:08 -0500 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 12:47:05 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 12:47:05 +0530 From: "Ravindran, Parthasarathi" To: "DRAGE, Keith (Keith)" , Richard Shockey , "'Hadriel Kaplan'" , "'Mary Barnes'" Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AQHM8lDeOShtUHq9ak+KXuBTjpig/pZMBgYAgAAFTwCAAAaPAIABWbcAgACQYgCAAl7XcA== Date: Mon, 27 Feb 2012 07:17:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E04DE00inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 07:17:05.0841 (UTC) FILETIME=[CF590210:01CCF51F] Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 07:17:20 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E04DE00inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like CALLID Partha From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of DRAGE, Keith (Keith) Sent: Sunday, February 26, 2012 6:05 AM To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG I'll work with CALLID Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: 25 February 2012 15:58 To: 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG Outstanding ... From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, February 24, 2012 2:20 PM To: Mary Barnes Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Oh I like INSIPID - it really is a boring topic, after all, and besides the= acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin= ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phr= ases. :) But if someone really wants one that will be easy to remember the purpose o= f, we could make it: Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID :) -hadriel On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). = Personally, I would like have SIP somewhere in the WG name. I'm just wai= ting for Hadriel to come up with a list from which we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) > wrote: I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG > > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_387F9047F55E8C42850AD6B3A7A03C6C0E04DE00inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like CALLID

 <= /p>

Partha<= /p>

 <= /p>

From: dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Sunday, February 26, 2012 6:05 AM
To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acronym for the SIP Session ID WG=

 

I’ll work= with CALLID

 

Keith

 

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Richard Shockey
Sent: 25 February 2012 15:58
To: 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acronym for the SIP Session ID WG

 

Outstanding …<= /o:p>

 <= /p>

From: dispatch-bounces@ietf.org = [mailto:dispatch-bounces@ietf.= org] On Behalf Of Hadriel Kaplan
Sent: Friday, February 24, 2012 2:20 PM
To: Mary Barnes
Cc: DISPATCH
Subject: Re: [dispatch] Acronym for the SIP Session ID WG=

 

 

Oh I like INSIPID - it really is a boring topic, aft= er all, and besides the acronym is not only the phrase "In SIP ID"= ; but also an anagram for "I Spin ID", "I Snip ID", &qu= ot;I Pin IDs", "IP ID Sin" and probably other relevant phras= es. :)

 

But if someone really wants one that will be easy to= remember the purpose of, we could make it:

Correlation Attribute for Logically Linking Independ= ent Dialogs =3D CALLID

:)

 

-hadriel

 

 

On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:=

 

Because WGs are supposed to be limited to 8 characte= rs (MEDIACTRL goofed).  Personally, I would  like have SIP somewh= ere in the WG name.  I'm just waiting for Hadriel to come up with a li= st from which we can choose one.

 

Mary. 

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keit= h) <keith.drage@alcate= l-lucent.com> wrote:

I see no reason why we don't call it by the name it = currently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted.

Keith


> -----Original Message-----
> From: dispatch-bounces@ie= tf.org [mailto:dispatch-bo= unces@ietf.org] On

> Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will tak= e
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E04DE00inbamail01sonus_-- From pkyzivat@alum.mit.edu Mon Feb 27 10:09:59 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E3A21F8702 for ; Mon, 27 Feb 2012 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28l75zmjIqEz for ; Mon, 27 Feb 2012 10:09:59 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 792B021F85AA for ; Mon, 27 Feb 2012 10:09:58 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id f5a11i00827AodY5169zTN; Mon, 27 Feb 2012 18:09:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id f69y1i00H07duvL3f69y41; Mon, 27 Feb 2012 18:09:59 +0000 Message-ID: <4F4BC6F5.4040101@alum.mit.edu> Date: Mon, 27 Feb 2012 13:09:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Richard Shockey References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> <002a01ccf4c6$60bd1c50$223754f0$@us> In-Reply-To: <002a01ccf4c6$60bd1c50$223754f0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 27 Feb 2012 10:16:08 -0800 Cc: SIPCORE Subject: [dispatch] Legal controls over sip signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:09:59 -0000 [I've changed the subject to reflect what we are discussing] Richard, This is interesting, and I think more discussion is appropriate on it. Its not clear where this discussion should take place - probably not dispatch. IMO sipcore is more suitable for the discussion. So I'm cross posting this but bcc'ing dispatch so that replies will go to sipcore. (Hopefully that will work. If it doesn't, please refrain from replying on dispatch.) I don't understand how a legal restriction would work. - would it be limited to regulated carriers? - how would this apply to the interconnect of "private" devices or environments to the "public" sip infrastructure? - would this be limited to identities that are E.164 numbers? Or would it include other sorts of identities? - would this apply to interconnects between private infrastructures? (E.g. ViPR) Thanks, Paul On 2/26/12 3:36 PM, Richard Shockey wrote: > > > On 2/25/12 10:50 AM, Richard Shockey wrote: > >> Also, what is to prevent someone from forging SPIDs in a message? >> [RS> ] >> [RS> ] One of the principal use cases for a global SPID this is >> International Interconnection of E.164 traffic or even domestic traffic in >> some national jurisdictions. As for forging SPID's we have the same > problem >> with issues of Calling Number in one way SIP traffic over the PSTN in the >> US. People do bad things. The prevention mechanism is national law or >> regulation that defines what is in the headers and what cannot be modified >> as it might transverse a all IP Interconnected network using E.164 >> identifiers. Its called fines and jail. > > There's a lot of callerid forging going on, and AFAIK nobody is going to > jail for it. > [RS> ] Not yet , but given the level of screaming by the service providers > on the fraudulent phantom traffic issue you can assume its coming. > > In what countries are there laws about what sip headers can go into a > sip message? > [RS> ] Right now the issue is related to traffic in both the US and Canada > but I would guess most of the PTT's are experiencing the same issue. The FCC > order on USF/ICC reform is very specific on the requirement for non > modification of charge number or calling party number in the signaling > path.. aka the SIP headers when applicable. A fair amount of this goes > away with bill and keep but you can assume you'll see a bunch of new > "requirements" be imposed as a transition to all SIP Interconnection for > real time communications occurs over the next decade. > > Thanks, > Paul > > From HKaplan@acmepacket.com Tue Feb 28 10:17:11 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A5821F85C2 for ; Tue, 28 Feb 2012 10:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-kJoMoRQUgx for ; Tue, 28 Feb 2012 10:17:11 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EF7F021F85BB for ; Tue, 28 Feb 2012 10:17:10 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 28 Feb 2012 13:17:05 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.216]) by Mail1.acmepacket.com ([169.254.1.208]) with mapi id 14.01.0270.001; Tue, 28 Feb 2012 13:17:05 -0500 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: AQHM9kUs9b7JHM0MHkOYIfWwpfMX4Q== Date: Tue, 28 Feb 2012 18:17:04 +0000 Message-ID: References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> In-Reply-To: <4F4987A7.5080804@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 18:17:11 -0000 I don't think it's so much that there'll be a law about what exact SIP head= ers must be used/included per se - it's more that they'll pass a law saying= each service provider (ie, IXC/ILEC/etc.) must indicate the call request t= ransited it, and pass on those indications it received from upstream. How = it's encoded (whether it be a SIP header, ISUP body, or for that matter not= in SIP but in SS7 calls) is probably going to be left out. (I hope!) -hadriel On Feb 25, 2012, at 8:15 PM, Paul Kyzivat wrote: > On 2/25/12 10:50 AM, Richard Shockey wrote: >=20 >> Also, what is to prevent someone from forging SPIDs in a message? >> [RS> ] >> [RS> ] One of the principal use cases for a global SPID this is >> International Interconnection of E.164 traffic or even domestic traffic = in >> some national jurisdictions. As for forging SPID's we have the same prob= lem >> with issues of Calling Number in one way SIP traffic over the PSTN in th= e >> US. People do bad things. The prevention mechanism is national law or >> regulation that defines what is in the headers and what cannot be modifi= ed >> as it might transverse a all IP Interconnected network using E.164 >> identifiers. Its called fines and jail. >=20 > There's a lot of callerid forging going on, and AFAIK nobody is going to = jail for it. >=20 > In what countries are there laws about what sip headers can go into a sip= message? >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From victor.pascual.avila@gmail.com Tue Feb 28 13:23:31 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1E21F85D8 for ; Tue, 28 Feb 2012 13:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp5s-nPdssQA for ; Tue, 28 Feb 2012 13:23:31 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 852E021F85D4 for ; Tue, 28 Feb 2012 13:23:30 -0800 (PST) Received: by wicr5 with SMTP id r5so2168036wic.31 for ; Tue, 28 Feb 2012 13:23:29 -0800 (PST) Received-SPF: pass (google.com: domain of victor.pascual.avila@gmail.com designates 10.180.92.34 as permitted sender) client-ip=10.180.92.34; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.pascual.avila@gmail.com designates 10.180.92.34 as permitted sender) smtp.mail=victor.pascual.avila@gmail.com; dkim=pass header.i=victor.pascual.avila@gmail.com Received: from mr.google.com ([10.180.92.34]) by 10.180.92.34 with SMTP id cj2mr3849793wib.20.1330464209832 (num_hops = 1); Tue, 28 Feb 2012 13:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=sw0O28Ze37VdZpN2a9CWIjr6B5cVIeI605Zx6h3P0zA=; b=S5CTgmqAawc7r0hNuaIl179t0ikKbUAtgmfnQNKNMV8xwXUX/A8SOJoshEnPAGvhuX 0V8Jjqn5cRxUZJ/As8S77NBhHGycW/U5AYKJDibkHtjY6B+16VRjdpm57LcWuWU5vqvb MeWAlFQ6DSnSZSWgXWmHMeJvqh/JHTPRhqAFM= Received: by 10.180.92.34 with SMTP id cj2mr3118701wib.20.1330464209704; Tue, 28 Feb 2012 13:23:29 -0800 (PST) Received: from [192.168.254.195] (213.211.135.48.static.edpnet.net. [213.211.135.48]) by mx.google.com with ESMTPS id s2sm76495692wix.3.2012.02.28.13.23.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 13:23:28 -0800 (PST) References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> From: Victor Pascual Content-Type: multipart/alternative; boundary=Apple-Mail-D71FCB74-F7E2-4463-86A9-DBFDF46F5B6F X-Mailer: iPhone Mail (9A405) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> Message-Id: <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> Date: Tue, 28 Feb 2012 22:23:25 +0100 To: dispatch@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 21:23:31 -0000 --Apple-Mail-D71FCB74-F7E2-4463-86A9-DBFDF46F5B6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" wrote: > I like CALLID > =20 > Partha > =20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha= lf Of DRAGE, Keith (Keith) > Sent: Sunday, February 26, 2012 6:05 AM > To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes' > Cc: 'DISPATCH' > Subject: Re: [dispatch] Acronym for the SIP Session ID WG > =20 > I=E2=80=99ll work with CALLID > =20 > Keith > =20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha= lf Of Richard Shockey > Sent: 25 February 2012 15:58 > To: 'Hadriel Kaplan'; 'Mary Barnes' > Cc: 'DISPATCH' > Subject: Re: [dispatch] Acronym for the SIP Session ID WG > =20 > Outstanding =E2=80=A6 > =20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha= lf Of Hadriel Kaplan > Sent: Friday, February 24, 2012 2:20 PM > To: Mary Barnes > Cc: DISPATCH > Subject: Re: [dispatch] Acronym for the SIP Session ID WG > =20 > =20 > Oh I like INSIPID - it really is a boring topic, after all, and besides th= e acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin= ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phra= ses. :) > =20 > But if someone really wants one that will be easy to remember the purpose o= f, we could make it: > Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID= > :) > =20 > -hadriel > =20 > =20 > On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: > =20 >=20 > Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed).= Personally, I would like have SIP somewhere in the WG name. I'm just wai= ting for Hadriel to come up with a list from which we can choose one. > =20 > Mary.=20 >=20 > On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) wrote: > I see no reason why we don't call it by the name it currently appears as i= n the agenda, i.e. >=20 > sessionid >=20 > At least it reminds me what it is about, which I am not getting from any o= f the other suggestions so far posted. >=20 > Keith >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Gonzalo Camarillo > > Sent: 23 February 2012 17:30 > > To: DISPATCH > > Subject: [dispatch] Acronym for the SIP Session ID WG > > > > Folks, > > > > as you know, we are in the process of chartering the SIP Session ID WG. > > As usual, we need an acronym for this new group. Any suggestions? > > > > Note that I will be making a decision about this real soon. I will take > > into consideration all the input I receive before that. > > > > Cheers, > > > > Gonzalo > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-D71FCB74-F7E2-4463-86A9-DBFDF46F5B6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1

On Feb 27= , 2012, at 8:17 AM, "Ravindran, Parthasarathi" <pravindran@sonusnet.com> wrote:

<= /div>
=

I like CALLID

 

Partha

 

From: dispatch-bounces@ietf.org [mailto:disp= atch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Sunday, February 26, 2012 6:05 AM
To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acronym for the SIP Session ID WG<= /span>

 

I=E2=80=99ll work= with CALLID

 =

Keith<= /span>

 =

From: dispatch-bounces@ietf.org [= mailto:dispatch-bounces@ietf.or= g] On Behalf Of Richard Shockey
Sent: 25 February 2012 15:58
To: 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acronym for the SIP Session ID WG=

 

Outstanding =E2=80=A6<= /o:p>

 

From: dispatch-bounces@ietf.org [= mailto:dispatch-bounces@ietf.or= g] On Behalf Of Hadriel Kaplan
Sent: Friday, February 24, 2012 2:20 PM
To: Mary Barnes
Cc: DISPATCH
Subject: Re: [dispatch] Acronym for the SIP Session ID WG<= /span>

 

 

Oh I like INSIPID - it really is a boring topic, afte= r all, and besides the acronym is not only the phrase "In SIP ID" but also a= n anagram for "I Spin ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probabl= y other relevant phrases. :)

 

But if someone really wants one that will be easy to r= emember the purpose of, we could make it:

Correlation Attribute for Logically Linking Independe= nt Dialogs =3D CALLID

:)

 

-hadriel

 

 

On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:<= /o:p>

 

Because WGs are supposed to be limited to 8 character= s (MEDIACTRL goofed).  Personally, I would  like have SIP somewher= e in the WG name.  I'm just waiting for Hadriel to come up with a list f= rom which we can choose one.

 

Mary. =

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith= ) <keith.drage@alcatel-= lucent.com> wrote:

I see no reason why we don't call it by the name it c= urrently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of t= he other suggestions so far posted.

Keith


> -----Original Message-----
> From: dispatch-bounces@iet= f.org [mailto:dispatch-boun= ces@ietf.org] On

> Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG.=
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will take=
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch

 

____________________= ___________________________
dispatch mailing list
= dispatch@ietf.org
<= span>https://www.= ietf.org/mailman/listinfo/dispatch
<= /html>= --Apple-Mail-D71FCB74-F7E2-4463-86A9-DBFDF46F5B6F-- From adam@nostrum.com Tue Feb 28 13:45:27 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46D21F85F7 for ; Tue, 28 Feb 2012 13:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vORG37URAQbq for ; Tue, 28 Feb 2012 13:45:25 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A00121F85F4 for ; Tue, 28 Feb 2012 13:45:25 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1SLjIQo082677 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Feb 2012 15:45:20 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F4D4AF2.7080105@nostrum.com> Date: Tue, 28 Feb 2012 15:45:22 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Victor Pascual References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> In-Reply-To: <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> Content-Type: multipart/alternative; boundary="------------090306060407060706080702" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 21:45:27 -0000 This is a multi-part message in MIME format. --------------090306060407060706080702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think Hadriel was kidding. The wisdom of naming a SIP-related working group after a SIP header field that it will in _no_ _way_ involve is highly questionable. /a On 2/28/12 3:23 PM, Victor Pascual wrote: > +1 > > On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" > > wrote: > >> I like CALLID >> >> Partha >> >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] *On Behalf Of *DRAGE, Keith (Keith) >> *Sent:* Sunday, February 26, 2012 6:05 AM >> *To:* Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes' >> *Cc:* 'DISPATCH' >> *Subject:* Re: [dispatch] Acronym for the SIP Session ID WG >> >> I'll work with CALLID >> >> Keith >> >> ------------------------------------------------------------------------ >> >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Richard Shockey >> *Sent:* 25 February 2012 15:58 >> *To:* 'Hadriel Kaplan'; 'Mary Barnes' >> *Cc:* 'DISPATCH' >> *Subject:* Re: [dispatch] Acronym for the SIP Session ID WG >> >> Outstanding ... >> >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Hadriel Kaplan >> *Sent:* Friday, February 24, 2012 2:20 PM >> *To:* Mary Barnes >> *Cc:* DISPATCH >> *Subject:* Re: [dispatch] Acronym for the SIP Session ID WG >> >> Oh I like INSIPID - it really is a boring topic, after all, and >> besides the acronym is not only the phrase "In SIP ID" but also an >> anagram for "I Spin ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and >> probably other relevant phrases. :) >> >> But if someone really wants one that will be easy to remember the >> purpose of, we could make it: >> >> Correlation Attribute for Logically Linking Independent Dialogs = CALLID >> >> :) >> >> -hadriel >> >> On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: >> >> Because WGs are supposed to be limited to 8 characters (MEDIACTRL >> goofed). Personally, I would like have SIP somewhere in the WG >> name. I'm just waiting for Hadriel to come up with a list from which >> we can choose one. >> >> Mary. >> >> On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) >> > > wrote: >> >> I see no reason why we don't call it by the name it currently appears >> as in the agenda, i.e. >> >> sessionid >> >> At least it reminds me what it is about, which I am not getting from >> any of the other suggestions so far posted. >> >> Keith >> >> >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org ] On >> >> > Behalf Of Gonzalo Camarillo >> > Sent: 23 February 2012 17:30 >> > To: DISPATCH >> > Subject: [dispatch] Acronym for the SIP Session ID WG >> > >> > Folks, >> > >> > as you know, we are in the process of chartering the SIP Session ID WG. >> > As usual, we need an acronym for this new group. Any suggestions? >> > >> > Note that I will be making a decision about this real soon. I will take >> > into consideration all the input I receive before that. >> > >> > Cheers, >> > >> > Gonzalo >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------090306060407060706080702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think Hadriel was kidding. The wisdom of naming a SIP-related working group after a SIP header field that it will in _no_ _way_ involve is highly questionable.

/a

On 2/28/12 3:23 PM, Victor Pascual wrote:
+1

On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" <pravindran@sonusnet.com> wrote:

I like CALLID

 

Partha

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Sunday, February 26, 2012 6:05 AM
To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acronym for the SIP Session ID WG

 

I’ll work with CALLID

 

Keith

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey
Sent: 25 February 2012 15:58
To: 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acronym for the SIP Session ID WG

 

Outstanding …

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Friday, February 24, 2012 2:20 PM
To: Mary Barnes
Cc: DISPATCH
Subject: Re: [dispatch] Acronym for the SIP Session ID WG

 

 

Oh I like INSIPID - it really is a boring topic, after all, and besides the acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phrases. :)

 

But if someone really wants one that will be easy to remember the purpose of, we could make it:

Correlation Attribute for Logically Linking Independent Dialogs = CALLID

:)

 

-hadriel

 

 

On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:

 

Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed).  Personally, I would  like have SIP somewhere in the WG name.  I'm just waiting for Hadriel to come up with a list from which we can choose one.

 

Mary. 

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:

I see no reason why we don't call it by the name it currently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of the other suggestions so far posted.

Keith


> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On

> Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG.
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will take
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--------------090306060407060706080702-- From keith.drage@alcatel-lucent.com Tue Feb 28 15:15:51 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E70221E802C for ; Tue, 28 Feb 2012 15:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.443 X-Spam-Level: X-Spam-Status: No, score=-109.443 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvwrUyacLdoS for ; Tue, 28 Feb 2012 15:15:48 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id DCA1E21E802A for ; Tue, 28 Feb 2012 15:15:47 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q1SNFfd8030430 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 Feb 2012 00:15:44 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 29 Feb 2012 00:15:41 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , Victor Pascual Date: Wed, 29 Feb 2012 00:15:37 +0100 Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: Acz2YlFbjazGn3z0QnKgpC/3CIYPeQADCDHQ Message-ID: References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> <4F4D4AF2.7080105@nostrum.com> In-Reply-To: <4F4D4AF2.7080105@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE224B5B6A0FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 23:15:51 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE224B5B6A0FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think anyone is trying to prejudge that. My preference is anything that at least gives a meaningful sense of what th= e WG is about. Sessionid would in my mind be idea and that is the terminolo= gy that flows through the last version of the charter I saw. I'm told we ca= nnot have that because it is one character too long. I'll settle for called= as the next most meaningful thing. I don't expect this to be a protocol el= ement name - just something I can remember the groups function more easily = from. Which I have been unable to do with many of those suggested by this fratern= ity in the past - particularly those based on beverages. Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Adam Roach Sent: 28 February 2012 21:45 To: Victor Pascual Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP Session ID WG I think Hadriel was kidding. The wisdom of naming a SIP-related working gro= up after a SIP header field that it will in _no_ _way_ involve is highly qu= estionable. /a On 2/28/12 3:23 PM, Victor Pascual wrote: +1 On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" > wrote: I like CALLID Partha From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Sunday, February 26, 2012 6:05 AM To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG I'll work with CALLID Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: 25 February 2012 15:58 To: 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG Outstanding ... From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, February 24, 2012 2:20 PM To: Mary Barnes Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Oh I like INSIPID - it really is a boring topic, after all, and besides the= acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin= ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phr= ases. :) But if someone really wants one that will be easy to remember the purpose o= f, we could make it: Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID :) -hadriel On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). = Personally, I would like have SIP somewhere in the WG name. I'm just wai= ting for Hadriel to come up with a list from which we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) > wrote: I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG > > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_EDC0A1AE77C57744B664A310A0B23AE224B5B6A0FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t think anyone is trying t= o prejudge that.

 

My preference is anything that at leas= t gives a meaningful sense of what the WG is about. Sessionid would in my min= d be idea and that is the terminology that flows through the last version of the charter I saw. I’m told we cannot have that because it is one charact= er too long. I’ll settle for called as the next most meaningful thing. I don= ’t expect this to be a protocol element name – just something I can remember th= e groups function more easily from.

 

Which I have been unable to do with ma= ny of those suggested by this fraternity in the past – particularly thos= e based on beverages.

 

Keith

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On B= ehalf Of Adam Roach
Sent: 28 February 2012 21:45=
To: Victor Pascual
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Acro= nym for the SIP Session ID WG

=  

= I think Hadriel was kidding. The wisdom of namin= g a SIP-related working group after a SIP header field that it will in _no_ _wa= y_ involve is highly questionable.

/a

On 2/28/12 3:23 PM, Victor Pascual wrote:

= +1


On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" <pravindran@s= onusnet.com> wrote:

I like CALLID =

 

Partha

 

From:= = dispatch-b= ounces@ietf.org [mailto:dispatch-bounces@ietf.= org] On Behalf Of DRAGE, Keith (K= eith)
Sent: Sunday, February 26, 2= 012 6:05 AM
To: Richard Shockey; 'Hadrie= l Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acro= nym for the SIP Session ID WG

 

I’ll work with CALLID

 =

Keith<= /o:p>

 =

From:= = dispatch-b= ounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On Behalf Of Richard Shockey=
Sent: 25 February 2012 15:58=
To: 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re: [dispatch] Acro= nym for the SIP Session ID WG

=  

Outstanding &#= 8230;

 

From:= = dispatch-b= ounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan<= br> Sent: Friday, February 24, 2= 012 2:20 PM
To: Mary Barnes
Cc: DISPATCH
Subject: Re: [dispatch] Acro= nym for the SIP Session ID WG

 

 

= Oh I like INSIPID - it really is a boring topic,= after all, and besides the acronym is not only the phrase "In SIP ID" b= ut also an anagram for "I Spin ID", "I Snip ID", "I P= in IDs", "IP ID Sin" and probably other relevant phrases. :)

 

= But if someone really wants one that will be eas= y to remember the purpose of, we could make it:

= Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID

= :)

 

= -hadriel

 

 

= On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:<= o:p>

 =

= Because WGs are supposed to be limited to 8 char= acters (MEDIACTRL goofed).  Personally, I would  like have SIP somewhere= in the WG name.  I'm just waiting for Hadriel to come up with a list from which we can choose one.

 

Mary. <= /o:p>

= On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (= Keith) <keith.drage@alcatel-lucent.com> wrote:

= I see no reason why we don't call it by the name= it currently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted.

Keith

=
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On

= > Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will tak= e
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch@i= etf.org
> https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________
dispatch mailing list
dispatch@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dispatch

 

= _______________________________________________<= br> dispatch mailing list
dispatch@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dispatch

 

= _______________________________________________<= br> dispatch mailing list
dispatch@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dispatch

= 


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.or=
g/mailman/listinfo/dispatch

=  

--_000_EDC0A1AE77C57744B664A310A0B23AE224B5B6A0FRMRSSXCHMBSC3d_-- From tom.taylor.stds@gmail.com Tue Feb 28 16:07:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA8121E8055 for ; Tue, 28 Feb 2012 16:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLKRUpFvTV-Z for ; Tue, 28 Feb 2012 16:07:35 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2612B21E802A for ; Tue, 28 Feb 2012 16:07:35 -0800 (PST) Received: by obbeh20 with SMTP id eh20so3963181obb.31 for ; Tue, 28 Feb 2012 16:07:34 -0800 (PST) Received-SPF: pass (google.com: domain of tom.taylor.stds@gmail.com designates 10.50.95.195 as permitted sender) client-ip=10.50.95.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom.taylor.stds@gmail.com designates 10.50.95.195 as permitted sender) smtp.mail=tom.taylor.stds@gmail.com; dkim=pass header.i=tom.taylor.stds@gmail.com Received: from mr.google.com ([10.50.95.195]) by 10.50.95.195 with SMTP id dm3mr24983833igb.9.1330474054763 (num_hops = 1); Tue, 28 Feb 2012 16:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=I8TVFX5YquqjzGExM61md9L1vlcfnbpFwf6TWCh/V4I=; b=e6fc8k8loNLOPHcb0zflNU1PeBC2XhhagjWDVTskHlj+4kYenHYXqzQe1l17COkqoO HKgQMoaNyv/fWa0h8OrJ3A516Tywrq5SA1tERBj2/MUP5Ha58r8XuRo/AjfAJ4isAlAL YjwW2atYWfej8WLClURsBgUGtlwhu3G4bUPSo= Received: by 10.50.95.195 with SMTP id dm3mr20276806igb.9.1330474054729; Tue, 28 Feb 2012 16:07:34 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id vw3sm2796778igb.9.2012.02.28.16.07.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 16:07:34 -0800 (PST) Message-ID: <4F4D6C42.2090004@gmail.com> Date: Tue, 28 Feb 2012 19:07:30 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> <4F4D4AF2.7080105@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120228-1, 28/02/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 00:07:41 -0000 Sessid On 28/02/2012 6:15 PM, DRAGE, Keith (Keith) wrote: > I don’t think anyone is trying to prejudge that. > > My preference is anything that at least gives a meaningful sense of what > the WG is about. Sessionid would in my mind be idea and that is the > terminology that flows through the last version of the charter I saw. > I’m told we cannot have that because it is one character too long. I’ll > settle for called as the next most meaningful thing. I don’t expect this > to be a protocol element name – just something I can remember the groups > function more easily from. > > Which I have been unable to do with many of those suggested by this > fraternity in the past – particularly those based on beverages. > > Keith > > ------------------------------------------------------------------------ > > *From:*dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On > Behalf Of *Adam Roach > *Sent:* 28 February 2012 21:45 > *To:* Victor Pascual > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] Acronym for the SIP Session ID WG > > I think Hadriel was kidding. The wisdom of naming a SIP-related working > group after a SIP header field that it will in _no_ _way_ involve is > highly questionable. > > /a >... From adam@nostrum.com Tue Feb 28 19:40:09 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1D321E8114 for ; Tue, 28 Feb 2012 19:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ruS7UwO6CzF for ; Tue, 28 Feb 2012 19:40:09 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 27AFF21E8071 for ; Tue, 28 Feb 2012 19:40:08 -0800 (PST) Received: from [192.168.0.159] (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q1T3e64A037461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Feb 2012 21:40:07 -0600 (CST) (envelope-from adam@nostrum.com) References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> <4F4D4AF2.7080105@nostrum.com> <4F4D6C42.2090004@gmail.com> In-Reply-To: <4F4D6C42.2090004@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9A405) From: Adam Roach Date: Tue, 28 Feb 2012 21:40:21 -0600 To: Tom Taylor Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 03:40:09 -0000 Works for me. On Feb 28, 2012, at 18:07, Tom Taylor wrote: > Sessid >=20 > On 28/02/2012 6:15 PM, DRAGE, Keith (Keith) wrote: >> I don=E2=80=99t think anyone is trying to prejudge that. >>=20 >> My preference is anything that at least gives a meaningful sense of what >> the WG is about. Sessionid would in my mind be idea and that is the >> terminology that flows through the last version of the charter I saw. >> I=E2=80=99m told we cannot have that because it is one character too long= . I=E2=80=99ll >> settle for called as the next most meaningful thing. I don=E2=80=99t expe= ct this >> to be a protocol element name =E2=80=93 just something I can remember the= groups >> function more easily from. >>=20 >> Which I have been unable to do with many of those suggested by this >> fraternity in the past =E2=80=93 particularly those based on beverages. >>=20 >> Keith >>=20 >> ------------------------------------------------------------------------ >>=20 >> *From:*dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On >> Behalf Of *Adam Roach >> *Sent:* 28 February 2012 21:45 >> *To:* Victor Pascual >> *Cc:* dispatch@ietf.org >> *Subject:* Re: [dispatch] Acronym for the SIP Session ID WG >>=20 >> I think Hadriel was kidding. The wisdom of naming a SIP-related working >> group after a SIP header field that it will in _no_ _way_ involve is >> highly questionable. >>=20 >> /a >> ... > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jmpolk@cisco.com Tue Feb 28 20:17:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C652B21E8015 for ; Tue, 28 Feb 2012 20:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.531 X-Spam-Level: X-Spam-Status: No, score=-109.531 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl2+1Q8ZWyny for ; Tue, 28 Feb 2012 20:17:56 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3FB21E8013 for ; Tue, 28 Feb 2012 20:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1949; q=dns/txt; s=iport; t=1330489076; x=1331698676; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=c/8ZLQAwnS9kNjaWMDmUbu9j7eolR7Npds7t8P36Hrg=; b=ks/cswyenBnhO+ItrvqpNl3E4E4Ts/74tNUZ+ri/jPhYnKt6LQcsb6va nbgJt04naMadvl5eGswa/9v1WpOHErb7IR6eTDRkk18fH/BhbVbYJ8pzR ERbsouYjXB08E1xW1ixgfhVzuj+eR4/xHGbfpZw8ba58uEQRNLQdGazuV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIymTU+rRDoG/2dsb2JhbABDs2qBB4F3AQEBBAEBAQ8BJTYLEAcEEQQBAQEnBxkIBh8RBgESIodlDKB4AZcSBIkZg2wOGAMCBgMDAQEBCQEBDQkDBwMYBgMChQ0DDwgDAwMHDAEYBhqDLASIHDOYCYd2 X-IronPort-AV: E=Sophos;i="4.73,499,1325462400"; d="scan'208";a="31025259" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 29 Feb 2012 04:17:56 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1T4HtQr029529; Wed, 29 Feb 2012 04:17:55 GMT Message-Id: <201202290417.q1T4HtQr029529@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Feb 2012 22:17:54 -0600 To: Adam Roach , Tom Taylor From: "James M. Polk" In-Reply-To: References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> <4F4D4AF2.7080105@nostrum.com> <4F4D6C42.2090004@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 04:17:57 -0000 I'm still a fan of INSIPID... it's very clueful At 09:40 PM 2/28/2012, Adam Roach wrote: >Works for me. On Feb 28, 2012, at 18:07, Tom=20 >Taylor wrote: >=20 >Sessid > > On 28/02/2012 6:15 PM, DRAGE, Keith=20 >(Keith) wrote: >> I don=E2=80=99t think anyone is=20 >trying to prejudge that. >> >> My preference is=20 >anything that at least gives a meaningful sense=20 >of what >> the WG is about. Sessionid would in=20 >my mind be idea and that is the >> terminology=20 >that flows through the last version of the=20 >charter I saw. >> I=E2=80=99m told we cannot have that=20 >because it is one character too long. I=E2=80=99ll >>=20 >settle for called as the next most meaningful=20 >thing. I don=E2=80=99t expect this >> to be a protocol=20 >element name =AD jjust something I can remember=20 >the groups >> function more easily from. >> >>=20 >Which I have been unable to do with many of=20 >those suggested by this >> fraternity in the=20 >past =AD particularly those based on=20 >beverages. >> >> Keith >>> >>=20 >------------------------------------------------------------------------ = =20 > >> >> *From:*dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] *On >> Behalf=20 >Of *Adam Roach >> *Sent:* 28 February 2012=20 >21:45 >> *To:* Victor Pascual >> *Cc:*=20 >dispatch@ietf.org >> *Subject:* Re: [dispatch]=20 >Acronym for the SIP Session ID WG >> >> I think=20 >Hadriel was kidding. The wisdom of naming a=20 >SIP-related working >> group after a SIP header=20 >field that it will in _no_ _way_ involve is >>=20 >highly questionable. >> >> /a >> ... >=20 >_______________________________________________ >=20 > dispatch mailing list > dispatch@ietf.org >=20 >https://www.ietf.org/mailman/listinfo/dispatch=20 >_______________________________________________=20 >dispatch mailing list dispatch@ietf.org=20 >https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Feb 28 20:34:16 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E532021E8010 for ; Tue, 28 Feb 2012 20:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jZCEiSVrh0b for ; Tue, 28 Feb 2012 20:34:16 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F52F21E803D for ; Tue, 28 Feb 2012 20:34:16 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta10.westchester.pa.mail.comcast.net with comcast id fgZX1i0030ldTLk5AgaBD8; Wed, 29 Feb 2012 04:34:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta04.westchester.pa.mail.comcast.net with comcast id fgaB1i00707duvL3QgaBPP; Wed, 29 Feb 2012 04:34:11 +0000 Message-ID: <4F4DAAC1.6020109@alum.mit.edu> Date: Tue, 28 Feb 2012 23:34:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> <4F4D4AF2.7080105@nostrum.com> <4F4D6C42.2090004@gmail.com> <201202290417.q1T4HtQr029529@mtv-core-1.cisco.com> In-Reply-To: <201202290417.q1T4HtQr029529@mtv-core-1.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 04:34:17 -0000 On 2/28/12 11:17 PM, James M. Polk wrote: > I'm still a fan of INSIPID... it's very clueful I also prefer INSIPID of all the names mentioned to date. > At 09:40 PM 2/28/2012, Adam Roach wrote: >> Works for me. On Feb 28, 2012, at 18:07, Tom Taylor >> wrote: > Sessid > > On 28/02/2012 6:15 PM, >> DRAGE, Keith (Keith) wrote: >> I don’t think anyone is trying to >> prejudge that. >> >> My preference is anything that at least gives a >> meaningful sense of what >> the WG is about. Sessionid would in my >> mind be idea and that is the >> terminology that flows through the >> last version of the charter I saw. >> I’m told we cannot have that >> because it is one character too long. I’ll >> settle for called as >> the next most meaningful thing. I don’t expect this >> to be a >> protocol element name ­ jjust something I can remember the groups >> >> function more easily from. >> >> Which I have been unable to do with >> many of those suggested by this >> fraternity in the past ­ >> particularly those based on beverages. >> >> Keith >>> >> >> ------------------------------------------------------------------------ >> >> >> *From:*dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] *On >> Behalf Of *Adam Roach >> >> *Sent:* 28 February 2012 21:45 >> *To:* Victor Pascual >> *Cc:* >> dispatch@ietf.org >> *Subject:* Re: [dispatch] Acronym for the SIP >> Session ID WG >> >> I think Hadriel was kidding. The wisdom of naming >> a SIP-related working >> group after a SIP header field that it will >> in _no_ _way_ involve is >> highly questionable. >> >> /a >> ... > >> _______________________________________________ > dispatch mailing >> list > dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ dispatch mailing list >> dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From D.Malas@cablelabs.com Wed Feb 29 08:40:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB9B21F861D for ; Wed, 29 Feb 2012 08:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.287 X-Spam-Level: X-Spam-Status: No, score=-100.287 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx4l-hWg7EgG for ; Wed, 29 Feb 2012 08:40:27 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D11A521F872F for ; Wed, 29 Feb 2012 08:40:26 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q1TGdPhA014762; Wed, 29 Feb 2012 09:39:25 -0700 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 29 Feb 2012 09:39:25 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 29 Feb 2012 09:39:25 -0700 From: Daryl Malas To: "DRAGE, Keith (Keith)" , Adam Roach , Victor Pascual Date: Wed, 29 Feb 2012 09:39:26 -0700 Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: Acz3ALKhzBLM8R/+RAuWcUvTSBieQg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB73A2A7C212dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:40:28 -0000 --_000_CB73A2A7C212dmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 re: "just something I can remember the groups function more easily from.= " From: "DRAGE, Keith (Keith)" > Date: Tue, 28 Feb 2012 16:15:37 -0700 To: Adam Roach >, Victor Pascual = > Cc: "dispatch@ietf.org" > Subject: Re: [dispatch] Acronym for the SIP Session ID WG I don=92t think anyone is trying to prejudge that. My preference is anything that at least gives a meaningful sense of what th= e WG is about. Sessionid would in my mind be idea and that is the terminolo= gy that flows through the last version of thecharter I saw. I=92m told we c= annot have that because it is one character too long. I=92ll settle for cal= led as the next most meaningful thing. I don=92t expect this to be a protoc= ol element name =96 just something I can remember the groups function more = easily from. Which I have been unable to do with many of those suggested by this fratern= ity in the past =96 particularly those based on beverages. Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: 28 February 2012 21:45 To: Victor Pascual Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP Session ID WG I think Hadriel was kidding. The wisdom of naming a SIP-related working gro= up after a SIP header field that it will in _no_ _way_ involve is highly qu= estionable. /a On 2/28/12 3:23 PM, Victor Pascual wrote: +1 On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" > wrote: I like CALLID Partha From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Sunday, February 26, 2012 6:05 AM To: Richard Shockey; 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG I=92ll work with CALLID Keith ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Richard Shockey Sent: 25 February 2012 15:58 To: 'Hadriel Kaplan'; 'Mary Barnes' Cc: 'DISPATCH' Subject: Re: [dispatch] Acronym for the SIP Session ID WG Outstanding =85 From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, February 24, 2012 2:20 PM To: Mary Barnes Cc: DISPATCH Subject: Re: [dispatch] Acronym for the SIP Session ID WG Oh I like INSIPID - it really is a boring topic, after all, and besides the= acronym is not only the phrase "In SIP ID" but also an anagram for "I Spin= ID", "I Snip ID", "I Pin IDs", "IP ID Sin" and probably other relevant phr= ases. :) But if someone really wants one that will be easy to remember the purpose o= f, we could make it: Correlation Attribute for Logically Linking Independent Dialogs =3D CALLID :) -hadriel On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote: Because WGs are supposed to be limited to 8 characters (MEDIACTRL goofed). = Personally, I would like have SIP somewhere in the WG name. I'm just wai= ting for Hadriel to come up with a list fromwhich we can choose one. Mary. On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Keith (Keith) > wrote: I see no reason why we don't call it by the name it currently appears as in= the agenda, i.e. sessionid At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted. Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: 23 February 2012 17:30 > To: DISPATCH > Subject: [dispatch] Acronym for the SIP Session ID WG > > Folks, > > as you know, we are in the process of chartering the SIP Session ID WG. > As usual, we need an acronym for this new group. Any suggestions? > > Note that I will be making a decision about this real soon. I will take > into consideration all the input I receive before that. > > Cheers, > > Gonzalo > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CB73A2A7C212dmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1 re: "just something I can remember the groups function= more easily from."

From: "DRAGE, Keith (Keith)&quo= t; <keith.drage@alcate= l-lucent.com>
Date: Tue,= 28 Feb 2012 16:15:37 -0700
To: = Adam Roach <adam@nostrum.com>= ;, Victor Pascual <vic= tor.pascual.avila@gmail.com>
Cc:= "dispatch@ietf.org&q= uot; <dispatch@ietf.org>
= Subject: Re: [dispatch] Acronym fo= r the SIP Session ID WG

I don=92t think anyone is trying to pr= ejudge that.

 

My preference is anything that at leas= t gives a meaningful sense of what the WG is about. Sessionid would in my min= d be idea and that is the terminology that flows through the last version of the= charter I saw. I=92m told we cannot have that because it is one character t= oo long. I=92ll settle for called as the next most meaningful thing. I don=92t= expect this to be a protocol element name =96 just something I can remember the gr= oups function more easily from.

 

Which I have been unable to do with ma= ny of those suggested by this fraternity in the past =96 particularly those ba= sed on beverages.

 

Keith

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.= org] On Behalf Of Adam Roach
Sent: 28 February 2012 21:45
To: Victor Pascual
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Acronym for the SIP Session ID WG

=  

<= span style=3D"font-size:12.0pt">I think Hadriel was kidding. The wisdom of = naming a SIP-related working group after a SIP header field that it will in _no_ _wa= y_ involve is highly questionable.

/a

On 2/28/12 3:23 PM, Victor Pascual wrote:

+1

=


On Feb 27, 2012, at 8:17 AM, "Ravindran, Parthasarathi" <pravindran@s= onusnet.com> wrote:

I like CALLID

 

Partha

 = ;

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.= org] On Behalf Of DRAGE, Keith (K= eith)
Sent: Sunday, Febru= ary 26, 2012 6:05 AM
To: Richard Shock= ey; 'Hadriel Kaplan'; 'Mary Barnes'
Cc: 'DISPATCH'
Subject: Re:= [dispatch] Acronym for the SIP Session ID WG

 

I=92ll work with CALLID

 =

Keith<= /o:p>

 =

=

From: dispatch-bounces@ietf.org= [mail= to:dispatch-bounces@ietf.org] On Behalf Of Richard Shockey=
Sent: 25 February 2012 1= 5:58
To: 'Hadriel Kaplan'= ; 'Mary Barnes'
Cc: 'DISPATCH'Subject: Re: [dispatch] Acr= onym for the SIP Session ID WG

 <= /font>

Outstanding =85

 

From: dispatch-bou= nces@ietf.org [mail= to:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan<= br>Sent: Friday, February 24= , 2012 2:20 PM
To: Mary BarnesCc: DISPATCH
Subject: Re: [dispatch] Acronym for the SIP Session ID WG

 

 

Oh I like INSIPID - it really is a boring topic, after all, and besides the acronym is not only the phrase "In SIP ID" b= ut also an anagram for "I Spin ID", "I Snip ID", "I P= in IDs", "IP ID Sin" and probably other relevant phrases. :)

 

=

But if someone really wants one that= will be easy to remember the purpose of, we could make it:

Correlation Attr= ibute for Logically Linking Independent Dialogs =3D CALLID

:)<= u5:p>

&nb= sp;

-hadriel

=

 

 <= /o:p>

On Feb 24, 2012, at 1:56 PM, Mary Barnes wrote:

 

= Because WGs are supposed to be limited to = 8 characters (MEDIACTRL goofed).  Personally, I would  like have SIP somewhere= in the WG name.  I'm just waiting for Hadriel to come up with a list from= which we can choose one.

 

Mary. 

On Fri, Feb 24, 2012 at 12:37 PM, DRAGE, Kei= th (Keith) <keith.drage@alcatel-lucent.com> wrote:

I see no reason why we don't call it by the name it currently appears as in the agenda, i.e.

sessionid

At least it reminds me what it is about, which I am not getting from any of= the other suggestions so far posted.
<= span style=3D"color:#888888">
Keith

=
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On

> Behalf Of Gonzalo Camarillo
> Sent: 23 February 2012 17:30
> To: DISPATCH
> Subject: [dispatch] Acronym for the SIP Session ID WG
>
> Folks,
>
> as you know, we are in the process of chartering the SIP Session ID WG= .
> As usual, we need an acronym for this new group. Any suggestions?
>
> Note that I will be making a decision about this real soon. I will tak= e
> into consideration all the input I receive before that.
>
> Cheers,
>
> Gonzalo
> _______________________________________________
> dispatch mailing list
> dispatch= @ietf.org
> https://www.ietf.org/mailman/listinfo/dispa= tch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www= .ietf.org/mailman/listinfo/dispatch

 =

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/= listinfo/dispatch

 

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/= listinfo/dispatch

= 


__________=
_____________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch<=
/o:p>

 =

--_000_CB73A2A7C212dmalascablelabscom_-- From mperumal@cisco.com Wed Feb 29 10:30:48 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C4221F86A7 for ; Wed, 29 Feb 2012 10:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.177 X-Spam-Level: X-Spam-Status: No, score=-8.177 tagged_above=-999 required=5 tests=[AWL=1.222, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqj7SUVBOfg6 for ; Wed, 29 Feb 2012 10:30:47 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id B88C521F86B7 for ; Wed, 29 Feb 2012 10:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=4847; q=dns/txt; s=iport; t=1330540243; x=1331749843; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tOP+Zdx6EFFcAnIjkzLCM89JNJcq2rCVDopilqFn0tg=; b=TKc6M6LfcONvSjLJjJ1uCi8gcUqZWYlQylPDfoZ0Mo+r9rHO2rsX/FBb kD9VVzLXetF79nhUerOvwfnwDIBq/ct26PflSTi8D4BIxzVmTeiTBm1SN 2yW/p+dOOU3hRhgfgZStPH2nKQvdy9dFR6TI9XkxwG887JoFKNuBMJEoy k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJptTk9Io8UY/2dsb2JhbABEDrRWgXoBAQEEAQEBDwEdCjQXBAIBCA4DBAEBCwYXAQYBIAYfCQgBAQQBCggIARmHZwuaRgGfGIkXa4J3DAkKFQJAFQuFDQMPCAMDAwcMAQUGAgEGAgIGAQQJCwGCSWMEiE2YDIcgP4FU X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="6680728" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 29 Feb 2012 18:30:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1TIUe8p009994; Wed, 29 Feb 2012 18:30:40 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 00:00:40 +0530 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: Thu, 1 Mar 2012 00:00:37 +0530 Message-ID: <1D062974A4845E4D8A343C653804920207BEFD56@XMB-BGL-414.cisco.com> In-Reply-To: <4F47D838.6040404@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Acronym for the SIP Session ID WG Thread-Index: AczzIyJfRn/afGTfSKGHP108vBhpCQD61rZA References: <4F467798.1060805@ericsson.com><7F2072F1E0DE894DA4B517B93C6A05852C3D9615A8@ESESSCMS0356.eemea.ericsson.se><62A9ED0E-C13E-410B-8610-F6F42E5E9693@acmepacket.com> <4F47D838.6040404@alum.mit.edu> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Paul Kyzivat" , X-OriginalArrivalTime: 29 Feb 2012 18:30:40.0630 (UTC) FILETIME=[3D43E960:01CCF710] Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:30:48 -0000 |> And we can't remove the ability to change it, or else=20 |> we'll be removed and replaced by another SBC that will.=20 |> And I don't blame operators for having the SBC change=20 |> the Call-ID; it's a security issue, | |I know they think so. And I won't argue with their decision=20 |to do so. But I expect its more paranoia than justified. That's the same operator paranoia I was trying to point to for the session ID earlier: http://www.ietf.org/mail-archive/web/dispatch/current/msg02301.html I wish we don't have to start another WG for inventing yet another ID if operators decide to rewrite the session ID -:) Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat |Sent: Saturday, February 25, 2012 12:05 AM |To: dispatch@ietf.org |Subject: Re: [dispatch] Acronym for the SIP Session ID WG | |On 2/24/12 1:11 PM, Hadriel Kaplan wrote: |> |> I know (or hope) you're joking, because this is NOT just because of Acme |> SBCs, or even SBCs in general. |> A vast majority of IP-PBXs, Call-Managers, App-Servers, etc., I've seen |> change the Call-ID. As well as all the other SBCs. |> |> -hadriel |> p.s. for the past 4 or 5 years or more Acme's SBCs have by *default* NOT |> changed the Call-ID - it's just that most operators immediately change |> this setting to make it change the Call-ID anyway. And we can't remove |> the ability to change it, or else we'll be removed and replaced by |> another SBC that will. And I don't blame operators for having the SBC |> change the Call-ID; it's a security issue, | |I know they think so. And I won't argue with their decision to do so. |But I expect its more paranoia than justified. | |> and often the only way to |> make SIP work right. | |I would like to hear more about this part. | | Thanks, | Paul | |> On Feb 24, 2012, at 3:50 AM, Christer Holmberg wrote: |> |>> STROBA |>> SomeThing we aRe fOrced to do Because of hAdriel's sbcs. |>> |>> ------------------------------------------------------------------------ |>> *From:*dispatch-bounces@ietf.org |>> [mailto:dispatch-bounces@ietf.org]*On Behalf |>> Of*Schmidt, Christian 1. (NSN - DE/Munich) |>> *Sent:*24. helmikuuta 2012 10:33 |>> *To:*ext Mary Barnes; Michael Hammer |>> *Cc:*DISPATCH |>> *Subject:*Re: [dispatch] Acronym for the SIP Session ID WG |>> |>> What about SIDE? |>> Session ID Extension. |>> Somehow a topic on a border line. |>> Servus |>> Christian |>> *From:*dispatch-bounces@ietf.org |>> [mailto:dispatch-bounces@ietf.org]*On Behalf |>> Of*ext Mary Barnes |>> *Sent:*Thursday, February 23, 2012 7:20 PM |>> *To:*Michael Hammer |>> *Cc:*DISPATCH |>> *Subject:*Re: [dispatch] Acronym for the SIP Session ID WG |>> Not a good idea for several reasons: |>> 1)http://www.internetslang.com/SID-meaning-definition.asp |>> 2) It stands for something that is one of the most devastating things |>> a parent can experience (think about it). |>> 3) It really doesn't lean towards any intuitive idea of what it's about. |>> I can't come up with anything creative at this time other than the |>> very basic SIPSID (pronounced SIPS-ID). I'm sure Hadriel can concoct a |>> dozen or more. |>> Mary. |>> On Thu, Feb 23, 2012 at 11:58 AM, Michael Hammer > > wrote: |>> SID ? |>> |>> On Thu, Feb 23, 2012 at 12:30 PM, Gonzalo Camarillo |>> > > wrote: |>> Folks, |>> |>> as you know, we are in the process of chartering the SIP Session ID WG. |>> As usual, we need an acronym for this new group. Any suggestions? |>> |>> Note that I will be making a decision about this real soon. I will take |>> into consideration all the input I receive before that. |>> |>> Cheers, |>> |>> Gonzalo |>> _______________________________________________ |>> dispatch mailing list |>> dispatch@ietf.org |>> https://www.ietf.org/mailman/listinfo/dispatch |>> |>> |>> _______________________________________________ |>> dispatch mailing list |>> dispatch@ietf.org |>> https://www.ietf.org/mailman/listinfo/dispatch |>> |>> _______________________________________________ |>> dispatch mailing list |>> dispatch@ietf.org |>> https://www.ietf.org/mailman/listinfo/dispatch |> |> |> |> _______________________________________________ |> dispatch mailing list |> dispatch@ietf.org |> https://www.ietf.org/mailman/listinfo/dispatch | |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From aeh@db.org Wed Feb 29 13:14:02 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CC321F8716 for ; Wed, 29 Feb 2012 13:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OikOblxRSoDy for ; Wed, 29 Feb 2012 13:14:01 -0800 (PST) Received: from mailstore05.sysedata.no (mailstore05.sysedata.no [195.159.29.9]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3D21F86AD for ; Wed, 29 Feb 2012 13:14:00 -0800 (PST) Received: from [84.215.77.9] (helo=macbook.lan) by mailstore05.sysedata.no with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1S2qqU-0004wM-Iz; Wed, 29 Feb 2012 22:13:58 +0100 Message-ID: <4F4E9516.8030307@db.org> Date: Wed, 29 Feb 2012 22:13:58 +0100 From: "Alfred E. Heggestad" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Tom Taylor References: <4F467798.1060805@ericsson.com> <59E8BD13-6AAC-4EF2-BDE3-F7785CCF71EB@acmepacket.com> <01db01ccf3d6$39fe9bc0$adfbd340$@us> <387F9047F55E8C42850AD6B3A7A03C6C0E04DE00@inba-mail01.sonusnet.com> <0826F083-28DA-40AA-882F-A8BDBF2C9074@gmail.com> <4F4D4AF2.7080105@nostrum.com> <4F4D6C42.2090004@gmail.com> In-Reply-To: <4F4D6C42.2090004@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Acronym for the SIP Session ID WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:14:02 -0000 On 2/29/12 1:07 AM, Tom Taylor wrote: > Sessid > +1 /alfred