From gsalguei@cisco.com Thu Nov 1 09:16: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 0A7E021F8F8F for ; Thu, 1 Nov 2012 09:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.216 X-Spam-Level: X-Spam-Status: No, score=-10.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 dIk+Ge0PyLjp for ; Thu, 1 Nov 2012 09:16:19 -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 1570521F8F8E for ; Thu, 1 Nov 2012 09:16:19 -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 qA1GGI98023109 for ; Thu, 1 Nov 2012 12:16:18 -0400 (EDT) Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA1GGII0019651 for ; Thu, 1 Nov 2012 12:16:18 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Nov 2012 12:16:17 -0400 References: To: insipid@ietf.org Message-Id: <477A8FAB-4566-4BF1-89B6-B295579C67A0@cisco.com> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [Insipid] Fwd: NomCom: Office Hours in Atlanta 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, 01 Nov 2012 16:16:20 -0000 Please help the NomCom and provide feedback. Cheers, Gonzalo Begin forwarded message: >=20 > I apologize for a minor error in the message below. >=20 > In order to ensure that your input is useful to the NomCom, please > send us your feedback on or before Sunday, November 11. > (i.e., NOT November 4 as incorrectly indicated in the email below) >=20 > - Matt Lepinski > nomcom-chair@ietf.org >=20 > On Wed, Oct 31, 2012 at 11:09 PM, Matthew Lepinski > wrote: >> The IETF Nominations Committee (NomCom) continues to seek input from >> the IETF Community. >>=20 >> The final list of candidates (as per RFC 5680) that the NomCom is >> considering for open positions can be found at: >> https://www.ietf.org/group/nomcom/2012/input/ >>=20 >> The NomCom will be holding office hours during IETF 85, Monday- >> Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes >> comments on specific individuals, as well as general feedback related = to >> any of the positions that NomCom is considering. >>=20 >> Note: A list of leadership positions that the NomCom is considering = can be >> found at: https://www.ietf.org/group/nomcom/2012/ >>=20 >> If the NomCom office hours are inconvenient for you or if you cannot >> attend IETF 85, the NomCom is happy to take community input via email >> to nomcom12@ietf.org. Additionally, the NomCom is happy to arrange a >> meeting outside of office hours, just send us email and we can set >> something up. >>=20 >> Comments on specific candidates can also be provided to the NomCom >> via the web feedback tool: >> https://www.ietf.org/group/nomcom/2012/input/ >>=20 >> In order to ensure that your input is received in time to be useful, = please >> provide your input on or before Sunday, November 4. >>=20 >> Thank you for your help, >> - Matt Lepinski >> nomcom-chair@ietf.org From gsalguei@cisco.com Fri Nov 2 09:36:01 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 A5A0721F8D5B for ; Fri, 2 Nov 2012 09:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 0TETjgJlKRMm for ; Fri, 2 Nov 2012 09:36:01 -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 22CAE21F8D5A for ; Fri, 2 Nov 2012 09:36:01 -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 qA2GZxSw010684 for ; Fri, 2 Nov 2012 12:35:59 -0400 (EDT) Received: from rtp-gsalguei-8914.cisco.com (rtp-gsalguei-8914.cisco.com [10.116.132.53]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA2GZvj0023081; Fri, 2 Nov 2012 12:35:58 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Nov 2012 12:35:57 -0400 Message-Id: To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Paul Jones , James Polk , Christer Holmberg Subject: [Insipid] INSIPID Slides 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, 02 Nov 2012 16:36:01 -0000 If you are presenting at the upcoming meeting, please send your slides = no later than Saturday evening so we can get them uploaded and made = available. Thanks, Keith & Gonzalo (as co-chairs)= From eckelcu@cisco.com Sat Nov 3 13:37:49 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 8762C21F9C3D for ; Sat, 3 Nov 2012 13:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrni3FZa7x0e for ; Sat, 3 Nov 2012 13:37:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D800221F9C7C for ; Sat, 3 Nov 2012 13:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1024; q=dns/txt; s=iport; t=1351975069; x=1353184669; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=MVHvb2AkI4HtNcPbFPAWHw53SMSQrcFmiL7hNVSqjwg=; b=UpP8xnNeviBPfbx92nMRby2KY06q23nrZZe15W2XDDFvmi1g2X51krV8 SLy7tiAHymXbrVIeJlsB0N5B2Y4iVdtZYedIrPtnoGTTrdzUSR3u2u5nA hO/KAlpNo+bqLsmLcHR+N/o6CnS4B3dYXYW0BJkO2VBpPstuPFtE/taGN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFV/lVCtJXG+/2dsb2JhbABEwzeBCIIgAQQSARQTUQEqFEImAQQbARmHaAuYKYErnz6MG4VBYQOkVIFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,705,1344211200"; d="scan'208";a="138489760" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 03 Nov 2012 20:37:48 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA3KbmrR015065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 3 Nov 2012 20:37:48 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 15:37:48 -0500 From: "Charles Eckel (eckelcu)" To: "insipid@ietf.org" Thread-Topic: proposal for replacement of "communication session" in requirements draft Thread-Index: Ac26AxV4z+PCFdS8SmW5UejRm5uTaw== Date: Sat, 3 Nov 2012 20:37:47 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882810439D@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.187] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--26.580400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] proposal for replacement of "communication session" in requirements draft 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, 03 Nov 2012 20:37:49 -0000 I was reading draft-ietf-insipid-session-id-reqts-02 and the corresponding= thread: http://www.ietf.org/mail-archive/web/insipid/current/msg00394.html How about we call it a SIP message exchange, where a SIP message exchange c= onsists of one of more SIP transactions between two end systems. A very sim= ple SIP exchange may be a single out-of-dialog SIP transaction (e.g. MESSAG= E/200) between the two end systems. In the case of a SIP dialog, the SIP me= ssage exchange includes a dialog creating INVITE transactions, and zero of= more subsequent SIP transactions within the same dialog (e.g. ACK, re-INVI= TE, BYE). Due to the existence of middle boxes, there may be multiple relat= ed SIP transactions or dialogs chained together along the path from one end= system to the other. For example: A -------middlebox--------B SIP trans1 -----> SIP trans 2 SIP dialog 1 ---> SIP dialog 2 In such cases, the two SIP transactions or dialogs are part of a single SIP= exchange. Cheers, Charles From pkyzivat@alum.mit.edu Sat Nov 3 15:12: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 BDD0721F98B6 for ; Sat, 3 Nov 2012 15:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M72fOUCsRqLg for ; Sat, 3 Nov 2012 15:12:51 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02021F9C35 for ; Sat, 3 Nov 2012 15:12:51 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id K7Qm1k0090xGWP853ACvzD; Sat, 03 Nov 2012 22:12:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id KABk1k0033ZTu2S3YABkWm; Sat, 03 Nov 2012 22:11:44 +0000 Message-ID: <509596E0.3030002@alum.mit.edu> Date: Sat, 03 Nov 2012 18:12:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <92B7E61ADAC1BB4F941F943788C0882810439D@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C0882810439D@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] proposal for replacement of "communication session" in requirements draft 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, 03 Nov 2012 22:12:51 -0000 Charles, This could work. It doesn't have pizzazz, I haven't thought of anything better. If so, maybe we need to have 'message-exchange-id:nnnnn' :-) Thanks, Paul On 11/3/12 4:37 PM, Charles Eckel (eckelcu) wrote: > I was reading draft-ietf-insipid-session-id-reqts-02 and the corresponding thread: > http://www.ietf.org/mail-archive/web/insipid/current/msg00394.html > > How about we call it a SIP message exchange, where a SIP message exchange consists of one of more SIP transactions between two end systems. A very simple SIP exchange may be a single out-of-dialog SIP transaction (e.g. MESSAGE/200) between the two end systems. In the case of a SIP dialog, the SIP message exchange includes a dialog creating INVITE transactions, and zero of more subsequent SIP transactions within the same dialog (e.g. ACK, re-INVITE, BYE). Due to the existence of middle boxes, there may be multiple related SIP transactions or dialogs chained together along the path from one end system to the other. For example: > > A -------middlebox--------B > SIP trans1 -----> SIP trans 2 > SIP dialog 1 ---> SIP dialog 2 > > In such cases, the two SIP transactions or dialogs are part of a single SIP exchange. > > Cheers, > Charles > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From eckelcu@cisco.com Sat Nov 3 17:44: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 B50FD21F9C9A for ; Sat, 3 Nov 2012 17:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCIyByhntmv6 for ; Sat, 3 Nov 2012 17:44:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B901821F9C90 for ; Sat, 3 Nov 2012 17:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1468; q=dns/txt; s=iport; t=1351989841; x=1353199441; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=eGtn3VkWC1P8h0R9t5lT1PMg3QLPxp4554oCgMGjuIA=; b=EqaJHw//1ARcYCbf8JHaIK6W0X6eSxUIeb6DgZpUqjMdnfSYHQlejvwD aOHinubHYVwYSMoJjA+Uao+mLOF5itMJdt0xHL8Xu2Q/8+8sxDNvPzCTd hb+xVYUliXTLSJz/jvmDdOJohfjeLzuG5U0p5hcg5nMszVuAmC0HUk2Qf s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEe5lVCtJXG8/2dsb2JhbABEwzeBCIIgAQQSASdRASoUQh8HAQQbARmHaAuYUIErnyCMG4VBYQOkVIFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,707,1344211200"; d="scan'208";a="138516662" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2012 00:44:01 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA40i1oB013152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Nov 2012 00:44:01 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 19:44:00 -0500 From: "Charles Eckel (eckelcu)" To: "insipid@ietf.org" Thread-Topic: comments on Thread-Index: Ac26JXeQbvX36dUMTjuxHIlQwEzKUw== Date: Sun, 4 Nov 2012 00:43:59 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828104752@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--28.006900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] comments on 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, 04 Nov 2012 00:44:02 -0000 I read the draft and think this version is a good step forward. Paul K. an= d Salvatore already raised most of the comments I had in mind, but I have t= he following which may still be of some value. Section 4 reads as follows: Consider the following example. Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823 Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823 The resulting concatenated Session Identifier would be: 0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 This is no longer true and does not align with the new ABNF (i.e. the addit= ion of the rcvr parameter). My other comment is in regard to: http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html ISTM that a session id aware intermediary should insert a uuid when not pre= sent on behalf on either the endpoint. It might help to enumerate all cases= explicitly: a) Alice includes a session-id and Bob does too=20 Yeah, the intermediary does not alter anything b) Alice includes a session-id and Bob does not Intermediary inserts a session-id in the response on behalf of Bob c) Alice does not include a session-id and Bob does Intermediary inserts a session-id in the request on behalf of Alice d) Alice does not include a session-id and Bob does not either Intermediary inserts a session-id in the request on behalf of Alice and in = the response on behalf of Bob Cheers, Charles From eckelcu@cisco.com Sat Nov 3 18:04:00 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 9829421F95DB for ; Sat, 3 Nov 2012 18:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCkS9nL33PAf for ; Sat, 3 Nov 2012 18:03:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A056221F86CC for ; Sat, 3 Nov 2012 18:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2152; q=dns/txt; s=iport; t=1351991039; x=1353200639; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0Y9ciO9uR+frTpr1cAn+A9LA80jUM1+YLwnBPviOTmA=; b=Ib6iEmVv6Q/tRh9FpiSpAX/AVW4HzPa6+U4YHgvI9HgkbtElKvz8sY4u 5JujQDVGRpIKj7+tn6+pJvG+dwfWX86V/TEKra5BiGXGflR3GIJMXHYeS f1Y52NIbYpdDhmt5/m/x1I9av2c8dqJudIygAYKgoRVu1VT2JotUhHpFL E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALe9lVCtJV2Y/2dsb2JhbABEDsMpgQiCHgEBAQQBAQEPARQTNBcEAgEIDgMEAQEBChQJBycLFAkIAQEEARIIARmHaAuZfZ8gjAEahUFhA6RUgWuCMj2BZBce X-IronPort-AV: E=Sophos;i="4.80,707,1344211200"; d="scan'208";a="138516821" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 04 Nov 2012 01:03:59 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA413xDB009243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 4 Nov 2012 01:03:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 20:03:58 -0500 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] proposal for replacement of "communication session" in requirements draft Thread-Index: Ac26AxV4z+PCFdS8SmW5UejRm5uTawANy7MAAASdu2A= Date: Sun, 4 Nov 2012 01:03:57 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882810478A@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C0882810439D@xmb-aln-x08.cisco.com> <509596E0.3030002@alum.mit.edu> In-Reply-To: <509596E0.3030002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--49.455900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] proposal for replacement of "communication session" in requirements draft 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, 04 Nov 2012 01:04:00 -0000 Yah, perhaps not an optimal name. If we get agreement on the definition, we= can open a naming contest up to the folks who always chime in with catchy = WG names. Cheers, Charles > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Saturday, November 03, 2012 6:13 PM > To: insipid@ietf.org > Subject: Re: [Insipid] proposal for replacement of "communication session= " > in requirements draft >=20 > Charles, >=20 > This could work. It doesn't have pizzazz, I haven't thought of anything > better. >=20 > If so, maybe we need to have 'message-exchange-id:nnnnn' :-) >=20 > Thanks, > Paul >=20 > On 11/3/12 4:37 PM, Charles Eckel (eckelcu) wrote: > > I was reading draft-ietf-insipid-session-id-reqts-02 and the correspon= ding > thread: > > http://www.ietf.org/mail-archive/web/insipid/current/msg00394.html > > > > How about we call it a SIP message exchange, where a SIP message > exchange consists of one of more SIP transactions between two end > systems. A very simple SIP exchange may be a single out-of-dialog SIP > transaction (e.g. MESSAGE/200) between the two end systems. In the case > of a SIP dialog, the SIP message exchange includes a dialog creating INVI= TE > transactions, and zero of more subsequent SIP transactions within the sa= me > dialog (e.g. ACK, re-INVITE, BYE). Due to the existence of middle boxes, > there may be multiple related SIP transactions or dialogs chained togethe= r > along the path from one end system to the other. For example: > > > > A -------middlebox--------B > > SIP trans1 -----> SIP trans 2 > > SIP dialog 1 ---> SIP dialog 2 > > > > In such cases, the two SIP transactions or dialogs are part of a single= SIP > exchange. > > > > Cheers, > > Charles > > _______________________________________________ > > 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 eckelcu@cisco.com Sat Nov 3 18:05: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 9642A21F98D7 for ; Sat, 3 Nov 2012 18:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75lw00gvF7ch for ; Sat, 3 Nov 2012 18:05:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E4DC521F976D for ; Sat, 3 Nov 2012 18:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1766; q=dns/txt; s=iport; t=1351991141; x=1353200741; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=xIJ+sTibipGMEdrYpPg90Hbyu+HMDURKj7VLhXDEuwY=; b=WSFmMQjhk07eq+6wWGP9OtcakubNlDNW/8ejxGqGryFHRQKattifPHMj C8XrE4pQPly0txAnaoVzJb5GeLjmhzQ/3kCggoSgKrLrlVpD/ut9Z6FBp SESDQlFcIZLywNauc5FkIdo3GSMfvjADb0L8+mvTE5dAsWEVErE0oInra o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACa/lVCtJV2d/2dsb2JhbABEwzeBCIIeAQEBBBIBJ0sGARkEAQELFEIdCQEEEwgBGYdoC5hWgSufIIwBGoVBYQOkVIFrgm+BZDU X-IronPort-AV: E=Sophos;i="4.80,707,1344211200"; d="scan'208";a="138300140" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 04 Nov 2012 01:05:40 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA415eAY025586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Nov 2012 01:05:40 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 20:05:39 -0500 From: "Charles Eckel (eckelcu)" To: "insipid@ietf.org" Thread-Topic: comments on draft-jones-insipid-session-id-01 Thread-Index: Ac26KIBEaqJdUcRcS92o0ZZft0m6+A== Date: Sun, 4 Nov 2012 01:05:38 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.222] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001 x-tm-as-result: No--31.774100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] comments on draft-jones-insipid-session-id-01 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, 04 Nov 2012 01:05:41 -0000 Oops - resending with complete subject this time > -----Original Message----- > From: Charles Eckel (eckelcu) > Sent: Saturday, November 03, 2012 8:44 PM > To: insipid@ietf.org > Subject: comments on >=20 > I read the draft and think this version is a good step forward. Paul K. = and > Salvatore already raised most of the comments I had in mind, but I have t= he > following which may still be of some value. >=20 > Section 4 reads as follows: >=20 > Consider the following example. >=20 > Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823 > Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823 >=20 > The resulting concatenated Session Identifier would be: > 0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 >=20 > This is no longer true and does not align with the new ABNF (i.e. the > addition of the rcvr parameter). >=20 > My other comment is in regard to: > http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html >=20 > ISTM that a session id aware intermediary should insert a uuid when not > present on behalf on either the endpoint. It might help to enumerate all > cases explicitly: >=20 > a) Alice includes a session-id and Bob does too > Yeah, the intermediary does not alter anything > b) Alice includes a session-id and Bob does not > Intermediary inserts a session-id in the response on behalf of Bob > c) Alice does not include a session-id and Bob does > Intermediary inserts a session-id in the request on behalf of Alice > d) Alice does not include a session-id and Bob does not either > Intermediary inserts a session-id in the request on behalf of Alice and i= n the > response on behalf of Bob >=20 > Cheers, > Charles From jmpolk@cisco.com Sat Nov 3 23:59:32 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 6B7AF21F9752 for ; Sat, 3 Nov 2012 23:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 rQO3ZEFQgT9a for ; Sat, 3 Nov 2012 23:59:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9818C21F962B for ; Sat, 3 Nov 2012 23:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2820; q=dns/txt; s=iport; t=1352012371; x=1353221971; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=k2WhELwjvXx7x22ZG3fVZWI52Dalw0JSCOjVUBFokqU=; b=ZJFIMwo0b/O7dc+/IA/vg86u1pKdW5WXcGluufm6JpA2GXKtBw33Kflz WvfzAPod0cy6xRwmnMjwt5bXiHtlrRg+PAeWPMywvDC8x6FTGSH9Z2QwY dG4nUeXayN8by5Bk+wfn9PpDzuMq/28b/YXXpjhBbOfSLPeK3FIKznIF/ U=; X-IronPort-AV: E=Sophos;i="4.80,709,1344211200"; d="scan'208";a="138568144" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 04 Nov 2012 06:59:31 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA46xURh007902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 06:59:30 GMT Message-Id: <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 01:59:29 -0500 To: "Charles Eckel (eckelcu)" , "insipid@ietf.org" From: James Polk In-Reply-To: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.c om> References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 04 Nov 2012 06:59:32 -0000 At 09:05 PM 11/3/2012, Charles Eckel (eckelcu) wrote: >Oops - resending with complete subject this time > > > -----Original Message----- > > From: Charles Eckel (eckelcu) > > Sent: Saturday, November 03, 2012 8:44 PM > > To: insipid@ietf.org > > Subject: comments on > > > > I read the draft and think this version is a good step forward. > Paul K. and > > Salvatore already raised most of the comments I had in mind, but I have the > > following which may still be of some value. > > > > Section 4 reads as follows: > > > > Consider the following example. > > > > Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823 > > Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823 > > > > The resulting concatenated Session Identifier would be: > > 0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 > > > > This is no longer true and does not align with the new ABNF (i.e. the > > addition of the rcvr parameter). Charles - you are correct, and this needs to align with the ABNF which is how we are thinking of this solution moving forward. I know this was a case of so many changes that a few (hopefully) small inconsistencies were overlooked (that needed modification too). > > > > My other comment is in regard to: > > http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html > > > > ISTM that a session id aware intermediary should insert a uuid when not > > present on behalf on either the endpoint. So, you want this session id aware intermediary to insert a uuid when which one is not present, the sender's or the receiver's? It matters a lot IMO. I can see uses for this insertion when the sender's is not present, but I believe it is bad for a session id aware intermediary to insert a receiver's before that receiver has had a chance to insert its own. Basically, I want to know which messages you see this insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever (after the dialog is established? >It might help to enumerate all > > cases explicitly: > > > > a) Alice includes a session-id and Bob does too > > Yeah, the intermediary does not alter anything > > b) Alice includes a session-id and Bob does not > > Intermediary inserts a session-id in the response on behalf of Bob > > c) Alice does not include a session-id and Bob does > > Intermediary inserts a session-id in the request on behalf of Alice > > d) Alice does not include a session-id and Bob does not either > > Intermediary inserts a session-id in the request on behalf of > Alice and in the > > response on behalf of Bob > > > > Cheers, > > Charles >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From eckelcu@cisco.com Sun Nov 4 11:45:32 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 A6D7921F865E for ; Sun, 4 Nov 2012 11:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=0.833, 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 lXMycUM1UFpn for ; Sun, 4 Nov 2012 11:45:31 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1A521F8615 for ; Sun, 4 Nov 2012 11:45:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3928; q=dns/txt; s=iport; t=1352058331; x=1353267931; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uSyvQcKu/TvpCVQG6ukFIscIYOx7Vvp+AmUSFYIpTlU=; b=AksZUAE/QTqxJNHMhdKCSWg45T/7r7fM++v627pi4q/eCbQ0VnTSPrjs aIsLeUtv21fRFGUrpJ7m2zukD+5rg0DoTZpQ7ujtqsd/YucHYXACCVzUi d6bc+K7hZuRBrb63y7JnzWMqx495zAIOu5Tf4F66YvEfVvBPShiJ/5Qpi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG7EllCtJV2b/2dsb2JhbABEwzmBCIIeAQEBBAEBAQ8BJzQXBAIBCBEEAQEBChQQJwsdCAIEARIIARIHh2gLmT2fCIwBGoVBYQOkVIFrgm+BZBce X-IronPort-AV: E=Sophos;i="4.80,711,1344211200"; d="scan'208";a="138662512" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 04 Nov 2012 19:45:29 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA4JjT8t024471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 4 Nov 2012 19:45:29 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Sun, 4 Nov 2012 13:45:29 -0600 From: "Charles Eckel (eckelcu)" To: "James Polk (jmpolk)" , "insipid@ietf.org" Thread-Topic: [Insipid] comments on draft-jones-insipid-session-id-01 Thread-Index: AQHNulnwe0DS+iXAV0S82SQ+281SRZfaEabA Date: Sun, 4 Nov 2012 19:45:28 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> In-Reply-To: <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.149] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19338.004 x-tm-as-result: No--56.757100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 04 Nov 2012 19:45:32 -0000 Hi James, please see inline. > -----Original Message----- > From: James Polk (jmpolk) > Sent: Sunday, November 04, 2012 1:59 AM > To: Charles Eckel (eckelcu); insipid@ietf.org > Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 >=20 > At 09:05 PM 11/3/2012, Charles Eckel (eckelcu) wrote: > >Oops - resending with complete subject this time > > > > > -----Original Message----- > > > From: Charles Eckel (eckelcu) > > > Sent: Saturday, November 03, 2012 8:44 PM > > > To: insipid@ietf.org > > > Subject: comments on > > > > > > I read the draft and think this version is a good step forward. > > Paul K. and > > > Salvatore already raised most of the comments I had in mind, but I ha= ve > the > > > following which may still be of some value. > > > > > > Section 4 reads as follows: > > > > > > Consider the following example. > > > > > > Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823 > > > Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823 > > > > > > The resulting concatenated Session Identifier would be: > > > > 0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 > > > > > > This is no longer true and does not align with the new ABNF (i.e. the > > > addition of the rcvr parameter). >=20 > Charles - you are correct, and this needs to align with the ABNF > which is how we are thinking of this solution moving forward. I know > this was a case of so many changes that a few (hopefully) small > inconsistencies were overlooked (that needed modification too). >=20 > > > > > > My other comment is in regard to: > > > http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html > > > > > > ISTM that a session id aware intermediary should insert a uuid when n= ot > > > present on behalf on either the endpoint. >=20 > So, you want this session id aware intermediary to insert a uuid when > which one is not present, the sender's or the receiver's? It matters > a lot IMO. I can see uses for this insertion when the sender's is not > present, but I believe it is bad for a session id aware intermediary > to insert a receiver's before that receiver has had a chance to > insert its own. Basically, I want to know which messages you see this > insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever > (after the dialog is established? I believe was are in agreement. What I am suggesting is as follows: Request from Alice through intermediary to Bob. - Intermediary creates and inserts in request on behalf of Alice if not the= re. Response from Bob through intermediary to Alice. - Intermediary creates and inserts in response on behalf of Bob if not ther= e The next question is what should the intermediary do if the uuid in the req= uest is not included in the response from Bob (i.e. it contains Bob's uuid = but is missing Alice's for some reason, perhaps it was dropped by some othe= r intermediary). I do not see harm in the intermediary re-inserting Alice's= uuid, so I think it should add it back. Cheers, Charles > >It might help to enumerate all > > > cases explicitly: > > > > > > a) Alice includes a session-id and Bob does too > > > Yeah, the intermediary does not alter anything > > > b) Alice includes a session-id and Bob does not > > > Intermediary inserts a session-id in the response on behalf of Bob > > > c) Alice does not include a session-id and Bob does > > > Intermediary inserts a session-id in the request on behalf of Alice > > > d) Alice does not include a session-id and Bob does not either > > > Intermediary inserts a session-id in the request on behalf of > > Alice and in the > > > response on behalf of Bob > > > > > > Cheers, > > > Charles > >_______________________________________________ > >insipid mailing list > >insipid@ietf.org > >https://www.ietf.org/mailman/listinfo/insipid From salvatore.loreto@ericsson.com Sun Nov 4 12:06: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 76DFF21F8830 for ; Sun, 4 Nov 2012 12:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.868 X-Spam-Level: X-Spam-Status: No, score=-105.868 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 29xPuKpRSgl9 for ; Sun, 4 Nov 2012 12:06:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3027821F860D for ; Sun, 4 Nov 2012 12:06:50 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-1f-5096cad7864f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 38.D2.11564.7DAC6905; Sun, 4 Nov 2012 21:06:47 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Sun, 4 Nov 2012 21:06:46 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BDB892ABB for ; Sun, 4 Nov 2012 22:06:46 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0C9F153A22 for ; Sun, 4 Nov 2012 22:06:46 +0200 (EET) Received: from dhcp-12c3.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 849A75356A for ; Sun, 4 Nov 2012 22:06:45 +0200 (EET) Message-ID: <5096CAD5.1060809@ericsson.com> Date: Sun, 4 Nov 2012 15:06:45 -0500 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: insipid@ietf.org References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje71U9MCDLqPa1rMv/+MyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGad+n2It+CZZ0d+9g72B8Z9IFyMHh4SAicT0pZxdjJxAppjE hXvr2boYuTiEBE4ySrx7+p8dwlnPKHH6zCMo5yKjxJ+WKYwQzhFGie/LfjPDOf9eXmICGcYr oC1x/OZdZhCbRUBF4sqhTkYQm03ATOL5wy1gcVGBZIm1n56wQ9QLSpyc+YQFxBYREJH4fXcK WFxYwEXiU9c/qNX7GCUevznBDnI4p4C3REurJEgNs4CtxIU511kgbHmJ7W/nMEM8pCZx9dwm MFtIQEui92wn0wRGkVlI1s1C0j4LSfsCRuZVjOy5iZk56eWGmxiBwXxwy2/dHYynzokcYpTm YFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTEmrbtt2mHRH24bLEMKJnvM8q+6 ucv1jv5swY13FeYpR6zcElgpGCXDuuSgzLKv37ewTRWc/CSL+R/78YvKEp0exUcjfJYuEl96 /tRHNqHQCe/3+Ez5/jf/m3zaTNZ7YvJGYgLuD3uM/LzFgmf5peZWZp9rashbHbVRvcvhwFaZ 7+kbZixkjlZiKc5INNRiLipOBAC32ySgNAIAAA== Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 04 Nov 2012 20:06:52 -0000 On 11/4/12 2:45 PM, Charles Eckel (eckelcu) wrote: > Hi James, please see inline. > >> -----Original Message----- >> From: James Polk (jmpolk) >> Sent: Sunday, November 04, 2012 1:59 AM >> To: Charles Eckel (eckelcu); insipid@ietf.org >> Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 >> >> At 09:05 PM 11/3/2012, Charles Eckel (eckelcu) wrote: >>> Oops - resending with complete subject this time >>> >>>> -----Original Message----- >>>> From: Charles Eckel (eckelcu) >>>> Sent: Saturday, November 03, 2012 8:44 PM >>>> To: insipid@ietf.org >>>> Subject: comments on >>>> >>>> I read the draft and think this version is a good step forward. >>> Paul K. and >>>> Salvatore already raised most of the comments I had in mind, but I have >> the >>>> following which may still be of some value. >>>> >>>> Section 4 reads as follows: >>>> >>>> Consider the following example. >>>> >>>> Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823 >>>> Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823 >>>> >>>> The resulting concatenated Session Identifier would be: >>>> >> 0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 >>>> This is no longer true and does not align with the new ABNF (i.e. the >>>> addition of the rcvr parameter). >> Charles - you are correct, and this needs to align with the ABNF >> which is how we are thinking of this solution moving forward. I know >> this was a case of so many changes that a few (hopefully) small >> inconsistencies were overlooked (that needed modification too). >> >>>> My other comment is in regard to: >>>> http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html >>>> >>>> ISTM that a session id aware intermediary should insert a uuid when not >>>> present on behalf on either the endpoint. >> So, you want this session id aware intermediary to insert a uuid when >> which one is not present, the sender's or the receiver's? It matters >> a lot IMO. I can see uses for this insertion when the sender's is not >> present, but I believe it is bad for a session id aware intermediary >> to insert a receiver's before that receiver has had a chance to >> insert its own. Basically, I want to know which messages you see this >> insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever >> (after the dialog is established? > I believe was are in agreement. What I am suggesting is as follows: > Request from Alice through intermediary to Bob. > - Intermediary creates and inserts in request on behalf of Alice if not there. > Response from Bob through intermediary to Alice. > - Intermediary creates and inserts in response on behalf of Bob if not there I concur things should be like described above by Charles > > The next question is what should the intermediary do if the uuid in the request is not included in the response from Bob (i.e. it contains Bob's uuid but is missing Alice's for some reason, perhaps it was dropped by some other intermediary). I do not see harm in the intermediary re-inserting Alice's uuid, so I think it should add it back. that is a good question, I don't see any harm neither, but I need to to think more about it /Salvatore -- Salvatore Loreto, PhD www.sloreto.com From jmpolk@cisco.com Sun Nov 4 20:47: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 9306A21F89E8 for ; Sun, 4 Nov 2012 20:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 yKUxy8OTLaI9 for ; Sun, 4 Nov 2012 20:47:10 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 15F9621F8865 for ; Sun, 4 Nov 2012 20:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11211; q=dns/txt; s=iport; t=1352090830; x=1353300430; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=eNffXNEpV4V1rcJrcDSkt2tdHge3L3e+AV7zUpNKvAw=; b=IA5UCDItlNAwM1dS9G59kH0qh425a03TQ6JWdZiHU94pp48UQFmN/u3j FNFxDJCGRbY3eUr9r3PCDWDTMBk3N4EyDJX/mH7rRVh4AquENd/0Va8p8 Eq8Kkf/Cp2HN1F7d5FimlVzPGyOAL49liCsJyZGP8VnGrdGgig88hKGSj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPBDl1CtJXG8/2dsb2JhbAA6CgENwy2BCIIeAQEBAwEBAQEPASUCLgYQBwQHBA4DBAEBAR4JBxkOHwkIBgEJCQkSB4diBguZXZ8ZjAEQhiwDiFqOPYoagyOBa4IyXA X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208";a="138721202" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 04:47:09 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-654.cisco.com [10.82.234.144]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA54l74Z031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 04:47:08 GMT Message-Id: <201211050447.qA54l74Z031160@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 22:13:33 -0600 To: Paul Kyzivat , From: James Polk In-Reply-To: <508B02E0.3090500@alum.mit.edu> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 05 Nov 2012 04:47:11 -0000 At 03:38 PM 10/26/2012, Paul Kyzivat wrote: >Here are some things I found while reviewing the latest version: > >Section 4: > > The Session Identifier is comprised of two RFC 4122 defined UUIDs > [4], with each UUID created by the endpoints participating in the > session. > >The above isn't correct when the id is inserted by an intermediary. >I think it might be more correct to say: > > The Session Identifier is comprised of two RFC 4122 defined UUIDs > [4], with each UUID representing one of the endpoints participating > in the session. > >Section 5: > > The "sess-id" value represents the UUID value of the UA transmitting > the message. If the UA transmitting the message previously received > a UUID value from its peer endpoint, it MUST include that UUID as the > "rcvr" parameter. > >I gather this means that the sess-id and rcvr-uuid need to be >swapped in the response to a request. That seems a little odd. It >runs contrary to how most things work in responses. But apparently >it is fundamental to the usage rules. > >Section 6: > > ... Session-ID header-values MUST NOT be present in any other > SIP header than the Session-ID header. > >Why is it important to mandate this? > > UAs MUST ignore the value in the "rcvr" parameter in any message it > receives, as this value may be incorrect due to service interactions > as shown in examples later in this document. > >If it is entirely ignored, then there is no point in sending it. For >instance, wouldn't you want to include it when logging? (Even if the >log also includes the local UUID.) Presumably an inconsistency >between these values may itself be interesting and worth noting. But >it can't be noted if the value in the message is ignored. > >I'm guessing that you mean that the recipient should not be >concerned if the value received is inconsistent with the value it is >holding in local state, and should not replace its local value with >the one received. > >Section 7: > > If performing interworking between SIP and another session protocol, > an intermediary MUST convert the Session-ID header as necessary so > that it properly places the correct UUID value of the message > transmitter and assumed recipient. This is a protocol gateway or > interworking function. > >The above is only possible if the other protocol has a comparable >mechanism in which the value can be represented. Any normative >behavior should be specified as part of the interworking >specification, not here. > >Section 8: > > Note, however, that this assumption of being part of the same > conference is not always true. For example, in a SIP forking > scenario, there might also be what appears to be multiple sessions > with a shared UUID value. This is actually desirable. What is > desired is to allow for the association of related sessions. Whether > sessions are related because of forking or because endpoints are > communicating as a part of a conference does not matter. They are > nonetheless related. > >So, when two sessions have half of a session id in common they are >"related", somehow. Then I might be encouraged to reuse my half when >initiating distinct sessions that I want to be treated as "related". >For instance, if I send a sequence of MESSAGE requests to the same >recipient, and I think they are related, maybe I'll be inclined to >use the same uuid in them? Paul J answered each of the above, and he's been nice enough to volunteer me to answer each of the below. >Section 10.2: > >The re-INVITE usage in this example seems entirely spurious. The >sequence starting with the REFER stands on its own. The bullet: > > o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction, > as described in [RFC3515]. UA-Alice is initially put on hold, > then told in the REFER who to contact with a new INVITE, in this > case UA-Carol. > >makes no sense to me. I understand your confusion, the bullets aren't to be read literally as SIP messages, but more of a 'here's what's happening' pov. This will be cleaned up. Technically, when invoking a call transfer using REFER, Bob would reINVITE Alice to audio=send-only, and once that transaction was completed, Bob would send a REFER directing Alice to INVITE Carol to a session at Bob's request. >Section 10.3: > >This also makes no sense to me as a stand-alone example. How is it >that Bob decides to do a re-INVITE if he wants to transfer to Bob? >How is it that the B2BUA knows it should call Carol? And the BYE >from the B2BUA to Alice means that the call to Carol will no longer >be functional. Many B2BUA's acting as enterprise call controllers (i.e., IP-PBXs) move part of an established end-to-end call when someone is transferred to another UA. You mentioning how this isn't propagated to Alice is how his occurs. >It is possible to construct a hybrid of what is shown in 10.2 and >10.3, where the REFER is terminated by the B2BUA, and not propagated >to Alice. Instead, the B2BUA uses a re-INVITE to Alice to update her >with the session info to Carol. > >Secton 10.4: > >This all seems reasonable. But it assumes that correlating that all >the sessions are part of the same conference is more important than >correlating the initial callin to the conference server with the >portion after logging in to the particular conference. Not true. Alice sends UUID A to the focus, which answers back with UUID M1. That M1 goes away doesn't matter because UID A did not, therefore a log, trace, whatever on that call would turn up any related sessions that had UUID A and consider them part of the same call. >The conference focus is in control of this, based on whether it >switches to a common uuid or not. That is fine if it is the >appropriate entity to make that decision. Not so good for somebody >trying to trace problems that require continuity for the entire call >of one participant. > >Section 10.6: > >Shouldn't the ACK from the B2BUA to Alice have {B,A} ??? oops, sorry about that James > Thanks, > Paul > > >On 10/25/12 8:45 PM, James Polk wrote: >>Here is a list of the changes between the -00 and -01 versions of >>draft-jones-insipid-session-id, for those that have not read this draft >>yet: >> >>- Rewrote a lot of the text (see the diff URL listed below as proof), >>but did not change the overall layout of the sections much, other than >>adding the new sections mentioned below. >> >>- clarified how the Session-ID is constructed exactly. >> >>- changed the ABNF (thanks to Paul K for the help) but did not alter the >>basic concept of two UUIDs (sender and receiver each insert their UUID) >>to construct the Session-ID. >> >>- Added a new section on the 6 different call flow scenarios this >>document solves for, covering >> >> - Basic Session-ID Construction with 2 UUIDs >> - Basic Call Transfer using REFER >> - Basic Call Transfer using reINVITE >> - Single Focus Conferencing >> - Single Focus Conferencing using WebEx >> - Basic 3PCC for two UAs >> >>each call flow shows the values of the UUIDs that make up the Session-ID >>on a per message basis (something that Robert asked for in the Vancouver >>meeting). >> >>- decided against showing how to do a multiple focus conference call in >>this version. That call flow could be added in the next version. >> >>- Added a new section to includeda way to be mostly backwards compatible >>with the "old way" of doing a session-id. It's not perfect, but attempts >>to address each of the 4 scenarios: >> >> - old calling old (should work fine) >> - new calling new (should work fine) >> - old calling new (interesting issues) >> - new calling old (more interesting issues) >> >>Comments and questions are encouraged >> >>James/Paul >> >>At 08:35 PM 10/22/2012, Paul E. Jones wrote: >>>Folks, >>> >>>We've posted a revised version of the proposed solution for the >>>end-to-end >>>session identifier. >>> >>>This draft has been substantially revised and now includes a number of >>>sample call flows. >>> >>>As we discussed during the interim calls, this version changes the >>>syntax in >>>an effort to try to make interworking with the current "Session-ID" >>>header >>>workable. >>> >>>Paul >>> >>> > -----Original Message----- >>> > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- >>> >> > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org >>> > Sent: Monday, October 22, 2012 7:34 PM >>> > To: i-d-announce@ietf.org >>> > Subject: I-D Action: draft-jones-insipid-session-id-01.txt >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> > directories. >>> > >>> > >>> > Title : End-to-End Session Identification in IP-Based >>> > Multimedia Communication Networks >>> > Author(s) : Paul E. Jones >>> > Chris Pearce >>> > James Polk >>> > Gonzalo Salgueiro >>> > Filename : draft-jones-insipid-session-id-01.txt >>> > Pages : 17 >>> > Date : 2012-10-22 >>> > >>> > Abstract: >>> > This document describes an end-to-end Session Identifier for use in >>> > IP-based Multimedia Communication systems that enables endpoints, >>> > intermediate devices, and management systems to identify a session >>> > end-to-end, associate multiple endpoints with a given multipoint >>> > conference, track communication sessions when they are redirected, >>> > and associate one or more media flows with a given communication >>> > session. >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > https://datatracker.ietf.org/doc/draft-jones-insipid-session-id >>> > >>> > There's also a htmlized version available at: >>> > http://tools.ietf.org/html/draft-jones-insipid-session-id-01 >>> > >>> > A diff from the previous version is available at: >>> > http://www.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-01 >>> > >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > I-D-Announce mailing list >>> > I-D-Announce@ietf.org >>> > https://www.ietf.org/mailman/listinfo/i-d-announce >>> > Internet-Draft directories: http://www.ietf.org/shadow.html or >>> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>>_______________________________________________ >>>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 > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Sun Nov 4 20:47: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 F191721F89E8 for ; Sun, 4 Nov 2012 20:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.586 X-Spam-Level: X-Spam-Status: No, score=-110.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 koNeIgtbRzI1 for ; Sun, 4 Nov 2012 20:47:11 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8632521F898B for ; Sun, 4 Nov 2012 20:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5939; q=dns/txt; s=iport; t=1352090830; x=1353300430; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=ufLKSoPWTAcqyNLdNXHqBTQKgw9pVytlqdG2NxfjZ4U=; b=PNPAdUIG3Z/xjLVxlqkaFno9n/rZVrovpTrcowOgzypd8litegT4ZBeR vgrFFagnIibh4itH6nN2qHbsyFErFg/N5QxFivmtRfM95dR3sBNLlByFF n/uOXPKtjR1JhRGw1gTAlrwQTbDd3fH5wvEufePnMbktGB6WyILrCktxO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPBDl1CtJXG8/2dsb2JhbABEDsMtgQiCHgEBAQMBAQEBDwElAi4GGwcEGB4QGQ4wBgESIodiBguZXZ8VBIwBhjwDiFqbeoFrgjJc X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208";a="138786469" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 05 Nov 2012 04:47:10 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-654.cisco.com [10.82.234.144]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA54l74b031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 04:47:09 GMT Message-Id: <201211050447.qA54l74b031160@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 22:20:51 -0600 To: "Paul E. Jones" , "'Paul Kyzivat'" , From: James Polk In-Reply-To: <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 05 Nov 2012 04:47:12 -0000 At 04:42 PM 10/26/2012, Paul E. Jones wrote: >Paul, > > > Here are some things I found while reviewing the latest version: > > > > Section 4: > > > > The Session Identifier is comprised of two RFC 4122 defined UUIDs > > [4], with each UUID created by the endpoints participating in the > > session. > > > > The above isn't correct when the id is inserted by an intermediary. I > > think it might be more correct to say: > > > > The Session Identifier is comprised of two RFC 4122 defined UUIDs > > [4], with each UUID representing one of the endpoints participating > > in the session. > >Sounds good to me. I'll make the change. > > > Section 5: > > > > The "sess-id" value represents the UUID value of the UA transmitting > > the message. If the UA transmitting the message previously received > > a UUID value from its peer endpoint, it MUST include that UUID as > > the > > "rcvr" parameter. > > > > I gather this means that the sess-id and rcvr-uuid need to be swapped in > > the response to a request. That seems a little odd. It runs contrary to > > how most things work in responses. But apparently it is fundamental to > > the usage rules. > >Your interpretation is correct. The sender of the message formulates the >Session-ID header as specified. However, how a header is set does vary. >Some remain the same in an exchange, like CSeq. Some get modified, like the >"To" header with a tag added. Others are set by the sender of the message, >such as the Content-Length header. Session-ID falls into the latter group. > > > Section 6: > > > > ... Session-ID header-values MUST NOT be present in any other > > SIP header than the Session-ID header. > > > > Why is it important to mandate this? I just don't like this header-value showing up anywhere else that someone might not be looking for it and then wonder why things didn't work as planned. Similar constraint on Geolocation header-values. >Good question. I'm sure there was a rationale, but it is not apparent now. >I'll remove it. I'd like that you didn't, for the above reason. James > > > UAs MUST ignore the value in the "rcvr" parameter in any message it > > receives, as this value may be incorrect due to service interactions > > as shown in examples later in this document. > > > > If it is entirely ignored, then there is no point in sending it. For > > instance, wouldn't you want to include it when logging? (Even if the log > > also includes the local UUID.) Presumably an inconsistency between these > > values may itself be interesting and worth noting. But it can't be noted > > if the value in the message is ignored. > >We do want this value to be used by intermediaries, so they should not >ignore it. The reason I inserted this wording is that I do not want a UA to >echo the value it receives back to the sender of that message in any >subsequent message. > >Do you have a suggestion for wording that? > > > I'm guessing that you mean that the recipient should not be concerned if > > the value received is inconsistent with the value it is holding in local > > state, and should not replace its local value with the one received. > >Right. If Carol (UUID=C) receives an INVITE that has "Session-ID: >A;rcvr=B", we do not want Carol to panic because C is not there, but we also >do not want Carol to echo back "Session-ID: B; rcvr=A". Rather, we want >Carol to form a reply like "Session-ID: C; rcvr=A". > > > Section 7: > > > > If performing interworking between SIP and another session protocol, > > an intermediary MUST convert the Session-ID header as necessary so > > that it properly places the correct UUID value of the message > > transmitter and assumed recipient. This is a protocol gateway or > > interworking function. > > > > The above is only possible if the other protocol has a comparable > > mechanism in which the value can be represented. Any normative behavior > > should be specified as part of the interworking specification, not here. > >Is there more to say re: interworking than this? I think there is one more >sentence we should add: > > If not suitable value exists, the intermediary may allocate a > UUID value to represent the endpoint for which it has no other > value. > >Sound reasonable? If we move this, move it to where? Introduce an >interworking section only with this paragraph? > > > Section 8: > > > > Note, however, that this assumption of being part of the same > > conference is not always true. For example, in a SIP forking > > scenario, there might also be what appears to be multiple sessions > > with a shared UUID value. This is actually desirable. What is > > desired is to allow for the association of related sessions. > > Whether > > sessions are related because of forking or because endpoints are > > communicating as a part of a conference does not matter. They are > > nonetheless related. > > > > So, when two sessions have half of a session id in common they are > > "related", somehow. Then I might be encouraged to reuse my half when > > initiating distinct sessions that I want to be treated as "related". For > > instance, if I send a sequence of MESSAGE requests to the same recipient, > > and I think they are related, maybe I'll be inclined to use the same > > uuid in them? > >That we do not want. Except in the case of a conference server, we want >each UA to allocate a unique UUID for each session. > >Section 10.2 onward... Let me allow James to respond on the call flows, as >he provided that text. I don't want to put words in his mouth :-) > >Paul > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Sun Nov 4 20:47: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 8ADA321F89F3 for ; Sun, 4 Nov 2012 20:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.288 X-Spam-Level: X-Spam-Status: No, score=-110.288 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_53=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 zLx2PeTEb+T7 for ; Sun, 4 Nov 2012 20:47:11 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21CE821F89C9 for ; Sun, 4 Nov 2012 20:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6930; q=dns/txt; s=iport; t=1352090831; x=1353300431; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=QsToYZ5DKqJ1snKeA1Vl1d+K1XfbZSV4ieg7z6tHYc8=; b=dQh21l/5QScQGbWSzNnS7uPj8+Nj0G8lrLaxvKB129m0mnp8SRoLhwdz sIsD6qa3RyIvJ1NSq1XH9s9oe92HU+1ov6O0CEOha0yr9Ru2bmyoHpK4L Ju9cvrALCzPMuP6hZYKqwTWI4jF7BvPN+J2m0uUYZmqKKwQ0nHZajMSAo Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADREl1CtJXG8/2dsb2JhbAA6CgHDOoEIgh4BAQEEAQEBDwElAi4GFwQHBBEEAQEBHgkHGQ4fCQgGAQkJCRIHh2gLmV2fGYwBEIYsA4hajj2KGoMjgWuDDoE8JA X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208";a="138776794" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2012 04:47:10 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-654.cisco.com [10.82.234.144]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA54l74d031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 04:47:10 GMT Message-Id: <201211050447.qA54l74d031160@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 22:32:49 -0600 To: Salvatore Loreto , From: James Polk In-Reply-To: <508C2C93.2080500@ericsson.com> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508C2C93.2080500@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 05 Nov 2012 04:47:12 -0000 At 12:48 PM 10/27/2012, Salvatore Loreto wrote: >Hi there > >I have read the 01 and have the following questions > >Example 10.5 is a little confused, as there Alice,Bob and Carol are >not just representation >of their respective SIP UA, but more of their device that include >both an HTTP client + SIP UA > >In general I don't find any extra value in 10.5 comparing it to the >example in 10.4 >unless there is something protocol interworking between HTTP and SIP >that you want point out Sal - Conferencing using Webex was something that was brought up during the last meeting (Vancouver) and I wasn't quick enough to track (when Hadriel talked about conferencing being taken out of the reqs ID because a lot of "higher than layer 7 stuff needs to happen to make that happen". Section 10.5 shows actually that there is no temporary UUIDs created for each UA when they call into a focus, that all of that is handled via an out of band web session to have the focus (Webex server) call the UA directly with the only UUID the webex server will need for everyone attending that webex conference. I'm not pushing Webex as a product here, just that it is something most (all?) of us are familiar with because we've used it ourselves, however frequently or infrequently. James >Cheers >/Sal > > >-- >Salvatore Loreto, PhD >www.sloreto.com > > >On 10/26/12 3:45 AM, James Polk wrote: >>Here is a list of the changes between the -00 and -01 versions of >>draft-jones-insipid-session-id, for those that have not read this draft yet: >> >>- Rewrote a lot of the text (see the diff URL listed below as >>proof), but did not change the overall layout of the sections much, >>other than adding the new sections mentioned below. >> >>- clarified how the Session-ID is constructed exactly. >> >>- changed the ABNF (thanks to Paul K for the help) but did not >>alter the basic concept of two UUIDs (sender and receiver each >>insert their UUID) to construct the Session-ID. >> >>- Added a new section on the 6 different call flow scenarios this >>document solves for, covering >> >> - Basic Session-ID Construction with 2 UUIDs >> - Basic Call Transfer using REFER >> - Basic Call Transfer using reINVITE >> - Single Focus Conferencing >> - Single Focus Conferencing using WebEx >> - Basic 3PCC for two UAs >> >>each call flow shows the values of the UUIDs that make up the >>Session-ID on a per message basis (something that Robert asked for >>in the Vancouver meeting). >> >>- decided against showing how to do a multiple focus conference >>call in this version. That call flow could be added in the next version. >> >>- Added a new section to includeda way to be mostly backwards >>compatible with the "old way" of doing a session-id. It's not >>perfect, but attempts to address each of the 4 scenarios: >> >> - old calling old (should work fine) >> - new calling new (should work fine) >> - old calling new (interesting issues) >> - new calling old (more interesting issues) >> >>Comments and questions are encouraged >> >>James/Paul >> >>At 08:35 PM 10/22/2012, Paul E. Jones wrote: >>>Folks, >>> >>>We've posted a revised version of the proposed solution for the end-to-end >>>session identifier. >>> >>>This draft has been substantially revised and now includes a number of >>>sample call flows. >>> >>>As we discussed during the interim calls, this version changes the >>>syntax in >>>an effort to try to make interworking with the current "Session-ID" header >>>workable. >>> >>>Paul >>> >>> > -----Original Message----- >>> > From: >>> i-d-announce-bounces@ietf.or >>> g [mailto:i-d-announce- >>> > bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> > Sent: Monday, October 22, 2012 7:34 PM >>> > To: i-d-announce@ietf.org >>> > Subject: I-D Action: draft-jones-insipid-session-id-01.txt >>> > >>> > >>> > A New Internet-Draft is available from the on-line Internet-Drafts >>> > directories. >>> > >>> > >>> > Title : End-to-End Session Identification in IP-Based >>> > Multimedia Communication Networks >>> > Author(s) : Paul E. Jones >>> > Chris Pearce >>> > James Polk >>> > Gonzalo Salgueiro >>> > Filename : draft-jones-insipid-session-id-01.txt >>> > Pages : 17 >>> > Date : 2012-10-22 >>> > >>> > Abstract: >>> > This document describes an end-to-end Session Identifier for use in >>> > IP-based Multimedia Communication systems that enables endpoints, >>> > intermediate devices, and management systems to identify a session >>> > end-to-end, associate multiple endpoints with a given multipoint >>> > conference, track communication sessions when they are redirected, >>> > and associate one or more media flows with a given communication >>> > session. >>> > >>> > >>> > The IETF datatracker status page for this draft is: >>> > >>> https://datatracker.ietf.org/doc/draft-jones-insipid-session-id >>> >>> > >>> > There's also a htmlized version available at: >>> > >>> http://tools.ietf.org/html/draft-jones-insipid-session-id-01 >>> >>> > >>> > A diff from the previous version is available at: >>> > >>> http://www.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-01 >>> >>> > >>> > >>> > Internet-Drafts are also available by anonymous FTP at: >>> > ftp://ftp.ietf.org/internet-drafts/ >>> > >>> > _______________________________________________ >>> > I-D-Announce mailing list >>> > I-D-Announce@ietf.org >>> > https://www.ietf.org/mailman/listinfo/i-d-announce >>> > Internet-Draft directories: >>> http://www.ietf.org/shadow.html or >>> > >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>_______________________________________________ >>>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 > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Sun Nov 4 20:47: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 CE6F021F89C9 for ; Sun, 4 Nov 2012 20:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.552 X-Spam-Level: X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 kPSlyyAispSt for ; Sun, 4 Nov 2012 20:47:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 727D521F89D3 for ; Sun, 4 Nov 2012 20:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3612; q=dns/txt; s=iport; t=1352090831; x=1353300431; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=xC1wi4dd6td7+/zXB5NY4ZVY+PcAXzXvj6AvHpP8fP8=; b=FfOmUgcov0GT+iYn6o3yH2sJs9w4eZ1IBuYp85lnrgkReUi7ziM1zLJy rIBBWrU6w0p6UYr+kucGf+RFzmcddhPqqHBvs3/PrRpnbJu73/pQd+LsK CNYED6wpn/y6ENrTCLAeaIntM7gr8R99kFi3nl+Y9Kk5EY0G56ei5WJjA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPBDl1CtJXG8/2dsb2JhbABEDsMtgQiCHgEBAQQBAQEPASUCNAsQBwQYHhAZDjAGARIUDodoC5ldnxUEjAGGPAOIWpt6gWuCMlw X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208";a="138721205" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 05 Nov 2012 04:47:11 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-654.cisco.com [10.82.234.144]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA54l74f031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 04:47:10 GMT Message-Id: <201211050447.qA54l74f031160@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 22:35:09 -0600 To: "Paul E. Jones" , "'Paul Kyzivat'" From: James Polk In-Reply-To: <093901cdb48c$f3b21d90$db1658b0$@packetizer.com> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> <508C1C47.9080006@alum.mit.edu> <093901cdb48c$f3b21d90$db1658b0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: insipid@ietf.org Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 05 Nov 2012 04:47:12 -0000 At 03:49 PM 10/27/2012, Paul E. Jones wrote: > > >> Section 6: > > > > >> UAs MUST ignore the value in the "rcvr" parameter in any message > > it > > >> receives, as this value may be incorrect due to service > > interactions > > >> as shown in examples later in this document. > > >> > > >> If it is entirely ignored, then there is no point in sending it. For > > >> instance, wouldn't you want to include it when logging? (Even if the > > >> log also includes the local UUID.) Presumably an inconsistency > > >> between these values may itself be interesting and worth noting. But > > >> it can't be noted if the value in the message is ignored. > > > > > > We do want this value to be used by intermediaries, so they should not > > > ignore it. The reason I inserted this wording is that I do not want a > > > UA to echo the value it receives back to the sender of that message in > > > any subsequent message. > > > > > > Do you have a suggestion for wording that? > > > > I think you already have normative language for what values should be > > used. So the normative language here is redundant. I would recommend > > replacing this with a Note giving warnings to implementers that > > unexpected values might be seen. > >OK, I'll strike that. How about this note: > > It should be noted that messages received by a UA might contain > a "remote" parameter that does match the UAs UUID. This might > happen as a result of service interactions by intermediaries and > MUST NOT be regarded as an error. > > > >> Section 7: > > >> > > >> If performing interworking between SIP and another session > > protocol, > > >> an intermediary MUST convert the Session-ID header as necessary > > so > > >> that it properly places the correct UUID value of the message > > >> transmitter and assumed recipient. This is a protocol gateway or > > >> interworking function. > > >> > > >> The above is only possible if the other protocol has a comparable > > >> mechanism in which the value can be represented. Any normative > > >> behavior should be specified as part of the interworking > > specification, not here. > > > > > > Is there more to say re: interworking than this? I think there is one > > > more sentence we should add: > > > > > > If not suitable value exists, the intermediary may allocate a > > > UUID value to represent the endpoint for which it has no other > > > value. > > > > > > Sound reasonable? If we move this, move it to where? Introduce an > > > interworking section only with this paragraph? > > > > ISTM that interworking can't be addressed in general. It must be > > addressed case by case. If you want to discuss interworking with H.323, > > then I think it would best be handled as a separate draft. If not that, > > then at least a separate section in this draft focused explicitly on > > that. (I think a separate draft because the community interested in it > > is different. Many people interested in insipid won't be able to comment > > meaningfully on this part.) > >OK, I'll delete it entirely. are we really going to remove all mention of interworking between dissimilar call signaling protocols? Can we not at least have a non-normative comment or discussion about it. It is something that may not be obvious to someone else who just reads this one document. James >Paul > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Sun Nov 4 21:22: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 08A6421F8A66 for ; Sun, 4 Nov 2012 21:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.557 X-Spam-Level: X-Spam-Status: No, score=-110.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 SFl6-2avf9e7 for ; Sun, 4 Nov 2012 21:22:24 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE41D21F8A65 for ; Sun, 4 Nov 2012 21:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4021; q=dns/txt; s=iport; t=1352092944; x=1353302544; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=C4xY2189Y7NSV94DAJxFqzjM6fpdYWsrpvlb2zKvnWY=; b=EAcEH6u5mNe8Td8DQEfLz91b7FvKXnlZxrTGCcDTxEBtIxugMi7MexiH uMYOVwREw46OyHRI76q4tU0IQRhQAW2Fk0zvyEbHegwO8axOpfRULNeHc LTzprbU9lstKZAoNpmVyhj/6oQS3vcru0NOziaDnFA3Bf03xyDYZn0ogP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPNLl1CtJV2Y/2dsb2JhbABEwzuBCIIeAQEBBAEBAQ8BJQI0FwQHBBEEAQEBHhAZDigIBgESCRIHh2gLmWKfG4wBGoYiA4ham3qBa4MOgUU X-IronPort-AV: E=Sophos;i="4.80,713,1344211200"; d="scan'208";a="135747344" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2012 05:22:23 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-654.cisco.com [10.82.234.144]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA55MMAS005068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 05:22:23 GMT Message-Id: <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 04 Nov 2012 23:22:22 -0600 To: Salvatore Loreto , From: James Polk In-Reply-To: <5096CAD5.1060809@ericsson.com> References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> <5096CAD5.1060809@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 05 Nov 2012 05:22:27 -0000 At 02:06 PM 11/4/2012, Salvatore Loreto wrote: >On 11/4/12 2:45 PM, Charles Eckel (eckelcu) wrote: >>Hi James, please see inline. >> >>>-----Original Message----- >>>From: James Polk (jmpolk) >>>Sent: Sunday, November 04, 2012 1:59 AM >>>To: Charles Eckel (eckelcu); insipid@ietf.org >>>Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 >>> >>>At 09:05 PM 11/3/2012, Charles Eckel (eckelcu) wrote: >>>>Oops - resending with complete subject this time >>>> >>>>>-----Original Message----- >>>>>From: Charles Eckel (eckelcu) >>>>>Sent: Saturday, November 03, 2012 8:44 PM >>>>>To: insipid@ietf.org >>>>>Subject: comments on >>>>> >>>>> I read the draft and think this version is a good step forward. >>>>Paul K. and >>>>>Salvatore already raised most of the comments I had in mind, but I have >>>the >>>>>following which may still be of some value. >>>>> >>>>>Section 4 reads as follows: >>>>> >>>>> Consider the following example. >>>>> >>>>> Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823 >>>>> Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823 >>>>> >>>>> The resulting concatenated Session Identifier would be: >>>0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 >>>>>This is no longer true and does not align with the new ABNF (i.e. the >>>>>addition of the rcvr parameter). >>>Charles - you are correct, and this needs to align with the ABNF >>>which is how we are thinking of this solution moving forward. I know >>>this was a case of so many changes that a few (hopefully) small >>>inconsistencies were overlooked (that needed modification too). >>> >>>>>My other comment is in regard to: >>>>>http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html >>>>> >>>>>ISTM that a session id aware intermediary should insert a uuid when not >>>>>present on behalf on either the endpoint. >>>So, you want this session id aware intermediary to insert a uuid when >>>which one is not present, the sender's or the receiver's? It matters >>>a lot IMO. I can see uses for this insertion when the sender's is not >>>present, but I believe it is bad for a session id aware intermediary >>>to insert a receiver's before that receiver has had a chance to >>>insert its own. Basically, I want to know which messages you see this >>>insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever >>>(after the dialog is established? >>I believe was are in agreement. What I am suggesting is as follows: >>Request from Alice through intermediary to Bob. >>- Intermediary creates and inserts in request on behalf of Alice if >>not there. >>Response from Bob through intermediary to Alice. >>- Intermediary creates and inserts in response on behalf of Bob if not there what if there where multiple intermediaries between Alice and Bob... which one gets to decide it inserts? Does it have to be the first SID aware server? >I concur things should be like described above by Charles > >> >>The next question is what should the intermediary do if the uuid in >>the request is not included in the response from Bob (i.e. it >>contains Bob's uuid but is missing Alice's for some reason, this is actually something we looked at in Section 11 in the backwards compatibility section when a version 0 UA talks to a version 1 UA and the Session-ID changed places. No one is sure what the answer is yet. >>perhaps it was dropped by some other intermediary). well, that intermediary is broken and should be taken out of service ;-) James >>I do not see harm in the intermediary re-inserting Alice's uuid, so >>I think it should add it back. >that is a good question, I don't see any harm neither, but I need to >to think more about it > >/Salvatore > >-- >Salvatore Loreto, PhD >www.sloreto.com > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From salvatore.loreto@ericsson.com Mon Nov 5 02:10:47 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 4D63321F88EA for ; Mon, 5 Nov 2012 02:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.906 X-Spam-Level: X-Spam-Status: No, score=-105.906 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 jWLm4KOqQQB1 for ; Mon, 5 Nov 2012 02:10:46 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D19E021F8820 for ; Mon, 5 Nov 2012 02:10:45 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-e3-509790a407dd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CB.F7.26143.4A097905; Mon, 5 Nov 2012 11:10:44 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 5 Nov 2012 11:10:44 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 277672B12; Mon, 5 Nov 2012 12:10:44 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7953E539C1; Mon, 5 Nov 2012 12:10:43 +0200 (EET) Received: from dhcp-4644.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CE4AB53832; Mon, 5 Nov 2012 12:10:42 +0200 (EET) Message-ID: <509790A2.40800@ericsson.com> Date: Mon, 5 Nov 2012 05:10:42 -0500 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: James Polk References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> <5096CAD5.1060809@ericsson.com> <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> In-Reply-To: <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvje6SCdMDDFauMLSYf/8Zk8WONYUO TB5Tfm9k9Viy5CdTAFMUl01Kak5mWWqRvl0CV8aLJ1PYC/YrVSx+epStgfGZdBcjJ4eEgInE iSPXGSFsMYkL99azdTFycQgJnGSU2PLnDyuEs55R4vLfPmYIZxejxIIF36EyaxklurYsZIdz JnacZQEZxiugKfHq+m5mEJtFQEXiaeMjJhCbTcBM4vnDLWBxUYFkibWfnrBD1AtKnJz5BKiX g0NEQFHiyNxqkDCzgIjEvAW9YPcJC7hIfOr6B1YuJDCJSaLjrAqIzSngIPH05WJ2iHpbiQtz rrNA2PIS29/OYYb4TU3i6rlNzBC9WhK9ZzuZJjCKzkKyeRaS9llI2hcwMq9iZM9NzMxJLzfa xAgM+4NbfqvuYLxzTuQQozQHi5I4r/XWPf5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFOV 3TfpeXhrPtdrmyD7/MJWz4ayqpN997oe6L03OSzwP/952f0npffj1mx7dtuueWJA+5bfcrud wyw5/1qxnFc6Uv55aqnkpCKhhOPPKxYw+vjN44s0LTnS9INrx+Ty9/FC7u8142bsK32/Z5OC c9j6ScVv+7RVOARFDgduO6Gkbmne9TKUU4mlOCPRUIu5qDgRAC/B4WlJAgAA Cc: insipid@ietf.org Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 05 Nov 2012 10:10:47 -0000 On 11/5/12 12:22 AM, James Polk wrote: > At 02:06 PM 11/4/2012, Salvatore Loreto wrote: >> On 11/4/12 2:45 PM, Charles Eckel (eckelcu) wrote: >>> Hi James, please see inline. >>> >>>> -----Original Message----- >>>> From: James Polk (jmpolk) >>>> Sent: Sunday, November 04, 2012 1:59 AM >>>> To: Charles Eckel (eckelcu); insipid@ietf.org >>>> Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 >>>> >>>> At 09:05 PM 11/3/2012, Charles Eckel (eckelcu) wrote: >>>>> Oops - resending with complete subject this time >>>>> >>>>>> -----Original Message----- >>>>>> From: Charles Eckel (eckelcu) >>>>>> Sent: Saturday, November 03, 2012 8:44 PM >>>>>> To: insipid@ietf.org >>>>>> Subject: comments on >>>>>> >>>>>> I read the draft and think this version is a good step forward. >>>>> Paul K. and >>>>>> Salvatore already raised most of the comments I had in mind, but >>>>>> I have >>>> the >>>>>> following which may still be of some value. >>>>>> >>>>>> Section 4 reads as follows: >>>>>> >>>>>> Consider the following example. >>>>>> >>>>>> Endpoint 1 produces this UUID: >>>>>> 0xaeffa652b22911dfa81f12313a006823 >>>>>> Endpoint 2 produces this UUID: >>>>>> 0xbe11afc8b22911df86c412313a006823 >>>>>> >>>>>> The resulting concatenated Session Identifier would be: >>>> 0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823 >>>>>> This is no longer true and does not align with the new ABNF (i.e. >>>>>> the >>>>>> addition of the rcvr parameter). >>>> Charles - you are correct, and this needs to align with the ABNF >>>> which is how we are thinking of this solution moving forward. I know >>>> this was a case of so many changes that a few (hopefully) small >>>> inconsistencies were overlooked (that needed modification too). >>>> >>>>>> My other comment is in regard to: >>>>>> http://www.ietf.org/mail-archive/web/insipid/current/msg00402.html >>>>>> >>>>>> ISTM that a session id aware intermediary should insert a uuid >>>>>> when not >>>>>> present on behalf on either the endpoint. >>>> So, you want this session id aware intermediary to insert a uuid when >>>> which one is not present, the sender's or the receiver's? It matters >>>> a lot IMO. I can see uses for this insertion when the sender's is not >>>> present, but I believe it is bad for a session id aware intermediary >>>> to insert a receiver's before that receiver has had a chance to >>>> insert its own. Basically, I want to know which messages you see this >>>> insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever >>>> (after the dialog is established? >>> I believe was are in agreement. What I am suggesting is as follows: >>> Request from Alice through intermediary to Bob. >>> - Intermediary creates and inserts in request on behalf of Alice if >>> not there. >>> Response from Bob through intermediary to Alice. >>> - Intermediary creates and inserts in response on behalf of Bob if >>> not there > > what if there where multiple intermediaries between Alice and Bob... > which one gets to decide it inserts? Does it have to be the first SID > aware server? yep, the first who is Session Id aware ! but this is more a deployment question then a protocol one, I guess. /Salvatore > >> I concur things should be like described above by Charles >> >>> >>> The next question is what should the intermediary do if the uuid in >>> the request is not included in the response from Bob (i.e. it >>> contains Bob's uuid but is missing Alice's for some reason, > > this is actually something we looked at in Section 11 in the backwards > compatibility section when a version 0 UA talks to a version 1 UA and > the Session-ID changed places. No one is sure what the answer is yet. > >>> perhaps it was dropped by some other intermediary). > > well, that intermediary is broken and should be taken out of service ;-) > > James > >>> I do not see harm in the intermediary re-inserting Alice's uuid, so >>> I think it should add it back. >> that is a good question, I don't see any harm neither, but I need to >> to think more about it >> >> /Salvatore >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > From pkyzivat@alum.mit.edu Mon Nov 5 05:31:00 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 9464F21F85C1 for ; Mon, 5 Nov 2012 05:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtGSk9Enu8ED for ; Mon, 5 Nov 2012 05:31:00 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 2696521F86E8 for ; Mon, 5 Nov 2012 05:30:20 -0800 (PST) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Kowc1k0041smiN4ACpWKRz; Mon, 05 Nov 2012 13:30:19 +0000 Received: from dhcp-16c4.meeting.ietf.org ([IPv6:2001:df8:0:16:11e5:28e:3b1a:e2d1]) by omta20.emeryville.ca.mail.comcast.net with comcast id KpWK1k0023x7nqr8gpWKQR; Mon, 05 Nov 2012 13:30:19 +0000 Message-ID: <5097BFCA.6010902@alum.mit.edu> Date: Mon, 05 Nov 2012 08:31:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> <5096CAD5.1060809@ericsson.com> <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> In-Reply-To: <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 05 Nov 2012 13:31:00 -0000 On 11/5/12 12:22 AM, James Polk wrote: > what if there where multiple intermediaries between Alice and Bob... > which one gets to decide it inserts? Does it have to be the first SID > aware server? To do the insertion, the intermediary needs to be session-id aware, but it also must be dialog stateful, so that it can continue to insert the id in all the messages of the dialog(s). So this will need to be a B2BUA or a record-routing proxy. (It only needs to be transaction stateful if the insertion is into an out-of-dialog transaction that is not dialog establishing.) Thanks, Paul From jmpolk@cisco.com Mon Nov 5 07:28:00 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 D04CF21F874B for ; Mon, 5 Nov 2012 07:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.561 X-Spam-Level: X-Spam-Status: No, score=-110.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 Cvctjm0UVA2o for ; Mon, 5 Nov 2012 07:28:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 30FCA21F8746 for ; Mon, 5 Nov 2012 07:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1025; q=dns/txt; s=iport; t=1352129280; x=1353338880; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=1g1PST6f1qAJfpiLtp5p/zwJj4LyVYTgwtyXI2pThcE=; b=ewxB2HLHYRO2LasKU6A2j8BsA5R1jKlkI8RqE6ZjX3TTtpiTjE6WYGix n8K/XFk7gLJuk8thoGL8Y8+ILvPsmx/ZQZc3zPTenPnl8fCn+Xe0mWxdI VmRotdO58evG48TvT3xv3hUbHjCAVRBt4sj6ot2WV+/5IGbPNvBKmYyKv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOjZl1CtJV2b/2dsb2JhbABEDsMsgQiCHgEBAQMBAQEBDwElAjQQCwcEDgoeEBkOMAYBEiKHYgYLmm6fZgSMAYY8A4ham3qBa4IyXA X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="135912931" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2012 15:27:59 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn6-1803.cisco.com [10.82.255.18]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA5FRw76019125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 15:27:59 GMT Message-Id: <201211051527.qA5FRw76019125@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Nov 2012 09:27:58 -0600 To: Paul Kyzivat , From: James Polk In-Reply-To: <5097BFCA.6010902@alum.mit.edu> References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> <5096CAD5.1060809@ericsson.com> <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> <5097BFCA.6010902@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 05 Nov 2012 15:28:00 -0000 At 07:31 AM 11/5/2012, Paul Kyzivat wrote: >On 11/5/12 12:22 AM, James Polk wrote: > >>what if there where multiple intermediaries between Alice and Bob... >>which one gets to decide it inserts? Does it have to be the first SID >>aware server? > >To do the insertion, the intermediary needs to be session-id aware, >but it also must be dialog stateful, so that it can continue to >insert the id in all the messages of the dialog(s). So this will >need to be a B2BUA or a record-routing proxy. > >(It only needs to be transaction stateful if the insertion is into >an out-of-dialog transaction that is not dialog establishing.) it's the continuous reinsertion issue I was thinking of, and want the WG to be aware of. This point is in the slides for today. There is not text covering all of this in the draft yet. James > Thanks, > Paul >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From eckelcu@cisco.com Mon Nov 5 11:34:19 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 56D7E21F8AC4 for ; Mon, 5 Nov 2012 11:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0E5U9eeEUY5 for ; Mon, 5 Nov 2012 11:34:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EF22221F889F for ; Mon, 5 Nov 2012 11:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5057; q=dns/txt; s=iport; t=1352144058; x=1353353658; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ryna+J8rV/lWAwJvlJmN+CsHMO2TdWhzjyA/56uq1D4=; b=V7pNK7wpjtH+e1vRuiI0WqXB4FNoWkPpBf0oHhPVZDsrSWzEUdY3jMTp EKp6vrOd+e+8CHn0WwA2EWbPeNL1Wz2Cm4i2GHTb8UtF8j3A5RfNT7PHc XO7DW2HN84BeuM7xCjRAwm9o6Evr/PCX6YfmXLVTAWIo2RsbyzBvFxOVM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEQUmFCtJXG+/2dsb2JhbABEwzSBCIIeAQEBAwEBAQEPASc0EAcEAgEIEQQBAQEKFAkHJwsUCQgCBAESCAESB4diBguaeaAJjAEahUFhA6ExgyOBa4JvgWQXHg X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="scan'208";a="139044299" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2012 19:34:05 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA5JY545026531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 19:34:05 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 13:34:04 -0600 From: "Charles Eckel (eckelcu)" To: "James Polk (jmpolk)" , Salvatore Loreto , "insipid@ietf.org" Thread-Topic: [Insipid] comments on draft-jones-insipid-session-id-01 Thread-Index: AQHNulnwe0DS+iXAV0S82SQ+281SRZfaEabAgABuD4CAAJs9AIAAhy/g Date: Mon, 5 Nov 2012 19:34:03 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828107C24@xmb-aln-x08.cisco.com> References: <92B7E61ADAC1BB4F941F943788C088281047A2@xmb-aln-x08.cisco.com> <201211040659.qA46xURh007902@rcdn-core2-1.cisco.com> <92B7E61ADAC1BB4F941F943788C08828107269@xmb-aln-x08.cisco.com> <5096CAD5.1060809@ericsson.com> <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> In-Reply-To: <201211050522.qA55MMAS005068@rcdn-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.64.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--48.423600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 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, 05 Nov 2012 19:34:19 -0000 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of James Polk (jmpolk) > Sent: Monday, November 05, 2012 12:22 AM > To: Salvatore Loreto; insipid@ietf.org > Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 >=20 > At 02:06 PM 11/4/2012, Salvatore Loreto wrote: > >On 11/4/12 2:45 PM, Charles Eckel (eckelcu) wrote: > >>Hi James, please see inline. > >> > >>>-----Original Message----- > >>>From: James Polk (jmpolk) > >>>Sent: Sunday, November 04, 2012 1:59 AM > >>>To: Charles Eckel (eckelcu); insipid@ietf.org > >>>Subject: Re: [Insipid] comments on draft-jones-insipid-session-id-01 > >>> > >>>At 09:05 PM 11/3/2012, Charles Eckel (eckelcu) wrote: > >>>>Oops - resending with complete subject this time > >>>> > >>>>>-----Original Message----- > >>>>>From: Charles Eckel (eckelcu) > >>>>>Sent: Saturday, November 03, 2012 8:44 PM > >>>>>To: insipid@ietf.org > >>>>>Subject: comments on > >>>>> > >>>>> I read the draft and think this version is a good step forward. > >>>>Paul K. and > >>>>>Salvatore already raised most of the comments I had in mind, but I > have > >>>the > >>>>>following which may still be of some value. > >>>>> > >>>>>Section 4 reads as follows: > >>>>> > >>>>> Consider the following example. > >>>>> > >>>>> Endpoint 1 produces this UUID: > 0xaeffa652b22911dfa81f12313a006823 > >>>>> Endpoint 2 produces this UUID: > 0xbe11afc8b22911df86c412313a006823 > >>>>> > >>>>> The resulting concatenated Session Identifier would be: > >>>0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a00682 > 3 > >>>>>This is no longer true and does not align with the new ABNF (i.e. th= e > >>>>>addition of the rcvr parameter). > >>>Charles - you are correct, and this needs to align with the ABNF > >>>which is how we are thinking of this solution moving forward. I know > >>>this was a case of so many changes that a few (hopefully) small > >>>inconsistencies were overlooked (that needed modification too). > >>> > >>>>>My other comment is in regard to: > >>>>>http://www.ietf.org/mail- > archive/web/insipid/current/msg00402.html > >>>>> > >>>>>ISTM that a session id aware intermediary should insert a uuid when > not > >>>>>present on behalf on either the endpoint. > >>>So, you want this session id aware intermediary to insert a uuid when > >>>which one is not present, the sender's or the receiver's? It matters > >>>a lot IMO. I can see uses for this insertion when the sender's is not > >>>present, but I believe it is bad for a session id aware intermediary > >>>to insert a receiver's before that receiver has had a chance to > >>>insert its own. Basically, I want to know which messages you see this > >>>insertion, the INVITE, the 200 OK, the reINVITE/UPDATE/whatever > >>>(after the dialog is established? > >>I believe was are in agreement. What I am suggesting is as follows: > >>Request from Alice through intermediary to Bob. > >>- Intermediary creates and inserts in request on behalf of Alice if > >>not there. > >>Response from Bob through intermediary to Alice. > >>- Intermediary creates and inserts in response on behalf of Bob if not > there >=20 > what if there where multiple intermediaries between Alice and Bob... > which one gets to decide it inserts? Does it have to be the first SID > aware server? Yes, the first SID aware intermediary would insert it. Any intermediaries l= ater in the path will see this uuid and therefore NOT need to insert one. =20 > >I concur things should be like described above by Charles > > > >> > >>The next question is what should the intermediary do if the uuid in > >>the request is not included in the response from Bob (i.e. it > >>contains Bob's uuid but is missing Alice's for some reason, >=20 > this is actually something we looked at in Section 11 in the > backwards compatibility section when a version 0 UA talks to a > version 1 UA and the Session-ID changed places. No one is sure what > the answer is yet. >=20 > >>perhaps it was dropped by some other intermediary). >=20 > well, that intermediary is broken and should be taken out of service ;-) Yes, but that is not an option for the properly functioning intermediary en= countering this situation. Forced removal of one intermediary by another is covered in another draft := ) Cheers, Charles =20 > James >=20 > >>I do not see harm in the intermediary re-inserting Alice's uuid, so > >>I think it should add it back. > >that is a good question, I don't see any harm neither, but I need to > >to think more about it > > > >/Salvatore > > > >-- > >Salvatore Loreto, PhD > >www.sloreto.com > > > >_______________________________________________ > >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 D.Malas@cablelabs.com Mon Nov 5 12:48:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC1B21F8643 for ; Mon, 5 Nov 2012 12:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.053 X-Spam-Level: X-Spam-Status: No, score=-100.053 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjbXHFnThift for ; Mon, 5 Nov 2012 12:48:48 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id F03ED21F86B3 for ; Mon, 5 Nov 2012 12:48:47 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id qA5KmkEh003476 for ; Mon, 5 Nov 2012 13:48:46 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 05 Nov 2012 13:48:46 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0298.004; Mon, 5 Nov 2012 13:48:47 -0700 From: Daryl Malas To: "insipid@ietf.org" Thread-Topic: [Insipid] Terminology in draft-ietf-insipid-session-id-reqts-02 Thread-Index: AQHNu5bzGg/7wKOrbkuJFmWYxwoqfg== Date: Mon, 5 Nov 2012 20:48:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CCBD906227BBdmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [Insipid] Terminology in draft-ietf-insipid-session-id-reqts-02 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, 05 Nov 2012 20:48:49 -0000 --_000_CCBD906227BBdmalascablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There was some discussion on the terms in the requirements draft during tod= ay's working group session. As a point of reference, some of these terms w= ere defined in RFC 6076: End-to-End - This is described as two or more elements utilized for initiating a request, receiving the request, and responding to the request. It encompasses elements as necessary to be involved in a session dialog between the originating user agent client (UAC), destination user agent server (UAS), and any interim proxies (may also include back-to-back user agents (B2BUAs)). This may be relative to a single operator's set of elements or may extend to encompass all elements (if beyond a single operator's network) associated with a session. Session - As described in RFC 3261 [RFC3261], SIP is used primarily to request, create, and conclude sessions. "These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences". The metrics within this document measure the performance associated with the SIP dialogs necessary to establish these sessions; therefore, they are titled as Session Request Delay, Session Disconnect Delay, etc. Although the titles of many of the metrics include this term, they are specifically measuring the signaling aspects only. Each session is identified by a unique "Call-ID", "To", and "From" header field tag. Obviously, terms can be unique to drafts, perhaps these definitions can hel= p shape the definitions in the requirements draft, or they could simply be = referenced. In either case, sharing them in the spirit of helping to creat= e better definitions in this requirements draft. Regards, Daryl --_000_CCBD906227BBdmalascablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8FB867BAFDE860498B5BC92D56D3E171@cablelabs.com> Content-Transfer-Encoding: quoted-printable
There was some discussion on the terms in the requirements draft during tod= ay's working group session.  As a point of reference, some of these te= rms were defined in RFC 6076:

End-to-End - This is described as tw= o or more elements utilized for
   initiating a request, r= eceiving the request, and responding to the
   request.  It encom= passes elements as necessary to be involved in a
   session dialog between = the originating user agent client (UAC),
   destination user agent = server (UAS), and any interim proxies (may
   also include back-to-ba= ck user agents (B2BUAs)).  This may be
   relative to a single op= erator's set of elements or may extend to
   encompass all elements = (if beyond a single operator's network)
   associated with a sessi= on.

   Session - As described = in RFC 3261 [RFC3261], SIP is used primarily
   to request, create, and= conclude sessions.  "These sessions include
   Internet telephone call= s, multimedia distribution, and multimedia
   conferences". &nbs= p;The metrics within this document measure the
   performance associated = with the SIP dialogs necessary to establish
   these sessions; therefo= re, they are titled as Session Request Delay,
   Session Disconnect Dela= y, etc.  Although the titles of many of the
   metrics include this te= rm, they are specifically measuring the
   signaling aspects only.=  Each session is identified by a unique
   "Call-ID", &q= uot;To", and "From" header field tag.

Obviously, terms can be unique to dr= afts, perhaps these definitions can help shape the definitions in the requi= rements draft, or they could simply be referenced.  In either cas= e, sharing them in the spirit of helping to create better definitions in this requirements draft.

Regards,

Daryl
--_000_CCBD906227BBdmalascablelabscom_-- From pkyzivat@alum.mit.edu Mon Nov 5 19:25:32 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 209CF11E80E6 for ; Mon, 5 Nov 2012 19:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLZhSZfqrK48 for ; Mon, 5 Nov 2012 19:25:31 -0800 (PST) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB3711E80D3 for ; Mon, 5 Nov 2012 19:25:31 -0800 (PST) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta07.emeryville.ca.mail.comcast.net with comcast id L0cv1k0041eYJf8A73RW4G; Tue, 06 Nov 2012 03:25:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([216.138.103.10]) by omta19.emeryville.ca.mail.comcast.net with comcast id L3PF1k0080DU8JY013PHmY; Tue, 06 Nov 2012 03:23:27 +0000 Message-ID: <50988304.1010703@alum.mit.edu> Date: Mon, 05 Nov 2012 22:24:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: James Polk References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> <508C1C47.9080006@alum.mit.edu> <093901cdb48c$f3b21d90$db1658b0$@packetizer.com> <201211050447.qA54l74f031160@rcdn-core2-1.cisco.com> In-Reply-To: <201211050447.qA54l74f031160@rcdn-core2-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Paul E. Jones" , insipid@ietf.org Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 06 Nov 2012 03:25:32 -0000 On 11/4/12 11:35 PM, James Polk wrote: > are we really going to remove all mention of interworking between > dissimilar call signaling protocols? Can we not at least have a > non-normative comment or discussion about it. It is something that may > not be obvious to someone else who just reads this one document. There was agreement to replace the RTCP reference in the requirements with something restricting the syntax & length of the ID so that it would also be suitable for use in other protocols. Some words about interworking can go there. And then in the protocol document, perhaps in text describing the ABNF syntax, some similar words could appear. Thanks, Paul From paulej@packetizer.com Mon Nov 5 19:32: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 B656E11E80D3 for ; Mon, 5 Nov 2012 19:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, 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 Tn+gWhpBxyGO for ; Mon, 5 Nov 2012 19:32:37 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E664F21F84FC for ; Mon, 5 Nov 2012 19:32:36 -0800 (PST) Received: from [130.129.68.150] (dhcp-4496.meeting.ietf.org [130.129.68.150]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qA63WXBF023747 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 22:32:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1352172754; bh=OEEORIeH15tlOPuCxtQQW3UuUr3vF6AlK4j5Sf+q/+g=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qzWX0TLyyikKd0bD0K7ZaofIMGZHcDSYnX+LlZICDQ3KJtNUzPaLeACSvwTInWO+P FXGkQvJ9NuKNqAqFj8yAm8AGCxnhlshUe8z6GmA347ixmF4HBle8Htzb0WCMnNyP01 HILyXi5om41K+MloaWRpOs2HBSFMqIhloZG/rTPk= Message-ID: <509884D1.7010400@packetizer.com> Date: Mon, 05 Nov 2012 22:32:33 -0500 From: "Paul E. Jones" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> <508C1C47.9080006@alum.mit.edu> <093901cdb48c$f3b21d90$db1658b0$@packetizer.com> <201211050447.qA54l74f031160@rcdn-core2-1.cisco.com> <50988304.1010703@alum.mit.edu> In-Reply-To: <50988304.1010703@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Polk , insipid@ietf.org Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 06 Nov 2012 03:32:37 -0000 Paul, The wording on the suitability for RTCP is some text Ganzalo said he would work with me on in the requirements document. The interworking text (between v0 and v1 endpoints) is entirely different and in the solution document. Am I missing something? Paul On 11/5/2012 10:24 PM, Paul Kyzivat wrote: > On 11/4/12 11:35 PM, James Polk wrote: > >> are we really going to remove all mention of interworking between >> dissimilar call signaling protocols? Can we not at least have a >> non-normative comment or discussion about it. It is something that may >> not be obvious to someone else who just reads this one document. > > There was agreement to replace the RTCP reference in the requirements > with something restricting the syntax & length of the ID so that it > would also be suitable for use in other protocols. Some words about > interworking can go there. > > And then in the protocol document, perhaps in text describing the ABNF > syntax, some similar words could appear. > > Thanks, > Paul > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From btv1==66138ec36ca==HKaplan@acmepacket.com Fri Nov 9 16:19: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 0EF7621F853D for ; Fri, 9 Nov 2012 16:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 niHKwMqYr2ct for ; Fri, 9 Nov 2012 16:19:04 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB2321F853C for ; Fri, 9 Nov 2012 16:19:04 -0800 (PST) X-ASG-Debug-ID: 1352506742-03fc202f755ad30001-Waf2p9 Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id pBCaeZ9bVADDqpa1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Fri, 09 Nov 2012 19:19:02 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Fri, 9 Nov 2012 19:19:02 -0500 From: Hadriel Kaplan To: James Polk Thread-Topic: [Insipid] Changes to the -01 of draft-jones-insipid-session-id X-ASG-Orig-Subj: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id Thread-Index: AQHNvtj8PWJ8wHCvFEuP08PVo2uWwQ== Date: Sat, 10 Nov 2012 00:19:01 +0000 Message-ID: References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> <201211050447.qA54l74b031160@rcdn-core2-1.cisco.com> In-Reply-To: <201211050447.qA54l74b031160@rcdn-core2-1.cisco.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352506742 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113773 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "Paul E. Jones" , "" , Paul Kyzivat Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 10 Nov 2012 00:25:07 -0000 On Nov 4, 2012, at 11:20 PM, James Polk wrote: >> > Section 6: >> > >> > ... Session-ID header-values MUST NOT be present in any other >> > SIP header than the Session-ID header. >> > >> > Why is it important to mandate this? >=20 > I just don't like this header-value showing up anywhere else that someone= might not be looking for it and then wonder why things didn't work as plan= ned. Similar constraint on Geolocation header-values. But we already know we might want it in another header, or at least a body:= for SIPREC, for example, it might be put into a header or the XML metadata= . (probably the latter, but it's not a big difference) Also there's been some discussion of putting it in the Refer-To or Target h= eader, though probably as an embedded Session-ID header inside the URI, so = I guess we might weasel our way around any restriction against putting it i= n another header since we're keeping it in a Session-ID header but sticking= that whole header into a URI somewhere else. -hadriel From christer.holmberg@ericsson.com Mon Nov 12 04:10: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 7673821F843F for ; Mon, 12 Nov 2012 04:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2aY21XaGA82 for ; Mon, 12 Nov 2012 04:10:20 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8788A21F843E for ; Mon, 12 Nov 2012 04:10:16 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-c9-50a0e7274f48 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 40.4D.06323.727E0A05; Mon, 12 Nov 2012 13:10:15 +0100 (CET) Received: from ESESSHC016.ericsson.se (153.88.183.66) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 12 Nov 2012 13:10:15 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 13:10:14 +0100 From: Christer Holmberg To: Hadriel Kaplan , James Polk Thread-Topic: [Insipid] Changes to the -01 of draft-jones-insipid-session-id Thread-Index: AQHNsxM53fhr6YLaUUCaKRcFSfpOMJfL/NkAgAAR0oCADpRLgIAHmBeAgAP7Nbc= Date: Mon, 12 Nov 2012 12:10:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B02AA61@ESESSMB209.ericsson.se> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508B02E0.3090500@alum.mit.edu> <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> <201211050447.qA54l74b031160@rcdn-core2-1.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rlf9+YIAg80nBCzmXn7ObjH//jMm ix1rCi3OX9jAZLFiwwFWB1aPTZM3s3n8ff+ByWPK742sHkuW/GTyaNh3lD2ANYrLJiU1J7Ms tUjfLoErY+3BH4wF7/krbq06ydLA+Jyni5GTQ0LARGLaqslMELaYxIV769m6GLk4hAROMkp8 vH6CESQhJLCTUaLxggVEYgmjxIYVW1i7GDk42AQsJLr/aYPUiAh4STReOgw2iFmgRmLee4ih wgLeEivOHgArFxHwkVizNQyi3E/i+IwmZhCbRUBVYmtDMzuIzQtUvuDEBxaIVW+YJC4u38cK kuAUcJK4OfEsWAMj0KHfT62B2iUucevJfKgHBCSW7DnPDGGLSrx8/I8VwlaU+PhqHyNEvY7E gt2f2CBsbYllC18zQywWlDg58wkLxL/aEi2LJ7BPYJSYhWTFLCTts5C0z0LSvoCRZRUje25i Zk56ufkmRmA0Htzy22AH46b7YocYpTlYlMR59VT3+wsJpCeWpGanphakFsUXleakFh9iZOLg lGpgTFNkrHlXttqtQ+WIqnX7MheJGHWlKwIOMRmfZDyP/6m+GznfoeampMabpC2hR5Lfn/Hw /dqzVEMisWKlqVSykopcB4Oz0P1p5+RK5uYaX2MpS5wp8GHvdj4nhVX79Rdcmlj73nHhieVT 2+MOeUoaTuj3U46cc1l+jvA8WcMdlxSv/Amb/VBPiaU4I9FQi7moOBEAQhBlE5QCAAA= Cc: "Paul E. Jones" , "" , Paul Kyzivat Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id 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, 12 Nov 2012 12:10:25 -0000 Hi, I agree with Hadriel. In addition, each header field specification defines what values it can inc= lude. So, my suggestion is to remove the text. IF we are going to allow the value in Refer-To/Target, even only as an embe= dded Session-ID header field inside a URI, you could write something like: "This document also describes how the Session-ID header field can be embedd= ed inside a URI or a Refer-To and Target header field." Regards, Christer ________________________________________ From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] on behalf of Hadr= iel Kaplan [HKaplan@acmepacket.com] Sent: Saturday, 10 November 2012 2:19 AM To: James Polk Cc: Paul E. Jones; ; Paul Kyzivat Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid-session-id On Nov 4, 2012, at 11:20 PM, James Polk wrote: >> > Section 6: >> > >> > ... Session-ID header-values MUST NOT be present in any other >> > SIP header than the Session-ID header. >> > >> > Why is it important to mandate this? > > I just don't like this header-value showing up anywhere else that someone= might not be looking for it and then wonder why things didn't work as plan= ned. Similar constraint on Geolocation header-values. But we already know we might want it in another header, or at least a body:= for SIPREC, for example, it might be put into a header or the XML metadata= . (probably the latter, but it's not a big difference) Also there's been some discussion of putting it in the Refer-To or Target h= eader, though probably as an embedded Session-ID header inside the URI, so = I guess we might weasel our way around any restriction against putting it i= n another header since we're keeping it in a Session-ID header but sticking= that whole header into a URI somewhere else. -hadriel _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From brett@broadsoft.com Tue Nov 13 12: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 4BFAD21F8645 for ; Tue, 13 Nov 2012 12:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[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 8FmXiMvXL6r3 for ; Tue, 13 Nov 2012 12:19:13 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6821F8644 for ; Tue, 13 Nov 2012 12:19:13 -0800 (PST) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 13 Nov 2012 12:19:41 -0800 Received: from MBX06.citservers.local ([fe80::bc79:c816:92ac:db09]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Tue, 13 Nov 2012 12:19:40 -0800 From: Brett Tate To: "insipid@ietf.org" Thread-Topic: Session-ID when B2BUA forks INVITE for audio and video to different locations Thread-Index: Ac3B3CSHJ+fLsWmpT/q0ZUY7wtw0AA== Date: Tue, 13 Nov 2012 20:19:40 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations 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, 13 Nov 2012 20:19:14 -0000 Hi, What Session-ID should be communicated when a B2BUA forks a video call so I= NVITE for audio and INVITE for video go to different locations? For instan= ce, the INVITE for video is sent the computer and INVITE for audio is sent = to the phone. The concept is mentioned within draft-ietf-straw-b2bua-taxonomy-00 section = 3.1.3. The following uses draft-jones-insipid-session-id-01 to indicate Session-ID= . Hopefully the picture doesn't get too corrupted. Session-ID ---- Alice B2BUA Bob-phone Bob-computer {A} |---INVITE--->| | | {A} | |---INVITE-->| | {A} | |---INVITE------------->| {Bp,A} | |<--200 OK---| | {Bc,A} | |<--200 OK--------------| {Bp,A} |<--200 OK----| | | {A,Bp} |-----ACK---->| | | {A,Bp} | |---ACK----->| | {A,Bc} | |---ACK---------------->| Is this the expected use of draft-jones-insipid-session-id-01? Note: Bc do= es not get communicated to Alice and the B2BUA adjusts the Session-ID befor= e sending ACK to Bob-computer. There is a similar call flow when Bob-phone originates a call to Alice. Bo= b-computer is pulled into the call setup so both audio and video can be off= ered to Alice. However, I will ask about that one later. Thanks, Brett This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, or by sendin= g an email to helpdesk@broadsoft.com, and destroy all copies of this messag= e, along with any attachment, prior to reading, distributing or copying it. From pkyzivat@alum.mit.edu Tue Nov 13 13:14:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4A421F86E1 for ; Tue, 13 Nov 2012 13:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqQa4FgNjLur for ; Tue, 13 Nov 2012 13:14:48 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id DF16221F86CC for ; Tue, 13 Nov 2012 13:14:47 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta15.westchester.pa.mail.comcast.net with comcast id P5Ms1k0030bG4ec5F9EnET; Tue, 13 Nov 2012 21:14:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id P9En1k0083ZTu2S3P9EnUQ; Tue, 13 Nov 2012 21:14:47 +0000 Message-ID: <50A2B846.2030200@alum.mit.edu> Date: Tue, 13 Nov 2012 16:14:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations 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, 13 Nov 2012 21:14:48 -0000 On 11/13/12 3:19 PM, Brett Tate wrote: > Hi, > > What Session-ID should be communicated when a B2BUA forks a video call so INVITE for audio and INVITE for video go to different locations? For instance, the INVITE for video is sent the computer and INVITE for audio is sent to the phone. > > The concept is mentioned within draft-ietf-straw-b2bua-taxonomy-00 section 3.1.3. > > The following uses draft-jones-insipid-session-id-01 to indicate Session-ID. Hopefully the picture doesn't get too corrupted. > > Session-ID > ---- Alice B2BUA Bob-phone Bob-computer > {A} |---INVITE--->| | | > {A} | |---INVITE-->| | > {A} | |---INVITE------------->| > {Bp,A} | |<--200 OK---| | > {Bc,A} | |<--200 OK--------------| > {Bp,A} |<--200 OK----| | | > {A,Bp} |-----ACK---->| | | > {A,Bp} | |---ACK----->| | > {A,Bc} | |---ACK---------------->| > > Is this the expected use of draft-jones-insipid-session-id-01? Note: Bc does not get communicated to Alice and the B2BUA adjusts the Session-ID before sending ACK to Bob-computer. > > There is a similar call flow when Bob-phone originates a call to Alice. Bob-computer is pulled into the call setup so both audio and video can be offered to Alice. However, I will ask about that one later. IMO there is a philosophical decision here that the B2BUA must make. As you have shown it, the B2BUA is acting as an *intermediary*, and is treating the phone as the callee. The computer is a secondary issue. Another way to view it is that the B2BUA is the device Alice talks to, and that both the phone and computer are just incidental peripherals. In that case the B2BUA might assign an ID itself. This might be better if the devices used might change - e.g. the phone dropped out while the call continues. This also might make sense if the sessions between the B2BUA and the phone/computer are long lived rather than being formed when the incoming call from Alice arrives. So there may be no single answer to this. But that does beg the question of which choices are valid ways to assign the IDs, and which ways are not. Thanks, Paul From eckelcu@cisco.com Wed Nov 14 11:59: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 7D3AA21F8660 for ; Wed, 14 Nov 2012 11:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu6GhRdFuXey for ; Wed, 14 Nov 2012 11:59:02 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5379221F8602 for ; Wed, 14 Nov 2012 11:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9880; q=dns/txt; s=iport; t=1352923142; x=1354132742; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=3n1omIOJ+XknL4O4ROcYdh9RcTxLpoCxx1lujeXek9E=; b=ZO/e7m2kwmfHwnbO73bbeCuIKAMWJfhT21fBwGwy/w2lqhpmZxihOR2R 14mIlW4sUgyolNBEPmfYQo75L3cKsufIJf8HTobQCNz71eM50s24kSt22 iIrf7MaMseG2zHdsM25QMFl8EDFXy1Mekjxen8ii4/JlyxbEWRzQQHnsc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOD2o1CtJXG//2dsb2JhbABEDoI7wHOBCIIeAQEBAwEBAQEPARQGQRAHBAIBCA4DBAEBAQodBycLFAkIAQEEARIIGodiBQELmyGgEwSMLYVLYQOkVIFrgjI9ghk X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142428626" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2012 19:59:01 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAEJx17X004237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Nov 2012 19:59:01 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.25]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 13:59:01 -0600 From: "Charles Eckel (eckelcu)" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations Thread-Index: Ac3B3CSHJ+fLsWmpT/q0ZUY7wtw0AAAOg40AACLGDFA= Date: Wed, 14 Nov 2012 19:59:00 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882812BD0A@xmb-aln-x08.cisco.com> References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> <50A2B846.2030200@alum.mit.edu> In-Reply-To: <50A2B846.2030200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19364.000 x-tm-as-result: No--23.967800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_92B7E61ADAC1BB4F941F943788C0882812BD0Axmbalnx08ciscocom_" MIME-Version: 1.0 Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations 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, 14 Nov 2012 19:59:03 -0000 --_000_92B7E61ADAC1BB4F941F943788C0882812BD0Axmbalnx08ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Tuesday, November 13, 2012 1:15 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and > video to different locations > > On 11/13/12 3:19 PM, Brett Tate wrote: > > Hi, > > > > What Session-ID should be communicated when a B2BUA forks a video call > so INVITE for audio and INVITE for video go to different locations? For > instance, the INVITE for video is sent the computer and INVITE for audio = is > sent to the phone. > > > > The concept is mentioned within draft-ietf-straw-b2bua-taxonomy-00 > section 3.1.3. > > > > The following uses draft-jones-insipid-session-id-01 to indicate Sessio= n- > ID. Hopefully the picture doesn't get too corrupted. > > > > Session-ID > > ---- Alice B2BUA Bob-phone Bob-computer > > {A} |---INVITE--->| | | > > {A} | |---INVITE-->| | > > {A} | |---INVITE------------->| > > {Bp,A} | |<--200 OK---| | > > {Bc,A} | |<--200 OK--------------| > > {Bp,A} |<--200 OK----| | | I would expect this session ID to be {B,A}, where the B2BUA creates its own= uuid (B) and manages the mapping to Bp and Bc. > > {A,Bp} |-----ACK---->| | | > > {A,Bp} | |---ACK----->| | > > {A,Bc} | |---ACK---------------->| > > > > Is this the expected use of draft-jones-insipid-session-id-01? Note: B= c > does not get communicated to Alice and the B2BUA adjusts the Session-ID > before sending ACK to Bob-computer. > > > > There is a similar call flow when Bob-phone originates a call to Alice.= Bob- > computer is pulled into the call setup so both audio and video can be > offered to Alice. However, I will ask about that one later. > > IMO there is a philosophical decision here that the B2BUA must make. > > As you have shown it, the B2BUA is acting as an *intermediary*, and is > treating the phone as the callee. The computer is a secondary issue. > > Another way to view it is that the B2BUA is the device Alice talks to, > and that both the phone and computer are just incidental peripherals. In > that case the B2BUA might assign an ID itself. This might be better if > the devices used might change - e.g. the phone dropped out while the > call continues. This also might make sense if the sessions between the > B2BUA and the phone/computer are long lived rather than being formed > when the incoming call from Alice arrives. My comment above aligns with this option. I agree, it is not the only optio= n. Cheers, Charles > So there may be no single answer to this. But that does beg the question > of which choices are valid ways to assign the IDs, and which ways are not= . > > Thanks, > Paul > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --_000_92B7E61ADAC1BB4F941F943788C0882812BD0Axmbalnx08ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
> -----Original Message-----
> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Tuesday, November 13, 2012 1:15 PM
> To: insipid@ietf.org
> Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for aud= io and
> video to different locations
>
> On 11/13/12 3:19 PM, Brett Tate wrote:
> > Hi,
> >
> > What Session-ID should be communicated when a B2BUA forks a = video call
> so INVITE for audio and INVITE for video go to different location= s?  For
> instance, the INVITE for video is sent the computer and INVITE fo= r audio is
> sent to the phone.
> >
> > The concept is mentioned within draft-ietf-straw-b2bua-taxon= omy-00
> section 3.1.3.
> >
> > The following uses draft-jones-insipid-session-id-01 to indi= cate Session-
> ID.  Hopefully the picture doesn't get too corrupted.
> >
> > Session-ID
> > ----  Alice        B= 2BUA     Bob-phone Bob-computer
> >    {A}   |---INVITE--->| &n= bsp;          |  &nb= sp;       |
> >    {A}   |    &= nbsp;        |---INVITE-->| &nbs= p;        |
> >    {A}   |    &= nbsp;        |---INVITE------------->= |
> >   {Bp,A} |      &nbs= p;      |<--200 OK---|    &= nbsp;     |
> >   {Bc,A} |      &nbs= p;      |<--200 OK--------------|
> >   {Bp,A} |<--200 OK----|    = ;        |     =      |
 
 
I would expect this session ID to be {B,A}, where the B2BUA creates it= s own uuid (B) and manages the mapping to Bp and Bc.
 
 
> >   {A,Bp} |-----ACK---->|    = ;        |     =      |
> >   {A,Bp} |      &nbs= p;      |---ACK----->|    &= nbsp;     |
> >   {A,Bc} |      &nbs= p;      |---ACK---------------->|
> >
> > Is this the expected use of draft-jones-insipid-session-id-0= 1?  Note: Bc
> does not get communicated to Alice and the B2BUA adjusts the Sess= ion-ID
> before sending ACK to Bob-computer.
> >
> > There is a similar call flow when Bob-phone originates a cal= l to Alice.  Bob-
> computer is pulled into the call setup so both audio and video ca= n be
> offered to Alice.  However, I will ask about that one later.=
>
> IMO there is a philosophical decision here that the B2BUA must ma= ke.
>
> As you have shown it, the B2BUA is acting as an *intermediary*, a= nd is
> treating the phone as the callee. The computer is a secondary iss= ue.
>
> Another way to view it is that the B2BUA is the device Alice talk= s to,
> and that both the phone and computer are just incidental peripher= als. In
> that case the B2BUA might assign an ID itself. This might be bett= er if
> the devices used might change - e.g. the phone dropped out while = the
> call continues. This also might make sense if the sessions betwee= n the
> B2BUA and the phone/computer are long lived rather than being for= med
> when the incoming call from Alice arrives.
 
