From keith.drage@alcatel-lucent.com Wed Oct 3 16:22:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266C421F84B6 for ; Wed, 3 Oct 2012 16:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAfrR78NMTDj for ; Wed, 3 Oct 2012 16:22:28 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB7421F84DD for ; Wed, 3 Oct 2012 16:22:27 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q93NMPUm023722 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 4 Oct 2012 01:22:26 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 4 Oct 2012 01:22:25 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Thu, 4 Oct 2012 01:22:24 +0200 Thread-Topic: Agenda for interim Thread-Index: Ac2hvfHReVX0omwoT5eUMGlU/Ueyzg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] Agenda for interim 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, 03 Oct 2012 23:22:29 -0000 Following find the agenda for the INSIPID interim tomorrow/today Note times are UK times.=20 INtermediary-safe SIP session ID (INSIPID) WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Interim meeting 4th October 2012 ** AGENDA ** Chairs: Gonzalo Salgueiro (gsalguei@cisco.com) Keith Drage (keith.drage@alcatel-lucent.com) =20 =20 14:00-14:05 Introduction and Status Update (Chairs) 14:05-14:50 Use cases=20 draft-ietf-insipid-session-id-reqts-01.txt 14:50-15:10 Impact of use cases on requirements=20 draft-ietf-insipid-session-id-reqts-01.txt 15:10-15:30 Review and discussion of proposed solution =20 draft-jones-insipid-session-id-00.txt (expired) 15:30-15:55 Session ID and backwards compatibility Christer Holmberg 15:55-16:00 Wrap-up (Chairs) Regards Keith From keith.drage@alcatel-lucent.com Thu Oct 4 05: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 F070321F86A2 for ; Thu, 4 Oct 2012 05:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.249 X-Spam-Level: X-Spam-Status: No, score=-108.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=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 2FZJEf+dH5xy for ; Thu, 4 Oct 2012 05:39:59 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id DF62C21F86A4 for ; Thu, 4 Oct 2012 05:39:58 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q94Cdmd2011046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 4 Oct 2012 14:39:52 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 4 Oct 2012 14:39:39 +0200 From: "DRAGE, Keith (Keith)" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Date: Thu, 4 Oct 2012 14:39:38 +0200 Thread-Topic: Agenda for interim Thread-Index: Ac2hvfHReVX0omwoT5eUMGlU/UeyzgAbnS4A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [Insipid] Agenda for interim 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, 04 Oct 2012 12:40:00 -0000 I thought my cochair had not posted this, so posted my version. Here is the real agenda: Agenda: 1) Note well, agenda bash, notetakers, etc. - Chairs (5 min) 2) Discussion of requirements draft: use cases (cont'd) - Paul Jones, James= Polk (45 min) draft-ietf-insipid-session-id-reqts-01 http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-01 3) Discussion of requirements draft: requirements (cont'd) - Paul Jones, Ja= mes Polk (15 min) draft-ietf-insipid-session-id-reqts-01 http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-01 4) Proposed solution discussion - various (50 min) (a) Discussion on backwards compatibility to Kaplan draft - Christer Holmbe= rg (20 minutes) (b) Discussion of proposed session id solution (conclusion of Vancouver pre= sentation) - Paul Jones, James Polk (30 min) draft-jones-insipid-session-id-00 http://tools.ietf.org/html/draft-jones-insipid-session-id-00 [Note: We encourage folks to submit any candidate solutions for session id = that they wish to be considered by the WG] 4) Next steps - Chairs (5 min) Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of DRAGE, Keith (Keith) > Sent: 04 October 2012 00:22 > To: insipid@ietf.org > Subject: [Insipid] Agenda for interim >=20 > Following find the agenda for the INSIPID interim tomorrow/today >=20 > Note times are UK times. >=20 > INtermediary-safe SIP session ID (INSIPID) WG > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >=20 > Interim meeting 4th October 2012 >=20 > ** AGENDA ** >=20 > Chairs: Gonzalo Salgueiro (gsalguei@cisco.com) > Keith Drage (keith.drage@alcatel-lucent.com) >=20 >=20 > 14:00-14:05 Introduction and Status Update (Chairs) >=20 > 14:05-14:50 Use cases >=20 > draft-ietf-insipid-session-id-reqts-01.txt >=20 > 14:50-15:10 Impact of use cases on requirements >=20 > draft-ietf-insipid-session-id-reqts-01.txt >=20 > 15:10-15:30 Review and discussion of proposed solution >=20 > draft-jones-insipid-session-id-00.txt > (expired) >=20 > 15:30-15:55 Session ID and backwards compatibility >=20 > Christer Holmberg >=20 > 15:55-16:00 Wrap-up (Chairs) >=20 > Regards >=20 > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Thu Oct 4 08:27: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 CFB0121F86FD for ; Thu, 4 Oct 2012 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[AWL=0.039, 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 CkwdysZgKyz1 for ; Thu, 4 Oct 2012 08:27:52 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id EAAC821F86FC for ; Thu, 4 Oct 2012 08:27:51 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id 6zfv1k00316LCl05D3TvC6; Thu, 04 Oct 2012 15:27:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 73NU1k00a3ZTu2S3S3NUyQ; Thu, 04 Oct 2012 15:22:29 +0000 Message-ID: <506DA9CA.4010704@alum.mit.edu> Date: Thu, 04 Oct 2012 11:22:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "insipid@ietf.org" , Keith Drage , 'Gonzalo Salgueiro' Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [Insipid] Notes from INSIPID call 4oct2012 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, 04 Oct 2012 15:27:52 -0000 Notes for INSIPID call 4oct2012 Paul Kyzivat is the note taker. Attendees: Paul Kyzivat, Gonzalo Salgueiro, Keith Drage, Andy Hutton, Christer Holmbert, Dan Romascanu, Hadriel Kaplan, Laura Leiss, Paul Jones, Peter Dawes, Adam Roach. (Maybe others joined later?) Christer expressed concern that we not do anything that excludes solving the transfer use case. Keith proposed that 3.2 of requirements be removed (on recording). Andy, speaking for the siprec group, agreed. Keith said 3725 on 3pcc doesn’t cover any 1 in 1 out cases and so doesn’t apply to us. There may still be 3pcc use cases that *are* 1 in 1 out, which would apply to us. Paul Jones was concerned about removing 3.5. He wasn’t concerned with matching a conference per se, but with correlating participants. He felt the proposed *mechanism* supported this, and he didn’t want to lose that. Keith was concerned that if we leave this requirement in then when selecting a mechanism we will be constrained to one that supports this. Paul J explained how his intended mechanism supported this. Hadriel commented that PBXs *want* to hide transfers, so one end doesn’t know that the other end has done the transfer. In that case the session id, or half id, won’t appear to change. Christer said he didn’t know of any requirement for the session id to identify participants. Adam and others were concerned with keeping 3.5 as a requirement. So solution might satisfy this even without a requirement, but there is no guarantee that we will choose a solution that satisfies it. Regarding 3.6: this justifies requirement 10. Andy said this leads to possibility that session ids can change during a session. Discussion ensued about preservation, or not, of sesson id across multiple dialogs. Hadriel drew a distinction between a “SIP transfer” via REFER, and a transfer at a “higher layer” (such as a PBX using reinvite) that might not be supported by this mechanism. He thinks that a B2BUA/PBX that does the transfer via reinvite should be able to preserve the id if it wants, but not be *required* to do so. Keith asked Hadriel about how he interprets 3.6 – does it imply REQ2 or not? He didn’t think it should require it. Hadriel said that he didn’t see REQ2 being implied. Hadriel doesn’t imagine that PBXs will be sending reinvites to ensure that the session id is preserved after a transfer. Adam said that will mean that many implementations (PBX style) won’t be compliant with insipid. Hadriel again stated that he didn’t think this applied to SIP PBXs. I disagreed. Adam says that there must be some level of correlatability in case of transfers, or else the mechanism will be of little use. He is arguing for preserving REQ2. Keith decided to postpone further discussion of this one for now because there is no sign of resolving it now. To be continued on list. Regarding 3.7: Keith proposed to remove part about accounting an billing. Asked if anybody objected to removing. No objections raised. Regarding 3.9: Keith asked about desire to preserve this. Andy spoke in favor of this, at least for 2 point calls. Keith observed that this figure is 0 in, 2 out. He wondered if it would still be in scope for 0 in, 3 out. And stated that he thought *that* could be out of scope. Keith proposed that 3.9 be updated to make it clear that this only applies for two endpoints. Paul J thought it already did, but agreed it could be made more explicit. Moved to discussion of section 4 on requirements: Keith stated that we have agreed to remove REQ3 and leave the remainder unchanged. Nobody disagreed. Moved to discussion of backward compatibility by Christer: He has been considering draft-kaplan-dispatch-session-id-00 and –03. It is -00 that is referenced by 3gpp, while -03 is the latest, though expired. (They differ in characters allowed in the id.) The requirements he derived are that syntax must be backward compatible with those drafts, and that a recipient must be prepared to receive a value from something implementing one of those drafts. He also inferred that it must be possible to detect when peer is following the Kaplan draft and then refrain from adding value for other end. Paul Jones wondered if that is necessary – wouldn’t the other half, encoded as a parameter, be ignored? Christer thought *maybe*. Need to investigate. Question came of of whether to go with -00 syntax (a-z) or -03 syntax (a-f => hex). Christer proposed to follow -00. But Hadriel stated this was a bug, that intent had always been to use hex. General agreement to support backward compatibility to -03. I asked if this implied adding additional formal requirements. There was consensus *not* to do that – that individuals might have a *desire* for backward compatibility and can factor that in when evaluating proposed mechanisms. Regarding draft-jones-insipid-session-id-00: Hadriel said he has read the Jones mechanism draft, and doesn’t understand how it does the things that are claimed for it. Paul Jones did an overview of his draft. Hadriel questioned the call transfer case in slide 7. Paul Jones was envisioning a B2BUA that does signaling and not media, so that a reinvite is needed to accomplish the transfer. Hadriel was concerned with the case where the B2BUA bridges media. In that case no signaling is required to accomplish the transfer. [I lost audio and may have missed some notes] There were questions for Hadriel about what he would want changed in this proposed mechanism to address his concerns. He stated that he thinks the main concern is complexity of having two values rather than one value. Keith asked for the various authors to get together and try to agree on those parts of a draft that all agree on, while preserving alternatives where there is disagreement. The three people involved are Paul J, Hadriel, Christer. There is an action item for Christer to set up meetings between the three to do this. The alternative, if that doesn’t work, is separate drafts in time for the Atlanta meeting. Another action item: for Paul J to make the agreed upon changes to the requirements. Keith will post those changes on the mailing list for others to comment on before doing the update. From keith.drage@alcatel-lucent.com Thu Oct 4 08:37:57 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 67C1E21F86EF for ; Thu, 4 Oct 2012 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOiz+fD7vBP6 for ; Thu, 4 Oct 2012 08:37:51 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id E9B9121F8694 for ; Thu, 4 Oct 2012 08:37:50 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q94FXh1L026482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 4 Oct 2012 17:37:46 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 4 Oct 2012 17:37:26 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Thu, 4 Oct 2012 17:37:26 +0200 Thread-Topic: Changes to INSIPID requirements draft Thread-Index: Ac2iRie4dYBPY8URQPmy6ukkNBF0LA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [Insipid] Changes to INSIPID 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: Thu, 04 Oct 2012 15:37:57 -0000 Based on the virtual interim we have just had, this is my summary of the ch= anges needed to the requirements document. These had consensus in the "meet= ing room", but I am putting these on the list for a few days to give change= s for objections, but otherwise I'll ask Paul Jones to proceed with a revis= ion early next week based on these changes. Paul, if you think I've missed anything then please post a response. 1) Use case in section 3.2 is removed. "3.2. Session Recording A SIP Session is established between UA A and UA B with a SIP B2BUA acting as a middlebox. Both UA A and UA B establish a recording session with a session recording server (SRS) using the SIPREC protocol. The SRS needs to be able to determine from the metadata provided by UA A and UA B that the media streams are associated with the same communication session (CS). Derived Requirements: REQ1, REQ3, REQ4" 2) Use case in section 3.5 is removed. "3.5. Identification of devices in the same conference SIP messaging can easily be multipoint in nature, specifically with several UAs communicating with a multipoint control unit (MCU) as part of a conference. The ability to distinguish all participants in single focus based multipoint conference to be identified as in the same communications session with all the other participants (i.e., in a single star configuration), verses in another conference session. Derived Requirements: REQ3" 3) In section 3.7, removes references to "acounting, billing". 4) In section 3.9 add a sentence that indicates the use case does not exten= d to 3 or more SIP UAs. Existing text already indicates two SIP UAs. 5) In section 4, REQ3 is removed. "REQ3: It must be possible for a device other than the conference focus to correlate sessions participating in a multipoint or multi- party conference on a single focus by observing the end-to-end session identifiers of each session." This is the bare bones as I don't want to duplicate the meeting report whic= h will come out separately. Regards Keith=20 From gsalguei@cisco.com Thu Oct 4 19:51:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D6E1F0C4C for ; Thu, 4 Oct 2012 19:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.514 X-Spam-Level: X-Spam-Status: No, score=-9.514 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, 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 VIxQyCgH6kXA for ; Thu, 4 Oct 2012 19:51:33 -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 CB2C11F041F for ; Thu, 4 Oct 2012 19:51:24 -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 q952pOUP002339 for ; Thu, 4 Oct 2012 22:51:24 -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 q952pJvD004043; Thu, 4 Oct 2012 22:51:20 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Oct 2012 22:51:19 -0400 Message-Id: <0AD83986-7C3F-4D5E-8FA0-0A2F24740C71@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: insipid-chairs@tools.ietf.org Subject: [Insipid] insipid - Requested session has been scheduled for IETF 85 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, 05 Oct 2012 02:51:34 -0000 The INSIPID session has been scheduled for IETF85 in Atlanta: --------------------------------------------- insipid Session 1 (2:00:00) Monday November 5th, Afternoon Session II 15:20-17:20 Room Name: Room 209 Length of Session(s): 2 Hours Number of Attendees: 40 --------------------------------------------- From gsalguei@cisco.com Thu Oct 4 20:27: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 1E66821F84BF for ; Thu, 4 Oct 2012 20:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 r4iq0PF28IW5 for ; Thu, 4 Oct 2012 20:27:04 -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 3571821F84B8 for ; Thu, 4 Oct 2012 20:27:04 -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 q953R3ZU006004 for ; Thu, 4 Oct 2012 23:27:03 -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 q953QxP3028149 for ; Thu, 4 Oct 2012 23:27:00 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Gonzalo Salgueiro In-Reply-To: <506DA9CA.4010704@alum.mit.edu> Date: Thu, 4 Oct 2012 23:26:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <506DA9CA.4010704@alum.mit.edu> To: insipid@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [Insipid] Notes from INSIPID call 4oct2012 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, 05 Oct 2012 03:27:05 -0000 The minutes from the virtual interim have been posted to the Proceedings = page: = http://www.ietf.org/proceedings/interim/2012/10/04/insipid/minutes/minutes= -interim-2012-insipid-5 Thanks, Keith & Gonzalo On Oct 4, 2012, at 11:22 AM, Paul Kyzivat wrote: > Notes for INSIPID call 4oct2012 >=20 > Paul Kyzivat is the note taker. >=20 > Attendees: Paul Kyzivat, Gonzalo Salgueiro, Keith Drage, Andy Hutton, = Christer Holmbert, Dan Romascanu, Hadriel Kaplan, Laura Leiss, Paul = Jones, Peter Dawes, Adam Roach. (Maybe others joined later?) >=20 > Christer expressed concern that we not do anything that excludes = solving the transfer use case. >=20 > Keith proposed that 3.2 of requirements be removed (on recording). = Andy, speaking for the siprec group, agreed. >=20 > Keith said 3725 on 3pcc doesn=92t cover any 1 in 1 out cases and so = doesn=92t apply to us. There may still be 3pcc use cases that *are* 1 in = 1 out, which would apply to us. >=20 > Paul Jones was concerned about removing 3.5. He wasn=92t concerned = with matching a conference per se, but with correlating participants. He = felt the proposed *mechanism* supported this, and he didn=92t want to = lose that. >=20 > Keith was concerned that if we leave this requirement in then when = selecting a mechanism we will be constrained to one that supports this. >=20 > Paul J explained how his intended mechanism supported this. >=20 > Hadriel commented that PBXs *want* to hide transfers, so one end = doesn=92t know that the other end has done the transfer. In that case = the session id, or half id, won=92t appear to change. >=20 > Christer said he didn=92t know of any requirement for the session id = to identify participants. >=20 > Adam and others were concerned with keeping 3.5 as a requirement. So = solution might satisfy this even without a requirement, but there is no = guarantee that we will choose a solution that satisfies it. >=20 > Regarding 3.6: this justifies requirement 10. Andy said this leads to = possibility that session ids can change during a session. Discussion = ensued about preservation, or not, of sesson id across multiple dialogs. > Hadriel drew a distinction between a =93SIP transfer=94 via REFER, and = a transfer at a =93higher layer=94 (such as a PBX using reinvite) that = might not be supported by this mechanism. He thinks that a B2BUA/PBX = that does the transfer via reinvite should be able to preserve the id if = it wants, but not be *required* to do so. >=20 > Keith asked Hadriel about how he interprets 3.6 =96 does it imply REQ2 = or not? He didn=92t think it should require it. >=20 > Hadriel said that he didn=92t see REQ2 being implied. Hadriel doesn=92t= imagine that PBXs will be sending reinvites to ensure that the session = id is preserved after a transfer. >=20 > Adam said that will mean that many implementations (PBX style) won=92t = be compliant with insipid. >=20 > Hadriel again stated that he didn=92t think this applied to SIP PBXs. = I disagreed. >=20 > Adam says that there must be some level of correlatability in case of = transfers, or else the mechanism will be of little use. He is arguing = for preserving REQ2. >=20 > Keith decided to postpone further discussion of this one for now = because there is no sign of resolving it now. To be continued on list. >=20 > Regarding 3.7: Keith proposed to remove part about accounting an = billing. Asked if anybody objected to removing. No objections raised. >=20 > Regarding 3.9: Keith asked about desire to preserve this. Andy spoke = in favor of this, at least for 2 point calls. Keith observed that this = figure is 0 in, 2 out. He wondered if it would still be in scope for 0 = in, 3 out. And stated that he thought *that* could be out of scope. = Keith proposed that 3.9 be updated to make it clear that this only = applies for two endpoints. Paul J thought it already did, but agreed it = could be made more explicit. >=20 > Moved to discussion of section 4 on requirements: >=20 > Keith stated that we have agreed to remove REQ3 and leave the = remainder unchanged. Nobody disagreed. >=20 > Moved to discussion of backward compatibility by Christer: >=20 > He has been considering draft-kaplan-dispatch-session-id-00 and =9603. = It is -00 that is referenced by 3gpp, while -03 is the latest, though = expired. (They differ in characters allowed in the id.) >=20 > The requirements he derived are that syntax must be backward = compatible with those drafts, and that a recipient must be prepared to = receive a value from something implementing one of those drafts. >=20 > He also inferred that it must be possible to detect when peer is = following the Kaplan draft and then refrain from adding value for other = end. Paul Jones wondered if that is necessary =96 wouldn=92t the other = half, encoded as a parameter, be ignored? Christer thought *maybe*. Need = to investigate. >=20 > Question came of of whether to go with -00 syntax (a-z) or -03 syntax = (a-f =3D> hex). Christer proposed to follow -00. But Hadriel stated this = was a bug, that intent had always been to use hex. General agreement to = support backward compatibility to -03. >=20 > I asked if this implied adding additional formal requirements. There = was consensus *not* to do that =96 that individuals might have a = *desire* for backward compatibility and can factor that in when = evaluating proposed mechanisms. >=20 > Regarding draft-jones-insipid-session-id-00: >=20 > Hadriel said he has read the Jones mechanism draft, and doesn=92t = understand how it does the things that are claimed for it. > Paul Jones did an overview of his draft. >=20 > Hadriel questioned the call transfer case in slide 7. Paul Jones was = envisioning a B2BUA that does signaling and not media, so that a = reinvite is needed to accomplish the transfer. Hadriel was concerned = with the case where the B2BUA bridges media. In that case no signaling = is required to accomplish the transfer. >=20 > [I lost audio and may have missed some notes] >=20 > There were questions for Hadriel about what he would want changed in = this proposed mechanism to address his concerns. He stated that he = thinks the main concern is complexity of having two values rather than = one value. >=20 > Keith asked for the various authors to get together and try to agree = on those parts of a draft that all agree on, while preserving = alternatives where there is disagreement. The three people involved are = Paul J, Hadriel, Christer. There is an action item for Christer to set = up meetings between the three to do this. >=20 > The alternative, if that doesn=92t work, is separate drafts in time = for the Atlanta meeting. >=20 > Another action item: for Paul J to make the agreed upon changes to the = requirements. Keith will post those changes on the mailing list for = others to comment on before doing the update. >=20 >=20 >=20 From keith.drage@alcatel-lucent.com Fri Oct 5 07:33: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 3D96E21F8760 for ; Fri, 5 Oct 2012 07:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.082 X-Spam-Level: X-Spam-Status: No, score=-110.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIld7av13SKl for ; Fri, 5 Oct 2012 07:33:19 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 69A6D21F846F for ; Fri, 5 Oct 2012 07:33:19 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q95ESFXZ012000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 5 Oct 2012 16:33:18 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 5 Oct 2012 16:32:55 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Fri, 5 Oct 2012 16:32:54 +0200 Thread-Topic: insipid - Requested session has been scheduled for IETF 85 Thread-Index: Ac2ipFjyqUyZ4vCtRvyqZLb3gvOKgAAYa2Tg Message-ID: References: <0AD83986-7C3F-4D5E-8FA0-0A2F24740C71@cisco.com> In-Reply-To: <0AD83986-7C3F-4D5E-8FA0-0A2F24740C71@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] insipid - Requested session has been scheduled for IETF 85 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, 05 Oct 2012 14:33:20 -0000 Just to add, please note that this is still subject to change, as swaps are= going on to resolve conflicts. RAI area tends to be fairly stable, but cha= nges can always occur. Additionally, while I think the chairs have a reasonably good idea of what = we think should be on the agenda, if you have specific requests, now would = be the time to send them to the chairs. Regards Keith > -----Original Message----- > From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com] > Sent: 05 October 2012 03:51 > To: insipid@ietf.org > Cc: insipid-chairs@tools.ietf.org > Subject: insipid - Requested session has been scheduled for IETF 85 >=20 > The INSIPID session has been scheduled for IETF85 in Atlanta: >=20 > --------------------------------------------- > insipid Session 1 (2:00:00) > Monday November 5th, Afternoon Session II 15:20-17:20 > Room Name: Room 209 > Length of Session(s): 2 Hours > Number of Attendees: 40 > --------------------------------------------- From keith.drage@alcatel-lucent.com Sat Oct 6 12:52:13 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 DB79A21F84AE for ; Sat, 6 Oct 2012 12:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.095 X-Spam-Level: X-Spam-Status: No, score=-110.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62-92ZNZglz2 for ; Sat, 6 Oct 2012 12:52:13 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B266521F84A6 for ; Sat, 6 Oct 2012 12:52:11 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q96Jq7FX000372 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 6 Oct 2012 21:52:08 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 6 Oct 2012 21:52:07 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Sat, 6 Oct 2012 21:52:07 +0200 Thread-Topic: Handling (or not) of call transfer Thread-Index: Ac2j7K3XtGJ2UmD/Qeuwf12VS2D83A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] Handling (or not) of call transfer 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, 06 Oct 2012 19:52:14 -0000 (As WG cochair) We currently have a use case in the requirements document as follows: "3.6. Tracking transferred sessions It is difficult to track which SIP messages where involved in the same call across transactions, especially when invoking supplementary services such as call transfer or call join. The ability to track communications sessions as they are transferred, one side at a time, through until completion of the session (i.e., until a BYE is sent). Derived Requirements: REQ1, REQ2, REQ10" This results in requirement 2 as follows: " REQ2: It must be possible to correlate two end-to-end sessions when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX). This might result in a change in the value of the end-to-end Session-Identifier." >From the discussion in the virtual interim it appears that we do not have t= he right requirement that corresponds to the scope, however there seemed to= be a need to have something. Please contribute to the mailing list on what you think the requirement sho= uld now be, and as such, what impact this has on the use case. Regards Keith From paulej@packetizer.com Sun Oct 7 11:19:13 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 7F54021F8707 for ; Sun, 7 Oct 2012 11:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 1dMPS5WAoZFi for ; Sun, 7 Oct 2012 11:19:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3B21F86DF for ; Sun, 7 Oct 2012 11:19:12 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q97IJ6S8009045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Oct 2012 14:19:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349633947; bh=pVEIkPa8s+5wbTXsubTajgr617c+vqjxHbUytGJ5Qww=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=GxWK362b4E3MFrzE4mN6pC7hFdhzZ/eF4QkAU+k6QwXb/OieSpMeTW1tDgc5GrGkB YGZnv10OCfYp002fQ0R6R5178m/yPbFdks4sjMV19Q31zt5yU00ee1Hg834dQ6ozle 2CBGA62arKCwebS3O/8EUhPp5IFX5QTGGME6fAE0= From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , References: In-Reply-To: Date: Sun, 7 Oct 2012 14:19:18 -0400 Message-ID: <03cc01cda4b8$44222ac0$cc668040$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sd5ewzfDg Content-Language: en-us Subject: Re: [Insipid] Handling (or not) of call transfer 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, 07 Oct 2012 18:19:13 -0000 Personally, I like the requirement. The primary objective of the work is to identify a session end-to-end. The reasons are several, but one strong use case is to be able to troubleshoot. Service interaction can make this challenging, since two separate calls can be merged into one, calls can be transferred, etc. When there are such service interactions, we do not want to lose the ability to identify the resulting session and the ability to relate that to the former end-to-end session. That's why we proposed the solution we proposed. In all cases where Alice calls Bob and, through whatever mechanism, Alice ends up in communication with Carol, Alice retains here Session-ID-UUID value. Likewise, Carol retains her distinct value. These two UUIDs then serve to identify a session end-to-end. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: Saturday, October 06, 2012 3:52 PM > To: insipid@ietf.org > Subject: [Insipid] Handling (or not) of call transfer > > (As WG cochair) > > We currently have a use case in the requirements document as follows: > > "3.6. Tracking transferred sessions > > It is difficult to track which SIP messages where involved in the > same call across transactions, especially when invoking supplementary > services such as call transfer or call join. The ability to track > communications sessions as they are transferred, one side at a time, > through until completion of the session (i.e., until a BYE is sent). > > Derived Requirements: REQ1, REQ2, REQ10" > > This results in requirement 2 as follows: > > " REQ2: It must be possible to correlate two end-to-end sessions when > a > session is transferred or if two different sessions are joined > together via an intermediary (e.g., a PBX). This might result in a > change in the value of the end-to-end Session-Identifier." > > From the discussion in the virtual interim it appears that we do not > have the right requirement that corresponds to the scope, however there > seemed to be a need to have something. > > Please contribute to the mailing list on what you think the requirement > should now be, and as such, what impact this has on the use case. > > Regards > > Keith > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Sun Oct 7 12:17:26 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCCF21F8714 for ; Sun, 7 Oct 2012 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.142, 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 rYqxMJLhyfju for ; Sun, 7 Oct 2012 12:17:25 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5281E21F8713 for ; Sun, 7 Oct 2012 12:17:25 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-02-5071d5447c8b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EC.BB.17130.445D1705; Sun, 7 Oct 2012 21:17:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sun, 7 Oct 2012 21:17:23 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Date: Sun, 7 Oct 2012 21:17:23 +0200 Thread-Topic: Handling (or not) of call transfer Thread-Index: Ac2j7K3XtGJ2UmD/Qeuwf12VS2D83AAFJYK3 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra7L1cIAg+VTBS3m33/GZPG08Syj A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYc3cOa8EnkYoDt/oZGxg/C3QxcnJICJhI XL99gQXCFpO4cG89WxcjF4eQwClGiXn9R5khnAWMEps73rF2MXJwsAlYSHT/0wZpEBFIkVg0 Yw4jiM0ioCLRu6CVFcQWFtCXOPbkBVi5iICBxOMH6RDlRhLzG5qZQWxegXCJLduOsIHYQgKx EqtfzwOzOQXiJHq+tjOB2IxA93w/tQbMZhYQl7j1ZD4TxJ0CEkv2nGeGsEUlXj7+xwpRLypx p309I0S9jsSC3Z/YIGxtiWULX0PtFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMQrnJmbm pJeb66UWZSYXF+fn6RWnbmIERsjBLb8NdjBuui92iFGag0VJnFdPdb+/kEB6YklqdmpqQWpR fFFpTmrxIUYmDk6pBkbTeUe6l2qkLU2Q+OHgs9LnyG7RE9cjJlunHb7T9bC/503Xv5LM6OaZ z1gKO9YZ6cs/Y27feNlBPHn/OU6zH4kHk49qSgiI/Dzak21gu7588hKlhA6pSln1NZ57Dlpv rp0wZ8m/q8sYsjzXPZ68VfJT87KTJ+tczr60Lrn66Xn/tIc87vmHuTOVWIozEg21mIuKEwGg 2sLsXgIAAA== Subject: Re: [Insipid] Handling (or not) of call transfer 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, 07 Oct 2012 19:17:26 -0000 Hi, First, I think we can remove the last sentence in the REQ2 text. The REQUIR= EMENT is about being able to correlate end-to-end sessions. Whether the ses= sion id changes or not is not relevant from a requirement perspective, as l= ong as there is A way to correlate. Second, if we want to be able to correlate sessions, do we limit the scope = transfer? What if users have other use-cases where sessions are considered = to be correlated? Just because SIP sessions are joined toghether via an int= ermediary, I doesn't have to be transfer. One example is the 3GPP voice con= tinuity function, where an application server joins together SIP sessions c= oming from the same user (but via different access technologies). I don't t= hink we call that "transfer" (at least not user transfer). Third, I know we've had discussions about this, but from reading the requir= ement I can't figure out what "end-to-end session" means. Maybe we should t= alk about correlating SIP sessions. Regards, Christer ________________________________________ From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] On Behalf Of DRAG= E, Keith (Keith) [keith.drage@alcatel-lucent.com] Sent: Saturday, October 06, 2012 10:52 PM To: insipid@ietf.org Subject: [Insipid] Handling (or not) of call transfer (As WG cochair) We currently have a use case in the requirements document as follows: "3.6. Tracking transferred sessions It is difficult to track which SIP messages where involved in the same call across transactions, especially when invoking supplementary services such as call transfer or call join. The ability to track communications sessions as they are transferred, one side at a time, through until completion of the session (i.e., until a BYE is sent). Derived Requirements: REQ1, REQ2, REQ10" This results in requirement 2 as follows: " REQ2: It must be possible to correlate two end-to-end sessions when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX). This might result in a change in the value of the end-to-end Session-Identifier." >From the discussion in the virtual interim it appears that we do not have t= he right requirement that corresponds to the scope, however there seemed to= be a need to have something. Please contribute to the mailing list on what you think the requirement sho= uld now be, and as such, what impact this has on the use case. Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid= From paulej@packetizer.com Sun Oct 7 12:46: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 4A65721F8715 for ; Sun, 7 Oct 2012 12:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 DyB3ZF1pbeGH for ; Sun, 7 Oct 2012 12:46:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7246221F870A for ; Sun, 7 Oct 2012 12:46:48 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q97Jkhsl012250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Oct 2012 15:46:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349639204; bh=2Eak1YWNAXCQVxa1oGnMSEMY+t5XTblalpf7lQM72vY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=sE9RxdHdwL9RBAJrc7ho6RlyJdWaor8FsJuRAUmBC+KRAxJAGgYM2YjTCGrvN19xm ap453FnsF5zbW87En6U1lWkLY00ZZiXscoR6oyiA8NhyuidBeft+dt8NiYJvSao9ZI vrhi/r+Qb5cept46PAHwU5Pg5PvkEn5dDf1UwYKA= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'DRAGE, Keith \(Keith\)'" , References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 7 Oct 2012 15:46:49 -0400 Message-ID: <000901cda4c4$7e8bd150$7ba373f0$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4Jl6qNzEA= Content-Language: en-us Subject: Re: [Insipid] Handling (or not) of call transfer 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, 07 Oct 2012 19:46:49 -0000 Christer, > First, I think we can remove the last sentence in the REQ2 text. The > REQUIREMENT is about being able to correlate end-to-end sessions. > Whether the session id changes or not is not relevant from a requirement > perspective, as long as there is A way to correlate. I think that sentence is useful. Under some circumstances, the end-to-end session identifier might change. Under other circumstances, it might remain the same. In our proposal, it would always change if either endpoint in the session changes. However, there may be a workable solution where the change is not necessary; I just don't know what solution that would be. > Second, if we want to be able to correlate sessions, do we limit the > scope transfer? What if users have other use-cases where sessions are > considered to be correlated? Just because SIP sessions are joined > toghether via an intermediary, I doesn't have to be transfer. One > example is the 3GPP voice continuity function, where an application > server joins together SIP sessions coming from the same user (but via > different access technologies). I don't think we call that "transfer" > (at least not user transfer). I think that might be an example of where sessions might be "joined" together. Arguably, that's still a "transfer", but it is important to differentiate between cases where two existing calls are "spliced" together vs. a case where a call between A and B is transferred such that B drops out and a call between A and C exists. The latter might be via a REFER or it might not. In any case, we need to cover "transferred" calls and calls that are "joined" together. > Third, I know we've had discussions about this, but from reading the > requirement I can't figure out what "end-to-end session" means. Maybe we > should talk about correlating SIP sessions. The definition of "session" is itself overused, but we do not have a better word. However, we did define it in Section 2: 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. Paul From christer.holmberg@ericsson.com Sun Oct 7 13:18:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275AB21F86B9 for ; Sun, 7 Oct 2012 13:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.138, 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 L41O6mUosxNP for ; Sun, 7 Oct 2012 13:18:39 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE7A21F86A3 for ; Sun, 7 Oct 2012 13:18:38 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-ab-5071e39d78e8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 51.BE.17130.D93E1705; Sun, 7 Oct 2012 22:18:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 7 Oct 2012 22:18:38 +0200 From: Christer Holmberg To: "Paul E. Jones" , "'DRAGE, Keith (Keith)'" , "insipid@ietf.org" Date: Sun, 7 Oct 2012 22:18:37 +0200 Thread-Topic: [Insipid] Handling (or not) of call transfer Thread-Index: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4Jl6qNzECAAAbj6A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> In-Reply-To: <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvre68x4UBBjfOMFvMv/+MyeJp41lG i/MXNjA5MHu0PtvL6rFkyU8mj4Z9R9kDmKO4bFJSczLLUov07RK4Ms7ffsFWcFW4omHaCvYG xpP8XYycHBICJhI/G/uYIWwxiQv31rN1MXJxCAmcYpTo/7KdFcKZwyjx/tYsli5GDg42AQuJ 7n/aIHERgX5GiR1T57ODdLMIqEjsuPMMrEZYwFJi3ZV0kLCIgJXE16vz2SBsJ4lP91vAbF6B cInZxy5ALbsDNGfFdrArOAVsJZ58OAU2kxHoou+n1jCB2MwC4hK3nsxngrhUQGLJnvNQV4tK vHz8jxWiXlTiTvt6Roh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjKKzkIydhaRlFpKWWUha FjCyrGIUzk3MzEkvN9dLLcpMLi7Oz9MrTt3ECIycg1t+G+xg3HRf7BCjNAeLkjivnup+fyGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2MZ5erMX/7b7yo1lV0iucluYJ2wcy4MuGjAZ8WPWdx +V359GtK7QVNf2cVvvSwG4umSERdF1//Vqnnt/LdZ1OO399R7FkkrCVkdn3XLJEWVqejZ05e uvXO/Fqy7JuppQaXWgTtxXrL8pc6Twu1/fWNRT//28s7H9wXvUgxj7/UYt6k/dPhhspzJZbi jERDLeai4kQAFXSlymoCAAA= Subject: Re: [Insipid] Handling (or not) of call transfer 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, 07 Oct 2012 20:18:40 -0000 Hi, >> First, I think we can remove the last sentence in the REQ2 text. The >> REQUIREMENT is about being able to correlate end-to-end sessions. >> Whether the session id changes or not is not relevant from a requirement >> perspective, as long as there is A way to correlate. > > I think that sentence is useful. Under some circumstances, the end-to-en= d > session identifier might change. Under other circumstances, it might rem= ain > the same. In our proposal, it would always change if either endpoint in = the > session changes. However, there may be a workable solution where the cha= nge > is not necessary; I just don't know what solution that would be. I don't think the requirements should talk about your proposal :) >> Second, if we want to be able to correlate sessions, do we limit the >> scope transfer? What if users have other use-cases where sessions are >> considered to be correlated? Just because SIP sessions are joined >> toghether via an intermediary, I doesn't have to be transfer. One >> example is the 3GPP voice continuity function, where an application >> server joins together SIP sessions coming from the same user (but via >> different access technologies). I don't think we call that "transfer" >> (at least not user transfer). > > I think that might be an example of where sessions might be "joined" > together. Arguably, that's still a "transfer", but it is important to > differentiate between cases where two existing calls are "spliced" togeth= er > vs. a case where a call between A and B is transferred such that B drops = out > and a call between A and C exists. The latter might be via a REFER or it > might not. In any case, we need to cover "transferred" calls and calls t= hat > are "joined" together. Of course, calls may also be joined together by the endpoints, ie there is = no intermediary doing it. So, IF we decide to keep the requirement, can't it simply say that it shall= be possible to correlate multiple sessions? "REQ2: It must be possible to correlate multiple end-to-end sessions= ." >> Third, I know we've had discussions about this, but from reading the >> requirement I can't figure out what "end-to-end session" means. Maybe we >> should talk about correlating SIP sessions. > > The definition of "session" is itself overused, but we do not have a bett= er > word. However, we did define it in Section 2: Yes, I noted that. Comment withdrawn :) Regards, Christer= From paulej@packetizer.com Sun Oct 7 14:10:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CB621F8713 for ; Sun, 7 Oct 2012 14:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.313 X-Spam-Level: X-Spam-Status: No, score=-2.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 bVjgACRvgJZw for ; Sun, 7 Oct 2012 14:10:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 65FAD21F870F for ; Sun, 7 Oct 2012 14:10:58 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q97LArtY015532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Oct 2012 17:10:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349644254; bh=IwdcASLvzi/e2zkd+lPqR6xWOrV2b1EqmBIBe/vEbHY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=PNyJ5DSa0tXf/cWG7GR+IjbCAMiwZaO1XAvhWOu42wUvMC4YyGQ2/kX+xyEWtfOpP zS61gsv2sPeYuJWunHexSA24gmySoeI9wa8IovXfI6dBgL98Sxgn4tL9bxMbflGiSM GmZ+eTV64NfgjfTW5tmjvDYVVSLknj2iSM4uQf7A= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'DRAGE, Keith \(Keith\)'" , References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 7 Oct 2012 17:10:59 -0400 Message-ID: <001701cda4d0$409d35d0$c1d7a170$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5o5eLuDRQ Content-Language: en-us Subject: Re: [Insipid] Handling (or not) of call transfer 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, 07 Oct 2012 21:10:59 -0000 Christer, > > I think that sentence is useful. Under some circumstances, the > > end-to-end session identifier might change. Under other > > circumstances, it might remain the same. In our proposal, it would > > always change if either endpoint in the session changes. However, > > there may be a workable solution where the change is not necessary; I > just don't know what solution that would be. > > I don't think the requirements should talk about your proposal :) It doesn't. I was only mentioning it as one where the end-to-end ID would always change whenever one endpoint is exchanged for another. Regardless of the solution, it might be necessary to change the ID. I think this consideration should not be ignored. > > I think that might be an example of where sessions might be "joined" > > together. Arguably, that's still a "transfer", but it is important to > > differentiate between cases where two existing calls are "spliced" > > together vs. a case where a call between A and B is transferred such > > that B drops out and a call between A and C exists. The latter might > > be via a REFER or it might not. In any case, we need to cover > > "transferred" calls and calls that are "joined" together. > > Of course, calls may also be joined together by the endpoints, ie there > is no intermediary doing it. This is true, but this bleeds into the "conferencing" scenarios. In that case, though, rather than having a conference on an MCU, the conference is local to the phone. > So, IF we decide to keep the requirement, can't it simply say that it > shall be possible to correlate multiple sessions? > > "REQ2: It must be possible to correlate multiple end-to-end > sessions." That loses the original intent. We want to ensure that we give consideration to what happens when calls are transferred or joined together. This is not the conferencing form of "joining" together, though. (I do wish we would still give consideration to conferencing, but I'm OK with ignoring those cases. In the case where a phone conferences three people together, those are two distinct SIP sessions. So, it would be logical to have two distinct session IDs. Correlating those would be nice, but I think we need to somehow reintroduce the conferencing requirement.) Paul From keith.drage@alcatel-lucent.com Sun Oct 7 15:20:23 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 9BE3721F86D1 for ; Sun, 7 Oct 2012 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.106 X-Spam-Level: X-Spam-Status: No, score=-110.106 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUmJqiBNrXPD for ; Sun, 7 Oct 2012 15:20:23 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9129D21F86B9 for ; Sun, 7 Oct 2012 15:20:21 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q97MK0n5027291 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 8 Oct 2012 00:20:01 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 8 Oct 2012 00:20:00 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Christer Holmberg'" , "insipid@ietf.org" Date: Mon, 8 Oct 2012 00:19:59 +0200 Thread-Topic: [Insipid] Handling (or not) of call transfer Thread-Index: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5o5eLuDRQgAAR/BA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> In-Reply-To: <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [Insipid] Handling (or not) of call transfer 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, 07 Oct 2012 22:20:23 -0000 But does this just come down to a requirement that it must be possible to a= llow session ID changes in what I, from my viewpoint (be it a proxy or an e= nd UE) still think is the same session (whatever we mean by that). If two existing calls are spliced at a B2BUA, then what causes that change = of session ID is outside the SIP world. Is the B2BUA allowed to force a cha= nge in the SIP world of session ID? Regards Keith > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: 07 October 2012 22:11 > To: 'Christer Holmberg'; DRAGE, Keith (Keith); insipid@ietf.org > Subject: RE: [Insipid] Handling (or not) of call transfer >=20 > Christer, >=20 > > > I think that sentence is useful. Under some circumstances, the > > > end-to-end session identifier might change. Under other > > > circumstances, it might remain the same. In our proposal, it would > > > always change if either endpoint in the session changes. However, > > > there may be a workable solution where the change is not necessary; I > > just don't know what solution that would be. > > > > I don't think the requirements should talk about your proposal :) >=20 > It doesn't. I was only mentioning it as one where the end-to-end ID would > always change whenever one endpoint is exchanged for another. Regardless > of > the solution, it might be necessary to change the ID. I think this > consideration should not be ignored. >=20 > > > I think that might be an example of where sessions might be "joined" > > > together. Arguably, that's still a "transfer", but it is important t= o > > > differentiate between cases where two existing calls are "spliced" > > > together vs. a case where a call between A and B is transferred such > > > that B drops out and a call between A and C exists. The latter might > > > be via a REFER or it might not. In any case, we need to cover > > > "transferred" calls and calls that are "joined" together. > > > > Of course, calls may also be joined together by the endpoints, ie there > > is no intermediary doing it. >=20 > This is true, but this bleeds into the "conferencing" scenarios. In that > case, though, rather than having a conference on an MCU, the conference i= s > local to the phone. >=20 > > So, IF we decide to keep the requirement, can't it simply say that it > > shall be possible to correlate multiple sessions? > > > > "REQ2: It must be possible to correlate multiple end-to-end > > sessions." >=20 > That loses the original intent. We want to ensure that we give > consideration to what happens when calls are transferred or joined > together. > This is not the conferencing form of "joining" together, though. (I do > wish > we would still give consideration to conferencing, but I'm OK with > ignoring > those cases. In the case where a phone conferences three people together= , > those are two distinct SIP sessions. So, it would be logical to have two > distinct session IDs. Correlating those would be nice, but I think we > need > to somehow reintroduce the conferencing requirement.) >=20 > Paul >=20 From pkyzivat@alum.mit.edu Sun Oct 7 16:58:18 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 2E19321F86F4 for ; Sun, 7 Oct 2012 16:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, 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 J3jiZNxxQIuD for ; Sun, 7 Oct 2012 16:58:17 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A2AD221F86EB for ; Sun, 7 Oct 2012 16:58:17 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id 8NTR1k0041ZXKqc55PyM4Z; Sun, 07 Oct 2012 23:58:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id 8PuN1k00g3ZTu2S3hPuNNk; Sun, 07 Oct 2012 23:54:22 +0000 Message-ID: <507215EB.80806@alum.mit.edu> Date: Sun, 07 Oct 2012 19:53:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "insipid@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Insipid] What session is the session ID for? 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, 07 Oct 2012 23:58:18 -0000 On the call the other day somebody (Keith?) was commenting that some use case was out of scope because the association between the "legs" was at the "application level". I would like to assert that any time we are talking about an entity that involves multiple dialogs connected by a B2BUA then we are talking about a construct that has been established at a level above SIP - what we call the "application level" For instance this is so when we have a PBX B2BUA that creates two call "legs" and associates them into one call. And it also happens when an SBC associates an incoming dialog with an outgoing dialog. What we *ought* to do is actually create a framework/architecture for such constructs built from multiple SIP dialogs, with proper terminology, definitions, etc. Then we would have a basis for defining things like this "session id". STRAW is also working in this space, and is a little closer to making such definitions, though it is still pretty fluffy. Such an activity is perhaps outside the current scope and aspirations of either INSIPID or STRAW. The question is whether those WGs can be successful without such work. Thanks, Paul From paulej@packetizer.com Sun Oct 7 18:12: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 83E5E21F8735 for ; Sun, 7 Oct 2012 18:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 2CMx9o5KVzMj for ; Sun, 7 Oct 2012 18:12:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF721F8710 for ; Sun, 7 Oct 2012 18:12:48 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q981CdLC023941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Oct 2012 21:12:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349658760; bh=9KgNxKpFHo9YqjdXa2+I8Y9NY2sQe+dJ+ZZLXdxNyrE=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QAw0SAPJ6adUXNBV+b/j4w7w82qSujMK2wkuLhl2TDf41vYiAsB5JtLqs/DOtf4mF +qsoN8OEVeQTzp4GOz9sG8xqt3LyK1tvOt3VAepmeHPNCL8xY1oVerllI7wqFFGAr0 baWAuaU5We1liMuc1xERzPRuSYdf0ORu0ztJ6670= From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , "'Christer Holmberg'" , References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> In-Reply-To: Date: Sun, 7 Oct 2012 21:12:45 -0400 Message-ID: <001f01cda4f2$0728d5d0$157a8170$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5owC0nRDEAsmsIZOXb/ejwA== Content-Language: en-us Subject: Re: [Insipid] Handling (or not) of call transfer 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, 08 Oct 2012 01:12:49 -0000 Keith, In many scenarios I've considered, there is a need to allow the Session-ID to change. For some calls, I cannot see how we can avoid it. The example I've used is this: Alice calls Bob. (Session-ID = "1") Carol calls Bob. (Session-ID = "2") Bob pushes a button on his phone and joins the call legs between Alice and Carol, dropping out of the call. In that case, we still want an end-to-end identifier. It might be "1", "2", or perhaps "3" ... but we need something both ends agree to. I've mentioned race condition examples in the past where, as an example, when Bob presses a button to merge Alice and Carol, Alice presses the same magic button to merge Bob and Sue (where Alice and Sue were previously talking). Now, Bob taking action to join call legs at the same time that Carol does means that the resulting call is between Sue and Carol. What would be Session-ID be then? With the solution we proposed, the answer is predictable. It would be S || C. Do we need more language than simply saying the call ID might change? I think so, because if we send a REFER message, we want to ensure that the endpoints behave as expected. We would want to correlate the new call with the previous one. We want that regardless of how the transfer or "join" takes place. Paul > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Sunday, October 07, 2012 6:20 PM > To: Paul E. Jones; 'Christer Holmberg'; insipid@ietf.org > Subject: RE: [Insipid] Handling (or not) of call transfer > > But does this just come down to a requirement that it must be possible > to allow session ID changes in what I, from my viewpoint (be it a proxy > or an end UE) still think is the same session (whatever we mean by that). > > If two existing calls are spliced at a B2BUA, then what causes that > change of session ID is outside the SIP world. Is the B2BUA allowed to > force a change in the SIP world of session ID? > > Regards > > Keith > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: 07 October 2012 22:11 > > To: 'Christer Holmberg'; DRAGE, Keith (Keith); insipid@ietf.org > > Subject: RE: [Insipid] Handling (or not) of call transfer > > > > Christer, > > > > > > I think that sentence is useful. Under some circumstances, the > > > > end-to-end session identifier might change. Under other > > > > circumstances, it might remain the same. In our proposal, it > > > > would always change if either endpoint in the session changes. > > > > However, there may be a workable solution where the change is not > > > > necessary; I > > > just don't know what solution that would be. > > > > > > I don't think the requirements should talk about your proposal :) > > > > It doesn't. I was only mentioning it as one where the end-to-end ID > > would always change whenever one endpoint is exchanged for another. > > Regardless of the solution, it might be necessary to change the ID. I > > think this consideration should not be ignored. > > > > > > I think that might be an example of where sessions might be > "joined" > > > > together. Arguably, that's still a "transfer", but it is > > > > important to differentiate between cases where two existing calls > are "spliced" > > > > together vs. a case where a call between A and B is transferred > > > > such that B drops out and a call between A and C exists. The > > > > latter might be via a REFER or it might not. In any case, we need > > > > to cover "transferred" calls and calls that are "joined" together. > > > > > > Of course, calls may also be joined together by the endpoints, ie > > > there is no intermediary doing it. > > > > This is true, but this bleeds into the "conferencing" scenarios. In > > that case, though, rather than having a conference on an MCU, the > > conference is local to the phone. > > > > > So, IF we decide to keep the requirement, can't it simply say that > > > it shall be possible to correlate multiple sessions? > > > > > > "REQ2: It must be possible to correlate multiple end-to-end > > > sessions." > > > > That loses the original intent. We want to ensure that we give > > consideration to what happens when calls are transferred or joined > > together. > > This is not the conferencing form of "joining" together, though. (I > > do wish we would still give consideration to conferencing, but I'm OK > > with ignoring those cases. In the case where a phone conferences > > three people together, those are two distinct SIP sessions. So, it > > would be logical to have two distinct session IDs. Correlating those > > would be nice, but I think we need to somehow reintroduce the > > conferencing requirement.) > > > > Paul > > From christer.holmberg@ericsson.com Sun Oct 7 23:37:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6324C21F86DC for ; Sun, 7 Oct 2012 23:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.136, 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 RKysUWFTZq3q for ; Sun, 7 Oct 2012 23:37:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A7D4521F869D for ; Sun, 7 Oct 2012 23:37:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-4f-507274aac1b4 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 60.D1.11467.AA472705; Mon, 8 Oct 2012 08:37:30 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 8 Oct 2012 08:37:30 +0200 From: Christer Holmberg To: "Paul E. Jones" , "'DRAGE, Keith (Keith)'" , "insipid@ietf.org" Date: Mon, 8 Oct 2012 08:37:29 +0200 Thread-Topic: [Insipid] Handling (or not) of call transfer Thread-Index: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5o5eLuDRQgACe8fA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> In-Reply-To: <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre6qkqIAgzVHtSzm33/GZPG08Syj xfkLG5gcmD1an+1l9Viy5CeTR8O+o+wBzFFcNimpOZllqUX6dglcGV+vCBdsEqv4d3EXcwPj Z8EuRk4OCQETif1vXzND2GISF+6tZ+ti5OIQEjjFKPF83k1GkISQwBxGiTO3WboYOTjYBCwk uv9pg9SICPQzSuyYOp8dpIZFQEWiZdsVVpAaYQFLiXVX0kHCIgJWEl+vzmeDsP0k5jw6C1bO KxAu0bbyCwvE+LtMEm0tYPWcArYSX1rfgsUZge75fmoNE4jNLCAucevJfCaIOwUkluw5D3Wz qMTLx/9YIepFJe60r2eEqNeRWLD7ExuErS2xbCHEj7wCghInZz5hmcAoOgvJ2FlIWmYhaZmF pGUBI8sqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzAmDm45bfuDsZT50QOMUpzsCiJ83Il7fcX EkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMjQWcNSd6F+vqsLs8aVEzxd11k9NHz61hg9TXr0 dfL6wIa9oZ3WlbZJ+ucthPODJxvLX3sT2dIvEO1Y927i2VelSgwbPbX3Cf63VsqPW1u7L2HH k+k/p7q6Pd1fMUl7+soMZdN/05zSuU26ltpcNo1y/xd4g3drxFmubHetkFliyRwLnz7KVmIp zkg01GIuKk4EAMtoglxnAgAA Subject: Re: [Insipid] Handling (or not) of call transfer 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, 08 Oct 2012 06:37:40 -0000 Hi, >>> I think that sentence is useful. Under some circumstances, the=20 >>> end-to-end session identifier might change. Under other=20 >>> circumstances, it might remain the same. In our proposal, it would=20 >>> always change if either endpoint in the session changes. However,=20 >>> there may be a workable solution where the change is not necessary;=20 >>> I just don't know what solution that would be. >> >> I don't think the requirements should talk about your proposal :) > > It doesn't. I was only mentioning it as one where the end-to-end ID would= always change whenever one endpoint is exchanged for another. Regardless = of the > solution, it might be necessary to change the ID. I think this considera= tion should not be ignored. Maybe not, but it's not a requirement. =20 >>> I think that might be an example of where sessions might be "joined" >>> together. Arguably, that's still a "transfer", but it is important=20 >>> to differentiate between cases where two existing calls are "spliced" >>> together vs. a case where a call between A and B is transferred such=20 >>> that B drops out and a call between A and C exists. The latter=20 >>> might be via a REFER or it might not. In any case, we need to cover=20 >>> "transferred" calls and calls that are "joined" together. >>=20 >> Of course, calls may also be joined together by the endpoints, ie=20 >> there is no intermediary doing it. > > This is true, but this bleeds into the "conferencing" scenarios. In that= case, though, rather than having a conference on an MCU, the conference is= local to the phone. >=20 >> So, IF we decide to keep the requirement, can't it simply say that it=20 >> shall be possible to correlate multiple sessions? >>=20 >> "REQ2: It must be possible to correlate multiple end-to-end sess= ions." > > That loses the original intent. We want to ensure that we give considera= tion to what happens when calls are transferred or joined together. > This is not the conferencing form of "joining" together, though. (I do w= ish we would still give consideration to conferencing, but I'm OK with igno= ring those cases. =20 > In the case where a phone conferences three people together, those are tw= o distinct SIP sessions. So, it would be logical to have two distinct sess= ion IDs. =20 Why? Someone may want to, for troubleshooting purpose, correlate these SIP = sessions. > Correlating those would be nice, but I think we need to somehow reintrodu= ce the conferencing requirement.) It is not about introducing a conferencing requirement. It's about whether = we need to put restrictions on what "correlation" means, or whether users c= an define that themselves - and e.g. use the session-id also to correlate s= essions associated with a conference. Regards, Christer From christer.holmberg@ericsson.com Mon Oct 8 00:09:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A2321F8772 for ; Mon, 8 Oct 2012 00:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=0.135, 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 yKXMMZ8XhVXG for ; Mon, 8 Oct 2012 00:09:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A075721F876F for ; Mon, 8 Oct 2012 00:09:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-91-50727c30f1a8 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 41.C6.11467.03C72705; Mon, 8 Oct 2012 09:09:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 8 Oct 2012 09:09:36 +0200 From: Christer Holmberg To: Paul Kyzivat , "insipid@ietf.org" Date: Mon, 8 Oct 2012 09:09:35 +0200 Thread-Topic: [Insipid] What session is the session ID for? Thread-Index: Ac2lIxZHvkj5Zb3ZRpmyQThiHpmG3g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD01A6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra5hTVGAwd6bAhbz7z9jslix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxfe8ppoL3QhU7WnczNjBO5O9i5OSQEDCR 6O+aywJhi0lcuLeerYuRi0NI4BSjxPoVu5ghnAWMEm/6nrF3MXJwsAlYSHT/0wZpEBEIlLh8 dAEbiM0ioCJx4nkj2CBhASuJ57+mMUHUWEvc63jPCmHrSRxbdg4szisQLvFj43FGEJsRaPH3 U2vA4swC4hK3nsxngjhIQGLJnvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4Wtm iPmCEidnPmGZwCg8C8nYWUhaZiFpmYWkZQEjyypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMCQ P7jlt+4OxlPnRA4xSnOwKInzciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAGLsv+8oR LxP5g+cCZy75KLk3J/DdM61Hb4wyxKWFv698Z59/6d7eeLaXr4xuHvmt8d395alOsV0atqE2 BuzrThne+HTfuiA9L+1b1wwlpS9x9iY324qZlR689l2au2n9NA1LryDfH+1KX8PuFQn4vpr7 TWbWXAHNVVklN7/LKfulhPPenCYuosRSnJFoqMVcVJwIANYkjJJHAgAA Subject: Re: [Insipid] What session is the session ID for? 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, 08 Oct 2012 07:09:40 -0000 Hi, When I read Paul K's e-mail, I start to think that this may once again turn= out in a never ending editorial exercise, which at the end brings very lit= tle good. In the beginning, the idea of session-id was very simply: an identifier bet= ween two endpoints, which B2BUAs are less likely to modify than the Call-Id= etc. Period. Then people start talking about transfer, later about 2-part values etc. Now, as far as transfer is concerned, I believe we already have a mechanism= to correlate transferred sessions: History-Info. Simply add the value of t= he original session as an embedded header field in History-Info, and you're= done. No need to be able to do the correlation based on the value itself, and pro= bably no need for a 2-part value. Simple :) Regards, Christer =20 -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 8. lokakuuta 2012 2:53 To: insipid@ietf.org Subject: [Insipid] What session is the session ID for? On the call the other day somebody (Keith?) was commenting that some use ca= se was out of scope because the association between the "legs" was at the "= application level". I would like to assert that any time we are talking about an entity that in= volves multiple dialogs connected by a B2BUA then we are talking about a co= nstruct that has been established at a level above SIP - what we call the "= application level" For instance this is so when we have a PBX B2BUA that creates two call "leg= s" and associates them into one call. And it also happens when an SBC assoc= iates an incoming dialog with an outgoing dialog. What we *ought* to do is actually create a framework/architecture for such = constructs built from multiple SIP dialogs, with proper terminology, defini= tions, etc. Then we would have a basis for defining things like this "sessi= on id". STRAW is also working in this space, and is a little closer to making such = definitions, though it is still pretty fluffy. Such an activity is perhaps outside the current scope and aspirations of ei= ther INSIPID or STRAW. The question is whether those WGs can be successful = without such work. Thanks, Paul _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Oct 8 02:56:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE8A21F86BD for ; Mon, 8 Oct 2012 02:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 Uz3H8gZxNrVo for ; Mon, 8 Oct 2012 02:56:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC721F858F for ; Mon, 8 Oct 2012 02:56:58 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q989ur0J010676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Oct 2012 05:56:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349690213; bh=jO7JBq/lN3+BKfs10+dmfC/QCF/JhRXw1j1CRQYeGao=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=XITcMM6OX6Eg1pN8B3oCIK+enWp20PBv8vLSs/l4W7L+Rnr4/pXIxfYx4r0mmFoJ+ 8vix1RtJrHrLb+b39mmdvka4gn3jIqBIZnrGhtjT/sh5WfFRyDMbKNNtXFbgL5df8J ZDOiQb1lvuhhDBAtrS8T1XMswRlq2O9pXNfFmt8Q= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'DRAGE, Keith \(Keith\)'" , References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 8 Oct 2012 05:57:00 -0400 Message-ID: <007901cda53b$4355ea90$ca01bfb0$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5owC0nRDEAaQYqW2Xecg9sA== Content-Language: en-us Subject: Re: [Insipid] Handling (or not) of call transfer 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, 08 Oct 2012 09:56:59 -0000 Christer, > >> I don't think the requirements should talk about your proposal :) > > > > It doesn't. I was only mentioning it as one where the end-to-end ID > > would always change whenever one endpoint is exchanged for another. > Regardless of the solution, it might be necessary to change the ID. I > think this consideration should not be ignored. > > Maybe not, but it's not a requirement. I'm struggling with this one. I can concede that changing the Session-ID is not, in and of itself, a requirement. However, I cannot see any other way to make these flows work without changing the Session-ID in some instances (my most recent call flow is one such example). So, how do we address that? Perhaps we should say that it is a requirement that endpoints accept changes to the Session-ID. If we do not make it a requirement, does that suggest it's a requirement that it stay fixed? > > That loses the original intent. We want to ensure that we give > consideration to what happens when calls are transferred or joined > together. > > This is not the conferencing form of "joining" together, though. (I > do wish we would still give consideration to conferencing, but I'm OK > with ignoring those cases. > > In the case where a phone conferences three people together, those are > two distinct SIP sessions. So, it would be logical to have two distinct > session IDs. > > Why? Someone may want to, for troubleshooting purpose, correlate these > SIP sessions. I agree, they might. To allow that to happen, we will have to do something along the lines of what we were proposing for the conference focus. When the phone bridges three users together, it would use the same UUID (using our proposed solution) for the two call legs. It could send a new INVITE down each side and inform endpoints of the change in the end-to-end Session-ID. I'm certainly OK with that, but folks wanted the conferencing requirements removed. > > Correlating those would be nice, but I think we need to somehow > > reintroduce the conferencing requirement.) > > It is not about introducing a conferencing requirement. It's about > whether we need to put restrictions on what "correlation" means, or > whether users can define that themselves - and e.g. use the session-id > also to correlate sessions associated with a conference. Without calling this a conference and speaking about it in those terms, I'm not sure how we would describe this. I'm open to suggestions :) Paul From paulej@packetizer.com Mon Oct 8 03: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 19D1521F866C for ; Mon, 8 Oct 2012 03:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] 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 kzNHQjZd6zR3 for ; Mon, 8 Oct 2012 03:19:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD6D21F85C0 for ; Mon, 8 Oct 2012 03:19:04 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q98AIx1J011601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Oct 2012 06:19:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349691540; bh=MapsLY9zoY3AnVOC1jNtM8B4X+nLI2zmw3CmtqkW5GA=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=jbQtHHWt/7BXzd6ZxJdLQmGWrpI+z+zlXGrM1bK5O8RiidGgtAjn0S/r9n+zTxBQI uIvjtN9hofNY1/9zlLUPupcC3qIjca5P2bP7WoHs0IZs7mmtggyV21LDFTXUrhQKrz EEV3Lmmnct/il8lgyGlgX86+DGHdrQXa+kiGurNk= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Paul Kyzivat'" , References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD01A6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD01A6@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 8 Oct 2012 06:19:07 -0400 Message-ID: <007c01cda53e$5a11e510$0e35af30$@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: AQIyKbznfkprcKYv/qZ94mKiy8jVEpbmJvzA Content-Language: en-us Subject: Re: [Insipid] What session is the session ID for? 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, 08 Oct 2012 10:19:05 -0000 Christer, >From the day we introduced our proposal, we've not added to the complexity at all. The two-part values are a very simple solution to the problem of identifying calls end-to-end through SIP and H.323 networks, through transfer scenarios, and call "joins" on a PBX. We can word-smith the requirements forever if we want, but I don't changes what we need to do. History-Info does not work since one end may not even know the call changed. As Hadriel mentioned, the SBC will often block a REFER. A call might be placed from A to B and B just happens to be 4 different endpoints due to forking. In our proposal, that would mean there are for Session-IDs (A||B1, A||B2, etc.). I'm still quite convinced that we need a solution like what we proposed, since everything else I've ever seen proposed fails in one way or another. I don't think the problem of identifying sessions end-to-end reliably is that challenging, though there are obviously some trade-offs with any solution. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Christer Holmberg > Sent: Monday, October 08, 2012 3:10 AM > To: Paul Kyzivat; insipid@ietf.org > Subject: Re: [Insipid] What session is the session ID for? > > Hi, > > When I read Paul K's e-mail, I start to think that this may once again > turn out in a never ending editorial exercise, which at the end brings > very little good. > > In the beginning, the idea of session-id was very simply: an identifier > between two endpoints, which B2BUAs are less likely to modify than the > Call-Id etc. Period. > > Then people start talking about transfer, later about 2-part values etc. > > Now, as far as transfer is concerned, I believe we already have a > mechanism to correlate transferred sessions: History-Info. Simply add > the value of the original session as an embedded header field in > History-Info, and you're done. > > No need to be able to do the correlation based on the value itself, and > probably no need for a 2-part value. > > Simple :) > > Regards, > > Christer > > > > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 8. lokakuuta 2012 2:53 > To: insipid@ietf.org > Subject: [Insipid] What session is the session ID for? > > On the call the other day somebody (Keith?) was commenting that some use > case was out of scope because the association between the "legs" was at > the "application level". > > I would like to assert that any time we are talking about an entity that > involves multiple dialogs connected by a B2BUA then we are talking about > a construct that has been established at a level above SIP - what we > call the "application level" > > For instance this is so when we have a PBX B2BUA that creates two call > "legs" and associates them into one call. And it also happens when an > SBC associates an incoming dialog with an outgoing dialog. > > What we *ought* to do is actually create a framework/architecture for > such constructs built from multiple SIP dialogs, with proper terminology, > definitions, etc. Then we would have a basis for defining things like > this "session id". > > STRAW is also working in this space, and is a little closer to making > such definitions, though it is still pretty fluffy. > > Such an activity is perhaps outside the current scope and aspirations of > either INSIPID or STRAW. The question is whether those WGs can be > successful without such work. > > Thanks, > Paul > _______________________________________________ > 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 salvatore.loreto@ericsson.com Mon Oct 8 03:48: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 A2EBF21F8540 for ; Mon, 8 Oct 2012 03:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 VeMGydgW-QUH for ; Mon, 8 Oct 2012 03:48:50 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6102421F853B for ; Mon, 8 Oct 2012 03:48:50 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-58-5072af91fa9f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 94.D0.11467.19FA2705; Mon, 8 Oct 2012 12:48:49 +0200 (CEST) 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, 8 Oct 2012 12:48:49 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CDB0D22F6 for ; Mon, 8 Oct 2012 13:48:48 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 26FC653956 for ; Mon, 8 Oct 2012 13:48:48 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CD08153327 for ; Mon, 8 Oct 2012 13:48:47 +0300 (EEST) Message-ID: <5072AF90.7030403@ericsson.com> Date: Mon, 8 Oct 2012 13:48:48 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> In-Reply-To: <007901cda53b$4355ea90$ca01bfb0$@packetizer.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+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvre7E9UUBBndfyFjMv/+MyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGYefTmUrWCRTMeftPvYGxiNiXYycHBICJhKN3SvYIWwxiQv3 1rOB2EICpxglfj0R7GLkArLXM0r0P93CBuFcYpS4N28LE4RzlFHi98NPLBDOXkaJnecngPXz CmhLXHx4kBHEZhFQkfjycg4ziM0mYCbx/OEWMFtUIFmid/5ORoh6QYmTM5+wgNgiAiISv+9O AbtJWMBS4texE8wQC64yS5yaDNHAKWArsen0NVYQmxnIvjDnOguELS+x/S3EMgkBNYmr5zYx QzykJdF7tpNpAqPILCT7ZiFpn4WkfQEj8ypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMAwP7jl t+4OxlPnRA4xSnOwKInzciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqFmUc2vKzT+n n3Otlj6Svu4iF0/foXVd23Wt9DyM9869zcJswvPLVXLqqd89F5d5eVusiPuieNnC0InvSJX0 Vq5HEgqmDzfXrzi3j8VyefOTCyuZucOCfBeoMOY+ZVt6hM/eX++AAm/IKuaOiXwia6yvqgv9 fbTKc+9PRYuO96x8SXzP2GJrlViKMxINtZiLihMB8wclvkECAAA= Subject: Re: [Insipid] Handling (or not) of call transfer 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, 08 Oct 2012 10:48:51 -0000 On 10/8/12 12:57 PM, Paul E. Jones wrote: > Christer, > >>>> I don't think the requirements should talk about your proposal :) >>> It doesn't. I was only mentioning it as one where the end-to-end ID >>> would always change whenever one endpoint is exchanged for another. >> Regardless of the solution, it might be necessary to change the ID. I >> think this consideration should not be ignored. >> >> Maybe not, but it's not a requirement. > I'm struggling with this one. I can concede that changing the Session-ID is > not, in and of itself, a requirement. However, I cannot see any other way > to make these flows work without changing the Session-ID in some instances > (my most recent call flow is one such example). So, how do we address that? > Perhaps we should say that it is a requirement that endpoints accept changes > to the Session-ID. If we do not make it a requirement, does that suggest > it's a requirement that it stay fixed? what about changing the last sentence of the REQ2 REQ2: It must be possible to correlate two end-to-end sessions when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX). This might result in a change in the value of the end-to-end Session-Identifier. with the following sentence (or an improved one): "This must be possible regardless of any eventual change in the value of the end-to-end Session-Identifier." in this way we provide the freedom for the solution, whatever it will be, to do whatever it has to do with the Session-Identifier. The important here is not the value of the Session-Identifier per se, but the fact that can successfully be used to correlate sessions! my two cents -- Salvatore Loreto, PhD www.sloreto.com > >>> That loses the original intent. We want to ensure that we give >> consideration to what happens when calls are transferred or joined >> together. >>> This is not the conferencing form of "joining" together, though. (I >> do wish we would still give consideration to conferencing, but I'm OK >> with ignoring those cases. >>> In the case where a phone conferences three people together, those are >> two distinct SIP sessions. So, it would be logical to have two distinct >> session IDs. >> >> Why? Someone may want to, for troubleshooting purpose, correlate these >> SIP sessions. > I agree, they might. To allow that to happen, we will have to do something > along the lines of what we were proposing for the conference focus. When > the phone bridges three users together, it would use the same UUID (using > our proposed solution) for the two call legs. It could send a new INVITE > down each side and inform endpoints of the change in the end-to-end > Session-ID. > > I'm certainly OK with that, but folks wanted the conferencing requirements > removed. > >>> Correlating those would be nice, but I think we need to somehow >>> reintroduce the conferencing requirement.) >> It is not about introducing a conferencing requirement. It's about >> whether we need to put restrictions on what "correlation" means, or >> whether users can define that themselves - and e.g. use the session-id >> also to correlate sessions associated with a conference. > Without calling this a conference and speaking about it in those terms, I'm > not sure how we would describe this. I'm open to suggestions :) > > Paul > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Oct 9 17:32:53 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0F1F0C6E for ; Tue, 9 Oct 2012 17:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 Ya+2wzW9hfl6 for ; Tue, 9 Oct 2012 17:32:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B3D631F0C4C for ; Tue, 9 Oct 2012 17:32:52 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9A0Wmmc010636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Oct 2012 20:32:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1349829169; bh=sVmS1s8b3mKRFYeRZ3ziFXCyNEPaIXYIY7jrA5nS29I=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TnKIVaiK1G0i6gH+MmK/8XFQ8nHbCxLtoAiUnRFmQuDJQbIkt5XCMUfCkoVIMvtY+ 7p3GFc5MepCsGNCg7GZ/svXDJcJhG7hw2pLOsFJSBTywQRu+TCdWKAT4HyY8X5PghP AUHTbo+2rbhhI/fJ3jeUUng7sXcHuxgyVStX3odU= From: "Paul E. Jones" To: "'Salvatore Loreto'" , References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> In-Reply-To: <5072AF90.7030403@ericsson.com> Date: Tue, 9 Oct 2012 20:32:59 -0400 Message-ID: <02d701cda67e$cd5ebac0$681c3040$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5owC0nRDEAaQYqW0BccWwGgIfe52gl1/GuoA= Content-Language: en-us Subject: Re: [Insipid] Handling (or not) of call transfer 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, 10 Oct 2012 00:32:53 -0000 Sal, > what about changing the last sentence of the REQ2 > > REQ2: It must be possible to correlate two end-to-end sessions when a > session is transferred or if two different sessions are joined > together via an intermediary (e.g., a PBX). This might result in a > change in the value of the end-to-end Session-Identifier. > > with the following sentence (or an improved one): > > "This must be possible regardless of any eventual change in the value of > the end-to-end Session-Identifier." > > in this way we provide the freedom for the solution, whatever it will be, > to do whatever it has to do with the Session-Identifier. > The important here is not the value of the Session-Identifier per se, > but the fact that can successfully be used to correlate sessions! Yeah, that would work. The intent with the original phrasing was to allow the door to be open on this one. I cannot see how we avoid changing the identifier in some signaling scenarios, but I'm certainly open to a proposal that might make it possible. I'm going to submit a revision of the draft with changes agreed to during the last call, but I'll exclude any changes to REQ2 right now. If there is agreement on this change, I can submit another revision again this week. Paul From internet-drafts@ietf.org Tue Oct 9 17:40:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD6911E80FC; Tue, 9 Oct 2012 17:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 HQ30LqD-nxg2; Tue, 9 Oct 2012 17:40:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4182C11E80EE; Tue, 9 Oct 2012 17:40:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010004058.23165.76937.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 17:40:58 -0700 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-reqts-02.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, 10 Oct 2012 00:40:59 -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-02.txt Pages : 10 Date : 2012-10-09 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-insipid-session-id-reqts-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paulej@packetizer.com Mon Oct 22 18:35:12 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8E61F0429 for ; Mon, 22 Oct 2012 18:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 03azRXJ5prqX for ; Mon, 22 Oct 2012 18:35:11 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31E1F0C72 for ; Mon, 22 Oct 2012 18:35:11 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9N1ZAY3011776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 21:35:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1350956110; bh=pFX3rFq48G55HrAtVX4CTKyWC0L6cnx3nS9+07zNQH8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=a2j1IlwMh7Fw/dhLPId4+HN8w3YpoKrKh2Hz0pE9jweEMCZxDo9ki3xLCPT5ome2v /AW5SRs9HDpkfJlRJZMow/fqv03DZnwDzG0RTJljD2rUSsmx7r9HcwI2CStzVltH4E X/BPgeq0vMxa4XL5PLCYrO6+NdGdVIpQFAddUXiI= From: "Paul E. Jones" To: References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> In-Reply-To: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 21:35:27 -0400 Message-ID: <031a01cdb0be$ae957e40$0bc07ac0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuZZlU3/Q Content-Language: en-us Subject: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 01:35:12 -0000 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 From gsalguei@cisco.com Tue Oct 23 21:03:28 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 02CB711E8115 for ; Tue, 23 Oct 2012 21:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 G21O-vMDlKQ0 for ; Tue, 23 Oct 2012 21:03:27 -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 712EF11E810B for ; Tue, 23 Oct 2012 21:03:27 -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 q9O43QF4026288 for ; Wed, 24 Oct 2012 00:03:26 -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 q9O43OCv028353; Wed, 24 Oct 2012 00:03:24 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Oct 2012 00:03:24 -0400 Message-Id: To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: insipid-chairs@tools.ietf.org Subject: [Insipid] Agenda for INSIPID WG meeting at IETF 85 (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: Wed, 24 Oct 2012 04:03:28 -0000 INSIPID WG -=20 The preliminary agenda for the INSIPID WG meeting at IETF 85 in Atlanta = is available here: http://www.ietf.org/proceedings/85/agenda/agenda-85-insipid Please note that the chairs are interested in having WG discussion = regarding actions to take relative to both of our milestones:=20 - Are we approaching WGLC for the requirements draft? - Is the WG ready to accept the text in the latest version of = the solution draft as a WG item? Feel free to bash and send feedback to the chairs = (insipid-chairs@ietf.org). Gonzalo & Keith (as co-chairs) From paulej@packetizer.com Wed Oct 24 22:54:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1633621F9053 for ; Wed, 24 Oct 2012 22:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 Ut+7nY59SSx0 for ; Wed, 24 Oct 2012 22:54:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 171F821F9052 for ; Wed, 24 Oct 2012 22:54:57 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9P5suNa002032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 25 Oct 2012 01:54:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351144497; bh=xsiAp4fmtaMNUw+CkiF6YO+it/Zy/Tvp/y2eo/Ta7mk=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=H76OeG9qBEDyeBbWbTTNTuslxoxBknT7UWFbDZwPCLETpW/QlIBZtqhYoyVLlNAjF k29Pv/+Wkh4sb4sTCUBVj3eNW4d8gsGiQ8Txg1fD2PHwpKsTsOgc0WR+ASdqubFais yFEXEdHxrMlHMHwXf98THEQk7FHoIlKo8illNeSk= From: "Paul E. Jones" To: Date: Thu, 25 Oct 2012 01:55:18 -0400 Message-ID: <05fa01cdb275$503d3a00$f0b7ae00$@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: Ac2ydKkEZZjmFxpHQu+QkyGyxAz/EA== Content-Language: en-us Subject: [Insipid] Reaching consensus on the 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: Thu, 25 Oct 2012 05:54:59 -0000 Folks, We need to reach consensus on the requirements. We've not had a lot of discussion on the list and I'd prefer to air issues before Atlanta. Below is the current list of requirements: REQ1: It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify those dialogs, transactions and messages which were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call). REQ2: It must be possible to correlate two end-to-end sessions when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a PBX). This might result in a change in the value of the end-to-end Session Identifier. Sal suggested changing the last sentence to read: "This must be possible regardless of any eventual change in the value of the end-to-end Session-Identifier" REQ4: It must be possible to pass the identifier unchanged through SIP B2BUAs or other intermediaries. REQ5: The identifier must not reveal any information related to any SIP user, device or domain identity. This includes any IP Address, port, hostname, domain name, username, Address-of-Record, MAC address, IP address family, transport type, subscriber ID, Call-ID, tags, or other SIP header or body parts. REQ7: It must be possible to identity SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling. REQ8: The identifier should be unique in time and space, similar to the Call-ID. REQ9a: The identifier should be constructed in such a way as to make it suitable for transmission in SIP and H.323. REQ9c: The identifier should be constructed in such a way as to make it suitable for transmission in SIP and RTCP. REQ10: It must be possible to correlate two end-to-end sessions when the sessions are created by a third party controller using 3PCC procedures shown in Figure 1 of RFC 3725. In an effort to help move things along, please raise any concerns with the wording of these or any requirement in general. Also, have a look over the current draft and provide any feedback you have. It is: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02 Paul From gonzalo.camarillo@ericsson.com Thu Oct 25 01:12:45 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 4B41521F89F2 for ; Thu, 25 Oct 2012 01:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqL905zl0ryL for ; Thu, 25 Oct 2012 01:12:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADCF21F89E8 for ; Thu, 25 Oct 2012 01:12:29 -0700 (PDT) X-AuditID: c1b4fb25-b7f956d0000011c3-55-5088f46cd880 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8A.E7.04547.C64F8805; Thu, 25 Oct 2012 10:12:28 +0200 (CEST) Received: from [131.160.126.249] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 25 Oct 2012 10:12:28 +0200 Message-ID: <5088F46B.8090302@ericsson.com> Date: Thu, 25 Oct 2012 11:12:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHJMWRmVeSWpSXmKPExsUyM+JvrW7Ol44Ag+ZPshbz7z9jcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsbp/YwFLewVh359YGxgPM3axcjJISFgIrF8/SFGCFtM4sK9 9WxdjFwcQgKnGCU2dN0EKxISWMso8adDCMTmFdCWmL6ziQnEZhFQlWi7sIoFxGYTsJDYcus+ mC0qECxxbuM2Noh6QYmTM5+AxUUERCR+353CDmILC1hLTF/5gB1isaTEm8k3wWqYBfQkplxt YYSw5SW2v53DDHGDtsTyZy0sExj5ZyEZOwtJyywkLQsYmVcxCucmZuaklxvppRZlJhcX5+fp FaduYgSG2cEtv1V3MN45J3KIUZqDRUmc13rrHn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jJOj/lRvOCBYE+neldD8U7quwHhhfdoD38Dewy6fM47ZzA5Y7xbHtO6p1RPRg60tdhtZthi/ Oaummyg9kenUrg/Oltxq/JV6k9PT976etVbPLHjLpIURK+SzpFvXuWadvf07a3ZE5PKWKXnb tCbFpBxhYgg9srXlpXT4xjWpaZYvZmWrs6icUmIpzkg01GIuKk4EADBkAScBAgAA Subject: [Insipid] Questions on draft-jones-insipid-session-id-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:12:45 -0000 Hi, a couple of quick questions on the following draft: http://www.ietf.org/id/draft-jones-insipid-session-id-01.txt The draft talks a few times about using a re-INVITE for call transfer. What does the re-INVITE exactly do? Does it change the target URI of the dialog, does it do something to the media streams? In Section 10.2, Alice calls Bob and they end up using a session ID value of A,B. Then, Bob transfers the call to Carol and Alice and Carol end up using a session ID value of A,C. Now, if we extend the call flow and have Alice transfer the call to David, Carol and David will end up using a session ID value of C,D, which has nothing to do with the original session ID value of A,B that created the communication session in the beginning. I just want to make sure this is the type of behavior people are after in a call transfer environment. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Oct 25 01:29: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 E40C421F8997 for ; Thu, 25 Oct 2012 01:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWTU5qyim3tf for ; Thu, 25 Oct 2012 01:29:37 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D68DA21F8992 for ; Thu, 25 Oct 2012 01:29:36 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-93-5088f86fbc7a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6A.6D.17130.F68F8805; Thu, 25 Oct 2012 10:29:35 +0200 (CEST) Received: from [131.160.126.249] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 25 Oct 2012 10:29:35 +0200 Message-ID: <5088F86F.9050104@ericsson.com> Date: Thu, 25 Oct 2012 11:29:35 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+JvrW7Bj44AgwmSFvPvP2NyYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG75NbGAtOCVQ8a5rF3MC4g7eLkZNDQsBEovvTI0YIW0ziwr31 bF2MXBxCAqcYJTZs/cAK4axllLh87zsTSBWvgLZE0/krYDaLgKrEjsO9YN1sAhYSW27dZwGx RQWCJc5t3MYGUS8ocXLmE7C4iICIxO+7U9i7GDk4hAXsJTbMNoZYLCnxZvJNsBJmAT2JKVdb GCFseYntb+cwg9hCQGuXP2thmcDIPwvJ1FlIWmYhaVnAyLyKUTg3MTMnvdxcL7UoM7m4OD9P rzh1EyMwyA5u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MG5ZXTFR+cHMJEHbqdcjX9Tw3LpSt//o/6+Hj+9rODxjddfSPekzbz6uOrMq/WqO4+UFLLXF 1h2L8hbG+VpKnF0qmLOUSS9YN+jRAvEPNXuOn3jt6LNt9+kM8+hZPktemK4p+xapodu6XI0/ 4fvanScyJku/NKpOOCXBbnUxuTMm12kJ+1RewSdKLMUZiYZazEXFiQDnipkqAAIAAA== Subject: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.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: Thu, 25 Oct 2012 08:29:38 -0000 Hi, a few quick comments on the following draft: http://www.ietf.org/id/draft-ietf-insipid-session-id-reqts-02.txt Section 3.1 talks about identifying each communication session "per transaction". I think that paragraph should be rephrased so that it is clearer what it means. With respect to defining a communication session, does a communication session always consist of one or more dialogs, or can there be a communication session without a dialog (e.g., a bunch of MESSAGE transactions)? The document needs to be clear on this. > REQ4: It must be possible to pass the identifier unchanged through > SIP B2BUAs or other intermediaries. This requirement is a bit strange since anything you carry in a SIP message *can* potentially be passed unchanged through any intermediary. A requirement about having a mechanism that does not disclose private information and that is not used for other purposes apart from session correlation so that intermediaries do not have incentives to remove it would make more sense. > REQ9c: The identifier should be constructed in such a way as to make > it suitable for transmission in SIP and RTCP [3]. There have been discussions about removing this type of requirement, since correlating media sessions and SIP sessions is well outside the charter of INSIPID. Note that the ability to correlate SIP sessions with media sessions is considered by some B2BUAs as a privacy concern. Those B2BUA will have an incentive to remove the header. I of course understand that the IETF cannot keep anyone from doing this if they want (given that syntax wise RTCP can carry a session identifier). That was discussed when this WG was chartered and that is the reason why some people in the community thought B2BUAs will remove whatever identifier is defined as soon as it starts being used for other purposes, regardless of what the specs say. In any case, the INSIPID documents should not try to explicitly address those types of use cases, per those discussions (which are documented in the DISPATCH archives). Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Oct 25 02:58: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 AD17921F89AA for ; Thu, 25 Oct 2012 02:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.22 X-Spam-Level: X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 gbjkyXLS7TpV for ; Thu, 25 Oct 2012 02:58:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E92321F89A9 for ; Thu, 25 Oct 2012 02:57:59 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd36d000007172-84-50890d2584b1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.C5.29042.52D09805; Thu, 25 Oct 2012 11:57:58 +0200 (CEST) Received: from [131.160.126.249] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 25 Oct 2012 11:57:57 +0200 Message-ID: <50890D25.9030206@ericsson.com> Date: Thu, 25 Oct 2012 12:57:57 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> In-Reply-To: <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra4ab2eAwZZlvBbz7z9jsjh/YQOT A5PHkiU/mTwa9h1lD2CK4rJJSc3JLEst0rdL4Mo4+fg1W8Fc4Yquf4uYGhhn8HcxcnJICJhI bPsxmwnCFpO4cG89WxcjF4eQwClGiQVLFjBDOGsZJRaf/cwMUsUroC3RdrsLrINFQFWie8IS RhCbTcBCYsut+ywgtqhAsMS5jdvYIOoFJU7OfAIWFwHqPXPtIdgcZoE4iV+9N1lBbGEBS4lf x05ALVvGIrFyyh6wZk4BW4lJR+ewQZwnKfFm8k0WiGY9iSlXWxghbHmJ7W/ngA0VAlqw/FkL ywRGoVlIds9C0jILScsCRuZVjMK5iZk56eWGeqlFmcnFxfl5esWpmxiBYXxwy2/dHYynzokc YpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbFg4XltJsFL2xcX+msp1Zw4 PGdBtIKlYNvaHTrTFv2uedbbrb19+rrQB5oif00DNkSHfnggbC1u7JDpfEPm/M3D4gyW0rER XisDbqyKfDpLW3NmnP8nrqbI+3FTj7K1fdZOnbj7YWj5f2v58MUPwhsuvnK+eObLlMA/Ctyy L09sXHL+VlL2jwlKLMUZiYZazEXFiQC5ZxzKMQIAAA== Cc: Salvatore Loreto , "insipid@ietf.org" Subject: Re: [Insipid] Handling (or not) of call transfer 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, 25 Oct 2012 09:58:01 -0000 Hi, this thread has discussed a requirement on being able to change the session ID but still correlate sessions. That is a second level of correlation you need to define very clearly in the requirements draft so that people understand what it means and can comment on it. If we assume that identifiers change but that there is a higher level of correlation that will know about the different identifiers being correlated, we are back into what we currently have with Call-IDs. A B2BUA that changes the Call-ID in a request knows that both Call-IDs are correlated even if they are different. The problem is that other elements do not know about that. By defining several levels of correlation we may very soon run into this type of problem. Of course, anyone who was involved in SPLICES will recognize that these are the same discussions we had in that WG. Cheers, Gonzalo On 10/10/2012 3:32 AM, Paul E. Jones wrote: > Sal, > >> what about changing the last sentence of the REQ2 >> >> REQ2: It must be possible to correlate two end-to-end sessions when a >> session is transferred or if two different sessions are joined >> together via an intermediary (e.g., a PBX). This might result in a >> change in the value of the end-to-end Session-Identifier. >> >> with the following sentence (or an improved one): >> >> "This must be possible regardless of any eventual change in the value of >> the end-to-end Session-Identifier." >> >> in this way we provide the freedom for the solution, whatever it will be, >> to do whatever it has to do with the Session-Identifier. >> The important here is not the value of the Session-Identifier per se, >> but the fact that can successfully be used to correlate sessions! > > Yeah, that would work. The intent with the original phrasing was to allow > the door to be open on this one. I cannot see how we avoid changing the > identifier in some signaling scenarios, but I'm certainly open to a proposal > that might make it possible. > > I'm going to submit a revision of the draft with changes agreed to during > the last call, but I'll exclude any changes to REQ2 right now. If there is > agreement on this change, I can submit another revision again this week. > > Paul > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > > From christer.holmberg@ericsson.com Thu Oct 25 05:53:15 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 E5FC421F8A18 for ; Thu, 25 Oct 2012 05:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 0ThBwyeR78qP for ; Thu, 25 Oct 2012 05:53:11 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B5CBA21F89FC for ; Thu, 25 Oct 2012 05:53:10 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-63-508936354efa Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7B.B4.26143.53639805; Thu, 25 Oct 2012 14:53:09 +0200 (CEST) Received: from ESESSHC017.ericsson.se (153.88.183.69) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 14:53:09 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 14:53:09 +0200 From: Christer Holmberg To: "'Paul E. Jones'" , "insipid@ietf.org" Thread-Topic: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF Thread-Index: AQHNsq+uf4JPM/plqESd18WSI2uF8Q== Date: Thu, 25 Oct 2012 12:53:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> In-Reply-To: <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvra6pWWeAwaQPmhbz7z9jsjh/YQOT A5PHkiU/mTwa9h1lD2CK4rJJSc3JLEst0rdL4Mo48m8uU8F59orD99cyNzD+Ye1i5OSQEDCR uLuxmxnCFpO4cG89WxcjF4eQwClGif65k1hAEkICOxkldp8WhrCXMErcP+zYxcjBwSZgIdH9 TxskLCIQJtG8bAc7iC0sECpx+9BlNph424+tLBC2nkTz3x1ge1kEVCUubLsHFucV8JZY976L GWJ8iUTflCtgvZwCthKtk36DxRmBbvt+ag0TiM0sIC5x68l8JoibBSSW7DkPdb+oxMvH/6D+ UpTYebadGaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5BOpFbYmWxRPYJzCKz0KyYhaS9llI2mch aV/AyLKKkT03MTMnvdxoEyMwcg5u+a26g/HOOZFDjNIcLErivNZb9/gLCaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYGTuEeCZGbRTQadZiP2itYnAy+r+V6b6535+FA5TvSuydO2N/AOi/bHJ KtxFFpe8BXZ3nqq3Osh/cYe65yN9ySan7RFcjyrmRjy5GX3Rhul80lOh5U2Fy7dOZWi2mLCE L0Rz750JfjtFnk1cLKdw4v6to+yVnqxPLXYues71krNr/0utD6tdTJRYijMSDbWYi4oTAe1X nhhqAgAA Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 25 Oct 2012 12:53:15 -0000 =20 Hi, One comment on the ABNF. First, I've had off-line discussions with the authors, where we in order to= be backward compatible with draft-kaplan agreed on the following things: 1. The ABNF will be backward compatible 2. Entities must be prepared to receive a value that does not contain a val= ue inserted by the remote peer ...so my comment is based on those assumptions. Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be optiona= l. I would suggest the following: Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI generic= -param) sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) In fact, I am not aware of any current implementations that use the generic= -param for anything, so we could even do the following: Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI generic-= param)] Regards, Christer From pkyzivat@alum.mit.edu Thu Oct 25 08:38: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 3B5F421F88B4 for ; Thu, 25 Oct 2012 08:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.062, 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 9WvZoZHPiTfB for ; Thu, 25 Oct 2012 08:38:18 -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 5208F21F88AE for ; Thu, 25 Oct 2012 08:38:17 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id FNsv1k0041ZXKqc53TeMrc; Thu, 25 Oct 2012 15:38:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id FTfU1k0143ZTu2S3hTfVlD; Thu, 25 Oct 2012 15:39:29 +0000 Message-ID: <50895CE6.4060903@alum.mit.edu> Date: Thu, 25 Oct 2012 11:38:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <5088F46B.8090302@ericsson.com> In-Reply-To: <5088F46B.8090302@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Questions on draft-jones-insipid-session-id-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:38:19 -0000 On 10/25/12 4:12 AM, Gonzalo Camarillo wrote: > Hi, > > a couple of quick questions on the following draft: > > http://www.ietf.org/id/draft-jones-insipid-session-id-01.txt > > The draft talks a few times about using a re-INVITE for call transfer. > What does the re-INVITE exactly do? Does it change the target URI of the > dialog, does it do something to the media streams? AFAIK this is referring to a 3pcc based transfer, where the initiator of the reINVITE is the 3pcc controller. Of course this begs the question of how the controller comes to know that a transfer is required. I think Cisco PBXs have a way to do this out of band. But it can also be achieved in a sip way by using a REFER based transfer that is handled in the 3pcc controller, using a reINVITE to the transferred party to map the existing dialog to the new party. Thanks, Paul > In Section 10.2, Alice calls Bob and they end up using a session ID > value of A,B. Then, Bob transfers the call to Carol and Alice and Carol > end up using a session ID value of A,C. Now, if we extend the call flow > and have Alice transfer the call to David, Carol and David will end up > using a session ID value of C,D, which has nothing to do with the > original session ID value of A,B that created the communication session > in the beginning. I just want to make sure this is the type of behavior > people are after in a call transfer environment. > > Cheers, > > Gonzalo > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From pkyzivat@alum.mit.edu Thu Oct 25 09:08:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAD921F89C6 for ; Thu, 25 Oct 2012 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, 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 NOp378hi66E4 for ; Thu, 25 Oct 2012 09:08:58 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6174621F89BB for ; Thu, 25 Oct 2012 09:08:58 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id FQcX1k00E0ldTLk55U92J0; Thu, 25 Oct 2012 16:09:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id FU8k1k00D3ZTu2S3QU8ku5; Thu, 25 Oct 2012 16:08:44 +0000 Message-ID: <50896417.5080400@alum.mit.edu> Date: Thu, 25 Oct 2012 12:08:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 25 Oct 2012 16:08:59 -0000 On 10/25/12 8:53 AM, Christer Holmberg wrote: > > Hi, > > One comment on the ABNF. > > First, I've had off-line discussions with the authors, where we in order to be backward compatible with draft-kaplan agreed on the following things: > > 1. The ABNF will be backward compatible > 2. Entities must be prepared to receive a value that does not contain a value inserted by the remote peer > > ...so my comment is based on those assumptions. > > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be optional. I would suggest the following: > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI generic-param) > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > > In fact, I am not aware of any current implementations that use the generic-param for anything, so we could even do the following: > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI generic-param)] IMO it is bad practice to require a specific ordering among params. So I would prefer: Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] sess-id-param = rcvr-uuid / generic-param sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] rcvr-uuid = "rcvr" EQUAL sess-id Another thing: the above only permits lower case hex. For consistency with common usage both lower and upper case should be permitted. This can be done by: sess-id = 32 HEXDIG (from 5234, used in 3261) And is there any reason to require leading zeros in the sess-id? If not, that can be specified via sess-id = 1*32 HEXDIG or maybe sess-id = 1*16 (HEXDIG HEXDIG) Or does backward compatibility require restricting to lower case and exactly 32 digits? Thanks, Paul From christer.holmberg@ericsson.com Thu Oct 25 09: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 61CC021F8782 for ; Thu, 25 Oct 2012 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.114, 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 e-57qW6Ly34N for ; Thu, 25 Oct 2012 09:25:31 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 283FE21F875A for ; Thu, 25 Oct 2012 09:25:30 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-d7-508967f9423b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 84.45.26143.9F769805; Thu, 25 Oct 2012 18:25:29 +0200 (CEST) Received: from ESESSHC008.ericsson.se (153.88.183.42) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 25 Oct 2012 18:25:29 +0200 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.001; Thu, 25 Oct 2012 18:25:29 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "insipid@ietf.org" Thread-Topic: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF Thread-Index: AQHNsq+6EiukJJs0p028SEDizxu5bJfKDymAgAAkVeA= Date: Thu, 25 Oct 2012 16:25:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B01E8A6@ESESSMB209.ericsson.se> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> In-Reply-To: <50896417.5080400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre7P9M4AgydzLSzm33/GZLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujcUErW8EJoYrWI6+ZGhgX8HUxcnJICJhI PH9ylR3CFpO4cG89WxcjF4eQwClGiVVP5kI5Oxkl3i6dygZSJSSwhFHi4W3vLkYODjYBC4nu f9ogYRGBYIktP94zgdjCAqEStw9dZoOIh0m0/djKAmFbSdxogljGIqAq8fnYQmYQm1fAW+Lo 1t3MELtuMErMnvccrJlTQEfi9+INYA2MQNd9P7UGbAGzgLjErSfzmSCuFpBYsuc8M4QtKvHy 8T9WCFtRYufZdmaIeh2JBbs/sUHY2hLLFr6GWiwocXLmExaIv7QlWhZPYJ/AKD4LyYpZSNpn IWmfhaR9ASPLKkb23MTMnPRyo02MwOg5uOW36g7GO+dEDjFKc7AoifNab93jLySQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFR53tgpk9lQU+o/kWWFeoRjtumTVk24eLOP2qXluewh7kd8pwb r7w3XNzN9bMH49lN1itM5wXuP579o1Mh7dRBW/9Ppz4dCC/qu6UVJ/GkPvH+QedPN2Ulapbx 79efs3Ch6oSlXVoPN5X1s7zPKmTXbZWZJmYf/056tqU5y0Vvo4manNzXu08rsRRnJBpqMRcV JwIAxZd/+mwCAAA= Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 25 Oct 2012 16:25:32 -0000 Hi,=20 >> One comment on the ABNF. >> >> First, I've had off-line discussions with the authors, where we in order= to be backward compatible with draft-kaplan agreed on the following things= : >> >> 1. The ABNF will be backward compatible 2. Entities must be prepared=20 >> to receive a value that does not contain a value inserted by the=20 >> remote peer >> >> ...so my comment is based on those assumptions. >> >> >> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be opti= onal. I would suggest the following: >> >> Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI=20 >> generic-param) >> >> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >> >> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) >> >> >> In fact, I am not aware of any current implementations that use the gene= ric-param for anything, so we could even do the following: >> >> Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI=20 >> generic-param)] > > IMO it is bad practice to require a specific ordering among params. So I = would prefer: > > Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > sess-id-param =3D rcvr-uuid / generic-param > > sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid =3D "rcvr" EQUAL sess-id ...or, we could simply remove generic-param. As I said earlier, I am not aw= are of any existing deployments using it for anything. > Another thing: the above only permits lower case hex. For consistency wit= h common usage both lower and upper case should be permitted. This can be d= one by: > > sess-id =3D 32 HEXDIG (from 5234, used in 3261) > > And is there any reason to require leading zeros in the sess-id? If not, = that can be specified via > > sess-id =3D 1*32 HEXDIG > or maybe > sess-id =3D 1*16 (HEXDIG HEXDIG) > > Or does backward compatibility require restricting to lower case and exac= tly 32 digits? Lower case and exactly 32 digits. "Session-ID =3D "Session-ID" HCOLON sess-id=20 *( SEMI generic-param )=20 sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f]=20 =20 NOTE: The sess-id value is technically case-INSENSITIVE, but note=20 that only lower-case characters are allowed." Regards, Christer From pkyzivat@alum.mit.edu Thu Oct 25 10:03: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 DC07121F89AF for ; Thu, 25 Oct 2012 10:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, 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 hJCm-GLGDDXW for ; Thu, 25 Oct 2012 10:03:49 -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 2B0DF21F89AC for ; Thu, 25 Oct 2012 10:03:49 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id FNxd1k00516LCl053V3tiG; Thu, 25 Oct 2012 17:03:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id FV3M1k00u3ZTu2S3SV3Mrh; Thu, 25 Oct 2012 17:03:21 +0000 Message-ID: <508970F2.50206@alum.mit.edu> Date: Thu, 25 Oct 2012 13:03:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B01E8A6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01E8A6@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 25 Oct 2012 17:03:50 -0000 On 10/25/12 12:25 PM, Christer Holmberg wrote: > > Hi, > >>> One comment on the ABNF. >>> >>> First, I've had off-line discussions with the authors, where we in order to be backward compatible with draft-kaplan agreed on the following things: >>> >>> 1. The ABNF will be backward compatible 2. Entities must be prepared >>> to receive a value that does not contain a value inserted by the >>> remote peer >>> >>> ...so my comment is based on those assumptions. >>> >>> >>> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be optional. I would suggest the following: >>> >>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI >>> generic-param) >>> >>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>> >>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) >>> >>> >>> In fact, I am not aware of any current implementations that use the generic-param for anything, so we could even do the following: >>> >>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI >>> generic-param)] >> >> IMO it is bad practice to require a specific ordering among params. So I would prefer: >> >> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] >> >> sess-id-param = rcvr-uuid / generic-param >> >> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >> >> rcvr-uuid = "rcvr" EQUAL sess-id > > ...or, we could simply remove generic-param. As I said earlier, I am not aware of any existing deployments using it for anything. IMO the reason for it is not because existing deployments use it, but rather is "future proofing" - providing for future extensions. >> Another thing: the above only permits lower case hex. For consistency with common usage both lower and upper case should be permitted. This can be done by: >> >> sess-id = 32 HEXDIG (from 5234, used in 3261) >> >> And is there any reason to require leading zeros in the sess-id? If not, that can be specified via >> >> sess-id = 1*32 HEXDIG >> or maybe >> sess-id = 1*16 (HEXDIG HEXDIG) >> >> Or does backward compatibility require restricting to lower case and exactly 32 digits? > > Lower case and exactly 32 digits. > > "Session-ID = "Session-ID" HCOLON sess-id > *( SEMI generic-param ) > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > NOTE: The sess-id value is technically case-INSENSITIVE, but note > that only lower-case characters are allowed." I have no idea what that note means. I don't like this, but could live with it if it is really needed for backward compatibility. Thanks, Paul From jmpolk@cisco.com Thu Oct 25 17:45:35 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214FE21F8862 for ; Thu, 25 Oct 2012 17:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Pka8O4TJplNc for ; Thu, 25 Oct 2012 17:45:32 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 902F621F869B for ; Thu, 25 Oct 2012 17:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4325; q=dns/txt; s=iport; t=1351212332; x=1352421932; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=PEKILDDy8JQ+FIoSxred+JTfu6mHRH1hSjM/azw4FXg=; b=YwzGz7Yo+k41ndJed0s0KBS7YxsUJ285ygqe/HJtHXTnFsC0V96pr8I+ A3i1wNxL5UmbAJl2nn5G886zO0GV9Bg0AzCrX1tU67CMjJW29mZBNlWsJ wTjXG8NUQ5YGN2dqROMJ/bEAB8/vD22JPd1PLqQ9ChtJlir0vtCxTQDh9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALfciVCtJV2b/2dsb2JhbAA6CgHAMYIDgQiCHgEBAQQBAQEPASUCLgYXBAcVBAEBAR4JBxkOHwkIBgoJCRIHh2ILnWGgHIthEIZdA4hcjjGKGYMigWuDDQ X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="135548426" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 26 Oct 2012 00:45:31 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9Q0jV0I019641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Oct 2012 00:45:31 GMT Message-Id: <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Oct 2012 19:45:29 -0500 To: From: James Polk In-Reply-To: <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: [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: Fri, 26 Oct 2012 00:45:35 -0000 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 From paulej@packetizer.com Thu Oct 25 22:40:26 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3121F8608 for ; Thu, 25 Oct 2012 22:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 uQmhSRMMTk4B for ; Thu, 25 Oct 2012 22:40:25 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4021F85E7 for ; Thu, 25 Oct 2012 22:40:25 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9Q5eIYE000445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 01:40:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351230019; bh=ZQQU/XYm5DQ+ABqAEDs0p2ShzsTXRDrKt5e6Q+FEJxs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=iYbC0A3mBzPfNVyrAIZjGUCNTF4CjvN/Vtql2GaglxS97iBB/m8T4M9XRsVZJbv/5 1t4+ImZ4K9AqDd+88fLbDqrbD69FOXFCRDkyTh3lDHvmuUvaX9ECyShE/zqYsY36mv N9DeTjeGv+uf9Ef9CGbs9oNbf2rYfsUTTrl+1Pu8= From: "Paul E. Jones" To: "'Gonzalo Camarillo'" , References: <5088F86F.9050104@ericsson.com> In-Reply-To: <5088F86F.9050104@ericsson.com> Date: Fri, 26 Oct 2012 01:40:42 -0400 Message-ID: <074401cdb33c$70c37600$524a6200$@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: AQKZbZgN23jzvno3rjTPIQU9SQi70pYzl1tQ Content-Language: en-us Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 05:40:26 -0000 Gonzalo, > a few quick comments on the following draft: > > http://www.ietf.org/id/draft-ietf-insipid-session-id-reqts-02.txt > > Section 3.1 talks about identifying each communication session "per > transaction". I think that paragraph should be rephrased so that it is > clearer what it means. Should we just remove "per transaction"? Cleaning up the text, we would have: For SIP messaging that either does not involve SIP servers or only involves SIP proxies, the Call-ID header value sufficiently identifies each SIP message within a transaction or dialog. This is not the case when either B2BUAs or SBCs are in the signaling path between UAs. Therefore, we need the ability to identify each communication session through a single SIP header-value regardless of which type of SIP servers are in the signaling path between UAs. For transactions that create a dialog, each message within the same dialog MUST use the same identifier. > With respect to defining a communication session, does a communication > session always consist of one or more dialogs, or can there be a > communication session without a dialog (e.g., a bunch of MESSAGE > transactions)? The document needs to be clear on this. REQ1 intends to require a solution for transactions and lengthier dialogs. The issues is defining a "communication session", which is a challenge since even "session" is vaguely defined. I welcome any suggested wording, perhaps something in section 2? > > REQ4: It must be possible to pass the identifier unchanged through > > SIP B2BUAs or other intermediaries. > > This requirement is a bit strange since anything you carry in a SIP > message *can* potentially be passed unchanged through any intermediary. > A requirement about having a mechanism that does not disclose private > information and that is not used for other purposes apart from session > correlation so that intermediaries do not have incentives to remove it > would make more sense. We have requirements on privacy. The real intent of REQ4 is that it will be an identifier that intermediaries MUST NOT change. However, the problem is that this requirements document is for the solution. The solution must specify the requirement that intermediaries not change it. Perhaps this: The solution must require that the identifier pass unchanged through SIP B2BUAs or other intermediaries"? > > REQ9c: The identifier should be constructed in such a way as to > make > > it suitable for transmission in SIP and RTCP [3]. > > There have been discussions about removing this type of requirement, > since correlating media sessions and SIP sessions is well outside the > charter of INSIPID. Note that the ability to correlate SIP sessions with > media sessions is considered by some B2BUAs as a privacy concern. Those > B2BUA will have an incentive to remove the header. > > I of course understand that the IETF cannot keep anyone from doing this > if they want (given that syntax wise RTCP can carry a session > identifier). That was discussed when this WG was chartered and that is > the reason why some people in the community thought B2BUAs will remove > whatever identifier is defined as soon as it starts being used for other > purposes, regardless of what the specs say. In any case, the INSIPID > documents should not try to explicitly address those types of use cases, > per those discussions (which are documented in the DISPATCH archives). The requirement is not for correlation, but that it must be possible to transport the identifier in RTCP. We want to allow it to be used for correlation since it's useful for diagnostics, quality of service, etc. to be able to correlate media flows with SIP sessions. We agree that any such correlation specification or other use in RTCP is outside the scope, but we don't want this identifier to be something that is totally unsuitable for transport in RTCP. Paul From paulej@packetizer.com Thu Oct 25 22:49:43 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 E49F121F8498 for ; Thu, 25 Oct 2012 22:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 ARtKVTR9GvCI for ; Thu, 25 Oct 2012 22:49:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0458B21F8431 for ; Thu, 25 Oct 2012 22:49:41 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9Q5ndRX000837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 01:49:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351230579; bh=Wo2lzGX/G//DGcpj5ys4Zr4tc6MgV0YuVYJwkN36JZQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QdFL3zW8MQdai6w8J6PPX16u+enVGnqmjiWWwHrA7Zbh1Ur5PLXkj6CYocr8i0GnA Gdo92dgC5d9UDtAsgSHlCk4Rvf6LzCFObfff5lXcm83Z3W6nZoAUt6/FVFlStHwBqa V0uGh5q78cgg42KQzgJKR4ghr5HmfFSndVWk3Eqo= From: "Paul E. Jones" To: "'Gonzalo Camarillo'" References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> <50890D25.9030206@ericsson.com> In-Reply-To: <50890D25.9030206@ericsson.com> Date: Fri, 26 Oct 2012 01:50:03 -0400 Message-ID: <074601cdb33d$becf8360$3c6e8a20$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5owC0nRDEAaQYqW0BccWwGgIfe52gAWcUoLwCIwtb8pdc8u2g Content-Language: en-us Cc: 'Salvatore Loreto' , insipid@ietf.org Subject: Re: [Insipid] Handling (or not) of call transfer 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, 26 Oct 2012 05:49:43 -0000 Gonzalo, This is REQ2 in the requirements document. Use case is in 3.6. How a transferred call is correlated would be defined by the solution. The requirement is merely that it must be possible. We're not even concerned necessarily with how the calls correlate, but merely that they are. With the solution we've proposed, Alice would have some identifier A that should would use for the life of a communication session -- from the time she sends an INVITE to the time she sends or receives the final BYE. That is, when the "call is over" as far as the human is concerned. No matter how many times she is transferred, she continues to use A in signaling. This allows for correlation. There is no higher-level correlation than that. Paul > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Thursday, October 25, 2012 5:58 AM > To: Paul E. Jones > Cc: Salvatore Loreto; insipid@ietf.org > Subject: Re: [Insipid] Handling (or not) of call transfer > > Hi, > > this thread has discussed a requirement on being able to change the > session ID but still correlate sessions. That is a second level of > correlation you need to define very clearly in the requirements draft so > that people understand what it means and can comment on it. > > If we assume that identifiers change but that there is a higher level of > correlation that will know about the different identifiers being > correlated, we are back into what we currently have with Call-IDs. A > B2BUA that changes the Call-ID in a request knows that both Call-IDs are > correlated even if they are different. The problem is that other > elements do not know about that. By defining several levels of > correlation we may very soon run into this type of problem. > > Of course, anyone who was involved in SPLICES will recognize that these > are the same discussions we had in that WG. > > Cheers, > > Gonzalo > > > On 10/10/2012 3:32 AM, Paul E. Jones wrote: > > Sal, > > > >> what about changing the last sentence of the REQ2 > >> > >> REQ2: It must be possible to correlate two end-to-end sessions > when a > >> session is transferred or if two different sessions are joined > >> together via an intermediary (e.g., a PBX). This might result in > a > >> change in the value of the end-to-end Session-Identifier. > >> > >> with the following sentence (or an improved one): > >> > >> "This must be possible regardless of any eventual change in the value > >> of the end-to-end Session-Identifier." > >> > >> in this way we provide the freedom for the solution, whatever it will > >> be, to do whatever it has to do with the Session-Identifier. > >> The important here is not the value of the Session-Identifier per se, > >> but the fact that can successfully be used to correlate sessions! > > > > Yeah, that would work. The intent with the original phrasing was to > > allow the door to be open on this one. I cannot see how we avoid > > changing the identifier in some signaling scenarios, but I'm certainly > > open to a proposal that might make it possible. > > > > I'm going to submit a revision of the draft with changes agreed to > > during the last call, but I'll exclude any changes to REQ2 right now. > > If there is agreement on this change, I can submit another revision > again this week. > > > > Paul > > > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > > > From paulej@packetizer.com Thu Oct 25 22:58:56 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7971F21F863F for ; Thu, 25 Oct 2012 22:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 BAtLVLI3OSig for ; Thu, 25 Oct 2012 22:58:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 673E921F84C7 for ; Thu, 25 Oct 2012 22:58:54 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9Q5wpcR001193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 01:58:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351231132; bh=LreFredGIpR2ZnCg+O79jgihX+Nweg9aA8051llvzOY=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=s/TZeTDLdpgKudv5ApIfPHXiqOPrxFvxsQEuVs3sNDnI0RZuhnfQOVOgnIKOQ97NT 3NgMbGHoR92B2xYs4sq6a8QnyTC4Z2sdWWRUIgLJFYt7KgKHmlUsHd86uw9qFbLRMF AQ6o0ja5bjYtxjuEkB2+jgFPd9hAmRLjBkKCk7Ns= From: "Paul E. Jones" To: "'Christer Holmberg'" , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> Date: Fri, 26 Oct 2012 01:59:15 -0400 Message-ID: <074801cdb33f$07ef5790$17ce06b0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOaWRsi/kA== Content-Language: en-us Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 05:58:56 -0000 Christer, I'm not sure what #2 is below. We do want to try to achieve compatibility in terms of syntax, thus the changes in syntax seen in this document. I might be in agreement with #2 if I understood it :) If you mean that Alice might send 'A' and then Alice might receive 'A' back, that is certainly an backward-compatibility case we want to allow. Was that the meaning? We do want to require the present solution to not do that, though, as that effectively breaks the end-to-end identification in certain cases. Also, we want to require the present solution to always include "rcvr-uuid". We'll have to state that in prose since the ABNF cannot be flexible enough to accommodate that. And, we must allow for it to be absent on the initial INVITE, too, since Alice would not have a value to include... unless we make it all zeros or something. Here's the modified ABNF (just the firt production): Session-ID = "Session-ID" HCOLON sess-id *1( SEMI rcvr-uuid ) *( SEMI generic-param ) Paul > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, October 25, 2012 8:53 AM > To: 'Paul E. Jones'; insipid@ietf.org > Subject: RE: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF > > > Hi, > > One comment on the ABNF. > > First, I've had off-line discussions with the authors, where we in order > to be backward compatible with draft-kaplan agreed on the following > things: > > 1. The ABNF will be backward compatible > 2. Entities must be prepared to receive a value that does not contain a > value inserted by the remote peer > > ...so my comment is based on those assumptions. > > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be > optional. I would suggest the following: > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI > generic-param) > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > > In fact, I am not aware of any current implementations that use the > generic-param for anything, so we could even do the following: > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI > generic-param)] > > > Regards, > > Christer From paulej@packetizer.com Thu Oct 25 23:11: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 179E321F84A6 for ; Thu, 25 Oct 2012 23:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 CZITQmwvSrOv for ; Thu, 25 Oct 2012 23:11:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEFF21F85AF for ; Thu, 25 Oct 2012 23:11:51 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9Q6BnkG001729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 02:11:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351231909; bh=WMznycetgETg3GR84L38DvDNwZOPdriSSYK/xIFDtOU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Vv2fnTar2hca4dctWSwo+yaZW3TmCQ34DBmwKWogzwdBnKggo7UY7Brv6VjkR3qNE jnDGwHCqunS8CSQ8GRHPXpvlDDJvcpA1cULgMFZ4aFTEfoV1NQWx0e6fT2enZwQCNV YN7CfCCfyO7QnniLmpmghArUl6zl/d7rvJNiCMuA= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> In-Reply-To: <50896417.5080400@alum.mit.edu> Date: Fri, 26 Oct 2012 02:12:13 -0400 Message-ID: <074c01cdb340$d79cd1b0$86d67510$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfZY5rE3Q Content-Language: en-us Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 06:11:52 -0000 Paul, OK... I now have this: Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] sess-id-param = rcvr-uuid / generic-param sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) I could change the hex digits, but that would not be compatible with the Kaplan draft. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, October 25, 2012 12:09 PM > To: insipid@ietf.org > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF > > On 10/25/12 8:53 AM, Christer Holmberg wrote: > > > > Hi, > > > > One comment on the ABNF. > > > > First, I've had off-line discussions with the authors, where we in > order to be backward compatible with draft-kaplan agreed on the > following things: > > > > 1. The ABNF will be backward compatible 2. Entities must be prepared > > to receive a value that does not contain a value inserted by the > > remote peer > > > > ...so my comment is based on those assumptions. > > > > > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be > optional. I would suggest the following: > > > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI > > generic-param) > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > > > > > In fact, I am not aware of any current implementations that use the > generic-param for anything, so we could even do the following: > > > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI > > generic-param)] > > IMO it is bad practice to require a specific ordering among params. So I > would prefer: > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > sess-id-param = rcvr-uuid / generic-param > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid = "rcvr" EQUAL sess-id > > Another thing: the above only permits lower case hex. For consistency > with common usage both lower and upper case should be permitted. This > can be done by: > > sess-id = 32 HEXDIG (from 5234, used in 3261) > > And is there any reason to require leading zeros in the sess-id? If not, > that can be specified via > > sess-id = 1*32 HEXDIG > or maybe > sess-id = 1*16 (HEXDIG HEXDIG) > > Or does backward compatibility require restricting to lower case and > exactly 32 digits? > > Thanks, > Paul > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Thu Oct 25 23:16: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 466D721F84CA for ; Thu, 25 Oct 2012 23:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 X9op92xYnje6 for ; Thu, 25 Oct 2012 23:16:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36821F85AF for ; Thu, 25 Oct 2012 23:16:47 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9Q6Gijd001929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 02:16:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351232204; bh=8nd9WVHxST6fdtpnkVTWEiQylVaJ+J/MeIPM8erTig4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=gcpS9IqP2z2ZrllP5LUMTVQeI+qgHrLzdQHxw9sIGN+VWGBMmnRtqC/Wn+YX+RwVm jdKVi05i8UhgzCb+qk8yMfNV5qkNyM9PtLc/FUZD/ptrLfctYeLzehdTdTarL9NMEH 1Kv0fhNFovz2K6UKY5bxXYvwSKWfqpfgnJQasJfU= From: "Paul E. Jones" To: "'Gonzalo Camarillo'" , References: <5088F46B.8090302@ericsson.com> In-Reply-To: <5088F46B.8090302@ericsson.com> Date: Fri, 26 Oct 2012 02:17:08 -0400 Message-ID: <074e01cdb341$87754c70$965fe550$@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: AQIZv/kPNb2EvfgnuP05b90x8gwn+ZczAdXQ Content-Language: en-us Subject: Re: [Insipid] Questions on draft-jones-insipid-session-id-01.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 06:16:48 -0000 Gonzalo, > a couple of quick questions on the following draft: > > http://www.ietf.org/id/draft-jones-insipid-session-id-01.txt > > The draft talks a few times about using a re-INVITE for call transfer. > What does the re-INVITE exactly do? Does it change the target URI of the > dialog, does it do something to the media streams? This might be done via proprietary signaling or via REFER, as Paul K. mentioned. > In Section 10.2, Alice calls Bob and they end up using a session ID > value of A,B. Then, Bob transfers the call to Carol and Alice and Carol > end up using a session ID value of A,C. Now, if we extend the call flow > and have Alice transfer the call to David, Carol and David will end up > using a session ID value of C,D, which has nothing to do with the > original session ID value of A,B that created the communication session > in the beginning. I just want to make sure this is the type of behavior > people are after in a call transfer environment. This is the type of behavior I was seeking. This allows us to have a unique end-to-end session identifier. It also allows us to look at log files and see these transitions occur, even if we looked at no specific signaling. It also allows us to correlate these kinds of changes when they occur between protocols like H.323 and SIP. Note also that on any transfer, a transferred-to device might actually be many devices (e.g., David's desk phone, mobile phone, tablet, etc.) So, we might actually see a series of identifier pairs {C,D1}, {C, D2}, {C, D3}, ... as the call is forked. In the end, only one survives, of course, but all of this would be captured in logs. Paul From paulej@packetizer.com Thu Oct 25 23:25: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 EB5F021F85C0 for ; Thu, 25 Oct 2012 23:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 oqEl51c7Iuv2 for ; Thu, 25 Oct 2012 23:25:51 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3505C21F843F for ; Thu, 25 Oct 2012 23:25:51 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9Q6PlK3002294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 02:25:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351232748; bh=kQzhIO9zzbuBKjEfiVJvk+MBZGhi4k5CoekqSoac9E4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CMOSGTxpAP3+nC/Oy+SaIIKDOLhHgSzjCzGihBZ3X8KhVMK1u6SYXht6y+4Q6dFht eL8cpuK6k9cqu0Se8dAnCAgxxZikn5Pmhvicxzgm3hOnHZDYgyaxxM92S7hzbHx5M6 M9E6vUzIIYRuApjsOqMI5B04Aklw8FgvSG5fxkN4= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Paul Kyzivat'" , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B01E8A6@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B01E8A6@ESESSMB209.ericsson.se> Date: Fri, 26 Oct 2012 02:26:11 -0400 Message-ID: <075201cdb342$cb5dd4b0$62197e10$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfQFjMtn2li6VNcA= Content-Language: en-us Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 06:25:52 -0000 Christer, > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > > > sess-id-param = rcvr-uuid / generic-param > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > rcvr-uuid = "rcvr" EQUAL sess-id > > ...or, we could simply remove generic-param. As I said earlier, I am not > aware of any existing deployments using it for anything. Sorry, I missed that in the first message. Are you sure it is safe? If so, I'm happy to remove it. > Lower case and exactly 32 digits. > > "Session-ID = "Session-ID" HCOLON sess-id > *( SEMI generic-param ) > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > NOTE: The sess-id value is technically case-INSENSITIVE, but note > that only lower-case characters are allowed." > This wording seems odd. I think we just have to say concretely that the sess-id and rcvr-uuid is case sensitive, if we say anything. Do we need to say something? Paul From R.Jesske@telekom.de Fri Oct 26 01:52:56 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6A21F850A for ; Fri, 26 Oct 2012 01:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 tfH7kZ4STcEy for ; Fri, 26 Oct 2012 01:52:55 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 073B921F84F6 for ; Fri, 26 Oct 2012 01:52:54 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 26 Oct 2012 10:52:19 +0200 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 26 Oct 2012 10:51:53 +0200 From: To: , , Date: Fri, 26 Oct 2012 10:51:52 +0200 Thread-Topic: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF Thread-Index: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfZY5rE3QgAAsqoA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AD15658D@HE111648.emea1.cds.t-internal.com> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> In-Reply-To: <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 08:52:56 -0000 Hi Paul, looks for me OK and is inline with that what we have currently implemented = in our network. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] Im Auftrag von Paul E. Jones > Gesendet: Freitag, 26. Oktober 2012 08:12 > An: 'Paul Kyzivat'; insipid@ietf.org > Betreff: Re: [Insipid] FW: I-D Action: > draft-jones-insipid-session-id-01.txt - ABNF > > Paul, > > OK... I now have this: > > Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > sess-id-param =3D rcvr-uuid / generic-param > > sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) > > I could change the hex digits, but that would not be > compatible with the Kaplan draft. > > Paul > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, October 25, 2012 12:09 PM > > To: insipid@ietf.org > > Subject: Re: [Insipid] FW: I-D Action: > draft-jones-insipid-session-id- > > 01.txt - ABNF > > > > On 10/25/12 8:53 AM, Christer Holmberg wrote: > > > > > > Hi, > > > > > > One comment on the ABNF. > > > > > > First, I've had off-line discussions with the authors, where we in > > order to be backward compatible with draft-kaplan agreed on the > > following things: > > > > > > 1. The ABNF will be backward compatible 2. Entities must > be prepared > > > to receive a value that does not contain a value inserted by the > > > remote peer > > > > > > ...so my comment is based on those assumptions. > > > > > > > > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid > needs to be > > optional. I would suggest the following: > > > > > > Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI > > > generic-param) > > > > > > sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > > > rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) > > > > > > > > > In fact, I am not aware of any current implementations > that use the > > generic-param for anything, so we could even do the following: > > > > > > Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI > > > generic-param)] > > > > IMO it is bad practice to require a specific ordering among > params. So > > I would prefer: > > > > Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > > > sess-id-param =3D rcvr-uuid / generic-param > > > > sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > rcvr-uuid =3D "rcvr" EQUAL sess-id > > > > Another thing: the above only permits lower case hex. For > consistency > > with common usage both lower and upper case should be > permitted. This > > can be done by: > > > > sess-id =3D 32 HEXDIG (from 5234, used in 3261) > > > > And is there any reason to require leading zeros in the sess-id? If > > not, that can be specified via > > > > sess-id =3D 1*32 HEXDIG > > or maybe > > sess-id =3D 1*16 (HEXDIG HEXDIG) > > > > Or does backward compatibility require restricting to lower > case and > > exactly 32 digits? > > > > Thanks, > > Paul > > > > > > > > _______________________________________________ > > 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 pkyzivat@alum.mit.edu Fri Oct 26 09:59:16 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CCB21F856F for ; Fri, 26 Oct 2012 09:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, 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 ikr9ktptNUZ6 for ; Fri, 26 Oct 2012 09:59:15 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 8926A21F8559 for ; Fri, 26 Oct 2012 09:59:15 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id Fpb11k00316LCl051szKaw; Fri, 26 Oct 2012 16:59:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id Fsyn1k00P3ZTu2S3SsynBd; Fri, 26 Oct 2012 16:58:47 +0000 Message-ID: <508AC161.7050304@alum.mit.edu> Date: Fri, 26 Oct 2012 12:59:13 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <5088F86F.9050104@ericsson.com> <074401cdb33c$70c37600$524a6200$@packetizer.com> In-Reply-To: <074401cdb33c$70c37600$524a6200$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:59:16 -0000 On 10/26/12 1:40 AM, Paul E. Jones wrote: > Gonzalo, > >> a few quick comments on the following draft: >> >> http://www.ietf.org/id/draft-ietf-insipid-session-id-reqts-02.txt >> >> Section 3.1 talks about identifying each communication session "per >> transaction". I think that paragraph should be rephrased so that it is >> clearer what it means. > > Should we just remove "per transaction"? Cleaning up the text, we would > have: > > For SIP messaging that either does not involve SIP servers > or only involves SIP proxies, the Call-ID header value > sufficiently identifies each SIP message within a > transaction or dialog. This is not the case when either > B2BUAs or SBCs are in the signaling path between UAs. > Therefore, we need the ability to identify each > communication session through a single SIP header-value > regardless of which type of SIP servers are in the signaling > path between UAs. For transactions that create a dialog, > each message within the same dialog MUST use the same > identifier. > > >> With respect to defining a communication session, does a communication >> session always consist of one or more dialogs, or can there be a >> communication session without a dialog (e.g., a bunch of MESSAGE >> transactions)? The document needs to be clear on this. > > REQ1 intends to require a solution for transactions and lengthier dialogs. > The issues is defining a "communication session", which is a challenge since > even "session" is vaguely defined. I welcome any suggested wording, perhaps > something in section 2? If there is an expectation that this mechanism should work for correlating the "legs" of a single message/response sent outside a dialog as it traverses B2BUAs, then *something* needs to be said about it. I raised early on the problem of inadequate terminology. And I think we still have it. I just did a search of 3261, and "communication session" is not defined there, and is used only once. So perhaps it is an available term that has no established definition in the sip context. That leaves the need to adequately define what it means. This is tied up with the scope of this work. We want the new ID to correlate 1:1 with certain kinds of things, and so presumably we want "communication session" to be a name for those kinds of things. But using "communication session" brings with it the baggage of "session". I think it is hard to make a definition of "communcation session" that doesn't relate in a clear and obvious way to the notion of "session" used in SIP. In particular, I find it difficult to use "communication session" to characterize a MESSAGE and its response that happen to traverse an SBC. OTOH, I can imagine coming up with *some* term to describe a set of related messages that are tightly coupled by B2BUAs. (But no good name for this comes to mind.) If we were to define that, then that can be applied to dialog establishing messages and used to extend the concept to related dialogs. IMO this is really coming in the back door at the task of defining a whole new architectural layer on top of existing sip concepts, made up of SIP UAs connected in specific ways. (This is exactly what Hadriel has made a non-goal in STRAW.) Thanks, Paul From pkyzivat@alum.mit.edu Fri Oct 26 10:20: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 99D1B21F85AF for ; Fri, 26 Oct 2012 10:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, 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 mUmICT-yT8FZ for ; Fri, 26 Oct 2012 10:20:26 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 8A04921F8575 for ; Fri, 26 Oct 2012 10:20:26 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id FrYi1k0020vyq2s5BtLWMX; Fri, 26 Oct 2012 17:20:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id FtLt1k0073ZTu2S3RtLted; Fri, 26 Oct 2012 17:20:53 +0000 Message-ID: <508AC658.4000901@alum.mit.edu> Date: Fri, 26 Oct 2012 13:20:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> In-Reply-To: <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 17:20:27 -0000 On 10/26/12 2:12 AM, Paul E. Jones wrote: > Paul, > > OK... I now have this: > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > sess-id-param = rcvr-uuid / generic-param > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) OK, now I'm moving to the esthetics of ABNF writing. None of the following changes what may be validly written. 1) the name of the header field is "Session-ID", so I would expect that a non-terminal in the syntax called would describe be the fundamental thing. But in the above it isn't. It is *half* of the ID of a communication session. (Except in the compatibility cases.) 2) I really dislike when specialized piece of syntax is repeated in two places rather than being defined once and referenced twice. Doing so suggests that any resemblance between the two is incidental rather than fundamental. In this case the syntax for and the value part of are fundamentally the same. In my prior proposals I addressed (2), but not (1). Here is a proposal that addresses them both: Session-ID = "Session-ID" HCOLON endpt-id *[SEMI sess-id-param] endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] sess-id-param = rcvr-id / generic-param rcvr-id = "rcvr" EQUAL endpt-id The above does not explicitly state that can appear at most once. That is a general rule for header field parameters. It could be specified in text for emphasis. Thanks, Paul K > I could change the hex digits, but that would not be compatible with the > Kaplan draft. > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, October 25, 2012 12:09 PM >> To: insipid@ietf.org >> Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- >> 01.txt - ABNF >> >> On 10/25/12 8:53 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> One comment on the ABNF. >>> >>> First, I've had off-line discussions with the authors, where we in >> order to be backward compatible with draft-kaplan agreed on the >> following things: >>> >>> 1. The ABNF will be backward compatible 2. Entities must be prepared >>> to receive a value that does not contain a value inserted by the >>> remote peer >>> >>> ...so my comment is based on those assumptions. >>> >>> >>> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to be >> optional. I would suggest the following: >>> >>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI >>> generic-param) >>> >>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>> >>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) >>> >>> >>> In fact, I am not aware of any current implementations that use the >> generic-param for anything, so we could even do the following: >>> >>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI >>> generic-param)] >> >> IMO it is bad practice to require a specific ordering among params. So I >> would prefer: >> >> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] >> >> sess-id-param = rcvr-uuid / generic-param >> >> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >> >> rcvr-uuid = "rcvr" EQUAL sess-id >> >> Another thing: the above only permits lower case hex. For consistency >> with common usage both lower and upper case should be permitted. This >> can be done by: >> >> sess-id = 32 HEXDIG (from 5234, used in 3261) >> >> And is there any reason to require leading zeros in the sess-id? If not, >> that can be specified via >> >> sess-id = 1*32 HEXDIG >> or maybe >> sess-id = 1*16 (HEXDIG HEXDIG) >> >> Or does backward compatibility require restricting to lower case and >> exactly 32 digits? >> >> Thanks, >> Paul >> >> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > From paulej@packetizer.com Fri Oct 26 13:33:56 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227A321F859E for ; Fri, 26 Oct 2012 13:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 wJ0wEu7iEkBj for ; Fri, 26 Oct 2012 13:33:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86721F84DF for ; Fri, 26 Oct 2012 13:33:55 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9QKXrdi007569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 16:33:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351283634; bh=giExyWSp7Gjin+RXCg/LKcSzJ62MZg5k9cgwGvGLtL0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Dvgal6ZzH2o9AzT02t1QnROxUulGdsSRTgzI7SFtA5l8YIebh2K66QUW8q8YG3Sbi k1j5lau6aNu8sHbnzJFiGP86fVrrkx6QeEZz1j14CJqFPZ5TlPrqoSoeocPGbaMRtj nvXODAFm/fYlTPyvQOXvhr4iIpxcfgnvFUwsFvw4= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> In-Reply-To: <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> Date: Fri, 26 Oct 2012 16:34:18 -0400 Message-ID: <080001cdb3b9$4651a590$d2f4f0b0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfQLUOGOKliP6TZA= Content-Language: en-us Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 20:33:56 -0000 Guys, Coming back to the syntax. I think the below syntax (including the generic-param) is best. We don't have a defined use for generic-param, but we might find a use for it one day. We should not lock ourselves out of extensibility. So, I have: Session-ID = "Session-ID" HCOLON sess-id [SEMI sess-id-param] sess-id-param = rcvr-uuid / generic-param sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Friday, October 26, 2012 2:12 AM > To: 'Paul Kyzivat'; insipid@ietf.org > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF > > Paul, > > OK... I now have this: > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > sess-id-param = rcvr-uuid / generic-param > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > I could change the hex digits, but that would not be compatible with the > Kaplan draft. > > Paul > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: Thursday, October 25, 2012 12:09 PM > > To: insipid@ietf.org > > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > > 01.txt - ABNF > > > > On 10/25/12 8:53 AM, Christer Holmberg wrote: > > > > > > Hi, > > > > > > One comment on the ABNF. > > > > > > First, I've had off-line discussions with the authors, where we in > > order to be backward compatible with draft-kaplan agreed on the > > following things: > > > > > > 1. The ABNF will be backward compatible 2. Entities must be prepared > > > to receive a value that does not contain a value inserted by the > > > remote peer > > > > > > ...so my comment is based on those assumptions. > > > > > > > > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to > be > > optional. I would suggest the following: > > > > > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI > > > generic-param) > > > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > > > > > > > > In fact, I am not aware of any current implementations that use the > > generic-param for anything, so we could even do the following: > > > > > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI > > > generic-param)] > > > > IMO it is bad practice to require a specific ordering among params. So > > I would prefer: > > > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > > > sess-id-param = rcvr-uuid / generic-param > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > rcvr-uuid = "rcvr" EQUAL sess-id > > > > Another thing: the above only permits lower case hex. For consistency > > with common usage both lower and upper case should be permitted. This > > can be done by: > > > > sess-id = 32 HEXDIG (from 5234, used in 3261) > > > > And is there any reason to require leading zeros in the sess-id? If > > not, that can be specified via > > > > sess-id = 1*32 HEXDIG > > or maybe > > sess-id = 1*16 (HEXDIG HEXDIG) > > > > Or does backward compatibility require restricting to lower case and > > exactly 32 digits? > > > > Thanks, > > Paul > > > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Fri Oct 26 13:57:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A9A21F85AF for ; Fri, 26 Oct 2012 13:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 bNr3JHQTC3uq for ; Fri, 26 Oct 2012 13:57:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 278D721F84EC for ; Fri, 26 Oct 2012 13:57:37 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9QKvZBF008598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 16:57:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351285056; bh=e+dla1xnAQRiRo7eofmI6jEvAuCQvZQ3bWomlaGZGj0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=B17uWczxipH8VkcFDSGx52rJ3zE6hV5ZoQd3/SxPH+Wo0vmEqcEFVOC5fIVon0vYw lPcJQ/uTQ3WqQAJ3uMAVGxyi3geCPSkFmV+wgCfQjE3PK9dY0yEpwdI5E4ASbphpT+ upQfnmR4WLS2bC43G+Z+d7oX0VQFxFxgx3hd8WgU= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <080001cdb3b9$4651a590$d2f4f0b0$@packetizer.com> In-Reply-To: <080001cdb3b9$4651a590$d2f4f0b0$@packetizer.com> Date: Fri, 26 Oct 2012 16:58:00 -0400 Message-ID: <080f01cdb3bc$95e46810$c1ad3830$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfQLUOGOKAnj1DSqWEDiiYA== Content-Language: en-us Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 20:57:38 -0000 Oops... not right. This allows for only one optional parameter. Also, there was a desire to allow any order and we need to ensure How about this: Session-ID = "Session-ID" HCOLON sess-id [sess-id-params] sess-id-params = *(SEMI generic-param) SEMI rcvr-uuid *(SEMI generic-param) sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) We'll add prose that says: The Session-ID header MUST NOT have more than one "rcvr" parameter. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Friday, October 26, 2012 4:34 PM > To: 'Paul Kyzivat'; insipid@ietf.org > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF > > Guys, > > Coming back to the syntax. I think the below syntax (including the > generic-param) is best. We don't have a defined use for generic-param, > but we might find a use for it one day. We should not lock ourselves > out of extensibility. > > So, I have: > > Session-ID = "Session-ID" HCOLON sess-id [SEMI sess-id-param] > > sess-id-param = rcvr-uuid / generic-param > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > Paul > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Paul E. Jones > > Sent: Friday, October 26, 2012 2:12 AM > > To: 'Paul Kyzivat'; insipid@ietf.org > > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > > 01.txt - ABNF > > > > Paul, > > > > OK... I now have this: > > > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > > > sess-id-param = rcvr-uuid / generic-param > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > > > I could change the hex digits, but that would not be compatible with > > the Kaplan draft. > > > > Paul > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: Thursday, October 25, 2012 12:09 PM > > > To: insipid@ietf.org > > > Subject: Re: [Insipid] FW: I-D Action: > > > draft-jones-insipid-session-id- 01.txt - ABNF > > > > > > On 10/25/12 8:53 AM, Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > One comment on the ABNF. > > > > > > > > First, I've had off-line discussions with the authors, where we in > > > order to be backward compatible with draft-kaplan agreed on the > > > following things: > > > > > > > > 1. The ABNF will be backward compatible 2. Entities must be > > > > prepared to receive a value that does not contain a value inserted > > > > by the remote peer > > > > > > > > ...so my comment is based on those assumptions. > > > > > > > > > > > > Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to > > be > > > optional. I would suggest the following: > > > > > > > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] > *(SEMI > > > > generic-param) > > > > > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > > > > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > > > > > > > > > > > In fact, I am not aware of any current implementations that use > > > > the > > > generic-param for anything, so we could even do the following: > > > > > > > > Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid > *(SEMI > > > > generic-param)] > > > > > > IMO it is bad practice to require a specific ordering among params. > > > So I would prefer: > > > > > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > > > > > sess-id-param = rcvr-uuid / generic-param > > > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > > > rcvr-uuid = "rcvr" EQUAL sess-id > > > > > > Another thing: the above only permits lower case hex. For > > > consistency with common usage both lower and upper case should be > > > permitted. This can be done by: > > > > > > sess-id = 32 HEXDIG (from 5234, used in 3261) > > > > > > And is there any reason to require leading zeros in the sess-id? If > > > not, that can be specified via > > > > > > sess-id = 1*32 HEXDIG > > > or maybe > > > sess-id = 1*16 (HEXDIG HEXDIG) > > > > > > Or does backward compatibility require restricting to lower case and > > > exactly 32 digits? > > > > > > Thanks, > > > Paul > > > > > > > > > > > > _______________________________________________ > > > 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 pkyzivat@alum.mit.edu Fri Oct 26 14:38:44 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 748B521F8669 for ; Fri, 26 Oct 2012 14:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, 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 lSUiCPjYfpDY for ; Fri, 26 Oct 2012 14:38:43 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7421F865C for ; Fri, 26 Oct 2012 14:38:43 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta08.westchester.pa.mail.comcast.net with comcast id FtUt1k0010cZkys58xencz; Fri, 26 Oct 2012 21:38:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Fxeg1k00U3ZTu2S3WxegBs; Fri, 26 Oct 2012 21:38:40 +0000 Message-ID: <508B02E0.3090500@alum.mit.edu> Date: Fri, 26 Oct 2012 17:38:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> In-Reply-To: <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Fri, 26 Oct 2012 21:38:44 -0000 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? 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. 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. 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. 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} ??? 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 > From paulej@packetizer.com Fri Oct 26 14:52:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9579B21F8671 for ; Fri, 26 Oct 2012 14:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 2w98q8LPqjS5 for ; Fri, 26 Oct 2012 14:52:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id B54D821F866D for ; Fri, 26 Oct 2012 14:52:37 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9QLqZaJ010960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 17:52:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351288356; bh=KhNHhhcGbJJJu39OXZ3+QAcsqPn5935vOO9HwF7At8A=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JfDqP94ZAHqLgaqgf2AcQxpdaaqRqFNl9/YjU/zVmT/Wlj7D+jpIEcHVtTqoKwawr lTwinyguk6QDdPuCFhcpe2QEGrejdB9pb0ektGwQg/7EoLROEzwCRV4k5aBxZchX6x BuEcct+fzmVfnBQO5qQ9XB21dGYe47J+5vXc+AZ8= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <5088F86F.9050104@ericsson.com> <074401cdb33c$70c37600$524a6200$@packetizer.com> <508AC161.7050304@alum.mit.edu> In-Reply-To: <508AC161.7050304@alum.mit.edu> Date: Fri, 26 Oct 2012 17:53:00 -0400 Message-ID: <081401cdb3c4$450379b0$cf0a6d10$@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: AQKZbZgN23jzvno3rjTPIQU9SQi70gKm9zPJAYQ9qJGWE1CMIA== Content-Language: en-us Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:52:38 -0000 Paul, > > REQ1 intends to require a solution for transactions and lengthier > dialogs. > > The issues is defining a "communication session", which is a challenge > > since even "session" is vaguely defined. I welcome any suggested > > wording, perhaps something in section 2? > > If there is an expectation that this mechanism should work for > correlating the "legs" of a single message/response sent outside a > dialog as it traverses B2BUAs, then *something* needs to be said about > it. If Alice calls Bob, Alice will allocate a Session-ID UUID value that will traverse through any number of B2BUAs, regardless of how many "legs" that might be. I think that should be clear. What may not be so clear is what we do with things like Subscribe/Notify. Even to me, that's not as clear. I think that was intended to be covered by the REQ1 text. If that isn't sufficiently addresses, I invite some re-wording. > I raised early on the problem of inadequate terminology. And I think we > still have it. I just did a search of 3261, and "communication session" > is not defined there, and is used only once. So perhaps it is an > available term that has no established definition in the sip context. But I'm not sure we should be defining it. If we drop "communication" from the language, does that help? Communication is what this is all about. It's more or less an adjective that might be superfluous. A Session is a phone call, conference call, etc. Communication session is the same: phone call, conference call, etc. Any two entities communicating would be a communication session. > That leaves the need to adequately define what it means. This is tied up > with the scope of this work. We want the new ID to correlate 1:1 with > certain kinds of things, and so presumably we want "communication > session" to be a name for those kinds of things. I'm not hung up on that word. But, I do think you can point to a phone call and say "that's a phone call between Alice and Bob". If it's between them and not part of a conference, then there would be a Session-ID representing that two-party phone call. > But using "communication session" brings with it the baggage of > "session". :-) The whole subject of 3261. > I think it is hard to make a definition of "communcation > session" that doesn't relate in a clear and obvious way to the notion of > "session" used in SIP. In particular, I find it difficult to use > "communication session" to characterize a MESSAGE and its response that > happen to traverse an SBC. OTOH, I can imagine coming up with *some* > term to describe a set of related messages that are tightly coupled by > B2BUAs. (But no good name for this comes to mind.) If we were to define > that, then that can be applied to dialog establishing messages and used > to extend the concept to related dialogs. Yeah, it it was just a MESSAGE out of the blue, one might argue it's not a communication session. But, what is it? The remote side will reply. If it's part of an ongoing phone call, then it's part of that "communication session". If it has no relationship with an ongoing phone call, then what is that exchange and do we want a Session-ID applied to it? For that, I don't care. Others seem to want it. > IMO this is really coming in the back door at the task of defining a > whole new architectural layer on top of existing sip concepts, made up > of SIP UAs connected in specific ways. (This is exactly what Hadriel has > made a non-goal in STRAW.) And today SIP is 16 years, 247 days old... Paul From paulej@packetizer.com Fri Oct 26 14:58: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 95C7D21F866D for ; Fri, 26 Oct 2012 14:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 jB70bdCGgKiT for ; Fri, 26 Oct 2012 14:58:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 94C5721F864A for ; Fri, 26 Oct 2012 14:58:10 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9QLw7Is011223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 17:58:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351288687; bh=rSzN/cKETAgLAzzzK8TmSF7OaHLD4jxZCsEmehYO9m8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=C/QbC/BfmhyeyUGFZI2TYnjs1tQMkZcavB9kP/x/UUIQxsiAjEGsQyCuUcaGfhnUx bpvUsbw/udXMAvDU4WGqH0ToFN3GPsV3hCvp4K/bPgj1vaqfaBr2T+/tHPEJsNNqGq MCcqWWGDIBI7pI2APdE3nd6aogsGYtpvj2WFLp4w= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <508AC658.4000901@alum.mit.edu> In-Reply-To: <508AC658.4000901@alum.mit.edu> Date: Fri, 26 Oct 2012 17:58:32 -0400 Message-ID: <081601cdb3c5$0aa028d0$1fe07a70$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfQLUOGOKAn6bPO6WEB38YA== Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 21:58:11 -0000 Paul, Merging what you propose and my changes from an hour or so earlier, how is this: Session-ID = "Session-ID" HCOLON endpt-id [sess-id-params] endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] sess-id-params = *(SEMI generic-param) SEMI rcvr-uuid *(SEMI generic-param) rcvr-uuid = "rcvr" EQUAL endpt-id Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 26, 2012 1:20 PM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF > > On 10/26/12 2:12 AM, Paul E. Jones wrote: > > Paul, > > > > OK... I now have this: > > > > Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > > > > sess-id-param = rcvr-uuid / generic-param > > > > sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > > OK, now I'm moving to the esthetics of ABNF writing. None of the > following changes what may be validly written. > > 1) the name of the header field is "Session-ID", so I would expect that > a non-terminal in the syntax called would describe be the > fundamental thing. But in the above it isn't. It is *half* of the ID of > a communication session. (Except in the compatibility cases.) > > 2) I really dislike when specialized piece of syntax is repeated in two > places rather than being defined once and referenced twice. Doing so > suggests that any resemblance between the two is incidental rather than > fundamental. In this case the syntax for and the value part of > are fundamentally the same. > > In my prior proposals I addressed (2), but not (1). Here is a proposal > that addresses them both: > > Session-ID = "Session-ID" HCOLON endpt-id *[SEMI sess-id-param] > > endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > sess-id-param = rcvr-id / generic-param > > rcvr-id = "rcvr" EQUAL endpt-id > > The above does not explicitly state that can appear at most > once. That is a general rule for header field parameters. It could be > specified in text for emphasis. > > Thanks, > Paul K > > > I could change the hex digits, but that would not be compatible with > > the Kaplan draft. > > > > Paul > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Thursday, October 25, 2012 12:09 PM > >> To: insipid@ietf.org > >> Subject: Re: [Insipid] FW: I-D Action: > >> draft-jones-insipid-session-id- 01.txt - ABNF > >> > >> On 10/25/12 8:53 AM, Christer Holmberg wrote: > >>> > >>> Hi, > >>> > >>> One comment on the ABNF. > >>> > >>> First, I've had off-line discussions with the authors, where we in > >> order to be backward compatible with draft-kaplan agreed on the > >> following things: > >>> > >>> 1. The ABNF will be backward compatible 2. Entities must be prepared > >>> to receive a value that does not contain a value inserted by the > >>> remote peer > >>> > >>> ...so my comment is based on those assumptions. > >>> > >>> > >>> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to > be > >> optional. I would suggest the following: > >>> > >>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI > >>> generic-param) > >>> > >>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>> > >>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > >>> > >>> > >>> In fact, I am not aware of any current implementations that use the > >> generic-param for anything, so we could even do the following: > >>> > >>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI > >>> generic-param)] > >> > >> IMO it is bad practice to require a specific ordering among params. > >> So I would prefer: > >> > >> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > >> > >> sess-id-param = rcvr-uuid / generic-param > >> > >> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >> > >> rcvr-uuid = "rcvr" EQUAL sess-id > >> > >> Another thing: the above only permits lower case hex. For consistency > >> with common usage both lower and upper case should be permitted. This > >> can be done by: > >> > >> sess-id = 32 HEXDIG (from 5234, used in 3261) > >> > >> And is there any reason to require leading zeros in the sess-id? If > >> not, that can be specified via > >> > >> sess-id = 1*32 HEXDIG > >> or maybe > >> sess-id = 1*16 (HEXDIG HEXDIG) > >> > >> Or does backward compatibility require restricting to lower case and > >> exactly 32 digits? > >> > >> Thanks, > >> Paul > >> > >> > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > From pkyzivat@alum.mit.edu Fri Oct 26 15:25:24 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9510221F8539 for ; Fri, 26 Oct 2012 15:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, 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 L9tVOv5E8qGV for ; Fri, 26 Oct 2012 15:25:23 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 8E36F21F8507 for ; Fri, 26 Oct 2012 15:25:23 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id FvSC1k00316LCl05DyRTg7; Fri, 26 Oct 2012 22:25:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id FyQv1k00U3ZTu2S3SyQvUe; Fri, 26 Oct 2012 22:24:55 +0000 Message-ID: <508B0DD1.8010906@alum.mit.edu> Date: Fri, 26 Oct 2012 18:25:21 -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: "Paul E. Jones" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <508AC658.4000901@alum.mit.edu> <081601cdb3c5$0aa028d0$1fe07a70$@packetizer.com> In-Reply-To: <081601cdb3c5$0aa028d0$1fe07a70$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 22:25:24 -0000 I am ok with what you propose. Others may call it overkill. There is an understanding (I'm not certain if it is written down) that a single header parameter can be used at most once within a given header field. And if that isn't enough, it can be stated in text. But I have no trouble with doing it in the syntax as you show. It is easy to do in syntax as long as there is only a single parameter. (It gets messier when there are several parameters and each can appear at most once. Then people must give up and use text.) Otherwise, we may want to tweak the syntax more in order to give names that work well with the descriptions in the text. For instance: Session-ID = "Session-ID" HCOLON local-uuid [sess-id-params] local-uuid = sess-uuid sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] sess-id-params = *(SEMI generic-param) SEMI remote-id-param *(SEMI generic-param) remote-id-param = "remote" EQUAL remote-uuid remote-uuid = sess-uuid This is using the same local/remote terminology that 3261 uses for dialog state. Thanks, Paul On 10/26/12 5:58 PM, Paul E. Jones wrote: > Paul, > > Merging what you propose and my changes from an hour or so earlier, how is > this: > > Session-ID = "Session-ID" HCOLON endpt-id [sess-id-params] > > endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > sess-id-params = *(SEMI generic-param) SEMI rcvr-uuid > *(SEMI generic-param) > > rcvr-uuid = "rcvr" EQUAL endpt-id > > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, October 26, 2012 1:20 PM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- >> 01.txt - ABNF >> >> On 10/26/12 2:12 AM, Paul E. Jones wrote: >>> Paul, >>> >>> OK... I now have this: >>> >>> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] >>> >>> sess-id-param = rcvr-uuid / generic-param >>> >>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>> >>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) >> >> OK, now I'm moving to the esthetics of ABNF writing. None of the >> following changes what may be validly written. >> >> 1) the name of the header field is "Session-ID", so I would expect that >> a non-terminal in the syntax called would describe be the >> fundamental thing. But in the above it isn't. It is *half* of the ID of >> a communication session. (Except in the compatibility cases.) >> >> 2) I really dislike when specialized piece of syntax is repeated in two >> places rather than being defined once and referenced twice. Doing so >> suggests that any resemblance between the two is incidental rather than >> fundamental. In this case the syntax for and the value part of >> are fundamentally the same. >> >> In my prior proposals I addressed (2), but not (1). Here is a proposal >> that addresses them both: >> >> Session-ID = "Session-ID" HCOLON endpt-id *[SEMI sess-id-param] >> >> endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >> >> sess-id-param = rcvr-id / generic-param >> >> rcvr-id = "rcvr" EQUAL endpt-id >> >> The above does not explicitly state that can appear at most >> once. That is a general rule for header field parameters. It could be >> specified in text for emphasis. >> >> Thanks, >> Paul K >> >>> I could change the hex digits, but that would not be compatible with >>> the Kaplan draft. >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Thursday, October 25, 2012 12:09 PM >>>> To: insipid@ietf.org >>>> Subject: Re: [Insipid] FW: I-D Action: >>>> draft-jones-insipid-session-id- 01.txt - ABNF >>>> >>>> On 10/25/12 8:53 AM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>> One comment on the ABNF. >>>>> >>>>> First, I've had off-line discussions with the authors, where we in >>>> order to be backward compatible with draft-kaplan agreed on the >>>> following things: >>>>> >>>>> 1. The ABNF will be backward compatible 2. Entities must be prepared >>>>> to receive a value that does not contain a value inserted by the >>>>> remote peer >>>>> >>>>> ...so my comment is based on those assumptions. >>>>> >>>>> >>>>> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to >> be >>>> optional. I would suggest the following: >>>>> >>>>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] *(SEMI >>>>> generic-param) >>>>> >>>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>>>> >>>>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) >>>>> >>>>> >>>>> In fact, I am not aware of any current implementations that use the >>>> generic-param for anything, so we could even do the following: >>>>> >>>>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid *(SEMI >>>>> generic-param)] >>>> >>>> IMO it is bad practice to require a specific ordering among params. >>>> So I would prefer: >>>> >>>> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] >>>> >>>> sess-id-param = rcvr-uuid / generic-param >>>> >>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>>> >>>> rcvr-uuid = "rcvr" EQUAL sess-id >>>> >>>> Another thing: the above only permits lower case hex. For consistency >>>> with common usage both lower and upper case should be permitted. This >>>> can be done by: >>>> >>>> sess-id = 32 HEXDIG (from 5234, used in 3261) >>>> >>>> And is there any reason to require leading zeros in the sess-id? If >>>> not, that can be specified via >>>> >>>> sess-id = 1*32 HEXDIG >>>> or maybe >>>> sess-id = 1*16 (HEXDIG HEXDIG) >>>> >>>> Or does backward compatibility require restricting to lower case and >>>> exactly 32 digits? >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> >>> > > > From paulej@packetizer.com Fri Oct 26 15:42:04 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 D325F21F84B9 for ; Fri, 26 Oct 2012 15:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 GyD8115ZUtCG for ; Fri, 26 Oct 2012 15:42:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D33C921F8545 for ; Fri, 26 Oct 2012 15:42:03 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9QMg2so013679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 18:42:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351291322; bh=zCnC0jf12bEMXag1zE+QH01pMdVZM6exaeyB6WoB6Hk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CFDbx/KRs7RzT3/QH4WiJApee+7Abmfm7b6BSrWW0gO2n25CIwsF92BqRGbfHdeI1 XOEMM9S5+8M6Gcji55Or5QXqDkrmTGFDji83Wrwz+ytI6UfOvgwR1mvIMd1lQ7l7f7 7QwNN/fS2dN55B7BIk1Q0Ob9UFBdFjf1kWt1Sl+I= From: "Paul E. Jones" 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> In-Reply-To: <508B02E0.3090500@alum.mit.edu> Date: Fri, 26 Oct 2012 18:42:27 -0400 Message-ID: <081801cdb3cb$2d448290$87cd87b0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAq3j/p8BVLx+WpY5EcTQ Content-Language: en-us 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: Fri, 26 Oct 2012 22:42:05 -0000 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? Good question. I'm sure there was a rationale, but it is not apparent now. I'll remove it. > 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 From paulej@packetizer.com Fri Oct 26 16:09:15 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 0ADB021F84C4 for ; Fri, 26 Oct 2012 16:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 DbdXIWJieknN for ; Fri, 26 Oct 2012 16:09:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DBE4921F84AF for ; Fri, 26 Oct 2012 16:09:13 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9QN9BY6016477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 19:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351292952; bh=X4RGtbZ8JgV9qEzUQnh3sqa5H8W78YA0vE8K9xxnrx8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=X/IRmQ2Bz2vAD+tuzkB/TE/eNi0TPfFXLrpOo/lsD+UUqr/yU5mwaok/48sYTNTms WLaB7eD4skq3eJLRigPh4sWMTbGog5G3BKe1WVbVuNuexC7ZQm84s/5tgfZiRP+Rly XuRE7Z1RimAjQQnI9Noq2C+tdPCROLNYIoM92xSc= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <508AC658.4000901@alum.mit.edu> <081601cdb3c5$0aa028d0$1fe07a70$@packetizer.com> <508B0DD1.8010906@alum.mit.edu> In-Reply-To: <508B0DD1.8010906@alum.mit.edu> Date: Fri, 26 Oct 2012 19:09:36 -0400 Message-ID: <082001cdb3ce$f8cad650$ea6082f0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfQLUOGOKAn6bPO4Cq5r1kwHTmubWlewzFwA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 26 Oct 2012 23:09:15 -0000 OK... looks good. Taking that and doing more tweaks: session-id = "Session-ID" HCOLON local-uuid *(SEMI sess-id-param) local-uuid = sess-uuid remote-uuid = sess-uuid sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] sess-id-param = remote-param / generic-param remote-param = "remote" EQUAL remote-uuid How does that look? You're right about the complexity of the sess-id-params. Trying to use syntax to prevent multiple "remote" parameters will not work, anyway, since there is nothing in syntax to prevent some "other" generic-param from having the value "remote". So, we just have to insert a normative statement like this: The Session-ID header MUST NOT have more than one "remote" parameter. Look good? I hope I didn't introduce an error. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Friday, October 26, 2012 6:25 PM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF > > I am ok with what you propose. Others may call it overkill. > There is an understanding (I'm not certain if it is written down) that a > single header parameter can be used at most once within a given header > field. And if that isn't enough, it can be stated in text. > > But I have no trouble with doing it in the syntax as you show. It is > easy to do in syntax as long as there is only a single parameter. (It > gets messier when there are several parameters and each can appear at > most once. Then people must give up and use text.) > > Otherwise, we may want to tweak the syntax more in order to give names > that work well with the descriptions in the text. For instance: > > Session-ID = "Session-ID" HCOLON local-uuid [sess-id-params] > > local-uuid = sess-uuid > > sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > sess-id-params = *(SEMI generic-param) SEMI remote-id-param > *(SEMI generic-param) > > remote-id-param = "remote" EQUAL remote-uuid > > remote-uuid = sess-uuid > > This is using the same local/remote terminology that 3261 uses for > dialog state. > > Thanks, > Paul > > On 10/26/12 5:58 PM, Paul E. Jones wrote: > > Paul, > > > > Merging what you propose and my changes from an hour or so earlier, > > how is > > this: > > > > Session-ID = "Session-ID" HCOLON endpt-id [sess-id-params] > > > > endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > sess-id-params = *(SEMI generic-param) SEMI rcvr-uuid > > *(SEMI generic-param) > > > > rcvr-uuid = "rcvr" EQUAL endpt-id > > > > Paul > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Friday, October 26, 2012 1:20 PM > >> To: Paul E. Jones > >> Cc: insipid@ietf.org > >> Subject: Re: [Insipid] FW: I-D Action: > >> draft-jones-insipid-session-id- 01.txt - ABNF > >> > >> On 10/26/12 2:12 AM, Paul E. Jones wrote: > >>> Paul, > >>> > >>> OK... I now have this: > >>> > >>> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > >>> > >>> sess-id-param = rcvr-uuid / generic-param > >>> > >>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>> > >>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > >> > >> OK, now I'm moving to the esthetics of ABNF writing. None of the > >> following changes what may be validly written. > >> > >> 1) the name of the header field is "Session-ID", so I would expect > >> that a non-terminal in the syntax called would describe be > >> the fundamental thing. But in the above it isn't. It is *half* of the > >> ID of a communication session. (Except in the compatibility cases.) > >> > >> 2) I really dislike when specialized piece of syntax is repeated in > >> two places rather than being defined once and referenced twice. Doing > >> so suggests that any resemblance between the two is incidental rather > >> than fundamental. In this case the syntax for and the value > >> part of are fundamentally the same. > >> > >> In my prior proposals I addressed (2), but not (1). Here is a > >> proposal that addresses them both: > >> > >> Session-ID = "Session-ID" HCOLON endpt-id *[SEMI sess-id- > param] > >> > >> endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >> > >> sess-id-param = rcvr-id / generic-param > >> > >> rcvr-id = "rcvr" EQUAL endpt-id > >> > >> The above does not explicitly state that can appear at most > >> once. That is a general rule for header field parameters. It could be > >> specified in text for emphasis. > >> > >> Thanks, > >> Paul K > >> > >>> I could change the hex digits, but that would not be compatible with > >>> the Kaplan draft. > >>> > >>> Paul > >>> > >>>> -----Original Message----- > >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Thursday, October 25, 2012 12:09 PM > >>>> To: insipid@ietf.org > >>>> Subject: Re: [Insipid] FW: I-D Action: > >>>> draft-jones-insipid-session-id- 01.txt - ABNF > >>>> > >>>> On 10/25/12 8:53 AM, Christer Holmberg wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> One comment on the ABNF. > >>>>> > >>>>> First, I've had off-line discussions with the authors, where we in > >>>> order to be backward compatible with draft-kaplan agreed on the > >>>> following things: > >>>>> > >>>>> 1. The ABNF will be backward compatible 2. Entities must be > >>>>> prepared to receive a value that does not contain a value inserted > >>>>> by the remote peer > >>>>> > >>>>> ...so my comment is based on those assumptions. > >>>>> > >>>>> > >>>>> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs to > >> be > >>>> optional. I would suggest the following: > >>>>> > >>>>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] > *(SEMI > >>>>> generic-param) > >>>>> > >>>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>>>> > >>>>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) > >>>>> > >>>>> > >>>>> In fact, I am not aware of any current implementations that use > >>>>> the > >>>> generic-param for anything, so we could even do the following: > >>>>> > >>>>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid > *(SEMI > >>>>> generic-param)] > >>>> > >>>> IMO it is bad practice to require a specific ordering among params. > >>>> So I would prefer: > >>>> > >>>> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] > >>>> > >>>> sess-id-param = rcvr-uuid / generic-param > >>>> > >>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>>> > >>>> rcvr-uuid = "rcvr" EQUAL sess-id > >>>> > >>>> Another thing: the above only permits lower case hex. For > >>>> consistency with common usage both lower and upper case should be > >>>> permitted. This can be done by: > >>>> > >>>> sess-id = 32 HEXDIG (from 5234, used in 3261) > >>>> > >>>> And is there any reason to require leading zeros in the sess-id? If > >>>> not, that can be specified via > >>>> > >>>> sess-id = 1*32 HEXDIG > >>>> or maybe > >>>> sess-id = 1*16 (HEXDIG HEXDIG) > >>>> > >>>> Or does backward compatibility require restricting to lower case > >>>> and exactly 32 digits? > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> insipid mailing list > >>>> insipid@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/insipid > >>> > >>> > > > > > > From pkyzivat@alum.mit.edu Fri Oct 26 20:43: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 0918721F86AC for ; Fri, 26 Oct 2012 20:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, 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 wY6Efe2q5oqX for ; Fri, 26 Oct 2012 20:43:46 -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 DEF0F21F8694 for ; Fri, 26 Oct 2012 20:43:45 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id G3hi1k00A0ldTLk533jqJL; Sat, 27 Oct 2012 03:43:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id G3jX1k00N3ZTu2S3Q3jXs9; Sat, 27 Oct 2012 03:43:32 +0000 Message-ID: <508B5823.2030503@alum.mit.edu> Date: Fri, 26 Oct 2012 23:42:27 -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: "Paul E. Jones" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <508AC658.4000901@alum.mit.edu> <081601cdb3c5$0aa028d0$1fe07a70$@packetizer.com> <508B0DD1.8010906@alum.mit.edu> <082001cdb3ce$f8cad650$ea6082f0$@packetizer.com> In-Reply-To: <082001cdb3ce$f8cad650$ea6082f0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 27 Oct 2012 03:43:47 -0000 This all seems fine to me! Thanks, Paul On 10/26/12 7:09 PM, Paul E. Jones wrote: > OK... looks good. Taking that and doing more tweaks: > > session-id = "Session-ID" HCOLON local-uuid > *(SEMI sess-id-param) > > local-uuid = sess-uuid > > remote-uuid = sess-uuid > > sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > sess-id-param = remote-param / generic-param > > remote-param = "remote" EQUAL remote-uuid > > How does that look? You're right about the complexity of the > sess-id-params. Trying to use syntax to prevent multiple "remote" > parameters will not work, anyway, since there is nothing in syntax to > prevent some "other" generic-param from having the value "remote". So, we > just have to insert a normative statement like this: > > The Session-ID header MUST NOT have more than one "remote" parameter. > > Look good? I hope I didn't introduce an error. > > Paul > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Friday, October 26, 2012 6:25 PM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- >> 01.txt - ABNF >> >> I am ok with what you propose. Others may call it overkill. >> There is an understanding (I'm not certain if it is written down) that a >> single header parameter can be used at most once within a given header >> field. And if that isn't enough, it can be stated in text. >> >> But I have no trouble with doing it in the syntax as you show. It is >> easy to do in syntax as long as there is only a single parameter. (It >> gets messier when there are several parameters and each can appear at >> most once. Then people must give up and use text.) >> >> Otherwise, we may want to tweak the syntax more in order to give names >> that work well with the descriptions in the text. For instance: >> >> Session-ID = "Session-ID" HCOLON local-uuid [sess-id-params] >> >> local-uuid = sess-uuid >> >> sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >> >> sess-id-params = *(SEMI generic-param) SEMI remote-id-param >> *(SEMI generic-param) >> >> remote-id-param = "remote" EQUAL remote-uuid >> >> remote-uuid = sess-uuid >> >> This is using the same local/remote terminology that 3261 uses for >> dialog state. >> >> Thanks, >> Paul >> >> On 10/26/12 5:58 PM, Paul E. Jones wrote: >>> Paul, >>> >>> Merging what you propose and my changes from an hour or so earlier, >>> how is >>> this: >>> >>> Session-ID = "Session-ID" HCOLON endpt-id [sess-id-params] >>> >>> endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>> >>> sess-id-params = *(SEMI generic-param) SEMI rcvr-uuid >>> *(SEMI generic-param) >>> >>> rcvr-uuid = "rcvr" EQUAL endpt-id >>> >>> Paul >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Friday, October 26, 2012 1:20 PM >>>> To: Paul E. Jones >>>> Cc: insipid@ietf.org >>>> Subject: Re: [Insipid] FW: I-D Action: >>>> draft-jones-insipid-session-id- 01.txt - ABNF >>>> >>>> On 10/26/12 2:12 AM, Paul E. Jones wrote: >>>>> Paul, >>>>> >>>>> OK... I now have this: >>>>> >>>>> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] >>>>> >>>>> sess-id-param = rcvr-uuid / generic-param >>>>> >>>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>>>> >>>>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) >>>> >>>> OK, now I'm moving to the esthetics of ABNF writing. None of the >>>> following changes what may be validly written. >>>> >>>> 1) the name of the header field is "Session-ID", so I would expect >>>> that a non-terminal in the syntax called would describe be >>>> the fundamental thing. But in the above it isn't. It is *half* of the >>>> ID of a communication session. (Except in the compatibility cases.) >>>> >>>> 2) I really dislike when specialized piece of syntax is repeated in >>>> two places rather than being defined once and referenced twice. Doing >>>> so suggests that any resemblance between the two is incidental rather >>>> than fundamental. In this case the syntax for and the value >>>> part of are fundamentally the same. >>>> >>>> In my prior proposals I addressed (2), but not (1). Here is a >>>> proposal that addresses them both: >>>> >>>> Session-ID = "Session-ID" HCOLON endpt-id *[SEMI sess-id- >> param] >>>> >>>> endpt-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>>> >>>> sess-id-param = rcvr-id / generic-param >>>> >>>> rcvr-id = "rcvr" EQUAL endpt-id >>>> >>>> The above does not explicitly state that can appear at most >>>> once. That is a general rule for header field parameters. It could be >>>> specified in text for emphasis. >>>> >>>> Thanks, >>>> Paul K >>>> >>>>> I could change the hex digits, but that would not be compatible with >>>>> the Kaplan draft. >>>>> >>>>> Paul >>>>> >>>>>> -----Original Message----- >>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: Thursday, October 25, 2012 12:09 PM >>>>>> To: insipid@ietf.org >>>>>> Subject: Re: [Insipid] FW: I-D Action: >>>>>> draft-jones-insipid-session-id- 01.txt - ABNF >>>>>> >>>>>> On 10/25/12 8:53 AM, Christer Holmberg wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> One comment on the ABNF. >>>>>>> >>>>>>> First, I've had off-line discussions with the authors, where we in >>>>>> order to be backward compatible with draft-kaplan agreed on the >>>>>> following things: >>>>>>> >>>>>>> 1. The ABNF will be backward compatible 2. Entities must be >>>>>>> prepared to receive a value that does not contain a value inserted >>>>>>> by the remote peer >>>>>>> >>>>>>> ...so my comment is based on those assumptions. >>>>>>> >>>>>>> >>>>>>> Q_ABNF-1: In order to be backward compatible, rcvr-uuid needs > to >>>> be >>>>>> optional. I would suggest the following: >>>>>>> >>>>>>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid] >> *(SEMI >>>>>>> generic-param) >>>>>>> >>>>>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>>>>>> >>>>>>> rcvr-uuid = "rcvr" EQUAL 32(DIGIT / %x61-66) >>>>>>> >>>>>>> >>>>>>> In fact, I am not aware of any current implementations that use >>>>>>> the >>>>>> generic-param for anything, so we could even do the following: >>>>>>> >>>>>>> Session-ID = "Session-ID" HCOLON sess-id [SEMI rcvr-uuid >> *(SEMI >>>>>>> generic-param)] >>>>>> >>>>>> IMO it is bad practice to require a specific ordering among params. >>>>>> So I would prefer: >>>>>> >>>>>> Session-ID = "Session-ID" HCOLON sess-id *[SEMI sess-id-param] >>>>>> >>>>>> sess-id-param = rcvr-uuid / generic-param >>>>>> >>>>>> sess-id = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] >>>>>> >>>>>> rcvr-uuid = "rcvr" EQUAL sess-id >>>>>> >>>>>> Another thing: the above only permits lower case hex. For >>>>>> consistency with common usage both lower and upper case should be >>>>>> permitted. This can be done by: >>>>>> >>>>>> sess-id = 32 HEXDIG (from 5234, used in 3261) >>>>>> >>>>>> And is there any reason to require leading zeros in the sess-id? If >>>>>> not, that can be specified via >>>>>> >>>>>> sess-id = 1*32 HEXDIG >>>>>> or maybe >>>>>> sess-id = 1*16 (HEXDIG HEXDIG) >>>>>> >>>>>> Or does backward compatibility require restricting to lower case >>>>>> and exactly 32 digits? >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>> >>>>> >>> >>> >>> > > > From salvatore.loreto@ericsson.com Sat Oct 27 08:57:44 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 9CF5F21F8503 for ; Sat, 27 Oct 2012 08:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.649 X-Spam-Level: X-Spam-Status: No, score=-106.649 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 JKZQe8j2V74b for ; Sat, 27 Oct 2012 08:57:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23821F8509 for ; Sat, 27 Oct 2012 08:57:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-19-508c047580da Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 78.1D.26143.5740C805; Sat, 27 Oct 2012 17:57:41 +0200 (CEST) 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; Sat, 27 Oct 2012 17:57:41 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 367EB24C7; Sat, 27 Oct 2012 18:57:41 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 81DC9539D0; Sat, 27 Oct 2012 18:57:40 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5B08D51BCF; Sat, 27 Oct 2012 18:57:39 +0300 (EEST) Message-ID: <508C0473.9080105@ericsson.com> Date: Sat, 27 Oct 2012 18:57:39 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> <50890D25.9030206@ericsson.com> <074601cdb33d$becf8360$3c6e8a20$@packetizer.com> In-Reply-To: <074601cdb33d$becf8360$3c6e8a20$@packetizer.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+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvrW4pS0+Awel55hbz7z9jsjh/YQOT A5PHkiU/mTwa9h1lD2CK4rJJSc3JLEst0rdL4Mr43/GVveCGQkXX0d2MDYx/JbsYOTkkBEwk zvXvZIawxSQu3FvP1sXIxSEkcIpRovPPLyYIZwOjxIbZfxkhnN2MEmvbf4K1CAmsY5T4MFMV wt7OKHH2sjaIzSugLXF19W+gBg4OFgFViXNLDUHCbAJmEs8fbgFrFRVIlpi34SozRLmgxMmZ T1hAbBGg1jPXHoLFmQV8JX6+2MMGYgsLWEr8OnYCau13Fone7iwQm1PAVmLRwnPsEPW2Ehfm XGeBsOUltr+dA/WZmsTVc5ugerUkes92Mk1gFJ2FZPUsJO2zkLQvYGRexciem5iZk15utIkR GPQHt/xW3cF455zIIUZpDhYlcV7rrXv8hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDulpgQ WFZft451Rru85Abv+SfUlhw72WnXk6VTcNzcZFdef0XY9g6JV/EtU0xecZ5oeCdlzfDQMHvK h4QF+SFpNZELRHu/nl7wMGNm5W03jcbIA8Ih0drr9/1klzDMK1lj5VLOd2ke07ZF5tK9ry01 jzt+k/s8kc04Tnpp+evDT/+zlUdnxCqxFGckGmoxFxUnAgCE2DQQSAIAAA== Cc: insipid@ietf.org, 'Gonzalo Camarillo' Subject: Re: [Insipid] Handling (or not) of call transfer 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, 27 Oct 2012 15:57:44 -0000 On 10/26/12 8:50 AM, Paul E. Jones wrote: > Gonzalo, > > This is REQ2 in the requirements document. Use case is in 3.6. > > How a transferred call is correlated would be defined by the solution. The > requirement is merely that it must be possible. We're not even concerned > necessarily with how the calls correlate, but merely that they are. I already suggested to somehow relax the last sentence of REQ.2 so that it does not include any possible link to the specific solution. Having thought more on it, I do think it would be even better remove completely the last sentence of REQ.2. In this way the requirement would be really merely that it must be possible! > > With the solution we've proposed, Alice would have some identifier A that > should would use for the life of a communication session -- from the time > she sends an INVITE to the time she sends or receives the final BYE. That > is, when the "call is over" as far as the human is concerned. No matter how > many times she is transferred, she continues to use A in signaling. This > allows for correlation. yep but again, I would like to have the requirement been solution agnostic /Sal -- Salvatore Loreto, PhD www.sloreto.com > > There is no higher-level correlation than that. > > Paul > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Thursday, October 25, 2012 5:58 AM >> To: Paul E. Jones >> Cc: Salvatore Loreto; insipid@ietf.org >> Subject: Re: [Insipid] Handling (or not) of call transfer >> >> Hi, >> >> this thread has discussed a requirement on being able to change the >> session ID but still correlate sessions. That is a second level of >> correlation you need to define very clearly in the requirements draft so >> that people understand what it means and can comment on it. >> >> If we assume that identifiers change but that there is a higher level of >> correlation that will know about the different identifiers being >> correlated, we are back into what we currently have with Call-IDs. A >> B2BUA that changes the Call-ID in a request knows that both Call-IDs are >> correlated even if they are different. The problem is that other >> elements do not know about that. By defining several levels of >> correlation we may very soon run into this type of problem. >> >> Of course, anyone who was involved in SPLICES will recognize that these >> are the same discussions we had in that WG. >> >> Cheers, >> >> Gonzalo >> >> >> On 10/10/2012 3:32 AM, Paul E. Jones wrote: >>> Sal, >>> >>>> what about changing the last sentence of the REQ2 >>>> >>>> REQ2: It must be possible to correlate two end-to-end sessions >> when a >>>> session is transferred or if two different sessions are joined >>>> together via an intermediary (e.g., a PBX). This might result in >> a >>>> change in the value of the end-to-end Session-Identifier. >>>> >>>> with the following sentence (or an improved one): >>>> >>>> "This must be possible regardless of any eventual change in the value >>>> of the end-to-end Session-Identifier." >>>> >>>> in this way we provide the freedom for the solution, whatever it will >>>> be, to do whatever it has to do with the Session-Identifier. >>>> The important here is not the value of the Session-Identifier per se, >>>> but the fact that can successfully be used to correlate sessions! >>> Yeah, that would work. The intent with the original phrasing was to >>> allow the door to be open on this one. I cannot see how we avoid >>> changing the identifier in some signaling scenarios, but I'm certainly >>> open to a proposal that might make it possible. >>> >>> I'm going to submit a revision of the draft with changes agreed to >>> during the last call, but I'll exclude any changes to REQ2 right now. >>> If there is agreement on this change, I can submit another revision >> again this week. >>> Paul >>> >>> >>> >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>> >>> From pkyzivat@alum.mit.edu Sat Oct 27 10:25:04 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 2F21021F84EB for ; Sat, 27 Oct 2012 10:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.062, 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 hV1dGpr5DVFA for ; Sat, 27 Oct 2012 10:25:03 -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 1384421F8472 for ; Sat, 27 Oct 2012 10:25:02 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id GBgk1k0071GhbT853HR7j6; Sat, 27 Oct 2012 17:25:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id GHRb1k00B3ZTu2S3THRbk5; Sat, 27 Oct 2012 17:25:35 +0000 Message-ID: <508C18EB.6000202@alum.mit.edu> Date: Sat, 27 Oct 2012 13:24:59 -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: "Paul E. Jones" References: <5088F86F.9050104@ericsson.com> <074401cdb33c$70c37600$524a6200$@packetizer.com> <508AC161.7050304@alum.mit.edu> <081401cdb3c4$450379b0$cf0a6d10$@packetizer.com> In-Reply-To: <081401cdb3c4$450379b0$cf0a6d10$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.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: Sat, 27 Oct 2012 17:25:04 -0000 On 10/26/12 5:53 PM, Paul E. Jones wrote: > Paul, > >>> REQ1 intends to require a solution for transactions and lengthier >> dialogs. >>> The issues is defining a "communication session", which is a challenge >>> since even "session" is vaguely defined. I welcome any suggested >>> wording, perhaps something in section 2? >> >> If there is an expectation that this mechanism should work for >> correlating the "legs" of a single message/response sent outside a >> dialog as it traverses B2BUAs, then *something* needs to be said about >> it. > > If Alice calls Bob, Alice will allocate a Session-ID UUID value that will > traverse through any number of B2BUAs, regardless of how many "legs" that > might be. I think that should be clear. > > What may not be so clear is what we do with things like Subscribe/Notify. > Even to me, that's not as clear. I think that was intended to be covered by > the REQ1 text. If that isn't sufficiently addresses, I invite some > re-wording. Your comments seem to address something different than the point I was making. My point was regarding messages out-of-dialog that are not dialog-establishing, like MESSAGE, PUBLISH, OPTIONS. "Session" in 3261 mostly refers to what is now more precisely called "invite dialog usage". (I draw this mostly from section 13 of 3261. It isn't exactly consistent with the definition in section 6, which is drawn from SDP.) But for a lot of practical use is is probably sufficient to consider Session to by synonymous with Dialog. That would encompass sub/not. It seems clear to me that Session doesn't encompass a MESSAGE and its response. Nor does Session in 3261 encompass a chain of dialogs strung together with B2BUAs. >> I raised early on the problem of inadequate terminology. And I think we >> still have it. I just did a search of 3261, and "communication session" >> is not defined there, and is used only once. So perhaps it is an >> available term that has no established definition in the sip context. > > But I'm not sure we should be defining it. What is it that you are not sure we should be defining? I think we need to be defining what it is that a Session-ID identifies. Ideally that means defining a term that names those things an no others. IMO the only issue is what the name of that term is. > If we drop "communication" from > the language, does that help? No, it makes it worse. It leaves us with just "session", which is hopelessly overloaded already, with none of the existing definitions being what is intended here. As I tried to say, I think "communication session" is a plausible choice, because AFAIK it doesn't already have another definition in the context of SIP. Or we could coin a new term. How about XYZZY? :-) > Communication is what this is all about. > It's more or less an adjective that might be superfluous. A Session is a > phone call, conference call, etc. Communication session is the same: phone > call, conference call, etc. Any two entities communicating would be a > communication session. > >> That leaves the need to adequately define what it means. This is tied up >> with the scope of this work. We want the new ID to correlate 1:1 with >> certain kinds of things, and so presumably we want "communication >> session" to be a name for those kinds of things. > > I'm not hung up on that word. But, I do think you can point to a phone call > and say "that's a phone call between Alice and Bob". If it's between them > and not part of a conference, then there would be a Session-ID representing > that two-party phone call. What I am concerned with is having the definition be "I know it when I see it". What you are describing is an *example*. Examples are good, but they are not enough. What I am looking for is an algorithm (or predicate if you prefer) that can be applied to any example and will say if two messages should share the same session-id (or same half session-id) or not. >> But using "communication session" brings with it the baggage of >> "session". > > :-) The whole subject of 3261. > >> I think it is hard to make a definition of "communcation >> session" that doesn't relate in a clear and obvious way to the notion of >> "session" used in SIP. In particular, I find it difficult to use >> "communication session" to characterize a MESSAGE and its response that >> happen to traverse an SBC. OTOH, I can imagine coming up with *some* >> term to describe a set of related messages that are tightly coupled by >> B2BUAs. (But no good name for this comes to mind.) If we were to define >> that, then that can be applied to dialog establishing messages and used >> to extend the concept to related dialogs. > > Yeah, it it was just a MESSAGE out of the blue, one might argue it's not a > communication session. But, what is it? The remote side will reply. If > it's part of an ongoing phone call, then it's part of that "communication > session". If it has no relationship with an ongoing phone call, then what > is that exchange and do we want a Session-ID applied to it? For that, I > don't care. Others seem to want it. Yes, people seem to want it, and it makes as much sense as the rest. But it is clearly not a "session" or "communication session". It needs to be called something else. But what is important is that if you start by defining *that*, then extending it to dialogs is easy. You decide to use the same ID with the chained dialog-establishing transactions. And then you add a rule that then also related other transactions in the same dialog. >> IMO this is really coming in the back door at the task of defining a >> whole new architectural layer on top of existing sip concepts, made up >> of SIP UAs connected in specific ways. (This is exactly what Hadriel has >> made a non-goal in STRAW.) > > And today SIP is 16 years, 247 days old... Is that a good thing or a bad thing? (I'm a lot older than that and I'm still alive and kicking.) My point is that this is really not just sip, it is another layer built using sip as a component. We might be better off recognizing this. Thanks, Paul From pkyzivat@alum.mit.edu Sat Oct 27 10:39:22 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4915C21F84BF for ; Sat, 27 Oct 2012 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, 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 AAqa5ug-qKzp for ; Sat, 27 Oct 2012 10:39:21 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 883AE21F84AF for ; Sat, 27 Oct 2012 10:39:21 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id GH6s1k0031wpRvQ58HfS2A; Sat, 27 Oct 2012 17:39:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id GJ091k00y3ZTu2S3eJ0Aks; Sat, 27 Oct 2012 18:00:10 +0000 Message-ID: <508C1C47.9080006@alum.mit.edu> Date: Sat, 27 Oct 2012 13:39:19 -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: "Paul E. Jones" 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> In-Reply-To: <081801cdb3cb$2d448290$87cd87b0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 27 Oct 2012 17:39:22 -0000 Trimming out the stuff I have no further comments on: On 10/26/12 6:42 PM, 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. >> 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.) >> 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. This is why it's important to have a clear and explicit definition of those cases there a common id is appropriate and those where it is not. I commented on that at length in another message, so probably better to discuss in that thread. Thanks, Paul From salvatore.loreto@ericsson.com Sat Oct 27 11:49: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 3589421F85A6 for ; Sat, 27 Oct 2012 11:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, 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 fT1F2QBSm5IW for ; Sat, 27 Oct 2012 11:48:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4658321F85B1 for ; Sat, 27 Oct 2012 11:48:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-c8-508c2c951bb1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F7.D4.26143.59C2C805; Sat, 27 Oct 2012 20:48:53 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sat, 27 Oct 2012 20:48:52 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AB1E12531 for ; Sat, 27 Oct 2012 21:48:52 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0CC7D539D0 for ; Sat, 27 Oct 2012 21:48:52 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8AA1951BCF for ; Sat, 27 Oct 2012 21:48:51 +0300 (EEST) Message-ID: <508C2C93.2080500@ericsson.com> Date: Sat, 27 Oct 2012 21:48:51 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> In-Reply-To: <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> Content-Type: multipart/alternative; boundary="------------030500040008070807080502" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM+Jvre5UnZ4AgzU/5C3m33/G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAcbPjAXnJvIWNH74BJjA+O0nC5GTg4JAROJp3NOMkLYYhIX 7q1nA7GFBE4xSmxYEN/FyAVkb2CUmHD2PSOEc4lR4uS0f1BVRxkl3jcWQiTOMUocfnWNBSTB K6At8aptGyuIzSKgKjHh/yOwFWwCZhLPH25hBrFFBZIl5m24ygxRLyhxcuYTsF4RARGJ33en sIPYwgLeEre3nGeGWLCMUWLrmldgmzkFHCRW7z/FBGIzC4RJzLu8lA3iBzWJq+c2MUNcpyXR e7aTaQKj8CwkO2YhaYGwbSUuzLkOFZeX2P52DjOErStx4f8UFPEFjGyrGNlzEzNz0suNNjEC w//glt+qOxjvnBM5xCjNwaIkzmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYlv+TZ FvICLdw9ayRqdSbr3i7cO3/r1YKQkErpFevbcrg6T040UUo9rHk1/WpueJtTFkvHg+jckn6j lT2x5+vTn2QwqjkoHplStmT2OtUz58QX75WJ6ku6+lri53nJjvv55YGHyx+bNLw6GMj8ylEk pLpDJD7Oe/vLJNV3rz2OHTn/6mJdrhJLcUaioRZzUXEiAIgPI9FNAgAA 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, 27 Oct 2012 18:49:00 -0000 --------------030500040008070807080502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there I have read the 01 and have the following questions in Section 7. Processing by Intermediaries I don't find anything that explain when an intermediary is "allowed" to inject an identifier into the session signaling so to meet REQ7. REQ7: It must be possible to identity SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling. Moreover Section 7 states Intermediaries MUST NOT alter the UUID values found in the Session-ID header, except as described in this section. and there is nothing the the section describing it. Do I have overlooked something ? I am a little puzzled from the aim of Section 9. There is nothing in that section that is necessary to fulfill the Req9c REQ9c: The identifier should be constructed in such a way as to make it suitable for transmission in SIP and RTCP [3 ]. 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 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.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 --------------030500040008070807080502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi there

