From gsalguei@cisco.com Tue Sep 4 19:42:51 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1969E21F8499 for ; Tue, 4 Sep 2012 19:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYleHBeACCjE for ; Tue, 4 Sep 2012 19:42:50 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23921F8498 for ; Tue, 4 Sep 2012 19:42:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q852gmbu028185 for ; Tue, 4 Sep 2012 22:42:48 -0400 (EDT) Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q852gmO2011378 for ; Tue, 4 Sep 2012 22:42:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Gonzalo Salgueiro In-Reply-To: <657AD091-25A8-4F52-BD58-ADEE2833DD58@cisco.com> Date: Tue, 4 Sep 2012 22:42:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E68A25E-78E0-4628-AB99-7420AB9B79B2@cisco.com> References: <0CD60541-DA01-4A16-9D98-1F1927DBB408@cisco.com> <657AD091-25A8-4F52-BD58-ADEE2833DD58@cisco.com> To: insipid@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [Insipid] INSIPID Virtual Interim Doodle Poll X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 02:42:51 -0000 Poll is now closed.=20 The next INSIPID Virtual Interim will be on October 4th at 9:00 AM EDT = (GMT -4:00) / 6:00 AM PDT (GMT -7:00) and will be a 2 hour meeting. Webex details to follow (once Secretariat provides them). Cheers, Gonzalo & Keith On Aug 28, 2012, at 12:02 AM, Gonzalo Salgueiro wrote: > Reminder that the poll closes this Friday. Please indicate your = preference for the INSIPID virtual interim. >=20 > --Gonzalo >=20 >=20 > On Aug 16, 2012, at 1:28 AM, Gonzalo Salgueiro wrote: >=20 >> Folks -=20 >>=20 >> As decided at IETF84 the INSIPID WG is planning a virtual interim = meeting in an attempt to comply with the milestone deadlines. Please = indicate your date/time preferences by the end of Friday, August 31. We = have offered a diverse selection of times during the weeks of September = 24 and October 1 to try and accommodate most. If you think other times = should be added to the poll, let the chairs knows. >>=20 >> This will be a 2 hour long webex meeting (I'll send out meeting = details once we converge on a date/time). >>=20 >> Please indicate your availability at: >>=20 >> http://doodle.com/ry7uz4ka5cpne7hi >>=20 >> The times specified on the poll are EDT (GMT -4:00) but it should be = intelligent enough to translate to your local time. >>=20 >> We're still working on the agenda, but we assume that we'll try to = close on open issues on the requirements draft as well as work towards = acceptable base text for a solution the WG can adopt. >>=20 >> Cheers, >>=20 >> Gonzalo and Keith >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >>=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From brett@broadsoft.com Wed Sep 5 04:33:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C8321F865C for ; Wed, 5 Sep 2012 04:33:36 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxFzwc2QkYg0 for ; Wed, 5 Sep 2012 04:33:35 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id CFDC421F8658 for ; Wed, 5 Sep 2012 04:33:32 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 5 Sep 2012 04:37:22 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 5 Sep 2012 04:37:21 -0700 From: Brett Tate To: "insipid@ietf.org" Thread-Topic: [Insipid] 3.X. End-to-end identification of a communication session: evaluation Thread-Index: Ac2Eqwatk/9ikOP8Ti62MUrD/3oWoQGq96Gg Date: Wed, 5 Sep 2012 11:37:20 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B885FAC@MBX06.citservers.local> References: <201208272320.q7RNK69G010568@mtv-core-2.cisco.com> In-Reply-To: <201208272320.q7RNK69G010568@mtv-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] 3.X. End-to-end identification of a communication session: evaluation X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 11:33:36 -0000 > 3.X. End-to-end identification of a communication session: >=20 > SIP messaging that either does not involve SIP servers=20 > or only involves SIP proxies, the Call-ID: header value=20 > sufficiently identifies each SIP message within a=20 > transaction or dialog. This is not the case when either=20 > B2BUAs or SBCs are in the signaling path between UAs.=20 > Therefore, we need the ability to identify each > communication session per transaction through a single=20 > SIP header-value regardless of which type of SIP servers=20 > are in the signaling path between UAs. For transactions=20 > that create a dialog, have each message within the same=20 > dialog MUST use the same identifier. If this item is added, I recommend that the last sentence be changed since = it appears to conflict with other requirements to allow the identifier to c= hange if the "end" changes. The following is an alternative to the last se= ntence; it is intentionally vague to allow the endpoint (B2BUA or otherwise= ) to change the identifier when deemed appropriate. =20 "Concerning transactions that create a dialog, each message within the same= dialog MUST use the same identifier unless the endpoint changes." Thanks, Brett From christer.holmberg@ericsson.com Wed Sep 5 04:36:07 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4D21F865E for ; Wed, 5 Sep 2012 04:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtGFj+HA+SdQ for ; Wed, 5 Sep 2012 04:36:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 805D821F8658 for ; Wed, 5 Sep 2012 04:36:06 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-55-504739259925 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 58.DE.17130.52937405; Wed, 5 Sep 2012 13:36:05 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 5 Sep 2012 13:36:04 +0200 From: Christer Holmberg To: "Paul E. Jones" , 'James Polk' , 'Andrew Allen' , "shida@ntt-at.com" Date: Wed, 5 Sep 2012 13:36:02 +0200 Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQKFof+u7rm5T9A76TKhojEtg9ODgAGf25OBAUpa5UoB0sHkvAJDQlBJARcmEVmVw7noYIAG+/KA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A461411@ESESSCMS0356.eemea.ericsson.se> References: , <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F55@ESESSCMS0356.eemea.ericsson.se>, <052401cd8656$5dc95f00$195c1d00$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F59@ESESSCMS0356.eemea.ericsson.se> <078e01cd87dd$23d02c60$6b708520$@packetizer.com> In-Reply-To: <078e01cd87dd$23d02c60$6b708520$@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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvra6qpXuAwaqVIhbTOrcyW8y//4zJ YseaQovzFzYwWfw+NI/VgdVjyu+NrB5Llvxk8ui5NJvRo2HfUXaPCV9WsgSwRnHZpKTmZJal FunbJXBlNLxuZCuYyV9x8cs/lgbG99xdjJwcEgImEjuPzWeDsMUkLtxbD2RzcQgJnGKUeLmu ASwhJDCfUaJhmmcXIwcHm4CFRPc/bZAaEYFpjBLnlkxnAalhFtCUWLH4NjuIzSKgIvFrUTsj iC0sECTRtKqDFcQWEQiWuP7wAQuEHSXxZ+Y5sBpegXCJubsvsEMs3sQs8eXOTLAiTgFbiVmt r8GOYAS67vupNUwQy8Qlbj2ZzwRxtYDEkj3nmSFsUYmXj/+xQtSLStxpX88IUa8jsWD3JzYI W1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjMK5iZk56eXmeqlFmcnFxfl5 esWpmxiBcXdwy2+DHYyb7osdYpTmYFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gXH5yXPcnwrOnYzkuWBnKPxtd65z8Y2FfRlT/Th0dwSHFDoLOAjdeVbF7h143WD2tD7fC55r q/r9Y2+W603NvOcv0M+VfzpzfQOf+raHp98kXJusqiEgK55Qk5/NnWNg27omxO94AWPVk8Ox PwwLLl3KfHUm7IHIruYZllnzTTtdn/xuDNpnqMRSnJFoqMVcVJwIABs1J/OJAgAA Cc: "insipid@ietf.org" Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 11:36:07 -0000 Hi Paul, Just for me to understand the use-case a little better: is there a reason w= hy the PBX can't keep the same value when contacting Carol? Regards, Christer -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com]=20 Sent: 1. syyskuuta 2012 4:00 To: Christer Holmberg; 'James Polk'; 'Andrew Allen'; shida@ntt-at.com Cc: insipid@ietf.org Subject: RE: [Insipid] Backward compability between draft-jones and draft-k= aplan Christer, > >Now, suppose Bob transfers the call with Alice to Carol. Bob's PBX=20 > >does the magic and Bob drops out of the call. Is it OK if the PBX=20 > >sends > Alice this? > > Session-ID: C; p=3DA > > > >This is a real-world scenario where two call legs are joined by the PBX. >=20 > What do you mean by "sends Alice this"? Do you mean that the=20 > session-id, on the exisiting dialog between Alice and the PBX, is updated= ? Yes. The Session-ID changes from: Session-ID: A; p=3DB To Session-ID: C; p=3DA In this way, we still have a single Session-ID end-to-end (namely, A || C o= r C || A, depending on how we order the values). However, the change in th= e Session-ID from A || B to A || C is necessary to indicate that an end dev= ice changed. If we do not allow for this, we do not have an end-to-end ID any longer. W= e will have two IDs, one going into the PBX and one coming out. And that d= efeats the purpose. So, the question is whether it's acceptable to make this change. If so, I = think we can go with a solution like that. The signaling will contain the = two UUID values, one representing each device, but the values might change = as described above. This is the best backward-compatible approach I can th= ink of and still ensure that, going forward, we have an ID we can see as en= d-to-end for the duration of the call where the same two devices are in dir= ect communication. Paul From brett@broadsoft.com Wed Sep 5 05:44:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61721F861E for ; Wed, 5 Sep 2012 05:44:31 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omdzBx8FdJus for ; Wed, 5 Sep 2012 05:44:30 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 72D0421F85AE for ; Wed, 5 Sep 2012 05:44:30 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 5 Sep 2012 05:48:20 -0700 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Wed, 5 Sep 2012 05:48:19 -0700 From: Brett Tate To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] REQ10: evaluation Thread-Index: AQJXn5mu3Zi+tP+Be4VcCRefHdJpXwK5a/dGAvg+O9gCvJ8WN5YZSTxQgArFTlA= Date: Wed, 5 Sep 2012 12:48:18 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B885FCC@MBX06.citservers.local> References: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9875@EXMBXCLUS01.citservers.local> <035301cd859b$346a28d0$9d3e7a70$@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F99CC@EXMBXCLUS01.citservers.local> <042901cd8601$402af9e0$c080eda0$@packetizer.com> In-Reply-To: <042901cd8601$402af9e0$c080eda0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] REQ10: evaluation X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 12:44:31 -0000 Hi Paul, > If changing the charter is what it take, yes. But is it=20 > necessary? Based upon Keith's email, I assume that it is necessary; however hopefully = the chairs will comment on the topic again. http://www.ietf.org/mail-archive/web/insipid/current/msg00255.html=20 > I'm not opposed to the wording in that sentence, as=20 > changing it to consider forked cases would make it overly=20 > complex. Perhaps the one thing we need to add is that we=20 > have to recognize the fact that a call does not stay > permanently fixed at a point of termination. For that=20 > matter, the point of origin is not necessarily fixed. Since=20 > either Alice or Bob can be exchanged for a different=20 > endpoint (or multiple endpoints), we need a mechanism that > is flexible enough to accommodate those changes. That's=20 > what our proposal was about from the start, but somehow the=20 > charter is interpreted more strictly and, as such, does not=20 > consider pre-answer situations or mid-call interactions. My understanding is that it is interpreted more strictly because of objecti= ons associated with the proposed charter which allowed the session identifi= er to change within a dialog. The current charter is significantly differe= nt from the one that "shocked" Cullen; however the items that were removed = are apparently still being addressed. http://www.ietf.org/mail-archive/web/dispatch/current/msg03821.html Thanks, Brett From pkyzivat@alum.mit.edu Wed Sep 5 07:35:12 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B55421F862B for ; Wed, 5 Sep 2012 07:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODraN2HOnulm for ; Wed, 5 Sep 2012 07:35:11 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id B19CA21F862A for ; Wed, 5 Sep 2012 07:35:11 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta02.westchester.pa.mail.comcast.net with comcast id vQ2G1j0080Fqzac51SbFgN; Wed, 05 Sep 2012 14:35:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id vSb71j00U3ZTu2S3USb7X5; Wed, 05 Sep 2012 14:35:07 +0000 Message-ID: <5047631D.9060202@alum.mit.edu> Date: Wed, 05 Sep 2012 10:35:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: insipid@ietf.org References: <201208272320.q7RNK69G010568@mtv-core-2.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B885FAC@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B885FAC@MBX06.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] 3.X. End-to-end identification of a communication session: evaluation X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:35:12 -0000 On 9/5/12 7:37 AM, Brett Tate wrote: >> 3.X. End-to-end identification of a communication session: >> >> SIP messaging that either does not involve SIP servers >> or only involves SIP proxies, the Call-ID: header value >> sufficiently identifies each SIP message within a >> transaction or dialog. This is not the case when either >> B2BUAs or SBCs are in the signaling path between UAs. >> Therefore, we need the ability to identify each >> communication session per transaction through a single >> SIP header-value regardless of which type of SIP servers >> are in the signaling path between UAs. For transactions >> that create a dialog, have each message within the same >> dialog MUST use the same identifier. > > If this item is added, I recommend that the last sentence be changed since it appears to conflict with other requirements to allow the identifier to change if the "end" changes. The following is an alternative to the last sentence; it is intentionally vague to allow the endpoint (B2BUA or otherwise) to change the identifier when deemed appropriate. > > "Concerning transactions that create a dialog, each message within the same dialog MUST use the same identifier unless the endpoint changes." The text as it was written is already weasle worded. It talks about *dialogs*. But when there are B2BUA middle boxes then there is not one dialog E2E. With one B2BUA there are two dialogs, etc. The use of *transaction* is even more dubious, since even proxies terminate a transaction and start another on the other side. (As the text was written, the call-id meets the requirement.) I think that the last sentence should have been written as: "For requests that create an end-to-end communication session, each message withing the end-to-end communication session MUST use the same identifier." And then I guess it is *that* which you propose to weaken. Perhaps to: "For requests that create an end-to-end communication session, each message withing the end-to-end communication session MUST use the same identifier as long as the endpoints remain unchanged." Thanks, Paul From gsalguei@cisco.com Wed Sep 5 22:43:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203B621F852E for ; Wed, 5 Sep 2012 22:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7MFDwujvmup for ; Wed, 5 Sep 2012 22:43:47 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6FA21F852B for ; Wed, 5 Sep 2012 22:43:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q865hkZ7001393 for ; Thu, 6 Sep 2012 01:43:46 -0400 (EDT) Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q865hkOs010177 for ; Thu, 6 Sep 2012 01:43:46 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Sep 2012 01:43:45 -0400 References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> To: insipid@ietf.org Message-Id: <0D429882-0BB7-428A-BD11-4E4A4449D9B5@cisco.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] Fwd: Help the NomCom: Nominations and Feedback X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 05:43:48 -0000 FYI Begin forwarded message: > From: NomCom Chair > Subject: Help the NomCom: Nominations and Feedback > Date: September 5, 2012 8:21:29 PM EDT > To: Working Group Chairs > > The IETF Nominations Committee (NomCom) is currently seeking > nominations for individuals to serve on the IESG, IAB, and IAOC. > Additionally, this is an announcement that the NomCom is seeking > feedback on individuals who have accepted nominations for IETF > leadership positions. > > It is very important to the NomCom process that we get input from a > broad spectrum of the community. Therefore, in case members of your > working group do not read the IETF announcement and discussion lists, > the NomCom would appreciate your help in disseminating the following > information. > > The NomCom website contains information about this year's NomCom > including the positions we are seeking to fill, and the qualifications > required for these positions: > > https://www.ietf.org/group/nomcom/2012/ > > The NomCom is accepting nominations until September 24. Nominations > for any position can be made using the following web tool: > > https://www.ietf.org/group/nomcom/2012/nominate > > Feedback about individuals who the NomCom is considering can be > providing using the following web tool: > > https://www.ietf.org/group/nomcom/2012/input > > The feedback tool provides a list of individuals who have agreed to be > considered for each position. We will be updating this list in the coming > weeks as more individuals accept nominations. > > Feedback provided to the NomCom is kept strictly confidential! > > Note that use of the NomCom web tools require an ietf.org (i.e., > datatracker) account. You can create an ietf.org account by visiting the > following URL: > > https://datatracker.ietf.org/accounts/create/ > > As an alternative to using the web tools, you can send email to the > NomCom at nomcom12@ietf.org to make a nomination or provide input to > the committee. > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org > From paulej@packetizer.com Fri Sep 7 16:42:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442B221F85C7 for ; Fri, 7 Sep 2012 16:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_PAIN=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpkT8I4YlmAw for ; Fri, 7 Sep 2012 16:42:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2649621F85C6 for ; Fri, 7 Sep 2012 16:42:33 -0700 (PDT) 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 q87NgQw3028485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Sep 2012 19:42:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1347061349; bh=vS+hfbgq2v664FlEAfhQynSM9KQX0ingmcvvqstPrio=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QOob3LaKccP2sHghgysRJDc4bGMWgAOL3kALuqli1uNm8fLCX/w7FEEn3fvOFR76N b4rXNhfzzM7t2jIKNt9NYvQYTeMGzeYXvyCmUyBjnQu2m87lO/ZaxsTks6kJt3oRPS zJLih2Uq49qm/5u3rXA/dxKkFnj/DlkJyd/O14m8= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'James Polk'" , "'Andrew Allen'" , References: , <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F55@ESESSCMS0356.eemea.ericsson.se>, <052401cd8656$5dc95f00$195c1d00$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F59@ESESSCMS0356.eemea.ericsson.se> <078e01cd87dd$23d02c60$6b708520$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340A461411@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A461411@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 7 Sep 2012 19:42:38 -0400 Message-ID: <053c01cd8d52$78420640$68c612c0$@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: AQKFof+u7rm5T9A76TKhojEtg9ODgAGf25OBAUpa5UoB0sHkvAJDQlBJARcmEVkCLkvm3wDVsjLKlbaEhjA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 23:42:34 -0000 Christer, There are two possible transfer examples. In one case, the PBX could just keep the same value, as it initiates the call to Carol. However, consider the two examples where it does not work: 1) Alice calls Bob. Carol calls Bob. Bob puts Alice on hold and talks to Carol for a moment. Bob then transfers the Bob/Carol call to Alice. What Session-ID it sent to Alice? What Session-ID is sent to Carol? Are these two values? (Note: in our proposal, Alice would always retain the UUID A and Carol the UUID C. After the transfer, the new "Sessio-ID" would be A || C (ordered).) 2) Alice calls Bob. Bob puts Alice on hold and calls Carol. Bob then transfers Alice to Carol. What Session-ID it sent to Alice? What Session-ID is sent to Carol? Are these two values? (Note: in our proposal, Alice would always retain the UUID A and Carol the UUID C. After the transfer, the new "Sessio-ID" would be A || C (ordered).) Note the same set of questions and we propose the same solution. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Wednesday, September 05, 2012 7:36 AM > To: Paul E. Jones; 'James Polk'; 'Andrew Allen'; shida@ntt-at.com > Cc: insipid@ietf.org > Subject: Re: [Insipid] Backward compability between draft-jones and draft- > kaplan > > Hi Paul, > > Just for me to understand the use-case a little better: is there a reason > why the PBX can't keep the same value when contacting Carol? > > Regards, > > Christer > > > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: 1. syyskuuta 2012 4:00 > To: Christer Holmberg; 'James Polk'; 'Andrew Allen'; shida@ntt-at.com > Cc: insipid@ietf.org > Subject: RE: [Insipid] Backward compability between draft-jones and draft- > kaplan > > Christer, > > > >Now, suppose Bob transfers the call with Alice to Carol. Bob's PBX > > >does the magic and Bob drops out of the call. Is it OK if the PBX > > >sends > > Alice this? > > > Session-ID: C; p=A > > > > > >This is a real-world scenario where two call legs are joined by the > PBX. > > > > What do you mean by "sends Alice this"? Do you mean that the > > session-id, on the exisiting dialog between Alice and the PBX, is > updated? > > Yes. The Session-ID changes from: > > Session-ID: A; p=B > To > Session-ID: C; p=A > > In this way, we still have a single Session-ID end-to-end (namely, A || C > or C || A, depending on how we order the values). However, the change in > the Session-ID from A || B to A || C is necessary to indicate that an end > device changed. > > If we do not allow for this, we do not have an end-to-end ID any longer. > We will have two IDs, one going into the PBX and one coming out. And that > defeats the purpose. > > So, the question is whether it's acceptable to make this change. If so, I > think we can go with a solution like that. The signaling will contain the > two UUID values, one representing each device, but the values might change > as described above. This is the best backward-compatible approach I can > think of and still ensure that, going forward, we have an ID we can see as > end-to-end for the duration of the call where the same two devices are in > direct communication. > > Paul > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From iesg-secretary@ietf.org Wed Sep 12 08:58:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE65D21F8602; Wed, 12 Sep 2012 08:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DF8MkgvCXuT8; Wed, 12 Sep 2012 08:58:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94B921F85EF; Wed, 12 Sep 2012 08:58:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120912155828.32148.17764.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 08:58:28 -0700 Cc: insipid@ietf.org Subject: [Insipid] INSIPID WG Virtual Interim Meeting: October 4, 2012 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:58:31 -0000 The INSIPID WG will be holding a virtual interim meeting on 4th October = 2012 at 9:00 AM Pacific / noon Eastern Daylight Time (GMT-4:00). The = duration will be 2 hours. The agenda will be posted to the INSIPID mailing list = (http://www.ietf.org/mail-archive/web/insipid/current/maillist.html) = pending further discussion on the list. From iesg-secretary@ietf.org Thu Sep 13 07:48:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C161C21F85A8; Thu, 13 Sep 2012 07:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ece5GhMyeVXb; Thu, 13 Sep 2012 07:48:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7082F21F853C; Thu, 13 Sep 2012 07:48:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120913144834.21256.22158.idtracker@ietfa.amsl.com> Date: Thu, 13 Sep 2012 07:48:34 -0700 Cc: insipid@ietf.org Subject: [Insipid] CORRECTED: INSIPID WG Virtual Interim Meeting: October 4, 2012 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 14:48:34 -0000 The INSIPID WG will be holding a virtual interim meeting on 4th October = 2012 at 9:00 AM Eastern Daylight Time (GMT-4:00). The duration will be 2 ho= urs. The agenda will be posted to the INSIPID mailing list = (http://www.ietf.org/mail-archive/web/insipid/current/maillist.html) = pending further discussion on the list. From paulej@packetizer.com Fri Sep 14 13:28:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1EB21F852B for ; Fri, 14 Sep 2012 13:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USxVCRrJ+-MY for ; Fri, 14 Sep 2012 13:28:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEE821F84EB for ; Fri, 14 Sep 2012 13:28:28 -0700 (PDT) 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 q8EKSNqT015440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Sep 2012 16:28:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1347654504; bh=+k69op0a/K1woHCDPaY1PjJWPljl7+OwlXri1x7cTHc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=aMZsZCjHGOe/8YV7RLS0K0A7PSeekURKf/64ASd2L+mqJiXGNIMRIjdxCmmf3/pPc 0RUoN7gS/u3KzaMWRtRKrozHzx/bkQ8vg86AREuF6FPQsS9/PyzWfRSI6fH18hT7fY iPeAMbtLrJ220GWZsyA3b/6h6vI5Vqb8zeq0JGA8= From: "Paul E. Jones" To: "'Paul Kyzivat'" , , "'Brett Tate'" References: <201208272320.q7RNK69G010568@mtv-core-2.cisco.com> <576A8B541C219D4E9CEB1DF8C19C7B885FAC@MBX06.citservers.local> <5047631D.9060202@alum.mit.edu> In-Reply-To: <5047631D.9060202@alum.mit.edu> Date: Fri, 14 Sep 2012 16:28:27 -0400 Message-ID: <007801cd92b7$801172b0$80345810$@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: AQJ4K5Kx7pxD5r8gXKu6dxj+8RfLLgH26qi5AYNe6U+WGUVrAA== Content-Language: en-us Subject: Re: [Insipid] 3.X. End-to-end identification of a communication session: evaluation X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 20:28:29 -0000 So, where are we on this one? > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, September 05, 2012 10:35 AM > To: insipid@ietf.org > Subject: Re: [Insipid] 3.X. End-to-end identification of a communication > session: evaluation > > On 9/5/12 7:37 AM, Brett Tate wrote: > >> 3.X. End-to-end identification of a communication session: > >> > >> SIP messaging that either does not involve SIP servers or only > >> involves SIP proxies, the Call-ID: header value sufficiently > >> identifies each SIP message within a transaction or dialog. This is > >> not the case when either B2BUAs or SBCs are in the signaling path > >> between UAs. > >> Therefore, we need the ability to identify each communication session > >> per transaction through a single SIP header-value regardless of which > >> type of SIP servers are in the signaling path between UAs. For > >> transactions that create a dialog, have each message within the same > >> dialog MUST use the same identifier. > > > > If this item is added, I recommend that the last sentence be changed > since it appears to conflict with other requirements to allow the > identifier to change if the "end" changes. The following is an > alternative to the last sentence; it is intentionally vague to allow the > endpoint (B2BUA or otherwise) to change the identifier when deemed > appropriate. > > > > "Concerning transactions that create a dialog, each message within the > same dialog MUST use the same identifier unless the endpoint changes." > > The text as it was written is already weasle worded. It talks about > *dialogs*. But when there are B2BUA middle boxes then there is not one > dialog E2E. With one B2BUA there are two dialogs, etc. The use of > *transaction* is even more dubious, since even proxies terminate a > transaction and start another on the other side. (As the text was written, > the call-id meets the requirement.) > > I think that the last sentence should have been written as: > > "For requests that create an end-to-end communication session, each > message withing the end-to-end communication session MUST use the same > identifier." > > And then I guess it is *that* which you propose to weaken. Perhaps to: > > "For requests that create an end-to-end communication session, each > message withing the end-to-end communication session MUST use the same > identifier as long as the endpoints remain unchanged." > > Thanks, > Paul > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From internet-drafts@ietf.org Fri Sep 14 14:35:53 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE3721F8578; Fri, 14 Sep 2012 14:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s1XOztZS1Dv; Fri, 14 Sep 2012 14:35:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0021F8557; Fri, 14 Sep 2012 14:35:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914213553.3298.5463.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 14:35:53 -0700 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-reqts-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:35:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : Requirements for an End-to-End Session Identification in= IP-Based Multimedia Communication Networks Author(s) : Paul E. Jones Gonzalo Salgueiro James Polk Laura Liess Hadriel Kaplan Filename : draft-ietf-insipid-session-id-reqts-01.txt Pages : 11 Date : 2012-09-14 Abstract: This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-reqts-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Fri Sep 14 14:39:12 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7B21F8568 for ; Fri, 14 Sep 2012 14:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-t5O2-MUFZF for ; Fri, 14 Sep 2012 14:39:11 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D429D21F8554 for ; Fri, 14 Sep 2012 14:39:10 -0700 (PDT) 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 q8ELdAKG020652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Sep 2012 17:39:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1347658750; bh=Asz+z63FWIkTWunqI/isPqcCDIn9ZLavW6Z97lRl8ZQ=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=GTWspvirTUJ5lfU8JQYmP5r7R8zzLL9eCnmGIXiOrerhxrFUE3eRprCOUagH5sXyI 2vBPWMC1JM7chnE0PH9loIVXI2QMa/SOAannhzcb4c1t+4e/Y4SD1DGhQrbfjSJs2W lwrT+rSvhFnECfVx/eygcV4bZKD6x+6DjXhEtfdo= From: "Paul E. Jones" To: Date: Fri, 14 Sep 2012 17:39:14 -0400 Message-ID: <007f01cd92c1$62b4c550$281e4ff0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01CD929F.DBA37370" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2SwQqtQrj8zMKAQOKopmKi/o4/mw== Content-Language: en-us Subject: [Insipid] Revised Draft Posted X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:39:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0080_01CD929F.DBA37370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, In an effort to try to move things along, I have posted a new -01 version of the draft. I'd like to solicit feedback on the precise wording of the document, issues, etc. James posted all of the use case text to the list, but there was little dialog. Perhaps the section numbers might help. Perhaps seeing it posted might help, too. If we can reach some quick agreements on text changes, I'll publish a -02 version next week. Paul ------=_NextPart_000_0080_01CD929F.DBA37370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

