From keith.drage@alcatel-lucent.com Fri Aug 3 12:04: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 3A3A621F8DAB for ; Fri, 3 Aug 2012 12:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.818 X-Spam-Level: X-Spam-Status: No, score=-109.818 tagged_above=-999 required=5 tests=[AWL=0.431, 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 WhaSUegoQ1Ql for ; Fri, 3 Aug 2012 12:04:11 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7116921F8D5A for ; Fri, 3 Aug 2012 12:04:11 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q73J4A7W027560 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 3 Aug 2012 21:04:10 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 3 Aug 2012 21:04:10 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Fri, 3 Aug 2012 21:04:09 +0200 Thread-Topic: Is session ID in conference in scope of the WG Thread-Index: Ac1xod4iQcE28BAjSii2gJBArSeByQ== 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.13 Subject: [Insipid] Is session ID in conference in scope of the WG 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, 03 Aug 2012 19:04:12 -0000 [As WG cochair] The chairs and the associated AD (Gonzalo) discussed this and came to the c= onclusion that creation of an identifier that is preserved across conferenc= es is out of scope according to the INSIPID working group charter. The reasoning for this is that the charter is bound to problem space for wh= ich a common To/From header field is used. We will therefore not include a conferencing use case, or attempt to derive= requirements from one. By the same argument, transfers are also out of scope at first sight, but t= he To and From headers are preserved in the Refer so it can be argued from = that perspective that it is in scope.=20 So we will continue to include the transfer use case. Obviously discussion of this is allowed, but please remember that any such = discussion is likely to a rechartering discussion (with consequent delay) r= ather than a discussion on the contents of the requirements document. Regards Keith From keith.drage@alcatel-lucent.com Sat Aug 4 11:12:25 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 2E57921F87D4 for ; Sat, 4 Aug 2012 11:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.833 X-Spam-Level: X-Spam-Status: No, score=-109.833 tagged_above=-999 required=5 tests=[AWL=0.416, 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 ZHIcRwWWZOHp for ; Sat, 4 Aug 2012 11:12:24 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B3B1721F86DF for ; Sat, 4 Aug 2012 11:12:20 -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 q74ICJ0M028107 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 4 Aug 2012 20:12:19 +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; Sat, 4 Aug 2012 20:12:19 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Sat, 4 Aug 2012 20:12:18 +0200 Thread-Topic: Is session ID in conference in scope of the WG Thread-Index: Ac1xod4iQcE28BAjSii2gJBArSeByQAwtD/w 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: Re: [Insipid] Is session ID in conference in scope of the WG 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: Sat, 04 Aug 2012 18:12:25 -0000 (As WG cochair) I have been asked about the third-party call controller cases. They have to fall for the same reason as the conference case.=20 The only use case that survives on the one in / one out case where the To/F= rom header fields could have been preserved. Regards Keith > -----Original Message----- > From: DRAGE, Keith (Keith) > Sent: 03 August 2012 19:00 > To: insipid@ietf.org > Subject: Is session ID in conference in scope of the WG >=20 > [As WG cochair] >=20 > The chairs and the associated AD (Gonzalo) discussed this and came to the > conclusion that creation of an identifier that is preserved across > conferences is out of scope according to the INSIPID working group charte= r. >=20 > The reasoning for this is that the charter is bound to problem space for > which a common To/From header field is used. >=20 > We will therefore not include a conferencing use case, or attempt to > derive requirements from one. >=20 > By the same argument, transfers are also out of scope at first sight, but > the To and From headers are preserved in the Refer so it can be argued > from that perspective that it is in scope. >=20 > So we will continue to include the transfer use case. >=20 > Obviously discussion of this is allowed, but please remember that any suc= h > discussion is likely to a rechartering discussion (with consequent delay) > rather than a discussion on the contents of the requirements document. >=20 > Regards >=20 > Keith From gonzalo.camarillo@ericsson.com Sun Aug 5 11:22: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 B5BEE21F854F for ; Sun, 5 Aug 2012 11:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 V-Jnd0KL2ftP for ; Sun, 5 Aug 2012 11:22:35 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A81EB21F854D for ; Sun, 5 Aug 2012 11:22:34 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-79-501eb9e98e78 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id ED.5D.12641.9E9BE105; Sun, 5 Aug 2012 20:22:33 +0200 (CEST) Received: from [131.160.126.136] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.0; Sun, 5 Aug 2012 20:22:32 +0200 Message-ID: <501EB9DF.1010403@ericsson.com> Date: Sun, 5 Aug 2012 21:22:23 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvre7LnXIBBk07+Szm33/GZPG08Syj A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpY0dTFWNAvUDHrRQ9jA+Mjni5GTg4JAROJ jdums0HYYhIX7q0Hsrk4hAROMUpM+dLKCuGsYZQ41vefEaSKV0Bb4tO3ryxdjBwcLAIqEjvv +IOE2QQsJLbcus8CYosKBEo8n72FHaJcUOLkzCdgcREBa4lXj7eALWMW0JRYsfg2WI2wgKvE oWP32EBGCgnESqy9EQVicgrESez6KQBiSghIStw+kALRqCcx5WoLI4QtL7H97RxmEFsI6K7l z1pYJjAKzUKydxaSlllIWhYwMq9iFM5NzMxJLzfXSy3KTC4uzs/TK07dxAgM3oNbfhvsYNx0 X+wQozQHi5I4r57qfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjLOapF2u39TJ4524IP9V j5Aef7fGkSwz3eb+xnoG3TznjPBvvYyL3h9kWlG37FtNveDupuLO7Ok3Lxpt7ZW4drjbLXJG q13epY51EexVZWerXP+d+uZqHjFZxtfRp2bFXG7FX1O5PqzweLPERvzDKncJ6b9bJA6+vjat RVDkZOGDrLjt+RVaSizFGYmGWsxFxYkAliMutSwCAAA= Cc: "insipid@ietf.org" Subject: Re: [Insipid] Is session ID in conference in scope of the WG 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: Sun, 05 Aug 2012 18:22:35 -0000 Hi, people may want to re-read the discussions we had about the scope of this WG when we were working on the charter (e.g., the thread with subject "[dispatch] new charter version for Session-id" on the DISPATCH mailing list) in order to get some background on what was discussed at that point. Cheers, Gonzalo On 04/08/2012 9:12 PM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > I have been asked about the third-party call controller cases. > > They have to fall for the same reason as the conference case. > > The only use case that survives on the one in / one out case where the To/From header fields could have been preserved. > > Regards > > Keith > > >> -----Original Message----- >> From: DRAGE, Keith (Keith) >> Sent: 03 August 2012 19:00 >> To: insipid@ietf.org >> Subject: Is session ID in conference in scope of the WG >> >> [As WG cochair] >> >> The chairs and the associated AD (Gonzalo) discussed this and came to the >> conclusion that creation of an identifier that is preserved across >> conferences is out of scope according to the INSIPID working group charter. >> >> The reasoning for this is that the charter is bound to problem space for >> which a common To/From header field is used. >> >> We will therefore not include a conferencing use case, or attempt to >> derive requirements from one. >> >> By the same argument, transfers are also out of scope at first sight, but >> the To and From headers are preserved in the Refer so it can be argued >> from that perspective that it is in scope. >> >> So we will continue to include the transfer use case. >> >> Obviously discussion of this is allowed, but please remember that any such >> discussion is likely to a rechartering discussion (with consequent delay) >> rather than a discussion on the contents of the requirements document. >> >> Regards >> >> Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > > From gsalguei@cisco.com Mon Aug 6 13:39: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 3DAB211E80E5 for ; Mon, 6 Aug 2012 13:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.872 X-Spam-Level: X-Spam-Status: No, score=-6.872 tagged_above=-999 required=5 tests=[AWL=3.727, BAYES_00=-2.599, 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 m8lFt5+Y6IXi for ; Mon, 6 Aug 2012 13:39:30 -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 8CD9311E80A6 for ; Mon, 6 Aug 2012 13:39:30 -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 q76KdTUJ006625 for ; Mon, 6 Aug 2012 16:39:30 -0400 (EDT) Received: from dhcp-64-102-154-155.cisco.com (dhcp-64-102-154-155.cisco.com [64.102.154.155]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q76KdTvT010947 for ; Mon, 6 Aug 2012 16:39:29 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 6 Aug 2012 16:39:29 -0400 Message-Id: <6BB23DB4-67B1-4EC7-8BF4-169A703E49D8@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] Minutes of the INSIPID meeting at IETF84 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, 06 Aug 2012 20:39:31 -0000 [As WG co-chair] The minutes from the INSIPID meeting at IETF84 in Vancouver are available at: http://www.ietf.org/proceedings/84/minutes/minutes-84-insipid Please review and comment if anything is incorrect or omitted. Thanks to all for attending! Cheers, Gonzalo & Keith From jmpolk@cisco.com Mon Aug 6 16:17: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 A1AE411E80DF for ; Mon, 6 Aug 2012 16:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 16nQhAruXOxy for ; Mon, 6 Aug 2012 16:17:23 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC111E80A5 for ; Mon, 6 Aug 2012 16:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2665; q=dns/txt; s=iport; t=1344295043; x=1345504643; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=qSNyLmEJQn2TYdaqnsFOmUP1gZjP7B1MZyACHFmQiSk=; b=SH9XkOTH/KnL6qrxZS0fwe9xHxqP8FR7AI13FdzuNiV2GWODZ67ZFRVN uxsZUwTyrvEheRWvo/VbvWnVvtvr81aSX55QumvOWavblPTXMq0Cx0Ymq isUz30mGGr+oCs+uWKm2Pds0qS5I+c78ckz4L3ZB2C9ViI3/4hNhp+jZq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOZPIFCrRDoI/2dsb2JhbABFuU+BB4IgAQEBBAEBAQ8BJQIuBgsMBAcEEQQBAQEeEBkOKAgGCgkih2oMmwigMASLSoZtA4hNmyKBZoJ9 X-IronPort-AV: E=Sophos;i="4.77,722,1336348800"; d="scan'208";a="54192351" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 06 Aug 2012 23:17:23 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q76NHMnl014862; Mon, 6 Aug 2012 23:17:22 GMT Message-Id: <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Aug 2012 18:17:21 -0500 To: Gonzalo Camarillo , "DRAGE, Keith (Keith)" From: James Polk In-Reply-To: <501EB9DF.1010403@ericsson.com> References: <501EB9DF.1010403@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" Subject: Re: [Insipid] Is session ID in conference in scope of the WG 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, 06 Aug 2012 23:17:24 -0000 At 01:22 PM 8/5/2012, Gonzalo Camarillo wrote: >Hi, > >people may want to re-read the discussions we had about the scope of >this WG when we were working on the charter (e.g., the thread with >subject "[dispatch] new charter version for Session-id" on the DISPATCH >mailing list) in order to get some background on what was discussed at >that point. I don't remember 3PCC ever being discussed then, therefore it would be out fo scope implicitly (but I have come to believe this is a good use-case we should include), but transfer was always talked about as something we include, now it's on the bubble and I can't understand why...? James >Cheers, > >Gonzalo > >On 04/08/2012 9:12 PM, DRAGE, Keith (Keith) wrote: > > (As WG cochair) > > > > I have been asked about the third-party call controller cases. > > > > They have to fall for the same reason as the conference case. > > > > The only use case that survives on the one in / one out case > where the To/From header fields could have been preserved. > > > > Regards > > > > Keith > > > > > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) > >> Sent: 03 August 2012 19:00 > >> To: insipid@ietf.org > >> Subject: Is session ID in conference in scope of the WG > >> > >> [As WG cochair] > >> > >> The chairs and the associated AD (Gonzalo) discussed this and came to the > >> conclusion that creation of an identifier that is preserved across > >> conferences is out of scope according to the INSIPID working > group charter. > >> > >> The reasoning for this is that the charter is bound to problem space for > >> which a common To/From header field is used. > >> > >> We will therefore not include a conferencing use case, or attempt to > >> derive requirements from one. > >> > >> By the same argument, transfers are also out of scope at first sight, but > >> the To and From headers are preserved in the Refer so it can be argued > >> from that perspective that it is in scope. > >> > >> So we will continue to include the transfer use case. > >> > >> Obviously discussion of this is allowed, but please remember that any such > >> discussion is likely to a rechartering discussion (with consequent delay) > >> rather than a discussion on the contents of the requirements document. > >> > >> Regards > >> > >> Keith > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > > > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Mon Aug 6 16:19: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 3D56C11E80A5 for ; Mon, 6 Aug 2012 16:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 nRgdwZL0MNRA for ; Mon, 6 Aug 2012 16:19:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8863311E80BF for ; Mon, 6 Aug 2012 16:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1861; q=dns/txt; s=iport; t=1344295153; x=1345504753; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=Y55OoW2UKxzzsCoGpUtcxYcwW/BHkpoQ0WAwdUyZPDo=; b=cmJcXJ2R90oBwezuGn/k9YwvmsINihCw4y6VxUfCj2ArgEXXP7qvQTy5 p6lajh6xudaJBpbhlcIWmTB+SJp1wyIQr0L3lH5ulj/uW9jhnJ31HRXMI wSp+yEsCb/XS/keGV4A8z33qFICHegPisWmJ5pYCGk/YT8EI20Li0YoEf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOZPIFCrRDoG/2dsb2JhbABFuU+BB4IgAQEBBAEBAQ8BJQIuBhcEBwQRBAEBAR4QGQ4oCAYBCQkih2oMmwigMASLSoZtA4hNmyKBZoJ9 X-IronPort-AV: E=Sophos;i="4.77,722,1336348800"; d="scan'208";a="54192433" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 06 Aug 2012 23:19:13 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q76NJCHL020210; Mon, 6 Aug 2012 23:19:12 GMT Message-Id: <201208062319.q76NJCHL020210@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Aug 2012 18:19:11 -0500 To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Is session ID in conference in scope of the WG 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, 06 Aug 2012 23:19:14 -0000 At 01:12 PM 8/4/2012, DRAGE, Keith (Keith) wrote: >(As WG cochair) > >I have been asked about the third-party call controller cases. > >They have to fall for the same reason as the conference case. > >The only use case that survives on the one in / one out case where >the To/From header fields could have been preserved. Keith I'm not fully following your "one in / one out case". Is it Figure 1's call flow from RFC 3725? James >Regards > >Keith > > > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: 03 August 2012 19:00 > > To: insipid@ietf.org > > Subject: Is session ID in conference in scope of the WG > > > > [As WG cochair] > > > > The chairs and the associated AD (Gonzalo) discussed this and came to the > > conclusion that creation of an identifier that is preserved across > > conferences is out of scope according to the INSIPID working group charter. > > > > The reasoning for this is that the charter is bound to problem space for > > which a common To/From header field is used. > > > > We will therefore not include a conferencing use case, or attempt to > > derive requirements from one. > > > > By the same argument, transfers are also out of scope at first sight, but > > the To and From headers are preserved in the Refer so it can be argued > > from that perspective that it is in scope. > > > > So we will continue to include the transfer use case. > > > > Obviously discussion of this is allowed, but please remember that any such > > discussion is likely to a rechartering discussion (with consequent delay) > > rather than a discussion on the contents of the requirements document. > > > > Regards > > > > Keith >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Mon Aug 6 16:30:17 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 09CAE11E80DF for ; Mon, 6 Aug 2012 16:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 4ESEkIZxM3NQ for ; Mon, 6 Aug 2012 16:30:16 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5911E80A5 for ; Mon, 6 Aug 2012 16:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=599; q=dns/txt; s=iport; t=1344295816; x=1345505416; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=oMo7xjsZYbyVl+EuRvz/TzSaX/aKZIC6tfGZ0obRBTc=; b=LwKWtnk+3AGU1SzysC4BHa/qYNwd1kV0kH0e/tHEZJIMdmtT5jpcnnMu C4SCrlhKp0r/nYraB2F9E1lj6SegcqhTe1390n+sjzqC5iIh689nz/fIv 0C/lhSIvUq5/a8MGtHT6aym5dF/OjBTPx//sJPfFVkMe5IeoaF63+HV6o Y=; X-IronPort-AV: E=Sophos;i="4.77,722,1336348800"; d="scan'208";a="54272980" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 06 Aug 2012 23:30:16 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q76NUFZk026913; Mon, 6 Aug 2012 23:30:15 GMT Message-Id: <201208062330.q76NUFZk026913@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Aug 2012 18:30:13 -0500 To: Gonzalo Salgueiro , From: James Polk In-Reply-To: <6BB23DB4-67B1-4EC7-8BF4-169A703E49D8@cisco.com> References: <6BB23DB4-67B1-4EC7-8BF4-169A703E49D8@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Minutes of the INSIPID meeting at IETF84 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, 06 Aug 2012 23:30:17 -0000 While not a fan of the conclusions drawn at the meeting, these minutes are accurate AFAICR. James At 03:39 PM 8/6/2012, Gonzalo Salgueiro wrote: >[As WG co-chair] > >The minutes from the INSIPID meeting at IETF84 in Vancouver are available at: > >http://www.ietf.org/proceedings/84/minutes/minutes-84-insipid > >Please review and comment if anything is incorrect or omitted. > >Thanks to all for attending! > >Cheers, > >Gonzalo & Keith >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Tue Aug 7 06:41:40 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 E7ABF21F867D for ; Tue, 7 Aug 2012 06:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 IY5Q-0Ltzqi4 for ; Tue, 7 Aug 2012 06:41:40 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E502821F867C for ; Tue, 7 Aug 2012 06:41:39 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id BB91923F0491; Tue, 7 Aug 2012 15:41:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Tue, 7 Aug 2012 15:41:38 +0200 From: "Hutton, Andrew" To: James Polk , Gonzalo Camarillo , "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: [Insipid] Is session ID in conference in scope of the WG Thread-Index: Ac1xod4iku0azJW7aUyoQyy4YX9rowAwtD/wADBz0YAAPJfPgAAh+KLA Date: Tue, 7 Aug 2012 13:41:37 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> References: <501EB9DF.1010403@ericsson.com> <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> In-Reply-To: <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Is session ID in conference in scope of the WG 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: Tue, 07 Aug 2012 13:41:41 -0000 Hi, I looked back through the thread and found this discussion which related to= 3PCC http://www.ietf.org/mail-archive/web/dispatch/current/msg03950.html.= =20 In this discussion it is my interpretation that 3PCC is consider in scope. = The the following snippet is taken from this thread. Paul Kyzivat asks the question. >> How do you feel about a 3PCC controller? Is it a B2BUA? If it does a >> transfer then it goes through stages when it has two dialogs, then >> three, then two. From past discussions, I think you expect there will be >> more than one session-id covering that. The response from Paul Jones. >A PBX-type device would be a B2BUA in my mind and, yes, there would be >different Session-IDs since there would be different devices end-to-end. = In >this case, the B2BUA truly is just an intermediary device, not a terminati= ng >device. My interpretation is this discussion is that 3PCC is within scope as the 3P= CC controller is "just an intermediary device" it is just confirmation that= a 3PCC transfer results in a new session identifier as per the basic endpo= int initiated case. In any case in the basic 3PCC call flow the result following the initial di= alog establishment is a simple 2 party call which is no different to the ca= se when the flow was initiated by an endpoint (i.e. 2 dialogs with a B2BUA = in the middle which mangles the dialog identifiers) so I don't understand w= hy it would be considered out of scope. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of James Polk > Sent: 07 August 2012 00:17 > To: Gonzalo Camarillo; DRAGE, Keith (Keith) > Cc: insipid@ietf.org > Subject: Re: [Insipid] Is session ID in conference in scope of the WG >=20 > At 01:22 PM 8/5/2012, Gonzalo Camarillo wrote: > >Hi, > > > >people may want to re-read the discussions we had about the scope of > >this WG when we were working on the charter (e.g., the thread with > >subject "[dispatch] new charter version for Session-id" on the > DISPATCH > >mailing list) in order to get some background on what was discussed at > >that point. >=20 > I don't remember 3PCC ever being discussed then, therefore it would > be out fo scope implicitly (but I have come to believe this is a good > use-case we should include), but transfer was always talked about as > something we include, now it's on the bubble and I can't understand > why...? >=20 > James >=20 >=20 > >Cheers, > > > >Gonzalo > > > >On 04/08/2012 9:12 PM, DRAGE, Keith (Keith) wrote: > > > (As WG cochair) > > > > > > I have been asked about the third-party call controller cases. > > > > > > They have to fall for the same reason as the conference case. > > > > > > The only use case that survives on the one in / one out case > > where the To/From header fields could have been preserved. > > > > > > Regards > > > > > > Keith > > > > > > > > >> -----Original Message----- > > >> From: DRAGE, Keith (Keith) > > >> Sent: 03 August 2012 19:00 > > >> To: insipid@ietf.org > > >> Subject: Is session ID in conference in scope of the WG > > >> > > >> [As WG cochair] > > >> > > >> The chairs and the associated AD (Gonzalo) discussed this and came > to the > > >> conclusion that creation of an identifier that is preserved across > > >> conferences is out of scope according to the INSIPID working > > group charter. > > >> > > >> The reasoning for this is that the charter is bound to problem > space for > > >> which a common To/From header field is used. > > >> > > >> We will therefore not include a conferencing use case, or attempt > to > > >> derive requirements from one. > > >> > > >> By the same argument, transfers are also out of scope at first > sight, but > > >> the To and From headers are preserved in the Refer so it can be > argued > > >> from that perspective that it is in scope. > > >> > > >> So we will continue to include the transfer use case. > > >> > > >> Obviously discussion of this is allowed, but please remember that > any such > > >> discussion is likely to a rechartering discussion (with consequent > delay) > > >> rather than a discussion on the contents of the requirements > document. > > >> > > >> Regards > > >> > > >> Keith > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > > > > > > > > >_______________________________________________ > >insipid mailing list > >insipid@ietf.org > >https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Tue Aug 14 13:27:02 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 BA98A21F8702 for ; Tue, 14 Aug 2012 13:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.146 X-Spam-Level: X-Spam-Status: No, score=-7.146 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, 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 nW11JniU8yta for ; Tue, 14 Aug 2012 13:27:02 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BA58D21F8600 for ; Tue, 14 Aug 2012 13:27:01 -0700 (PDT) X-AuditID: c1b4fb25-b7f236d000005cde-e9-502ab494dc99 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6C.46.23774.494BA205; Tue, 14 Aug 2012 22:27:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 14 Aug 2012 22:27:00 +0200 From: Christer Holmberg To: "insipid@ietf.org" Date: Tue, 14 Aug 2012 22:27:00 +0200 Thread-Topic: Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNelsowThAhaVjf0qqgp+IUqUFRg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvre6ULVoBBu0fLCzm33/G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCNfj7EVTBKvOL3nPnMD42zBLkZODgkBE4mdW1czQ9hiEhfu rWfrYuTiEBI4xSixdPIeFghnAaPE186L7F2MHBxsAhYS3f+0QRpEBDQlPt44xwwSZhFQlfjx KxDEFBZwkvjeHAtR4S5xZvohNghbT+JqWy8rSAmvQLjE5l9yIGFGoK3fT61hArGZBcQlbj2Z zwRxjYDEkj3noS4TlXj5+B8rRL2oxJ329YwQ9XoSN6ZOYYOwtSWWLXwNVs8rIChxcuYTlgmM wrOQjJ2FpGUWkpZZSFoWMLKsYhTOTczMSS830kstykwuLs7P0ytO3cQIDOyDW36r7mC8c07k EKM0B4uSOK/11j3+QgLpiSWp2ampBalF8UWlOanFhxiZODilGhj9dlgJvt92J91pPvtZ00zz SyGzs75NUDi28W3rMc/fAenhO9tzrgf4774uYpvekxr2wuxPUdwKuUWMyxf9z3XezszMzZ4g dqMg+CcjU7DV2VTjdNv3XO7v78ucNf1mPiXmVTuTkJeS9t7rKTWXFyy26V+zVmGr6qJkritN m659Y5RJqJWWC1RiKc5INNRiLipOBADNoHLcOgIAAA== Subject: [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: Tue, 14 Aug 2012 20:27:02 -0000 Hi, In Vancouver, I expressed a wish to make the INSIPID mechanism backward com= patible with the draft-kaplan-session-id one, the reason being that it has = been around for a relatively long time, and has been implemented and deploy= ed. I compared the suggested draft-jones solution with the draft-kaplan solutio= n, and I think there are ways to achieve backward compability. -------------- FIRST, looking purely at the ABNF syntax: The jones ABNF is: Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID The kaplan ABNF is: Session-ID =3D "Session-ID" HCOLON sess-id *( SEMI generic-param ) sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] Now, assuming 32 chars is enough to carry ONE UUID, jones applications coul= d put the SECOND UUID in a header field parameter (generic-param), rather t= han combining it with the received UUID. Of course, the first UUDI (carried in sess-id) can only contains characters= 0-9 and a-z. A UUID can contain characters 0-9 and a-f and A-F. So, a jones entity would have to be prepared to receive g-z. And, as kaplan entity is not prepared to receive capital A-F, a jones entit= y would have to only use small letters. But, that should not be a problem, = afaik, as they have the same meaning as far as UUID is concerned. -------------- SECOND, looking at it would work functionwise: There are two main alternatives: 1. Second UUID is added even when one entity is kaplan compliant 2. Second UUID is not added when one entity is kaplan compliant Alternative 1: When a kaplan entity inserts the first UUID (I use that as a general term, = eventhough a kaplan entity does not use UUIDs), one must assume that it is = prepared to receive a response from a jones entity which has added the seco= nd UUID into the header field parameter. When a jones entity inserts the first UUID, one must assume that it is prep= ared to receive a response from a kaplan entity where the second UUID has *= not* been added. Alternative 2: When a kaplan entity inserts the first UUID, the jones entity detects (usin= g some identify-a-kaplan-entity mechanism) that it comes from a kaplan enti= ty, so it does not insert a seoncd UUID in the first place. As in alternative 1, when a jones entity inserts the first UUID, it has to = be prepared to receive a response where the second UUID has not been added = (the identify-a-kaplan-entity mechanism might also inform the jones entity = that the response comes from a kaplan entity. -------------- Now, there will of course be cases, where two UUIDs are required, that won'= t work. But, kaplan entities would be able to use the session-id for whatev= er they've used it so far. Regards, Christer From R.Jesske@telekom.de Wed Aug 15 04:50: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 6F8A521F86E2 for ; Wed, 15 Aug 2012 04:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, 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 DT-vKIkjPP17 for ; Wed, 15 Aug 2012 04:50:34 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8047721F86E0 for ; Wed, 15 Aug 2012 04:50:31 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 15 Aug 2012 13:50:24 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 15 Aug 2012 13:50:23 +0200 From: To: , Date: Wed, 15 Aug 2012 13:50:22 +0200 Thread-Topic: Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNelsowThAhaVjf0qqgp+IUqUFRpdawyyw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD8D96D1@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 15 Aug 2012 11:50:35 -0000 Hi, I support this approach as we have already an implementation based on draft= -kaplan. Thank you and best Regards Roland -----Urspr=FCngliche Nachricht----- Von: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] Im Auftrag = von Christer Holmberg Gesendet: Dienstag, 14. August 2012 22:27 An: insipid@ietf.org Betreff: [Insipid] Backward compability between draft-jones and draft-kapla= n Hi, In Vancouver, I expressed a wish to make the INSIPID mechanism backward com= patible with the draft-kaplan-session-id one, the reason being that it has = been around for a relatively long time, and has been implemented and deploy= ed. I compared the suggested draft-jones solution with the draft-kaplan solutio= n, and I think there are ways to achieve backward compability. -------------- FIRST, looking purely at the ABNF syntax: The jones ABNF is: Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID The kaplan ABNF is: Session-ID =3D "Session-ID" HCOLON sess-id *( SEMI generic-param ) sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] Now, assuming 32 chars is enough to carry ONE UUID, jones applications coul= d put the SECOND UUID in a header field parameter (generic-param), rather t= han combining it with the received UUID. Of course, the first UUDI (carried in sess-id) can only contains characters= 0-9 and a-z. A UUID can contain characters 0-9 and a-f and A-F. So, a jones entity would have to be prepared to receive g-z. And, as kaplan entity is not prepared to receive capital A-F, a jones entit= y would have to only use small letters. But, that should not be a problem, = afaik, as they have the same meaning as far as UUID is concerned. -------------- SECOND, looking at it would work functionwise: There are two main alternatives: 1. Second UUID is added even when one entity is kaplan compliant 2. Second UUID is not added when one entity is kaplan compliant Alternative 1: When a kaplan entity inserts the first UUID (I use that as a general term, = eventhough a kaplan entity does not use UUIDs), one must assume that it is = prepared to receive a response from a jones entity which has added the seco= nd UUID into the header field parameter. When a jones entity inserts the first UUID, one must assume that it is prep= ared to receive a response from a kaplan entity where the second UUID has *= not* been added. Alternative 2: When a kaplan entity inserts the first UUID, the jones entity detects (usin= g some identify-a-kaplan-entity mechanism) that it comes from a kaplan enti= ty, so it does not insert a seoncd UUID in the first place. As in alternative 1, when a jones entity inserts the first UUID, it has to = be prepared to receive a response where the second UUID has not been added = (the identify-a-kaplan-entity mechanism might also inform the jones entity = that the response comes from a kaplan entity. -------------- Now, there will of course be cases, where two UUIDs are required, that won'= t work. But, kaplan entities would be able to use the session-id for whatev= er they've used it so far. Regards, Christer _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From R.Jesske@telekom.de Wed Aug 15 05:17:22 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 8676321F87A5 for ; Wed, 15 Aug 2012 05:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, 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 ov1pr3P1uHGQ for ; Wed, 15 Aug 2012 05:17:22 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 696BA21F879F for ; Wed, 15 Aug 2012 05:17:21 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 15 Aug 2012 14:17:19 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 15 Aug 2012 14:17:19 +0200 From: To: , Date: Wed, 15 Aug 2012 14:17:17 +0200 Thread-Topic: Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNelsowThAhaVjf0qqgp+IUqUFRpdaxV3g Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D14DD8D9736@HE111648.emea1.cds.t-internal.com> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 15 Aug 2012 12:17:22 -0000 Hi Christer, You state ... And, as kaplan entity is not prepared to receive capital A-F, a jones entit= y would have to only use small letters. But, that should not be a problem, = afaik, as they have the same meaning as far as UUID is concerned. ... I found in RFC4122 (UUID) the following wording. Each field is treated as an integer and has its value printed as a zero-filled hexadecimal digit string with the most significant digit first. The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input. ... hexDigit =3D "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F" ... Is this the "procedure" how a recived UUID has to be interpreted or does that mean that the UUID is sent only in lower case even that the hexDi= git is also defined as upper case in the ABNF? Than you Roland From shida@ntt-at.com Wed Aug 15 10:01: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 B568821F84DF for ; Wed, 15 Aug 2012 10:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, 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 dPe8VRzXJfud for ; Wed, 15 Aug 2012 10:01:11 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13B21F883A for ; Wed, 15 Aug 2012 10:01:06 -0700 (PDT) Received: from [172.218.64.46] (port=50673 helo=[192.168.1.76]) by gator465.hostgator.com with esmtpa (Exim 4.77) (envelope-from ) id 1T1gxs-0006AB-VF; Wed, 15 Aug 2012 12:01:05 -0500 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 15 Aug 2012 10:01:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.76]) [172.218.64.46]:50673 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t 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, 15 Aug 2012 17:01:12 -0000 As we have the kaplan spec implemented and deployed,=20 I support Christer's proposal. Regards Shida On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > Hi, >=20 > In Vancouver, I expressed a wish to make the INSIPID mechanism = backward compatible with the draft-kaplan-session-id one, the reason = being that it has been around for a relatively long time, and has been = implemented and deployed. >=20 > I compared the suggested draft-jones solution with the draft-kaplan = solution, and I think there are ways to achieve backward compability. >=20 >=20 > -------------- >=20 >=20 > FIRST, looking purely at the ABNF syntax: >=20 > The jones ABNF is: >=20 >=20 > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >=20 >=20 >=20 > The kaplan ABNF is: >=20 >=20 >=20 > Session-ID =3D "Session-ID" HCOLON sess-id >=20 > *( SEMI generic-param ) >=20 > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >=20 >=20 >=20 >=20 >=20 > Now, assuming 32 chars is enough to carry ONE UUID, jones applications = could put the SECOND UUID in a header field parameter (generic-param), = rather than combining it with the received UUID. >=20 >=20 >=20 > Of course, the first UUDI (carried in sess-id) can only contains = characters 0-9 and a-z. >=20 >=20 >=20 > A UUID can contain characters 0-9 and a-f and A-F. >=20 >=20 >=20 > So, a jones entity would have to be prepared to receive g-z. >=20 >=20 >=20 > And, as kaplan entity is not prepared to receive capital A-F, a jones = entity would have to only use small letters. But, that should not be a = problem, afaik, as they have the same meaning as far as UUID is = concerned. >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > SECOND, looking at it would work functionwise: >=20 >=20 >=20 > There are two main alternatives: >=20 >=20 >=20 >=20 >=20 > 1. Second UUID is added even when one entity is kaplan compliant >=20 > 2. Second UUID is not added when one entity is kaplan compliant >=20 >=20 >=20 >=20 >=20 > Alternative 1: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID (I use that as a general = term, eventhough a kaplan entity does not use UUIDs), one must assume = that it is prepared to receive a response from a jones entity which has = added the second UUID into the header field parameter. >=20 >=20 >=20 > When a jones entity inserts the first UUID, one must assume that it is = prepared to receive a response from a kaplan entity where the second = UUID has *not* been added. >=20 >=20 >=20 >=20 >=20 > Alternative 2: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID, the jones entity detects = (using some identify-a-kaplan-entity mechanism) that it comes from a = kaplan entity, so it does not insert a seoncd UUID in the first place. >=20 >=20 >=20 > As in alternative 1, when a jones entity inserts the first UUID, it = has to be prepared to receive a response where the second UUID has not = been added (the identify-a-kaplan-entity mechanism might also inform the = jones entity that the response comes from a kaplan entity. >=20 >=20 >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > Now, there will of course be cases, where two UUIDs are required, that = won't work. But, kaplan entities would be able to use the session-id for = whatever they've used it so far. >=20 >=20 >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From gsalguei@cisco.com Wed Aug 15 22:29:03 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 7DE0B21F863C for ; Wed, 15 Aug 2012 22:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.182 X-Spam-Level: X-Spam-Status: No, score=-7.182 tagged_above=-999 required=5 tests=[AWL=3.417, 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 RVMh8AW67tYn for ; Wed, 15 Aug 2012 22:29:02 -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 C117221F8620 for ; Wed, 15 Aug 2012 22:29:02 -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 q7G5T2b4020773 for ; Thu, 16 Aug 2012 01:29:02 -0400 (EDT) Received: from rtp-gsalguei-8916.cisco.com (rtp-gsalguei-8916.cisco.com [10.116.132.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7G5Sxnb008718 for ; Thu, 16 Aug 2012 01:28:59 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Aug 2012 01:28:59 -0400 Message-Id: <0CD60541-DA01-4A16-9D98-1F1927DBB408@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [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: Thu, 16 Aug 2012 05:29:03 -0000 Folks -=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. This will be a 2 hour long webex meeting (I'll send out meeting details = once we converge on a date/time). Please indicate your availability at: http://doodle.com/ry7uz4ka5cpne7hi The times specified on the poll are EDT (GMT -4:00) but it should be = intelligent enough to translate to your local time. 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. Cheers, Gonzalo and Keith= From prvs=2575bc6765=aallen@rim.com Thu Aug 16 15:00:17 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 29DC821F8589 for ; Thu, 16 Aug 2012 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_QP_LONG_LINE=1.396, 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 t7PJFCmC+pyk for ; Thu, 16 Aug 2012 15:00:16 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8000B21F8554 for ; Thu, 16 Aug 2012 15:00:12 -0700 (PDT) X-AuditID: 0a41282f-b7f036d000004990-08-502d6d688d9b Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id A8.14.18832.86D6D205; Thu, 16 Aug 2012 17:00:08 -0500 (CDT) Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0298.004; Thu, 16 Aug 2012 17:00:07 -0500 From: Andrew Allen To: "shida@ntt-at.com" , "christer.holmberg@ericsson.com" Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNewefi0qZqUUQIEmCbPY2XcSeXJdc/u2o Date: Thu, 16 Aug 2012 22:00:06 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsXC5ZyvpZuRqxtg0LlPyuLCzMOMFvPvP2Oy +H1oHqsDs8evr1fZPJYs+cnk0XNpNmMAc1QDo01SYklZcGZ6nr6dTWJeXn5JYkmqQkpqcbKt kk9qemKOQkBRZllicqWCS2Zxck5iZm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2X AgawASrLzFNIzUvOT8nMS7dV8gz217WwMLXUNVSy003o5MnY8GAvS8FB1Yrnr48xNzAeke1i 5OSQEDCR2HD1CjuELSZx4d56ti5GLg4hgZWMEpsWPWWGcLYwSrzo/McCUsUmoCyx/PcMRhBb RCBPouficTCbWUBTYsXi22CThAWCJL586GCCqAmWmHP+IpRtJHFx5xswm0VAVeL2u4esIDav gIfE0ztzweKcAnYS37cdYAOxGQVkJXafvc4EMV9c4taT+UwQlwpILNlznhnCFpV4+fgfK4St KLHsxEk2iHo9iRtTp0DZ2hLLFr5mhtglKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFMzN KDYwM0jOS9YryszVy0st2cQIShKOGvo7GN++tzjEKMDBqMTDa2SpGyDEmlhWXJl7iFGCg1lJ hHd5IFCINyWxsiq1KD++qDQntfgQowUwJCYyS3En5wMTWF5JvLGBAQpHSZw3mU0zQEggHZhk slNTC1KLYFqZODhBRnNJiRQDU0VqUWJpSUY8KKHFFwNTmlQDY0nRgrK4VbLKcoKSyas+CLL/ WPLL/l8L2ztNd66OA66tvT3iTfqPZyxqqD6/qnN/mFJW34EPDu5CD3c9Ftr0y+Kr1VoXGc+J Kydqqts9XWb5M/qZeW++ok/w6RdxVxm36K1njZrwZteU0lXBT70+xcR9nvY3y3j3pwWnl6lf uXXj2jKNlneHniixFGckGmoxFxUnAgB12Jz/RgMAAA== 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: Thu, 16 Aug 2012 22:00:17 -0000 If its at all possible to make the INSIPID solution backwards compatible wit= h the Kaplan draft I would strongly urge we do this. With several pre-standards deployments already based on Kaplan draft there= is a real danger that INSIPID solution will become an unimplemented standar= d if it is not backward compatible with what has already been deployed. While we don't guarantee to maintain compatibility with earlier versions of= drafts it is in our interest to attempt to be compatible with what has been= deployed commercially. Running code is of course something we desire and believe in! Andrew ----- Original Message ----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, August 15, 2012 12:01 PM=0A= To: Christer Holmberg Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-ka= plan As we have the kaplan spec implemented and deployed, I support Christer's proposal. Regards Shida On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > Hi, > > In Vancouver, I expressed a wish to make the INSIPID mechanism backward co= mpatible with the draft-kaplan-session-id one, the reason being that it has= been around for a relatively long time, and has been implemented and deploy= ed. > > I compared the suggested draft-jones solution with the draft-kaplan soluti= on, and I think there are ways to achieve backward compability. > > > -------------- > > > FIRST, looking purely at the ABNF syntax: > > The jones ABNF is: > > > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID > > > > The kaplan ABNF is: > > > > Session-ID =3D "Session-ID" HCOLON sess-id > > *( SEMI generic-param ) > > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > > > > Now, assuming 32 chars is enough to carry ONE UUID, jones applications cou= ld put the SECOND UUID in a header field parameter (generic-param), rather t= han combining it with the received UUID. > > > > Of course, the first UUDI (carried in sess-id) can only contains character= s 0-9 and a-z. > > > > A UUID can contain characters 0-9 and a-f and A-F. > > > > So, a jones entity would have to be prepared to receive g-z. > > > > And, as kaplan entity is not prepared to receive capital A-F, a jones enti= ty would have to only use small letters. But, that should not be a problem,= afaik, as they have the same meaning as far as UUID is concerned. > > > > -------------- > > > > SECOND, looking at it would work functionwise: > > > > There are two main alternatives: > > > > > > 1. Second UUID is added even when one entity is kaplan compliant > > 2. Second UUID is not added when one entity is kaplan compliant > > > > > > Alternative 1: > > > > When a kaplan entity inserts the first UUID (I use that as a general term,= eventhough a kaplan entity does not use UUIDs), one must assume that it is= prepared to receive a response from a jones entity which has added the seco= nd UUID into the header field parameter. > > > > When a jones entity inserts the first UUID, one must assume that it is pre= pared to receive a response from a kaplan entity where the second UUID has *= not* been added. > > > > > > Alternative 2: > > > > When a kaplan entity inserts the first UUID, the jones entity detects (usi= ng some identify-a-kaplan-entity mechanism) that it comes from a kaplan enti= ty, so it does not insert a seoncd UUID in the first place. > > > > As in alternative 1, when a jones entity inserts the first UUID, it has to= be prepared to receive a response where the second UUID has not been added= (the identify-a-kaplan-entity mechanism might also inform the jones entity= that the response comes from a kaplan entity. > > > > > > -------------- > > > > Now, there will of course be cases, where two UUIDs are required, that won= 't work. But, kaplan entities would be able to use the session-id for whatev= er they've used it so far. > > > > > > Regards, > > > > Christer > > > > > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From peter.leis@nsn.com Fri Aug 17 02:11: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 34EE221F850D for ; Fri, 17 Aug 2012 02:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 Fo6btgFsbc7f for ; Fri, 17 Aug 2012 02:11:33 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D6D2421F84E1 for ; Fri, 17 Aug 2012 02:11:32 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7H9BM6m003940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Aug 2012 11:11:22 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7H9BI09004362; Fri, 17 Aug 2012 11:11:22 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 11:10:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Aug 2012 11:10:49 +0200 Message-ID: <79C4240C13B4C84B910850B96B1B431204AC7429@DEMUEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Insipid] Backward compability between draft-jonesand draft-kaplan Thread-Index: AQHNewefi0qZqUUQIEmCbPY2XcSeXJdc/u2ogAC6hLA= References: From: "Leis, Peter (NSN - DE/Munich)" To: , X-OriginalArrivalTime: 17 Aug 2012 09:10:50.0096 (UTC) FILETIME=[31F8AF00:01CD7C58] 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: 6016 X-purgate-ID: 151667::1345194683-00003184-6B1C0983/0-0/0-0 Subject: Re: [Insipid] Backward compability between draft-jonesand 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, 17 Aug 2012 09:11:34 -0000 I support the proposal to make the INSIPID mechanism backward compatible with the mechanism in draft-kaplan-session-id. Regards Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of ext Andrew Allen Sent: Friday, August 17, 2012 12:00 AM To: shida@ntt-at.com; christer.holmberg@ericsson.com Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jonesand draft-kaplan If its at all possible to make the INSIPID solution backwards compatible with the Kaplan draft I would strongly urge we do this.=20 With several pre-standards deployments already based on Kaplan draft there is a real danger that INSIPID solution will become an unimplemented standard if it is not backward compatible with what has already been deployed. While we don't guarantee to maintain compatibility with earlier versions of drafts it is in our interest to attempt to be compatible with what has been deployed commercially.=20 Running code is of course something we desire and believe in! Andrew=20 ----- Original Message ----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, August 15, 2012 12:01 PM To: Christer Holmberg Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan As we have the kaplan spec implemented and deployed,=20 I support Christer's proposal. Regards Shida On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > Hi, >=20 > In Vancouver, I expressed a wish to make the INSIPID mechanism backward compatible with the draft-kaplan-session-id one, the reason being that it has been around for a relatively long time, and has been implemented and deployed. >=20 > I compared the suggested draft-jones solution with the draft-kaplan solution, and I think there are ways to achieve backward compability. >=20 >=20 > -------------- >=20 >=20 > FIRST, looking purely at the ABNF syntax: >=20 > The jones ABNF is: >=20 >=20 > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >=20 >=20 >=20 > The kaplan ABNF is: >=20 >=20 >=20 > Session-ID =3D "Session-ID" HCOLON sess-id >=20 > *( SEMI generic-param ) >=20 > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >=20 >=20 >=20 >=20 >=20 > Now, assuming 32 chars is enough to carry ONE UUID, jones applications could put the SECOND UUID in a header field parameter (generic-param), rather than combining it with the received UUID. >=20 >=20 >=20 > Of course, the first UUDI (carried in sess-id) can only contains characters 0-9 and a-z. >=20 >=20 >=20 > A UUID can contain characters 0-9 and a-f and A-F. >=20 >=20 >=20 > So, a jones entity would have to be prepared to receive g-z. >=20 >=20 >=20 > And, as kaplan entity is not prepared to receive capital A-F, a jones entity would have to only use small letters. But, that should not be a problem, afaik, as they have the same meaning as far as UUID is concerned. >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > SECOND, looking at it would work functionwise: >=20 >=20 >=20 > There are two main alternatives: >=20 >=20 >=20 >=20 >=20 > 1. Second UUID is added even when one entity is kaplan compliant >=20 > 2. Second UUID is not added when one entity is kaplan compliant >=20 >=20 >=20 >=20 >=20 > Alternative 1: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID (I use that as a general term, eventhough a kaplan entity does not use UUIDs), one must assume that it is prepared to receive a response from a jones entity which has added the second UUID into the header field parameter. >=20 >=20 >=20 > When a jones entity inserts the first UUID, one must assume that it is prepared to receive a response from a kaplan entity where the second UUID has *not* been added. >=20 >=20 >=20 >=20 >=20 > Alternative 2: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID, the jones entity detects (using some identify-a-kaplan-entity mechanism) that it comes from a kaplan entity, so it does not insert a seoncd UUID in the first place. >=20 >=20 >=20 > As in alternative 1, when a jones entity inserts the first UUID, it has to be prepared to receive a response where the second UUID has not been added (the identify-a-kaplan-entity mechanism might also inform the jones entity that the response comes from a kaplan entity. >=20 >=20 >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > Now, there will of course be cases, where two UUIDs are required, that won't work. But, kaplan entities would be able to use the session-id for whatever they've used it so far. >=20 >=20 >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From jan.van.geel@belgacom.be Fri Aug 17 02:23:56 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 9FEB121F852C for ; Fri, 17 Aug 2012 02:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 LfCfQzX5Rp8o for ; Fri, 17 Aug 2012 02:23:55 -0700 (PDT) Received: from mx23.belgacom.be (mx23.belgacom.be [213.181.45.233]) by ietfa.amsl.com (Postfix) with ESMTP id 79A3821F8557 for ; Fri, 17 Aug 2012 02:23:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,783,1336341600"; d="scan'208";a="24789311" Received: from unknown (HELO A03006.BGC.NET) ([10.121.129.161]) by mx23.belgacom.be with ESMTP; 17 Aug 2012 11:23:50 +0200 X-TM-IMSS-Message-ID: <12a425dc0002f25d@belgacom.be> Received: from A04021.BGC.NET ([10.120.135.22]) by belgacom.be ([10.121.129.161]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 12a425dc0002f25d ; Fri, 17 Aug 2012 11:23:50 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04021.BGC.NET ([10.120.135.22]) with mapi id 14.01.0355.002; Fri, 17 Aug 2012 11:23:51 +0200 From: "VAN GEEL Jan (CIS/SCC)" To: "insipid@ietf.org" Thread-Topic: [Insipid] Backward compability between draft-jonesand draft-kaplan Thread-Index: AQHNfFhRXnVJwscXJUaqaaukFoXXXJddu0jQ Date: Fri, 17 Aug 2012 09:23:51 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E1246DE@A04067.BGC.NET> References: <79C4240C13B4C84B910850B96B1B431204AC7429@DEMUEXC035.nsn-intra.net> In-Reply-To: <79C4240C13B4C84B910850B96B1B431204AC7429@DEMUEXC035.nsn-intra.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.29.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Backward compability between draft-jonesand 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, 17 Aug 2012 09:23:56 -0000 +1 Jan Van Geel IT and Network Specialist Belgacom SDE/SDV/PSE/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Leis, Peter (NSN - DE/Munich) Sent: Friday 17 August 2012 11:11 To: christer.holmberg@ericsson.com; insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jonesand draft-ka= plan I support the proposal to make the INSIPID mechanism backward compatible wi= th the mechanism in draft-kaplan-session-id. Regards Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of ext Andrew Allen Sent: Friday, August 17, 2012 12:00 AM To: shida@ntt-at.com; christer.holmberg@ericsson.com Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jonesand draft-ka= plan If its at all possible to make the INSIPID solution backwards compatible wi= th the Kaplan draft I would strongly urge we do this. With several pre-standards deployments already based on Kaplan draft there = is a real danger that INSIPID solution will become an unimplemented standar= d if it is not backward compatible with what has already been deployed. While we don't guarantee to maintain compatibility with earlier versions of= drafts it is in our interest to attempt to be compatible with what has bee= n deployed commercially. Running code is of course something we desire and believe in! Andrew ----- Original Message ----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, August 15, 2012 12:01 PM To: Christer Holmberg Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-k= aplan As we have the kaplan spec implemented and deployed, I support Christer's = proposal. Regards Shida On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > Hi, > > In Vancouver, I expressed a wish to make the INSIPID mechanism backward compatible with the draft-kaplan-session-id one, the reason being = that it has been around for a relatively long time, and has been implemente= d and deployed. > > I compared the suggested draft-jones solution with the draft-kaplan solution, and I think there are ways to achieve backward compability. > > > -------------- > > > FIRST, looking purely at the ABNF syntax: > > The jones ABNF is: > > > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID > > > > The kaplan ABNF is: > > > > Session-ID =3D "Session-ID" HCOLON sess-id > > *( SEMI generic-param ) > > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > > > > Now, assuming 32 chars is enough to carry ONE UUID, jones applications could put the SECOND UUID in a header field parameter (generic-param), rath= er than combining it with the received UUID. > > > > Of course, the first UUDI (carried in sess-id) can only contains characters 0-9 and a-z. > > > > A UUID can contain characters 0-9 and a-f and A-F. > > > > So, a jones entity would have to be prepared to receive g-z. > > > > And, as kaplan entity is not prepared to receive capital A-F, a jones entity would have to only use small letters. But, that should not be a prob= lem, afaik, as they have the same meaning as far as UUID is concerned. > > > > -------------- > > > > SECOND, looking at it would work functionwise: > > > > There are two main alternatives: > > > > > > 1. Second UUID is added even when one entity is kaplan compliant > > 2. Second UUID is not added when one entity is kaplan compliant > > > > > > Alternative 1: > > > > When a kaplan entity inserts the first UUID (I use that as a general term, eventhough a kaplan entity does not use UUIDs), one must assume that = it is prepared to receive a response from a jones entity which has added th= e second UUID into the header field parameter. > > > > When a jones entity inserts the first UUID, one must assume that it is prepared to receive a response from a kaplan entity where the second UUID h= as *not* been added. > > > > > > Alternative 2: > > > > When a kaplan entity inserts the first UUID, the jones entity detects (using some identify-a-kaplan-entity mechanism) that it comes from a kaplan= entity, so it does not insert a seoncd UUID in the first place. > > > > As in alternative 1, when a jones entity inserts the first UUID, it has to be prepared to receive a response where the second UUID has not been= added (the identify-a-kaplan-entity mechanism might also inform the jones = entity that the response comes from a kaplan entity. > > > > > > -------------- > > > > Now, there will of course be cases, where two UUIDs are required, that won't work. But, kaplan entities would be able to use the session-id for wh= atever they've used it so far. > > > > > > Regards, > > > > Christer > > > > > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer From md3135@att.com Fri Aug 17 03:59:22 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 A821821F852D for ; Fri, 17 Aug 2012 03:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, 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 aRLrk6d1d5wd for ; Fri, 17 Aug 2012 03:59:21 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id B1AC521F846F for ; Fri, 17 Aug 2012 03:59:21 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 9042e205.4793b940.1087569.00-537.3005219.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 17 Aug 2012 10:59:21 +0000 (UTC) X-MXL-Hash: 502e240969856dac-30c10e3708ea8876f6e8c9859653814a65ac84b7 Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 4042e205.0.1087562.00-480.3005200.nbfkord-smmo04.seg.att.com (envelope-from ); Fri, 17 Aug 2012 10:59:18 +0000 (UTC) X-MXL-Hash: 502e240625d90bed-f17bce2c38b443872ede8128a17edafcb70e8f9b Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7HAxFip022311; Fri, 17 Aug 2012 03:59:16 -0700 Received: from fflint03.pst.cso.att.com (fflint03.pst.cso.att.com [150.234.39.63]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q7HAx8ER022250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 03:59:09 -0700 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by fflint03.pst.cso.att.com (RSA Interceptor); Fri, 17 Aug 2012 03:58:42 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.02.0318.001; Fri, 17 Aug 2012 06:58:41 -0400 From: "DOLLY, MARTIN C" To: Andrew Allen , "shida@ntt-at.com" , "christer.holmberg@ericsson.com" Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNewefi0qZqUUQIEmCbPY2XcSeXJdc/u2ogADY+5A= Date: Fri, 17 Aug 2012 10:58:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.86.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=ShlNgWpomOMA:10 a=qNWmvztOciIA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=pGQwqaTwoeMA:1] X-AnalysisOut: [0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a=48vgC7mUAAAA:8 a=M9IkpJ_] X-AnalysisOut: [0AAAA:8 a=0FD05c-RAAAA:8 a=osXYWGPTallrCxRbFF4A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=lZB815dzVvQA:10 a=gzzNvakQ__kA:10 a=f7GxY0FH8Q] X-AnalysisOut: [IA:10 a=gaftPN7sA6iMELHl:21 a=xMgq6w-nA03HZKCR:21] 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, 17 Aug 2012 10:59:22 -0000 AT&T supports the proposal to make the INSIPID mechanism backward compatibl= e with the mechanism in draft-kaplan-session-id. -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Andrew Allen Sent: Thursday, August 16, 2012 6:00 PM To: shida@ntt-at.com; christer.holmberg@ericsson.com Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-k= aplan If its at all possible to make the INSIPID solution backwards compatible wi= th the Kaplan draft I would strongly urge we do this.=20 With several pre-standards deployments already based on Kaplan draft there= is a real danger that INSIPID solution will become an unimplemented standa= rd if it is not backward compatible with what has already been deployed. While we don't guarantee to maintain compatibility with earlier versions of= drafts it is in our interest to attempt to be compatible with what has bee= n deployed commercially.=20 Running code is of course something we desire and believe in! Andrew=20 ----- Original Message ----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, August 15, 2012 12:01 PM To: Christer Holmberg Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-k= aplan As we have the kaplan spec implemented and deployed,=20 I support Christer's proposal. Regards Shida On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > Hi, >=20 > In Vancouver, I expressed a wish to make the INSIPID mechanism backward c= ompatible with the draft-kaplan-session-id one, the reason being that it ha= s been around for a relatively long time, and has been implemented and depl= oyed. >=20 > I compared the suggested draft-jones solution with the draft-kaplan solut= ion, and I think there are ways to achieve backward compability. >=20 >=20 > -------------- >=20 >=20 > FIRST, looking purely at the ABNF syntax: >=20 > The jones ABNF is: >=20 >=20 > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >=20 >=20 >=20 > The kaplan ABNF is: >=20 >=20 >=20 > Session-ID =3D "Session-ID" HCOLON sess-id >=20 > *( SEMI generic-param ) >=20 > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >=20 >=20 >=20 >=20 >=20 > Now, assuming 32 chars is enough to carry ONE UUID, jones applications co= uld put the SECOND UUID in a header field parameter (generic-param), rather= than combining it with the received UUID. >=20 >=20 >=20 > Of course, the first UUDI (carried in sess-id) can only contains characte= rs 0-9 and a-z. >=20 >=20 >=20 > A UUID can contain characters 0-9 and a-f and A-F. >=20 >=20 >=20 > So, a jones entity would have to be prepared to receive g-z. >=20 >=20 >=20 > And, as kaplan entity is not prepared to receive capital A-F, a jones ent= ity would have to only use small letters. But, that should not be a problem= , afaik, as they have the same meaning as far as UUID is concerned. >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > SECOND, looking at it would work functionwise: >=20 >=20 >=20 > There are two main alternatives: >=20 >=20 >=20 >=20 >=20 > 1. Second UUID is added even when one entity is kaplan compliant >=20 > 2. Second UUID is not added when one entity is kaplan compliant >=20 >=20 >=20 >=20 >=20 > Alternative 1: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID (I use that as a general term= , eventhough a kaplan entity does not use UUIDs), one must assume that it i= s prepared to receive a response from a jones entity which has added the se= cond UUID into the header field parameter. >=20 >=20 >=20 > When a jones entity inserts the first UUID, one must assume that it is pr= epared to receive a response from a kaplan entity where the second UUID has= *not* been added. >=20 >=20 >=20 >=20 >=20 > Alternative 2: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID, the jones entity detects (us= ing some identify-a-kaplan-entity mechanism) that it comes from a kaplan en= tity, so it does not insert a seoncd UUID in the first place. >=20 >=20 >=20 > As in alternative 1, when a jones entity inserts the first UUID, it has t= o be prepared to receive a response where the second UUID has not been adde= d (the identify-a-kaplan-entity mechanism might also inform the jones entit= y that the response comes from a kaplan entity. >=20 >=20 >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > Now, there will of course be cases, where two UUIDs are required, that wo= n't work. But, kaplan entities would be able to use the session-id for what= ever they've used it so far. >=20 >=20 >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From Peter.Dawes@vodafone.com Fri Aug 17 07:08:20 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 67D7E21F858A for ; Fri, 17 Aug 2012 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 xApRW08+Ttqb for ; Fri, 17 Aug 2012 07:08:19 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by ietfa.amsl.com (Postfix) with ESMTP id 646ED21F8594 for ; Fri, 17 Aug 2012 07:08:19 -0700 (PDT) Received: from mailint02 (localhost [127.0.0.1]) by mailout02 (Postfix) with ESMTP id 77FCA21451C for ; Fri, 17 Aug 2012 16:08:17 +0200 (CEST) Received: from VOEXC02W.internal.vodafone.com (voexc02w.dc-ratingen.de [145.230.101.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint02 (Postfix) with ESMTPS id 673F6214242; Fri, 17 Aug 2012 16:08:17 +0200 (CEST) Received: from AVOEXH04W.internal.vodafone.com (145.230.15.136) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 Aug 2012 16:09:41 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.77]) by AVOEXH04W.internal.vodafone.com ([145.230.15.136]) with mapi id 14.01.0355.002; Fri, 17 Aug 2012 16:09:41 +0200 From: "Dawes, Peter, Vodafone Group" To: Andrew Allen , "shida@ntt-at.com" , "christer.holmberg@ericsson.com" Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNe/q6QYes7GI4Zkqnf3EIwQ9u+JdeCfig Date: Fri, 17 Aug 2012 14:09:40 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D995123D1E4@VOEXM31W.internal.vodafone.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [145.230.12.27] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 17 Aug 2012 14:08:20 -0000 I share the view in the comments below, the INSIPID solution needs to be ba= ckwards compatible with the Kaplan draft. Regards, Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Andrew Allen Sent: 16 August 2012 23:00 To: shida@ntt-at.com; christer.holmberg@ericsson.com Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-k= aplan If its at all possible to make the INSIPID solution backwards compatible wi= th the Kaplan draft I would strongly urge we do this.=20 With several pre-standards deployments already based on Kaplan draft there= is a real danger that INSIPID solution will become an unimplemented standa= rd if it is not backward compatible with what has already been deployed. While we don't guarantee to maintain compatibility with earlier versions of= drafts it is in our interest to attempt to be compatible with what has bee= n deployed commercially.=20 Running code is of course something we desire and believe in! Andrew=20 ----- Original Message ----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, August 15, 2012 12:01 PM To: Christer Holmberg Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-k= aplan As we have the kaplan spec implemented and deployed, I support Christer's = proposal. Regards Shida On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > Hi, >=20 > In Vancouver, I expressed a wish to make the INSIPID mechanism backward c= ompatible with the draft-kaplan-session-id one, the reason being that it ha= s been around for a relatively long time, and has been implemented and depl= oyed. >=20 > I compared the suggested draft-jones solution with the draft-kaplan solut= ion, and I think there are ways to achieve backward compability. >=20 >=20 > -------------- >=20 >=20 > FIRST, looking purely at the ABNF syntax: >=20 > The jones ABNF is: >=20 >=20 > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >=20 >=20 >=20 > The kaplan ABNF is: >=20 >=20 >=20 > Session-ID =3D "Session-ID" HCOLON sess-id >=20 > *( SEMI generic-param ) >=20 > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >=20 >=20 >=20 >=20 >=20 > Now, assuming 32 chars is enough to carry ONE UUID, jones applications co= uld put the SECOND UUID in a header field parameter (generic-param), rather= than combining it with the received UUID. >=20 >=20 >=20 > Of course, the first UUDI (carried in sess-id) can only contains characte= rs 0-9 and a-z. >=20 >=20 >=20 > A UUID can contain characters 0-9 and a-f and A-F. >=20 >=20 >=20 > So, a jones entity would have to be prepared to receive g-z. >=20 >=20 >=20 > And, as kaplan entity is not prepared to receive capital A-F, a jones ent= ity would have to only use small letters. But, that should not be a problem= , afaik, as they have the same meaning as far as UUID is concerned. >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > SECOND, looking at it would work functionwise: >=20 >=20 >=20 > There are two main alternatives: >=20 >=20 >=20 >=20 >=20 > 1. Second UUID is added even when one entity is kaplan compliant >=20 > 2. Second UUID is not added when one entity is kaplan compliant >=20 >=20 >=20 >=20 >=20 > Alternative 1: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID (I use that as a general term= , eventhough a kaplan entity does not use UUIDs), one must assume that it i= s prepared to receive a response from a jones entity which has added the se= cond UUID into the header field parameter. >=20 >=20 >=20 > When a jones entity inserts the first UUID, one must assume that it is pr= epared to receive a response from a kaplan entity where the second UUID has= *not* been added. >=20 >=20 >=20 >=20 >=20 > Alternative 2: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID, the jones entity detects (us= ing some identify-a-kaplan-entity mechanism) that it comes from a kaplan en= tity, so it does not insert a seoncd UUID in the first place. >=20 >=20 >=20 > As in alternative 1, when a jones entity inserts the first UUID, it has t= o be prepared to receive a response where the second UUID has not been adde= d (the identify-a-kaplan-entity mechanism might also inform the jones entit= y that the response comes from a kaplan entity. >=20 >=20 >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > Now, there will of course be cases, where two UUIDs are required, that wo= n't work. But, kaplan entities would be able to use the session-id for what= ever they've used it so far. >=20 >=20 >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From HKaplan@acmepacket.com Fri Aug 17 09:38:55 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 E1A5711E80D5 for ; Fri, 17 Aug 2012 09:38:55 -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 EFQTN-+ytnDR for ; Fri, 17 Aug 2012 09:38:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2AA011E80D1 for ; Fri, 17 Aug 2012 09:38:54 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 17 Aug 2012 12:38:53 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.149]) by Mail2.acmepacket.com ([169.254.2.126]) with mapi id 14.02.0283.003; Fri, 17 Aug 2012 12:38:53 -0400 From: Hadriel Kaplan To: "Hutton, Andrew" Thread-Topic: [Insipid] Is session ID in conference in scope of the WG Thread-Index: AQHNfJbJgkitcnPjnU6W6gfgCd4pGw== Date: Fri, 17 Aug 2012 16:38:52 +0000 Message-ID: References: <501EB9DF.1010403@ericsson.com> <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <01435B7A64CBA349B982E67901DDDA84@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: =?us-ascii?Q?H4sIAAAAAAAAC02Sb0gTYRzHfXZ36zSvzs3prxFkg/5YOSwrBmHoC+tFBaZF?= =?us-ascii?Q?0Att6tlG7k/bjBlFYUXknxBfWDPDmZpaW6VSTjOJJVJLKoZZTNKWpjgzTdDI?= =?us-ascii?Q?ULvbndW9+tzv+32+z/d5eEhMclWsEIfhYSEhUXG3zcrU+NG+qw2EarYwQVU+?= =?us-ascii?Q?9xGpliZeE6rmV624qsRlw5OI1JDjhFafZbCeIDTTL9+tMA7R1tZuO7qIHFQR?= =?us-ascii?Q?CiMldBOCm87FFfyPHUHRm15REQolxXQcPHrmxDiOpPfAdPVljDNhdDuC8Wvu?= =?us-ascii?Q?oElKp4C7Z1DMm/bBwGALm0SyrITf/eu4MU5vgLGqG4hjik6GkltdIn6znwi8?= =?us-ascii?Q?836cE0LpQ+B8URvcDNFR8NPjCOZjdDT4RqqDDPRWaAt0ETxvg5b+ezjPe2Cy?= =?us-ascii?Q?+7cwp6Gu8y3GswJKB74La2UwPrxIcN2A7Wa/sorHw3DLF887dsG3Oq+QmAgv?= =?us-ascii?Q?nQtCyn648rBGmB8Cd22dwOtgaXBI4CSY7GgT/DHw6/kvbDln1Nso8AGory8V?= =?us-ascii?Q?eAd8mC0Ul6HYyv8OyfM2sD+dEfOcCBWOeYG3wt2aCawyeIsR8Mo2gtsRcQ/J?= =?us-ascii?Q?GItOrc1TqrN1jFGdfYqxKLMNuhbEPpKPsSB2oS9zm9xoDSlSyKj7RmWqZFWW?= =?us-ascii?Q?IadAozZrMk35eYzZjYAMV0RSY6dZjTIb1Tqz9uSytJYkFUCNcFKEiTnJWHO1?= =?us-ascii?Q?eRbGxMsetEYeTS1xIs2t0+Tr/2peJJNLqeEcVgs3Miad1sLPfUhK+kUSXG/Q?= =?us-ascii?Q?M3K2Ygj7bUYBFE0ihZTPCtfqLX8rBNh2IrZdU2Qc186i/ifJL6Ky3Qs/jrjS?= =?us-ascii?Q?F3or0qTJ/qkBIvNMr2GlrXil/3OMtSfMn1HTZjsbV/HBkbExbzClY++l60O9?= =?us-ascii?Q?HV8bzuWOdW5+3FhLWT0e0dHZkvXHc9IDTx6cDhwUzXzaWV2AiRJKMpmy5rl5?= =?us-ascii?Q?j698/Pz05bpWmzPCnfjGNXXuQnvTnferZVXF8rS+YwrcrFFv34KZzOo/BSzT?= =?us-ascii?Q?X5oDAAA=3D?= Cc: "DRAGE, Keith \(Keith\)" , James Polk , "insipid@ietf.org" , Gonzalo Camarillo Subject: Re: [Insipid] Is session ID in conference in scope of the WG 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, 17 Aug 2012 16:38:56 -0000 I didn't get that view from re-reading that thread. But anyway just because it's out of scope doesn't mean a proposed solution = can't cover it - if even by accident/coincidence of its solution design. It just means we can't have requirements to cover it, and proposed solution= s don't need to address it. Both draft-jones and draft-kaplan models happe= n to address the "simple" 3PCC case, and the draft-jones might try to addre= ss the more complicated cases (I think). -hadriel On Aug 7, 2012, at 9:41 AM, Hutton, Andrew wrote: > Hi, >=20 > I looked back through the thread and found this discussion which related = to 3PCC http://www.ietf.org/mail-archive/web/dispatch/current/msg03950.html= .=20 >=20 > In this discussion it is my interpretation that 3PCC is consider in scope= . The the following snippet is taken from this thread. >=20 > Paul Kyzivat asks the question. >=20 >>> How do you feel about a 3PCC controller? Is it a B2BUA? If it does a >>> transfer then it goes through stages when it has two dialogs, then >>> three, then two. From past discussions, I think you expect there will b= e >>> more than one session-id covering that. >=20 > The response from Paul Jones. >=20 >> A PBX-type device would be a B2BUA in my mind and, yes, there would be >> different Session-IDs since there would be different devices end-to-end.= In >> this case, the B2BUA truly is just an intermediary device, not a termina= ting >> device. >=20 > My interpretation is this discussion is that 3PCC is within scope as the = 3PCC controller is "just an intermediary device" it is just confirmation th= at a 3PCC transfer results in a new session identifier as per the basic end= point initiated case. >=20 > In any case in the basic 3PCC call flow the result following the initial = dialog establishment is a simple 2 party call which is no different to the = case when the flow was initiated by an endpoint (i.e. 2 dialogs with a B2BU= A in the middle which mangles the dialog identifiers) so I don't understand= why it would be considered out of scope. >=20 > Regards > Andy >=20 From HKaplan@acmepacket.com Fri Aug 17 09:43:27 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 DD63521F85C5 for ; Fri, 17 Aug 2012 09:43:27 -0700 (PDT) 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, GB_I_LETTER=-2] 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 evtnJiPU1jj0 for ; Fri, 17 Aug 2012 09:43:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C53321F85A3 for ; Fri, 17 Aug 2012 09:43:26 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 17 Aug 2012 12:43:25 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.149]) by Mail2.acmepacket.com ([169.254.2.126]) with mapi id 14.02.0283.003; Fri, 17 Aug 2012 12:43:25 -0400 From: Hadriel Kaplan To: "insipid@ietf.org" Thread-Topic: [Insipid] Backward compability between draft-jonesand draft-kaplan Thread-Index: AQHNfJdrhYzcmzvsT0CS6FBxAIvWrA== Date: Fri, 17 Aug 2012 16:43:24 +0000 Message-ID: References: <79C4240C13B4C84B910850B96B1B431204AC7429@DEMUEXC035.nsn-intra.net> <1E97FFD1485F1142BC075FF145A53A1E1246DE@A04067.BGC.NET> In-Reply-To: <1E97FFD1485F1142BC075FF145A53A1E1246DE@A04067.BGC.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <570FE25ED6CECE4DA4AEE4C9C82D894C@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: =?us-ascii?Q?H4sIAAAAAAAAC02Sa0hTcRjG/e+cM4+yE8ep26tE1kDyum5kZUhKgh8isAuI?= =?us-ascii?Q?g6ipJzdyF3YmrKBQwz6Y0wbhjcJLWs40RYmJt3SaOYOEGWlKVipBKw0LLfHW?= =?us-ascii?Q?tnO0zqffeZ7nfc57/vxJTFwglAn9cX8fH0lsi1GeenCoruIJcby4sxJPRKk+?= =?us-ascii?Q?CkKtzdCZrhAqx2QHoS+MNw0vTmF56PaBIuRPimkrAtudcYJ7qUHQ8rrMtwj5?= =?us-ascii?Q?kUI6Ftp6WzAPB9GRsDT5xsuB9Dl4O3+f4PTzMHbXhXMsh43uB95ZnA6HspEB?= =?us-ascii?Q?b56ik+CZpRjjPrCOYGm1SeAx/OhkMNt7vEWIlsDv0WavjtFSmJqv9jLQ0WBz?= =?us-ascii?Q?9REcx0D7uyac45OwMLTG6zTU94xhHMvAPL3IzwbD17lNPiOHF2XtfOYcrFW0?= =?us-ascii?Q?+nJ8FL7XO/nOBBhp2eAzKVDYWsvrZ8H+qJ7nMNia+chzIix02fj8XljtX8W2?= =?us-ascii?Q?e744G3k+Aw0NZp4Pw8RygZDjE7BgqcHvoYiq/36Z4xio6f4p5DgBbM0dvB4N?= =?us-ascii?Q?j2u/YVXeMw0AR+U8XoOIJhTMGDVKdY5cmalh9MrMa4xRnqnTtCP3nZiMBGEn?= =?us-ascii?Q?ml3Zb0chpEAWTD3Vy1PFuzJ0WddVSlZ12ZCbw7B2BKRIFkRNG9wexeqVGlad?= =?us-ascii?Q?vW3tJkkZUOMeK8DAZDOmq+ocI2Pg7FEUTm45HB+QGNfqtEyolHJ4grSnQ5Wr?= =?us-ascii?Q?3ck5UXBoIDWX5fZEesagURs5fQoFkp8F/LB7XR/3E4FcSEoiWSDV7+kSqbXG?= =?us-ascii?Q?nXVc7k0F7k2tQbGeTY3Kf1ZoHkqzvmwMC9IuDaznfirvjbogN02LZwcLbp36?= =?us-ascii?Q?YVp+qAmLO23NGFXU+tluPJ9TCIrXu0J+pUmdka6pdIvvn0tHUs3xGJtcsi9r?= =?us-ascii?Q?ne1qKplteyW3iBQzq+/zy/vZOm1pkuTiSuNED5VCRlUP5u8ZSbTElWwWZR8r?= =?us-ascii?Q?VTXbJKF9bTeH02U4q1IeisIMrPIvAFAfJZUDAAA=3D?= Subject: Re: [Insipid] Backward compability between draft-jonesand 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, 17 Aug 2012 16:43:28 -0000 In case it wasn't obvious: +1 FYI, the new draft should be coming out next week or week after. -hadriel On Aug 17, 2012, at 5:23 AM, VAN GEEL Jan (CIS/SCC) wrote: > +1 >=20 > Jan Van Geel > IT and Network Specialist > Belgacom SDE/SDV/PSE/FVC > Tel: +32 2 202 1035 > Tel: +32 2 207 9032 > Email : jan.van.geel@belgacom.be >=20 >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f Of Leis, Peter (NSN - DE/Munich) > Sent: Friday 17 August 2012 11:11 > To: christer.holmberg@ericsson.com; insipid@ietf.org > Subject: Re: [Insipid] Backward compability between draft-jonesand draft-= kaplan >=20 > I support the proposal to make the INSIPID mechanism backward compatible = with the mechanism in draft-kaplan-session-id. >=20 > Regards > Peter >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f Of ext Andrew Allen > Sent: Friday, August 17, 2012 12:00 AM > To: shida@ntt-at.com; christer.holmberg@ericsson.com > Cc: insipid@ietf.org > Subject: Re: [Insipid] Backward compability between draft-jonesand draft-= kaplan >=20 >=20 > If its at all possible to make the INSIPID solution backwards compatible = with the Kaplan draft I would strongly urge we do this. >=20 > With several pre-standards deployments already based on Kaplan draft ther= e is a real danger that INSIPID solution will become an unimplemented stand= ard if it is not backward compatible with what has already been deployed. >=20 > While we don't guarantee to maintain compatibility with earlier versions = of drafts it is in our interest to attempt to be compatible with what has b= een deployed commercially. >=20 > Running code is of course something we desire and believe in! >=20 > Andrew >=20 > ----- Original Message ----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Wednesday, August 15, 2012 12:01 PM > To: Christer Holmberg > Cc: insipid@ietf.org > Subject: Re: [Insipid] Backward compability between draft-jones and draft= -kaplan >=20 >=20 > As we have the kaplan spec implemented and deployed, I support Christer's= proposal. >=20 > Regards > Shida >=20 > On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> In Vancouver, I expressed a wish to make the INSIPID mechanism > backward compatible with the draft-kaplan-session-id one, the reason bein= g that it has been around for a relatively long time, and has been implemen= ted and deployed. >>=20 >> I compared the suggested draft-jones solution with the draft-kaplan > solution, and I think there are ways to achieve backward compability. >>=20 >>=20 >> -------------- >>=20 >>=20 >> FIRST, looking purely at the ABNF syntax: >>=20 >> The jones ABNF is: >>=20 >>=20 >> Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >>=20 >>=20 >>=20 >> The kaplan ABNF is: >>=20 >>=20 >>=20 >> Session-ID =3D "Session-ID" HCOLON sess-id >>=20 >> *( SEMI generic-param ) >>=20 >> sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >>=20 >>=20 >>=20 >>=20 >>=20 >> Now, assuming 32 chars is enough to carry ONE UUID, jones applications > could put the SECOND UUID in a header field parameter (generic-param), ra= ther than combining it with the received UUID. >>=20 >>=20 >>=20 >> Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. >>=20 >>=20 >>=20 >> A UUID can contain characters 0-9 and a-f and A-F. >>=20 >>=20 >>=20 >> So, a jones entity would have to be prepared to receive g-z. >>=20 >>=20 >>=20 >> And, as kaplan entity is not prepared to receive capital A-F, a jones > entity would have to only use small letters. But, that should not be a pr= oblem, afaik, as they have the same meaning as far as UUID is concerned. >>=20 >>=20 >>=20 >> -------------- >>=20 >>=20 >>=20 >> SECOND, looking at it would work functionwise: >>=20 >>=20 >>=20 >> There are two main alternatives: >>=20 >>=20 >>=20 >>=20 >>=20 >> 1. Second UUID is added even when one entity is kaplan compliant >>=20 >> 2. Second UUID is not added when one entity is kaplan compliant >>=20 >>=20 >>=20 >>=20 >>=20 >> Alternative 1: >>=20 >>=20 >>=20 >> When a kaplan entity inserts the first UUID (I use that as a general > term, eventhough a kaplan entity does not use UUIDs), one must assume tha= t it is prepared to receive a response from a jones entity which has added = the second UUID into the header field parameter. >>=20 >>=20 >>=20 >> When a jones entity inserts the first UUID, one must assume that it is > prepared to receive a response from a kaplan entity where the second UUID= has *not* been added. >>=20 >>=20 >>=20 >>=20 >>=20 >> Alternative 2: >>=20 >>=20 >>=20 >> When a kaplan entity inserts the first UUID, the jones entity detects > (using some identify-a-kaplan-entity mechanism) that it comes from a kapl= an entity, so it does not insert a seoncd UUID in the first place. >>=20 >>=20 >>=20 >> As in alternative 1, when a jones entity inserts the first UUID, it > has to be prepared to receive a response where the second UUID has not be= en added (the identify-a-kaplan-entity mechanism might also inform the jone= s entity that the response comes from a kaplan entity. >>=20 >>=20 >>=20 >>=20 >>=20 >> -------------- >>=20 >>=20 >>=20 >> Now, there will of course be cases, where two UUIDs are required, that > won't work. But, kaplan entities would be able to use the session-id for = whatever they've used it so far. >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >>=20 >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 > ________________________________ >=20 > ***** Disclaimer ***** > http://www.belgacom.be/maildisclaimer > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From HKaplan@acmepacket.com Fri Aug 17 10:47: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 9F6FC11E80D1 for ; Fri, 17 Aug 2012 10:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, GB_I_LETTER=-2] 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 YBUWC7iHupBn for ; Fri, 17 Aug 2012 10:47:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B035B11E809B for ; Fri, 17 Aug 2012 10:47:40 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 17 Aug 2012 13:47:36 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.149]) by Mail2.acmepacket.com ([169.254.2.126]) with mapi id 14.02.0283.003; Fri, 17 Aug 2012 13:47:36 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: session-id ABNF (Was: Backward compability between draft-jones and draft-kaplan) Thread-Index: AQHNfKBi2n2oQiD9n0aMHrsrBqV3wA== Date: Fri, 17 Aug 2012 17:47:35 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: =?us-ascii?Q?H4sIAAAAAAAAC02Sf0gTcRjG/e5u8xyenJu6V7OMgZqpM4NyGoX1h0FWmEGF?= =?us-ascii?Q?gTntcsNtyjbLKPIXgohLC5E0K8UpOrRSRMWy1H6Q/lOI6ZiamBKpGeTPVNLu?= =?us-ascii?Q?dqd1f33ued73+T7f4whMki+Si8S42MnJK7QzXxF3oN2a3yhUFpZZBcrizgo8?= =?us-ascii?Q?WhDnlCDU6JPTs5KE6uV1m3NGS0BW++oCykHFe4qQmJBQjQjME3nCIuTCvFQj?= =?us-ascii?Q?WOm5xbKICoXn3c0Yyx7UYRhZNAtYxqggaKgddWZZSl2G4aYWZ24mCdbnN3CO?= =?us-ascii?Q?FTBprUcs45Q/vO4YdzBJHYf8Wk6XUBfh/dNeB7tQl2CzZcmRgygvWB1o4s+S?= =?us-ascii?Q?gX36iYOBCoaO2VdCjkOgddiKc3wE5t9u8DoFlpcfMY7lYB79ye96wszUJj+j?= =?us-ascii?Q?gLYaC3MWwfA5KH3kzsmH4IdlkI88Ch+a//AxJ6HgWQ2vn4G+WgvPfrD1ZYLn?= =?us-ascii?Q?aJjv6uDn98Jazxq2nfNtsIHnWKirM/N8EEaW80SlKKjyv1tyHALVLxZElUw7?= =?us-ascii?Q?jFkvmwBODob6mjms0vER3aG/YhqvRkIr8qRNOpVGq1Cl6OgMVUoabVKkpOta?= =?us-ascii?Q?EfNT2IJA1Im+rgT2IW9CIPckY7IVcRK35PSrN9Uqo/qKIVNLG/sQEK5yD7I6?= =?us-ascii?Q?l/FIY4ZKZ9Skblu+BCEHsp613A10Kp11TaM10QbOHkD+xFZ//ziS4Pp0Pe0j?= =?us-ascii?Q?I0vYQYrNUGfqd+YGkaePlLxwg/FcM2iDTmPidDuSEpMCfpmp68Q8+9AskhFI?= =?us-ascii?Q?LiW72CxXjd60U2eWaSpgmjZ6hLJNTap/lk8Oihm+Vx4YeH4xgrZmn76vrNyF?= =?us-ascii?Q?V0Ru+S29KXG7PnWKOv1deazW39rXbNv9y95r1xWqxdoSS5v7gul35IOWtY4x?= =?us-ascii?Q?WViReMbvbKQ1amapvLQgKlASEotZxua6EtfvBHc/vDscU/UusTRsSGvzvh2e?= =?us-ascii?Q?YBp6HGFM+zRU9XkzvtP3REA8mSvHjWpV+H7MYFT9BY5LTTiWAwAA?= Cc: "insipid@ietf.org" Subject: [Insipid] session-id ABNF (Was: 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, 17 Aug 2012 17:47:41 -0000 When we talked about this in Vancouver I was thinking there wouldn't be any= problem going to/from UUID syntax, because going to/from UUIDs in H.323 wa= s talked about a long, long time ago for session-id. But I forgot about th= e bug in the draft-kaplan ABNF... Since version 01 of draft-kaplan-sip-session-id in 2008, which later became= draft-kaplan-dispatch-session-id, the rules for generating the session-id = always made it lower-case *hex* characters. I.e., the g-z range wasn't act= ually possible. The ABNF for it didn't get fixed until draft-kaplan-dispat= ch-session-id-01 in April 2010, but that also dropped it to 16 characters o= f hex because the algorithm changed, and then 3 months later reverted back = to 32 characters and the correct ABNF. So that begs the question of *which* version of draft-kaplan we want to be = backwards compatible with. Since draft-kaplan-dispatch-session-id-01 only = existed for 3 months, I think we can ignore that one. And since everything= else only used hex characters, except the initial 00-draft which itself on= ly existed for 4 months, I think we can ignore that one too. Therefore, as far as I can tell we shouldn't have a problem converting draf= t-kaplan session-ids to/from UUIDs for H.323/whatever. -hadriel On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: > Hi, >=20 > In Vancouver, I expressed a wish to make the INSIPID mechanism backward c= ompatible with the draft-kaplan-session-id one, the reason being that it ha= s been around for a relatively long time, and has been implemented and depl= oyed. >=20 > I compared the suggested draft-jones solution with the draft-kaplan solut= ion, and I think there are ways to achieve backward compability. >=20 >=20 > -------------- >=20 >=20 > FIRST, looking purely at the ABNF syntax: >=20 > The jones ABNF is: >=20 >=20 > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >=20 >=20 >=20 > The kaplan ABNF is: >=20 >=20 >=20 > Session-ID =3D "Session-ID" HCOLON sess-id >=20 > *( SEMI generic-param ) >=20 > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] >=20 >=20 >=20 >=20 >=20 > Now, assuming 32 chars is enough to carry ONE UUID, jones applications co= uld put the SECOND UUID in a header field parameter (generic-param), rather= than combining it with the received UUID. >=20 >=20 >=20 > Of course, the first UUDI (carried in sess-id) can only contains characte= rs 0-9 and a-z. >=20 >=20 >=20 > A UUID can contain characters 0-9 and a-f and A-F. >=20 >=20 >=20 > So, a jones entity would have to be prepared to receive g-z. >=20 >=20 >=20 > And, as kaplan entity is not prepared to receive capital A-F, a jones ent= ity would have to only use small letters. But, that should not be a problem= , afaik, as they have the same meaning as far as UUID is concerned. >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > SECOND, looking at it would work functionwise: >=20 >=20 >=20 > There are two main alternatives: >=20 >=20 >=20 >=20 >=20 > 1. Second UUID is added even when one entity is kaplan compliant >=20 > 2. Second UUID is not added when one entity is kaplan compliant >=20 >=20 >=20 >=20 >=20 > Alternative 1: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID (I use that as a general term= , eventhough a kaplan entity does not use UUIDs), one must assume that it i= s prepared to receive a response from a jones entity which has added the se= cond UUID into the header field parameter. >=20 >=20 >=20 > When a jones entity inserts the first UUID, one must assume that it is pr= epared to receive a response from a kaplan entity where the second UUID has= *not* been added. >=20 >=20 >=20 >=20 >=20 > Alternative 2: >=20 >=20 >=20 > When a kaplan entity inserts the first UUID, the jones entity detects (us= ing some identify-a-kaplan-entity mechanism) that it comes from a kaplan en= tity, so it does not insert a seoncd UUID in the first place. >=20 >=20 >=20 > As in alternative 1, when a jones entity inserts the first UUID, it has t= o be prepared to receive a response where the second UUID has not been adde= d (the identify-a-kaplan-entity mechanism might also inform the jones entit= y that the response comes from a kaplan entity. >=20 >=20 >=20 >=20 >=20 > -------------- >=20 >=20 >=20 > Now, there will of course be cases, where two UUIDs are required, that wo= n't work. But, kaplan entities would be able to use the session-id for what= ever they've used it so far. >=20 >=20 >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Fri Aug 17 11:49:38 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 7282D11E80E1 for ; Fri, 17 Aug 2012 11:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, GB_I_LETTER=-2] 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 WZfuDoeUH2iF for ; Fri, 17 Aug 2012 11:49:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC0811E80A5 for ; Fri, 17 Aug 2012 11:49:37 -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 q7HInXel008077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Aug 2012 14:49:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1345229374; bh=d/L1XdbP81IgiQFAE8WY0ahHan6ViN+yIZLO6KoHW7A=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=gFncDs7BwANSPVOMoZoxr3Bg/XUbPHZ5WaXpTnQ7NZnKhRpvO5yh37+s2oijOoBoN kriksuXx/nZ2ytpb5l+6z8B9G3HCigH1FcLiLs9+Fgewmx1fXvuW/iv9q1Ixvdnhaq ZOW8ai6kQJUa7bd4qSNhJR+gEiSUV599GEAZe7FY= From: "Paul E. Jones" To: "'Christer Holmberg'" , References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 17 Aug 2012 14:49:39 -0400 Message-ID: <015001cd7ca9$0f2ee060$2d8ca120$@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: AQGQlrwc96LJmyJNZehiP4Ej0pCKD5fYGYNA Content-Language: en-us 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, 17 Aug 2012 18:49:38 -0000 Christer, The reason for introducing the use of two UUIDs was to address a few signaling scenarios that I do not think Hadriel's draft addresses. I might be wrong, so let me present some assertions and ask questions. If enterprise user A calls enterprise user B, you want to have an identifier end-to-end for that call. What if the PBX at B redirects that call to enterprise user C. Would you expect to see the same Session-ID or a different one? If you want to use the same ID. I would venture to guess you have two IDs today in practice. Let suppose the call to B results in both B and C ringing and 180 messages coming back from both. Would you want the same Session-ID on both? The draft we submitted would allow for each device to uniquely represent itself, so we would have two Session-IDs, in effect, with one disappearing when the call is answered. Assume Alice calls Bob. There is a Session-ID between Alice and Bob. Now, assume Bob presses a button on his phone that results in transferring the call to Carol. Do we retain the same Session-ID or does it change? Let's assume Alice calls Bob, so we have a Session-ID between Alice and Bob. Suppose Carol calls Bob. There is a different Session-ID between Carol and Bob. Now, suppose Bob presses a button on his phone such that Alice and Carol are now talking directly to each other and Bob drops out of the call. What is the Session-ID? Are there two Session IDs or one? Suppose Alice calls Bob. At or about the same time, Alice transfers the Alice/Bob call to Sue and Bob transfers the Alice/Bob call to Sue. What is the Session-ID between Carol/Sue? Suppose Alice calls Bob (Session ID A/B). Suppose Dave calls Alice (Session ID D/A) and she puts Bob on hold. While waiting, Bob place a separate call to Sue (Session ID B/S). Later and at or about the same time, Alice transfers the Alice/Bob call to Dave and Bob transfers the Alice/Bob call to Sue. What is the Session-ID? We went down this path with H.323 trying to identify a call end-to-end. Because of the wide variety of ways in which calls can be manipulated, a single identifier assigned on one end would not work, since there would always be a conflict over IDs. I see the same challenge with SIP in some of these flows. That's why we suggested concatenating two UUIDs and expecting UUIDs to change at any time. Such changes indicate a change in the remote terminal device. I have no objection to trying to use similar syntax as what Hadriel had in his draft, but I do think we need to allow use of two UUIDs to identify the session end-to-end to address some of the example scenarios above. So, perhaps we have: Session-ID: A;p=B Where A = Alice's UUID p = some parameter name B = Bob's UUID Alice would include only A in the INVITE. Bob could put all of the above in the reply. Now, if Bob sends an INVITE to Alice, how would it construct the above header? Exactly the same way? Let's consider the case where Carol calls Bob (C||B2): Session-ID: C;p=B2 Bob pushes a button on his phone to transfer the call with Carol to Alice. The PBX would send an INVITE to Alice. What would be in the Session-ID? What we were proposing in the Jones draft is (and given recent discussion of putting the sender's UUID first): Session-ID: C:A This would tell Alice that the remote device's UUID is now 'C'. Alice would know her own UUID, but could reply differently if required (if we had that odd race condition I mentioned before and above): Session-ID: A:C Trying to fit this with the Kaplan draft, what would the PBX send to Alice? It might also send an INVITE to Carol. What would it send? In one direction or the other, the original Session-ID value must change, I believe. I'm not sure if that would be compatible with the current Kaplan draft. The challenge is with forcing the requirement that the value following "Session-ID" can never change, because it will. Calls get routed and re-routed from one device to another (IVR, person 1, person 2, music on hold server, person 3, etc.) Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Tuesday, August 14, 2012 4:27 PM > To: insipid@ietf.org > Subject: [Insipid] Backward compability between draft-jones and draft- > kaplan > > Hi, > > In Vancouver, I expressed a wish to make the INSIPID mechanism backward > compatible with the draft-kaplan-session-id one, the reason being that it > has been around for a relatively long time, and has been implemented and > deployed. > > I compared the suggested draft-jones solution with the draft-kaplan > solution, and I think there are ways to achieve backward compability. > > > -------------- > > > FIRST, looking purely at the ABNF syntax: > > The jones ABNF is: > > > Session-ID-UUID = "Session-ID-UUID" HCOLON UUID > > > > The kaplan ABNF is: > > > > Session-ID = "Session-ID" HCOLON sess-id > > *( SEMI generic-param ) > > sess-id = 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > > > > Now, assuming 32 chars is enough to carry ONE UUID, jones applications > could put the SECOND UUID in a header field parameter (generic-param), > rather than combining it with the received UUID. > > > > Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. > > > > A UUID can contain characters 0-9 and a-f and A-F. > > > > So, a jones entity would have to be prepared to receive g-z. > > > > And, as kaplan entity is not prepared to receive capital A-F, a jones > entity would have to only use small letters. But, that should not be a > problem, afaik, as they have the same meaning as far as UUID is concerned. > > > > -------------- > > > > SECOND, looking at it would work functionwise: > > > > There are two main alternatives: > > > > > > 1. Second UUID is added even when one entity is kaplan compliant > > 2. Second UUID is not added when one entity is kaplan compliant > > > > > > Alternative 1: > > > > When a kaplan entity inserts the first UUID (I use that as a general term, > eventhough a kaplan entity does not use UUIDs), one must assume that it is > prepared to receive a response from a jones entity which has added the > second UUID into the header field parameter. > > > > When a jones entity inserts the first UUID, one must assume that it is > prepared to receive a response from a kaplan entity where the second UUID > has *not* been added. > > > > > > Alternative 2: > > > > When a kaplan entity inserts the first UUID, the jones entity detects > (using some identify-a-kaplan-entity mechanism) that it comes from a > kaplan entity, so it does not insert a seoncd UUID in the first place. > > > > As in alternative 1, when a jones entity inserts the first UUID, it has to > be prepared to receive a response where the second UUID has not been added > (the identify-a-kaplan-entity mechanism might also inform the jones entity > that the response comes from a kaplan entity. > > > > > > -------------- > > > > Now, there will of course be cases, where two UUIDs are required, that > won't work. But, kaplan entities would be able to use the session-id for > whatever they've used it so far. > > > > > > Regards, > > > > Christer > > > > > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From HKaplan@acmepacket.com Fri Aug 17 15:14:26 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 42F8021E8063 for ; Fri, 17 Aug 2012 15:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_BACKHAIR_34=1, J_BACKHAIR_53=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 abKKW3uqW7cE for ; Fri, 17 Aug 2012 15:14:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB9EF11E80D1 for ; Fri, 17 Aug 2012 15:14:24 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 17 Aug 2012 18:14:21 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.149]) by Mail2.acmepacket.com ([169.254.2.126]) with mapi id 14.02.0283.003; Fri, 17 Aug 2012 18:14:21 -0400 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNfMWm6uZ/nWEPrkix5mPMBBZBFQ== Date: Fri, 17 Aug 2012 22:14:19 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <015001cd7ca9$0f2ee060$2d8ca120$@packetizer.com> In-Reply-To: <015001cd7ca9$0f2ee060$2d8ca120$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <93F7B7FA94EB7F46B618CD0EB811776A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: =?us-ascii?Q?H4sIAAAAAAAAC02Sa0gUURiG9+zMbqM4Mbrqfm6RMmHmbbuAJaRgRESFYYZ/?= =?us-ascii?Q?+mOjTu6Suy67K5n1wwLDxC6G5QXNlSR1S7SlWsn7El02zTRRU7xmhZbRzUxM?= =?us-ascii?Q?bWZntM6v53zve77vPYdDYF7LMlrujrtLJL7h0Q513Pam0r4GWWT+1St4ZG6h?= =?us-ascii?Q?VRqZ31iCx2BxkuMyrT4pPfOETFNjpwwLAZn1dyuwbFSmykPuhBdVi8C+NIiE?= =?us-ascii?Q?jQVBefY4nofcCDkVDg0tdRjP3lQodPZPuBijGLAUrbg8Cioefn7NlQqeY1DW?= =?us-ascii?Q?3SOyGs6/nEY841QgOJ/VrOOZpPbCn65pcVgegt+Pml0mNyoa3rd/dA1AlC/M?= =?us-ascii?Q?O+9JhWFKGJqqcDFwIewzrTKBw8DWb8UF3gOzTxbFOgVVzd2YwDRcHv4invWB?= =?us-ascii?Q?6XfLokcNw11FoucoFBe3yQWOgM9VvWLPaHhetyR6DkBOfaVYjwXH7SqR/WFl?= =?us-ascii?Q?dEzkGJh9bBf9AbDQvoCt9vnQW8MxwXE8dFUECeWdMDB3QX4NBZf+d0uBw8DS?= =?us-ascii?Q?9F0ucDTkvKmWCRwKdyo/YaWuZ/SEFyVTuAXJrMiHNesYbZqaSdaxBib5FGtW?= =?us-ascii?Q?J6frbIj7G4PBIG9Ek7+CHMiPkNI+5KYOdZzX+qT0lDMaxqRJNGaksSYHAsKD?= =?us-ascii?Q?9iZVvEaaDIzOpE1dlTYSBA3kFl7yNLKpbOZJbZqZNQqyE/mplKQnL1L8OU2G?= =?us-ascii?Q?fk3rRT4qBdnXwmkeBtao05qF+hBSEBNSL1yfrmdVXEQJt7aiGaQkEK0gw/le?= =?us-ascii?Q?Hlq9eS3CDJdOyqWr9Q7n05mZf5IqGyWkGPc7e2ItRFXh2PirOf8suDnS1nnI?= =?us-ascii?Q?8eB61LcfWV2pg6VMsvUgbVg5YiiYj5gctT3clX+6YXPHiNu5werKW/S+gumL?= =?us-ascii?Q?9cTuswp6PNMW1aImO96O3d+QFUheqpkJGU5wb+0JMiTNKgeehh1eljRLLQX2?= =?us-ascii?Q?xdDGbbE3yq1EYvBw62saN2mYHSGY0cT8BUwSB/+RAwAA?= Cc: "" , Christer Holmberg 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, 17 Aug 2012 22:14:26 -0000 I don't know what Christer's proposal would be exactly, but what I proposed= in Vancouver would be to make the "second" id a header parameter. So yes it's like this: Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6;p=3D2128675309beef15f00d4dead2= fee155 Alice generates the header-value, Bob inserts the param. Both Alice and Bob use the same header sess-id value and param-value for al= l in-dialog requests, regardless who's sending what. (ie, upstream requests= from Bob still have the same sess-id;param, and there are no re-INVITEs/UP= DATEs required to change it because it can't change in that SIP dialog) Note that the header sess-id value (the "f81d4fae7dec11d0a76500a0c91e6bf6")= and the param value (the "2128675309beef15f00d4dead2fee155") are separate = keys/values, so if you're a monitoring device you'd have a lookup table wit= h each separate key.=20 So suppose a scenario such as you describe: > Suppose Alice calls Bob (Session ID A/B). Suppose Dave calls Alice (Sess= ion > ID D/A) and she puts Bob on hold. While waiting, Bob place a separate cal= l > to Sue (Session ID B/S). Later and at or about the same time, Alice > transfers the Alice/Bob call to Dave and Bob transfers the Alice/Bob call= to > Sue. What is the Session-ID? I'm going to use U/V/W/X/Y/Z instead of A/B/etc. because the sesssion-id va= lues are just random numbers - they don't identify a user/identity and we t= end to think that when we use 'A' for Alice's session-id, and 'B' for Bob's= . The setup is this regardless: Alice <--> Bob =3D U;V Dave <--> Alice =3D W;X Bob <--> Sue =3D Y;Z As for what happens in the REFER transfer, we (INSIPID WG) get to decide... OPTION-1: I believe that following draft-kaplan model strictly, we'd have this: Alice sends REFER to Bob referring him to Dave, by putting 'W;X' in her REF= ER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of = 'W;X'. That continues to be the Session-ID of the (now) Bob <--> Dave sess= ion, so: Bob <--> Dave =3D W;X Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;Z' in = his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session= -ID of 'Y;Z'. That continues to be the Session-ID of the (now) Dave <--> S= ue session, so: Dave <--> Sue =3D Y;Z The above would be following the rule in draft-kaplan of copying the whole = Session-ID being referred-to in the Refer-To. -- OPTION-2: However an argument could be made that we could do this instead, and still = comply with draft-kaplan model: Alice sends REFER to Bob referring him to Dave, by putting 'W;V' in her REF= ER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of = 'W;V'. That continues to be the Session-ID of the (now) Bob <--> Dave sess= ion, so: Bob <--> Dave =3D W;V Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in = his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session= -ID of 'Y;W'. That continues to be the Session-ID of the (now) Dave <--> S= ue session, so: Dave <--> Sue =3D Y;W The above would be a rule of copying the Session-ID 'sess-id' field being r= eferred-to, but with a param value of the REFER's target created to the Ref= erer. (ie., "V" in the Alice<-->Bob call, and "W" in the Bob<-->Dave call) = If the REFER's target created both values, the param would be set to the s= ess-id field of that dialog. -- OPTION-3: OR, the rule could just be copying the Session-ID 'sess-id' field being ref= erred-to, but with a param value of the REFER's target sess-id field. Which means... Alice sends REFER to Bob referring him to Dave, by putting 'W;U' in her REF= ER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of = 'W;U'. That continues to be the Session-ID of the (now) Bob <--> Dave sess= ion, so: Bob <--> Dave =3D W;U Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in = his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session= -ID of 'Y;W'. That continues to be the Session-ID of the (now) Dave <--> S= ue session, so: Dave <--> Sue =3D Y;W -hadriel From christer.holmberg@ericsson.com Fri Aug 17 16:05:08 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 5271321F83EF for ; Fri, 17 Aug 2012 16:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.169 X-Spam-Level: X-Spam-Status: No, score=-5.169 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_BACKHAIR_34=1, J_BACKHAIR_53=1, 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 WZuICTKZstQH for ; Fri, 17 Aug 2012 16:05:07 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 934EF11E80A4 for ; Fri, 17 Aug 2012 16:05:06 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-ed-502ece173876 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 83.C2.12641.71ECE205; Sat, 18 Aug 2012 01:04:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 18 Aug 2012 01:04:55 +0200 From: Christer Holmberg To: Hadriel Kaplan , "Paul E. Jones" Date: Sat, 18 Aug 2012 01:04:54 +0200 Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNfMWm6uZ/nWEPrkix5mPMBBZBFZdenBD0 Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534086836B5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <015001cd7ca9$0f2ee060$2d8ca120$@packetizer.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra74Ob0AgxczDC3mXn7ObjH//jMm i/MXNjA5MHtsmryZzWPJkp9MHg37jrIHMEdx2aSk5mSWpRbp2yVwZfx+0MJW8FexouPNDfYG xv9SXYycHBICJhLbXjWwQNhiEhfurWfrYuTiEBI4xShxYdtRVghnAaPEtP2ngao4ONgELCS6 /2mDNIgIhEms2biRFcRmFtCWuHvuDdggFgFViYkb1rKD2MICQRI3Pk5jh6gPlphz/iITyBgR ASOJlrlJIGFegXCJDU8Os0OsOsAo0fLvGCtIDaeAk8SUdgmQGkag276fWsMEsUpc4taT+UwQ NwtILNlznhnCFpV4+fgfK0S9qMSd9vWMEPU6Egt2f2KDOXPZwtfMEHsFJU7OfMIygVFsFpKx s5C0zELSMgtJywJGllWMwrmJmTnp5eZ6qUWZycXF+Xl6xambGIHRdHDLb4MdjJvuix1ilOZg URLn1VPd7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMZBxZ0bjxFXXLtpdiVS5c0Vqnugm mdgry21EIv9wOmw/9ig+PnurssCVU73/1s4984YnKkggIvzOE6FT3+8vq/AQZ+rh+bhk6j51 t99nUz5Y/Pywdp2i7c2cF6tvJpcKLXplsvFsnTVTzg21hG/rVkraW7cX717LY/qsmbny97Jn C9V8eu6IHFRiKc5INNRiLipOBACsf8DxdAIAAA== Cc: "" 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, 17 Aug 2012 23:05:08 -0000 Hi, >I don't know what Christer's proposal would be exactly, but what I propose= d in Vancouver would be to >make the "second" id a header parameter. >So yes it's like this: >Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6;p=3D2128675309beef15f00d4dead= 2fee155 > >Alice generates the header-value, Bob inserts the param. >Both Alice and Bob use the same header sess-id value and param-value for a= ll in-dialog requests, regardless >who's sending what. (ie, upstream reques= ts from Bob still have the same sess-id;param, and there are no re->INVITEs= /UPDATEs required to change it because it can't change in that SIP dialog) > >Note that the header sess-id value (the "f81d4fae7dec11d0a76500a0c91e6bf6"= ) and the param value (the " >2128675309beef15f00d4dead2fee155") are separate keys/values, so if you're = a monitoring device you'd >have a lookup table with each separate key. That's a correct description of my proposal :) (I will look at the use-cases later.) Regards, Christer So suppose a scenario such as you describe: > Suppose Alice calls Bob (Session ID A/B). Suppose Dave calls Alice (Sess= ion > ID D/A) and she puts Bob on hold. While waiting, Bob place a separate cal= l > to Sue (Session ID B/S). Later and at or about the same time, Alice > transfers the Alice/Bob call to Dave and Bob transfers the Alice/Bob call= to > Sue. What is the Session-ID? I'm going to use U/V/W/X/Y/Z instead of A/B/etc. because the sesssion-id va= lues are just random numbers - they don't identify a user/identity and we t= end to think that when we use 'A' for Alice's session-id, and 'B' for Bob's= . The setup is this regardless: Alice <--> Bob =3D U;V Dave <--> Alice =3D W;X Bob <--> Sue =3D Y;Z As for what happens in the REFER transfer, we (INSIPID WG) get to decide... OPTION-1: I believe that following draft-kaplan model strictly, we'd have this: Alice sends REFER to Bob referring him to Dave, by putting 'W;X' in her REF= ER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of = 'W;X'. That continues to be the Session-ID of the (now) Bob <--> Dave sess= ion, so: Bob <--> Dave =3D W;X Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;Z' in = his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session= -ID of 'Y;Z'. That continues to be the Session-ID of the (now) Dave <--> S= ue session, so: Dave <--> Sue =3D Y;Z The above would be following the rule in draft-kaplan of copying the whole = Session-ID being referred-to in the Refer-To. -- OPTION-2: However an argument could be made that we could do this instead, and still = comply with draft-kaplan model: Alice sends REFER to Bob referring him to Dave, by putting 'W;V' in her REF= ER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of = 'W;V'. That continues to be the Session-ID of the (now) Bob <--> Dave sess= ion, so: Bob <--> Dave =3D W;V Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in = his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session= -ID of 'Y;W'. That continues to be the Session-ID of the (now) Dave <--> S= ue session, so: Dave <--> Sue =3D Y;W The above would be a rule of copying the Session-ID 'sess-id' field being r= eferred-to, but with a param value of the REFER's target created to the Ref= erer. (ie., "V" in the Alice<-->Bob call, and "W" in the Bob<-->Dave call) = If the REFER's target created both values, the param would be set to the s= ess-id field of that dialog. -- OPTION-3: OR, the rule could just be copying the Session-ID 'sess-id' field being ref= erred-to, but with a param value of the REFER's target sess-id field. Which means... Alice sends REFER to Bob referring him to Dave, by putting 'W;U' in her REF= ER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of = 'W;U'. That continues to be the Session-ID of the (now) Bob <--> Dave sess= ion, so: Bob <--> Dave =3D W;U Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in = his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session= -ID of 'Y;W'. That continues to be the Session-ID of the (now) Dave <--> S= ue session, so: Dave <--> Sue =3D Y;W -hadriel= From paulej@packetizer.com Sun Aug 19 18:56: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 CC8E621F865B for ; Sun, 19 Aug 2012 18:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-1.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_BACKHAIR_34=1, J_BACKHAIR_53=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 Aaxna2jqOJEm for ; Sun, 19 Aug 2012 18:56:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8821F8648 for ; Sun, 19 Aug 2012 18:56:40 -0700 (PDT) Received: from dyn-129.arid.us (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 q7K1uXZF001792 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 19 Aug 2012 21:56:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1345427796; bh=FhfZYHnRShbrCK00ptOxeCad22CgVszV2efSrQ7hf/U=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=Ir3F/8JFv6IQvZ1DL2ombCHKXmjaYOeOa4nmGrsPRmtYMkvQKKnE32MtUygTFqAn+ u6JRI0n5Fy3T/IhRYGi8Ud+1/MhZCPT2KOTk8ccfYoxCKhnP/cqYdYsr3+upS+0VBq Yi9xJlEVfarAODYlzGNkrC9M2zzO+UKctNhqBbHk= User-Agent: Kaiten Mail In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <015001cd7ca9$0f2ee060$2d8ca120$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----9X3HMLI9WV5ENA2PNCS0IOR72RERPM" From: "Paul E. Jones" Date: Sun, 19 Aug 2012 21:57:12 -0400 To: Hadriel Kaplan Message-ID: <51f40b7d-4f53-4500-b80a-1a935c4dd6ca@email.android.com> Cc: "" , Christer Holmberg 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: Mon, 20 Aug 2012 01:56:41 -0000 ------9X3HMLI9WV5ENA2PNCS0IOR72RERPM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Now let's assume no refer message is sent. For billing reasons, one would want to handle that transfer locally. So, Alice's call agent will send an invite to Dave to get him and Bob talking. I guess this will work the same. I'd expect the invite to contain Dave and Bob's uuid values, but how would we construct those? An invite would also get sent to Bob. What would that look like? Since the invite to Bob is actually being redirected to Sue in this scenario, I guess Bob's call agent needs to do the proper substitution of a uuid... replacing Bob's with Sue's. What do these headers look like? Whose ID is a parameter? Paul -------- Original Message -------- From: Hadriel Kaplan Sent: Fri Aug 17 18:14:19 EDT 2012 To: "Paul E. Jones" Cc: Christer Holmberg , "" Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan I don't know what Christer's proposal would be exactly, but what I proposed in Vancouver would be to make the "second" id a header parameter. So yes it's like this: Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6;p=2128675309beef15f00d4dead2fee155 Alice generates the header-value, Bob inserts the param. Both Alice and Bob use the same header sess-id value and param-value for all in-dialog requests, regardless who's sending what. (ie, upstream requests from Bob still have the same sess-id;param, and there are no re-INVITEs/UPDATEs required to change it because it can't change in that SIP dialog) Note that the header sess-id value (the "f81d4fae7dec11d0a76500a0c91e6bf6") and the param value (the "2128675309beef15f00d4dead2fee155") are separate keys/values, so if you're a monitoring device you'd have a lookup table with each separate key. So suppose a scenario such as you describe: > Suppose Alice calls Bob (Session ID A/B). Suppose Dave calls Alice (Session > ID D/A) and she puts Bob on hold. While waiting, Bob place a separate call > to Sue (Session ID B/S). Later and at or about the same time, Alice > transfers the Alice/Bob call to Dave and Bob transfers the Alice/Bob call to > Sue. What is the Session-ID? I'm going to use U/V/W/X/Y/Z instead of A/B/etc. because the sesssion-id values are just random numbers - they don't identify a user/identity and we tend to think that when we use 'A' for Alice's session-id, and 'B' for Bob's. The setup is this regardless: Alice <--> Bob = U;V Dave <--> Alice = W;X Bob <--> Sue = Y;Z As for what happens in the REFER transfer, we (INSIPID WG) get to decide... OPTION-1: I believe that following draft-kaplan model strictly, we'd have this: Alice sends REFER to Bob referring him to Dave, by putting 'W;X' in her REFER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;X'. That continues to be the Session-ID of the (now) Bob <--> Dave session, so: Bob <--> Dave = W;X Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;Z' in his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;Z'. That continues to be the Session-ID of the (now) Dave <--> Sue session, so: Dave <--> Sue = Y;Z The above would be following the rule in draft-kaplan of copying the whole Session-ID being referred-to in the Refer-To. -- OPTION-2: However an argument could be made that we could do this instead, and still comply with draft-kaplan model: Alice sends REFER to Bob referring him to Dave, by putting 'W;V' in her REFER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;V'. That continues to be the Session-ID of the (now) Bob <--> Dave session, so: Bob <--> Dave = W;V Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;W'. That continues to be the Session-ID of the (now) Dave <--> Sue session, so: Dave <--> Sue = Y;W The above would be a rule of copying the Session-ID 'sess-id' field being referred-to, but with a param value of the REFER's target created to the Referer. (ie., "V" in the Alice<-->Bob call, and "W" in the Bob<-->Dave call) If the REFER's target created both values, the param would be set to the sess-id field of that dialog. -- OPTION-3: OR, the rule could just be copying the Session-ID 'sess-id' field being referred-to, but with a param value of the REFER's target sess-id field. Which means... Alice sends REFER to Bob referring him to Dave, by putting 'W;U' in her REFER's Refer-To. Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;U'. That continues to be the Session-ID of the (now) Bob <--> Dave session, so: Bob <--> Dave = W;U Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in his REFER's Refer-To. Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;W'. That continues to be the Session-ID of the (now) Dave <--> Sue session, so: Dave <--> Sue = Y;W -hadriel ------9X3HMLI9WV5ENA2PNCS0IOR72RERPM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Now let's assume no refer message is sent. For billing reasons, one would want to handle that transfer locally. So, Alice's call agent will send an invite to Dave to get him and Bob talking. I guess this will work the same. I'd expect the invite to contain Dave and Bob's uuid values, but how would we construct those? An invite would also get sent to Bob. What would that look like?

Since the invite to Bob is actually being redirected to Sue in this scenario, I guess Bob's call agent needs to do the proper substitution of a uuid... replacing Bob's with Sue's.

What do these headers look like? Whose ID is a parameter?

Paul



From: Hadriel Kaplan <HKaplan@acmepacket.com>
Sent: Fri Aug 17 18:14:19 EDT 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "<insipid@ietf.org>" <insipid@ietf.org>
Subject: Re: [Insipid] Backward compability between draft-jones and draft-kaplan


I don't know what Christer's proposal would be exactly, but what I proposed in Vancouver would be to make the "second" id a header parameter.
So yes it's like this:
Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6;p=2128675309beef15f00d4dead2fee155

Alice generates the header-value, Bob inserts the param.
Both Alice and Bob use the same header sess-id value and param-value for all in-dialog requests, regardless who's sending what. (ie, upstream requests from Bob still have the same sess-id;param, and there are no re-INVITEs/UPDATEs required to change it because it can't change in that SIP dialog)

Note that the header sess-id value (the "f81d4fae7dec11d0a76500a0c91e6bf6") and the param value (the "2128675309beef15f00d4dead2fee155") are separate keys/values, so if you're a monitoring device you'd have a lookup table with each separate key. 

So suppose a scenario such as you describe:
Suppose Alice calls Bob (Session ID A/B).  Suppose Dave calls Alice (Session
ID D/A) and she puts Bob on hold. While waiting, Bob place a separate call
to Sue (Session ID B/S).  Later and at or about the same time, Alice
transfers the Alice/Bob call to Dave and Bob transfers the Alice/Bob call to
Sue.  What is the Session-ID?


I'm going to use U/V/W/X/Y/Z instead of A/B/etc. because the sesssion-id values are just random numbers - they don't identify a user/identity and we tend to think that when we use 'A' for Alice's session-id, and 'B' for Bob's.

The setup is this regardless:
Alice <--> Bob = U;V
Dave <--> Alice = W;X
Bob <--> Sue = Y;Z

As for what happens in the REFER transfer, we (INSIPID WG) get to
decide...

OPTION-1:
I believe that following draft-kaplan model strictly, we'd have this:
Alice sends REFER to Bob referring him to Dave, by putting 'W;X' in her REFER's Refer-To.  Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;X'.  That continues to be the Session-ID of the (now) Bob <--> Dave session, so:
Bob <--> Dave = W;X

Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;Z' in his REFER's Refer-To.  Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;Z'.  That continues to be the Session-ID of the (now) Dave <--> Sue session, so:
Dave <--> Sue = Y;Z

The above would be following the rule in draft-kaplan of copying the whole Session-ID being referred-to in the Refer-To.

--
OPTION-2:
However an argument could be made that we could do this instead, and still comply with draft-kaplan model:
Alice sends REFER to Bob referring him t!
 o Dave,
by putting 'W;V' in her REFER's Refer-To.  Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;V'.  That continues to be the Session-ID of the (now) Bob <--> Dave session, so:
Bob <--> Dave = W;V

Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in his REFER's Refer-To.  Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;W'.  That continues to be the Session-ID of the (now) Dave <--> Sue session, so:
Dave <--> Sue = Y;W

The above would be a rule of copying the Session-ID 'sess-id' field being referred-to, but with a param value of the REFER's target created to the Referer. (ie., "V" in the Alice<-->Bob call, and "W" in the Bob<-->Dave call)  If the REFER's target created both values, the param would be set to the sess-id field of that dialog.

--
OPTION-3:
OR, the rule could just be copying the Session-ID 'sess-id' field being referred-to, but wi!
 th a
param value of the REFER's target sess-id field.
Which means...
Alice sends REFER to Bob referring him to Dave, by putting 'W;U' in her REFER's Refer-To.  Bob's new INVITE with Replaces to Dave has a Session-ID of 'W;U'.  That continues to be the Session-ID of the (now) Bob <--> Dave session, so:
Bob <--> Dave = W;U

Later, Bob sends a REFER to Dave referring him to Sue, by putting 'Y;W' in his REFER's Refer-To.  Dave's new INVITE with Replaces to Sue has a Session-ID of 'Y;W'.  That continues to be the Session-ID of the (now) Dave <--> Sue session, so:
Dave <--> Sue = Y;W

-hadriel

------9X3HMLI9WV5ENA2PNCS0IOR72RERPM-- From HKaplan@acmepacket.com Sun Aug 19 20:40:33 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 ABE6521F8659 for ; Sun, 19 Aug 2012 20:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 RC+BwgPH57jt for ; Sun, 19 Aug 2012 20:40:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9521F8652 for ; Sun, 19 Aug 2012 20:40:32 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 19 Aug 2012 23:40:27 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.149]) by Mail2.acmepacket.com ([169.254.2.126]) with mapi id 14.02.0283.003; Sun, 19 Aug 2012 23:40:27 -0400 From: Hadriel Kaplan To: "Paul E. Jones" Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNfoWIYil05AF780WXgyr0DGaDPQ== Date: Mon, 20 Aug 2012 03:40:25 +0000 Message-ID: <10020CF0-1D0D-4AA9-AF02-E8B1170836C4@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <015001cd7ca9$0f2ee060$2d8ca120$@packetizer.com> <51f40b7d-4f53-4500-b80a-1a935c4dd6ca@email.android.com> In-Reply-To: <51f40b7d-4f53-4500-b80a-1a935c4dd6ca@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <64FF4BCE65A37B409D24419953922D8E@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: =?us-ascii?Q?H4sIAAAAAAAAC02SbUgTcRzH99/d5ik7OZ9/SaQsRupUNIikB7AXZWCJzXe+?= =?us-ascii?Q?sVNPN3JTt4kWCEMSzNRMhVI0Z84wH+de5EwLkxS1wLnARFHxISmfErEHzWk3?= =?us-ascii?Q?77Tu1ee+3+/v9//enyMwz2KxVOyGuwkEvmGtXZHxERZrV4k4quRRGR5VVNUi?= =?us-ascii?Q?jCqxVuPRWLwgUaTSJGfm3RYp+4cLRVmjp/Je7JeLDGjQrxi5EZ7USwSD01sY?= =?us-ascii?Q?92JEYK42ioqRKyGmwsD8ph1zsjclh48T84eMUTQYnxzgTvaiFLC9WSTkMglQ?= =?us-ascii?Q?OzbOczi82pw4zOCUDMbbZpCTSeoKNLW2unCHORDM1VaxAwThSl0FR3uaM4Mo?= =?us-ascii?Q?X/g12ibkzvKDqaX6Qwa2Q/fKWxHHoWCZaME5vgjr7//wOgWmvjGMYymUTm/w?= =?us-ascii?Q?sz7wbXGfz4TD4oNKPnMLzMVrvH4O1kx2fudlGG538JkYKOxs4PWbMNBo4jkA?= =?us-ascii?Q?DmbneI6G9dfdfD4Qdvp3sKM9y/ZmnmOhqamU57Pw+UeBuBwF1/z3mRyHgrF3?= =?us-ascii?Q?S1zD3grGjt9fiOZkObxoWMVqDm/RA0aql3AjErUgH0avplUZ4XSKmsmiU+4w?= =?us-ascii?Q?+vCUTLUFsf/GZDCIrWjh55kBdIIQSn3I/ObIeE/35MzUu0pap0zS5mQwugEE?= =?us-ascii?Q?hETqTTo6WY/UZdFqnSr9yDpJEFIgc82s5aFl0pm8NFWGntFy9iiSEY37IzPI?= =?us-ascii?Q?E9dkahh/P/KaM0g5dyhzNMc5O/Lx9yJl7awnyWK0apWe06eQFzEv5IfZugL2?= =?us-ascii?Q?CUIryI9AUi/yu7OPRKXRH9dZYZsK2aYLdRHOpnr6n+VvQB3QrBmKs+Py+dyA?= =?us-ascii?Q?nsc9FXtBKwpzRWWfoczd7jK5N9kUZOi9kPZ748al8zZFnxWzBdUHWkMS4x5+?= =?us-ascii?Q?tXU8P12e0FOdVOltGvqSYkidMEXJBbQk21W3O/ZMQxZ8GHKh9pZzgsO2W2QK?= =?us-ascii?Q?G1N3z1zvyP+0eT323dNdlO1miUlene2W4jolHRmCaXX0XySBO1SdAwAA?= Cc: "" , Christer Holmberg 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: Mon, 20 Aug 2012 03:40:33 -0000 I think the diagram you're talking about is this: +-------+ +-------+ | Alice |\ /| Bob | +-------+ \ / +-------+ +-----+ +-----+ |PBX-1|----|PBX-2| +-----+ +-----+ +-------+ / \ +-------+ | Dave |/ \| Sue | +-------+ +-------+ The rest inline... On Aug 19, 2012, at 9:57 PM, Paul E. Jones wrote: > Now let's assume no refer message is sent. For billing reasons, one would= want to handle that transfer locally. So, Alice's call agent will send an = invite to Dave to get him and Bob talking. I guess this will work the same.= I'd expect the invite to contain Dave and Bob's uuid values, but how would= we construct those? An invite would also get sent to Bob. What would that = look like? Alice makes call to Bob, Session-ID=3DU;V Dave calls Alice, Session-ID=3DW;X Bob calls Sue, Session-ID=3DY;Z. Later, Alice presses some keys to make PBX-1 transfer Bob to Dave, instead = of sending Bob a REFER. Later, Bob presses some keys to make PBX-2 transfer Alice to Sue, instead o= f sending Alice a REFER. Currently draft-kaplan doesn't specify what to do for this, I think, becaus= e it's not a REFER-driven transfer. So it's really up for debate. By that= I mean there's no backwards-compatibility problem/requirement/impact. Personally, I think it should behave as if it were a REFER situation, i.e. = do what a REFER would have made happen. For example PBX-1 could generate an= INVITE to Dave with a Session-ID=3DW;V or W;U, possibly with a Replaces he= ader having a session-id param of 'W;X', depending on how we wanted a real = REFER case to work. If a re-INVITE is sent to Bob/PBX-2 from the PBX-1, it= 's still U;V on that leg because it doesn't change mid-dialog. In either c= ase, a monitoring device would be able to correlate them since one of the k= eys match.=20 Likewise, in the second part when Bob transfers Alice (who's now Dave reall= y) to Sue, PBX-2 would send an INVITE to Sue with Session-ID=3DY;U or Y;V (= again depending on what rule we wanted to impose for REFERs), possibly with= a Replaces header having a session-id param of 'Y;Z'. > Since the invite to Bob is actually being redirected to Sue in this scena= rio, I guess Bob's call agent needs to do the proper substitution of a uuid= ... replacing Bob's with Sue's. Yes, if a PBX performs a transfer by terminating/processing REFER as a UA o= r based on keys or app-logic, generating dialog-creating INVITEs out of thi= n air so-to-speak, life gets messy. It's going to no matter what we do at = that point - for example Dave could have just barged in to the Alice-Bob ca= ll by calling the PBX as a new call and pressed some keys for barge-in, or = the PBX could handle call transfers without ever sending new INVITEs or re-= INVITEs, by just switching the media (assuming it was already handling all = media). And we can't mandate the PBXes send re-INVITEs or UPDATEs to change the Ses= sion-IDs - we'd just be ignored because many PBXs have a hard time doing it= , and many customers don't want them to do it (or have SBCs answer the re-I= NVITEs to prevent them from going further). I think the best we can do is = have simple rules for the devices generating them, and make sure this Sessi= on-ID thing is only used for monitoring/troubleshooting type uses - things = that won't cause calls to fail if the INSIPID rules/algorithms don't handle= it right. > What do these headers look like? Whose ID is a parameter? Anything beyond the normal single session/dialog case and basic REFER scena= rio is not covered by the current draft-kaplan, so it's up for debate reall= y what it should do. There's no backwards-compatibility problem/requiremen= t/impact for such cases. -hadriel From paulej@packetizer.com Mon Aug 20 18:29:10 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 7479621F856C for ; Mon, 20 Aug 2012 18:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=1.099, BAYES_00=-2.599, GB_I_LETTER=-2] 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 o4T675iOCgyT for ; Mon, 20 Aug 2012 18:29:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 74EF221F8568 for ; Mon, 20 Aug 2012 18:29:09 -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 q7L1Swmf008083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2012 21:28:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1345512539; bh=pWqLP1fDKi+qyIg0QWDE76y1baEqua02r88hnbfA7/U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zhw8jaGnBV+U96qKX6VwnEINAQ8R5phHX2kq3cL6ICYZeAj33cmjvCXA7hHsSjGFO KPZVz8NCv3XyNb+7hk7KFP8Kb2Mma1DJBXtjK6bnYTDnXzc++//opOPVUtlkAMlRHJ M+0B1bILPvWSxkNrWGg0eQxdh49GWntLh4RHXfC4= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <015001cd7ca9$0f2ee060$2d8ca120$@packetizer.com> <51f40b7d-4f53-4500-b80a-1a935c4dd6ca@email.android.com> <10020CF0-1D0D-4AA9-AF02-E8B1170836C4@acmepacket.com> In-Reply-To: <10020CF0-1D0D-4AA9-AF02-E8B1170836C4@acmepacket.com> Date: Mon, 20 Aug 2012 21:29:01 -0400 Message-ID: <024901cd7f3c$586d5d20$09481760$@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: AQGQlrwc96LJmyJNZehiP4Ej0pCKDwFQkPCpARKh4xgBxMCHoQIG9JCYl6vQkPA= Content-Language: en-us Cc: insipid@ietf.org, 'Christer Holmberg' 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: Tue, 21 Aug 2012 01:29:10 -0000 Hadriel, What I hoped for out of our original proposal was to allow for this kind of flexibility. So, Alice transfers to Dave, the INVITE to Dave would look like: Session-ID: V;p=W (I think... using the A/B/D/S naming, it would be Session-ID: B;p=D. I just want to make sure I don't suggest the wrong values in my example.) Now, PBX-1 needs to also send an INVITE to Bob. This would then look the same: Session-ID: V;p=W I think this is workable. If PBX-2 is performing a mid-call endpoint exchange, it just has to take responsibility for these ensuring proper values are conveyed. Now, let's suppose that Bob had called Alice. In that case, the original session-ID from Bob to Alice would have been: Session-ID: B;p=A (I know you do not want folks to assume B carries some meaning, but I find it easier to use these letters.) Now, Alice transfers the call to Dave. In this case, the Session-ID would be what? Session-ID: B;p=D This would be replacing "Session-ID: A;p=D" with "Session-ID: B;p=D" It's this mid-call change of the Session-ID that concerns me w.r.t. backward compatibility. During the middle of the call the Session-ID per your original draft (using just the first 32 bits) changes from A to B. I mentioned before that we have to have a means of allowing the Session-ID to change mid-call since one endpoint may be replaced with another at any time and there may or may not be associated signaling. Will that work for you, or would it cause a lot of problems? Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Sunday, August 19, 2012 11:40 PM > To: Paul E. Jones > Cc: Christer Holmberg; > Subject: Re: [Insipid] Backward compability between draft-jones and draft- > kaplan > > > I think the diagram you're talking about is this: > > +-------+ +-------+ > | Alice |\ /| Bob | > +-------+ \ / +-------+ > +-----+ +-----+ > |PBX-1|----|PBX-2| > +-----+ +-----+ > +-------+ / \ +-------+ > | Dave |/ \| Sue | > +-------+ +-------+ > > The rest inline... > > > On Aug 19, 2012, at 9:57 PM, Paul E. Jones wrote: > > Now let's assume no refer message is sent. For billing reasons, one > would want to handle that transfer locally. So, Alice's call agent will > send an invite to Dave to get him and Bob talking. I guess this will work > the same. I'd expect the invite to contain Dave and Bob's uuid values, but > how would we construct those? An invite would also get sent to Bob. What > would that look like? > > Alice makes call to Bob, Session-ID=U;V > Dave calls Alice, Session-ID=W;X > Bob calls Sue, Session-ID=Y;Z. > Later, Alice presses some keys to make PBX-1 transfer Bob to Dave, instead > of sending Bob a REFER. > Later, Bob presses some keys to make PBX-2 transfer Alice to Sue, instead > of sending Alice a REFER. > > Currently draft-kaplan doesn't specify what to do for this, I think, > because it's not a REFER-driven transfer. So it's really up for debate. > By that I mean there's no backwards-compatibility > problem/requirement/impact. > > Personally, I think it should behave as if it were a REFER situation, i.e. > do what a REFER would have made happen. For example PBX-1 could generate > an INVITE to Dave with a Session-ID=W;V or W;U, possibly with a Replaces > header having a session-id param of 'W;X', depending on how we wanted a > real REFER case to work. If a re-INVITE is sent to Bob/PBX-2 from the > PBX-1, it's still U;V on that leg because it doesn't change mid-dialog. > In either case, a monitoring device would be able to correlate them since > one of the keys match. > > Likewise, in the second part when Bob transfers Alice (who's now Dave > really) to Sue, PBX-2 would send an INVITE to Sue with Session-ID=Y;U or > Y;V (again depending on what rule we wanted to impose for REFERs), > possibly with a Replaces header having a session-id param of 'Y;Z'. > > > > Since the invite to Bob is actually being redirected to Sue in this > scenario, I guess Bob's call agent needs to do the proper substitution of > a uuid... replacing Bob's with Sue's. > > Yes, if a PBX performs a transfer by terminating/processing REFER as a UA > or based on keys or app-logic, generating dialog-creating INVITEs out of > thin air so-to-speak, life gets messy. It's going to no matter what we do > at that point - for example Dave could have just barged in to the Alice- > Bob call by calling the PBX as a new call and pressed some keys for barge- > in, or the PBX could handle call transfers without ever sending new > INVITEs or re-INVITEs, by just switching the media (assuming it was > already handling all media). > > And we can't mandate the PBXes send re-INVITEs or UPDATEs to change the > Session-IDs - we'd just be ignored because many PBXs have a hard time > doing it, and many customers don't want them to do it (or have SBCs answer > the re-INVITEs to prevent them from going further). I think the best we > can do is have simple rules for the devices generating them, and make sure > this Session-ID thing is only used for monitoring/troubleshooting type > uses - things that won't cause calls to fail if the INSIPID > rules/algorithms don't handle it right. > > > > What do these headers look like? Whose ID is a parameter? > > Anything beyond the normal single session/dialog case and basic REFER > scenario is not covered by the current draft-kaplan, so it's up for debate > really what it should do. There's no backwards-compatibility > problem/requirement/impact for such cases. > > -hadriel From brett@broadsoft.com Tue Aug 21 03:14:37 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 2750C21F86AA for ; Tue, 21 Aug 2012 03:14:37 -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 O0slICucatB6 for ; Tue, 21 Aug 2012 03:14:36 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8C31821F869F for ; Tue, 21 Aug 2012 03:14:26 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 03:18:03 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 21 Aug 2012 03:18:03 -0700 From: Brett Tate To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Date: Tue, 21 Aug 2012 03:14:23 -0700 Thread-Topic: Is session ID in conference in scope of the WG Thread-Index: Ac1xod4iQcE28BAjSii2gJBArSeByQAwtD/wA0bbYzA= Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F736A@EXMBXCLUS01.citservers.local> References: In-Reply-To: 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: [Insipid] Is session ID in conference in scope of the WG 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: Tue, 21 Aug 2012 10:14:37 -0000 Hi, Since the topic of changing Session-ID within a dialog is still being raise= d, I thought that I'd ask again about such requirements/use-cases since it = doesn't appear to meet the criteria for the "one in / one out case where th= e To/From header fields could have been preserved" situation. Is the Session-ID allowed to change within a dialog? More specifically (as= discussed within the following threads) if a B2BUA connects two existing d= ialogs which have different Session-ID values, is the Session-ID required t= o be renegotiated and/or changed? http://www.ietf.org/mail-archive/web/insipid/current/msg00280.html=20 http://www.ietf.org/mail-archive/web/insipid/current/msg00082.html=20 Thanks, Brett > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Saturday, August 04, 2012 2:12 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Is session ID in conference in scope of the WG >=20 > (As WG cochair) >=20 > I have been asked about the third-party call controller cases. >=20 > They have to fall for the same reason as the conference case. >=20 > The only use case that survives on the one in / one out case where the > To/From header fields could have been preserved. >=20 > Regards >=20 > Keith >=20 >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) > > Sent: 03 August 2012 19:00 > > To: insipid@ietf.org > > Subject: Is session ID in conference in scope of the WG > > > > [As WG cochair] > > > > The chairs and the associated AD (Gonzalo) discussed this and came to > the > > conclusion that creation of an identifier that is preserved across > > conferences is out of scope according to the INSIPID working group > charter. > > > > The reasoning for this is that the charter is bound to problem space > for > > which a common To/From header field is used. > > > > We will therefore not include a conferencing use case, or attempt to > > derive requirements from one. > > > > By the same argument, transfers are also out of scope at first sight, > but > > the To and From headers are preserved in the Refer so it can be > argued > > from that perspective that it is in scope. > > > > So we will continue to include the transfer use case. > > > > Obviously discussion of this is allowed, but please remember that any > such > > discussion is likely to a rechartering discussion (with consequent > delay) > > rather than a discussion on the contents of the requirements > document. > > > > Regards > > > > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From andrew.hutton@siemens-enterprise.com Tue Aug 21 04:28:55 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 2E61E21F8628 for ; Tue, 21 Aug 2012 04:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 PLPLRMR-QQsA for ; Tue, 21 Aug 2012 04:28:54 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 21A1221F856F for ; Tue, 21 Aug 2012 04:28:54 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 8220C1EB843E; Tue, 21 Aug 2012 13:28:52 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.46]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 13:28:52 +0200 From: "Hutton, Andrew" To: Hadriel Kaplan Thread-Topic: [Insipid] Is session ID in conference in scope of the WG Thread-Index: Ac1xod4iku0azJW7aUyoQyy4YX9rowAwtD/wADBz0YAAPJfPgAAh+KLAAflRSQAAwhb/UA== Date: Tue, 21 Aug 2012 11:28:51 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF09DC50@MCHP04MSX.global-ad.net> References: <501EB9DF.1010403@ericsson.com> <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DRAGE, Keith \(Keith\)" , James Polk , "insipid@ietf.org" , Gonzalo Camarillo Subject: Re: [Insipid] Is session ID in conference in scope of the WG 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: Tue, 21 Aug 2012 11:28:55 -0000 I agree that it might be that the solution accidently is able to handle the= 3PCC case but I was rather hoping that it we could explicitly state this a= s a requirement. It seems strange to me that the issue of 3PCC is not explicitly covered in = a working group established because of B2BUA behavior. 3PCC is a very commo= n function of a SIP B2BUA and so should be covered in my opinion and I thou= ght that was the opinion of the working group at IETF84. Regards Andy > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 17 August 2012 17:39 > To: Hutton, Andrew > Cc: James Polk; Gonzalo Camarillo; DRAGE, Keith (Keith); > insipid@ietf.org > Subject: Re: [Insipid] Is session ID in conference in scope of the WG >=20 >=20 > I didn't get that view from re-reading that thread. >=20 > But anyway just because it's out of scope doesn't mean a proposed > solution can't cover it - if even by accident/coincidence of its > solution design. > It just means we can't have requirements to cover it, and proposed > solutions don't need to address it. Both draft-jones and draft-kaplan > models happen to address the "simple" 3PCC case, and the draft-jones > might try to address the more complicated cases (I think). >=20 > -hadriel >=20 >=20 > On Aug 7, 2012, at 9:41 AM, Hutton, Andrew wrote: >=20 > > Hi, > > > > I looked back through the thread and found this discussion which > related to 3PCC http://www.ietf.org/mail- > archive/web/dispatch/current/msg03950.html. > > > > In this discussion it is my interpretation that 3PCC is consider in > scope. The the following snippet is taken from this thread. > > > > Paul Kyzivat asks the question. > > > >>> How do you feel about a 3PCC controller? Is it a B2BUA? If it does > a > >>> transfer then it goes through stages when it has two dialogs, then > >>> three, then two. From past discussions, I think you expect there > will be > >>> more than one session-id covering that. > > > > The response from Paul Jones. > > > >> A PBX-type device would be a B2BUA in my mind and, yes, there would > be > >> different Session-IDs since there would be different devices end-to- > end. In > >> this case, the B2BUA truly is just an intermediary device, not a > terminating > >> device. > > > > My interpretation is this discussion is that 3PCC is within scope as > the 3PCC controller is "just an intermediary device" it is just > confirmation that a 3PCC transfer results in a new session identifier > as per the basic endpoint initiated case. > > > > In any case in the basic 3PCC call flow the result following the > initial dialog establishment is a simple 2 party call which is no > different to the case when the flow was initiated by an endpoint (i.e. > 2 dialogs with a B2BUA in the middle which mangles the dialog > identifiers) so I don't understand why it would be considered out of > scope. > > > > Regards > > Andy > > From andrew.hutton@siemens-enterprise.com Tue Aug 21 04:38:05 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 BCED721F85F7 for ; Tue, 21 Aug 2012 04:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.031, 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 zj9xCWip44Y4 for ; Tue, 21 Aug 2012 04:38:05 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3067021F85AA for ; Tue, 21 Aug 2012 04:38:05 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 3DD1D23F0462 for ; Tue, 21 Aug 2012 13:38:04 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.46]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 13:38:04 +0200 From: "Hutton, Andrew" To: "insipid@ietf.org" Thread-Topic: SIPREC and the INISIPID SessionID. Thread-Index: AQHNf5FslqH/mH1w7U+bgEvjQo4N4Q== Date: Tue, 21 Aug 2012 11:38:02 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF09DC81@MCHP04MSX.global-ad.net> References: <501EB9DF.1010403@ericsson.com> <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] SIPREC and the INISIPID SessionID. 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: Tue, 21 Aug 2012 11:38:05 -0000 Hi All, Due to the discussion on the scope of the INSIPID work I asked the SIPREC w= orking group what requirements and/or dependencies that SIPREC work has on = the INSIPID session identifier. The consensus of the SIPREC group appears to be that there is no dependency= on INSIPID and that any end to end session identifier would simple be a ni= ce to have for SIPREC and would could be made use of using the SIPREC metad= ata extension mechanism. Regards Andy (SIPREC Co-Chair).=20 From gsalguei@cisco.com Tue Aug 21 06:41: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 E96E121F8607 for ; Tue, 21 Aug 2012 06:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[AWL=2.600, 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 Yt8wbl3U71sF for ; Tue, 21 Aug 2012 06:41:12 -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 6251721F8564 for ; Tue, 21 Aug 2012 06:41:12 -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 q7LDfBmj026062 for ; Tue, 21 Aug 2012 09:41:11 -0400 (EDT) Received: from dhcp-10-150-53-73.cisco.com (dhcp-10-150-53-73.cisco.com [10.150.53.73]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7LDfBCK003941; Tue, 21 Aug 2012 09:41:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF09DC81@MCHP04MSX.global-ad.net> Date: Tue, 21 Aug 2012 09:41:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <501EB9DF.1010403@ericsson.com> <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF09DC81@MCHP04MSX.global-ad.net> To: "Hutton, Andrew" X-Mailer: Apple Mail (2.1278) Cc: insipid@ietf.org Subject: Re: [Insipid] SIPREC and the INISIPID SessionID. 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: Tue, 21 Aug 2012 13:41:13 -0000 Andy -=20 Morbidly curious as to whether the lack of dependency is a result of = concerns with the session ID delivery timeline or potential concerns = with Session ID construction? Cheers, Gonzalo On Aug 21, 2012, at 7:38 AM, Hutton, Andrew wrote: > Hi All, >=20 > Due to the discussion on the scope of the INSIPID work I asked the = SIPREC working group what requirements and/or dependencies that SIPREC = work has on the INSIPID session identifier. >=20 > The consensus of the SIPREC group appears to be that there is no = dependency on INSIPID and that any end to end session identifier would = simple be a nice to have for SIPREC and would could be made use of using = the SIPREC metadata extension mechanism. >=20 > Regards > Andy (SIPREC Co-Chair).=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From andrew.hutton@siemens-enterprise.com Tue Aug 21 06:53:10 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 44A2F21F86B0 for ; Tue, 21 Aug 2012 06:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 ftln0q28JT0f for ; Tue, 21 Aug 2012 06:53:09 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0762721F8518 for ; Tue, 21 Aug 2012 06:53:09 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 3E4391EB840E; Tue, 21 Aug 2012 15:53:08 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.46]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Tue, 21 Aug 2012 15:53:07 +0200 From: "Hutton, Andrew" To: Gonzalo Salgueiro Thread-Topic: [Insipid] SIPREC and the INISIPID SessionID. Thread-Index: AQHNf5FslqH/mH1w7U+bgEvjQo4N4ZdkJJaAgAAjzFA= Date: Tue, 21 Aug 2012 13:53:07 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF09DE8B@MCHP04MSX.global-ad.net> References: <501EB9DF.1010403@ericsson.com> <201208062317.q76NHMnl014862@mtv-core-3.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF07638E@MCHP04MSX.global-ad.net> <9F33F40F6F2CD847824537F3C4E37DDF09DC81@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" Subject: Re: [Insipid] SIPREC and the INISIPID SessionID. 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: Tue, 21 Aug 2012 13:53:10 -0000 Hi Gonzalo, Neither really it is simply that it is desirable in SIPREC to have an end t= o end session identifier so that recordings that relate to the same communi= cation session can be correlated but it is not essential to the recording m= echanism. Therefore if INSIPID is successful we can use the resulting session identif= ier and place it in the SIPREC metadata but the basic metadata model is not= dependant on this. Regards Andy > -----Original Message----- > From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com] > Sent: 21 August 2012 14:41 > To: Hutton, Andrew > Cc: insipid@ietf.org > Subject: Re: [Insipid] SIPREC and the INISIPID SessionID. >=20 > Andy - >=20 > Morbidly curious as to whether the lack of dependency is a result of > concerns with the session ID delivery timeline or potential concerns > with Session ID construction? >=20 > Cheers, >=20 > Gonzalo >=20 > On Aug 21, 2012, at 7:38 AM, Hutton, Andrew wrote: >=20 > > Hi All, > > > > Due to the discussion on the scope of the INSIPID work I asked the > SIPREC working group what requirements and/or dependencies that SIPREC > work has on the INSIPID session identifier. > > > > The consensus of the SIPREC group appears to be that there is no > dependency on INSIPID and that any end to end session identifier would > simple be a nice to have for SIPREC and would could be made use of > using the SIPREC metadata extension mechanism. > > > > Regards > > Andy (SIPREC Co-Chair). > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > From jmpolk@cisco.com Mon Aug 27 16:18:46 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 7F12921F8474 for ; Mon, 27 Aug 2012 16:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, 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 1iM-cwzq6z2v for ; Mon, 27 Aug 2012 16:18:45 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id EA18F21F845C for ; Mon, 27 Aug 2012 16:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1206; q=dns/txt; s=iport; t=1346109525; x=1347319125; h=message-id:date:to:from:subject:mime-version; bh=Pv1kVqUiakDVq0Jk0hhCDYdCHRMX5mZ81ma/c3S/0f0=; b=MSQyGw+iN53TuTRUXxX7K3z4USUllpfcqZnBaWM1RjQ6wV+4aVAKVvEJ 3yX8d7xwzrg1Fjj7vOeUZHYW2x2LR0ArkGlxLeH4w8elY7H6+AS69DpYW kEXKC4VkzBLL26A6qNIAwn6BTxvIgXMhEy2OugYcUvH699Lvt1wpWLy+Y A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA0APFCrRDoH/2dsb2JhbABFunuBB4IgAQIWAQobAlYbHyk2DjWHapkxgSigKJFhA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53742675" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:18:28 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNIRsQ009803 for ; Mon, 27 Aug 2012 23:18:28 GMT Message-Id: <201208272318.q7RNIRsQ009803@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:18:26 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.1. Session Recording: 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: Mon, 27 Aug 2012 23:18:46 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.1. Session Recording: A SIP Session is established between UA A and UA B with a SIP B2BUA acting as a middlebox. Both UA A and UA B establish a recording session with a session recording server (SRS) using the SIPREC protocol. The SRS needs to be able to determine from the metadata provided by UA A and UA B that the media streams are associated with the same communication session (CS). Derived Requirements: From jmpolk@cisco.com Mon Aug 27 16:19:17 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 444B321F8474 for ; Mon, 27 Aug 2012 16:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, 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 sgVKZsSs68HH for ; Mon, 27 Aug 2012 16:19:16 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id DB36421F845C for ; Mon, 27 Aug 2012 16:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1342; q=dns/txt; s=iport; t=1346109556; x=1347319156; h=message-id:date:to:from:subject:mime-version; bh=KBYiPbTWDHXV8lLdfaChYEpbm+IlPHNHthxZaStPnmc=; b=T8rNTstrGtlHD8LyNwoszxf1hkDahbCkA8BUS7zclVGBLX5GoUCZnLLS SA3rIXgd6Dqfnx03nEisA7ZKDIy/UCBsW5thwtKzgPy7IzysWucrkFVfu U5q8FPOVzAIMUNb61wHOHBj2LaVJM7MdWwtfC25MaxsRIIBoXfB9yH30E I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADn/O1CrRDoG/2dsb2JhbAA7Crp7gQeCIAECFgEKGwJWGx8pNg41h2qZMIEooCiLGIZJA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="56234786" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 27 Aug 2012 23:19:15 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNJFVo012135 for ; Mon, 27 Aug 2012 23:19:15 GMT Message-Id: <201208272319.q7RNJFVo012135@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:19:13 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.2. Protocol Interworking: 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: Mon, 27 Aug 2012 23:19:17 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.2. Protocol Interworking: A communication session might originate in an H.323 endpoint and pass through a Session Border Controller before ultimately reaching a terminating SIP user agent. Likewise, a call might originate on a SIP user agent and terminate on an H.323 endpoint. It MUST be possible to identify such sessions end-to-end across the plurality of devices, networks, or administrative domains. It is expected that the ITU-T will define protocol elements for H.323 to make the end-to-end signaling possible. Derived Requirements: From jmpolk@cisco.com Mon Aug 27 16:20:08 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 25B5621F847A for ; Mon, 27 Aug 2012 16:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.505 X-Spam-Level: X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, 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 RycKACdOOeKh for ; Mon, 27 Aug 2012 16:20:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5A621F845B for ; Mon, 27 Aug 2012 16:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1468; q=dns/txt; s=iport; t=1346109607; x=1347319207; h=message-id:date:to:from:subject:mime-version; bh=JVewjH0oX+G7OZkEvuCb0CVM0LbH2Y2f4kyIYgMhMVo=; b=II/ytOwxcXZV60PCeRQf8xS+JbYNjp3xxPMmVeCB7faGiSoAUA/VNwvS WDPJReW1cHqmZ8uK85L3wZlU4asq/UIJIgn+EgP8LAc1JfGDsD7trsTsj +c73hUwFsxN4bNt8O4pdq1q8Rehms5OC82x4bXtBvrkbZ9VsO7IvybaMo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA0APFCrRDoH/2dsb2JhbAA7Crp7gQeCIAECFgEKGwJWGx8pNg41h2qZMYEooCiLGIZJA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53742838" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:20:06 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNK69G010568 for ; Mon, 27 Aug 2012 23:20:06 GMT Message-Id: <201208272320.q7RNK69G010568@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:20:04 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [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: Mon, 27 Aug 2012 23:20:08 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 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. Derived Requirements: From jmpolk@cisco.com Mon Aug 27 16:21: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 48CD021F84B2 for ; Mon, 27 Aug 2012 16:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.506 X-Spam-Level: X-Spam-Status: No, score=-110.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 H2D-iPjIUKI0 for ; Mon, 27 Aug 2012 16:21:11 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9937421F8474 for ; Mon, 27 Aug 2012 16:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1305; q=dns/txt; s=iport; t=1346109671; x=1347319271; h=message-id:date:to:from:subject:mime-version; bh=RPgkIDcjnXcl1HuNfIY+zyXHmEH3YZjJE+D5xPri/Fs=; b=M0WCrZvv6GH1jTkGp+yn/Sze9VQMZNGD+ONsAoIj686KYM1SwyRs0s4l xY8H4omMhGWgQSumngaf9WMvjcennli78kk57SrlzUAgF9pvjMqYlYAvF 6DgrZv3fk7MQJaSs+unXCTGLJJfdGptXyOUTwv03SxnF1m1WIIgULwNEU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA0APFCrRDoI/2dsb2JhbABFunuBB4IgAQIWAQobAi4oGx8pNg41h2qZMYEooCiRYQOIT5s0gWeDAQ X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53742942" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:21:08 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNL7Tu008968 for ; Mon, 27 Aug 2012 23:21:08 GMT Message-Id: <201208272321.q7RNL7Tu008968@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:21:06 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.X Identification of devices taking part in the same multipoint Conference: 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: Mon, 27 Aug 2012 23:21:12 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.X Identification of devices taking part in the same multipoint Conference: SIP messaging can easily be multipoint in nature, specifically with several UAs communicating with a multipoint control unit (MCU) as part of a conference. The ability to distinguish all participants in single focus based multipoint conference to be identified as in the same communications session with all the other participants (i.e., in a single star configuration), verses in another conference session. Derived Requirements: From jmpolk@cisco.com Mon Aug 27 16:21:58 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 8BA9021F84AE for ; Mon, 27 Aug 2012 16:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 WEINWs7sM2ZM for ; Mon, 27 Aug 2012 16:21:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 02A1F21F8474 for ; Mon, 27 Aug 2012 16:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1223; q=dns/txt; s=iport; t=1346109718; x=1347319318; h=message-id:date:to:from:subject:mime-version; bh=7ERDujuzu3rcz2a1sO7eWiHwriifIjMEwhw7MmS2kgs=; b=fYTw8hdSrz+E58fCF8VHjxIJ7EgQKM1MwlMqrRwTv/ZD0Kim+mQMZNhv 28lrvya9vEHqlcQ/WyMIecGtf4SCKfKSGzr6MQyc7ctW/8iAc+hgLg/5H eTBpZ5cZTljGxXlBIk23zDkwcQOdcz6nQe2jaD67Vqd8x/deek7YyUDnv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA0APFCrRDoJ/2dsb2JhbABFunuBB4IgAQIWAQobAlYbHyk2Dgorh2qZMYEooCiRYQOIT5s0gWeDAQ X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53742991" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:21:57 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNLvEV009606 for ; Mon, 27 Aug 2012 23:21:57 GMT Message-Id: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:21:55 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: 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: Mon, 27 Aug 2012 23:21:58 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.X Tracking sessions transferred from one endpoint to another: It is difficult to track which SIP messages where involved in the same call across transactions, especially when invoking supplementary services such as call transfer or call join. The ability to track communications sessions as they are transferred, one side at a time, through until completion of the session (i.e., until a BYE is sent). Derived Requirements: From jmpolk@cisco.com Mon Aug 27 16:23:11 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 63B5E21F84F2 for ; Mon, 27 Aug 2012 16:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 s0slPNxUp3Oa for ; Mon, 27 Aug 2012 16:23:11 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 02EAA21F84F1 for ; Mon, 27 Aug 2012 16:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1587; q=dns/txt; s=iport; t=1346109790; x=1347319390; h=message-id:date:to:from:subject:mime-version; bh=aRx/tkKbexbsHzOjdATOKWA8ahdvqgwPfLRa1wo2Moc=; b=SUN/jowAIW185AAIhfrq5+pRGKkk/pHOnFl4BIuJgOMODj2Z6sd6dEun oSv+6q3z5AH6UPCe/FDSXhwSpuYbyudiGyRue9GhwGaNQBY3X6rDrbzIb OKqClVEG0WD0mozEh+K5MKpsV6OtAaFBoBP9cAHl1Qet5KEN86OU4GH7h 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIYAPFCrRDoH/2dsb2JhbABFunuBB4IgAQIWAQobAlYbHyk2DjWHapkygSigKJFhA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53203516" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 27 Aug 2012 23:23:09 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNN81i012339 for ; Mon, 27 Aug 2012 23:23:08 GMT Message-Id: <201208272323.q7RNN81i012339@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:23:07 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.X Session Signal Logging: 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: Mon, 27 Aug 2012 23:23:11 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.X Session Signal Logging: An after the fact search of SIP messages to determine which were part of the same transaction or call is difficult when B2BUAs and SBCs are involved in the signaling between UAs. Mapping more than one Call-ID together can be challenging because all of the values in SIP headers on one side of the B2BUA or SBC will likely be different than those on the other side. If multiple B2BUAs and/or SBCs are in the signaling path, more than two sets of header values will exist, creating more of a challenge. Creating a common header value through all SIP entities will greatly reduce any challenge for the purposes of accounting, billing, debugging, communication tracking (such as for security purposes in case of theft of service), etc. Derived Requirements: From jmpolk@cisco.com Mon Aug 27 16:24:08 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 D681E21F84F9 for ; Mon, 27 Aug 2012 16:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.36 X-Spam-Level: X-Spam-Status: No, score=-110.36 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 j-jfw-MyTFQt for ; Mon, 27 Aug 2012 16:24:08 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7627E21F84F8 for ; Mon, 27 Aug 2012 16:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1403; q=dns/txt; s=iport; t=1346109848; x=1347319448; h=message-id:date:to:from:subject:mime-version: content-transfer-encoding; bh=/CTrFpcpoVr5Ka7cnnyXmZ9l5bcD3pZQnUrTmSy7Hfg=; b=gfyFDLoeoA6oEy5rLPy84I7RWlEa6i8uDEyA2vvNq2lFECeHFXhRsz+U rtD5Yguoq8AIci4G7x6/sS3g/kFOXJ1GjhwY+OdlA4IFEN7QnUvYkjw22 zxRJ63e9IjcHT/0cDA2UdB3okfJiWWe+Bo19gheTunQqkcDFTvDRwhYWw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIYAPFCrRDoI/2dsb2JhbABFunuBB4IgAQIWAQobWBtINg41h2qZMoEooCiRYQOIGjWbNIFngwE X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="56315011" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 27 Aug 2012 23:24:08 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNO7o2010295 for ; Mon, 27 Aug 2012 23:24:08 GMT Message-Id: <201208272324.q7RNO7o2010295@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:24:06 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [Insipid] =?iso-8859-1?q?3=2EX_Identifier_Porting_to_Other_Protoc?= =?iso-8859-1?q?ols_=96_RSVP=3A_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: Mon, 27 Aug 2012 23:24:09 -0000 INSIPID Here is the set of use-cases and requirements=20 discussed in Vancouver. We are to come to=20 consensus on each of these (or not), and if we=20 agree the use-case or requirement should be in=20 the document, we need to determine acceptable=20 wording for each. The Subject: line will contain=20 the specific topic (which use-case or=20 requirement) for this thread. PLEASE do not cross=20 contaminate the threads. Any new topic SHOULD=20 have its own Subject line. The chairs will=20 monitor and call for consensus on each use-case=20 and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once=20 consensus has been reached on all items we're=20 covering, so don't worry about that part. 3.X Identifier Porting to Other Protocols =96 RSVP: There may be a desire to associate SIP session=20 signaling with corresponding media flows. To=20 facilitate this association, it should be=20 possible to insert the Session-ID into a=20 media-related message, such as an RSVP PATH=20 message. This association would allow, as an=20 example, for network monitoring equipment to=20 associate troubled network flows with the end-to-end SIP session signaling. Derived Requirements: REQ9b WG consensus in room was to deprecate this=20 use-case, and the requirement REQ9b. From jmpolk@cisco.com Mon Aug 27 16:24: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 0F4E121F84F8 for ; Mon, 27 Aug 2012 16:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.359 X-Spam-Level: X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 z8GLBykUiheN for ; Mon, 27 Aug 2012 16:24:50 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 81D4021F84F5 for ; Mon, 27 Aug 2012 16:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1325; q=dns/txt; s=iport; t=1346109890; x=1347319490; h=message-id:date:to:from:subject:mime-version: content-transfer-encoding; bh=sPazmPDQXq/sUQuau/NWSFirPieeA+19aNzd1USb0t8=; b=XjC7aUij6Ba7MttHIHUyT8FDkvERBrA+3YCXDeMoJkqByWnqIXEMihOf cJyvcEUh3GY0/ReafZcbcySYpedG/joDZ93cb8ePgMxeVXsQSGZ3Q1uWg Kj0FrjV+1P8NtcntDGkg15NACScm4dxUDq26QfMay+g1yDPd2dOWhWbK4 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACwBPFCrRDoG/2dsb2JhbABFunuBB4IgAQIWAQobWBtINg41h2qZM4EooCiRYQOIGjWbNIFngwE X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53743274" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:24:50 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNOnua014189 for ; Mon, 27 Aug 2012 23:24:50 GMT Message-Id: <201208272324.q7RNOnua014189@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:24:48 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [Insipid] =?iso-8859-1?q?3=2EX_Identifier_Porting_to_Other_Protoc?= =?iso-8859-1?q?ols_=96_RTCP=3A_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: Mon, 27 Aug 2012 23:24:51 -0000 INSIPID Here is the set of use-cases and requirements=20 discussed in Vancouver. We are to come to=20 consensus on each of these (or not), and if we=20 agree the use-case or requirement should be in=20 the document, we need to determine acceptable=20 wording for each. The Subject: line will contain=20 the specific topic (which use-case or=20 requirement) for this thread. PLEASE do not cross=20 contaminate the threads. Any new topic SHOULD=20 have its own Subject line. The chairs will=20 monitor and call for consensus on each use-case=20 and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once=20 consensus has been reached on all items we're=20 covering, so don't worry about that part. 3.X Identifier Porting to Other Protocols =96 RTCP: There may be a desire to associate SIP session=20 signaling with corresponding media flows. To=20 facilitate this association, it should be=20 possible to insert the Session-ID into a=20 media-related message, such as an RTCP sender=20 report message. This association would allow, as=20 an example, for network monitoring equipment to=20 associate troubled network flows with the end-to-end SIP session signaling. Derived Requirements: REQ9c From jmpolk@cisco.com Mon Aug 27 16:26:17 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 6AE2E21F845B for ; Mon, 27 Aug 2012 16:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 qm3CLcrMasCI for ; Mon, 27 Aug 2012 16:26:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 05A9721E8034 for ; Mon, 27 Aug 2012 16:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1908; q=dns/txt; s=iport; t=1346109977; x=1347319577; h=message-id:date:to:from:subject:mime-version; bh=32oMsjQvzrOLGVl6XbITz8NPqIL9Eh6FVTpuyFT53ts=; b=iMZhJimCXA01rhTkrhSDvH+Q10/o2067irlKUAJxF5bwGhrPUlPFrDHv 5lvSRCrolwLAfREdlrATrGGQZVUnOn6K/bSo16dt9DLBCFuLMbHyIiBW6 RUYscRSwnTnP0s4b0sShx4sM1ACxWyMui9MunQCqOMdohpQ2anEvIWihb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKcBPFCrRDoH/2dsb2JhbAA8Cbp7gQeCIAECFgEKGwJWGx8pNg41h2qZM4EooCeLGYZIA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="56315205" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Aug 2012 23:25:56 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNPtAX014906 for ; Mon, 27 Aug 2012 23:25:55 GMT Message-Id: <201208272325.q7RNPtAX014906@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:25:54 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.X Traffic Monitoring: 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: Mon, 27 Aug 2012 23:26:17 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.X Traffic Monitoring: UA A and UA B communicate using SIP messaging with a SIP B2BUA acting as a middlebox which belongs to a SIP service provider. For privacy reasons, the B2BUA changes the SIP headers that reveal information related to the SIP users, device or domain identity. The service provider uses an external device to monitor and log all SIP traffic coming to and from the B2BUA. In the case of failures reported by the customer or when security issue arise (e.g. theft of service), the service provider has to analyze the logs from the past several days or weeks and correlates those messages which were messages for a single end-to-end SIP session. For this scenario, we must consider three particular use cases: a) The UAs A and B support the end-to-end Session Identifier. Derived Requirements: REQ1, REQ4, REQ5, REQ8. b) Only the UA A supports the end-to-end Session Identifier, the UA B does not. Derived Requirements: REQ1, REQ4, REQ5, REQ7, REQ8. c) UA A and UA B do not support the end-to-end Session Identifier. Derived Requirements: REQ1, REQ4, REQ5, REQ7, REQ8 From jmpolk@cisco.com Mon Aug 27 16:26:56 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 CCE7221F84F8 for ; Mon, 27 Aug 2012 16:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 VldKUur1doxZ for ; Mon, 27 Aug 2012 16:26:56 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 63FAA21F845B for ; Mon, 27 Aug 2012 16:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2273; q=dns/txt; s=iport; t=1346110016; x=1347319616; h=message-id:date:to:from:subject:mime-version; bh=rViFwkDU72LgzXqtW2uiKg4QiP8tKYxav477qsQfsQY=; b=JGqW6hisceCgPRUvbi8s08i/sEFqxB13KXxAun3/NLQ+bm+FLAPndBk/ KaLR1SrZvZb7ZhSGP1tWvGRURMbfmAQ9JqVzHfjT0q8l+8G8cGt7W2ANX bUdr/hwqGbNoXlKe55oQrt8z29qPh0mq/0FNbugJ4j4kGm5MpSIeLSpg6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKcBPFCrRDoH/2dsb2JhbABFunuBB4IgAQIWAQoKEQJWGx8pNg41h2qZM4EooCeRYQOIT5s0gWeDAQ X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="56315310" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Aug 2012 23:26:56 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNQtuh015662 for ; Mon, 27 Aug 2012 23:26:55 GMT Message-Id: <201208272326.q7RNQtuh015662@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:26:54 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] 3.X 3PCC Use Case: 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: Mon, 27 Aug 2012 23:26:56 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. 3.X 3PCC Use Case: Third party call control refers to the ability of an entity to create a call in which communication is actually between two or more parties. For example, a B2BUA acting as a third party controller could establish a call between two SIP UA's using 3PCC procedures as described in section 4.1 of RFC 3725 the flow for which is reproduced below. A Controller B |(1) INVITE no SDP | | |<------------------| | |(2) 200 offer1 | | |------------------>| | | |(3) INVITE offer1 | | |------------------>| | |(4) 200 OK answer1 | | |<------------------| | |(5) ACK | | |------------------>| |(6) ACK answer1 | | |<------------------| | |(7) RTP | | |.......................................| Figure 1. Session-ID 3PCC Scenario Such a flow must result in a single session identifier being used for the communication session between UA A and UA B. Derived Requirements: REQ10 From jmpolk@cisco.com Mon Aug 27 16:27:59 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 8815321F845E for ; Mon, 27 Aug 2012 16:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 OnvMbS277amG for ; Mon, 27 Aug 2012 16:27:59 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id AAC7821F845B for ; Mon, 27 Aug 2012 16:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1152; q=dns/txt; s=iport; t=1346110078; x=1347319678; h=message-id:date:to:from:subject:mime-version; bh=wv+U6FCddQ9KextLgOTRI65e1XUUpqSGPSrsaMNxhiA=; b=Lra4j+ZMQ4962BIsluqBgyyua/lNc5Ci3E3j3TPWCh3awP1EXCE8PHEV +q+cXtxf8QAbx8AMSmg22tzxv9E/oN/pjNojAJKeSheHU408EWnOfA1Rt 1wuQ9zi6nldHCtKb/DVL7X51HFz1NvHVTBHR+EnrWXFH14DfrOb62IRZl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACwBPFCQ/khR/2dsb2JhbAA7Crp7gQeCIAECFgEKGwJWGx8pNg41h2uZMoEooCiLGIZJA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="7616446" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:27:55 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNRs8R000456 for ; Mon, 27 Aug 2012 23:27:54 GMT Message-Id: <201208272327.q7RNRs8R000456@ams-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:27:52 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] REQ1: 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: Mon, 27 Aug 2012 23:27:59 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. REQ1: It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify those dialogs which were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call). REQ1a: With the repurposed REQ1, no one not believes this yet-unwritten REQ1a is any longer necessary. From jmpolk@cisco.com Mon Aug 27 16: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 77E4021E8034 for ; Mon, 27 Aug 2012 16:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, 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 wM7Z4FPBvSpO for ; Mon, 27 Aug 2012 16:28:29 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 134D421F8508 for ; Mon, 27 Aug 2012 16:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=802; q=dns/txt; s=iport; t=1346110109; x=1347319709; h=message-id:date:to:from:subject:mime-version; bh=7Ap057lb01KHa0YTzhM3pA5IcJexWqMrmUXb4kiEFVo=; b=a3jprlz0GOqhN1VAGiEl3KzJjSt9+IeIG2hFWojHr8L2P8zM69DVzBAY U0IvtQwZB/gmSU0ZkehgAAJBWpwxbnZsSaXX5gwAU3kbXHEOITTBfqH+L kSoYqyXOEtR3skh0dya+IH9pqnXpWMh/ApJmuc5P8kEnkOTDEqvYx4A7x k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKcBPFCrRDoJ/2dsb2JhbABFunuBB4IgAQIWAQobAlYbHyk2DjWHapkzgSigJ5FhA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="56235628" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 27 Aug 2012 23:28:29 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNSSBZ012721 for ; Mon, 27 Aug 2012 23:28:28 GMT Message-Id: <201208272328.q7RNSSBZ012721@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:28:27 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] REQ6: merged into REQ5 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, 27 Aug 2012 23:28:29 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. REQ6: merged into REQ5 From jmpolk@cisco.com Mon Aug 27 16:29:02 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 A78C421F8516 for ; Mon, 27 Aug 2012 16:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 Qd-VwdqHrEp3 for ; Mon, 27 Aug 2012 16:29:00 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9224121F8514 for ; Mon, 27 Aug 2012 16:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=986; q=dns/txt; s=iport; t=1346110140; x=1347319740; h=message-id:date:to:from:subject:mime-version; bh=3LbSlY1QRt3frY4eh8fGW0gb92nQ1L5EeIVsIwAcy94=; b=GYVS5roYcsl6NaTIgJbUs544FoZctiD5n38diq+76VkKYrnfYIqrDT+e 7DwwFlCrg3I4LNuVsbOP0fqL33f8g/jQ3Rg17x0AVaOhlQfr7pGl2GpXo HVB2EhCmxq4RcSulX5Ff4cYu/qJDHq0uCCW3zbl4BjgeAzxgVB/D/xrd2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKcBPFCrRDoH/2dsb2JhbABFunuBB4IgAQIWAQobAlYbHyk2DjWHapkzgSigJ5FhA4hPmzSBZ4MB X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="56315430" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 27 Aug 2012 23:29:00 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNSxVr016826 for ; Mon, 27 Aug 2012 23:29:00 GMT Message-Id: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:28:58 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [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: Mon, 27 Aug 2012 23:29:02 -0000 INSIPID Here is the set of use-cases and requirements discussed in Vancouver. We are to come to consensus on each of these (or not), and if we agree the use-case or requirement should be in the document, we need to determine acceptable wording for each. The Subject: line will contain the specific topic (which use-case or requirement) for this thread. PLEASE do not cross contaminate the threads. Any new topic SHOULD have its own Subject line. The chairs will monitor and call for consensus on each use-case and requirement (and wording of each). Please make constructive suggestions regarding each you care about. The Section numbers will be reordered once consensus has been reached on all items we're covering, so don't worry about that part. REQ10: It must be possible to correlate two end-to-end sessions when the sessions are created by a third party controller using 3PCC procedures as described shown in Figure 1, as described in RFC 3725. From jmpolk@cisco.com Mon Aug 27 16:37:16 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 0CFD421E804B for ; Mon, 27 Aug 2012 16:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.512 X-Spam-Level: X-Spam-Status: No, score=-110.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, 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 CgrJxtqEy3pN for ; Mon, 27 Aug 2012 16:37:15 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 62DD221E803F for ; Mon, 27 Aug 2012 16:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2159; q=dns/txt; s=iport; t=1346110635; x=1347320235; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=0pmUWsERh4nk0W8/EoTBmaJo2KrQN1g3dHKiLkwKRSs=; b=LiA90LE0OiKTUfv095opCRRki3TYTxGFxsHlhu5yuCs7GgGNNzpKk1dn DOrd9eRh9w12Pez+WgJXzKH0GR5ThsXIrblz3iP1bfWSCuMNTbZoHBcmc VGG+GbCW1O23QnqJqqdRM0b9umQifVkiYdstle3dRuWxti+L+Bq55Wsu7 A=; X-IronPort-AV: E=Sophos;i="4.80,322,1344211200"; d="scan'208";a="53744227" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 27 Aug 2012 23:37:15 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7RNbE6V022469; Mon, 27 Aug 2012 23:37:14 GMT Message-Id: <201208272337.q7RNbE6V022469@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 27 Aug 2012 18:37:13 -0500 To: James Polk , "insipid@ietf.org" From: James Polk In-Reply-To: <201208272321.q7RNL7Tu008968@mtv-core-3.cisco.com> References: <201208272321.q7RNL7Tu008968@mtv-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] 3.X Identification of devices taking part in the same multipoint Conference: 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: Mon, 27 Aug 2012 23:37:16 -0000 At 06:21 PM 8/27/2012, James Polk wrote: >INSIPID > >Here is the set of use-cases and requirements discussed in >Vancouver. We are to come to consensus on each of these (or not), >and if we agree the use-case or requirement should be in the >document, we need to determine acceptable wording for each. The >Subject: line will contain the specific topic (which use-case or >requirement) for this thread. PLEASE do not cross contaminate the >threads. Any new topic SHOULD have its own Subject line. The chairs >will monitor and call for consensus on each use-case and requirement >(and wording of each). > >Please make constructive suggestions regarding each you care about. > >The Section numbers will be reordered once consensus has been >reached on all items we're covering, so don't worry about that part. > > >3.X Identification of devices taking part in the same multipoint Conference: > >SIP messaging can easily be multipoint in nature, specifically with >several UAs communicating with a multipoint control unit (MCU) as >part of a conference. The ability to distinguish all participants in >single focus based multipoint conference to be identified as in the >same communications session with all the other participants (i.e., >in a single star configuration), verses in another conference session. Within the WG session, it was discussed by several that this use-case, and the subsequent requirement should not remain a goal of this WG. I vehemently disagree with this view. It was stated several times that no solution can tackle this problem-space, yet I suggest that the existing proposed solution does just that for a single bridge (i.e., single focus conference), which is the most often use-case. This might not matter to SBCs (or their manufacturers) but it does to B2BUAs (and their manufacturers). I know, them's fightin` words, but that doesn't make them wrong. James (a B2BUA and SBC manufacturer) >Derived Requirements: > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From gsalguei@cisco.com Mon Aug 27 21:02:11 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 92A0B21F847F for ; Mon, 27 Aug 2012 21:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.288 X-Spam-Level: X-Spam-Status: No, score=-8.288 tagged_above=-999 required=5 tests=[AWL=2.311, 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 MgNC4bDVfrKA for ; Mon, 27 Aug 2012 21:02:10 -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 A7BF021F8476 for ; Mon, 27 Aug 2012 21:02:10 -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 q7S429Rv002141 for ; Tue, 28 Aug 2012 00:02:09 -0400 (EDT) Received: from rtp-vpn4-730.cisco.com (rtp-vpn4-730.cisco.com [10.82.210.218]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7S4295v022955 for ; Tue, 28 Aug 2012 00:02:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Gonzalo Salgueiro In-Reply-To: <0CD60541-DA01-4A16-9D98-1F1927DBB408@cisco.com> Date: Tue, 28 Aug 2012 00:02:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <657AD091-25A8-4F52-BD58-ADEE2833DD58@cisco.com> References: <0CD60541-DA01-4A16-9D98-1F1927DBB408@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: Tue, 28 Aug 2012 04:02:11 -0000 Reminder that the poll closes this Friday. Please indicate your = preference for the INSIPID virtual interim. --Gonzalo On Aug 16, 2012, at 1:28 AM, Gonzalo Salgueiro wrote: > 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 From atle.monrad@ericsson.com Tue Aug 28 00:37:50 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 9A82721F8456 for ; Tue, 28 Aug 2012 00:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2, 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 AIQu0ZZkIVwh for ; Tue, 28 Aug 2012 00:37:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8360521F8459 for ; Tue, 28 Aug 2012 00:37:49 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-0e-503c754c6fa9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 68.02.17130.C457C305; Tue, 28 Aug 2012 09:37:48 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 28 Aug 2012 09:37:48 +0200 From: Atle Monrad To: "insipid@ietf.org" Date: Tue, 28 Aug 2012 09:37:47 +0200 Thread-Topic: Backward compability between draft-jones and draft-kaplan Thread-Index: AQHNelsowThAhaVjf0qqgp+IUqUFRpddh1nggBFFwkA= Message-ID: <7A051DFAA46D0246A82293C7CEF621E90709D2E787@ESESSCMS0352.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853408BA4F62@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408BA4F62@ESESSCMS0356.eemea.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyM+Jvra5PqU2AwZ+nyhbz7z9jcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpKO98wF2+Uqlj77zdTAuEq8i5GTQ0LARKL7/WlmCFtM4sK9 9WxdjFwcQgKnGCX2rj/PDOEsYJRYuWk+K0gVm4COxLmfd8BsEQFNiY83zoF1swioSpx89Y6x i5GDQ1jATeJfRzFEibvEmemH2CBsK4nLu36C2bwC4RKz7vVDzV/KKDHh6kIWkASnQITEu+5O VpA5jAKyEnObeEHCzALiEreezGeCOFRAYsme81BHi0q8fPwP7BxGARmJFVu/sUHU60gs2P0J ytaWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5uV5qUWZycXF+ nl5x6iZGYDwc3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amBME3uUw8263tl4EoOipOX3SldpGc97p/dJBd+rim2cGvttPovG141XjRgtDPZZsDy2+xS5 ruyAj9r6xDfzWXonHj15fbr/qWJP9fOV7oZtz95u/zDxuofNarb/QplG1z8anlWeH9QT26Ll Xegwba7+nANT388Vmas+P8t6ykTDeH3ecwtfLg5VYinOSDTUYi4qTgQAqlm5W1UCAAA= 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: Tue, 28 Aug 2012 07:37:50 -0000 All Considerations on backwards compatibility with the draft-kaplan-session-id = would be useful.=20 As Christer indiates below, there are implementations and deployments aroun= d and it would be good to consider these and specify a backwards compatible= solution if possible. The session-id is a 3GPP Rel-9 dependency. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 14. elokuuta 2012 23:27 To: insipid@ietf.org Subject: [Insipid] Backward compability between draft-jones and draft-kapla= n Hi, In Vancouver, I expressed a wish to make the INSIPID mechanism backward com= patible with the draft-kaplan-session-id one, the reason being that it has = been around for a relatively long time, and has been implemented and deploy= ed. I compared the suggested draft-jones solution with the draft-kaplan solutio= n, and I think there are ways to achieve backward compability. -------------- FIRST, looking purely at the ABNF syntax: The jones ABNF is: Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID The kaplan ABNF is: Session-ID =3D "Session-ID" HCOLON sess-id *( SEMI generic-param ) sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] Now, assuming 32 chars is enough to carry ONE UUID, jones applications coul= d put the SECOND UUID in a header field parameter (generic-param), rather t= han combining it with the received UUID. Of course, the first UUDI (carried in sess-id) can only contains characters= 0-9 and a-z. A UUID can contain characters 0-9 and a-f and A-F. So, a jones entity would have to be prepared to receive g-z. And, as kaplan entity is not prepared to receive capital A-F, a jones entit= y would have to only use small letters. But, that should not be a problem, = afaik, as they have the same meaning as far as UUID is concerned. -------------- SECOND, looking at it would work functionwise: There are two main alternatives: 1. Second UUID is added even when one entity is kaplan compliant 2. Second UUID is not added when one entity is kaplan compliant Alternative 1: When a kaplan entity inserts the first UUID (I use that as a general term, = eventhough a kaplan entity does not use UUIDs), one must assume that it is = prepared to receive a response from a jones entity which has added the seco= nd UUID into the header field parameter. When a jones entity inserts the first UUID, one must assume that it is prep= ared to receive a response from a kaplan entity where the second UUID has *= not* been added. Alternative 2: When a kaplan entity inserts the first UUID, the jones entity detects (usin= g some identify-a-kaplan-entity mechanism) that it comes from a kaplan enti= ty, so it does not insert a seoncd UUID in the first place. As in alternative 1, when a jones entity inserts the first UUID, it has to = be prepared to receive a response where the second UUID has not been added = (the identify-a-kaplan-entity mechanism might also inform the jones entity = that the response comes from a kaplan entity. -------------- Now, there will of course be cases, where two UUIDs are required, that won'= t work. But, kaplan entities would be able to use the session-id for whatev= er they've used it so far. Regards, Christer _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From brett@broadsoft.com Tue Aug 28 06:19:56 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 037E021F8466 for ; Tue, 28 Aug 2012 06:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 BkPE6Il+xHiE for ; Tue, 28 Aug 2012 06:19:55 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 26DE921F845D for ; Tue, 28 Aug 2012 06:19:55 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 28 Aug 2012 06:23:37 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 28 Aug 2012 06:23:37 -0700 From: Brett Tate To: "insipid@ietf.org" Date: Tue, 28 Aug 2012 06:19:52 -0700 Thread-Topic: [Insipid] REQ10: evaluation Thread-Index: Ac2ErEQn7pkLROrzSluHxq0lhdn1FgAY9r1g Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9875@EXMBXCLUS01.citservers.local> References: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.com> In-Reply-To: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.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: [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: Tue, 28 Aug 2012 13:19:56 -0000 > REQ10: It must be possible to correlate two end-to-end=20 > sessions when the sessions are created by a third party=20 > controller using 3PCC procedures as described shown in=20 > Figure 1, as described in RFC 3725. As far as I know, this requirement should not be added since it does not me= et the "one in / one out case where the To/From header fields could have be= en preserved" situation (unless the requirement can be met without informin= g A of the B's Session-ID fragment). Thus I think that the requirement sho= uld not be included within draft. If such 3PCC specific requirements are actually within scope for insipid, t= he requirement should clarify if implying that a Session-ID can change with= in a dialog. REQ10 should also clarify if only applicable to specific 3PCC= procedure shown within figure 1 or also applicable to all of the other 3PC= C procedures and call flows (such as Figure 13 or reconnecting two existing= dialogs which have different existing Session-ID values). Thanks, Brett From brett@broadsoft.com Tue Aug 28 06:48:08 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 2312821F8460 for ; Tue, 28 Aug 2012 06:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 TY9Q-Gn-ZyNU for ; Tue, 28 Aug 2012 06:48:07 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id 461B221F845F for ; Tue, 28 Aug 2012 06:48:07 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 28 Aug 2012 06:51:49 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 28 Aug 2012 06:51:49 -0700 From: Brett Tate To: "insipid@ietf.org" Date: Tue, 28 Aug 2012 06:48:05 -0700 Thread-Topic: [Insipid] 3.X 3PCC Use Case: evaluation Thread-Index: Ac2Eq/nZYGc4oqERTO6COXcK55RY7wAdMOxQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9885@EXMBXCLUS01.citservers.local> References: <201208272326.q7RNQtuh015662@mtv-core-2.cisco.com> In-Reply-To: <201208272326.q7RNQtuh015662@mtv-core-2.cisco.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: [Insipid] 3.X 3PCC Use Case: 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: Tue, 28 Aug 2012 13:48:08 -0000 > 3.X 3PCC Use Case: >=20 > Third party call control refers to the ability of an entity=20 > to create a call in which communication is actually between=20 > two or more parties. For example, a B2BUA acting as a third=20 > party controller could establish a call between two SIP UA's=20 > using 3PCC procedures as described in section 4.1 of RFC 3725=20 > the flow for which is reproduced below. >=20 > Such a flow must result in a single session identifier being=20 > used for the communication session between UA A and UA B. >=20 > Derived Requirements: REQ10 As far as I know, this use case should not be added since it does not meet = the "one in / one out case where the To/From header fields could have been = preserved" situation. Thus I think that the use case should not be include= d within draft. If such 3PCC specific use cases are actually within scope for insipid, the = use case should clarify if the "single session identifier" is allowed to ch= ange after the dialog is established. Thanks, Brett From brett@broadsoft.com Tue Aug 28 09:54:21 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 1ED6421F859F for ; Tue, 28 Aug 2012 09:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 6Lv6QrOSFn4E for ; Tue, 28 Aug 2012 09:54:18 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id E305521F8596 for ; Tue, 28 Aug 2012 09:54:15 -0700 (PDT) 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; Tue, 28 Aug 2012 09:57:59 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Tue, 28 Aug 2012 09:57:30 -0700 From: Brett Tate To: "insipid@ietf.org" Date: Tue, 28 Aug 2012 09:53:46 -0700 Thread-Topic: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: evaluation Thread-Index: Ac2Eq0dRrI3bYygWSpCsyBE857fYugAi7GhA Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.citservers.local> References: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.com> In-Reply-To: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.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: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: 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: Tue, 28 Aug 2012 16:54:21 -0000 > 3.X Tracking sessions transferred from one endpoint=20 > to another: >=20 > It is difficult to track which SIP messages where=20 > involved in the same call across transactions,=20 > especially when invoking supplementary services such=20 > as call transfer or call join. The ability to track > communications sessions as they are transferred, one=20 > side at a time, through until completion of the=20 > session (i.e., until a BYE is sent). As far as I know, this use case should not be added since it does not meet = the "one in / one out case where the To/From header fields could have been = preserved" situation (unless the use case can actually be met without chang= ing session identifier within existing dialog). Thus I think that the use = case should not be included within draft. If such use cases are within scope for insipid, the use case should likely = be split into multiple parts or uses cases. The following are a few parts;= however there are likely other interesting related use case. 1) B2BUA connecting 4 dialogs for 2 active calls (A-B and A-C). B2BUA rece= ives REFER with Refer-To replaces from one party (A) involved in both calls= (attended transfer), the B2BUA reconnects the other two parties (B and C) = together using re-INVITE. 2) B2BUA connecting two dialogs for active call. B2BUA reconnects/transfer= s one party (using re-INVITE) to a new party (such as within RFC 3725 figur= es 7 and 13). 3) B2BUA connecting two dialogs for active call. B2BUA receives INVITE wit= h Replaces to replace one of the connections/dialogs. Thanks, Brett From paulej@packetizer.com Tue Aug 28 21:02:54 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 C295421F8473 for ; Tue, 28 Aug 2012 21:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 fgmBEZa0vxpF for ; Tue, 28 Aug 2012 21:02:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DF15421F8471 for ; Tue, 28 Aug 2012 21:02:53 -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 q7T42o9Z030325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 00:02:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346212971; bh=hX+NC+Z3nXjuHrAunPJxczCyHNEtCieVerNlwVBOOpU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=bZo+zKnSvlkId828c1vQ2jL7Fy+i40Xe6oActMiWskSpnITPhyZjJwGvH08lwMH+A jTNQzsDzkstfl4bitdX/Y9ONBvU7MaikaMVHpDA/fRyPLZJ3hhM/9Rbrerigp5UaPu +J+jRqW/xOUDHWw77+BC5gqJ9m/Q9FoA5jDrwdvc= From: "Paul E. Jones" To: "'Brett Tate'" , References: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9875@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9875@EXMBXCLUS01.citservers.local> Date: Wed, 29 Aug 2012 00:03:10 -0400 Message-ID: <035301cd859b$346a28d0$9d3e7a70$@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: AQJXn5mu3Zi+tP+Be4VcCRefHdJpXwK5a/dGlkYpvqA= Content-Language: en-us 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, 29 Aug 2012 04:02:54 -0000 Brett, I've said many times that I believe it's absolutely a requirement that session IDs change in a dialog. This would be true of 3PCC cases where a device initiates a call between two people. It would also be the case where a PBX joins to call legs together. Not to be confused with the "join" header in SIP, what I'm referring to is the case where Alice calls Bob, Bob calls Carol, and Bob transfers the call to Carol. The PBX sends an INVITE to Alice and Sue (in whatever order) to get the two communicating. So, whereas we had (A || B) as a call then then (B || C) as a call, but then after the transfer, we have (A || C) as the only call. We need this kind of behavior (where the Session-ID changes) since we want to be able to identify a session end-to-end and those ends might move around mid-call. What we do not want, I would hope, is that we end up with a solution where we have two values (A || B) and (B || C) when B isn't even in the call. It very much defeats the purpose of having an end-to-end identifier, as it does not go end-to-end. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Brett Tate > Sent: Tuesday, August 28, 2012 9:20 AM > To: insipid@ietf.org > Subject: Re: [Insipid] REQ10: evaluation > > > REQ10: It must be possible to correlate two end-to-end sessions when > > the sessions are created by a third party controller using 3PCC > > procedures as described shown in Figure 1, as described in RFC 3725. > > As far as I know, this requirement should not be added since it does not > meet the "one in / one out case where the To/From header fields could have > been preserved" situation (unless the requirement can be met without > informing A of the B's Session-ID fragment). Thus I think that the > requirement should not be included within draft. > > If such 3PCC specific requirements are actually within scope for insipid, > the requirement should clarify if implying that a Session-ID can change > within a dialog. REQ10 should also clarify if only applicable to specific > 3PCC procedure shown within figure 1 or also applicable to all of the > other 3PCC procedures and call flows (such as Figure 13 or reconnecting > two existing dialogs which have different existing Session-ID values). > > Thanks, > Brett > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Aug 28 21:11:08 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 69FC121F8498 for ; Tue, 28 Aug 2012 21:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 Hutz+x9TKEu7 for ; Tue, 28 Aug 2012 21:11:07 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDFF21F8497 for ; Tue, 28 Aug 2012 21:11:07 -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 q7T4B4Oe030610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 00:11:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346213465; bh=gMD9dtJf235dRumFfbcqLF8TEq5qfJnCroMkl3gB3TQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dAqHWOhfgCUUjB0TZS8eO2tZxhssaYP91SIwldHRACRwwhGK3XIXeWGrBnLxKbqx2 ZyZ45vHbYwLQGTIupX0MuCz8Jnfj2U/Sixf5dH/0XWVLJsC12olFEsKPF86j74T/aC uO4ayF5fV7NhE2u+2VXz55henkti1RBnKCf7VHlA= From: "Paul E. Jones" To: "'Brett Tate'" , References: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.citservers.local> Date: Wed, 29 Aug 2012 00:11:24 -0400 Message-ID: <035501cd859c$5af4d6c0$10de8440$@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: AQGg35NYEKdcc5YthbCPW9iyKUWvVwGaPaSTl7ylwaA= Content-Language: en-us Subject: Re: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: 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, 29 Aug 2012 04:11:08 -0000 Brett, With what we had proposed, whether a device uses REFER or not makes no difference. In our original proposal, Alice will have some value A that persists for the duration of the call. Likewise, Bob and Carol would have UUIDs that persist. So, regardless of what the signaling looks like, Alice retains her value A until the call is terminated. There might be some debate over whether Alice should carry the value A even when receiving a REFER and initiating a new INVITE to Carol, though I would prefer that it did. However, in all cases where Alice does not send a new INVITE in response to a REFER, but rather some intermediary B2BUA handles the transfer, Alice would definitely retain A. Do you still think we need to break these out? Will the expanded requirements change the signaling flow outside of the B2BUA? If so, I'll be happy to add them if you me exactly what you'd like to have in the text in the form of a requirement. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Brett Tate > Sent: Tuesday, August 28, 2012 12:54 PM > To: insipid@ietf.org > Subject: Re: [Insipid] 3.X Tracking sessions transferred from one endpoint > to another: evaluation > > > 3.X Tracking sessions transferred from one endpoint to another: > > > > It is difficult to track which SIP messages where involved in the same > > call across transactions, especially when invoking supplementary > > services such as call transfer or call join. The ability to track > > communications sessions as they are transferred, one side at a time, > > through until completion of the session (i.e., until a BYE is sent). > > As far as I know, this use case should not be added since it does not meet > the "one in / one out case where the To/From header fields could have been > preserved" situation (unless the use case can actually be met without > changing session identifier within existing dialog). Thus I think that > the use case should not be included within draft. > > If such use cases are within scope for insipid, the use case should likely > be split into multiple parts or uses cases. The following are a few > parts; however there are likely other interesting related use case. > > 1) B2BUA connecting 4 dialogs for 2 active calls (A-B and A-C). B2BUA > receives REFER with Refer-To replaces from one party (A) involved in both > calls (attended transfer), the B2BUA reconnects the other two parties (B > and C) together using re-INVITE. > > 2) B2BUA connecting two dialogs for active call. B2BUA > reconnects/transfers one party (using re-INVITE) to a new party (such as > within RFC 3725 figures 7 and 13). > > 3) B2BUA connecting two dialogs for active call. B2BUA receives INVITE > with Replaces to replace one of the connections/dialogs. > > Thanks, > Brett > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From brett@broadsoft.com Wed Aug 29 04:09:08 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 D5FAA21F85AA for ; Wed, 29 Aug 2012 04:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 EyHPQXoLdSsY for ; Wed, 29 Aug 2012 04:09:07 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82321F8499 for ; Wed, 29 Aug 2012 04:09:07 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 Aug 2012 04:12:50 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 29 Aug 2012 04:12:50 -0700 From: Brett Tate To: "Paul E. Jones" , "insipid@ietf.org" Date: Wed, 29 Aug 2012 04:09:04 -0700 Thread-Topic: [Insipid] REQ10: evaluation Thread-Index: AQJXn5mu3Zi+tP+Be4VcCRefHdJpXwK5a/dGlkYpvqCAAHF4UA== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F99CC@EXMBXCLUS01.citservers.local> References: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9875@EXMBXCLUS01.citservers.local> <035301cd859b$346a28d0$9d3e7a70$@packetizer.com> In-Reply-To: <035301cd859b$346a28d0$9d3e7a70$@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: [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, 29 Aug 2012 11:09:09 -0000 Hi Paul, > I've said many times that I believe it's absolutely a=20 > requirement that session IDs change in a dialog. =20 Since allowing the session ID to change appears (per Keith's email) to requ= ire changing the insipid charter, should the request to change the charter = occur now or during the WGLC of draft-ietf-insipid-session-id-reqts and dra= ft-ietf-insipid-session-id? More specifically, I'm wondering if insipid sh= ould continue working on the drafts as though it won't subsequently have an= y problems changing the charter to accommodate the requirements and solutio= n. http://www.ietf.org/mail-archive/web/insipid/current/msg00255.html Thanks, Brett From paulej@packetizer.com Wed Aug 29 09:13:22 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 4767521F867F for ; Wed, 29 Aug 2012 09:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 VhDtP5nyUjDo for ; Wed, 29 Aug 2012 09:13:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 622F421F8533 for ; Wed, 29 Aug 2012 09:13:21 -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 q7TGDHxO028514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 12:13:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346256798; bh=nydsPDnY87DxHjeHRQKxofL7WIYRtjaD4J16/jEgcMM=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=oaJdODAPybCJLl9uQT0w+8ah3Oh2JxaW9z/Hh6prqbpdXYG31Fm9I1zCK8gGaRZ++ oKUiWLuxf8p38gdt7L6lEYCumWnNTDXAQnztoJEhMjpEyimF1hGQwf2XDm/YlCXHwj xOkoBOd0FkGXHr8QcnBP9IjXWJmQpv2AGu6mi9Rk= From: "Paul E. Jones" To: "'Brett Tate'" , References: <201208272329.q7RNSxVr016826@mtv-core-2.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9875@EXMBXCLUS01.citservers.local> <035301cd859b$346a28d0$9d3e7a70$@packetizer.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F99CC@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F99CC@EXMBXCLUS01.citservers.local> Date: Wed, 29 Aug 2012 12:13:38 -0400 Message-ID: <042901cd8601$402af9e0$c080eda0$@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: AQJXn5mu3Zi+tP+Be4VcCRefHdJpXwK5a/dGAvg+O9gCvJ8WN5YZSTxQ Content-Language: en-us 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, 29 Aug 2012 16:13:22 -0000 Brett, If changing the charter is what it take, yes. But is it necessary? The charter says we want to have an identifier that identifies a "session from the point of origin ... to the ultimate point of termination." There are a few points I'd like to make on that sentence: 1) If Alice calls Bob and the call passes through a forking proxy, would we not like to have separate ID for B1, B2, B3 (i.e., A || B1, A || B2, A || B3)? I would, because each of those are pending sessions. We do not know which Bob will answer, but we would like to trace signaling messages end-to-end for each. 2) If a call is transferred mid-call without REFER, I assume service providers would like to be able to know that a call coming into the enterprise and then back out to a different endpoint is actually the same call. (This was the main reason we propose using two UUIDs in the first place, allowing those to change mid-call.) 3) If a call is transferred using REFER, I would still like to be able to associate Alice's UUID with the original call. Thus, when Alice sends an INVITE in response to REFER, she would continue to use the same UUID. I'm not opposed to the wording in that sentence, as changing it to consider forked cases would make it overly complex. Perhaps the one thing we need to add is that we have to recognize the fact that a call does not stay permanently fixed at a point of termination. For that matter, the point of origin is not necessarily fixed. Since either Alice or Bob can be exchanged for a different endpoint (or multiple endpoints), we need a mechanism that is flexible enough to accommodate those changes. That's what our proposal was about from the start, but somehow the charter is interpreted more strictly and, as such, does not consider pre-answer situations or mid-call interactions. Paul > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Wednesday, August 29, 2012 7:09 AM > To: Paul E. Jones; insipid@ietf.org > Subject: RE: [Insipid] REQ10: evaluation > > Hi Paul, > > > I've said many times that I believe it's absolutely a requirement that > > session IDs change in a dialog. > > Since allowing the session ID to change appears (per Keith's email) to > require changing the insipid charter, should the request to change the > charter occur now or during the WGLC of draft-ietf-insipid-session-id- > reqts and draft-ietf-insipid-session-id? More specifically, I'm wondering > if insipid should continue working on the drafts as though it won't > subsequently have any problems changing the charter to accommodate the > requirements and solution. > > http://www.ietf.org/mail-archive/web/insipid/current/msg00255.html > > Thanks, > Brett From jmpolk@cisco.com Wed Aug 29 13:11:25 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 8294821F86D6 for ; Wed, 29 Aug 2012 13:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.513 X-Spam-Level: X-Spam-Status: No, score=-111.513 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, GB_I_LETTER=-2, 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 z16DGJVsmvq5 for ; Wed, 29 Aug 2012 13:11:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71CED11E80EC for ; Wed, 29 Aug 2012 13:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=6279; q=dns/txt; s=iport; t=1346271084; x=1347480684; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=pyuGtTJf9DO79GYUJkjQO3tuSZXcU8MvfRrj1l7b8iM=; b=dJj0js7bKlq+K0N21+8LwnGWEXx+sugRRnApwpwejC854x/ki+5vWnU4 jYsQ5XM5nW1m5kG1s0dklvIMiT/BH7Af90UNFskUQE2MpLo6q293YyAoz tAg42BCANT5cnpddHPU+x1z/R5E+lZxiDhdXIwrQrtlmgrhWhEDQTqXTm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAR3PlCrRDoJ/2dsb2JhbAA7CrpxgQeCIAEBAQMBAQEBDwElAi0HCwwEBwQOAwQBAQEeCQcZDh8JCAYBEhsHh2UFDJtnoDQEiwgQhkkDiE+bNYFngwGBOgU X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208";a="53487439" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 29 Aug 2012 20:11:16 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7TKBFZt030529; Wed, 29 Aug 2012 20:11:16 GMT Message-Id: <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Aug 2012 15:11:14 -0500 To: Andrew Allen , "shida@ntt-at.com" , "christer.holmberg@ericsson.com" From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 29 Aug 2012 20:11:25 -0000 At 05:00 PM 8/16/2012, Andrew Allen wrote: >If its at all possible to make the INSIPID solution backwards >compatible with the Kaplan draft I would strongly urge we do this. > >With several pre-standards deployments already based on Kaplan >draft there is a real danger that INSIPID solution will become an >unimplemented standard if it is not backward compatible with what >has already been deployed. err, "...will become an unimplemented standard..." really? Is everyone who will ever implement the Session-ID RFC implementing the individual draft version now? I highly think not. Therefore I don't believe this is justification or a valid threat to this WG to tune our standard towards what previously hasn't yet been accepted in the years it's been available by any WG in the IETF. >While we don't guarantee to maintain compatibility with earlier >versions of drafts it is in our interest to attempt to be compatible >with what has been deployed commercially. > >Running code is of course something we desire and believe in! yes, if that code meets all the reasonable requirements. Running code that only meets some of the requirements is only a partial implementation, by definition. James >Andrew > >----- Original Message ----- >From: Shida Schubert [mailto:shida@ntt-at.com] >Sent: Wednesday, August 15, 2012 12:01 PM >To: Christer Holmberg >Cc: insipid@ietf.org >Subject: Re: [Insipid] Backward compability between draft-jones >and draft-kaplan > > > As we have the kaplan spec implemented and deployed, >I support Christer's proposal. > > Regards > Shida > >On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > > > Hi, > > > > In Vancouver, I expressed a wish to make the INSIPID mechanism > backward compatible with the draft-kaplan-session-id one, the > reason being that it has been around for a relatively long time, > and has been implemented and deployed. > > > > I compared the suggested draft-jones solution with the > draft-kaplan solution, and I think there are ways to achieve > backward compability. > > > > > > -------------- > > > > > > FIRST, looking purely at the ABNF syntax: > > > > The jones ABNF is: > > > > > > Session-ID-UUID = "Session-ID-UUID" HCOLON UUID > > > > > > > > The kaplan ABNF is: > > > > > > > > Session-ID = "Session-ID" HCOLON sess-id > > > > *( SEMI generic-param ) > > > > sess-id = 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > > > > > > > > > > Now, assuming 32 chars is enough to carry ONE UUID, jones > applications could put the SECOND UUID in a header field parameter > (generic-param), rather than combining it with the received UUID. > > > > > > > > Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. > > > > > > > > A UUID can contain characters 0-9 and a-f and A-F. > > > > > > > > So, a jones entity would have to be prepared to receive g-z. > > > > > > > > And, as kaplan entity is not prepared to receive capital A-F, a > jones entity would have to only use small letters. But, that should > not be a problem, afaik, as they have the same meaning as far as > UUID is concerned. > > > > > > > > -------------- > > > > > > > > SECOND, looking at it would work functionwise: > > > > > > > > There are two main alternatives: > > > > > > > > > > > > 1. Second UUID is added even when one entity is kaplan compliant > > > > 2. Second UUID is not added when one entity is kaplan compliant > > > > > > > > > > > > Alternative 1: > > > > > > > > When a kaplan entity inserts the first UUID (I use that as a > general term, eventhough a kaplan entity does not use UUIDs), one > must assume that it is prepared to receive a response from a jones > entity which has added the second UUID into the header field parameter. > > > > > > > > When a jones entity inserts the first UUID, one must assume that > it is prepared to receive a response from a kaplan entity where the > second UUID has *not* been added. > > > > > > > > > > > > Alternative 2: > > > > > > > > When a kaplan entity inserts the first UUID, the jones entity > detects (using some identify-a-kaplan-entity mechanism) that it > comes from a kaplan entity, so it does not insert a seoncd UUID in > the first place. > > > > > > > > As in alternative 1, when a jones entity inserts the first UUID, > it has to be prepared to receive a response where the second UUID > has not been added (the identify-a-kaplan-entity mechanism might > also inform the jones entity that the response comes from a kaplan entity. > > > > > > > > > > > > -------------- > > > > > > > > Now, there will of course be cases, where two UUIDs are required, > that won't work. But, kaplan entities would be able to use the > session-id for whatever they've used it so far. > > > > > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain >confidential information, privileged material (including material >protected by the solicitor-client or other applicable privileges), >or constitute non-public information. Any use of this information by >anyone other than the intended recipient is prohibited. If you have >received this transmission in error, please immediately reply to the >sender and delete this information from your system. Use, >dissemination, distribution, or reproduction of this transmission by >unintended recipients is not authorized and may be unlawful. >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Wed Aug 29 13:27:22 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 B101611E80F0 for ; Wed, 29 Aug 2012 13:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.159 X-Spam-Level: X-Spam-Status: No, score=-7.159 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, GB_I_LETTER=-2, 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 uhFsiAQyJUdg for ; Wed, 29 Aug 2012 13:27:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2A11E80EA for ; Wed, 29 Aug 2012 13:27:20 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-53-503e7b27afeb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 40.3E.17130.72B7E305; Wed, 29 Aug 2012 22:27:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 29 Aug 2012 22:27:19 +0200 From: Christer Holmberg To: James Polk , Andrew Allen , "shida@ntt-at.com" Date: Wed, 29 Aug 2012 22:27:18 +0200 Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: Ac2GIng8/cBwkMKsT42Zh7bOY8Ie+gAANP9V Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F55@ESESSCMS0356.eemea.ericsson.se> References: , <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> In-Reply-To: <201208292011.q7TKBFZt030529@mtv-core-4.cisco.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+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvra5GtV2AwZtDnBbTOrcyW8y//4zJ YseaQovfh+axOrB4TPm9kdVjyZKfTB49l2Yzekz4spIlgCWKyyYlNSezLLVI3y6BK+PC7aSC VrOKP/+2MTYwTtHqYuTkkBAwkbi7ZiILhC0mceHeejYQW0jgFKPEu968LkYuIHsOo0THr7NM XYwcHGwCFhLd/7RBakQEMiWOT9gMVs8soCmxYvFtdhCbRUBV4vKPS6wgtrBAsMSvA9uYIepD JC7NmMEKYRtJfO9rBrN5BcIllqxqZYTYtZ5R4mzXSrBBnAL2Ehdb3jGB2IxAx30/tYYJYpm4 xK0n85kgjhaQWLLnPDOELSrx8vE/Voh6UYk77esZIep1JBbs/gR1qLbEsoWvmSEWC0qcnPmE ZQKj2CwkY2chaZmFpGUWkpYFjCyrGIVzEzNz0svN9VKLMpOLi/Pz9IpTNzEC4+vglt8GOxg3 3Rc7xCjNwaIkzqunut9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2O6u4bkv+9/dumJ/5kg 8NU/kGGCqVHSqdKI2mu91aJ+m3l9mN+pTVfVe6x2gutdYtx9fY4JxlkcglVHNgr4ys+Raijy YU80irfgbHgq99d1/8vJh5kDbHLOW30RPNYo9ue8okOR1YxDd7MdprbMypMxZkyz2rpu2V0G r9rTB3iunqpS2PrkkBJLcUaioRZzUXEiAGOXcg59AgAA 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, 29 Aug 2012 20:27:22 -0000 Hi, >>If its at all possible to make the INSIPID solution backwards >>compatible with the Kaplan draft I would strongly urge we do this. >> >>With several pre-standards deployments already based on Kaplan >>draft there is a real danger that INSIPID solution will become an >>unimplemented standard if it is not backward compatible with what >>has already been deployed. > > err, "...will become an unimplemented standard..." really? > > Is everyone who will ever implement the Session-ID RFC implementing > the individual draft version now? I highly think not. > > Therefore I don't believe this is justification or a valid threat to > this WG to tune our standard towards what previously hasn't yet been > accepted in the years it's been available by any WG in the IETF. Assuming that people will deploy the INSIPID solution is in my opinion a go= od reason why we should aim at making it backward compatible. Me and Hadriel have presented some ideas on how it could be done. I think w= e can get pretty far simply by alligning the syntax. >>While we don't guarantee to maintain compatibility with earlier >>versions of drafts it is in our interest to attempt to be compatible >>with what has been deployed commercially. >> >>Running code is of course something we desire and believe in! > >yes, if that code meets all the reasonable requirements. Running code >that only meets some of the requirements is only a partial >implementation, by definition. I believe the draft implementations meet the requirements that were used to= justify the implementation of the draft. I am not suggesting that we should not be allowed to specify additional req= uirements for the INSIPID solution. Draft implementations will still only s= upport the requirements they support today, but they will be able to commun= icate with INSIPID implementations. Regards, Christer >----- Original Message ----- >From: Shida Schubert [mailto:shida@ntt-at.com] >Sent: Wednesday, August 15, 2012 12:01 PM >To: Christer Holmberg >Cc: insipid@ietf.org >Subject: Re: [Insipid] Backward compability between draft-jones >and draft-kaplan > > > As we have the kaplan spec implemented and deployed, >I support Christer's proposal. > > Regards > Shida > >On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > > > Hi, > > > > In Vancouver, I expressed a wish to make the INSIPID mechanism > backward compatible with the draft-kaplan-session-id one, the > reason being that it has been around for a relatively long time, > and has been implemented and deployed. > > > > I compared the suggested draft-jones solution with the > draft-kaplan solution, and I think there are ways to achieve > backward compability. > > > > > > -------------- > > > > > > FIRST, looking purely at the ABNF syntax: > > > > The jones ABNF is: > > > > > > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID > > > > > > > > The kaplan ABNF is: > > > > > > > > Session-ID =3D "Session-ID" HCOLON sess-id > > > > *( SEMI generic-param ) > > > > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > > > > > > > > > > Now, assuming 32 chars is enough to carry ONE UUID, jones > applications could put the SECOND UUID in a header field parameter > (generic-param), rather than combining it with the received UUID. > > > > > > > > Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. > > > > > > > > A UUID can contain characters 0-9 and a-f and A-F. > > > > > > > > So, a jones entity would have to be prepared to receive g-z. > > > > > > > > And, as kaplan entity is not prepared to receive capital A-F, a > jones entity would have to only use small letters. But, that should > not be a problem, afaik, as they have the same meaning as far as > UUID is concerned. > > > > > > > > -------------- > > > > > > > > SECOND, looking at it would work functionwise: > > > > > > > > There are two main alternatives: > > > > > > > > > > > > 1. Second UUID is added even when one entity is kaplan compliant > > > > 2. Second UUID is not added when one entity is kaplan compliant > > > > > > > > > > > > Alternative 1: > > > > > > > > When a kaplan entity inserts the first UUID (I use that as a > general term, eventhough a kaplan entity does not use UUIDs), one > must assume that it is prepared to receive a response from a jones > entity which has added the second UUID into the header field parameter. > > > > > > > > When a jones entity inserts the first UUID, one must assume that > it is prepared to receive a response from a kaplan entity where the > second UUID has *not* been added. > > > > > > > > > > > > Alternative 2: > > > > > > > > When a kaplan entity inserts the first UUID, the jones entity > detects (using some identify-a-kaplan-entity mechanism) that it > comes from a kaplan entity, so it does not insert a seoncd UUID in > the first place. > > > > > > > > As in alternative 1, when a jones entity inserts the first UUID, > it has to be prepared to receive a response where the second UUID > has not been added (the identify-a-kaplan-entity mechanism might > also inform the jones entity that the response comes from a kaplan entity= . > > > > > > > > > > > > -------------- > > > > > > > > Now, there will of course be cases, where two UUIDs are required, > that won't work. But, kaplan entities would be able to use the > session-id for whatever they've used it so far. > > > > > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain >confidential information, privileged material (including material >protected by the solicitor-client or other applicable privileges), >or constitute non-public information. Any use of this information by >anyone other than the intended recipient is prohibited. If you have >received this transmission in error, please immediately reply to the >sender and delete this information from your system. Use, >dissemination, distribution, or reproduction of this transmission by >unintended recipients is not authorized and may be unlawful. >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid= From jmpolk@cisco.com Wed Aug 29 13:27: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 9EDC711E80EC for ; Wed, 29 Aug 2012 13:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 yyakB+mytl2r for ; Wed, 29 Aug 2012 13:27:53 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 88C0F11E80EA for ; Wed, 29 Aug 2012 13:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2284; q=dns/txt; s=iport; t=1346272072; x=1347481672; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=JXuvxtMiT34mlEGgiooBmtwmrRhCj7Nhcwie/GzEzIE=; b=aP/aN9VjWGdoYErZYm3RyY1tVwPoK4XCsUrVu//1eo3g88grBeohMi2v Y6VIjDnoiiZPxvZ8rX4MzEjyYnrli0t77l4LseXYjg+x4PMgh+d3VCZqt gz1bCAroUqUeKeitK51GUGu6SjXiRj5kJtRI7PWO1HkWRppJtgFaoeN8b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALl6PlBIo8UY/2dsb2JhbABFu3mCIAEBAQQBAQEPASUCNBsHBBgeEBkOMAYBCQkih2sLm22gOgSLCIZZA4hPmzWBZ4MB X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208";a="16576591" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 29 Aug 2012 20:27:50 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7TKRmIH023851; Wed, 29 Aug 2012 20:27:49 GMT Message-Id: <201208292027.q7TKRmIH023851@bgl-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Aug 2012 15:27:46 -0500 To: Brett Tate , "insipid@ietf.org" From: James Polk In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.cit servers.local> References: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.citservers.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: 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, 29 Aug 2012 20:27:53 -0000 At 11:53 AM 8/28/2012, Brett Tate wrote: > > 3.X Tracking sessions transferred from one endpoint > > to another: > > > > It is difficult to track which SIP messages where > > involved in the same call across transactions, > > especially when invoking supplementary services such > > as call transfer or call join. The ability to track > > communications sessions as they are transferred, one > > side at a time, through until completion of the > > session (i.e., until a BYE is sent). > >As far as I know, this use case should not be added since it does >not meet the "one in / one out case where the To/From header fields >could have been preserved" situation (unless the use case can >actually be met without changing session identifier within existing >dialog). Thus I think that the use case should not be included within draft. The ability to track transferred calls across B2BUAs is a fundamental use of this Session-ID. This use-case and requirement needs to stay. >If such use cases are within scope for insipid, the use case should >likely be split into multiple parts or uses cases. The following >are a few parts; however there are likely other interesting related use case. > >1) B2BUA connecting 4 dialogs for 2 active calls (A-B and >A-C). B2BUA receives REFER with Refer-To replaces from one party >(A) involved in both calls (attended transfer), the B2BUA reconnects >the other two parties (B and C) together using re-INVITE. > >2) B2BUA connecting two dialogs for active call. B2BUA >reconnects/transfers one party (using re-INVITE) to a new party >(such as within RFC 3725 figures 7 and 13). > >3) B2BUA connecting two dialogs for active call. B2BUA receives >INVITE with Replaces to replace one of the connections/dialogs. I'm not sure about expanding the call transfer use-case any more than it is, mainly because everyone's got a favorite or few scenarios that will apply here and this text isn't supposed to be 'that' verbose (i.e., for each scenario). I'm not opposed to a few if the WG believes that's needed though. James >Thanks, >Brett > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From atle.monrad@ericsson.com Wed Aug 29 13:39:55 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 8888A11E80ED for ; Wed, 29 Aug 2012 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.482 X-Spam-Level: X-Spam-Status: No, score=-7.482 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Bi4bRIRbk2aT for ; Wed, 29 Aug 2012 13:39:54 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1052911E80F4 for ; Wed, 29 Aug 2012 13:39:53 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-f2-503e7e1803db Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 34.EE.17130.81E7E305; Wed, 29 Aug 2012 22:39:52 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 29 Aug 2012 22:39:52 +0200 From: Atle Monrad To: James Polk , Andrew Allen , "shida@ntt-at.com" , Christer Holmberg Date: Wed, 29 Aug 2012 22:39:50 +0200 Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: Ac2GInmMgh7YnSxVQYC+eTh04z9N5QAAoiAg Message-ID: <7A051DFAA46D0246A82293C7CEF621E90709D2E950@ESESSCMS0352.eemea.ericsson.se> References: <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> In-Reply-To: <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvra5EnV2AwcNpJhbTOrcyW8y//4zJ YseaQovfh+axOrB4TPm9kdVjyZKfTB49l2Yzekz4spIlgCWKyyYlNSezLLVI3y6BK+PrQeGC nZYVWzf8YG5gXKLbxcjJISFgIvFg61RWCFtM4sK99WxdjFwcQgKnGCU2/F3ICOEsYJRo+neY GaSKTUBH4tzPO6wgCRGB+YwS06bsZQRJMAtoSqxYfJsdxGYRUJXY9OI8G4gtLBAkcePjNLC4 iECwxJzzF5kgbCOJMzsWg/XyCoRL/P56Bmr1RkaJr8vOgzVwCthLXGx5B9TAwcEoICsxt4kX Ype4xK0n85kgzhaQWLLnPDOELSrx8vE/sHcYBWQkVmz9xgZRryOxYPcnKFtbYtnC18wQewUl Ts58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYzCuYmZOenl5nqpRZnJxcX5eXrFqZsYgTF2cMtv gx2Mm+6LHWKU5mBREufVU93vLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFR2lXe7uLKyWZu Drru+peb0icfui/acknqONtrXntnmWXWr5b+71HsZZ40SyuNQzH92wwuq1dVfBGR/Vt+LZta U2H+7fz59TsV5i2SWDhho8YLvh2Ly68e/3h3bRiz41vlHS6FjQJfS+JemHs8ZDY6WqK+hMP4 jrlL0f/Is7wtc6Q1llzj09VRYinOSDTUYi4qTgQAZ6ZzbH8CAAA= 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, 29 Aug 2012 20:39:55 -0000 James I understand Andrews comments as a reminder to consider backwards compatibi= lity due to deployed implementations . Obviously people implement drafts on= their own risk, but lets not throw the coding updside down just for fun. My understanding is that Christer and Hadriel have some ideas on how to do = the coding. I hope this can be further considered. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of James Polk Sent: 29. august 2012 22:11 To: Andrew Allen; shida@ntt-at.com; Christer Holmberg Cc: insipid@ietf.org Subject: Re: [Insipid] Backward compability between draft-jones and draft-k= aplan At 05:00 PM 8/16/2012, Andrew Allen wrote: >If its at all possible to make the INSIPID solution backwards=20 >compatible with the Kaplan draft I would strongly urge we do this. > >With several pre-standards deployments already based on Kaplan draft =20 >there is a real danger that INSIPID solution will become an=20 >unimplemented standard if it is not backward compatible with what has=20 >already been deployed. err, "...will become an unimplemented standard..." really? Is everyone who will ever implement the Session-ID RFC implementing the ind= ividual draft version now? I highly think not. Therefore I don't believe this is justification or a valid threat to this W= G to tune our standard towards what previously hasn't yet been accepted in = the years it's been available by any WG in the IETF. >While we don't guarantee to maintain compatibility with earlier=20 >versions of drafts it is in our interest to attempt to be compatible=20 >with what has been deployed commercially. > >Running code is of course something we desire and believe in! yes, if that code meets all the reasonable requirements. Running code that = only meets some of the requirements is only a partial implementation, by de= finition. James >Andrew > >----- Original Message ----- >From: Shida Schubert [mailto:shida@ntt-at.com] >Sent: Wednesday, August 15, 2012 12:01 PM >To: Christer Holmberg >Cc: insipid@ietf.org >Subject: Re: [Insipid] Backward compability between draft-jones=20 >and draft-kaplan > > > As we have the kaplan spec implemented and deployed, I support=20 >Christer's proposal. > > Regards > Shida > >On Aug 14, 2012, at 1:27 PM, Christer Holmberg wrote: > > > Hi, > > > > In Vancouver, I expressed a wish to make the INSIPID mechanism > backward compatible with the draft-kaplan-session-id one, the reason=20 > being that it has been around for a relatively long time, and has been=20 > implemented and deployed. > > > > I compared the suggested draft-jones solution with the > draft-kaplan solution, and I think there are ways to achieve backward=20 > compability. > > > > > > -------------- > > > > > > FIRST, looking purely at the ABNF syntax: > > > > The jones ABNF is: > > > > > > Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID > > > > > > > > The kaplan ABNF is: > > > > > > > > Session-ID =3D "Session-ID" HCOLON sess-id > > > > *( SEMI generic-param ) > > > > sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > > > > > > > > > > Now, assuming 32 chars is enough to carry ONE UUID, jones > applications could put the SECOND UUID in a header field parameter=20 > (generic-param), rather than combining it with the received UUID. > > > > > > > > Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. > > > > > > > > A UUID can contain characters 0-9 and a-f and A-F. > > > > > > > > So, a jones entity would have to be prepared to receive g-z. > > > > > > > > And, as kaplan entity is not prepared to receive capital A-F, a > jones entity would have to only use small letters. But, that should=20 > not be a problem, afaik, as they have the same meaning as far as UUID=20 > is concerned. > > > > > > > > -------------- > > > > > > > > SECOND, looking at it would work functionwise: > > > > > > > > There are two main alternatives: > > > > > > > > > > > > 1. Second UUID is added even when one entity is kaplan compliant > > > > 2. Second UUID is not added when one entity is kaplan compliant > > > > > > > > > > > > Alternative 1: > > > > > > > > When a kaplan entity inserts the first UUID (I use that as a > general term, eventhough a kaplan entity does not use UUIDs), one must=20 > assume that it is prepared to receive a response from a jones entity=20 > which has added the second UUID into the header field parameter. > > > > > > > > When a jones entity inserts the first UUID, one must assume that > it is prepared to receive a response from a kaplan entity where the=20 > second UUID has *not* been added. > > > > > > > > > > > > Alternative 2: > > > > > > > > When a kaplan entity inserts the first UUID, the jones entity > detects (using some identify-a-kaplan-entity mechanism) that it comes=20 > from a kaplan entity, so it does not insert a seoncd UUID in the first=20 > place. > > > > > > > > As in alternative 1, when a jones entity inserts the first UUID, > it has to be prepared to receive a response where the second UUID has=20 > not been added (the identify-a-kaplan-entity mechanism might also=20 > inform the jones entity that the response comes from a kaplan entity. > > > > > > > > > > > > -------------- > > > > > > > > Now, there will of course be cases, where two UUIDs are required, > that won't work. But, kaplan entities would be able to use the=20 > session-id for whatever they've used it so far. > > > > > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid > >--------------------------------------------------------------------- >This transmission (including any attachments) may contain confidential=20 >information, privileged material (including material protected by the=20 >solicitor-client or other applicable privileges), or constitute=20 >non-public information. Any use of this information by anyone other=20 >than the intended recipient is prohibited. If you have received this=20 >transmission in error, please immediately reply to the sender and=20 >delete this information from your system. Use, dissemination,=20 >distribution, or reproduction of this transmission by unintended=20 >recipients is not authorized and may be unlawful. >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed Aug 29 19:22:42 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 F015F21F84B3 for ; Wed, 29 Aug 2012 19:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 qDduY1BvY0hN for ; Wed, 29 Aug 2012 19:22:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B11EA21F848B for ; Wed, 29 Aug 2012 19:22:41 -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 q7U2MW1n023088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Aug 2012 22:22:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346293354; bh=6tvE+PvfO65CwoxXgVpwkoyGLb1Cw0lwKkNroThLGA4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NM9Tf6NeTkrq/4kK6EM+6VBNnfssDEvr4WkMQlPbR9b/Ks8m8ybEN4zwA5OnJpeWw UVwhRQvh5r67cPBcWivROnJEWUGNJinJVhlpSKa8zfpf+mon9IKFR4XFKP8MRzSHl6 +FFwnaopOsG0Gs0Ip3gCCpCHHte1gjwuQruv0qR4= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'James Polk'" , "'Andrew Allen'" , References: , <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F55@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F55@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 29 Aug 2012 22:22:54 -0400 Message-ID: <052401cd8656$5dc95f00$195c1d00$@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+u7rm5T9A76TKhojEtg9ODgAGf25OBAUpa5UoB0sHkvJXbf17Q 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: Thu, 30 Aug 2012 02:22:43 -0000 Christer, > > Therefore I don't believe this is justification or a valid threat to > > this WG to tune our standard towards what previously hasn't yet been > > accepted in the years it's been available by any WG in the IETF. > > Assuming that people will deploy the INSIPID solution is in my opinion a > good reason why we should aim at making it backward compatible. > > Me and Hadriel have presented some ideas on how it could be done. I think > we can get pretty far simply by alligning the syntax. I agree that it looks like we can perhaps make this compatible through syntax. I'm still concerned about use of that syntax, though. I asked before, but I don't think I got an answer to (what I think is) an important question. Let's assume Alice calls Bob. We might have this: Session-ID: A ; p=B Let's also assume Carol calls Bob. We might have this: Session-ID: C ; p=B 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. Paul From christer.holmberg@ericsson.com Thu Aug 30 00:31:03 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 D42DA21F84B6 for ; Thu, 30 Aug 2012 00:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.079, 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 HVq8edZF13yI for ; Thu, 30 Aug 2012 00:31:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4179321F84A0 for ; Thu, 30 Aug 2012 00:30:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-10-503f16b28cab Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.F1.11467.2B61F305; Thu, 30 Aug 2012 09:30:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 30 Aug 2012 09:30:59 +0200 From: Christer Holmberg To: "Paul E. Jones" , 'James Polk' , 'Andrew Allen' , "shida@ntt-at.com" Date: Thu, 30 Aug 2012 09:30:57 +0200 Thread-Topic: [Insipid] Backward compability between draft-jones and draft-kaplan Thread-Index: AQKFof+u7rm5T9A76TKhojEtg9ODgAGf25OBAUpa5UoB0sHkvJXbf17QgABWBnc= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F59@ESESSCMS0356.eemea.ericsson.se> References: , <201208292011.q7TKBFZt030529@mtv-core-4.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F55@ESESSCMS0356.eemea.ericsson.se>, <052401cd8656$5dc95f00$195c1d00$@packetizer.com> In-Reply-To: <052401cd8656$5dc95f00$195c1d00$@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+Jvre4mMfsAg+lbLCymdW5ltph//xmT xY41hRbnL2xgsvh9aB6rA6vHlN8bWT2WLPnJ5NFzaTajR8O+o+weE76sZAlgjeKySUnNySxL LdK3S+DKmH99ImPBG66K9rkbmBoY13N0MXJySAiYSCx9s4kRwhaTuHBvPVsXIxeHkMApRom/ 67tZIZwFjBJrX/SzdDFycLAJWEh0/9MGiYsITGOUOLdkOgtIN7OApsSKxbfZQWpYBFQl1i+X BgkLCwRJNK3qYAWxRQSCJa4/fMACYftJnPt8gh3E5hUIl7j5fQU7xK6NTBJLN55kAklwCthK /Pm+DKyBEei676fWMEHsEpe49WQ+E8TVAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvY7Egt2f 2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLSMgtJyywkLQsYWVYxCucmZuaklxvqpRZlJhcX 5+fpFaduYgTG3cEtv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYO TqkGRmMt4dotAvlxtvnG3F+ev53ed/IwW++1O037/PySO5gvOzpqZqXNsHp+dt2E0Ig+wevn 6hwKX/knZMRdXJO8feH33rmZlrufa0cskWfl+td7okXl8K7pbdu+Lgtyehivtpuh0jswWStQ 6tEkzZ19824pbvzheHOiMO+dmsTGpDMe0U8556//qsRSnJFoqMVcVJwIAMS+C7eJAgAA 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: Thu, 30 Aug 2012 07:31:04 -0000 Hi Paul, >>> Therefore I don't believe this is justification or a valid threat to >>> this WG to tune our standard towards what previously hasn't yet been >>> accepted in the years it's been available by any WG in the IETF. >> >> Assuming that people will deploy the INSIPID solution is in my opinion a >> good reason why we should aim at making it backward compatible. >> >> Me and Hadriel have presented some ideas on how it could be done. I thin= k >> we can get pretty far simply by alligning the syntax. > >I agree that it looks like we can perhaps make this compatible through >syntax. > >I'm still concerned about use of that syntax, though. I asked before, but= I >don't think I got an answer to (what I think is) an important question. > >Let's assume Alice calls Bob. We might have this: > Session-ID: A ; p=3DB > >Let's also assume Carol calls Bob. We might have this: > Session-ID: C ; p=3DB > >Now, suppose Bob transfers the call with Alice to Carol. Bob's PBX does t= he >magic and Bob drops out of the call. Is it OK if the PBX sends Alice this= ? > Session-ID: C; p=3DA > >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?=20 Regards, Christer Paul From brett@broadsoft.com Thu Aug 30 05:03:52 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 2A76B21F85A8 for ; Thu, 30 Aug 2012 05:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 0t-2nCwT+hIX for ; Thu, 30 Aug 2012 05:03:51 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 6314F21F856F for ; Thu, 30 Aug 2012 05:03:51 -0700 (PDT) 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; Thu, 30 Aug 2012 05:07:35 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Thu, 30 Aug 2012 05:07:34 -0700 From: Brett Tate To: "insipid@ietf.org" Date: Thu, 30 Aug 2012 05:03:48 -0700 Thread-Topic: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: evaluation Thread-Index: Ac2GJUt70N1Qq7QWQ0S457hsz0ABaQAevUZQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9BA1@EXMBXCLUS01.citservers.local> References: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.citservers.local> <201208292027.q7TKRmIH023851@bgl-core-4.cisco.com> In-Reply-To: <201208292027.q7TKRmIH023851@bgl-core-4.cisco.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: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: 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: Thu, 30 Aug 2012 12:03:52 -0000 > At 11:53 AM 8/28/2012, Brett Tate wrote: > > > 3.X Tracking sessions transferred from one endpoint > > > to another: > > > > > > It is difficult to track which SIP messages where > > > involved in the same call across transactions, > > > especially when invoking supplementary services such > > > as call transfer or call join. The ability to track > > > communications sessions as they are transferred, one > > > side at a time, through until completion of the > > > session (i.e., until a BYE is sent). > >If such use cases are within scope for insipid, the use case should > >likely be split into multiple parts or uses cases. The following > >are a few parts; however there are likely other interesting related > use case. > > > >1) B2BUA connecting 4 dialogs for 2 active calls (A-B and > >A-C). B2BUA receives REFER with Refer-To replaces from one party > >(A) involved in both calls (attended transfer), the B2BUA reconnects > >the other two parties (B and C) together using re-INVITE. > > > >2) B2BUA connecting two dialogs for active call. B2BUA > >reconnects/transfers one party (using re-INVITE) to a new party > >(such as within RFC 3725 figures 7 and 13). > > > >3) B2BUA connecting two dialogs for active call. B2BUA receives > >INVITE with Replaces to replace one of the connections/dialogs. >=20 > I'm not sure about expanding the call transfer use-case any more than > it is, mainly because everyone's got a favorite or few scenarios that > will apply here and this text isn't supposed to be 'that' verbose > (i.e., for each scenario). I'm not opposed to a few if the WG > believes that's needed though. If the use cases are just to help identify requirements, I agree that they = likely are not needed as long as something captures that it is acceptable (= or mandatory) to be able to change the session identifier within an existin= g dialog. However if the use cases are intended to ensure that the solution draft cov= ers these types of scenarios, these 3 use cases could be useful. Concerning number 1, is the B2BUA supposed to provide a new Session-ID with= in re-INVITE? If not, should the re-INVITE's Session-ID reflect the curren= tly connected dialog or subsequently connected dialog? Concerning number 2 and figure 13, is the B2BUA supposed to provide a new S= ession-ID within re-INVITE (4)? Is the B2BUA supposed to muck with the rec= eived re-INVITE 200 (5) Session-ID or just proxy it within INVITE (6)? Concerning number 3, is the B2BUA supposed to muck with the received INVITE= 's Session-ID or just proxy it within re-INVITE? Thanks, Brett From jmpolk@cisco.com Thu Aug 30 13:28: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 9557921F84FD for ; Thu, 30 Aug 2012 13:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.525 X-Spam-Level: X-Spam-Status: No, score=-110.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, 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 h-Dbb69jFJnv for ; Thu, 30 Aug 2012 13:28:23 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CEF6121F8505 for ; Thu, 30 Aug 2012 13:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3295; q=dns/txt; s=iport; t=1346358503; x=1347568103; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=qE7m7L+Tb0LQ0uckEBtcJpAcRmIrlVY6sx5aMsI2UXI=; b=ETz5//maiKdc7vw9u7EUVVDJh7VpgxJQidUurcoMVOpxAzbUo3CcjkAP wyhamIgYOXABU1sYL1JMVsLr0/JrOMhbsedFpoTTNVCGB9prNlbUy0buA gsluH1AqjrQZ7JDdOmBX8skYqvYix6VwgrksafvyCoUtBEikNXnRjjYqx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOjLP1CrRDoI/2dsb2JhbAA7CrsQgQeCIAEBAQQBAQEPASUCNBsHBBgVCRAZDjAGAQkJGweHagybfKAJBIsIEIMhgygDiE+bOoFngwE X-IronPort-AV: E=Sophos;i="4.80,342,1344211200"; d="scan'208";a="54218283" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Aug 2012 20:28:23 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7UKSMG1004197; Thu, 30 Aug 2012 20:28:22 GMT Message-Id: <201208302028.q7UKSMG1004197@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 30 Aug 2012 15:28:22 -0500 To: Brett Tate , "insipid@ietf.org" From: James Polk In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9BA1@EXMBXCLUS01.cit servers.local> References: <201208272321.q7RNLvEV009606@mtv-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9905@EXMBXCLUS01.citservers.local> <201208292027.q7TKRmIH023851@bgl-core-4.cisco.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9BA1@EXMBXCLUS01.citservers.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] 3.X Tracking sessions transferred from one endpoint to another: 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: Thu, 30 Aug 2012 20:28:24 -0000 At 07:03 AM 8/30/2012, Brett Tate wrote: > > At 11:53 AM 8/28/2012, Brett Tate wrote: > > > > 3.X Tracking sessions transferred from one endpoint > > > > to another: > > > > > > > > It is difficult to track which SIP messages where > > > > involved in the same call across transactions, > > > > especially when invoking supplementary services such > > > > as call transfer or call join. The ability to track > > > > communications sessions as they are transferred, one > > > > side at a time, through until completion of the > > > > session (i.e., until a BYE is sent). > > > > > >If such use cases are within scope for insipid, the use case should > > >likely be split into multiple parts or uses cases. The following > > >are a few parts; however there are likely other interesting related > > use case. > > > > > >1) B2BUA connecting 4 dialogs for 2 active calls (A-B and > > >A-C). B2BUA receives REFER with Refer-To replaces from one party > > >(A) involved in both calls (attended transfer), the B2BUA reconnects > > >the other two parties (B and C) together using re-INVITE. > > > > > >2) B2BUA connecting two dialogs for active call. B2BUA > > >reconnects/transfers one party (using re-INVITE) to a new party > > >(such as within RFC 3725 figures 7 and 13). > > > > > >3) B2BUA connecting two dialogs for active call. B2BUA receives > > >INVITE with Replaces to replace one of the connections/dialogs. > > > > I'm not sure about expanding the call transfer use-case any more than > > it is, mainly because everyone's got a favorite or few scenarios that > > will apply here and this text isn't supposed to be 'that' verbose > > (i.e., for each scenario). I'm not opposed to a few if the WG > > believes that's needed though. > >If the use cases are just to help identify requirements, I agree >that they likely are not needed as long as something captures that >it is acceptable (or mandatory) to be able to change the session >identifier within an existing dialog. > >However if the use cases are intended to ensure that the solution >draft covers these types of scenarios, these 3 use cases could be useful. I agree with what you're saying -- i.e., if they are guidance - each example isn't set in stone for a solution; but if the WG decides each example within a use-case has to be accounted for within any solution, we need tight text for each example then. Plus, we can add examples that any solution has to account for, much like you've listed above. James >Concerning number 1, is the B2BUA supposed to provide a new >Session-ID within re-INVITE? If not, should the re-INVITE's >Session-ID reflect the currently connected dialog or subsequently >connected dialog? > >Concerning number 2 and figure 13, is the B2BUA supposed to provide >a new Session-ID within re-INVITE (4)? Is the B2BUA supposed to >muck with the received re-INVITE 200 (5) Session-ID or just proxy it >within INVITE (6)? > >Concerning number 3, is the B2BUA supposed to muck with the received >INVITE's Session-ID or just proxy it within re-INVITE? > >Thanks, >Brett > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Fri Aug 31 17:59: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 37B8921F84FD for ; Fri, 31 Aug 2012 17:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_05=-1.11] 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 2NcDIfqMi9+5 for ; Fri, 31 Aug 2012 17:59:50 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 705E921F84A5 for ; Fri, 31 Aug 2012 17:59:50 -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 q810xixa006205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Aug 2012 20:59:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1346461186; bh=ZPF75beKNfoxoIer88zV64gdLcSI5wnYEGogFeHyq5s=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=A1BejbkTkeIWAAH15Nr84SrSfpPNGYFRN6eMFohmhSLmRSzwqrn7X9t/pIHu3uh1n pjtACeLA7nUwzzlOk7Yn3IDKjbhaCza6lEqAOQwr0GvYZ1uoqL8PhWeQTbl14fuU4V dQtMmnI6/HwGKIu68Qz3Wfgde7ESl0DTYGnHe0dk= 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> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F59@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 31 Aug 2012 21:00:10 -0400 Message-ID: <078e01cd87dd$23d02c60$6b708520$@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+u7rm5T9A76TKhojEtg9ODgAGf25OBAUpa5UoB0sHkvAJDQlBJARcmEVmVw7noYA== 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: Sat, 01 Sep 2012 00:59:51 -0000 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