I have read the 01 and have the following questions


in Section 7. Processing by Intermediaries

I don't find anything that explain when an intermediary is "allowed" to inject an identifier into the session signaling
so to meet REQ7.

   REQ7: It must be possible to identity SIP traffic with an end-to-end
   session identifier from and to end devices that do not support this
   new identifier, such as by allowing an intermediary to inject an
   identifier into the session signaling.

Moreover Section 7 states

   Intermediaries MUST NOT alter the UUID values found in the Session-ID
   header, except as described in this section.
and there is nothing the the section describing it.
Do I have overlooked something ?



I am a little puzzled from the aim of Section 9.
There is nothing in that section that is necessary to fulfill the Req9c

   REQ9c: The identifier should be constructed in such a way as to make
   it suitable for transmission in SIP and RTCP [3].

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

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.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

--------------030500040008070807080502-- From paulej@packetizer.com Sat Oct 27 14:09:18 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 9C69F21F8540 for ; Sat, 27 Oct 2012 14:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 4P65Yw6rzPxe for ; Sat, 27 Oct 2012 14:09:18 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DF91821F84FC for ; Sat, 27 Oct 2012 14:09:17 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9RL9ECX008530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 17:09:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351372155; bh=SXEjCqY9XJrVxEysW8x2vP6zxEeuARQ6J/uO/dQxQ4c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=E1HfHbhzz1Vep1ohat8nzmQR0DaO3TIkTFsirwXoGeAFAE3/j/CXG209mNO/RKDZH k2mA4cw6O6FfyincP8u6n95Vm+JyrebpAtyH38Lin3K5LD0gNzncfJTfbTokxpxgKN SjVK13GPGw6F04u16MMvicdYRiBjSZBvLtOlhIzI= From: "Paul E. Jones" To: "'Salvatore Loreto'" References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> <50890D25.9030206@ericsson.com> <074601cdb33d$becf8360$3c6e8a20$@packetizer.com> <508C0473.9080105@ericsson.com> In-Reply-To: <508C0473.9080105@ericsson.com> Date: Sat, 27 Oct 2012 17:09:15 -0400 Message-ID: <092f01cdb487$52d55630$f8800290$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5owC0nRDEAaQYqW0BccWwGgIfe52gAWcUoLwCIwtb8gKLh6U+APAT6ZOXQ6iyMA== Content-Language: en-us Cc: insipid@ietf.org, 'Gonzalo Camarillo' Subject: Re: [Insipid] Handling (or not) of call transfer 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, 27 Oct 2012 21:09:18 -0000 Sal, > > This is REQ2 in the requirements document. Use case is in 3.6. > > > > How a transferred call is correlated would be defined by the solution. > > The requirement is merely that it must be possible. We're not even > > concerned necessarily with how the calls correlate, but merely that > they are. > > I already suggested to somehow relax the last sentence of REQ.2 so that > it does not include any possible link to the specific solution. > Having thought more on it, I do think it would be even better remove > completely the last sentence of REQ.2. > In this way the requirement would be really merely that it must be > possible! My current draft has this sentence you provided: "This must be possible regardless of any eventual change in the value of the end-to-end Session-Identifier." I think we should say something. If we say nothing, then somebody might be quite surprised to discover that the Session ID changes. It would be nice if the ID never changed, but there are flows that occur in normal operation where I cannot see how we could not change the Session ID. It only happens in cases of call transfer, merging/joining calls, etc. So, having this as a comment tacked onto the end of this requirement is helpful. We could remove that sentence, but I would not want somebody to say a solution is not acceptable because the ID changes in certain flows. Paul From paulej@packetizer.com Sat Oct 27 14:39: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 7B73821F845E for ; Sat, 27 Oct 2012 14:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 IirjdWqcnrSB for ; Sat, 27 Oct 2012 14:39:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 91ED721F841E for ; Sat, 27 Oct 2012 14:39:31 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9RLdTOg009779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 17:39:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351373970; bh=5IU0k7VT1VUV1gEQIK6nNoNrBznXRORHTXP4jwUyC4E=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=JG1UGxi45IododjAjZzFwbSL9Ib+TSY8zjHfz9pKwwNL5UShymR4sJu/lUJB9l997 gJFKLozmcetcuVGUGLj6uL77k/xarr66nfL7YkofIaCqUbNTF7XE+WdxUQe3RYmYq1 I4Gidd0UUA2J69G3/J67IsccE5cz/0jIiiE9rmVI= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <5088F86F.9050104@ericsson.com> <074401cdb33c$70c37600$524a6200$@packetizer.com> <508AC161.7050304@alum.mit.edu> <081401cdb3c4$450379b0$cf0a6d10$@packetizer.com> <508C18EB.6000202@alum.mit.edu> In-Reply-To: <508C18EB.6000202@alum.mit.edu> Date: Sat, 27 Oct 2012 17:39:31 -0400 Message-ID: <093701cdb48b$8ce341d0$a6a9c570$@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: AQKZbZgN23jzvno3rjTPIQU9SQi70gKm9zPJAYQ9qJEB8TWcOgECmKpSlf0+QcA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Comments on draft-ietf-insipid-session-id-reqts-02.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: Sat, 27 Oct 2012 21:39:32 -0000 Paul, > Your comments seem to address something different than the point I was > making. My point was regarding messages out-of-dialog that are not > dialog-establishing, like MESSAGE, PUBLISH, OPTIONS. > > "Session" in 3261 mostly refers to what is now more precisely called > "invite dialog usage". (I draw this mostly from section 13 of 3261. It > isn't exactly consistent with the definition in section 6, which is > drawn from SDP.) > > But for a lot of practical use is is probably sufficient to consider > Session to by synonymous with Dialog. That would encompass sub/not. > > It seems clear to me that Session doesn't encompass a MESSAGE and its > response. Nor does Session in 3261 encompass a chain of dialogs strung > together with B2BUAs. I think there should be a relationship to a dialog, I agree. This gets back to the original idea... if we removed any B2BUA and a dialog existed directly between two devices, anything part of that dialog would have the same Session-ID. > >> I raised early on the problem of inadequate terminology. And I think > >> we still have it. I just did a search of 3261, and "communication > session" > >> is not defined there, and is used only once. So perhaps it is an > >> available term that has no established definition in the sip context. > > > > But I'm not sure we should be defining it. > > What is it that you are not sure we should be defining? > I think we need to be defining what it is that a Session-ID identifies. > Ideally that means defining a term that names those things an no others. > IMO the only issue is what the name of that term is. That I agree with and would accept any wording. It's defining the word "session" -- which is not consistently defined -- that I think we should not approach. > > If we drop "communication" from > > the language, does that help? > > No, it makes it worse. It leaves us with just "session", which is > hopelessly overloaded already, with none of the existing definitions > being what is intended here. > > As I tried to say, I think "communication session" is a plausible choice, > because AFAIK it doesn't already have another definition in the context > of SIP. > > Or we could coin a new term. How about XYZZY? :-) Does that mean "it's easy"? Sure... ;-) > > Communication is what this is all about. > > It's more or less an adjective that might be superfluous. A Session is > > a phone call, conference call, etc. Communication session is the > > same: phone call, conference call, etc. Any two entities > > communicating would be a communication session. > > > >> That leaves the need to adequately define what it means. This is tied > >> up with the scope of this work. We want the new ID to correlate 1:1 > >> with certain kinds of things, and so presumably we want > >> "communication session" to be a name for those kinds of things. > > > > I'm not hung up on that word. But, I do think you can point to a > > phone call and say "that's a phone call between Alice and Bob". If > > it's between them and not part of a conference, then there would be a > > Session-ID representing that two-party phone call. > > What I am concerned with is having the definition be "I know it when I > see it". What you are describing is an *example*. Examples are good, but > they are not enough. > > What I am looking for is an algorithm (or predicate if you prefer) that > can be applied to any example and will say if two messages should share > the same session-id (or same half session-id) or not. Fully agreed, but I need that definition. I'm not sure exactly how it should be defined more precisely than it is now. > > Yeah, it it was just a MESSAGE out of the blue, one might argue it's > > not a communication session. But, what is it? The remote side will > > reply. If it's part of an ongoing phone call, then it's part of that > > "communication session". If it has no relationship with an ongoing > > phone call, then what is that exchange and do we want a Session-ID > > applied to it? For that, I don't care. Others seem to want it. > > Yes, people seem to want it, and it makes as much sense as the rest. > But it is clearly not a "session" or "communication session". It needs > to be called something else. > > But what is important is that if you start by defining *that*, then > extending it to dialogs is easy. You decide to use the same ID with the > chained dialog-establishing transactions. And then you add a rule that > then also related other transactions in the same dialog. I think you know what we should insert... I just feel it. ;-) > >> IMO this is really coming in the back door at the task of defining a > >> whole new architectural layer on top of existing sip concepts, made > >> up of SIP UAs connected in specific ways. (This is exactly what > >> Hadriel has made a non-goal in STRAW.) > > > > And today SIP is 16 years, 247 days old... > > Is that a good thing or a bad thing? (I'm a lot older than that and I'm > still alive and kicking.) I was only suggesting we've made it this far without a precise definition of "Session". So, there is a question of whether there is a new definition needed. > My point is that this is really not just sip, it is another layer built > using sip as a component. We might be better off recognizing this. Yeah, point taken. Paul From paulej@packetizer.com Sat Oct 27 14:49:34 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369E221F84EC for ; Sat, 27 Oct 2012 14:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 C9UtyYMLKBby for ; Sat, 27 Oct 2012 14:49:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 637CA21F854F for ; Sat, 27 Oct 2012 14:49:33 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9RLnVQQ010166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 17:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351374572; bh=bvtps8aVDZgpSRJTcYKomXoTWpgxQpZO9TLXtZrTEZg=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=h7N3aZxoM2IGJ8r1DlRTq99taLiBZeeiKrJ8+/d8jRdlWMBdt4zHFlCEtNxkuIJrY vUvOcFGRIrRawTofvX/ZRRMeZDOa3tf6OFaKmYEWi0vMo/Ijcneq425eFeVjDZfTvV gy19eNiiOIOZU7mI3YumPuEwq5OUgk+lVyjlAzR8= From: "Paul E. Jones" 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> In-Reply-To: <508C1C47.9080006@alum.mit.edu> Date: Sat, 27 Oct 2012 17:49:33 -0400 Message-ID: <093901cdb48c$f3b21d90$db1658b0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAq3j/p8BVLx+WgKIsFv/AmDDWlSWE1EWwA== Content-Language: en-us 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: Sat, 27 Oct 2012 21:49:34 -0000 > >> 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. Paul From paulej@packetizer.com Sat Oct 27 15:08: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 A488321F85BB for ; Sat, 27 Oct 2012 15:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[AWL=-0.300, J_CHICKENPOX_53=0.6] 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 C5n8CYna2yLz for ; Sat, 27 Oct 2012 15:08:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 59E3321F8553 for ; Sat, 27 Oct 2012 15:08:36 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9RM8VUS010954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 27 Oct 2012 18:08:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351375713; bh=Lq1Q2Tk0UTv0sBuO5qMT6t5Hj2B2Es3SeyYu0RRCSoI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=QcRtP4soGAaso4f8hsgzTIeUXwdyxUEN+Ooi6RW6x2zaJAnvtdSsjQRnUqmCyX13t Lk/dqS102Gw5k/4VA0U+qEe3tTqtfPdxEZCHXS+ZgE/wXnNqxfTCDlUkPkvY/eq14I aV4+i+3pxiOvFyod17ATQ9O0GvrfNkUIZFxhExDA= From: "Paul E. Jones" To: "'Salvatore Loreto'" , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508C2C93.2080500@ericsson.com> In-Reply-To: <508C2C93.2080500@ericsson.com> Date: Sat, 27 Oct 2012 18:08:33 -0400 Message-ID: <093b01cdb48f$9b988740$d2c995c0$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAq3j/p8Bu4ISfJY3a0LQ Content-Language: en-us 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, 27 Oct 2012 22:08:37 -0000 On Sat, 27 Oct 2012 21:48:51 +0300, Salvatore Loreto wrote: > Hi there > > I have read the 01 and have the following questions > > in Section 7. Processing by Intermediaries > > I don't find anything that explain when an intermediary is "allowed" > to inject an identifier into the session signaling > so to meet REQ7. > > REQ7: It must be possible to identity SIP traffic with an end-to-end > session identifier from and to end devices that do not support this > new identifier, such as by allowing an intermediary to inject an > identifier into the session signaling. How about this sentence: If a SIP message having no Session-ID header is received by an intermediary, the intermediary MAY assign a "local-uuid" value to represent the sending endpoint and insert that value into all signaling messages on behalf of the sending endpoint. > Moreover Section 7 states > > Intermediaries MUST NOT alter the UUID values found in the Session-ID > header, except as described in this section. > and there is nothing the the section describing it. > Do I have overlooked something ? Intermediaries might change the value to facilitate call transfer, call joins, or insert values on behalf of endpoints. We may have more examples where intermediaries change values. We do need language to restrict changes, otherwise, devices might change things in any way they wish. > I am a little puzzled from the aim of Section 9. > There is nothing in that section that is necessary to fulfill the > Req9c > > REQ9c: The identifier should be constructed in such a way as to make > it suitable for transmission in SIP and RTCP [3 [18]]. Yeah, this is left over from before. There is no normative language at all. We had that there to indicate in what other ways this value might be used, if we choose to define it. If we remove this section, it would not change the solution. I'll let James address the comments on call flows. Paul > 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 > > Cheers > /Sal > > -- > Salvatore Loreto, PhD > www.sloreto.com [19] From salvatore.loreto@ericsson.com Sat Oct 27 23:37:46 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C1D21F866D for ; Sat, 27 Oct 2012 23:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.649 X-Spam-Level: X-Spam-Status: No, score=-104.649 tagged_above=-999 required=5 tests=[AWL=1.600, 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 mwuaq3kXD4ZN for ; Sat, 27 Oct 2012 23:37:45 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5188221F855F for ; Sat, 27 Oct 2012 23:37:44 -0700 (PDT) X-AuditID: c1b4fb25-b7f926d00000661f-62-508cd2b792ac Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3D.69.26143.7B2DC805; Sun, 28 Oct 2012 07:37:43 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Sun, 28 Oct 2012 07:37:43 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 429792531; Sun, 28 Oct 2012 08:37:43 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6870353699; Sun, 28 Oct 2012 08:37:42 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0A66351BCF; Sun, 28 Oct 2012 08:37:42 +0200 (EET) Message-ID: <508CD2B6.90409@ericsson.com> Date: Sun, 28 Oct 2012 08:37:42 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> <50890D25.9030206@ericsson.com> <074601cdb33d$becf8360$3c6e8a20$@packetizer.com> <508C0473.9080105@ericsson.com> <092f01cdb487$52d55630$f8800290$@packetizer.com> In-Reply-To: <092f01cdb487$52d55630$f8800290$@packetizer.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+NgFtrKLMWRmVeSWpSXmKPExsUyM+Jvre72Sz0BBiv+GFnMv/+MyeL8hQ1M DkweS5b8ZPJo2HeUPYApissmJTUnsyy1SN8ugSvj4GSZguN8Feu3fGZvYNzO3cXIySEhYCKx 4uE8NghbTOLCvfVANheHkMBJRomTC74zgySEBDYwSmz8WgWR2MUosa55KyuEs5ZR4vW03ewQ zjagzN/L7CAtvAKaEns/fwGyOThYBFQlTs4zAQmzCZhJPH+4BWyqqECyxLwNV5khygUlTs58 wgJiiwhoS5y59hAszizgK/HzxR6w84QFLCV+HTvBDLHrBKvEhU8nWEDmcwrYSpy74gZRbytx Yc51FghbXmL72znMEK+pSVw9twnqGy2J3rOdTBMYRWchWT0LSfssJO0LGJlXMbLnJmbmpJcb bWIEBv3BLb9VdzDeOSdyiFGag0VJnNd66x5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyL +D+lvdYXcpsrx/eiv6dpnpzSZ5/p/keVqmf2un1/KjY5R7C8Lt/G6/p8ZYsFMyItQ469+tz6 zOhx6MZ/GT5HDRS4nMTqLBMPSsW+YH/8dJdooeZlje/9PobGH3qeLTe/+Mhpk37DJK9NHBu/ 3RYX0Cp4H+ahXJGtkNRhc4bLZSr/hIOrDyqxFGckGmoxFxUnAgBr4GNHSAIAAA== Cc: insipid@ietf.org, 'Gonzalo Camarillo' Subject: Re: [Insipid] Handling (or not) of call transfer 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, 28 Oct 2012 06:37:46 -0000 On 10/28/12 12:09 AM, Paul E. Jones wrote: > Sal, > >>> This is REQ2 in the requirements document. Use case is in 3.6. >>> >>> How a transferred call is correlated would be defined by the solution. >>> The requirement is merely that it must be possible. We're not even >>> concerned necessarily with how the calls correlate, but merely that >> they are. >> >> I already suggested to somehow relax the last sentence of REQ.2 so that >> it does not include any possible link to the specific solution. >> Having thought more on it, I do think it would be even better remove >> completely the last sentence of REQ.2. >> In this way the requirement would be really merely that it must be >> possible! > My current draft has this sentence you provided: > "This must be possible regardless of any eventual change in the > value of the end-to-end Session-Identifier." > > I think we should say something. If we say nothing, then somebody might be > quite surprised to discover that the Session ID changes. It would be nice > if the ID never changed, but there are flows that occur in normal operation > where I cannot see how we could not change the Session ID. It only happens > in cases of call transfer, merging/joining calls, etc. So, having this as a > comment tacked onto the end of this requirement is helpful. > > We could remove that sentence, but I would not want somebody to say a > solution is not acceptable because the ID changes in certain flows. from my point of view the important is *the possibility to correlate sessions*, and this is what the requirement should emphasize. The fact that we correlate them through a header value that doesn't change, or change only partially or change in a predictable way are all solution choices that would meet the requirement. /Sal > > Paul > > From salvatore.loreto@ericsson.com Sat Oct 27 23:47: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 E9DF821F85EE for ; Sat, 27 Oct 2012 23:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.149 X-Spam-Level: X-Spam-Status: No, score=-105.149 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, 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 H5Bzhgd9aovv for ; Sat, 27 Oct 2012 23:47:31 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 37CA321F84B5 for ; Sat, 27 Oct 2012 23:47:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-06-508cd50137cd Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 28.6E.11564.105DC805; Sun, 28 Oct 2012 07:47:29 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Sun, 28 Oct 2012 07:47:29 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1FCCE2531; Sun, 28 Oct 2012 08:47:29 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 689C953699; Sun, 28 Oct 2012 08:47:28 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0DB1951BCF; Sun, 28 Oct 2012 08:47:28 +0200 (EET) Message-ID: <508CD500.8060805@ericsson.com> Date: Sun, 28 Oct 2012 08:47:28 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508C2C93.2080500@ericsson.com> <093b01cdb48f$9b988740$d2c995c0$@packetizer.com> In-Reply-To: <093b01cdb48f$9b988740$d2c995c0$@packetizer.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+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvrS7j1Z4Agxkd1hbz7z9jsjh/YQOT A5PHkiU/mTwa9h1lD2CK4rJJSc3JLEst0rdL4Mp4+PMHe8FBqYq53yYyNzCuEeli5OSQEDCR aD+7lgXCFpO4cG89WxcjF4eQwElGifXX+pghnA2MEh82TWGHcHYxSsz6sgrKWcsocaB5AVTZ NkaJztbvQMM4OHgFtCXWn8gHmcsioCrx+vs8RhCbTcBM4vnDLcwgtqhAssS8DVfBbF4BQYmT M5+A3SEC1Hrm2kOwOLOAiMS8Bb1gvcIC3hK3t5yH2vWdUaJjxx+wBKeArUTn1l0sEA22Ehfm XIey5SW2v53DDPGcmsTVc5vAbCEBLYnes51MExhFZyHZPQtJ+ywk7QsYmVcxsucmZuaklxtu YgSG/sEtv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxljm EqYJ61otE3eazn5sNfOM2FF9V66AFyz/7DduXMr/7uWLE+z2nz/+eeh+603Qmxdmgr3LllsJ /k3YqfLBepHM1lm//mRnPVDefd7jxtJ7TD2Sj2zbr+vcZLgXUjbng8Cb3acyKsJO8Z2dyHrs jvGHi7cm/5v5xehe2Vq/eF/De9cy4/kOF3ArsRRnJBpqMRcVJwIA+wvTZ0sCAAA= 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: Sun, 28 Oct 2012 06:47:33 -0000 On 10/28/12 1:08 AM, Paul E. Jones wrote: > On Sat, 27 Oct 2012 21:48:51 +0300, Salvatore Loreto wrote: >> Hi there >> >> I have read the 01 and have the following questions >> >> in Section 7. Processing by Intermediaries >> >> I don't find anything that explain when an intermediary is "allowed" >> to inject an identifier into the session signaling >> so to meet REQ7. >> >> REQ7: It must be possible to identity SIP traffic with an end-to-end >> session identifier from and to end devices that do not support this >> new identifier, such as by allowing an intermediary to inject an >> identifier into the session signaling. > How about this sentence: > If a SIP message having no Session-ID header is received by > an intermediary, the intermediary MAY assign a "local-uuid" > value to represent the sending endpoint and insert that value > into all signaling messages on behalf of the sending endpoint. we should also say what an Intermediary should do if it sees a SIP request with a Session-ID header but the answer does not contain it anymore or the answer contain only a copy of the Session-ID present in the request: i.e. what happen if the peer does not support the Session-ID header my guess is that it can - remove the Session-ID header or - just copy back it as it has been received. > >> Moreover Section 7 states >> >> Intermediaries MUST NOT alter the UUID values found in the Session-ID >> header, except as described in this section. >> and there is nothing the the section describing it. >> Do I have overlooked something ? > Intermediaries might change the value to facilitate call transfer, call > joins, > or insert values on behalf of endpoints. We may have more examples where > intermediaries change values. We do need language to restrict changes, > otherwise, devices might change things in any way they wish. my point was about the fact that I see as an alteration of the UUID also the possibility for an intermediary to insert it if it was not present in the original request or response. So I would like to have this point clarified in the draft. > >> I am a little puzzled from the aim of Section 9. >> There is nothing in that section that is necessary to fulfill the >> Req9c >> >> REQ9c: The identifier should be constructed in such a way as to make >> it suitable for transmission in SIP and RTCP [3 [18]]. > Yeah, this is left over from before. There is no normative language at > all. We had that there to indicate in what other ways this > value might be used, if we choose to define it. If we remove this > section, it would not change the solution. I agree, and I would suggest to remove it. thanks for your answers cheers Sal > > I'll let James address the comments on call flows. > > Paul > > >> 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 >> >> Cheers >> /Sal >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com [19] From paulej@packetizer.com Sun Oct 28 11:18:35 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D7121F8599 for ; Sun, 28 Oct 2012 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.683 X-Spam-Level: X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.916, 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 FjQ1GtCMskUN for ; Sun, 28 Oct 2012 11:18:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 363CB21F8538 for ; Sun, 28 Oct 2012 11:18:34 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9SIIUeA030892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Oct 2012 14:18:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351448311; bh=Jvm5PKlMTc1WDB3PmhniTkzbvQnN5rVsg34yX8c2Oww=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=t7c1ky6Njspl+v2o7ToIGKRKMZgXoPzTAbv/v/TeLxEWQ4UWHsW+Be647HlAQY+/G r4mVe3Xj/WkEAdRkenKj+Sb8M6SzDQCXDi+k8x8YssJod7WbVNd+L4mu3d4p6lccy1 Nlb7bsP18D+uqVKCF3YY+g3ik9Yci2P/sCXqjDEo= From: "Paul E. Jones" To: "'Salvatore Loreto'" References: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA60@ESESSCMS0356.eemea.ericsson.se>, <000901cda4c4$7e8bd150$7ba373f0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA64@ESESSCMS0356.eemea.ericsson.se> <001701cda4d0$409d35d0$c1d7a170$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A0585340BAD0164@ESESSCMS0356.eemea.ericsson.se> <007901cda53b$4355ea90$ca01bfb0$@packetizer.com> <5072AF90.7030403@ericsson.com> <02d701cda67e$cd5ebac0$681c3040$@packetizer.com> <50890D25.9030206@ericsson.com> <074601cdb33d$becf8360$3c6e8a20$@packetizer.com> <508C0473.9080105@ericsson.com> <092f01cdb487$52d55630$f8800290$@packetizer.com> <508CD2B6.90409@ericsson.com> In-Reply-To: <508CD2B6.90409@ericsson.com> Date: Sun, 28 Oct 2012 14:18:33 -0400 Message-ID: <099601cdb538$a47fb000$ed7f1000$@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: AQHMUGinKo5yVDx8rp6IDHd7T62sdwDK7b4JAqIHjqYBO7n5owC0nRDEAaQYqW0BccWwGgIfe52gAWcUoLwCIwtb8gKLh6U+APAT6ZMCxrOCUgKVdHOrlxosF5A= Content-Language: en-us Cc: insipid@ietf.org, 'Gonzalo Camarillo' Subject: Re: [Insipid] Handling (or not) of call transfer 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, 28 Oct 2012 18:18:35 -0000 Ok.. I removed the last sentence from REQ2. Paul > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Sunday, October 28, 2012 2:38 AM > To: Paul E. Jones > Cc: 'Gonzalo Camarillo'; insipid@ietf.org > Subject: Re: [Insipid] Handling (or not) of call transfer > > On 10/28/12 12:09 AM, Paul E. Jones wrote: > > Sal, > > > >>> This is REQ2 in the requirements document. Use case is in 3.6. > >>> > >>> How a transferred call is correlated would be defined by the > solution. > >>> The requirement is merely that it must be possible. We're not even > >>> concerned necessarily with how the calls correlate, but merely that > >> they are. > >> > >> I already suggested to somehow relax the last sentence of REQ.2 so > >> that it does not include any possible link to the specific solution. > >> Having thought more on it, I do think it would be even better remove > >> completely the last sentence of REQ.2. > >> In this way the requirement would be really merely that it must be > >> possible! > > My current draft has this sentence you provided: > > "This must be possible regardless of any eventual change in the > > value of the end-to-end Session-Identifier." > > > > I think we should say something. If we say nothing, then somebody > > might be quite surprised to discover that the Session ID changes. It > > would be nice if the ID never changed, but there are flows that occur > > in normal operation where I cannot see how we could not change the > > Session ID. It only happens in cases of call transfer, > > merging/joining calls, etc. So, having this as a comment tacked onto > the end of this requirement is helpful. > > > > We could remove that sentence, but I would not want somebody to say a > > solution is not acceptable because the ID changes in certain flows. > > from my point of view the important is *the possibility to correlate > sessions*, and this is what the requirement should emphasize. > > The fact that we correlate them through a header value that doesn't > change, or change only partially or change in a predictable way are all > solution choices that would meet the requirement. > > /Sal > > > > Paul > > > > > From paulej@packetizer.com Sun Oct 28 11:25:18 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 483E821F8645 for ; Sun, 28 Oct 2012 11:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 nRXoXRVBA1KM for ; Sun, 28 Oct 2012 11:25:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7215D21F8629 for ; Sun, 28 Oct 2012 11:25:17 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9SIPDNj031199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Oct 2012 14:25:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351448714; bh=8gNeHTIlb3ZXE8EPIIfPdSK6l05YEu7tvity+V7L61Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pWhU+Yyp0jhryLy2OrdoHk87Tv9HHH18HcFj7OzopsvshDKg4vLPmpF8w/eww2W8b u9om3NFKi9eA8WSlhUSM/9bfIEe2yERxMQRVZCTNEArCxdG+o6XTXFizl45RuuuUTG FdNQCT3FCWPWotIo79bqb6J24tUPPGVvxfHlT5gE= From: "Paul E. Jones" To: "'Salvatore Loreto'" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508C2C93.2080500@ericsson.com> <093b01cdb48f$9b988740$d2c995c0$@packetizer.com> <508CD500.8060805@ericsson.com> In-Reply-To: <508CD500.8060805@ericsson.com> Date: Sun, 28 Oct 2012 14:25:17 -0400 Message-ID: <099801cdb539$95050570$bf0f1050$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAq3j/p8Bu4ISfAKFWNbOAp9nX9GWD5qNEA== Content-Language: en-us 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: Sun, 28 Oct 2012 18:25:18 -0000 Sal, That gets into territory of "how do you deal with non-compliant endpoints". Either the Session-ID header is there or not. If it's there, I don't think the intermediary should take steps to ensure that it's fully-compliant with the spec. If it's missing entirely, that's different. The intermediary can act on behalf of the endpoint that does not support the header. Perhaps I'm missing your point, but if we need language related to interworking with Kaplan entities, we should find proper wording in Section 11. Right now, we're not 100% sure how those entities behave, so some work is probably needed in Section 11. Paul > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Sunday, October 28, 2012 2:47 AM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid- > session-id > > On 10/28/12 1:08 AM, Paul E. Jones wrote: > > On Sat, 27 Oct 2012 21:48:51 +0300, Salvatore Loreto wrote: > >> Hi there > >> > >> I have read the 01 and have the following questions > >> > >> in Section 7. Processing by Intermediaries > >> > >> I don't find anything that explain when an intermediary is > "allowed" > >> to inject an identifier into the session signaling > >> so to meet REQ7. > >> > >> REQ7: It must be possible to identity SIP traffic with an end-to- > end > >> session identifier from and to end devices that do not support this > >> new identifier, such as by allowing an intermediary to inject an > >> identifier into the session signaling. > > How about this sentence: > > If a SIP message having no Session-ID header is received by > > an intermediary, the intermediary MAY assign a "local-uuid" > > value to represent the sending endpoint and insert that value > > into all signaling messages on behalf of the sending endpoint. > > we should also say what an Intermediary should do if it sees a SIP > request with a Session-ID header but the answer does not contain it > anymore or the answer contain only a copy of the Session-ID present in > the request: > i.e. what happen if the peer does not support the Session-ID header my > guess is that it can > - remove the Session-ID header > or > - just copy back it as it has been received. > > > > > > > >> Moreover Section 7 states > >> > >> Intermediaries MUST NOT alter the UUID values found in the Session- > ID > >> header, except as described in this section. > >> and there is nothing the the section describing it. > >> Do I have overlooked something ? > > Intermediaries might change the value to facilitate call transfer, > > call joins, or insert values on behalf of endpoints. We may have more > > examples where intermediaries change values. We do need language to > > restrict changes, otherwise, devices might change things in any way > > they wish. > my point was about the fact that I see as an alteration of the UUID also > the possibility for an intermediary to insert it if it was not present > in the original request or response. > > So I would like to have this point clarified in the draft. > > > > >> I am a little puzzled from the aim of Section 9. > >> There is nothing in that section that is necessary to fulfill the > >> Req9c > >> > >> REQ9c: The identifier should be constructed in such a way as to > make > >> it suitable for transmission in SIP and RTCP [3 [18]]. > > Yeah, this is left over from before. There is no normative language > > at all. We had that there to indicate in what other ways this value > > might be used, if we choose to define it. If we remove this section, > > it would not change the solution. > > I agree, and I would suggest to remove it. > > thanks for your answers > > cheers > Sal > > > > > > I'll let James address the comments on call flows. > > > > Paul > > > > > >> 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 > >> > >> Cheers > >> /Sal > >> > >> -- > >> Salvatore Loreto, PhD > >> www.sloreto.com [19] > From salvatore.loreto@ericsson.com Sun Oct 28 12:10: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 4483021F85C1 for ; Sun, 28 Oct 2012 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.474 X-Spam-Level: X-Spam-Status: No, score=-105.474 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=0.6, 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 UZN+u+0NG9pn for ; Sun, 28 Oct 2012 12:10:18 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8E121F85B1 for ; Sun, 28 Oct 2012 12:10:17 -0700 (PDT) X-AuditID: c1b4fb30-b7f936d0000018b3-c5-508d8318c188 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 04.CD.06323.8138D805; Sun, 28 Oct 2012 20:10:16 +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; Sun, 28 Oct 2012 20:10:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 814D424C7; Sun, 28 Oct 2012 21:10:15 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EFE9053699; Sun, 28 Oct 2012 21:10:14 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 50AA651BCF; Sun, 28 Oct 2012 21:10:14 +0200 (EET) Message-ID: <508D8316.6040807@ericsson.com> Date: Sun, 28 Oct 2012 21:10:14 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508C2C93.2080500@ericsson.com> <093b01cdb48f$9b988740$d2c995c0$@packetizer.com> <508CD500.8060805@ericsson.com> <099801cdb539$95050570$bf0f1050$@packetizer.com> In-Reply-To: <099801cdb539$95050570$bf0f1050$@packetizer.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+Jvra5Ec2+AweU5Ihbz7z9jsjh/YQOT A5PHkiU/mTwa9h1lD2CK4rJJSc3JLEst0rdL4Mo4+LyLteCqesXxw+uZGhjfy3UxcnJICJhI XNjwgw3CFpO4cG89kM3FISRwklFi6+UbUM4GRonvi1+zQzi7gJx1/SwQzlpGiecXF0NltjFK 3N7byA4yjFdAW2L2/TOsXYwcHCwCqhIvtuWAhNkEzCSeP9zCDGKLCiRLzNtwlRmiXFDi5Mwn LCC2CFDrmWsPweLMAiIS8xb0MoLYwgLeEre3nAeLCwmcYJJ4MScAZDyngK3E74YAiHJbiQtz rrNA2PIS29/OYYZ4TU3i6rlNUK1aEr1nO5kmMIrOQrJ5FpL2WUjaFzAyr2Jkz03MzEkvN9/E CAz7g1t+G+xg3HRf7BCjNAeLkjivnup+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MPvWl e/bNz7ut/60n2WeF+bSD37c/D0mM6t72UIgvtWJ32M1pRT7nrl6T3lT0KXx1bpSWvzqzqt2F jWY2aY9Z5yRd/lHsef/Nymefi6ZeOLImLmKq5IXPc4uEbHvMXxj9+7+Wv0Tv6bWFOhMPW32V Fr/2Y9GEKD356ed/27N1fNBe8r0rJWD+UiWW4oxEQy3mouJEAIdUxT1JAgAA 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: Sun, 28 Oct 2012 19:10:19 -0000 On 10/28/12 8:25 PM, Paul E. Jones wrote: > Sal, > > That gets into territory of "how do you deal with non-compliant endpoints". > Either the Session-ID header is there or not. If it's there, I don't think > the intermediary should take steps to ensure that it's fully-compliant with > the spec. If it's missing entirely, that's different. The intermediary can > act on behalf of the endpoint that does not support the header. what I am trying to understand is what will do (or is allowed to do) an intermediary in the case it seats in between a Session-ID compliant end point that is trying to contact a non compliant end-point. what you explain in the previous mail was the opposite scenario where an intermediary seats in between a non Session-ID compliant end point that is trying to contact a compliant end point. /Sal -- Salvatore Loreto, PhD www.sloreto.com > > Perhaps I'm missing your point, but if we need language related to > interworking with Kaplan entities, we should find proper wording in Section > 11. Right now, we're not 100% sure how those entities behave, so some work > is probably needed in Section 11. > > Paul > >> -----Original Message----- >> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] >> Sent: Sunday, October 28, 2012 2:47 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid- >> session-id >> >> On 10/28/12 1:08 AM, Paul E. Jones wrote: >>> On Sat, 27 Oct 2012 21:48:51 +0300, Salvatore Loreto wrote: >>>> Hi there >>>> >>>> I have read the 01 and have the following questions >>>> >>>> in Section 7. Processing by Intermediaries >>>> >>>> I don't find anything that explain when an intermediary is >> "allowed" >>>> to inject an identifier into the session signaling >>>> so to meet REQ7. >>>> >>>> REQ7: It must be possible to identity SIP traffic with an end-to- >> end >>>> session identifier from and to end devices that do not support this >>>> new identifier, such as by allowing an intermediary to inject an >>>> identifier into the session signaling. >>> How about this sentence: >>> If a SIP message having no Session-ID header is received by >>> an intermediary, the intermediary MAY assign a "local-uuid" >>> value to represent the sending endpoint and insert that value >>> into all signaling messages on behalf of the sending endpoint. >> we should also say what an Intermediary should do if it sees a SIP >> request with a Session-ID header but the answer does not contain it >> anymore or the answer contain only a copy of the Session-ID present in >> the request: >> i.e. what happen if the peer does not support the Session-ID header my >> guess is that it can >> - remove the Session-ID header >> or >> - just copy back it as it has been received. >> >> >> >> >>>> Moreover Section 7 states >>>> >>>> Intermediaries MUST NOT alter the UUID values found in the Session- >> ID >>>> header, except as described in this section. >>>> and there is nothing the the section describing it. >>>> Do I have overlooked something ? >>> Intermediaries might change the value to facilitate call transfer, >>> call joins, or insert values on behalf of endpoints. We may have more >>> examples where intermediaries change values. We do need language to >>> restrict changes, otherwise, devices might change things in any way >>> they wish. >> my point was about the fact that I see as an alteration of the UUID also >> the possibility for an intermediary to insert it if it was not present >> in the original request or response. >> >> So I would like to have this point clarified in the draft. >> >>>> I am a little puzzled from the aim of Section 9. >>>> There is nothing in that section that is necessary to fulfill the >>>> Req9c >>>> >>>> REQ9c: The identifier should be constructed in such a way as to >> make >>>> it suitable for transmission in SIP and RTCP [3 [18]]. >>> Yeah, this is left over from before. There is no normative language >>> at all. We had that there to indicate in what other ways this value >>> might be used, if we choose to define it. If we remove this section, >>> it would not change the solution. >> I agree, and I would suggest to remove it. >> >> thanks for your answers >> >> cheers >> Sal >> >> >>> I'll let James address the comments on call flows. >>> >>> Paul >>> >>> >>>> 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 >>>> >>>> Cheers >>>> /Sal >>>> >>>> -- >>>> Salvatore Loreto, PhD >>>> www.sloreto.com > From paulej@packetizer.com Sun Oct 28 13:33:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4805A21F853E for ; Sun, 28 Oct 2012 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] 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 SevUecuTlFHv for ; Sun, 28 Oct 2012 13:33:37 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3299521F853F for ; Sun, 28 Oct 2012 13:33:37 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9SKXXK8004236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Oct 2012 16:33:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351456414; bh=C72q4JYCwLWto+bkttSCWHiSmtr08YkqkE9xKPfjI1w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=iQ7dBzZLd0xsbLjrPeZDaOeiI7WHdrv3fJKEw2BbuUWpziDkJH2OckqPtQvTvBw93 FauMmEx5K1PLU3MZDrzGOmOebZ+m5+HHMvpFqHUFXmZD5Wp5XaHQD4ohb+hOZhESyF fBJbGrHwPQGJht0XSr/h+mftpHveqorE3D/PjMHs= From: "Paul E. Jones" To: "'Salvatore Loreto'" References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <201210260045.q9Q0jV0I019641@rcdn-core-4.cisco.com> <508C2C93.2080500@ericsson.com> <093b01cdb48f$9b988740$d2c995c0$@packetizer.com> <508CD500.8060805@ericsson.com> <099801cdb539$95050570$bf0f1050$@packetizer.com> <508D8316.6040807@ericsson.com> In-Reply-To: <508D8316.6040807@ericsson.com> Date: Sun, 28 Oct 2012 16:33:37 -0400 Message-ID: <09c501cdb54b$825537d0$86ffa770$@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: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAq3j/p8Bu4ISfAKFWNbOAp9nX9ECqBzm7AJ7XSL1leaiCpA= Content-Language: en-us 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: Sun, 28 Oct 2012 20:33:38 -0000 Sal, Current text says: If a SIP message having no Session-ID header is received by an intermediary, the intermediary MAY assign a "local-uuid" value to represent the sending endpoint and insert that value into all signaling messages on behalf of the sending endpoint. So, if Alice calls Bob and Bob does not insert a Session-ID, you want to know what happens. The above text would still apply, but perhaps it's not clear. The intermediary may assign the "local-uuid" value that represents Bob. What is missing is an explicit statement that says that the intermediary should insert the appropriate "remote" value for Alice. Perhaps we add this? If the intermediary is aware of a "remote" value that identifies the receiving UA, it MUST insert that value if also inserting the "local-uuid" value. Feel free to suggest other wording. Paul > -----Original Message----- > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > Sent: Sunday, October 28, 2012 3:10 PM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid- > session-id > > On 10/28/12 8:25 PM, Paul E. Jones wrote: > > Sal, > > > > That gets into territory of "how do you deal with non-compliant > endpoints". > > Either the Session-ID header is there or not. If it's there, I don't > > think the intermediary should take steps to ensure that it's > > fully-compliant with the spec. If it's missing entirely, that's > > different. The intermediary can act on behalf of the endpoint that > does not support the header. > what I am trying to understand is what will do (or is allowed to do) an > intermediary in the case it seats in between a Session-ID compliant end > point that is trying to contact a non compliant end-point. > > what you explain in the previous mail was the opposite scenario where an > intermediary seats in between a non Session-ID compliant end point that > is trying to contact a compliant end point. > > /Sal > > -- > Salvatore Loreto, PhD > www.sloreto.com > > > > > > Perhaps I'm missing your point, but if we need language related to > > interworking with Kaplan entities, we should find proper wording in > Section > > 11. Right now, we're not 100% sure how those entities behave, so some > work > > is probably needed in Section 11. > > > > > > Paul > > > >> -----Original Message----- > >> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] > >> Sent: Sunday, October 28, 2012 2:47 AM > >> To: Paul E. Jones > >> Cc: insipid@ietf.org > >> Subject: Re: [Insipid] Changes to the -01 of draft-jones-insipid- > >> session-id > >> > >> On 10/28/12 1:08 AM, Paul E. Jones wrote: > >>> On Sat, 27 Oct 2012 21:48:51 +0300, Salvatore Loreto wrote: > >>>> Hi there > >>>> > >>>> I have read the 01 and have the following questions > >>>> > >>>> in Section 7. Processing by Intermediaries > >>>> > >>>> I don't find anything that explain when an intermediary is > >> "allowed" > >>>> to inject an identifier into the session signaling > >>>> so to meet REQ7. > >>>> > >>>> REQ7: It must be possible to identity SIP traffic with an end- > to- > >> end > >>>> session identifier from and to end devices that do not support > this > >>>> new identifier, such as by allowing an intermediary to inject an > >>>> identifier into the session signaling. > >>> How about this sentence: > >>> If a SIP message having no Session-ID header is received by > >>> an intermediary, the intermediary MAY assign a "local-uuid" > >>> value to represent the sending endpoint and insert that value > >>> into all signaling messages on behalf of the sending endpoint. > >> we should also say what an Intermediary should do if it sees a SIP > >> request with a Session-ID header but the answer does not contain it > >> anymore or the answer contain only a copy of the Session-ID present > in > >> the request: > >> i.e. what happen if the peer does not support the Session-ID header > my > >> guess is that it can > >> - remove the Session-ID header > >> or > >> - just copy back it as it has been received. > >> > >> > >> > >> > >>>> Moreover Section 7 states > >>>> > >>>> Intermediaries MUST NOT alter the UUID values found in the > Session- > >> ID > >>>> header, except as described in this section. > >>>> and there is nothing the the section describing it. > >>>> Do I have overlooked something ? > >>> Intermediaries might change the value to facilitate call transfer, > >>> call joins, or insert values on behalf of endpoints. We may have > more > >>> examples where intermediaries change values. We do need language to > >>> restrict changes, otherwise, devices might change things in any way > >>> they wish. > >> my point was about the fact that I see as an alteration of the UUID > also > >> the possibility for an intermediary to insert it if it was not > present > >> in the original request or response. > >> > >> So I would like to have this point clarified in the draft. > >> > >>>> I am a little puzzled from the aim of Section 9. > >>>> There is nothing in that section that is necessary to fulfill > the > >>>> Req9c > >>>> > >>>> REQ9c: The identifier should be constructed in such a way as to > >> make > >>>> it suitable for transmission in SIP and RTCP [3 [18]]. > >>> Yeah, this is left over from before. There is no normative language > >>> at all. We had that there to indicate in what other ways this value > >>> might be used, if we choose to define it. If we remove this section, > >>> it would not change the solution. > >> I agree, and I would suggest to remove it. > >> > >> thanks for your answers > >> > >> cheers > >> Sal > >> > >> > >>> I'll let James address the comments on call flows. > >>> > >>> Paul > >>> > >>> > >>>> 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 > >>>> > >>>> Cheers > >>>> /Sal > >>>> > >>>> -- > >>>> Salvatore Loreto, PhD > >>>> www.sloreto.com > > From R.Jesske@telekom.de Mon Oct 29 07:22: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 B2C8C21F86F0 for ; Mon, 29 Oct 2012 07:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 0yEed3k2qCKd for ; Mon, 29 Oct 2012 07:22:00 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 237E621F86ED for ; Mon, 29 Oct 2012 07:21:58 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 29 Oct 2012 15:18:40 +0100 Received: from HE111648.emea1.cds.t-internal.com ([10.134.93.17]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 29 Oct 2012 15:18:39 +0100 From: To: , Date: Mon, 29 Oct 2012 15:18:37 +0100 Thread-Topic: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF Thread-Index: Ac2z9UlQYFt+sBB+RCi3WRB+Xm1oYgB47xqA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AD284CCA@HE111648.emea1.cds.t-internal.com> References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <508AC658.4000901@alum.mit.edu> <081601cdb3c5$0aa028d0$1fe07a70$@packetizer.com> <508B0DD1.8010906@alum.mit.edu> <082001cdb3ce$f8cad650$ea6082f0$@packetizer.com> <508B5823.2030503@alum.mit.edu> In-Reply-To: <508B5823.2030503@alum.mit.edu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 29 Oct 2012 14:22:01 -0000 Hi Paul and Paul, Now my question is: Is this now backward compatible as we tried to be some mails earlier? > >>>>> > >>>>> Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI > >>>>> sess-id-param] > >>>>> > >>>>> sess-id-param =3D rcvr-uuid / generic-param > >>>>> > >>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>>>> > >>>>> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) Thank you and Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Samstag, 27. Oktober 2012 05:42 > An: Paul E. Jones > Cc: insipid@ietf.org > Betreff: Re: [Insipid] FW: I-D Action: > draft-jones-insipid-session-id-01.txt - ABNF > > This all seems fine to me! > > Thanks, > Paul > > On 10/26/12 7:09 PM, Paul E. Jones wrote: > > OK... looks good. Taking that and doing more tweaks: > > > > session-id =3D "Session-ID" HCOLON local-uuid > > *(SEMI sess-id-param) > > > > local-uuid =3D sess-uuid > > > > remote-uuid =3D sess-uuid > > > > sess-uuid =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > sess-id-param =3D remote-param / generic-param > > > > remote-param =3D "remote" EQUAL remote-uuid > > > > How does that look? You're right about the complexity of the > > sess-id-params. Trying to use syntax to prevent multiple "remote" > > parameters will not work, anyway, since there is nothing in > syntax to > > prevent some "other" generic-param from having the value "remote". > > So, we just have to insert a normative statement like this: > > > > The Session-ID header MUST NOT have more than one > "remote" parameter. > > > > Look good? I hope I didn't introduce an error. > > > > Paul > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Friday, October 26, 2012 6:25 PM > >> To: Paul E. Jones > >> Cc: insipid@ietf.org > >> Subject: Re: [Insipid] FW: I-D Action: > >> draft-jones-insipid-session-id- 01.txt - ABNF > >> > >> I am ok with what you propose. Others may call it overkill. > >> There is an understanding (I'm not certain if it is written down) > >> that a single header parameter can be used at most once within a > >> given header field. And if that isn't enough, it can be > stated in text. > >> > >> But I have no trouble with doing it in the syntax as you > show. It is > >> easy to do in syntax as long as there is only a single > parameter. (It > >> gets messier when there are several parameters and each > can appear at > >> most once. Then people must give up and use text.) > >> > >> Otherwise, we may want to tweak the syntax more in order to give > >> names that work well with the descriptions in the text. > For instance: > >> > >> Session-ID =3D "Session-ID" HCOLON local-uuid [sess-id-params] > >> > >> local-uuid =3D sess-uuid > >> > >> sess-uuid =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >> > >> sess-id-params =3D *(SEMI generic-param) SEMI remote-id-param > >> *(SEMI generic-param) > >> > >> remote-id-param =3D "remote" EQUAL remote-uuid > >> > >> remote-uuid =3D sess-uuid > >> > >> This is using the same local/remote terminology that 3261 uses for > >> dialog state. > >> > >> Thanks, > >> Paul > >> > >> On 10/26/12 5:58 PM, Paul E. Jones wrote: > >>> Paul, > >>> > >>> Merging what you propose and my changes from an hour or > so earlier, > >>> how is > >>> this: > >>> > >>> Session-ID =3D "Session-ID" HCOLON endpt-id [sess-id-params] > >>> > >>> endpt-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>> > >>> sess-id-params =3D *(SEMI generic-param) SEMI rcvr-uuid > >>> *(SEMI generic-param) > >>> > >>> rcvr-uuid =3D "rcvr" EQUAL endpt-id > >>> > >>> Paul > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>> Sent: Friday, October 26, 2012 1:20 PM > >>>> To: Paul E. Jones > >>>> Cc: insipid@ietf.org > >>>> Subject: Re: [Insipid] FW: I-D Action: > >>>> draft-jones-insipid-session-id- 01.txt - ABNF > >>>> > >>>> On 10/26/12 2:12 AM, Paul E. Jones wrote: > >>>>> Paul, > >>>>> > >>>>> OK... I now have this: > >>>>> > >>>>> Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI > >>>>> sess-id-param] > >>>>> > >>>>> sess-id-param =3D rcvr-uuid / generic-param > >>>>> > >>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>>>> > >>>>> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) > >>>> > >>>> OK, now I'm moving to the esthetics of ABNF writing. None of the > >>>> following changes what may be validly written. > >>>> > >>>> 1) the name of the header field is "Session-ID", so I > would expect > >>>> that a non-terminal in the syntax called would > describe > >>>> be the fundamental thing. But in the above it isn't. It > is *half* > >>>> of the ID of a communication session. (Except in the > compatibility > >>>> cases.) > >>>> > >>>> 2) I really dislike when specialized piece of syntax is > repeated in > >>>> two places rather than being defined once and referenced twice. > >>>> Doing so suggests that any resemblance between the two is > >>>> incidental rather than fundamental. In this case the syntax for > >>>> and the value part of are > fundamentally the same. > >>>> > >>>> In my prior proposals I addressed (2), but not (1). Here is a > >>>> proposal that addresses them both: > >>>> > >>>> Session-ID =3D "Session-ID" HCOLON endpt-id > *[SEMI sess-id- > >> param] > >>>> > >>>> endpt-id =3D 32(DIGIT / %x61-66) ;32 chars > of [0-9a-f] > >>>> > >>>> sess-id-param =3D rcvr-id / generic-param > >>>> > >>>> rcvr-id =3D "rcvr" EQUAL endpt-id > >>>> > >>>> The above does not explicitly state that can appear at > >>>> most once. That is a general rule for header field > parameters. It > >>>> could be specified in text for emphasis. > >>>> > >>>> Thanks, > >>>> Paul K > >>>> > >>>>> I could change the hex digits, but that would not be compatible > >>>>> with the Kaplan draft. > >>>>> > >>>>> Paul > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] > >>>>>> On Behalf Of Paul Kyzivat > >>>>>> Sent: Thursday, October 25, 2012 12:09 PM > >>>>>> To: insipid@ietf.org > >>>>>> Subject: Re: [Insipid] FW: I-D Action: > >>>>>> draft-jones-insipid-session-id- 01.txt - ABNF > >>>>>> > >>>>>> On 10/25/12 8:53 AM, Christer Holmberg wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> One comment on the ABNF. > >>>>>>> > >>>>>>> First, I've had off-line discussions with the > authors, where we > >>>>>>> in > >>>>>> order to be backward compatible with draft-kaplan > agreed on the > >>>>>> following things: > >>>>>>> > >>>>>>> 1. The ABNF will be backward compatible 2. Entities must be > >>>>>>> prepared to receive a value that does not contain a value > >>>>>>> inserted by the remote peer > >>>>>>> > >>>>>>> ...so my comment is based on those assumptions. > >>>>>>> > >>>>>>> > >>>>>>> Q_ABNF-1: In order to be backward compatible, > rcvr-uuid needs > > to > >>>> be > >>>>>> optional. I would suggest the following: > >>>>>>> > >>>>>>> Session-ID =3D "Session-ID" HCOLON sess-id [SEMI > rcvr-uuid] > >> *(SEMI > >>>>>>> generic-param) > >>>>>>> > >>>>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>>>>>> > >>>>>>> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) > >>>>>>> > >>>>>>> > >>>>>>> In fact, I am not aware of any current > implementations that use > >>>>>>> the > >>>>>> generic-param for anything, so we could even do the following: > >>>>>>> > >>>>>>> Session-ID =3D "Session-ID" HCOLON sess-id [SEMI rcvr-uuid > >> *(SEMI > >>>>>>> generic-param)] > >>>>>> > >>>>>> IMO it is bad practice to require a specific ordering > among params. > >>>>>> So I would prefer: > >>>>>> > >>>>>> Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI > sess-id-param] > >>>>>> > >>>>>> sess-id-param =3D rcvr-uuid / generic-param > >>>>>> > >>>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > >>>>>> > >>>>>> rcvr-uuid =3D "rcvr" EQUAL sess-id > >>>>>> > >>>>>> Another thing: the above only permits lower case hex. For > >>>>>> consistency with common usage both lower and upper > case should be > >>>>>> permitted. This can be done by: > >>>>>> > >>>>>> sess-id =3D 32 HEXDIG (from 5234, used in 3261) > >>>>>> > >>>>>> And is there any reason to require leading zeros in > the sess-id? > >>>>>> If not, that can be specified via > >>>>>> > >>>>>> sess-id =3D 1*32 HEXDIG > >>>>>> or maybe > >>>>>> sess-id =3D 1*16 (HEXDIG HEXDIG) > >>>>>> > >>>>>> Or does backward compatibility require restricting to > lower case > >>>>>> and exactly 32 digits? > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> insipid mailing list > >>>>>> insipid@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/insipid > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From paulej@packetizer.com Mon Oct 29 09:08:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1884021F8739 for ; Mon, 29 Oct 2012 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.555, 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 bw1bB5LpMihS for ; Mon, 29 Oct 2012 09:08:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DC28421F86E7 for ; Mon, 29 Oct 2012 09:08:18 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q9TG8GkK032269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 12:08:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1351526897; bh=U3MsqEdLZkZC0GeuS7AXfcFV3boW0qMhdW/IcyAYwiQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=W2RQR+ocCz8FPz6GF6n+ImVKJ+Bq/mpjJ36JabFOthFwuoyGv4/Df3iUa7khFQb8E /bdb0RHIpkODfVlx7N2RAfrnuksfLNCtCrh7UFXl1IJ25NoEeOx9J3xspa1iCXOjOH eVmASpfyV2V1wH3z59stOi5a8xU53dqWkDGz9tt8= From: "Paul E. Jones" To: , References: <20121022233415.25252.78101.idtracker@ietfa.amsl.com> <031a01cdb0be$ae957e40$0bc07ac0$@packetizer.com> <7594FB04B1934943A5C02806D1A2204B01E4E7@ESESSMB209.ericsson.se> <50896417.5080400@alum.mit.edu> <074c01cdb340$d79cd1b0$86d67510$@packetizer.com> <508AC658.4000901@alum.mit.edu> <081601cdb3c5$0aa028d0$1fe07a70$@packetizer.com> <508B0DD1.8010906@alum.mit.edu> <082001cdb3ce$f8cad650$ea6082f0$@packetizer.com> <508B5823.2030503@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D15AD284CCA@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D15AD284CCA@HE111648.emea1.cds.t-internal.com> Date: Mon, 29 Oct 2012 12:08:22 -0400 Message-ID: <0ad101cdb5ef$9ed14b20$dc73e160$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+FC3LKjFKdFVesKl+7nTpe5/EuQJHxIAbAimuJOYBpCKyfQLUOGOKAn6bPO4Cq5r1kwHTmubWAf9ppecCO74RegHIfctFlcBb+eA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] FW: I-D Action: draft-jones-insipid-session-id-01.txt - ABNF 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, 29 Oct 2012 16:08:20 -0000 I believe the syntax is. I do not know about semantics. The syntax would be: Alice (initial INVITE): Session-ID: 438f03a3fd4f420494ed7d38891123ef Bob (e.g., 200): Session-ID: ee270c18dbcd4e11bb14a0bc10005517 ; remote=3D438f03a3fd4f420494ed7d38891123ef Paul > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, October 29, 2012 10:19 AM > To: pkyzivat@alum.mit.edu; paulej@packetizer.com > Cc: insipid@ietf.org > Subject: AW: [Insipid] FW: I-D Action: draft-jones-insipid-session-id- > 01.txt - ABNF >=20 > Hi Paul and Paul, > Now my question is: >=20 > Is this now backward compatible as we tried to be some mails earlier? >=20 > > >>>>> > > >>>>> Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI > > >>>>> sess-id-param] > > >>>>> > > >>>>> sess-id-param =3D rcvr-uuid / generic-param > > >>>>> > > >>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of = [0-9a-f] > > >>>>> > > >>>>> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) >=20 > Thank you and Best Regards >=20 > Roland >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: insipid-bounces@ietf.org > > [mailto:insipid-bounces@ietf.org] Im Auftrag von Paul Kyzivat > > Gesendet: Samstag, 27. Oktober 2012 05:42 > > An: Paul E. Jones > > Cc: insipid@ietf.org > > Betreff: Re: [Insipid] FW: I-D Action: > > draft-jones-insipid-session-id-01.txt - ABNF > > > > This all seems fine to me! > > > > Thanks, > > Paul > > > > On 10/26/12 7:09 PM, Paul E. Jones wrote: > > > OK... looks good. Taking that and doing more tweaks: > > > > > > session-id =3D "Session-ID" HCOLON local-uuid > > > *(SEMI sess-id-param) > > > > > > local-uuid =3D sess-uuid > > > > > > remote-uuid =3D sess-uuid > > > > > > sess-uuid =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > > > > > sess-id-param =3D remote-param / generic-param > > > > > > remote-param =3D "remote" EQUAL remote-uuid > > > > > > How does that look? You're right about the complexity of the > > > sess-id-params. Trying to use syntax to prevent multiple "remote" > > > parameters will not work, anyway, since there is nothing in > > syntax to > > > prevent some "other" generic-param from having the value "remote". > > > So, we just have to insert a normative statement like this: > > > > > > The Session-ID header MUST NOT have more than one > > "remote" parameter. > > > > > > Look good? I hope I didn't introduce an error. > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > >> Sent: Friday, October 26, 2012 6:25 PM > > >> To: Paul E. Jones > > >> Cc: insipid@ietf.org > > >> Subject: Re: [Insipid] FW: I-D Action: > > >> draft-jones-insipid-session-id- 01.txt - ABNF > > >> > > >> I am ok with what you propose. Others may call it overkill. > > >> There is an understanding (I'm not certain if it is written down) > > >> that a single header parameter can be used at most once within a > > >> given header field. And if that isn't enough, it can be > > stated in text. > > >> > > >> But I have no trouble with doing it in the syntax as you > > show. It is > > >> easy to do in syntax as long as there is only a single > > parameter. (It > > >> gets messier when there are several parameters and each > > can appear at > > >> most once. Then people must give up and use text.) > > >> > > >> Otherwise, we may want to tweak the syntax more in order to give > > >> names that work well with the descriptions in the text. > > For instance: > > >> > > >> Session-ID =3D "Session-ID" HCOLON local-uuid = [sess-id-params] > > >> > > >> local-uuid =3D sess-uuid > > >> > > >> sess-uuid =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > >> > > >> sess-id-params =3D *(SEMI generic-param) SEMI remote-id-param > > >> *(SEMI generic-param) > > >> > > >> remote-id-param =3D "remote" EQUAL remote-uuid > > >> > > >> remote-uuid =3D sess-uuid > > >> > > >> This is using the same local/remote terminology that 3261 uses = for > > >> dialog state. > > >> > > >> Thanks, > > >> Paul > > >> > > >> On 10/26/12 5:58 PM, Paul E. Jones wrote: > > >>> Paul, > > >>> > > >>> Merging what you propose and my changes from an hour or > > so earlier, > > >>> how is > > >>> this: > > >>> > > >>> Session-ID =3D "Session-ID" HCOLON endpt-id [sess-id-params] > > >>> > > >>> endpt-id =3D 32(DIGIT / %x61-66) ;32 chars of [0-9a-f] > > >>> > > >>> sess-id-params =3D *(SEMI generic-param) SEMI rcvr-uuid > > >>> *(SEMI generic-param) > > >>> > > >>> rcvr-uuid =3D "rcvr" EQUAL endpt-id > > >>> > > >>> Paul > > >>> > > >>>> -----Original Message----- > > >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > >>>> Sent: Friday, October 26, 2012 1:20 PM > > >>>> To: Paul E. Jones > > >>>> Cc: insipid@ietf.org > > >>>> Subject: Re: [Insipid] FW: I-D Action: > > >>>> draft-jones-insipid-session-id- 01.txt - ABNF > > >>>> > > >>>> On 10/26/12 2:12 AM, Paul E. Jones wrote: > > >>>>> Paul, > > >>>>> > > >>>>> OK... I now have this: > > >>>>> > > >>>>> Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI > > >>>>> sess-id-param] > > >>>>> > > >>>>> sess-id-param =3D rcvr-uuid / generic-param > > >>>>> > > >>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of = [0-9a-f] > > >>>>> > > >>>>> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) > > >>>> > > >>>> OK, now I'm moving to the esthetics of ABNF writing. None of = the > > >>>> following changes what may be validly written. > > >>>> > > >>>> 1) the name of the header field is "Session-ID", so I > > would expect > > >>>> that a non-terminal in the syntax called would > > describe > > >>>> be the fundamental thing. But in the above it isn't. It > > is *half* > > >>>> of the ID of a communication session. (Except in the > > compatibility > > >>>> cases.) > > >>>> > > >>>> 2) I really dislike when specialized piece of syntax is > > repeated in > > >>>> two places rather than being defined once and referenced twice. > > >>>> Doing so suggests that any resemblance between the two is > > >>>> incidental rather than fundamental. In this case the syntax for > > >>>> and the value part of are > > fundamentally the same. > > >>>> > > >>>> In my prior proposals I addressed (2), but not (1). Here is a > > >>>> proposal that addresses them both: > > >>>> > > >>>> Session-ID =3D "Session-ID" HCOLON endpt-id > > *[SEMI sess-id- > > >> param] > > >>>> > > >>>> endpt-id =3D 32(DIGIT / %x61-66) ;32 chars > > of [0-9a-f] > > >>>> > > >>>> sess-id-param =3D rcvr-id / generic-param > > >>>> > > >>>> rcvr-id =3D "rcvr" EQUAL endpt-id > > >>>> > > >>>> The above does not explicitly state that can appear = at > > >>>> most once. That is a general rule for header field > > parameters. It > > >>>> could be specified in text for emphasis. > > >>>> > > >>>> Thanks, > > >>>> Paul K > > >>>> > > >>>>> I could change the hex digits, but that would not be = compatible > > >>>>> with the Kaplan draft. > > >>>>> > > >>>>> Paul > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: insipid-bounces@ietf.org > > [mailto:insipid-bounces@ietf.org] > > >>>>>> On Behalf Of Paul Kyzivat > > >>>>>> Sent: Thursday, October 25, 2012 12:09 PM > > >>>>>> To: insipid@ietf.org > > >>>>>> Subject: Re: [Insipid] FW: I-D Action: > > >>>>>> draft-jones-insipid-session-id- 01.txt - ABNF > > >>>>>> > > >>>>>> On 10/25/12 8:53 AM, Christer Holmberg wrote: > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> One comment on the ABNF. > > >>>>>>> > > >>>>>>> First, I've had off-line discussions with the > > authors, where we > > >>>>>>> in > > >>>>>> order to be backward compatible with draft-kaplan > > agreed on the > > >>>>>> following things: > > >>>>>>> > > >>>>>>> 1. The ABNF will be backward compatible 2. Entities must be > > >>>>>>> prepared to receive a value that does not contain a value > > >>>>>>> inserted by the remote peer > > >>>>>>> > > >>>>>>> ...so my comment is based on those assumptions. > > >>>>>>> > > >>>>>>> > > >>>>>>> Q_ABNF-1: In order to be backward compatible, > > rcvr-uuid needs > > > to > > >>>> be > > >>>>>> optional. I would suggest the following: > > >>>>>>> > > >>>>>>> Session-ID =3D "Session-ID" HCOLON sess-id [SEMI > > rcvr-uuid] > > >> *(SEMI > > >>>>>>> generic-param) > > >>>>>>> > > >>>>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of = [0-9a-f] > > >>>>>>> > > >>>>>>> rcvr-uuid =3D "rcvr" EQUAL 32(DIGIT / %x61-66) > > >>>>>>> > > >>>>>>> > > >>>>>>> In fact, I am not aware of any current > > implementations that use > > >>>>>>> the > > >>>>>> generic-param for anything, so we could even do the = following: > > >>>>>>> > > >>>>>>> Session-ID =3D "Session-ID" HCOLON sess-id [SEMI = rcvr-uuid > > >> *(SEMI > > >>>>>>> generic-param)] > > >>>>>> > > >>>>>> IMO it is bad practice to require a specific ordering > > among params. > > >>>>>> So I would prefer: > > >>>>>> > > >>>>>> Session-ID =3D "Session-ID" HCOLON sess-id *[SEMI > > sess-id-param] > > >>>>>> > > >>>>>> sess-id-param =3D rcvr-uuid / generic-param > > >>>>>> > > >>>>>> sess-id =3D 32(DIGIT / %x61-66) ;32 chars of = [0-9a-f] > > >>>>>> > > >>>>>> rcvr-uuid =3D "rcvr" EQUAL sess-id > > >>>>>> > > >>>>>> Another thing: the above only permits lower case hex. For > > >>>>>> consistency with common usage both lower and upper > > case should be > > >>>>>> permitted. This can be done by: > > >>>>>> > > >>>>>> sess-id =3D 32 HEXDIG (from 5234, used in 3261) > > >>>>>> > > >>>>>> And is there any reason to require leading zeros in > > the sess-id? > > >>>>>> If not, that can be specified via > > >>>>>> > > >>>>>> sess-id =3D 1*32 HEXDIG > > >>>>>> or maybe > > >>>>>> sess-id =3D 1*16 (HEXDIG HEXDIG) > > >>>>>> > > >>>>>> Or does backward compatibility require restricting to > > lower case > > >>>>>> and exactly 32 digits? > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Paul > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> 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 > >