In an effort = to try to move things along, I have posted a new -01 version of the = draft.  I’d like to solicit feedback on the precise wording = of the document, issues, etc.  James posted all of the use case = text to the list, but there was little dialog.

 

Perhaps the = section numbers might help.  Perhaps seeing it posted might help, = too.

 

If we can reach some quick agreements on text changes, = I’ll publish a -02 version next week.

 

Paul

 

------=_NextPart_000_0080_01CD929F.DBA37370-- From gsalguei@cisco.com Mon Sep 17 04:23:35 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9CC21F8607 for ; Mon, 17 Sep 2012 04:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcP7s6rpttl0 for ; Mon, 17 Sep 2012 04:23:35 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id DD51921F8604 for ; Mon, 17 Sep 2012 04:23:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from shindeshi.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8HBNX4q009282 for ; Mon, 17 Sep 2012 20:23:33 +0900 (JST) Received: from [64.103.236.233] ([64.103.236.233]) by shindeshi.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8HBNWvH012369 for ; Mon, 17 Sep 2012 20:23:32 +0900 (JST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Gonzalo Salgueiro In-Reply-To: <7E68A25E-78E0-4628-AB99-7420AB9B79B2@cisco.com> Date: Mon, 17 Sep 2012 07:23:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7AE74687-CFFA-4C22-97DA-2C0B07152B74@cisco.com> References: <0CD60541-DA01-4A16-9D98-1F1927DBB408@cisco.com> <657AD091-25A8-4F52-BD58-ADEE2833DD58@cisco.com> <7E68A25E-78E0-4628-AB99-7420AB9B79B2@cisco.com> To: insipid@ietf.org X-Mailer: Apple Mail (2.1278) Subject: Re: [Insipid] INSIPID Virtual Interim Doodle Poll X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 11:23:36 -0000 Webex details for the upcoming INSIPID Virtual Interim on October 4th at = 9:00 AM EDT (GMT -4:00) / 6:00 AM PDT (GMT -7:00): Topic: INSIPID WG Virtual Interim=20 Date: Thursday, October 4, 2012=20 Time: 5:45 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 644 749 678=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://ietf.webex.com/ietf/j.php?ED=3D160232632&UID=3D1272813422&PW=3DNMz= E0MjdiZWUy&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 = https://ietf.webex.com/ietf/j.php?ED=3D160232632&UID=3D1272813422&PW=3DNMz= E0MjdiZWUy&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 Call-in toll number (US/Canada): +1-408-600-3600=20 Access code:644 749 678=20 On Sep 4, 2012, at 10:42 PM, Gonzalo Salgueiro wrote: > Poll is now closed.=20 >=20 > The next INSIPID Virtual Interim will be on October 4th at 9:00 AM EDT = (GMT -4:00) / 6:00 AM PDT (GMT -7:00) and will be a 2 hour meeting. >=20 > Webex details to follow (once Secretariat provides them). >=20 > Cheers, >=20 > Gonzalo & Keith >=20 >=20 > On Aug 28, 2012, at 12:02 AM, Gonzalo Salgueiro wrote: >=20 >> Reminder that the poll closes this Friday. Please indicate your = preference for the INSIPID virtual interim. >>=20 >> --Gonzalo >>=20 >>=20 >> On Aug 16, 2012, at 1:28 AM, Gonzalo Salgueiro wrote: >>=20 >>> Folks -=20 >>>=20 >>> As decided at IETF84 the INSIPID WG is planning a virtual interim = meeting in an attempt to comply with the milestone deadlines. Please = indicate your date/time preferences by the end of Friday, August 31. We = have offered a diverse selection of times during the weeks of September = 24 and October 1 to try and accommodate most. If you think other times = should be added to the poll, let the chairs knows. >>>=20 >>> This will be a 2 hour long webex meeting (I'll send out meeting = details once we converge on a date/time). >>>=20 >>> Please indicate your availability at: >>>=20 >>> http://doodle.com/ry7uz4ka5cpne7hi >>>=20 >>> The times specified on the poll are EDT (GMT -4:00) but it should be = intelligent enough to translate to your local time. >>>=20 >>> We're still working on the agenda, but we assume that we'll try to = close on open issues on the requirements draft as well as work towards = acceptable base text for a solution the WG can adopt. >>>=20 >>> Cheers, >>>=20 >>> Gonzalo and Keith >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >>=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From ietf-ipr@ietf.org Tue Sep 18 20:45:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6921E8096; Tue, 18 Sep 2012 20:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNszLBxeWwFF; Tue, 18 Sep 2012 20:45:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1B11E80E8; Tue, 18 Sep 2012 20:45:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: paulej@packetizer.com, gsalguei@cisco.com, jmpolk@cisco.com, laura.liess.dt@gmail.com, hkaplan@acmepacket.com X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919034528.26798.76410.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 20:45:28 -0700 X-Mailman-Approved-At: Wed, 19 Sep 2012 02:14:00 -0700 Cc: keith.drage@alcatel-lucent.com, gsalguei@cisco.com, gonzalo.camarillo@ericsson.com, insipid@ietf.org, ipr-announce@ietf.org, rjsparks@nostrum.com Subject: [Insipid] IPR Disclosure: Dean Willis' Statement about IPR related to draft-ietf-insipid-session-id-reqts-01 and Product of INSIPID Working Group belonging to Telefonaktiebolaget LM Ericsson (publ) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 03:45:29 -0000 Dear Paul Jones, Gonzalo Salgueiro, James M. Polk, Laura Liess, Hadriel Kap= lan: An IPR disclosure that pertains to your Internet-Draft entitled "Requireme= nts for an End-to-End Session Identification in IP-Based Multimedia Communicati= on Networks" (draft-ietf-insipid-session-id-reqts) was submitted to the IETF Secretariat on 2012-09-18 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1882/). The = title of the IPR disclosure is "Dean Willis' Statement about IPR related to draft- ietf-insipid-session-id-reqts-01 and Product of INSIPID Working Group belon= ging to Telefonaktiebolaget LM Ericsson (publ).""); The IETF Secretariat From ietf-ipr@ietf.org Tue Sep 18 20:46:24 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9710321E809A; Tue, 18 Sep 2012 20:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1yBbcXBx8AV; Tue, 18 Sep 2012 20:46:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E611E80E7; Tue, 18 Sep 2012 20:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: paulej@packetizer.com, gsalguei@cisco.com, jmpolk@cisco.com, laura.liess.dt@gmail.com, hkaplan@acmepacket.com X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919034624.15068.76215.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 20:46:24 -0700 X-Mailman-Approved-At: Wed, 19 Sep 2012 02:14:09 -0700 Cc: keith.drage@alcatel-lucent.com, gsalguei@cisco.com, gonzalo.camarillo@ericsson.com, insipid@ietf.org, ipr-announce@ietf.org, rjsparks@nostrum.com Subject: [Insipid] IPR Disclosure: Dean Willis' Statement about IPR related to draft-ietf-insipid-session-id-reqts-01 and Product of INSIPID Working Group belonging to Cable television Labs, Inc. X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 03:46:24 -0000 Dear Paul Jones, Gonzalo Salgueiro, James M. Polk, Laura Liess, Hadriel Kap= lan: An IPR disclosure that pertains to your Internet-Draft entitled "Requireme= nts for an End-to-End Session Identification in IP-Based Multimedia Communicati= on Networks" (draft-ietf-insipid-session-id-reqts) was submitted to the IETF Secretariat on 2012-09-18 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1883/). The = title of the IPR disclosure is "Dean Willis' Statement about IPR related to draft- ietf-insipid-session-id-reqts-01 and Product of INSIPID Working Group belon= ging to Cable television Labs, Inc..""); The IETF Secretariat From gsalguei@cisco.com Wed Sep 26 10:11:14 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8F021F85A0 for ; Wed, 26 Sep 2012 10:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CliFPo1lgPGC for ; Wed, 26 Sep 2012 10:11:13 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7921F8433 for ; Wed, 26 Sep 2012 10:11:13 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8QHBB2P002195 for ; Wed, 26 Sep 2012 13:11:11 -0400 (EDT) Received: from dhcp-64-102-154-202.cisco.com (dhcp-64-102-154-202.cisco.com [64.102.154.202]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8QHBB7m020941 for ; Wed, 26 Sep 2012 13:11:11 -0400 (EDT) From: Gonzalo Salgueiro Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_EBC6E3B1-80A9-48F2-AE65-C77FAB345D05" Date: Wed, 26 Sep 2012 13:11:11 -0400 In-Reply-To: <92F65FB9-2DC6-4EFE-8ADC-947C58BDE250@cisco.com> To: insipid@ietf.org References: <92F65FB9-2DC6-4EFE-8ADC-947C58BDE250@cisco.com> Message-Id: <1B812857-1588-4515-A940-294FBA4A37AF@cisco.com> X-Mailer: Apple Mail (2.1283) Subject: [Insipid] INSIPID WG Virtual Interim Meeting: Agenda & Dial-in details X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:11:14 -0000 --Apple-Mail=_EBC6E3B1-80A9-48F2-AE65-C77FAB345D05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks -=20 We will use Webex to host the INSIPID Virtual Interim meeting on October = 4th at 9:00 AM EDT (GMT -4:00) / 6:00 AM PDT (GMT -7:00). Duration 2 = hours.=20 See below for the proposed agenda and "dial-in" details.=20 Please feel free to bash the agenda and let the chairs know whether you = feel someone else should be speaking or if a topic has been omitted or = mis-represented. Cheers, Gonzalo & Keith -------------------------------------------------------- Agenda: 1) Note well, agenda bash, notetakers, etc. - Chairs (5 min) 2) Discussion of requirements draft: use cases (cont'd) - Paul Jones, = James Polk (45 min) draft-ietf-insipid-session-id-reqts-01 = http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-01 3) Discussion of requirements draft: requirements (cont'd) - Paul Jones, = James Polk (15 min) draft-ietf-insipid-session-id-reqts-01 = http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-01 4) Proposed solution discussion - various (50 min) (a) Discussion on backwards compatibility to Kaplan draft - = Christer Holmberg (20 minutes) (b) Discussion of proposed session id solution (conclusion of = Vancouver presentation) - Paul Jones, James Polk (30 min) draft-jones-insipid-session-id-00 = http://tools.ietf.org/html/draft-jones-insipid-session-id-00 [Note: We encourage folks to submit any candidate solutions for session = id that they wish to be considered by the WG] 4) Next steps - Chairs (5 min) -------------------------------------------------------- Webex details for the upcoming INSIPID Virtual Interim on October 4th at = 9:00 AM EDT (GMT -4:00) / 6:00 AM PDT (GMT -7:00): Topic: INSIPID WG Virtual Interim=20 Date: Thursday, October 4, 2012=20 Time: 5:45 am, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 644 749 678=20 Meeting Password: 1234=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://ietf.webex.com/ietf/j.php?ED=3D160232632&UID=3D1272813422&PW=3DNMz= E0MjdiZWUy&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: 1234=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 = https://ietf.webex.com/ietf/j.php?ED=3D160232632&UID=3D1272813422&PW=3DNMz= E0MjdiZWUy&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 Call-in toll number (US/Canada): +1-408-600-3600=20 Access code:644 749 678=20 --Apple-Mail=_EBC6E3B1-80A9-48F2-AE65-C77FAB345D05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks - 

We = will use Webex to host the INSIPID Virtual Interim meeting on October = 4th at 9:00 AM EDT (GMT -4:00) / 6:00 AM PDT (GMT -7:00). Duration 2 = hours. 

See below for the proposed agenda and = "dial-in" details. 

Please feel free to = bash the agenda and let the chairs know whether you feel someone else = should be speaking or if a topic has been omitted or = mis-represented.

Cheers,

Gonzalo & Keith

-----------------------------------------------= ---------
Agenda:

1) = Note well, agenda bash, notetakers, etc. - Chairs (5 min)