My comment above aligns with this option. I agree, it is not the only = option.
 
Cheers,
Charles
 
 
> So there may be no single answer to this. But that does beg the q= uestion
> of which choices are valid ways to assign the IDs, and which ways= are not.
>
>        Thanks,
>        Paul
>
> _______________________________________________
> insipid mailing list
 
 --_000_92B7E61ADAC1BB4F941F943788C0882812BD0Axmbalnx08ciscocom_-- From paulej@packetizer.com Tue Nov 20 22:13: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 4A00621F86B9 for ; Tue, 20 Nov 2012 22:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 NOIAGsB6eTm1 for ; Tue, 20 Nov 2012 22:13:10 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6E121F8696 for ; Tue, 20 Nov 2012 22:13:10 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qAL6D5wu000437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Nov 2012 01:13:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353478386; bh=nWJYmeAwTA0zaWKfmtFknHxt9Kui/QRzmB1NsHErf1w=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Q2segG+xM2netj2imPjnuywIxjy1PplIXWPQ+T1aXQdNzAzc1Ip10pntu2YExfTjF 2qfH/pYOFQWssNdtznPbmtBPK2hNBgQi1JJ/LeYqjTsIHpDb8oZtS2saR4B/r/Wh78 GjaGuIit62cAMGrHZ0R0+ZHkTw7dVcNBxxlPKyDw= From: "Paul E. Jones" To: "'Brett Tate'" , References: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B880239BA@MBX06.citservers.local> Date: Wed, 21 Nov 2012 01:13:14 -0500 Message-ID: <002101cdc7af$4a892ac0$df9b8040$@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: AQL9S5dCuxNx07jAyDHHgQPV6OoCpZWUxBvw Content-Language: en-us Subject: Re: [Insipid] Session-ID when B2BUA forks INVITE for audio and video to different locations 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, 21 Nov 2012 06:13:11 -0000 Brett, Well, this is certainly different. Does the phone ring? Does the computer ring? Does the user independently answer each one of those devices? And what would happen if the PC has only audio? I assume only the B2BUA knows the capabilities of devices in advance? Basically, what we have on the right-hand side of the B2BUA is two completely independent SIP sessions that are more-or-less "conferenced" via the B2BUA. The media might be going directly to the endpoints, but it is still very much like a conference server where there is Alice, Bob, and Carol all in a conference. So, given that, I would expect to see these three Session-IDs: {A,F} - Session ID between Alice and the B2BUA (F) {F,Bp} - Session ID between the B2BUA and Bob's phone {F,Bc} - Session ID between the B2BUA and Bob's computer This means there are three unique identifiers, but there still exists the possibility to correlate the calls since F is in common across all sessions. There are limits to the utility of having F in all sessions. For example, A is not present anywhere on the right-hand side. If A happened to be an MCU that had 100 calls in conference, it might be possible to relate all the sessions on the left side of the B2BUA, but the diagnostic / monitoring equipment looking at the right side would never see A. Thus, it's not perfect. Even so, I think that approach would provide a "better than nothing" solution. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Brett Tate > Sent: Tuesday, November 13, 2012 3:20 PM > To: insipid@ietf.org > Subject: [Insipid] Session-ID when B2BUA forks INVITE for audio and > video to different locations > > Hi, > > What Session-ID should be communicated when a B2BUA forks a video call > so INVITE for audio and INVITE for video go to different locations? For > instance, the INVITE for video is sent the computer and INVITE for audio > is sent to the phone. > > The concept is mentioned within draft-ietf-straw-b2bua-taxonomy-00 > section 3.1.3. > > The following uses draft-jones-insipid-session-id-01 to indicate > Session-ID. Hopefully the picture doesn't get too corrupted. > > Session-ID > ---- Alice B2BUA Bob-phone Bob-computer > {A} |---INVITE--->| | | > {A} | |---INVITE-->| | > {A} | |---INVITE------------->| > {Bp,A} | |<--200 OK---| | > {Bc,A} | |<--200 OK--------------| > {Bp,A} |<--200 OK----| | | > {A,Bp} |-----ACK---->| | | > {A,Bp} | |---ACK----->| | > {A,Bc} | |---ACK---------------->| > > Is this the expected use of draft-jones-insipid-session-id-01? Note: Bc > does not get communicated to Alice and the B2BUA adjusts the Session-ID > before sending ACK to Bob-computer. > > There is a similar call flow when Bob-phone originates a call to Alice. > Bob-computer is pulled into the call setup so both audio and video can > be offered to Alice. However, I will ask about that one later. > > Thanks, > Brett > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, > or by sending an email to helpdesk@broadsoft.com, and destroy all copies > of this message, along with any attachment, prior to reading, > distributing or copying it. > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Nov 20 22:48:32 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 6B81921F8856 for ; Tue, 20 Nov 2012 22:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSAx-BtpsHWH for ; Tue, 20 Nov 2012 22:48:30 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E468921F884A for ; Tue, 20 Nov 2012 22:48:29 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qAL6mRZx001912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Nov 2012 01:48:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353480508; bh=dfv01Auw+0U8MLWGRswCWoCmkccysbHlG67fmBhHV7Q=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=NajEocKQ839+RUCSwly5dG7XHeoOLzOSaUpvQi04empCYhBCDtpr6Y3uLkCSQTMYQ SvTPVCaMZz/yOvoYDedHg8P7xSBRWD9ZnTVU5SKR2wZmEBP4nNvA1avhDu6T9h02Ad +TjlmpQ3CynTIwwk2I58PHpgI00cSSR0sc4TL24k= From: "Paul E. Jones" To: Date: Wed, 21 Nov 2012 01:48:36 -0500 Message-ID: <002601cdc7b4$3b494270$b1dbc750$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01CDC78A.527424D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3HsSorT1HX9tYVQyqDerYvSCdnSA== Content-Language: en-us Cc: "'Charles Eckel \(eckelcu\)'" Subject: [Insipid] Communication Session 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, 21 Nov 2012 06:48:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0027_01CDC78A.527424D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I said I will publish a new revision of the requirements document. I have a list of things on my list, but I may have neglected a few items. If you can think of an important change you wanted made to the requirements draft, let me know. One thing that was discussed and for which I don't have an answer is that of "communication session" vs. something else. The requirements document currently says: In this document, the word "session" refers to a "communication session" that may exist between two SIP user agents or that might pass through one or more intermediary devices, including B2BUAs or SIP Proxies. The term "end-to-end" in this document means the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It is recognized that legacy devices may not support the "end-to-end" session identifier, though an identifier might be created by an intermediary when it is absent from the session signaling. There was a desire for changes in terminology. Specifically what, though? Please look at the terminology in the current draft and let's discuss what changes to make: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02 I'm not so confident that we'll have a quick answer, so what I might do is go ahead and publish an -03 with what other changes I believe folks wanted (and any I get between now and tomorrow evening). Don't take that publication as ignoring this point. We can work on revising the terminology even after the next version. Charles Eckel proposed (on Nov. 3) to replace the words "communication session" with "SIP message exchange". Paul Kyzivat seemed to think that might work, but I didn't see others comment. Looking at the proposal, I'm having trouble seeing how I'd use the term in these sentences: . "The identifier is intended to represents an end-to-end communication session from the originating device to the terminating device" . "if a PBX joins or merges two communication sessions together locally, the end-to-end properties of currently-defined identifiers are lost" . "we need the ability to identify each communication session through a single SIP header-value regardless of which type of SIP servers" . "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" . Etc. The sentence with H.323 mentioned is a bit tricky and extends the term to non-SIP signaling. Still, we do want to cover that case and the intent certainly was that a "communication session" is one that s Personally, I like the term "communication session", but perhaps we just need to modify it along the lines of what Charles suggested? Can folks offer a good replacement definition to put in Section 2? Paul ------=_NextPart_000_0027_01CDC78A.527424D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I said I = will publish a new revision of the requirements document.  I have a = list of things on my list, but I may have neglected a few items.  = If you can think of an important change you wanted made to the = requirements draft, let me know.

 

One thing = that was discussed and for which I don’t have an answer is that of = “communication session” vs. something else.  The = requirements document currently says:

 

In this document, the word = "session" refers to a "communication session” that = may exist between two SIP user agents or that might pass through one or = more intermediary devices, including B2BUAs or SIP = Proxies.

 

The term "end-to-end" in this = document means the communication session from the point of origin, = passing through any number of intermediaries, to the ultimate point of = termination. It is recognized that legacy devices may not support the = "end-to-end" session identifier, though an identifier might be = created by an intermediary when it is absent from the session = signaling.

 

There was a desire for changes in terminology.  = Specifically what, though?  Please look at the terminology in the = current draft and let’s discuss what changes to = make:

http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02

 

I’m not so confident that we’ll have a = quick answer, so what I might do is go ahead and publish an -03 with = what other changes I believe folks wanted (and any I get between now and = tomorrow evening).  Don’t take that publication as ignoring = this point.  We can work on revising the terminology even after the = next version.

 

Charles Eckel proposed (on Nov. 3) to replace the = words “communication session” with “SIP message = exchange”.  Paul Kyzivat seemed to think that might work, but = I didn’t see others comment.  Looking at the proposal, = I’m having trouble seeing how I’d use the term in these = sentences:

·         = “The identifier is intended to = represents an end-to-end communication session from the = originating device to the terminating device”

·         = “if a PBX joins or merges two = communication sessions together locally, the end-to-end = properties of currently-defined identifiers are = lost”

·         = “we need the ability to identify = each communication session through a single SIP header-value = regardless of which type of SIP servers”

·         = “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”

·         = Etc.

 

The sentence = with H.323 mentioned is a bit tricky and extends the term to non-SIP = signaling.  Still, we do want to cover that case and the intent = certainly was that a “communication session” is one that = s

 

Personally, I like the term “communication = session”, but perhaps we just need to modify it along the lines of = what Charles suggested?  Can folks offer a good replacement = definition to put in Section 2?

 

Paul

 

------=_NextPart_000_0027_01CDC78A.527424D0-- From internet-drafts@ietf.org Wed Nov 21 10:40:00 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 8FC4A21F87B6; Wed, 21 Nov 2012 10:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaQzDq0ka7bd; Wed, 21 Nov 2012 10:40:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7C21F8756; Wed, 21 Nov 2012 10:40:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121121184000.3058.70482.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2012 10:40:00 -0800 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-reqts-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 18:40:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : Requirements for an End-to-End Session Identification in= IP-Based Multimedia Communication Networks Author(s) : Paul E. Jones Gonzalo Salgueiro James Polk Laura Liess Hadriel Kaplan Filename : draft-ietf-insipid-session-id-reqts-03.txt Pages : 10 Date : 2012-11-21 Abstract: This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-reqts-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Wed Nov 21 10:46:47 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 0A70221F86D0 for ; Wed, 21 Nov 2012 10:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF5Rt9BLCNcF for ; Wed, 21 Nov 2012 10:46:46 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B6A9121F8609 for ; Wed, 21 Nov 2012 10:46:45 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id qALIkiMR001471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Nov 2012 13:46:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1353523605; bh=EnlMU+QWoREN1uvUlFNBwRjuT4VYDnAqIHmO5da2dTA=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=REVxAHTdZ/rznwIeNbEG77xoMqNjdjOSn7I2cmAop4RGgHjBQUA8CZWF/5GS9Ge2v Bq0a4fbfNRM1iIs1IKGKh5FRFUolrC+UiN2D+xx9p17lf5Bz26UvayJ6cJKP0iVT8N k/BFlmKA1cwjlKLPywxj8lJrT1HKzvIJOpxLJNpA= From: "Paul E. Jones" To: Date: Wed, 21 Nov 2012 13:46:54 -0500 Message-ID: <00cb01cdc818$93b3b210$bb1b1630$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01CDC7EE.AADE4650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3IF8bpueH+iTehRLCeLtn7ExVWiw== Content-Language: en-us Subject: [Insipid] draft-ietf-insipid-session-id-reqts-03 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, 21 Nov 2012 18:46:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CC_01CDC7EE.AADE4650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I've posted a new -03 version of the requirements draft. Please note that I did not change the wording related to "communication session", yet. However, what was changed is: . Removed sections marked as "DELETED" . Re-numbered all requirements so they are consecutive . Minor editorial changes . Changes to REQ8 and corresponding section 3.6 that removes language related to RTCP with language relating to syntax; please be sure to look at that text . Removed last sentence from REQ2 . Wording change on REQ3 . At the AD's request, I moved some authors to a new "Contributors" section Comments welcome, though note it is a holiday here in the US Thursday and Friday, so I apologize if my responses are slow. Paul ------=_NextPart_000_00CC_01CDC7EE.AADE4650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I’ve = posted a new -03 version of the requirements draft.  Please note = that I did not change the wording related to “communication = session”, yet.  However, what was changed = is:

·         = Removed sections marked as = “DELETED”

·         = Re-numbered all requirements so they are = consecutive

·         = Minor editorial changes

·         = Changes to REQ8 and corresponding section = 3.6 that removes language related to RTCP with language relating to = syntax; please be sure to look at that text

·         = Removed last sentence from = REQ2

·         = Wording change on REQ3

·         = At the AD’s request, I moved some = authors to a new “Contributors” section

 

Comments = welcome, though note it is a holiday here in the US Thursday and Friday, = so I apologize if my responses are slow.

 

Paul

 

------=_NextPart_000_00CC_01CDC7EE.AADE4650--