2) = Discussion of requirements draft: use cases (cont'd) - Paul Jones, James = Polk (45 min)

= draft-ietf-insipid-session-id-reqts-01

3) Discussion of = requirements draft: requirements (cont'd) - Paul Jones, James Polk (15 = min)

= draft-ietf-insipid-session-id-reqts-01

4) Proposed solution discussion - various (50 = min)

(a) Discussion on backwards = compatibility to Kaplan draft - Christer Holmberg (20 = minutes)

(b) Discussion of proposed = session id solution (conclusion of Vancouver presentation) - Paul = Jones, James Polk (30 min)

= draft-jones-insipid-session-id-00

[Note: We encourage = folks to submit any candidate solutions for session id that they wish to = be considered by the WG]

4) Next steps - Chairs (5 min)

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

Webex details for the upcoming INSIPID = Virtual Interim on October 4th at 9:00 AM EDT (GMT -4:00) / 6:00 AM PDT = (GMT -7:00):


Topic: INSIPID WG Virtual Interim 
Date: = Thursday, October 4, 2012 
Time: 5:45 am, Pacific Daylight Time = (San Francisco, GMT-07:00) 
Meeting Number: 644 749 = 678 
Meeting Password: = 1234 


----------------------------------------------------= --- 
To join the online meeting (Now from mobile = devices!) 
-------------------------------------------------------=  
1. Go to https://ietf.webex.com/ietf/j.ph= p?ED=3D160232632&UID=3D1272813422&PW=3DNMzE0MjdiZWUy&RT=3DMiM0=  
2. If requested, enter your name and email = address. 
3. If a password is required, enter the meeting = password: 1234 
4. Click "Join". 

To view in other = time zones or languages, please click the link: 
https://ietf.webex.com/ietf/j.p= hp?ED=3D160232632&UID=3D1272813422&PW=3DNMzE0MjdiZWUy&ORT=3DMi= M0 

------------------------------------------------------= - 
To join the audio conference = only 
------------------------------------------------------- = ;
Call-in toll number (US/Canada): = +1-408-600-3600 

Access code:644 749 = 678 
= --Apple-Mail=_EBC6E3B1-80A9-48F2-AE65-C77FAB345D05-- From keith.drage@alcatel-lucent.com Thu Sep 27 09:59:41 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7221F84F8 for ; Thu, 27 Sep 2012 09:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRjVSJXgEPpi for ; Thu, 27 Sep 2012 09:59:41 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id F03B221F859C for ; Thu, 27 Sep 2012 09:59:40 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8RGxbId000990 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 27 Sep 2012 18:59:37 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 27 Sep 2012 18:59:37 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Thu, 27 Sep 2012 18:59:36 +0200 Thread-Topic: Scoping of the insipid work and impact on use cases Thread-Index: Ac2c0XmLA9+ZbBCkQfGlGW16W8H+jA== Message-ID: 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.84 Subject: [Insipid] Scoping of the insipid work and impact on use cases X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 16:59:42 -0000 The chairs and the AD went through the slides presented to the Vancouver me= eting that can be found here http://www.ietf.org/proceedings/84/slides/slides-84-insipid-0.pptx=20 James Polk also posted the contents of these slides to the list in various = messages on 28th August. I have now also tried to correlate that review to the current -01 version o= f the requirements document. Obviously if this is followed, and out AD will insist that it is, it remove= s the justification for some on the requirements, and we will need to work = through that on the virtual interim. Slide 4: Session-ID old Use-cases (1/2) -------------------------------------- No issues Slide 5: Session-ID old Use-cases (2/2) --------------------------------------- No issues Slide 6: Session-ID retained Use-cases (1/2) -------------------------------------------- Out of scope because conferencing is out of scope. 3.2 in in -01 version of requirements i-d. Note, no formal SIPREC requirements have been identified. Slide 7: Session-ID retained Use-cases (1/2) -------------------------------------------- No issues identified Slide 8: Session-ID new Use-cases (1/8): 3.X End-to-end identification of= a communication session --------------------------------------------------------------------------- Now section 3.1 in -01 version of requirements i-d. One in, one out. No issues identified. This may be the source of some of the confusion about 3PCC. I think the one= in, one out configuration is 3PCC, but it is not one of the scenarions ide= ntified in RFC 3725. Slide 9: Session-ID new Use-cases (2/8): 3.X Identification of devices ta= king part in the same multipoint Conference --------------------------------------------------------------------------- Now section 3.5 in -01 version of requirements i-d. Out of scope, conferences not covered. Slide 10: Session-ID new Use-cases (3/8): 3.X Tracking sessions transferr= ed from one endpoint to another --------------------------------------------------------------------------- Now section 3.6 in -01 version of requirements i-d. Formally REFER etc, is out of scope, however... Explore the issues - cannot avoid someone putting an INSIPID identifier in = a REFER contents, so need to say what occurs when it happens. Slide 11: Session-ID new Use-cases (4/8): 3.X Session Signal Logging ---------------------------------------------------------------------- Now section 3.7 in -01 version of requirements i-d. Slim down only to debugging. Accounting and billing are out of scope. Slide 12: Session-ID new Use-cases (5/8): 3.X Identifier Porting to Other= Protocols - RSVP --------------------------------------------------------------------------- While such interworking is not in scope, obviously, if an implementor wants= to subsequently do this, it is not precluded. Slide 13: Session-ID new Use-cases (6/8): 3.X Identifier Porting to Other= Protocols - RTCP --------------------------------------------------------------------------- Keep use case based on discussion in Vancouver meeting. Now section 3.8 in -01 version of requirements i-d. Slide 14: Session-ID new Use-cases (7/8): 3.X Traffic Monitoring ---------------------------------------------------------------- Section 3.4 in -01 version of requirements i-d As slide 8 Slide 15: Session-ID new Use-cases (8/8): 3.X 3PCC Use Case. ------------------------------------------------------------- Now section 3.9 in -01 version of requirements i-d. All RFC 3725 use cases are out of scope. Regards Keith From paulej@packetizer.com Thu Sep 27 16:33:51 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BA221F84CD for ; Thu, 27 Sep 2012 16:33:51 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz8b8mAM+ZGk for ; Thu, 27 Sep 2012 16:33:50 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 221CD21F84C5 for ; Thu, 27 Sep 2012 16:33:50 -0700 (PDT) Received: from [131.181.20.110] ([131.181.20.110]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q8RNXixt006090 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Sep 2012 19:33:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1348788828; bh=/z0AcXSAxqCHNifaNw4RiZhu8XeU57eyawaESmLG99s=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kA9PVroBQuYaMbwffp3xb4j8KaVb5caAb9opoN8oDPeWDKMVDR/HyyXOLJyCOkk2J +VsXl2u8n5hFq1/70J8A4LUaSvDpFSZRSxn2NGp4LDR5K02Vu63OIHkMHKPpSX5FsP vlI3a+DKV6Kvy0ixdSpIacAHxBb/UHNPCZXyAFN8= Message-ID: <5064E25C.20206@packetizer.com> Date: Thu, 27 Sep 2012 19:33:48 -0400 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" Subject: Re: [Insipid] Scoping of the insipid work and impact on use cases X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 23:33:51 -0000 Keith, I can understand the argument that conferencing is out. I viewed that as a "freebie" given the way we had constructed the Session-ID. Also, it was not perfect, since one could not tell if two devices shared a half-key value because they are in a conference together or because one call leg is being transferred or joined with another. What it did, though, was clearly indicate that two sessions were somehow related. I think that is what was most important. I didn't care to know with 100% certainty that two sessions are in a conference together, but I did want to know that the was some relationship. Thus, the reason for recommending that MCUs use the same Session-ID-UUID. Call transfer can come in multiple forms, including a REFER and a local "join" on a PBX. This one is vital. If Alice calls Bob and Carol call Bob, there are two session-IDs. Then if Bob does something such that Alice and Carol are now communicating and Bob drops out, what is the Session-ID between Alice and Carol? What we proposed would answer that question consistently. I'm rather concerned that the transfer / "call join" use cases might be declared out of scope. Cullen assured us this was not the case before. Can you clarify? Paul On 9/27/2012 12:59 PM, DRAGE, Keith (Keith) wrote: > The chairs and the AD went through the slides presented to the Vancouver meeting that can be found here > > http://www.ietf.org/proceedings/84/slides/slides-84-insipid-0.pptx > > James Polk also posted the contents of these slides to the list in various messages on 28th August. > > I have now also tried to correlate that review to the current -01 version of the requirements document. > > Obviously if this is followed, and out AD will insist that it is, it removes the justification for some on the requirements, and we will need to work through that on the virtual interim. > > Slide 4: Session-ID old Use-cases (1/2) > -------------------------------------- > > No issues > > Slide 5: Session-ID old Use-cases (2/2) > --------------------------------------- > > No issues > > Slide 6: Session-ID retained Use-cases (1/2) > -------------------------------------------- > > Out of scope because conferencing is out of scope. > > 3.2 in in -01 version of requirements i-d. > > Note, no formal SIPREC requirements have been identified. > > Slide 7: Session-ID retained Use-cases (1/2) > -------------------------------------------- > > No issues identified > > Slide 8: Session-ID new Use-cases (1/8): 3.X End-to-end identification of a communication session > --------------------------------------------------------------------------- > > Now section 3.1 in -01 version of requirements i-d. > > One in, one out. > > No issues identified. > > This may be the source of some of the confusion about 3PCC. I think the one in, one out configuration is 3PCC, but it is not one of the scenarions identified in RFC 3725. > > Slide 9: Session-ID new Use-cases (2/8): 3.X Identification of devices taking part in the same multipoint Conference > --------------------------------------------------------------------------- > > Now section 3.5 in -01 version of requirements i-d. > > Out of scope, conferences not covered. > > Slide 10: Session-ID new Use-cases (3/8): 3.X Tracking sessions transferred from one endpoint to another > --------------------------------------------------------------------------- > > Now section 3.6 in -01 version of requirements i-d. > > Formally REFER etc, is out of scope, however... > > Explore the issues - cannot avoid someone putting an INSIPID identifier in a REFER contents, so need to say what occurs when it happens. > > Slide 11: Session-ID new Use-cases (4/8): 3.X Session Signal Logging > ---------------------------------------------------------------------- > > Now section 3.7 in -01 version of requirements i-d. > > Slim down only to debugging. Accounting and billing are out of scope. > > Slide 12: Session-ID new Use-cases (5/8): 3.X Identifier Porting to Other Protocols - RSVP > --------------------------------------------------------------------------- > > While such interworking is not in scope, obviously, if an implementor wants to subsequently do this, it is not precluded. > > Slide 13: Session-ID new Use-cases (6/8): 3.X Identifier Porting to Other Protocols - RTCP > --------------------------------------------------------------------------- > > Keep use case based on discussion in Vancouver meeting. > > Now section 3.8 in -01 version of requirements i-d. > > Slide 14: Session-ID new Use-cases (7/8): 3.X Traffic Monitoring > ---------------------------------------------------------------- > > Section 3.4 in -01 version of requirements i-d > > As slide 8 > > Slide 15: Session-ID new Use-cases (8/8): 3.X 3PCC Use Case. > ------------------------------------------------------------- > > Now section 3.9 in -01 version of requirements i-d. > > All RFC 3725 use cases are out of scope. > > Regards > > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid