From hadriel.kaplan@oracle.com Thu Aug 1 02:09:11 2013 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 E90F121E808F for ; Thu, 1 Aug 2013 02:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.281 X-Spam-Level: X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ou-ewcWEEdt for ; Thu, 1 Aug 2013 02:09:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 82EF721F9E27 for ; Thu, 1 Aug 2013 02:08:59 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7198vuT004650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 09:08:58 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7198ud9016952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 09:08:57 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7198ucE009213; Thu, 1 Aug 2013 09:08:56 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 02:08:56 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> Date: Thu, 1 Aug 2013 05:08:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:09:11 -0000 This isn't about Enterprise vs. Service-Provider, or Cisco vs. another = vendor. This is just about a Working Group document, and whether the = mechanism defined in it should change the Session-ID header value vs. = parameter based on direction of messages, or not. I totally get the = need to have a distinguishing Session-ID identifier for party-A vs. = party-B. What I don't get is why they need to change the encoding of = the Session-ID header value vs. parameter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" This second model keeps the Session-ID header value as "foo" the whole = time, while adding a parameter of "bar" for Bob that remains a parameter = the whole time. Neither Alice nor Bob are confused about which one is "their" UUID = value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why = it had to be swapped, but I don't remember what it is and I don't see it = in the draft. So I'm trying to find out why we need to do it the way = the draft currently has it. The other topic of whether SBCs will change things is completely = orthogonal to the ordering or backwards compatibility issues, and really = shouldn't be conflated with it at all. It has nothing to do with the = solutions document, or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones = wrote: > Folks, >=20 > I step away for a couple of days and the floodgate opens. :) >=20 > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to = effectively > deal with things like forking, call transfer, park, bridging, = conferencing, > etc. >=20 > When initiating a call and using a single UUID value, that has the = potential > to go end-to-end. However, if a call is forked there are multiple = "ends". > How do we track each of those? For proper diagnostics and = troubleshooting, > it would be ideal to be able to identify which devices have an issue. >=20 > Once a call has been placed, there is a Session-ID established between = Alice > and Bob. If Alice (in one country) transfers Bob (perhaps in the same = or > different country) to a some location in a high-toll country, who pays = the > bill? Well, to address that, we do call transfer locally on PBXes. = The PBX > maintains control over the call and Alice would pay the bill for the = call > transfer. But if Alice was talking to Carol before the transfer, = there is a > Session-ID for that call. If Bob is put in communication with Carol, = what > is the Session-ID value? Bob had one and Carol had a different one. = What > is the new ID? >=20 > It's issues like this that led us to using a two-part value. In this = way, > we could see the call from Alice to Bob has a Session-ID {A,B}. If = Alice > transfers the call to Carol, each device understands that the = Session-ID > changed to {B,C}. Not only that, but intermediaries along the path = that > were not privy to signaling that resulted in this change can take note = of > the fact the value changed. This can provide a useful historical = record, > since previously they might see a call to Carol identified as {A,C}, = but > then it changed to {B,C}. >=20 > This property extends quite naturally to other signaling scenarios, as = it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value = out of > the two. >=20 > Hadriel mentioned the desire to use the Session-ID to correlate media = flows > and calls. That's certainly something Cisco would like to do, but it = is not > the driver behind the solution. Having a valid end-to-end identifier = (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a = solution > that allows us to properly identify calls end-to-end and we recognize = that, > due to various service interactions in the network, these UUID values = can > change. >=20 > I would hope that UUID values will not change to the extent that SBCs = change > them for business reasons. It would certainly defeat the point. = Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that = such > a request effectively breaks the end-to-end model. We can't do much = about > that if they do go down that path. >=20 > As for backward-compatibility, the simplest approach (IMO) is to just = use a > header value not already in use. Originally, we had proposed = Session-UUID. > That was changed at the request of the group to be Session-ID. = However, > when we have a two UUID solution interacting with a one-UUID solution, = we > immediately face some challenges. >=20 > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=3DX >=20 > Does this break things? If so, how do current implementations deal = with > such things as mid-call transfers that happen on a PBX like the one I > described above? >=20 > We could switch the order like this: > Session-ID: X; remote=3DY >=20 > However, that does not work for similar reasons. If we have a call = transfer > where Alice transfers a call with Bob to Carol, then each has a = different > idea about what the proper value is for the first position. >=20 > Originally, the proposed solution did not indicate position = information and > just had single UUID values going in each direction. We then proposed = a > concatenated string (X:Y). However, that presented the same issues for = the > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end = has for > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) >=20 > So, that's why we are where we are. There has been an effort to = maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been = told > explicitly what the issues are. Further, if there are such issues, we = need > to also understand how those would be handled in the face of call = transfer > or "joining" a call locally on a PBX. Those are real-world scenarios = that > we must address. >=20 > Anyway, nothing is set in stone. Anything can be changed, but I would = hope > we can find a solution that works for the enterprise use cases as well = as > the service provider networks. >=20 > Paul >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From prvs=992526917d=aallen@blackberry.com Thu Aug 1 02:23:02 2013 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 D75E121F9EA1 for ; Thu, 1 Aug 2013 02:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.601 X-Spam-Level: X-Spam-Status: No, score=-5.601 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rujva0ywqu0R for ; Thu, 1 Aug 2013 02:22:58 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id D163721F9CA8 for ; Thu, 1 Aug 2013 02:22:13 -0700 (PDT) X-AuditID: 0a41282f-b7f9b6d000002847-86-51fa28b53552 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 9D.58.10311.5B82AF15; Thu, 1 Aug 2013 04:21:58 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.03.0123.003; Thu, 1 Aug 2013 04:21:57 -0500 From: Andrew Allen To: "hadriel.kaplan@oracle.com" , "paulej@packetizer.com" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: Ac6ObL8bHmdBy9j3R4y13v8TdvwiwQAU+ioAAAoFmYg= Date: Thu, 1 Aug 2013 09:21:56 +0000 Message-ID: In-Reply-To: <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsXC5ZyvpbtN41egwctZbBafNn1itph//xmT xfkLG5gcmD2WLPnJ5PHx6S0Wj4Z9R9kDmKMaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5Nt lXxS0xNzFAKKMssSkysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4 FDCADVBZZp5Cal5yfkpmXrqtkmewv66FhamlrqGSnW5CJ0/G7WXH2QuOO1Ysn7iUpYGx1aSL kZNDQsBE4uKfHcwQtpjEhXvr2UBsIYGVjBI99xi7GLmA7E2MEncaJ4MVsQloSew/PJ0JxBYR yJNobuplBLGZBTQlViy+zQ5iCwt4S9z9NpMVosZH4sPsV+wQtpXEiabtQL0cHCwCKhL3LiqD hHkFPCQuvZ/EAmJzCthJbLvzBGw8o4CsxO6z15kgxotL3HoynwniTgGJJXvOQ90sKvHy8T9W CFtRYsae+awQ9XoSN6ZOYYOwtSWWLXzNDLFLUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnF KJibUWxgZpCcl6xXlJmrl5dasokRlCAcNfR3ML59b3GIUYCDUYmHl13hV6AQa2JZcWXuIUYJ DmYlEd6t6T8DhXhTEiurUovy44tKc1KLDzG6AgNiIrMUd3I+MHnllcQbGxjg5iiJ87qqfAgU EkgHpp7s1NSC1CKYOUwcnCB7uKREioEJJLUosbQkIx6U5uKLgYlOqoGR0eXpzd0Bgobal75b ian2qu5LeqcvMHPunXey6p2SjQEv63qaDF8YzC+/GyB0aor+x3s5iw2L15TyJWlcfLYzQ9bh ncdB21nsLE/E3BtyGSympfxNZvDLzPI7JJ81v5+TbdUyryDFLwukrpf7x19Xm7D5ROW1lY9X h9/PuyZYPMn3QN6ZnG9KLMUZiYZazEXFiQAw8wbeUQMAAA== Cc: "insipid@ietf.org" Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 09:23:03 -0000 I also think the order of local and remote should remain the same regardless= of the direction unless there is a really really good reason otherwise, (I= previously made a comment to this effect at the mic at a previous IETF). ----- Original Message ----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Thursday, August 01, 2013 04:08 AM Central Standard Time=0A= To: Paul E. Jones Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendo= r. This is just about a Working Group document, and whether the mechanism d= efined in it should change the Session-ID header value vs. parameter based o= n direction of messages, or not. I totally get the need to have a distingui= shing Session-ID identifier for party-A vs. party-B. What I don't get is wh= y they need to change the encoding of the Session-ID header value vs. parame= ter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" This second model keeps the Session-ID header value as "foo" the whole time,= while adding a parameter of "bar" for Bob that remains a parameter the whol= e time. Neither Alice nor Bob are confused about which one is "their" UUID value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why it h= ad to be swapped, but I don't remember what it is and I don't see it in the= draft. So I'm trying to find out why we need to do it the way the draft cu= rrently has it. The other topic of whether SBCs will change things is completely orthogonal= to the ordering or backwards compatibility issues, and really shouldn't be= conflated with it at all. It has nothing to do with the solutions document= , or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > Folks, > > I step away for a couple of days and the floodgate opens. :) > > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to effectively > deal with things like forking, call transfer, park, bridging, conferencing= , > etc. > > When initiating a call and using a single UUID value, that has the potenti= al > to go end-to-end. However, if a call is forked there are multiple "ends". > How do we track each of those? For proper diagnostics and troubleshooting= , > it would be ideal to be able to identify which devices have an issue. > > Once a call has been placed, there is a Session-ID established between Ali= ce > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > different country) to a some location in a high-toll country, who pays the > bill? Well, to address that, we do call transfer locally on PBXes. The P= BX > maintains control over the call and Alice would pay the bill for the call > transfer. But if Alice was talking to Carol before the transfer, there is= a > Session-ID for that call. If Bob is put in communication with Carol, what > is the Session-ID value? Bob had one and Carol had a different one. What > is the new ID? > > It's issues like this that led us to using a two-part value. In this way, > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > transfers the call to Carol, each device understands that the Session-ID > changed to {B,C}. Not only that, but intermediaries along the path that > were not privy to signaling that resulted in this change can take note of > the fact the value changed. This can provide a useful historical record, > since previously they might see a call to Carol identified as {A,C}, but > then it changed to {B,C}. > > This property extends quite naturally to other signaling scenarios, as it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value out o= f > the two. > > Hadriel mentioned the desire to use the Session-ID to correlate media flow= s > and calls. That's certainly something Cisco would like to do, but it is n= ot > the driver behind the solution. Having a valid end-to-end identifier (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a solutio= n > that allows us to properly identify calls end-to-end and we recognize that= , > due to various service interactions in the network, these UUID values can > change. > > I would hope that UUID values will not change to the extent that SBCs chan= ge > them for business reasons. It would certainly defeat the point. Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that suc= h > a request effectively breaks the end-to-end model. We can't do much about > that if they do go down that path. > > As for backward-compatibility, the simplest approach (IMO) is to just use= a > header value not already in use. Originally, we had proposed Session-UUID= . > That was changed at the request of the group to be Session-ID. However, > when we have a two UUID solution interacting with a one-UUID solution, we > immediately face some challenges. > > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=3DX > > Does this break things? If so, how do current implementations deal with > such things as mid-call transfers that happen on a PBX like the one I > described above? > > We could switch the order like this: > Session-ID: X; remote=3DY > > However, that does not work for similar reasons. If we have a call transf= er > where Alice transfers a call with Bob to Carol, then each has a different > idea about what the proper value is for the first position. > > Originally, the proposed solution did not indicate position information an= d > just had single UUID values going in each direction. We then proposed a > concatenated string (X:Y). However, that presented the same issues for the > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end has fo= r > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) > > So, that's why we are where we are. There has been an effort to maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been told > explicitly what the issues are. Further, if there are such issues, we nee= d > to also understand how those would be handled in the face of call transfer > or "joining" a call locally on a PBX. Those are real-world scenarios that > we must address. > > Anyway, nothing is set in stone. Anything can be changed, but I would hop= e > we can find a solution that works for the enterprise use cases as well as > the service provider networks. > > 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From pkyzivat@alum.mit.edu Thu Aug 1 05:31:29 2013 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 DAC4921F9C59 for ; Thu, 1 Aug 2013 05:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_61=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2ZmF8KEpzwd for ; Thu, 1 Aug 2013 05:31:16 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id D056021E80F9 for ; Thu, 1 Aug 2013 05:25:24 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta06.emeryville.ca.mail.comcast.net with comcast id 7QPq1m00417UAYkA6QRBfV; Thu, 01 Aug 2013 12:25:11 +0000 Received: from dhcp-15b9.meeting.ietf.org ([130.129.21.185]) by omta13.emeryville.ca.mail.comcast.net with comcast id 7QP11m00U3zbtzW8ZQP4R3; Thu, 01 Aug 2013 12:23:09 +0000 Message-ID: <51FA5325.10107@alum.mit.edu> Date: Thu, 01 Aug 2013 14:23:01 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: insipid@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375359911; bh=fTVATIJo9MuAuC+cV7g9DUF2tXIK9tv8b+ME4pj5C3Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Fsb75qZMO7dD2mzytFIv4BWZLOr5KNKXE8UDVqKbd9Ltx0JJVcdk4IjHnX5aDZEkk olEuMXkd6syIydjwnwaDDzMPTwbv0epmuw9epmRa2TpIAttTbqnx7uwmc/jqKWPpP2 4XAaIlrua7sDm19oBvHchbN26OjfyqXDkx/zfpPXtQuB0WKSqpToCgjkaRVndl5duz 7MIHeNELXyQuP1qT1MypUBMgxcUoeotoDY563kgFMcWWIr+S5vKwFpR9Xuf4N16IQm +McxMWmKWH6+v1Hl4X1n0XFco6oeEGvf2PRokefo1zfwEfWa+oLl+ag5zlTM7M5LGO 79yl4pngSFP6Q== Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:31:42 -0000 I find the currenly agreed upon scheme "odd", primarily just because it is different from the way from/to tags are used. But from/to tags are weird in their own way. The important thing is that how they are arragned be entirely clear in all cases. At least the current scheme has the benefit of having a simple rule: - keep track of "mine" and "yours" - always send "mine" first - always receive "yours" first. I can live with this. A scheme that uses a single ordering for the two halves in all messages of a dialog, including requests in both directions and responses in either direction, would IMO be a little bit harder, in that it requires a bit more state: I must remember "mine", "yours", and which goes first. I think this is what Hadriel is suggesting below. An alternative would be to use "mine";"yours" in requests, and keep the same ordering in responses to the requests. That is very analogous to how to/from tags are handled. Thanks, Paul On 8/1/13 11:21 AM, Andrew Allen wrote: > > I also think the order of local and remote should remain the same regardless of the direction unless there is a really really good reason otherwise, (I previously made a comment to this effect at the mic at a previous IETF). > > > ----- Original Message ----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 01, 2013 04:08 AM Central Standard Time > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor. This is just about a Working Group document, and whether the mechanism defined in it should change the Session-ID header value vs. parameter based on direction of messages, or not. I totally get the need to have a distinguishing Session-ID identifier for party-A vs. party-B. What I don't get is why they need to change the encoding of the Session-ID header value vs. parameter, on a message direction basis. > > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > This second model keeps the Session-ID header value as "foo" the whole time, while adding a parameter of "bar" for Bob that remains a parameter the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. > > I *think* there was a reason someone came up with at one time as to why it had to be swapped, but I don't remember what it is and I don't see it in the draft. So I'm trying to find out why we need to do it the way the draft currently has it. > > The other topic of whether SBCs will change things is completely orthogonal to the ordering or backwards compatibility issues, and really shouldn't be conflated with it at all. It has nothing to do with the solutions document, or the direction stuff, etc. > > -hadriel > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > >> Folks, >> >> I step away for a couple of days and the floodgate opens. :) >> >> I think it's important to understand why we proposed using a two-part >> Session Identifier. The reason is that we have to be able to effectively >> deal with things like forking, call transfer, park, bridging, conferencing, >> etc. >> >> When initiating a call and using a single UUID value, that has the potential >> to go end-to-end. However, if a call is forked there are multiple "ends". >> How do we track each of those? For proper diagnostics and troubleshooting, >> it would be ideal to be able to identify which devices have an issue. >> >> Once a call has been placed, there is a Session-ID established between Alice >> and Bob. If Alice (in one country) transfers Bob (perhaps in the same or >> different country) to a some location in a high-toll country, who pays the >> bill? Well, to address that, we do call transfer locally on PBXes. The PBX >> maintains control over the call and Alice would pay the bill for the call >> transfer. But if Alice was talking to Carol before the transfer, there is a >> Session-ID for that call. If Bob is put in communication with Carol, what >> is the Session-ID value? Bob had one and Carol had a different one. What >> is the new ID? >> >> It's issues like this that led us to using a two-part value. In this way, >> we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice >> transfers the call to Carol, each device understands that the Session-ID >> changed to {B,C}. Not only that, but intermediaries along the path that >> were not privy to signaling that resulted in this change can take note of >> the fact the value changed. This can provide a useful historical record, >> since previously they might see a call to Carol identified as {A,C}, but >> then it changed to {B,C}. >> >> This property extends quite naturally to other signaling scenarios, as it >> allows one to identify a call end-to-end, but also establish some >> relationship between other calls that shared at least one UUID value out of >> the two. >> >> Hadriel mentioned the desire to use the Session-ID to correlate media flows >> and calls. That's certainly something Cisco would like to do, but it is not >> the driver behind the solution. Having a valid end-to-end identifier (in >> whatever form) allows us to do that. We're not suggesting to fit the >> solution to meet that business use case, but rather we just want a solution >> that allows us to properly identify calls end-to-end and we recognize that, >> due to various service interactions in the network, these UUID values can >> change. >> >> I would hope that UUID values will not change to the extent that SBCs change >> them for business reasons. It would certainly defeat the point. Hadriel >> might be right that an SBC vendor might manipulate those values at the >> request of a customer, but I would hope said customer appreciates that such >> a request effectively breaks the end-to-end model. We can't do much about >> that if they do go down that path. >> >> As for backward-compatibility, the simplest approach (IMO) is to just use a >> header value not already in use. Originally, we had proposed Session-UUID. >> That was changed at the request of the group to be Session-ID. However, >> when we have a two UUID solution interacting with a one-UUID solution, we >> immediately face some challenges. >> >> What happens if an older system sends this: >> Session-ID: X >> But then receives this: >> Session-ID: Y; remote=X >> >> Does this break things? If so, how do current implementations deal with >> such things as mid-call transfers that happen on a PBX like the one I >> described above? >> >> We could switch the order like this: >> Session-ID: X; remote=Y >> >> However, that does not work for similar reasons. If we have a call transfer >> where Alice transfers a call with Bob to Carol, then each has a different >> idea about what the proper value is for the first position. >> >> Originally, the proposed solution did not indicate position information and >> just had single UUID values going in each direction. We then proposed a >> concatenated string (X:Y). However, that presented the same issues for the >> call transfer case, so we indicate values by position (sender's value >> first), so it is clear what value the receive thinks the remote end has for >> the local end. It might be wrong, but that will be corrected in the >> following response. (Intermediaries can take note of the change.) >> >> So, that's why we are where we are. There has been an effort to maintain >> backward-compatibility, but there are challenges in meeting that >> requirement. Where it falls short, we do not know: we've not been told >> explicitly what the issues are. Further, if there are such issues, we need >> to also understand how those would be handled in the face of call transfer >> or "joining" a call locally on a PBX. Those are real-world scenarios that >> we must address. >> >> Anyway, nothing is set in stone. Anything can be changed, but I would hope >> we can find a solution that works for the enterprise use cases as well as >> the service provider networks. >> >> 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 > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From pkyzivat@alum.mit.edu Thu Aug 1 05:52:38 2013 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 E4F1921E80CF for ; Thu, 1 Aug 2013 05:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeU+LsLQppuZ for ; Thu, 1 Aug 2013 05:52:32 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 7811121E811C for ; Thu, 1 Aug 2013 05:52:19 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta08.emeryville.ca.mail.comcast.net with comcast id 7Qij1m0011eYJf8A8QsKyd; Thu, 01 Aug 2013 12:52:19 +0000 Received: from dhcp-15b9.meeting.ietf.org ([130.129.21.185]) by omta19.emeryville.ca.mail.comcast.net with comcast id 7Qq71m00B3zbtzW01QqAH1; Thu, 01 Aug 2013 12:50:17 +0000 Message-ID: <51FA597E.5030106@alum.mit.edu> Date: Thu, 01 Aug 2013 14:50:06 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hadriel Kaplan References: <51F7A26B.1000704@ericsson.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@oracle.com> <51F93FC3.40206@alum.mit.edu> <9DBF0FDC-8866-4957-BEA6-8C1D7A4617FF@oracle.com> In-Reply-To: <9DBF0FDC-8866-4957-BEA6-8C1D7A4617FF@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375361539; bh=w1enlprP5R8uAKBEOnvuEaTtFvdwcqaB0hLBRj9SHME=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XsqOqQCKIfckQX6TatPX9lH3rHZVFdBFDbrDl1Buuxn6twfdqZfNg7uSbScqRR0CI W7lrl2QWT52/SQWTmv6tgq/3397sD2RXor8FegcHqNqo11HLv3oXOsxtWrKefOaRyk xvdjHMdCdKfYPlL7bKDwT7cdjyslGo5N54YY2HGQs2tKxK2rwsfNh4W0kvH/01uCwA OIaxYzxWyZBy9ZI6nsAF2TZiN5UlocOSmqSE3IE1pCSrFX2Ta5IwZx7jC7J3fjaRRo UJeBsTHO/AN+n13iI+uMGu2efEfLY4c99YjdNe9sqtnJGozH7lkkzgRvCim+YGQy0+ eF7QuRDd9SCvQ== Cc: insipid@ietf.org Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:52:38 -0000 On 8/1/13 12:24 AM, Hadriel Kaplan wrote: > > On Jul 31, 2013, at 12:48 PM, Paul Kyzivat wrote: >>>> This is simplistic but I think it meets REQ3. The discussion on Gonzalo's question seems to me to be about a different requirement along the lines of "how the Session-ID header field is generated and used must be compared with generation and use of header fields that a SIP B2BUA or other intermediary removes or modifies to ensure that a SIP B2BUA or other intermediary does not have any reason to remove the Session-ID: header field." >>> >>> Yup. Basically a "why do we think the MUST statement generated by REQ3 would actually be followed or not". >> >> Because if they don't follow it then any product that wants to claim conformance to a feature that requires session-id will fail in the presence of such B2BUA. If those features are themselves valuable, then people will demand products that conform to them. > > It's not the "products that conform to them" that's the issue, it's whether the operators/admins of the products want them to do it and whether it's possible to do without breaking something else. > > Take the Call-ID header, for example - even if there weren't a security problem with revealing IP Addresses, fundamentally there are call scenarios that simply don't work if the Call-ID is left unchanged by B2BUAs. Some of the scenarios are very subtle and only show up in certain deployments; others are more obvious, like out-of-dialog REFER handling. B2BUA products don't change the Call-ID because it's fun, they change it to make things *work*.[1] So if a new feature/mechanism is defined in the IETF which relies on Call-ID remaining unchanged, it doesn't matter if the product vendor and owner/admins want to support the new feature; it's giving them a choice of: "to get this new feature, you must break other features". I "understand" the rationale for changing callid to hide ip or dns addresses. (I think its silly, but I understand there are people that are paranoid about such things. I'm paranoid about *different* things.) I don't understand why you would need to "fix" callids for other reasons. I'd be interested in hearing (offline) about such cases. I can't think of anything except broken implementations. >> Yes, I know that is naive, but its all the leverage we have. > > It's not naive - it *is* all the leverage we have. The entire concept of INSIPID and STRAW docs is that a purchaser of equipment who wants feature X in RFC Y, tells its vendors to comply with RFC Y; if the vendors don't do RFC Y, then they can't have feature X. > > The challenge is when we use RFC Y to accomplish multiple different features Z and W, we run the risk that not all of X+Z+W are achievable simultaneously, in practice. So in the Session-ID case, if it turns out a SBC has to change a Session-ID to match/not-match others in order to make calls work right, vs. leaving it alone for troubleshooting purposes, it will invariably choose to change it to make calls work instead of help troubleshooting, as will its owner. Calls have to work... the spice must flow. The implication of this is that we should have *no* general mechanisms. Rather we should have many many feature-specific mechanisms. IIUC, that is a description of the systems we have been replacing, and one of the main reasons they needed to be replaced. Thanks, Paul > Thus when faced with the STIR stuff needing to do caller-id verification, in my opinion it would be safer to not use Session-ID, than rely on it surviving e2e. I don't *know* it won't survive e2e, since Session-ID hasn't gotten much deployment yet. It's just a hunch based on the use-cases people have in mind for it. They're not "benign" use-cases; they affect calls failing or succeeding. > > -hadriel > [1] This isn't entirely the case - I've been told by some B2BUA vendors that their internal architecture limits their ability to do certain things transparently, such as Call-ID handling. I won't name who they are because I was told in confidence, but they don't all attend the IETF and it's not my place to represent their views/issues. > > From laura.liess.dt@googlemail.com Thu Aug 1 06:14:47 2013 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 7B89421E80C7 for ; Thu, 1 Aug 2013 06:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS6Kr8iWge84 for ; Thu, 1 Aug 2013 06:14:44 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4570221E8147 for ; Thu, 1 Aug 2013 06:13:17 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id w10so1508430lbi.35 for ; Thu, 01 Aug 2013 06:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zv8rsXKiJkuBuF8po5JXLmlbzaxbzYbmW4CigPncnOs=; b=f0kWtwNsIeqT4Rd46aiQ711yNlbT5z6KY/6qqwtZ6vKocuakitUKQgYFQsSEYBjFSx nf5f1SXK7WR9RaeMCAOQ0YBFFMvl36BLR5gqQbqruQil/tzPGI/mQQkT+X2OSy4slv/7 XxL2+LUCuk/6nJHY+rjNS4p9XeRWc89iIezlWX71rT6WxE1L6SsKJp9wYIz/MeDAExDR n06i0gV/XFlKbTs2rcWkOetnplfkaJCnd9R9+2FtOmicFz1DVayC5wUE3xt3edDlVYI9 9b/myN+/QYsT70eAo1BwXLO2mtPjcodubIcTUwXayYm+UNS6IZPF8RBFW6j60ouy2Xb9 QabQ== MIME-Version: 1.0 X-Received: by 10.152.28.129 with SMTP id b1mr724340lah.51.1375362794527; Thu, 01 Aug 2013 06:13:14 -0700 (PDT) Received: by 10.114.75.144 with HTTP; Thu, 1 Aug 2013 06:13:14 -0700 (PDT) In-Reply-To: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> Date: Thu, 1 Aug 2013 15:13:14 +0200 Message-ID: From: Laura Liess To: insipid@ietf.org Content-Type: multipart/alternative; boundary=089e0160bde0ce20b704e2e29a3d Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:14:47 -0000 --089e0160bde0ce20b704e2e29a3d Content-Type: text/plain; charset=ISO-8859-1 Hadriel's proposal works for us. Thank you Laura 2013/8/1 Hadriel Kaplan > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the need > to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the Session-ID > header value vs. parameter, on a message direction basis. > > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > This second model keeps the Session-ID header value as "foo" the whole > time, while adding a parameter of "bar" for Bob that remains a parameter > the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. > > I *think* there was a reason someone came up with at one time as to why it > had to be swapped, but I don't remember what it is and I don't see it in > the draft. So I'm trying to find out why we need to do it the way the > draft currently has it. > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and really > shouldn't be conflated with it at all. It has nothing to do with the > solutions document, or the direction stuff, etc. > > -hadriel > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > Folks, > > > > I step away for a couple of days and the floodgate opens. :) > > > > I think it's important to understand why we proposed using a two-part > > Session Identifier. The reason is that we have to be able to effectively > > deal with things like forking, call transfer, park, bridging, > conferencing, > > etc. > > > > When initiating a call and using a single UUID value, that has the > potential > > to go end-to-end. However, if a call is forked there are multiple "ends". > > How do we track each of those? For proper diagnostics and > troubleshooting, > > it would be ideal to be able to identify which devices have an issue. > > > > Once a call has been placed, there is a Session-ID established between > Alice > > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > > different country) to a some location in a high-toll country, who pays > the > > bill? Well, to address that, we do call transfer locally on PBXes. The > PBX > > maintains control over the call and Alice would pay the bill for the call > > transfer. But if Alice was talking to Carol before the transfer, there > is a > > Session-ID for that call. If Bob is put in communication with Carol, > what > > is the Session-ID value? Bob had one and Carol had a different one. > What > > is the new ID? > > > > It's issues like this that led us to using a two-part value. In this > way, > > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > > transfers the call to Carol, each device understands that the Session-ID > > changed to {B,C}. Not only that, but intermediaries along the path that > > were not privy to signaling that resulted in this change can take note of > > the fact the value changed. This can provide a useful historical record, > > since previously they might see a call to Carol identified as {A,C}, but > > then it changed to {B,C}. > > > > This property extends quite naturally to other signaling scenarios, as it > > allows one to identify a call end-to-end, but also establish some > > relationship between other calls that shared at least one UUID value out > of > > the two. > > > > Hadriel mentioned the desire to use the Session-ID to correlate media > flows > > and calls. That's certainly something Cisco would like to do, but it is > not > > the driver behind the solution. Having a valid end-to-end identifier (in > > whatever form) allows us to do that. We're not suggesting to fit the > > solution to meet that business use case, but rather we just want a > solution > > that allows us to properly identify calls end-to-end and we recognize > that, > > due to various service interactions in the network, these UUID values can > > change. > > > > I would hope that UUID values will not change to the extent that SBCs > change > > them for business reasons. It would certainly defeat the point. Hadriel > > might be right that an SBC vendor might manipulate those values at the > > request of a customer, but I would hope said customer appreciates that > such > > a request effectively breaks the end-to-end model. We can't do much > about > > that if they do go down that path. > > > > As for backward-compatibility, the simplest approach (IMO) is to just > use a > > header value not already in use. Originally, we had proposed > Session-UUID. > > That was changed at the request of the group to be Session-ID. However, > > when we have a two UUID solution interacting with a one-UUID solution, we > > immediately face some challenges. > > > > What happens if an older system sends this: > > Session-ID: X > > But then receives this: > > Session-ID: Y; remote=X > > > > Does this break things? If so, how do current implementations deal with > > such things as mid-call transfers that happen on a PBX like the one I > > described above? > > > > We could switch the order like this: > > Session-ID: X; remote=Y > > > > However, that does not work for similar reasons. If we have a call > transfer > > where Alice transfers a call with Bob to Carol, then each has a different > > idea about what the proper value is for the first position. > > > > Originally, the proposed solution did not indicate position information > and > > just had single UUID values going in each direction. We then proposed a > > concatenated string (X:Y). However, that presented the same issues for > the > > call transfer case, so we indicate values by position (sender's value > > first), so it is clear what value the receive thinks the remote end has > for > > the local end. It might be wrong, but that will be corrected in the > > following response. (Intermediaries can take note of the change.) > > > > So, that's why we are where we are. There has been an effort to maintain > > backward-compatibility, but there are challenges in meeting that > > requirement. Where it falls short, we do not know: we've not been told > > explicitly what the issues are. Further, if there are such issues, we > need > > to also understand how those would be handled in the face of call > transfer > > or "joining" a call locally on a PBX. Those are real-world scenarios > that > > we must address. > > > > Anyway, nothing is set in stone. Anything can be changed, but I would > hope > > we can find a solution that works for the enterprise use cases as well as > > the service provider networks. > > > > 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 > --089e0160bde0ce20b704e2e29a3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hadriel's proposal works for us.
Thank you
Laura

2013/8/1 Hadriel Kaplan <hadriel.kaplan@oracle.com><= br>

This isn't about Enterprise vs. Service-Provider, or Cisco vs. another = vendor. =A0This is just about a Working Group document, and whether the mec= hanism defined in it should change the Session-ID header value vs. paramete= r based on direction of messages, or not. =A0I totally get the need to have= a distinguishing Session-ID identifier for party-A vs. party-B. =A0What I = don't get is why they need to change the encoding of the Session-ID hea= der value vs. parameter, on a message direction basis.

In other words, today the draft has this:
1) Alice sends INVITE with =A0 =A0 "Session-ID: foo"
2) Bob =A0 sends 18x/200 with =A0 =A0"Session-ID: bar;remote=3Dfoo&quo= t;
3) Alice sends ACK with =A0 =A0 =A0 =A0"Session-ID: foo;remote=3Dbar&q= uot;
4) Bob =A0 sends BYE with =A0 =A0 =A0 =A0"Session-ID: bar;remote=3Dfoo= "
5) Alice sends 200 with =A0 =A0 =A0 =A0"Session-ID: foo;remote=3Dbar&q= uot;

But we could instead do this:
1) Alice sends INVITE with =A0 =A0 "Session-ID: foo"
2) Bob =A0 sends 18x/200 with =A0 =A0"Session-ID: foo;remote=3Dbar&quo= t;
3) Alice sends ACK with =A0 =A0 =A0 =A0"Session-ID: foo;remote=3Dbar&q= uot;
4) Bob =A0 sends BYE with =A0 =A0 =A0 =A0"Session-ID: foo;remote=3Dbar= "
5) Alice sends 200 with =A0 =A0 =A0 =A0"Session-ID: foo;remote=3Dbar&q= uot;

This second model keeps the Session-ID header value as "foo" the = whole time, while adding a parameter of "bar" for Bob that remain= s a parameter the whole time.
Neither Alice nor Bob are confused about which one is "their" UUI= D value.
And it's backward-compatible with the previous kaplan-draft.
And it's arguably easier to implement, for the common cases.

I *think* there was a reason someone came up with at one time as to why it = had to be swapped, but I don't remember what it is and I don't see = it in the draft. =A0So I'm trying to find out why we need to do it the = way the draft currently has it.

The other topic of whether SBCs will change things is completely orthogonal= to the ordering or backwards compatibility issues, and really shouldn'= t be conflated with it at all. =A0It has nothing to do with the solutions d= ocument, or the direction stuff, etc.

-hadriel


On Aug 1, 2013, at 12:38 AM, Paul E. Jones <paulej@packetizer.com> wrote:

> Folks,
>
> I step away for a couple of days and the floodgate opens. :)
>
> I think it's important to understand why we proposed using a two-p= art
> Session Identifier. =A0The reason is that we have to be able to effect= ively
> deal with things like forking, call transfer, park, bridging, conferen= cing,
> etc.
>
> When initiating a call and using a single UUID value, that has the pot= ential
> to go end-to-end. However, if a call is forked there are multiple &quo= t;ends".
> How do we track each of those? =A0For proper diagnostics and troublesh= ooting,
> it would be ideal to be able to identify which devices have an issue.<= br> >
> Once a call has been placed, there is a Session-ID established between= Alice
> and Bob. =A0If Alice (in one country) transfers Bob (perhaps in the sa= me or
> different country) to a some location in a high-toll country, who pays= the
> bill? =A0Well, to address that, we do call transfer locally on PBXes. = =A0The PBX
> maintains control over the call and Alice would pay the bill for the c= all
> transfer. =A0But if Alice was talking to Carol before the transfer, th= ere is a
> Session-ID for that call. =A0If Bob is put in communication with Carol= , what
> is the Session-ID value? =A0Bob had one and Carol had a different one.= =A0What
> is the new ID?
>
> It's issues like this that led us to using a two-part value. =A0In= this way,
> we could see the call from Alice to Bob has a Session-ID {A,B}. =A0If = Alice
> transfers the call to Carol, each device understands that the Session-= ID
> changed to {B,C}. =A0Not only that, but intermediaries along the path = that
> were not privy to signaling that resulted in this change can take note= of
> the fact the value changed. =A0This can provide a useful historical re= cord,
> since previously they might see a call to Carol identified as {A,C}, b= ut
> then it changed to {B,C}.
>
> This property extends quite naturally to other signaling scenarios, as= it
> allows one to identify a call end-to-end, but also establish some
> relationship between other calls that shared at least one UUID value o= ut of
> the two.
>
> Hadriel mentioned the desire to use the Session-ID to correlate media = flows
> and calls. =A0That's certainly something Cisco would like to do, b= ut it is not
> the driver behind the solution. =A0Having a valid end-to-end identifie= r (in
> whatever form) allows us to do that. =A0We're not suggesting to fi= t the
> solution to meet that business use case, but rather we just want a sol= ution
> that allows us to properly identify calls end-to-end and we recognize = that,
> due to various service interactions in the network, these UUID values = can
> change.
>
> I would hope that UUID values will not change to the extent that SBCs = change
> them for business reasons. =A0It would certainly defeat the point. =A0= Hadriel
> might be right that an SBC vendor might manipulate those values at the=
> request of a customer, but I would hope said customer appreciates that= such
> a request effectively breaks the end-to-end model. =A0We can't do = much about
> that if they do go down that path.
>
> As for backward-compatibility, the simplest approach (IMO) is to just = use a
> header value not already in use. =A0Originally, we had proposed Sessio= n-UUID.
> That was changed at the request of the group to be Session-ID. =A0Howe= ver,
> when we have a two UUID solution interacting with a one-UUID solution,= we
> immediately face some challenges.
>
> What happens if an older system sends this:
> =A0Session-ID: X
> But then receives this:
> =A0Session-ID: Y; remote=3DX
>
> Does this break things? =A0If so, how do current implementations deal = with
> such things as mid-call transfers that happen on a PBX like the one I<= br> > described above?
>
> We could switch the order like this:
> =A0Session-ID: X; remote=3DY
>
> However, that does not work for similar reasons. =A0If we have a call = transfer
> where Alice transfers a call with Bob to Carol, then each has a differ= ent
> idea about what the proper value is for the first position.
>
> Originally, the proposed solution did not indicate position informatio= n and
> just had single UUID values going in each direction. =A0We then propos= ed a
> concatenated string (X:Y). However, that presented the same issues for= the
> call transfer case, so we indicate values by position (sender's va= lue
> first), so it is clear what value the receive thinks the remote end ha= s for
> the local end. =A0It might be wrong, but that will be corrected in the=
> following response. (Intermediaries can take note of the change.)
>
> So, that's why we are where we are. =A0There has been an effort to= maintain
> backward-compatibility, but there are challenges in meeting that
> requirement. =A0Where it falls short, we do not know: we've not be= en told
> explicitly what the issues are. =A0Further, if there are such issues, = we need
> to also understand how those would be handled in the face of call tran= sfer
> or "joining" a call locally on a PBX. =A0Those are real-worl= d scenarios that
> we must address.
>
> Anyway, nothing is set in stone. =A0Anything can be changed, but I wou= ld hope
> we can find a solution that works for the enterprise use cases as well= as
> the service provider networks.
>
> Paul
>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org=
> https://www.ietf.org/mailman/listinfo/insipid

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


--089e0160bde0ce20b704e2e29a3d-- From paulej@packetizer.com Thu Aug 1 06:27:54 2013 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 CD42321E8090 for ; Thu, 1 Aug 2013 06:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivsVOtelwOQv for ; Thu, 1 Aug 2013 06:27:50 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACA421F8526 for ; Thu, 1 Aug 2013 06:26:26 -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 r71DQHAi022267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Aug 2013 09:26:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375363577; bh=NNc4lu0X5N+fNIbUIoaOX2DojBoU0RbOiHv7pXd1E5I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VFORt9hPo2PsIjCnqvi3UD6+/0w/3p0YLEEc1iN2vVE0cCkKQUzWxPgrhgWY0j1iN lCwsCmONKB5B10f0rIypY2b7m4zk8WY4yZU+/v9d3C8KHNGM7Y9cfQ52od+6g9GOrQ XxWOV/BC1VRD1mVofq31NgWKKHKIqo7UnEfBfOjQ= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> In-Reply-To: <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> Date: Thu, 1 Aug 2013 09:26:13 -0400 Message-ID: <00bc01ce8eba$b20b2860$16217920$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEl6pJZnA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:27:55 -0000 Hadriel, As I explained down below, I think there is still an issue with the latter approach for such things as call transfer. For example, 1) Alice calls Bob {A,B} 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking server) 3) Bob calls Carol {B,C} 4) Bob transfers the call from Alice to Carol {A,C} With the current solution, the order is only significant so that the receiving endpoint can clearly identify the UUID of the sender. If we utilized the former proposal, what would these UUID values be? 1) Alice calls Bob {A,B} 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking server?) 3) Bob calls Carol {B,C} 4) Bob transfers the call from Alice to Carol {?,?} Perhaps that last one might be {A,C}, which might work for Bob. But if Carol was an older endpoint, what would she do seeing this "A" value as the first value? I think that's one example of where the former solution will break in real-world calls. Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 01, 2013 5:09 AM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the need > to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the Session-ID > header value vs. parameter, on a message direction basis. > > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > This second model keeps the Session-ID header value as "foo" the whole > time, while adding a parameter of "bar" for Bob that remains a parameter > the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. > > I *think* there was a reason someone came up with at one time as to why it > had to be swapped, but I don't remember what it is and I don't see it in > the draft. So I'm trying to find out why we need to do it the way the > draft currently has it. > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and really > shouldn't be conflated with it at all. It has nothing to do with the > solutions document, or the direction stuff, etc. > > -hadriel > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > Folks, > > > > I step away for a couple of days and the floodgate opens. :) > > > > I think it's important to understand why we proposed using a two-part > > Session Identifier. The reason is that we have to be able to > effectively > > deal with things like forking, call transfer, park, bridging, > conferencing, > > etc. > > > > When initiating a call and using a single UUID value, that has the > potential > > to go end-to-end. However, if a call is forked there are multiple "ends". > > How do we track each of those? For proper diagnostics and > troubleshooting, > > it would be ideal to be able to identify which devices have an issue. > > > > Once a call has been placed, there is a Session-ID established between > Alice > > and Bob. If Alice (in one country) transfers Bob (perhaps in the same > or > > different country) to a some location in a high-toll country, who pays > the > > bill? Well, to address that, we do call transfer locally on PBXes. The > PBX > > maintains control over the call and Alice would pay the bill for the > call > > transfer. But if Alice was talking to Carol before the transfer, there > is a > > Session-ID for that call. If Bob is put in communication with Carol, > what > > is the Session-ID value? Bob had one and Carol had a different one. > What > > is the new ID? > > > > It's issues like this that led us to using a two-part value. In this > way, > > we could see the call from Alice to Bob has a Session-ID {A,B}. If > Alice > > transfers the call to Carol, each device understands that the Session-ID > > changed to {B,C}. Not only that, but intermediaries along the path that > > were not privy to signaling that resulted in this change can take note > of > > the fact the value changed. This can provide a useful historical record, > > since previously they might see a call to Carol identified as {A,C}, but > > then it changed to {B,C}. > > > > This property extends quite naturally to other signaling scenarios, as > it > > allows one to identify a call end-to-end, but also establish some > > relationship between other calls that shared at least one UUID value out > of > > the two. > > > > Hadriel mentioned the desire to use the Session-ID to correlate media > flows > > and calls. That's certainly something Cisco would like to do, but it is > not > > the driver behind the solution. Having a valid end-to-end identifier > (in > > whatever form) allows us to do that. We're not suggesting to fit the > > solution to meet that business use case, but rather we just want a > solution > > that allows us to properly identify calls end-to-end and we recognize > that, > > due to various service interactions in the network, these UUID values > can > > change. > > > > I would hope that UUID values will not change to the extent that SBCs > change > > them for business reasons. It would certainly defeat the point. > Hadriel > > might be right that an SBC vendor might manipulate those values at the > > request of a customer, but I would hope said customer appreciates that > such > > a request effectively breaks the end-to-end model. We can't do much > about > > that if they do go down that path. > > > > As for backward-compatibility, the simplest approach (IMO) is to just > use a > > header value not already in use. Originally, we had proposed Session- > UUID. > > That was changed at the request of the group to be Session-ID. However, > > when we have a two UUID solution interacting with a one-UUID solution, > we > > immediately face some challenges. > > > > What happens if an older system sends this: > > Session-ID: X > > But then receives this: > > Session-ID: Y; remote=X > > > > Does this break things? If so, how do current implementations deal with > > such things as mid-call transfers that happen on a PBX like the one I > > described above? > > > > We could switch the order like this: > > Session-ID: X; remote=Y > > > > However, that does not work for similar reasons. If we have a call > transfer > > where Alice transfers a call with Bob to Carol, then each has a > different > > idea about what the proper value is for the first position. > > > > Originally, the proposed solution did not indicate position information > and > > just had single UUID values going in each direction. We then proposed a > > concatenated string (X:Y). However, that presented the same issues for > the > > call transfer case, so we indicate values by position (sender's value > > first), so it is clear what value the receive thinks the remote end has > for > > the local end. It might be wrong, but that will be corrected in the > > following response. (Intermediaries can take note of the change.) > > > > So, that's why we are where we are. There has been an effort to > maintain > > backward-compatibility, but there are challenges in meeting that > > requirement. Where it falls short, we do not know: we've not been told > > explicitly what the issues are. Further, if there are such issues, we > need > > to also understand how those would be handled in the face of call > transfer > > or "joining" a call locally on a PBX. Those are real-world scenarios > that > > we must address. > > > > Anyway, nothing is set in stone. Anything can be changed, but I would > hope > > we can find a solution that works for the enterprise use cases as well > as > > the service provider networks. > > > > Paul > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Thu Aug 1 07:10:35 2013 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 6078021E8146 for ; Thu, 1 Aug 2013 07:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBLZ0FRGEt2s for ; Thu, 1 Aug 2013 07:10:30 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6590121E81E0 for ; Thu, 1 Aug 2013 07:10: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 r71EA3Uq024965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Aug 2013 10:10:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375366203; bh=NNc4lu0X5N+fNIbUIoaOX2DojBoU0RbOiHv7pXd1E5I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=SHizgfcB0yNvcJ+Mh5eyFs38Iy0c5lj2l+QsMEcRZmyNNrLoO5scaGlFsHxcgvTMQ x6lb4H4dY7ZUNAI2UPHrWJXem1EwLiekWcZDNKBZwwbjvK9VxiLL867qNOnoNTsc/H /Adj23MqEvSNd3BgvDMYeoc5hPYuXLxjBAiSFaM8= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> In-Reply-To: <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> Date: Thu, 1 Aug 2013 10:09:59 -0400 Message-ID: <003701ce8ec0$cef571a0$6ce054e0$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEl6pYtoA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:10:35 -0000 Hadriel, As I explained down below, I think there is still an issue with the latter approach for such things as call transfer. For example, 1) Alice calls Bob {A,B} 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking server) 3) Bob calls Carol {B,C} 4) Bob transfers the call from Alice to Carol {A,C} With the current solution, the order is only significant so that the receiving endpoint can clearly identify the UUID of the sender. If we utilized the former proposal, what would these UUID values be? 1) Alice calls Bob {A,B} 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking server?) 3) Bob calls Carol {B,C} 4) Bob transfers the call from Alice to Carol {?,?} Perhaps that last one might be {A,C}, which might work for Bob. But if Carol was an older endpoint, what would she do seeing this "A" value as the first value? I think that's one example of where the former solution will break in real-world calls. Paul > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, August 01, 2013 5:09 AM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the need > to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the Session-ID > header value vs. parameter, on a message direction basis. > > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > This second model keeps the Session-ID header value as "foo" the whole > time, while adding a parameter of "bar" for Bob that remains a parameter > the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. > > I *think* there was a reason someone came up with at one time as to why it > had to be swapped, but I don't remember what it is and I don't see it in > the draft. So I'm trying to find out why we need to do it the way the > draft currently has it. > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and really > shouldn't be conflated with it at all. It has nothing to do with the > solutions document, or the direction stuff, etc. > > -hadriel > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > Folks, > > > > I step away for a couple of days and the floodgate opens. :) > > > > I think it's important to understand why we proposed using a two-part > > Session Identifier. The reason is that we have to be able to > effectively > > deal with things like forking, call transfer, park, bridging, > conferencing, > > etc. > > > > When initiating a call and using a single UUID value, that has the > potential > > to go end-to-end. However, if a call is forked there are multiple "ends". > > How do we track each of those? For proper diagnostics and > troubleshooting, > > it would be ideal to be able to identify which devices have an issue. > > > > Once a call has been placed, there is a Session-ID established between > Alice > > and Bob. If Alice (in one country) transfers Bob (perhaps in the same > or > > different country) to a some location in a high-toll country, who pays > the > > bill? Well, to address that, we do call transfer locally on PBXes. The > PBX > > maintains control over the call and Alice would pay the bill for the > call > > transfer. But if Alice was talking to Carol before the transfer, there > is a > > Session-ID for that call. If Bob is put in communication with Carol, > what > > is the Session-ID value? Bob had one and Carol had a different one. > What > > is the new ID? > > > > It's issues like this that led us to using a two-part value. In this > way, > > we could see the call from Alice to Bob has a Session-ID {A,B}. If > Alice > > transfers the call to Carol, each device understands that the Session-ID > > changed to {B,C}. Not only that, but intermediaries along the path that > > were not privy to signaling that resulted in this change can take note > of > > the fact the value changed. This can provide a useful historical record, > > since previously they might see a call to Carol identified as {A,C}, but > > then it changed to {B,C}. > > > > This property extends quite naturally to other signaling scenarios, as > it > > allows one to identify a call end-to-end, but also establish some > > relationship between other calls that shared at least one UUID value out > of > > the two. > > > > Hadriel mentioned the desire to use the Session-ID to correlate media > flows > > and calls. That's certainly something Cisco would like to do, but it is > not > > the driver behind the solution. Having a valid end-to-end identifier > (in > > whatever form) allows us to do that. We're not suggesting to fit the > > solution to meet that business use case, but rather we just want a > solution > > that allows us to properly identify calls end-to-end and we recognize > that, > > due to various service interactions in the network, these UUID values > can > > change. > > > > I would hope that UUID values will not change to the extent that SBCs > change > > them for business reasons. It would certainly defeat the point. > Hadriel > > might be right that an SBC vendor might manipulate those values at the > > request of a customer, but I would hope said customer appreciates that > such > > a request effectively breaks the end-to-end model. We can't do much > about > > that if they do go down that path. > > > > As for backward-compatibility, the simplest approach (IMO) is to just > use a > > header value not already in use. Originally, we had proposed Session- > UUID. > > That was changed at the request of the group to be Session-ID. However, > > when we have a two UUID solution interacting with a one-UUID solution, > we > > immediately face some challenges. > > > > What happens if an older system sends this: > > Session-ID: X > > But then receives this: > > Session-ID: Y; remote=X > > > > Does this break things? If so, how do current implementations deal with > > such things as mid-call transfers that happen on a PBX like the one I > > described above? > > > > We could switch the order like this: > > Session-ID: X; remote=Y > > > > However, that does not work for similar reasons. If we have a call > transfer > > where Alice transfers a call with Bob to Carol, then each has a > different > > idea about what the proper value is for the first position. > > > > Originally, the proposed solution did not indicate position information > and > > just had single UUID values going in each direction. We then proposed a > > concatenated string (X:Y). However, that presented the same issues for > the > > call transfer case, so we indicate values by position (sender's value > > first), so it is clear what value the receive thinks the remote end has > for > > the local end. It might be wrong, but that will be corrected in the > > following response. (Intermediaries can take note of the change.) > > > > So, that's why we are where we are. There has been an effort to > maintain > > backward-compatibility, but there are challenges in meeting that > > requirement. Where it falls short, we do not know: we've not been told > > explicitly what the issues are. Further, if there are such issues, we > need > > to also understand how those would be handled in the face of call > transfer > > or "joining" a call locally on a PBX. Those are real-world scenarios > that > > we must address. > > > > Anyway, nothing is set in stone. Anything can be changed, but I would > hope > > we can find a solution that works for the enterprise use cases as well > as > > the service provider networks. > > > > Paul > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Thu Aug 1 07:59:44 2013 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 6D07911E80DF for ; Thu, 1 Aug 2013 07:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apU98af42H1N for ; Thu, 1 Aug 2013 07:59:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BAA4A11E8100 for ; Thu, 1 Aug 2013 07:59: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 r71ExYbT028114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Aug 2013 10:59:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375369175; bh=9N38sBJm5fcRlmYAJP05F1TOClElGcL/J9OrWNY9eZ8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QVdpY5+ejEHpDA7UmbH7RMZeSVl7nOzgmLmzcWjgib3eBiWfwz91Zuf0xU8rCR8k2 iP8FsL6NpmbXeNfxIgm86Vg281KeKKeVVhQAetQb8bNNiH7CsPqA1Eoz7kUGY7AVgH U+EKL+o+vw+Cjd3NwYE1Rxw8DCYeHpXTvtoNYvcU= From: "Paul E. Jones" To: "'Laura Liess'" , References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> In-Reply-To: Date: Thu, 1 Aug 2013 10:59:30 -0400 Message-ID: <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01CE8EA6.331E6B70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7ZeBoOPA Content-Language: en-us Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:59:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0045_01CE8EA6.331E6B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Laura, I assert that old draft will not work for some "real-world" calls. Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc. Consider a common case: if you call into a call center and the agent puts you on hold while they transfer you to a specialist (transfer out of consultation), for example, your SIP UA does not receive a REFER to initiate a new call directly to the specialist. This is handled at the call center. So rather specifically, how would this be handled (with the old draft)? 1) Alice calls Bob (Session-ID: A) 2) Bob puts Alice on hold and calls Carol (Session-ID: B) 3) Bob transfers the call from Alice to Carol using a local transfer function on the PBX (Session-ID: ??) The PBX could send different values to Alice and Carol, but we totally lose the end-to-end identification of the call. Alice could not send "A" to Carol, since Carol is expecting B. Likewise, Carol cannot send "B" to Alice, since Alice is expecting "A". Well, they could, and it would be no worse than our current proposal in terms of backward-compatibility. Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Liess Sent: Thursday, August 01, 2013 9:13 AM To: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Hadriel's proposal works for us. Thank you Laura 2013/8/1 Hadriel Kaplan This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor. This is just about a Working Group document, and whether the mechanism defined in it should change the Session-ID header value vs. parameter based on direction of messages, or not. I totally get the need to have a distinguishing Session-ID identifier for party-A vs. party-B. What I don't get is why they need to change the encoding of the Session-ID header value vs. parameter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" 3) Alice sends ACK with "Session-ID: foo;remote=bar" 4) Bob sends BYE with "Session-ID: bar;remote=foo" 5) Alice sends 200 with "Session-ID: foo;remote=bar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" 3) Alice sends ACK with "Session-ID: foo;remote=bar" 4) Bob sends BYE with "Session-ID: foo;remote=bar" 5) Alice sends 200 with "Session-ID: foo;remote=bar" This second model keeps the Session-ID header value as "foo" the whole time, while adding a parameter of "bar" for Bob that remains a parameter the whole time. Neither Alice nor Bob are confused about which one is "their" UUID value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why it had to be swapped, but I don't remember what it is and I don't see it in the draft. So I'm trying to find out why we need to do it the way the draft currently has it. The other topic of whether SBCs will change things is completely orthogonal to the ordering or backwards compatibility issues, and really shouldn't be conflated with it at all. It has nothing to do with the solutions document, or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > Folks, > > I step away for a couple of days and the floodgate opens. :) > > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to effectively > deal with things like forking, call transfer, park, bridging, conferencing, > etc. > > When initiating a call and using a single UUID value, that has the potential > to go end-to-end. However, if a call is forked there are multiple "ends". > How do we track each of those? For proper diagnostics and troubleshooting, > it would be ideal to be able to identify which devices have an issue. > > Once a call has been placed, there is a Session-ID established between Alice > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > different country) to a some location in a high-toll country, who pays the > bill? Well, to address that, we do call transfer locally on PBXes. The PBX > maintains control over the call and Alice would pay the bill for the call > transfer. But if Alice was talking to Carol before the transfer, there is a > Session-ID for that call. If Bob is put in communication with Carol, what > is the Session-ID value? Bob had one and Carol had a different one. What > is the new ID? > > It's issues like this that led us to using a two-part value. In this way, > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > transfers the call to Carol, each device understands that the Session-ID > changed to {B,C}. Not only that, but intermediaries along the path that > were not privy to signaling that resulted in this change can take note of > the fact the value changed. This can provide a useful historical record, > since previously they might see a call to Carol identified as {A,C}, but > then it changed to {B,C}. > > This property extends quite naturally to other signaling scenarios, as it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value out of > the two. > > Hadriel mentioned the desire to use the Session-ID to correlate media flows > and calls. That's certainly something Cisco would like to do, but it is not > the driver behind the solution. Having a valid end-to-end identifier (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a solution > that allows us to properly identify calls end-to-end and we recognize that, > due to various service interactions in the network, these UUID values can > change. > > I would hope that UUID values will not change to the extent that SBCs change > them for business reasons. It would certainly defeat the point. Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that such > a request effectively breaks the end-to-end model. We can't do much about > that if they do go down that path. > > As for backward-compatibility, the simplest approach (IMO) is to just use a > header value not already in use. Originally, we had proposed Session-UUID. > That was changed at the request of the group to be Session-ID. However, > when we have a two UUID solution interacting with a one-UUID solution, we > immediately face some challenges. > > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=X > > Does this break things? If so, how do current implementations deal with > such things as mid-call transfers that happen on a PBX like the one I > described above? > > We could switch the order like this: > Session-ID: X; remote=Y > > However, that does not work for similar reasons. If we have a call transfer > where Alice transfers a call with Bob to Carol, then each has a different > idea about what the proper value is for the first position. > > Originally, the proposed solution did not indicate position information and > just had single UUID values going in each direction. We then proposed a > concatenated string (X:Y). However, that presented the same issues for the > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end has for > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) > > So, that's why we are where we are. There has been an effort to maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been told > explicitly what the issues are. Further, if there are such issues, we need > to also understand how those would be handled in the face of call transfer > or "joining" a call locally on a PBX. Those are real-world scenarios that > we must address. > > Anyway, nothing is set in stone. Anything can be changed, but I would hope > we can find a solution that works for the enterprise use cases as well as > the service provider networks. > > 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 ------=_NextPart_000_0045_01CE8EA6.331E6B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Laura,

 

I assert that old draft will not work for some = “real-world” calls.  Calls do get manipulated in = enterprise environments and call centers for billing purposes, privacy = reasons, etc.

 

Consider a common case: if you call into a call center and the agent = puts you on hold while they transfer you to a specialist (transfer out = of consultation), for example, your SIP UA does not receive a = REFER to initiate a new call directly to the specialist.  This is = handled at the call center.

 

So rather specifically, how would this be handled (with the old = draft)?

 

1) Alice calls Bob (Session-ID: A)

2) Bob puts Alice on hold and calls Carol (Session-ID: = B)

3) Bob transfers the call from Alice to Carol using a local transfer = function on the PBX (Session-ID: ??)

 

The PBX could send different values to Alice and Carol, but we = totally lose the end-to-end identification of the = call.

 

Alice could not send “A” to Carol, since Carol is = expecting B.  Likewise, Carol cannot send “B” to Alice, = since Alice is expecting “A”.  Well, they could, and it = would be no worse than our current proposal in terms of = backward-compatibility.

 

Paul

 

From:= = insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Laura Liess
Sent: Thursday, August 01, 2013 9:13 = AM
To: insipid@ietf.org
Subject: Re: [Insipid] = Proposed INSIPID solution and backward = compatibility

 


Hadriel's proposal works for us.

Thank = you
Laura

 

2013/8/1 Hadriel Kaplan <hadriel.kaplan@oracle.com>


This isn't about Enterprise vs. Service-Provider, = or Cisco vs. another vendor.  This is just about a Working Group = document, and whether the mechanism defined in it should change the = Session-ID header value vs. parameter based on direction of messages, or = not.  I totally get the need to have a distinguishing Session-ID = identifier for party-A vs. party-B.  What I don't get is why they = need to change the encoding of the Session-ID header value vs. = parameter, on a message direction basis.

In other words, today = the draft has this:
1) Alice sends INVITE with     = "Session-ID: foo"
2) Bob   sends 18x/200 with   =  "Session-ID: bar;remote=3Dfoo"
3) Alice sends ACK = with        "Session-ID: = foo;remote=3Dbar"
4) Bob   sends BYE with     =    "Session-ID: bar;remote=3Dfoo"
5) Alice sends = 200 with        "Session-ID: = foo;remote=3Dbar"

But we could instead do this:
1) Alice = sends INVITE with     "Session-ID: foo"
2) Bob =   sends 18x/200 with    "Session-ID: = foo;remote=3Dbar"
3) Alice sends ACK with       =  "Session-ID: foo;remote=3Dbar"
4) Bob   sends = BYE with        "Session-ID: = foo;remote=3Dbar"
5) Alice sends 200 with       =  "Session-ID: foo;remote=3Dbar"

This second model = keeps the Session-ID header value as "foo" the whole time, = while adding a parameter of "bar" for Bob that remains a = parameter the whole time.
Neither Alice nor Bob are confused about = which one is "their" UUID value.
And it's = backward-compatible with the previous kaplan-draft.
And it's arguably = easier to implement, for the common cases.

I *think* there was a = reason someone came up with at one time as to why it had to be swapped, = but I don't remember what it is and I don't see it in the draft. =  So I'm trying to find out why we need to do it the way the draft = currently has it.

The other topic of whether SBCs will change = things is completely orthogonal to the ordering or backwards = compatibility issues, and really shouldn't be conflated with it at all. =  It has nothing to do with the solutions document, or the direction = stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones = <paulej@packetizer.com> wrote:

> = Folks,
>
> I step away for a couple of days and the = floodgate opens. :)
>
> I think it's important to understand = why we proposed using a two-part
> Session Identifier.  The = reason is that we have to be able to effectively
> deal with = things like forking, call transfer, park, bridging, = conferencing,
> etc.
>
> When initiating a call and = using a single UUID value, that has the potential
> to go = end-to-end. However, if a call is forked there are multiple = "ends".
> How do we track each of those?  For = proper diagnostics and troubleshooting,
> it would be ideal to be = able to identify which devices have an issue.
>
> Once a = call has been placed, there is a Session-ID established between = Alice
> and Bob.  If Alice (in one country) transfers Bob = (perhaps in the same or
> different country) to a some location in = a high-toll country, who pays the
> bill?  Well, to address = that, we do call transfer locally on PBXes.  The PBX
> = maintains control over the call and Alice would pay the bill for the = call
> transfer.  But if Alice was talking to Carol before = the transfer, there is a
> Session-ID for that call.  If Bob = is put in communication with Carol, what
> is the Session-ID = value?  Bob had one and Carol had a different one. =  What
> is the new ID?
>
> It's issues like this = that led us to using a two-part value.  In this way,
> we = could see the call from Alice to Bob has a Session-ID {A,B}.  If = Alice
> transfers the call to Carol, each device understands that = the Session-ID
> changed to {B,C}.  Not only that, but = intermediaries along the path that
> were not privy to signaling = that resulted in this change can take note of
> the fact the value = changed.  This can provide a useful historical record,
> = since previously they might see a call to Carol identified as {A,C}, = but
> then it changed to {B,C}.
>
> This property = extends quite naturally to other signaling scenarios, as it
> = allows one to identify a call end-to-end, but also establish = some
> relationship between other calls that shared at least one = UUID value out of
> the two.
>
> Hadriel mentioned the = desire to use the Session-ID to correlate media flows
> and calls. =  That's certainly something Cisco would like to do, but it is = not
> the driver behind the solution.  Having a valid = end-to-end identifier (in
> whatever form) allows us to do that. =  We're not suggesting to fit the
> solution to meet that = business use case, but rather we just want a solution
> that = allows us to properly identify calls end-to-end and we recognize = that,
> due to various service interactions in the network, these = UUID values can
> change.
>
> I would hope that UUID = values will not change to the extent that SBCs change
> them for = business reasons.  It would certainly defeat the point. =  Hadriel
> might be right that an SBC vendor might manipulate = those values at the
> request of a customer, but I would hope said = customer appreciates that such
> a request effectively breaks the = end-to-end model.  We can't do much about
> that if they do = go down that path.
>
> As for backward-compatibility, the = simplest approach (IMO) is to just use a
> header value not = already in use.  Originally, we had proposed Session-UUID.
> = That was changed at the request of the group to be Session-ID. =  However,
> when we have a two UUID solution interacting with = a one-UUID solution, we
> immediately face some = challenges.
>
> What happens if an older system sends = this:
>  Session-ID: X
> But then receives = this:
>  Session-ID: Y; remote=3DX
>
> Does this = break things?  If so, how do current implementations deal = with
> such things as mid-call transfers that happen on a PBX like = the one I
> described above?
>
> We could switch the = order like this:
>  Session-ID: X; remote=3DY
>
> = However, that does not work for similar reasons.  If we have a call = transfer
> where Alice transfers a call with Bob to Carol, then = each has a different
> idea about what the proper value is for the = first position.
>
> Originally, the proposed solution did = not indicate position information and
> just had single UUID = values going in each direction.  We then proposed a
> = concatenated string (X:Y). However, that presented the same issues for = the
> call transfer case, so we indicate values by position = (sender's value
> first), so it is clear what value the receive = thinks the remote end has for
> the local end.  It might be = wrong, but that will be corrected in the
> following response. = (Intermediaries can take note of the change.)
>
> So, that's = why we are where we are.  There has been an effort to = maintain
> backward-compatibility, but there are challenges in = meeting that
> requirement.  Where it falls short, we do not = know: we've not been told
> explicitly what the issues are. =  Further, if there are such issues, we need
> to also = understand how those would be handled in the face of call = transfer
> or "joining" a call locally on a PBX. =  Those are real-world scenarios that
> we must = address.
>
> Anyway, nothing is set in stone.  Anything = can be changed, but I would hope
> we can find a solution that = works for the enterprise use cases as well as
> the service = provider networks.
>
> 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<= /o:p>

 

 

------=_NextPart_000_0045_01CE8EA6.331E6B70-- From laura.liess.dt@googlemail.com Thu Aug 1 08:51:30 2013 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 E3A3F21E818D for ; Thu, 1 Aug 2013 08:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCYktm51Z5Iz for ; Thu, 1 Aug 2013 08:51:29 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 919EC21E8150 for ; Thu, 1 Aug 2013 08:51:28 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id hi8so1522094lab.7 for ; Thu, 01 Aug 2013 08:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tArFIqI8NMCIyS8KnXUH4yhHdZ8bhOpTzOM2zHIP4II=; b=wP8CRI82HQjn4svS9NDzweLaYccdXxe+ZkORwfXrpAzatDKktYZ/NJaGBA4mUITuOS EFF02geUM64HzdMqIYr4YwuXAf5PjTgPbphRAL2iulUVaIwqG7Z3eRjk4Pu+GVhWzV5W B4eR1TsCL/EoIKbu3gRNHcxdFAXUyGgZyloxrUQnqQn2W5Ha5FrUxFKjW63vTaZOhs0h EgGQ+GtBsNCno22YHGRIwssktiLL2Vij1DpfaY2bhQbSw/s4d49I7pwcRWGpn1HSK8G1 gViyHPvOukORAi3cX4JCUh3/UHVs4KfQKFPiys4kVOGeQx9vxquCGDpjl9h+rsqtaAvH k39A== MIME-Version: 1.0 X-Received: by 10.112.218.68 with SMTP id pe4mr1704758lbc.40.1375372286145; Thu, 01 Aug 2013 08:51:26 -0700 (PDT) Received: by 10.114.75.144 with HTTP; Thu, 1 Aug 2013 08:51:26 -0700 (PDT) In-Reply-To: <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> Date: Thu, 1 Aug 2013 17:51:26 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=001a11c3d14a8cb91404e2e4d025 Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:51:31 -0000 --001a11c3d14a8cb91404e2e4d025 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, We use the old Session-ID only accross SBCs, to correlate both legs of the same dialog. And it works fine for this use case. We never tried, intend or were required to do more with it. We are not against the new mechanism, we just want it to interwork with the old one which we have in thousands of customer end devices. If it does, we can add new end devices and application servers which support the new Session-ID. Otherwise we can't. Let's see if it works when we keep the UUID order unchanged, as Hadriel proposed. Thank you Laura 2013/8/1 Paul E. Jones > Laura,**** > > ** ** > > I assert that old draft will not work for some =93real-world=94 calls. C= alls > do get manipulated in enterprise environments and call centers for billin= g > purposes, privacy reasons, etc.**** > > ** ** > > Consider a common case: if you call into a call center and the agent puts > you on hold while they transfer you to a specialist (transfer out of > consultation), for example, your SIP UA does *not* receive a REFER to > initiate a new call directly to the specialist. This is handled at the > call center.**** > > ** ** > > So rather specifically, how would this be handled (with the old draft)?**= * > * > > ** ** > > 1) Alice calls Bob (Session-ID: A)**** > > 2) Bob puts Alice on hold and calls Carol (Session-ID: B)**** > > 3) Bob transfers the call from Alice to Carol using a local transfer > function on the PBX (Session-ID: ??)**** > > ** ** > > The PBX could send different values to Alice and Carol, but we totally > lose the end-to-end identification of the call.**** > > ** ** > > Alice could not send =93A=94 to Carol, since Carol is expecting B. Likew= ise, > Carol cannot send =93B=94 to Alice, since Alice is expecting =93A=94. We= ll, they > could, and it would be no worse than our current proposal in terms of > backward-compatibility.**** > > ** ** > > Paul**** > > ** ** > > *From:* insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On > Behalf Of *Laura Liess > *Sent:* Thursday, August 01, 2013 9:13 AM > *To:* insipid@ietf.org > > *Subject:* Re: [Insipid] Proposed INSIPID solution and backward > compatibility**** > > ** ** > > > Hadriel's proposal works for us. > > Thank you > Laura**** > > ** ** > > 2013/8/1 Hadriel Kaplan **** > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the need > to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the Session-= ID > header value vs. parameter, on a message direction basis. > > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" > > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" > > This second model keeps the Session-ID header value as "foo" the whole > time, while adding a parameter of "bar" for Bob that remains a parameter > the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. > > I *think* there was a reason someone came up with at one time as to why i= t > had to be swapped, but I don't remember what it is and I don't see it in > the draft. So I'm trying to find out why we need to do it the way the > draft currently has it. > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and really > shouldn't be conflated with it at all. It has nothing to do with the > solutions document, or the direction stuff, etc. > > -hadriel**** > > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > Folks, > > > > I step away for a couple of days and the floodgate opens. :) > > > > I think it's important to understand why we proposed using a two-part > > Session Identifier. The reason is that we have to be able to effective= ly > > deal with things like forking, call transfer, park, bridging, > conferencing, > > etc. > > > > When initiating a call and using a single UUID value, that has the > potential > > to go end-to-end. However, if a call is forked there are multiple "ends= ". > > How do we track each of those? For proper diagnostics and > troubleshooting, > > it would be ideal to be able to identify which devices have an issue. > > > > Once a call has been placed, there is a Session-ID established between > Alice > > and Bob. If Alice (in one country) transfers Bob (perhaps in the same = or > > different country) to a some location in a high-toll country, who pays > the > > bill? Well, to address that, we do call transfer locally on PBXes. Th= e > PBX > > maintains control over the call and Alice would pay the bill for the ca= ll > > transfer. But if Alice was talking to Carol before the transfer, there > is a > > Session-ID for that call. If Bob is put in communication with Carol, > what > > is the Session-ID value? Bob had one and Carol had a different one. > What > > is the new ID? > > > > It's issues like this that led us to using a two-part value. In this > way, > > we could see the call from Alice to Bob has a Session-ID {A,B}. If Ali= ce > > transfers the call to Carol, each device understands that the Session-I= D > > changed to {B,C}. Not only that, but intermediaries along the path tha= t > > were not privy to signaling that resulted in this change can take note = of > > the fact the value changed. This can provide a useful historical recor= d, > > since previously they might see a call to Carol identified as {A,C}, bu= t > > then it changed to {B,C}. > > > > This property extends quite naturally to other signaling scenarios, as = it > > allows one to identify a call end-to-end, but also establish some > > relationship between other calls that shared at least one UUID value ou= t > of > > the two. > > > > Hadriel mentioned the desire to use the Session-ID to correlate media > flows > > and calls. That's certainly something Cisco would like to do, but it i= s > not > > the driver behind the solution. Having a valid end-to-end identifier (= in > > whatever form) allows us to do that. We're not suggesting to fit the > > solution to meet that business use case, but rather we just want a > solution > > that allows us to properly identify calls end-to-end and we recognize > that, > > due to various service interactions in the network, these UUID values c= an > > change. > > > > I would hope that UUID values will not change to the extent that SBCs > change > > them for business reasons. It would certainly defeat the point. Hadri= el > > might be right that an SBC vendor might manipulate those values at the > > request of a customer, but I would hope said customer appreciates that > such > > a request effectively breaks the end-to-end model. We can't do much > about > > that if they do go down that path. > > > > As for backward-compatibility, the simplest approach (IMO) is to just > use a > > header value not already in use. Originally, we had proposed > Session-UUID. > > That was changed at the request of the group to be Session-ID. However= , > > when we have a two UUID solution interacting with a one-UUID solution, = we > > immediately face some challenges. > > > > What happens if an older system sends this: > > Session-ID: X > > But then receives this: > > Session-ID: Y; remote=3DX > > > > Does this break things? If so, how do current implementations deal wit= h > > such things as mid-call transfers that happen on a PBX like the one I > > described above? > > > > We could switch the order like this: > > Session-ID: X; remote=3DY > > > > However, that does not work for similar reasons. If we have a call > transfer > > where Alice transfers a call with Bob to Carol, then each has a differe= nt > > idea about what the proper value is for the first position. > > > > Originally, the proposed solution did not indicate position information > and > > just had single UUID values going in each direction. We then proposed = a > > concatenated string (X:Y). However, that presented the same issues for > the > > call transfer case, so we indicate values by position (sender's value > > first), so it is clear what value the receive thinks the remote end has > for > > the local end. It might be wrong, but that will be corrected in the > > following response. (Intermediaries can take note of the change.) > > > > So, that's why we are where we are. There has been an effort to mainta= in > > backward-compatibility, but there are challenges in meeting that > > requirement. Where it falls short, we do not know: we've not been told > > explicitly what the issues are. Further, if there are such issues, we > need > > to also understand how those would be handled in the face of call > transfer > > or "joining" a call locally on a PBX. Those are real-world scenarios > that > > we must address. > > > > Anyway, nothing is set in stone. Anything can be changed, but I would > hope > > we can find a solution that works for the enterprise use cases as well = as > > the service provider networks. > > > > 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**** > > ** ** > > ** ** > --001a11c3d14a8cb91404e2e4d025 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul,
We use the old Session-ID only accross SBCs, to c= orrelate both legs of the same dialog. And it works fine for this use case.= We never tried, intend=A0 or were required to do more with it.
=A0We ar= e not against the new mechanism, we just want it to interwork with the old = one which we have in thousands of customer end devices. If it does, we can = add new end devices and application servers which support the new Session-I= D. Otherwise we can't.=A0

Let's see if it works when we keep the UUID order = unchanged, as Hadriel proposed.

Thank youLaura


2013/8/1 Paul E. Jones= <paulej@packetizer.com>

Laura,=

=A0<= /p>

I assert that old draf= t will not work for some =93real-world=94 calls.=A0 Calls do get manipulate= d in enterprise environments and call centers for billing purposes, privacy= reasons, etc.

=A0<= /p>

Consider a common case= : if you call into a call center and the agent puts you on hold while they = transfer you to a specialist (transfer out of consultation), for example, y= our SIP UA does not receive a REFER to initiate a new call directly = to the specialist.=A0 This is handled at the call center.

=A0<= /p>

So rather specifically= , how would this be handled (with the old draft)?

=A0<= /p>

1) Alice calls Bob (Se= ssion-ID: A)

2) Bob puts Alice on hold= and calls Carol (Session-ID: B)

3) Bob transfers the call from Alice to Carol us= ing a local transfer function on the PBX (Session-ID: ??)

=A0<= /p>

The PBX could send dif= ferent values to Alice and Carol, but we totally lose the end-to-end identi= fication of the call.

=A0<= /p>

Alice could not send = =93A=94 to Carol, since Carol is expecting B.=A0 Likewise, Carol cannot sen= d =93B=94 to Alice, since Alice is expecting =93A=94.=A0 Well, they could, = and it would be no worse than our current proposal in terms of backward-com= patibility.

=A0<= /p>

Paul

=A0<= /p>

From: insipid= -bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Li= ess
Sent: Thursday, August 01, 2013 9:13 AM
To: insipid@ietf.org


Subject: Re: [Insipid] Proposed INSIPID solution a= nd backward compatibility

=A0


Hadriel's proposal works= for us.

Thank you
Laura=

=A0

= 2013/8/1 Hadriel Kaplan <hadriel.kaplan@oracle.com>


This isn't about Enterprise vs. Service-Prov= ider, or Cisco vs. another vendor. =A0This is just about a Working Group do= cument, and whether the mechanism defined in it should change the Session-I= D header value vs. parameter based on direction of messages, or not. =A0I t= otally get the need to have a distinguishing Session-ID identifier for part= y-A vs. party-B. =A0What I don't get is why they need to change the enc= oding of the Session-ID header value vs. parameter, on a message direction = basis.

In other words, today the draft has this:
1) Alice sends INVITE with= =A0 =A0 "Session-ID: foo"
2) Bob =A0 sends 18x/200 with =A0 = =A0"Session-ID: bar;remote=3Dfoo"
3) Alice sends ACK with =A0 = =A0 =A0 =A0"Session-ID: foo;remote=3Dbar"
4) Bob =A0 sends BYE with =A0 =A0 =A0 =A0"Session-ID: bar;remote=3Dfoo= "
5) Alice sends 200 with =A0 =A0 =A0 =A0"Session-ID: foo;remo= te=3Dbar"

But we could instead do this:
1) Alice sends INVIT= E with =A0 =A0 "Session-ID: foo"
2) Bob =A0 sends 18x/200 with =A0 =A0"Session-ID: foo;remote=3Dbar&quo= t;
3) Alice sends ACK with =A0 =A0 =A0 =A0"Session-ID: foo;remote= =3Dbar"
4) Bob =A0 sends BYE with =A0 =A0 =A0 =A0"Session-ID: = foo;remote=3Dbar"
5) Alice sends 200 with =A0 =A0 =A0 =A0"Sess= ion-ID: foo;remote=3Dbar"

This second model keeps the Session-ID header value as "foo" = the whole time, while adding a parameter of "bar" for Bob that re= mains a parameter the whole time.
Neither Alice nor Bob are confused abo= ut which one is "their" UUID value.
And it's backward-compatible with the previous kaplan-draft.
And it&= #39;s arguably easier to implement, for the common cases.

I *think* = there was a reason someone came up with at one time as to why it had to be = swapped, but I don't remember what it is and I don't see it in the = draft. =A0So I'm trying to find out why we need to do it the way the dr= aft currently has it.

The other topic of whether SBCs will change things is completely orthog= onal to the ordering or backwards compatibility issues, and really shouldn&= #39;t be conflated with it at all. =A0It has nothing to do with the solutio= ns document, or the direction stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones= <paulej@pack= etizer.com> wrote:

> Folks,
>
> I step away for a couple of days and the fl= oodgate opens. :)
>
> I think it's important to understand = why we proposed using a two-part
> Session Identifier. =A0The reason = is that we have to be able to effectively
> deal with things like forking, call transfer, park, bridging, conferen= cing,
> etc.
>
> When initiating a call and using a singl= e UUID value, that has the potential
> to go end-to-end. However, if = a call is forked there are multiple "ends".
> How do we track each of those? =A0For proper diagnostics and troublesh= ooting,
> it would be ideal to be able to identify which devices have= an issue.
>
> Once a call has been placed, there is a Session-= ID established between Alice
> and Bob. =A0If Alice (in one country) transfers Bob (perhaps in the sa= me or
> different country) to a some location in a high-toll country,= who pays the
> bill? =A0Well, to address that, we do call transfer l= ocally on PBXes. =A0The PBX
> maintains control over the call and Alice would pay the bill for the c= all
> transfer. =A0But if Alice was talking to Carol before the trans= fer, there is a
> Session-ID for that call. =A0If Bob is put in commu= nication with Carol, what
> is the Session-ID value? =A0Bob had one and Carol had a different one.= =A0What
> is the new ID?
>
> It's issues like this t= hat led us to using a two-part value. =A0In this way,
> we could see = the call from Alice to Bob has a Session-ID {A,B}. =A0If Alice
> transfers the call to Carol, each device understands that the Session-= ID
> changed to {B,C}. =A0Not only that, but intermediaries along the= path that
> were not privy to signaling that resulted in this change= can take note of
> the fact the value changed. =A0This can provide a useful historical re= cord,
> since previously they might see a call to Carol identified as= {A,C}, but
> then it changed to {B,C}.
>
> This property= extends quite naturally to other signaling scenarios, as it
> allows one to identify a call end-to-end, but also establish some
&= gt; relationship between other calls that shared at least one UUID value ou= t of
> the two.
>
> Hadriel mentioned the desire to use t= he Session-ID to correlate media flows
> and calls. =A0That's certainly something Cisco would like to do, b= ut it is not
> the driver behind the solution. =A0Having a valid end-= to-end identifier (in
> whatever form) allows us to do that. =A0We= 9;re not suggesting to fit the
> solution to meet that business use case, but rather we just want a sol= ution
> that allows us to properly identify calls end-to-end and we r= ecognize that,
> due to various service interactions in the network, = these UUID values can
> change.
>
> I would hope that UUID values will not change = to the extent that SBCs change
> them for business reasons. =A0It wou= ld certainly defeat the point. =A0Hadriel
> might be right that an SB= C vendor might manipulate those values at the
> request of a customer, but I would hope said customer appreciates that= such
> a request effectively breaks the end-to-end model. =A0We can&= #39;t do much about
> that if they do go down that path.
>
> As for backward-compatibility, the simplest approach (IMO) is to just = use a
> header value not already in use. =A0Originally, we had propos= ed Session-UUID.
> That was changed at the request of the group to be= Session-ID. =A0However,
> when we have a two UUID solution interacting with a one-UUID solution,= we
> immediately face some challenges.
>
> What happens = if an older system sends this:
> =A0Session-ID: X
> But then re= ceives this:
> =A0Session-ID: Y; remote=3DX
>
> Does this break things? = =A0If so, how do current implementations deal with
> such things as m= id-call transfers that happen on a PBX like the one I
> described abo= ve?
>
> We could switch the order like this:
> =A0Session-ID: X;= remote=3DY
>
> However, that does not work for similar reasons= . =A0If we have a call transfer
> where Alice transfers a call with B= ob to Carol, then each has a different
> idea about what the proper value is for the first position.
>> Originally, the proposed solution did not indicate position informati= on and
> just had single UUID values going in each direction. =A0We t= hen proposed a
> concatenated string (X:Y). However, that presented the same issues for= the
> call transfer case, so we indicate values by position (sender&= #39;s value
> first), so it is clear what value the receive thinks th= e remote end has for
> the local end. =A0It might be wrong, but that will be corrected in the=
> following response. (Intermediaries can take note of the change.)<= br>>
> So, that's why we are where we are. =A0There has been a= n effort to maintain
> backward-compatibility, but there are challenges in meeting that
&g= t; requirement. =A0Where it falls short, we do not know: we've not been= told
> explicitly what the issues are. =A0Further, if there are such= issues, we need
> to also understand how those would be handled in the face of call tran= sfer
> or "joining" a call locally on a PBX. =A0Those are r= eal-world scenarios that
> we must address.
>
> Anyway, n= othing is set in stone. =A0Anything can be changed, but I would hope
> we can find a solution that works for the enterprise use cases as well= as
> the service provider networks.
>
> Paul
>
= >
> _______________________________________________
> insipi= d 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

=A0

<= /div>

=A0


--001a11c3d14a8cb91404e2e4d025-- From paulej@packetizer.com Thu Aug 1 08:59:33 2013 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 129A121E8124 for ; Thu, 1 Aug 2013 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmLF0z1z89sw for ; Thu, 1 Aug 2013 08:59:28 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5633921F9D35 for ; Thu, 1 Aug 2013 08:59:28 -0700 (PDT) Received: from dyn-170.arid.us (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r71FxP0D031930 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 1 Aug 2013 11:59:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375372766; bh=dyWG1me7BmUy8A6EKYPIFHIvDS0xjeiD/KYNN0AJets=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=DfIMJbWNuaN4uPQItceSiPn3kDZqZonMmActD3BaQrHaHidkI5eSwtVYi33O9ZI3S nxKJVWHTu/GG/1qo2yLzn8IVmjZnlYEP4l6kFSOgFKTTBj6Vp2fnC0SkkW+BICZyMJ PqGtuNmy2ESBY5IQH6QUNHU7gq54zzJ/+p4EQ+GA= User-Agent: Kaiten Mail In-Reply-To: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----X4ICXWBZA0MDRAJ4EZMBWI5NK5KX4J" From: "Paul E. Jones" Date: Thu, 01 Aug 2013 11:59:20 -0400 To: Laura Liess Message-ID: <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:59:33 -0000 ------X4ICXWBZA0MDRAJ4EZMBWI5NK5KX4J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Laura, The example I show below is a real call center example. I show use of the old session ID. Tell me how that works. Forget about the new solution for the moment. If you say it will not work, then I'm not sure how we can make something work with something that does not work. If there is a way to make this work, then we can try to figure out how to interwork with it. Paul -------- Original Message -------- From: Laura Liess Sent: Thu Aug 01 11:51:26 EDT 2013 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Paul, We use the old Session-ID only accross SBCs, to correlate both legs of the same dialog. And it works fine for this use case. We never tried, intend or were required to do more with it. We are not against the new mechanism, we just want it to interwork with the old one which we have in thousands of customer end devices. If it does, we can add new end devices and application servers which support the new Session-ID. Otherwise we can't. Let's see if it works when we keep the UUID order unchanged, as Hadriel proposed. Thank you Laura 2013/8/1 Paul E. Jones > Laura,**** > > ** ** > > I assert that old draft will not work for some “real-world” calls. Calls > do get manipulated in enterprise environments and call centers for billing > purposes, privacy reasons, etc.**** > > ** ** > > Consider a common case: if you call into a call center and the agent puts > you on hold while they transfer you to a specialist (transfer out of > consultation), for example, your SIP UA does *not* receive a REFER to > initiate a new call directly to the specialist. This is handled at the > call center.**** > > ** ** > > So rather specifically, how would this be handled (with the old draft)?*** > * > > ** ** > > 1) Alice calls Bob (Session-ID: A)**** > > 2) Bob puts Alice on hold and calls Carol (Session-ID: B)**** > > 3) Bob transfers the call from Alice to Carol using a local transfer > function on the PBX (Session-ID: ??)**** > > ** ** > > The PBX could send different values to Alice and Carol, but we totally > lose the end-to-end identification of the call.**** > > ** ** > > Alice could not send “A” to Carol, since Carol is expecting B. Likewise, > Carol cannot send “B” to Alice, since Alice is expecting “A”. Well, they > could, and it would be no worse than our current proposal in terms of > backward-compatibility.**** > > ** ** > > Paul**** > > ** ** > > *From:* insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On > Behalf Of *Laura Liess > *Sent:* Thursday, August 01, 2013 9:13 AM > *To:* insipid@ietf.org > > *Subject:* Re: [Insipid] Proposed INSIPID solution and backward > compatibility**** > > ** ** > > > Hadriel's proposal works for us. > > Thank you > Laura**** > > ** ** > > 2013/8/1 Hadriel Kaplan **** > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the need > to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the Session-ID > header value vs. parameter, on a message direction basis. > > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > This second model keeps the Session-ID header value as "foo" the whole > time, while adding a parameter of "bar" for Bob that remains a parameter > the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. > > I *think* there was a reason someone came up with at one time as to why it > had to be swapped, but I don't remember what it is and I don't see it in > the draft. So I'm trying to find out why we need to do it the way the > draft currently has it. > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and really > shouldn't be conflated with it at all. It has nothing to do with the > solutions document, or the direction stuff, etc. > > -hadriel**** > > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > Folks, > > > > I step away for a couple of days and the floodgate opens. :) > > > > I think it's important to understand why we proposed using a two-part > > Session Identifier. The reason is that we have to be able to effectively > > deal with things like forking, call transfer, park, bridging, > conferencing, > > etc. > > > > When initiating a call and using a single UUID value, that has the > potential > > to go end-to-end. However, if a call is forked there are multiple "ends". > > How do we track each of those? For proper diagnostics and > troubleshooting, > > it would be ideal to be able to identify which devices have an issue. > > > > Once a call has been placed, there is a Session-ID established between > Alice > > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > > different country) to a some location in a high-toll country, who pays > the > > bill? Well, to address that, we do call transfer locally on PBXes. The > PBX > > maintains control over the call and Alice would pay the bill for the call > > transfer. But if Alice was talking to Carol before the transfer, there > is a > > Session-ID for that call. If Bob is put in communication with Carol, > what > > is the Session-ID value? Bob had one and Carol had a different one. > What > > is the new ID? > > > > It's issues like this that led us to using a two-part value. In this > way, > > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > > transfers the call to Carol, each device understands that the Session-ID > > changed to {B,C}. Not only that, but intermediaries along the path that > > were not privy to signaling that resulted in this change can take note of > > the fact the value changed. This can provide a useful historical record, > > since previously they might see a call to Carol identified as {A,C}, but > > then it changed to {B,C}. > > > > This property extends quite naturally to other signaling scenarios, as it > > allows one to identify a call end-to-end, but also establish some > > relationship between other calls that shared at least one UUID value out > of > > the two. > > > > Hadriel mentioned the desire to use the Session-ID to correlate media > flows > > and calls. That's certainly something Cisco would like to do, but it is > not > > the driver behind the solution. Having a valid end-to-end identifier (in > > whatever form) allows us to do that. We're not suggesting to fit the > > solution to meet that business use case, but rather we just want a > solution > > that allows us to properly identify calls end-to-end and we recognize > that, > > due to various service interactions in the network, these UUID values can > > change. > > > > I would hope that UUID values will not change to the extent that SBCs > change > > them for business reasons. It would certainly defeat the point. Hadriel > > might be right that an SBC vendor might manipulate those values at the > > request of a customer, but I would hope said customer appreciates that > such > > a request effectively breaks the end-to-end model. We can't do much > about > > that if they do go down that path. > > > > As for backward-compatibility, the simplest approach (IMO) is to just > use a > > header value not already in use. Originally, we had proposed > Session-UUID. > > That was changed at the request of the group to be Session-ID. However, > > when we have a two UUID solution interacting with a one-UUID solution, we > > immediately face some challenges. > > > > What happens if an older system sends this: > > Session-ID: X > > But then receives this: > > Session-ID: Y; remote=X > > > > Does this break things? If so, how do current implementations deal with > > such things as mid-call transfers that happen on a PBX like the one I > > described above? > > > > We could switch the order like this: > > Session-ID: X; remote=Y > > > > However, that does not work for similar reasons. If we have a call > transfer > > where Alice transfers a call with Bob to Carol, then each has a different > > idea about what the proper value is for the first position. > > > > Originally, the proposed solution did not indicate position information > and > > just had single UUID values going in each direction. We then proposed a > > concatenated string (X:Y). However, that presented the same issues for > the > > call transfer case, so we indicate values by position (sender's value > > first), so it is clear what value the receive thinks the remote end has > for > > the local end. It might be wrong, but that will be corrected in the > > following response. (Intermediaries can take note of the change.) > > > > So, that's why we are where we are. There has been an effort to maintain > > backward-compatibility, but there are challenges in meeting that > > requirement. Where it falls short, we do not know: we've not been told > > explicitly what the issues are. Further, if there are such issues, we > need > > to also understand how those would be handled in the face of call > transfer > > or "joining" a call locally on a PBX. Those are real-world scenarios > that > > we must address. > > > > Anyway, nothing is set in stone. Anything can be changed, but I would > hope > > we can find a solution that works for the enterprise use cases as well as > > the service provider networks. > > > > 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**** > > ** ** > > ** ** > ------X4ICXWBZA0MDRAJ4EZMBWI5NK5KX4J Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Laura,

The example I show below is a real call center example. I show use of the old session ID. Tell me how that works. Forget about the new solution for the moment.

If you say it will not work, then I'm not sure how we can make something work with something that does not work. If there is a way to make this work, then we can try to figure out how to interwork with it.

Paul



From: Laura Liess <laura.liess.dt@googlemail.com>
Sent: Thu Aug 01 11:51:26 EDT 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

Paul,
We use the old Session-ID only accross SBCs, to correlate both legs of the same dialog. And it works fine for this use case. We never tried, intend  or were required to do more with it.
 We are not against the new mechanism, we just want it to interwork with the old one which we have in thousands of customer end devices. If it does, we can add new end devices and application servers which support the new Session-ID. Otherwise we can't. 

Let's see if it works when we keep the UUID order unchanged, as Hadriel proposed.

Thank you
Laura


2013/8/1 Paul E. Jones <paulej@packetizer.com>

Laura,

 

I assert that old draft will not work for some “real-world” calls.  Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc.

 

Consider a common case: if you call into a call center and the agent puts you on hold while they transfer you to a specialist (transfer out of consultation), for example, your SIP UA does not receive a REFER to initiate a new call directly to the specialist.  This is handled at the call center.

 

So rather specifically, how would this be handled (with the old draft)?

 

1) Alice calls Bob (Session-ID: A)

2) Bob puts Alice on hold and calls Carol (Session-ID: B)

3) Bob transfers the call from Alice to Carol using a local transfer function on the PBX (Session-ID: ??)

 

The PBX could send different values to Alice and Carol, but we totally lose the end-to-end identification of the call.

 

Alice could not send “A” to Carol, since Carol is expecting B.  Likewise, Carol cannot send “B” to Alice, since Alice is expecting “A”.  Well, they could, and it would be no worse than our current proposal in terms of backward-compatibility.

 

Paul

 

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Liess
Sent: Thursday, August 01, 2013 9:13 AM
To: insipid@ietf.org


Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility

 


Hadriel's proposal works for us.

Thank you
Laura

 

2013/8/1 Hadriel Kaplan <hadriel.kaplan@oracle.com>


This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor.  This is just about a Working Group document, and whether the mechanism defined in it should change the Session-ID header value vs. parameter based on direction of messages, or not.  I totally get the need to have a distinguishing Session-ID identifier for party-A vs. party-B.  What I don't get is why they need to change the encoding of the Session-ID header value vs. parameter, on a message direction basis.

In other words, today the draft has this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: bar;remote=foo"
3) Alice sends ACK with        "Session-ID: foo;remote=bar"
4) Bob   sends BYE with        "Session-ID: bar;remote=foo"
5) Alice sends 200 with        "Session-ID: foo;remote=bar"

But we could instead do this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: foo;remote=bar"
3) Alice sends ACK with        "Session-ID: foo;remote=bar"
4) Bob   sends BYE with        "Session-ID: foo;remote=bar"
5) Alice sends 200 with        "Session-ID: foo;remote=bar"

This second model keeps the Session-ID header value as "foo" the whole time, while adding a parameter of "bar" for Bob that remains a parameter the whole time.
Neither Alice nor Bob are confused about which one is "their" UUID value.
And it's backward-compatible with the previous kaplan-draft.
And it's arguably easier to implement, for the common cases.

I *think* there was a reason someone came up with at one time as to why it had to be swapped, but I don't remember what it is and I don't see it in the draft.  So I'm trying to find out why we need to do it the way the draft currently has it.

The other topic of whether SBCs will change things is completely orthogonal to the ordering or backwards compatibility issues, and really shouldn't be conflated with it at all.  It has nothing to do with the solutions document, or the direction stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones <paulej@packetizer.com> wrote:

> Folks,
>
> I step away for a couple of days and the floodgate opens. :)
>
> I think it's important to understand why we proposed using a two-part
> Session Identifier.  The reason is that we have to be able to effectively
> deal with things like forking, call transfer, park, bridging, conferencing,
> etc.
>
> When initiating a call and using a single UUID value, that has the potential
> to go end-to-end. However, if a call is forked there are multiple "ends".
> How do we track each of those?  For proper diagnostics and troubleshooting,
> it would be ideal to be able to identify which devices have an issue.
>
> Once a call has been placed, there is a Session-ID established between Alice
> and Bob.  If Alice (in one country) transfers Bob (perhaps in the same or
> different country) to a some location in a high-toll country, who pays the
> bill?  Well, to address that, we do call transfer locally on PBXes.  The PBX
> maintains control over the call and Alice would pay the bill for the call
> transfer.  But if Alice was talking to Carol before the transfer, there is a
> Session-ID for that call.  If Bob is put in communication with Carol, what
> is the Session-ID value?  Bob had one and Carol had a different one.  What
> is the new ID?
>
> It's issues like this that led us to using a two-part value.  In this way,
> we could see the call from Alice to Bob has a Session-ID {A,B}.  If Alice
> transfers the call to Carol, each device understands that the Session-ID
> changed to {B,C}.  Not only that, but intermediaries along the path that
> were not privy to signaling that resulted in this change can take note of
> the fact the value changed.  This can provide a useful historical record,
> since previously they might see a call to Carol identified as {A,C}, but
> then it changed to {B,C}.
>
> This property extends quite naturally to other signaling scenarios, as it
> allows one to identify a call end-to-end, but also establish some
> relationship between other calls that shared at least one UUID value out of
> the two.
>
> Hadriel mentioned the desire to use the Session-ID to correlate media flows
> and calls.  That's certainly something Cisco would like to do, but it is not
> the driver behind the solution.  Having a valid end-to-end identifier (in
> whatever form) allows us to do that.  We're not suggesting to fit the
> solution to meet that business use case, but rather we just want a solution
> that allows us to properly identify calls end-to-end and we recognize that,
> due to various service interactions in the network, these UUID values can
> change.
>
> I would hope that UUID values will not change to the extent that SBCs change
> them for business reasons.  It would certainly defeat the point.  Hadriel
> might be right that an SBC vendor might manipulate those values at the
> request of a customer, but I would hope said customer appreciates that such
> a request effectively breaks the end-to-end model.  We can't do much about
> that if they do go down that path.
>
> As for backward-compatibility, the simplest approach (IMO) is to just use a
> header value not already in use.  Originally, we had proposed Session-UUID.
> That was changed at the request of the group to be Session-ID.  However,
> when we have a two UUID solution interacting with a one-UUID solution, we
> immediately face some challenges.
>
> What happens if an older system sends this:
>  Session-ID: X
> But then receives this:
>  Session-ID: Y; remote=X
>
> Does this break things?  If so, how do current implementations deal with
> such things as mid-call transfers that happen on a PBX like the one I
> described above?
>
> We could switch the order like this:
>  Session-ID: X; remote=Y
>
> However, that does not work for similar reasons.  If we have a call transfer
> where Alice transfers a call with Bob to Carol, then each has a different
> idea about what the proper value is for the first position.
>
> Originally, the proposed solution did not indicate position information and
> just had single UUID values going in each direction.  We then proposed a
> concatenated string (X:Y). However, that presented the same issues for the
> call transfer case, so we indicate values by position (sender's value
> first), so it is clear what value the receive thinks the remote end has for
> the local end.  It might be wrong, but that will be corrected in the
> following response. (Intermediaries can take note of the change.)
>
> So, that's why we are where we are.  There has been an effort to maintain
> backward-compatibility, but there are challenges in meeting that
> requirement.  Where it falls short, we do not know: we've not been told
> explicitly what the issues are.  Further, if there are such issues, we need
> to also understand how those would be handled in the face of call transfer
> or "joining" a call locally on a PBX.  Those are real-world scenarios that
> we must address.
>
> Anyway, nothing is set in stone.  Anything can be changed, but I would hope
> we can find a solution that works for the enterprise use cases as well as
> the service provider networks.
>
> 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

 

 


------X4ICXWBZA0MDRAJ4EZMBWI5NK5KX4J-- From hadriel.kaplan@oracle.com Thu Aug 1 09:19:29 2013 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 66E1211E810F for ; Thu, 1 Aug 2013 09:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vc2Aqk9KTaq for ; Thu, 1 Aug 2013 09:19:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id C74BA21F84D1 for ; Thu, 1 Aug 2013 09:19:22 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r71GJK2V028510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 16:19:21 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71GJJR3002233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 16:19:19 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71GJI2J015939; Thu, 1 Aug 2013 16:19:18 GMT Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 09:19:18 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <00bc01ce8eba$b20b2860$16217920$@packetizer.com> Date: Thu, 1 Aug 2013 12:19:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:19:29 -0000 On Aug 1, 2013, at 9:26 AM, Paul E. Jones wrote: > 1) Alice calls Bob {A,B} > 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a = parking > server) > 3) Bob calls Carol {B,C} > 4) Bob transfers the call from Alice to Carol {A,C} >=20 > With the current solution, the order is only significant so that the > receiving endpoint can clearly identify the UUID of the sender. >=20 > If we utilized the former proposal, what would these UUID values be? > 1) Alice calls Bob {A,B} > 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a = parking > server?) I'm not sure what "if there is a parking server" means - I mean I know = what parking servers are, but I don't know how it's involved here from a = SIP protocol layer between Alice and Bob, in your example. Is Bob = sending a REFER to Alice to have her move to the parking server, or is = Bob sending a REFER to the parking server to have it send Alice an = INVITE with replaces, or is Bob making a separate call to the parking = server and sending Alice a re-INVITE/UPDATE just to move the media to = the parking server? > 3) Bob calls Carol {B,C} > 4) Bob transfers the call from Alice to Carol {?,?} Same question as above - how is it doing it? I ask these questions because the old draft-kaplan session-id had rules = about what to do for REFERs and INVITE with replaces, so I'm trying to = see where it breaks. > Perhaps that last one might be {A,C}, which might work for Bob. But = if > Carol was an older endpoint, what would she do seeing this "A" value = as the > first value? Carol sees it when? She see's it in a new INVITE? In a REFER? In a = re-INVITE? I think we've talked about this before, but in case we hadn't: the = Session-ID value in the legacy draft didn't really identify a human or = user or even User Agent device - it's not "A" for "Alice" and "B" for = "Bob" - it's just a randomish number identifying a session. Since it = doesn't identify a particular device, it can move around/migrate, and = doesn't "belong" to Alice or Bob. I'm not saying that's a *good* = property, but since it had that property we can probably play games with = parameters to get what needs to be done for the new Session-ID uses. -hadriel From laura.liess.dt@googlemail.com Thu Aug 1 09:50:32 2013 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 9B20721F9D01 for ; Thu, 1 Aug 2013 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbuGY5SdbDoZ for ; Thu, 1 Aug 2013 09:50:32 -0700 (PDT) Received: from mail-lb0-x244.google.com (mail-lb0-x244.google.com [IPv6:2a00:1450:4010:c04::244]) by ietfa.amsl.com (Postfix) with ESMTP id 94D8521F90C3 for ; Thu, 1 Aug 2013 09:50:24 -0700 (PDT) Received: by mail-lb0-f196.google.com with SMTP id a16so767214lbj.7 for ; Thu, 01 Aug 2013 09:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8Y6P+8LovoS8zWjyoWEVbwOcm1trcZw5x/zAAI3TipA=; b=rFdlMxhU6eYMlLKoa6RlntxoTKjC1E3fhgcquFzqEhzSI65iEf1Z3siy1SAuSj232c ioiyECl/TlCB9NqQIFcIeWcKvb4aOXRlR7CZ/pzMGuFCWI+Tb0iiNeNOmraIidvhGp5f yhzn0n8aSGmui+nVaHRJBw6U8pH0WLH5wjU+q+Qv57FkXArPIBhh7EiKWLUUGxxz14qi 7/4jNxiVIEErf7stYwid+wOPDqHAu9JiEsQ4y2bRlXFEHLkCXUVpfjqxt426MuUTLr52 I8XMc3Z+ga7uzkvdO785klwVZbZnGG7AqJRn0jjHSSdkA/TzGx5plbfFUbfkYwqX4+uK JhDQ== MIME-Version: 1.0 X-Received: by 10.152.116.76 with SMTP id ju12mr1159392lab.54.1375375816031; Thu, 01 Aug 2013 09:50:16 -0700 (PDT) Received: by 10.114.75.144 with HTTP; Thu, 1 Aug 2013 09:50:15 -0700 (PDT) Date: Thu, 1 Aug 2013 18:50:15 +0200 Message-ID: From: Laura Liess To: insipid@ietf.org Content-Type: multipart/alternative; boundary=001a11c365a6f2836404e2e5a21b Subject: [Insipid] Generation of a new Session-ID on behalf of an end device X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:50:32 -0000 --001a11c365a6f2836404e2e5a21b Content-Type: text/plain; charset=ISO-8859-1 Hi, As agreed in the insipid meeting, please find below the text on how SBCs should generate the Session-ID (or a part of it) on behalf of an end device. It is "copy & paste" from Hadriel's draft, parts of the Sections 4.1 and 4.5.1. However, I think we should replace B2BUA by SBC. Application servers and PBXs may want to insert their own UUID. I am fine if they do not add the received Call-ID. ******Text from Hadriel's draft *************************************************************** If an out-of-dialog request is received by a B2BUA compliant with this document, and the request does *not* contain a Session-ID header field, the B2BUA MAY generate a new one. The new Session-ID value MUST be generated by taking the Call-ID header value, and SHA-1 hashing it based on [RFC2104] HMAC using a locally generated pseudo-random 128-bit system secret key, to create a 128- bit resultant HMAC value. Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value, secret_key), and the 128-bit result is encoded using lowercase alphanumeric hex representation, as defined in the ABNF section of this document. In order to enable trouble-shooting of in-dialog messages, a generator needs to remember or re-create the same Session-ID value for the duration of a given dialog(s). If any received message already had a Session-ID, a B2BUA compliant with this document would not replace it. ************************************************************************** Thank you Laura --001a11c365a6f2836404e2e5a21b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi,

As agreed in the insipid meeting, please find below t=
he text on how SBCs should 
generate the Session-ID (or a part of it) on=
 behalf of an end device. 
It is  "copy & paste" from Hadriel's draft, parts=
 of the Sections 4.1 and 4.5.1. 

However, I think we should replace B2BUA by SBC. Application servers and PB=
Xs may want to insert their own UUID. I am fine 
if they do not add the =
received Call-ID. 


******Text from Hadriel's draft *********=
******************************************************<=
font>   =20
   If an out-of-dialog request is received by a B2BUA compliant with=20
   this document, and the request does *not* contain a Session-ID=20
   header field, the B2BUA MAY generate a new one.  The new Session-ID=20
   value MUST be generated by taking the Call-ID header=20
   value, and SHA-1 hashing it based on [RFC2104] HMAC using a locally=20
   generated pseudo-random 128-bit system secret key, to create a 128-
   bit resultant HMAC value. Per [RFC2104], the algorithm is thus HMAC-SHA-=
1-128(Call-ID_value,=20
   secret_key), and the 128-bit result is encoded using lowercase=20
   alphanumeric hex representation, as defined in the ABNF section of=20
   this document.    =20
   In order to enable trouble-shooting of in-dialog messages, a=20
   generator needs to remember or re-create the same Session-ID value=20
   for the duration of a given dialog(s). 
   If any received message al=
ready had a=20
   Session-ID, a B2BUA compliant with this document would not replace=20
   it. 
****************************************************************=
**********

Thank you
Laura
--001a11c365a6f2836404e2e5a21b-- From paulej@packetizer.com Thu Aug 1 12:47:38 2013 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 A1DB721E821C for ; Thu, 1 Aug 2013 12:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuPJhsSkRKJZ for ; Thu, 1 Aug 2013 12:47:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7042921E8217 for ; Thu, 1 Aug 2013 12:47: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 r71JlVGn013483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Aug 2013 15:47:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375386452; bh=WOhQKBFrEPW6yXS51eFr+8a8goze2l8eUxb3r1Fy3uk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=eQkQRio4dqa3jReGcY6vyS9jJ0rAKDIH1ktTHf1QeaB+QTMrTxdHFcgm1lyF/8YJE a0nzzJgO4pTtkl0lzLFixXH07CbcR5zmM+tFEr68ysLsa7/oK7tPwkFaFku9mxz2vs ivITDCL5V9Ucx47VFhBW1LRnQHQv+c7uEIUtDiPY= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> In-Reply-To: Date: Thu, 1 Aug 2013 15:47:27 -0400 Message-ID: <008b01ce8eef$f4924e40$ddb6eac0$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEAul1PlEC084uX5d8yFHQ Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 19:47:38 -0000 Hadriel, Thus sayest Hadriel Kaplan: > On Aug 1, 2013, at 9:26 AM, Paul E. Jones wrote: > > > 1) Alice calls Bob {A,B} > > 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking > > server) > > 3) Bob calls Carol {B,C} > > 4) Bob transfers the call from Alice to Carol {A,C} > > > > With the current solution, the order is only significant so that the > > receiving endpoint can clearly identify the UUID of the sender. > > > > If we utilized the former proposal, what would these UUID values be? > > 1) Alice calls Bob {A,B} > > 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking > > server?) > > I'm not sure what "if there is a parking server" means - I mean I know > what parking servers are, but I don't know how it's involved here from a > SIP protocol layer between Alice and Bob, in your example. Is Bob sending > a REFER to Alice to have her move to the parking server, or is Bob sending > a REFER to the parking server to have it send Alice an INVITE with > replaces, or is Bob making a separate call to the parking server and > sending Alice a re-INVITE/UPDATE just to move the media to the parking > server? The parking server was optional, but basically Bob is putting Alice on hold. This might just be a local hold or it might mean Bob moves Alice to a parking server. In the latter case, there would be no REFER to Alice since we would not want those messages going outside the enterprise and resulting in what appears to be a new phone call established. (Introduces billing issues and also introduces internal infrastructure details.) > > 3) Bob calls Carol {B,C} > > 4) Bob transfers the call from Alice to Carol {?,?} > > Same question as above - how is it doing it? > I ask these questions because the old draft-kaplan session-id had rules > about what to do for REFERs and INVITE with replaces, so I'm trying to see > where it breaks. Here, it would be a transfer managed on the PBX. Again, no REFER to Alice, but perhaps this: 1) PBX puts Carol on hold 2) PBX sends INVITE without SDP to take Carol off hold and to get SDP 3) PBX sends that SDP in an INVITE to Alice 4) Reply send to Carol Etc. Again, a REFER would not be wanted since Carol might be in a high-toll area and Bob should be handling the billing charges. Also, this is a call center type environment and Alice should never have direct contact information for Carol. So, the PBX wants to keep this local. > > Perhaps that last one might be {A,C}, which might work for Bob. But if > > Carol was an older endpoint, what would she do seeing this "A" value as > the > > first value? > > Carol sees it when? She see's it in a new INVITE? In a REFER? In a re- > INVITE? I meant to say {A,C} might work for Alice. If the PBX sends an INVITE to Carol with the Session-ID {A,C}, what will Carol do (assuming Carol is an old endpoint). See also my note to Laura. I removed the two UUID values and focus only on the one. When the PBX sends an INVITE to Carol following the transfer, it has only one of two values it could send: either A or C. Which does it choose? And if it sends C to Carol and sends A to Alice, then we do not have an end-to-end ID. We have an end-to-PBX ID. > I think we've talked about this before, but in case we hadn't: the > Session-ID value in the legacy draft didn't really identify a human or > user or even User Agent device - it's not "A" for "Alice" and "B" for > "Bob" - it's just a randomish number identifying a session. Since it > doesn't identify a particular device, it can move around/migrate, and > doesn't "belong" to Alice or Bob. I'm not saying that's a *good* property, > but since it had that property we can probably play games with parameters > to get what needs to be done for the new Session-ID uses. In our draft, these are also random values. However, when I use the notation 'A' or 'B', I'm referring to the random UUID generated by that respective endpoint. So, where I get confused with the previous draft is how it will deal with things like these PBX-managed call transfers (especially transfer out of consultation or joining two calls or conferencing calls legs together and one leg dropping out), IVR interactions in call centers (that are like transfers), etc. These are all real things we have to deal with and not because we did something strange in our systems. As a practical matter, we cannot send a REFER outside the enterprise in many cases. Paul From hadriel.kaplan@oracle.com Thu Aug 1 13:18:03 2013 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 72D2821E80BA for ; Thu, 1 Aug 2013 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QN9kVUXoLFpT for ; Thu, 1 Aug 2013 13:17:56 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id CD61311E80E3 for ; Thu, 1 Aug 2013 13:17:56 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r71KHkkU023936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 20:17:47 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71KHiSF003824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 20:17:46 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71KHi3v014449; Thu, 1 Aug 2013 20:17:44 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 13:17:44 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> Date: Thu, 1 Aug 2013 16:16:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 20:18:03 -0000 On Aug 1, 2013, at 3:47 PM, "Paul E. Jones" = wrote: >>> If we utilized the former proposal, what would these UUID values be? >>> 1) Alice calls Bob {A,B} >>> 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a = parking >>> server?) >>=20 >> I'm not sure what "if there is a parking server" means - I mean I = know >> what parking servers are, but I don't know how it's involved here = from a >> SIP protocol layer between Alice and Bob, in your example. Is Bob = sending >> a REFER to Alice to have her move to the parking server, or is Bob = sending >> a REFER to the parking server to have it send Alice an INVITE with >> replaces, or is Bob making a separate call to the parking server and >> sending Alice a re-INVITE/UPDATE just to move the media to the = parking >> server? >=20 > The parking server was optional, but basically Bob is putting Alice on = hold. > This might just be a local hold or it might mean Bob moves Alice to a > parking server. In the latter case, there would be no REFER to Alice = since > we would not want those messages going outside the enterprise and = resulting > in what appears to be a new phone call established. (Introduces = billing > issues and also introduces internal infrastructure details.) Right, so why do you need the Session-ID to change on the call leg = between Alice and Bob, if nothing changes in SIP between Alice and Bob? = I mean you got {A} from Alice, and Bob made it into {A,B} on that leg, = and then you sent an INVITE to the park server to park this call, so = send {A} to the park server, and let that call leg be {A,P}. The = SEssion-ID value "A" ties them together. Or heck, even send {A,B} to = the parking server. Regardless, if we need it to change we can - just the header value (the = part not including the parameters) doesn't change. The parameters can = change all day long and it would still be compatible with the legacy = draft. >>> 3) Bob calls Carol {B,C} >>> 4) Bob transfers the call from Alice to Carol {?,?} >>=20 >> Same question as above - how is it doing it? >> I ask these questions because the old draft-kaplan session-id had = rules >> about what to do for REFERs and INVITE with replaces, so I'm trying = to see >> where it breaks. >=20 > Here, it would be a transfer managed on the PBX. Again, no REFER to = Alice, > but perhaps this: > 1) PBX puts Carol on hold > 2) PBX sends INVITE without SDP to take Carol off hold and to get SDP > 3) PBX sends that SDP in an INVITE to Alice > 4) Reply send to Carol > Etc. >=20 > Again, a REFER would not be wanted since Carol might be in a high-toll = area > and Bob should be handling the billing charges. Also, this is a call = center > type environment and Alice should never have direct contact = information for > Carol. So, the PBX wants to keep this local. Right, as I would expect - so again same answer as I had above. >>> Perhaps that last one might be {A,C}, which might work for Bob. But = if >>> Carol was an older endpoint, what would she do seeing this "A" value = as >> the >>> first value? >>=20 >> Carol sees it when? She see's it in a new INVITE? In a REFER? In a = re- >> INVITE? >=20 > I meant to say {A,C} might work for Alice. If the PBX sends an INVITE = to > Carol with the Session-ID {A,C}, what will Carol do (assuming Carol is = an > old endpoint). See also my note to Laura. I removed the two UUID = values > and focus only on the one. When the PBX sends an INVITE to Carol = following > the transfer, it has only one of two values it could send: either A or = C. > Which does it choose? And if it sends C to Carol and sends A to = Alice, then > we do not have an end-to-end ID. We have an end-to-PBX ID. Well it feels like you want to hide the changes from Alice, but at the = same time you want Alice to know things changed because you want to send = her a new/updated UUID pairing. Isn't that revealing things changed to = Alice? This seems like a contradiction. But anyway... if you send a new INVITE to Carol, you can put the same = "A" in the Session-ID, or you could even put "A;C" in the Session-id. = The header value is "A", and its generated by the PBX to Carol, so per = the legacy draft Carol reflects it in her responses/requests back to the = PBX for that dialog. The legacy draft only had rules around the header = value, and allowed arbitrary parameters but had no rules around them. > So, where I get confused with the previous draft is how it will deal = with > things like these PBX-managed call transfers (especially transfer out = of > consultation or joining two calls or conferencing calls legs together = and > one leg dropping out), IVR interactions in call centers (that are like > transfers), etc. These are all real things we have to deal with and = not > because we did something strange in our systems. As a practical = matter, we > cannot send a REFER outside the enterprise in many cases. Yup, understood. But all we have to do for legacy compatibility is have = the sender of an out-of-dialog request send a UUID as the header value, = and that value cannot change for the duration of the dialog. We can = create new parameters, and they can change during a dialog if need be. = And there's nothing to prevent you from using the same "A" UUID you got = from Alice in a new INVITE to Carol 10 minutes later, so long as it's = the same session, which you're saying it is. So all we have to figure out is what to put in parameters, how they get = used (e.g., replaced if need be), etc., to support the same = scenarios/use-cases/requirements that the current solutions draft = supports. In the worst case, we could literally take the "local-uuid" = and "remote-uuid" fields of your draft and put them as two separate = *parameters* and do the send/receive swapping there, if that's what we = have to do. I'm hoping we don't have to go that far, but instead can = figure out how to do it with just the main header value and one = parameter. -hadriel From paulej@packetizer.com Thu Aug 1 13:48:38 2013 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 1FD1511E810E for ; Thu, 1 Aug 2013 13:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQhSpNWFU+wa for ; Thu, 1 Aug 2013 13:48:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5322D11E8150 for ; Thu, 1 Aug 2013 13:48: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 r71KmSOU017230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Aug 2013 16:48:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375390110; bh=zUxX17hYUbyqh5zSxwOaBXRrAbcciPjaBqhQCw4Q8NQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dKHR2FgcfaWMDzciUksin1B58ZggW5Rw0sjbtwvr7eibMzt1sFUUwwNYdQjcI3Wcq kHqv+xoIHHpcJJp9nK5cz+HdHzjP8B4E4vO7mMF43IiJwHohSktsbYyX0dxm0ArcZ/ S8sEgzOCWEuwGF6rkt+Tcr3aajKCDPMXcV+o1o04= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> In-Reply-To: <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> Date: Thu, 1 Aug 2013 16:48:25 -0400 Message-ID: <009c01ce8ef8$7906b780$6b142680$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEAul1PlEC084uXwHoWQp5AJYnTYyXaOWh8A== Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 20:48:38 -0000 Hadriel, > > The parking server was optional, but basically Bob is putting Alice on > hold. > > This might just be a local hold or it might mean Bob moves Alice to a > > parking server. In the latter case, there would be no REFER to Alice > since > > we would not want those messages going outside the enterprise and > resulting > > in what appears to be a new phone call established. (Introduces billing > > issues and also introduces internal infrastructure details.) > > Right, so why do you need the Session-ID to change on the call leg between > Alice and Bob, if nothing changes in SIP between Alice and Bob? I mean > you got {A} from Alice, and Bob made it into {A,B} on that leg, and then > you sent an INVITE to the park server to park this call, so send {A} to > the park server, and let that call leg be {A,P}. The SEssion-ID value "A" > ties them together. Or heck, even send {A,B} to the parking server. I didn't suggest anything is problematic to this point. Alice could have transferred the call with Bob to the parking lot and used "A" or "B" or whatever "the" value was. Let's not focus here... let's go to the end. It's the transfer out of consultation case that's the issue. > Regardless, if we need it to change we can - just the header value (the > part not including the parameters) doesn't change. The parameters can > change all day long and it would still be compatible with the legacy draft. And I'm not sure how we can avoid not changing the value before the parameter in the transfer case. > >>> 3) Bob calls Carol {B,C} > >>> 4) Bob transfers the call from Alice to Carol {?,?} > >> > >> Same question as above - how is it doing it? > >> I ask these questions because the old draft-kaplan session-id had rules > >> about what to do for REFERs and INVITE with replaces, so I'm trying to > see > >> where it breaks. > > > > Here, it would be a transfer managed on the PBX. Again, no REFER to > Alice, > > but perhaps this: > > 1) PBX puts Carol on hold > > 2) PBX sends INVITE without SDP to take Carol off hold and to get SDP > > 3) PBX sends that SDP in an INVITE to Alice > > 4) Reply send to Carol > > Etc. > > > > Again, a REFER would not be wanted since Carol might be in a high-toll > area > > and Bob should be handling the billing charges. Also, this is a call > center > > type environment and Alice should never have direct contact information > for > > Carol. So, the PBX wants to keep this local. > > Right, as I would expect - so again same answer as I had above. This one is really different. Let's consider the old draft. Bob calls Carol, so the Session-ID is some value we'll call 'B'. Bob was on a call with Alice with some value Alice assigned 'A'. Now, we want to join these two calls together so that Alice is talking with Carol (no REFER ... all local stuff). What is the Session-ID value in this case? What does the PBX send to Alice and Carol? You said the value cannot change, but I argue that *something* has to change on one leg of that call, else we do not have an E2E ID anymore. > > I meant to say {A,C} might work for Alice. If the PBX sends an INVITE > to > > Carol with the Session-ID {A,C}, what will Carol do (assuming Carol is > an > > old endpoint). See also my note to Laura. I removed the two UUID > values > > and focus only on the one. When the PBX sends an INVITE to Carol > following > > the transfer, it has only one of two values it could send: either A or C. > > Which does it choose? And if it sends C to Carol and sends A to Alice, > then > > we do not have an end-to-end ID. We have an end-to-PBX ID. > > Well it feels like you want to hide the changes from Alice, but at the > same time you want Alice to know things changed because you want to send > her a new/updated UUID pairing. Isn't that revealing things changed to > Alice? This seems like a contradiction. No, Alice knows the call transferred. That's not a problem. But, we would not want to reveal Carol's phone number or URI to Alice, and likely might want to hide other signaling elements. You know B2BUAs do strange things. But, we would like these random numbers to go end-to-end. Nothing is revealed in the random number. > But anyway... if you send a new INVITE to Carol, you can put the same "A" > in the Session-ID, or you could even put "A;C" in the Session-id. The > header value is "A", and its generated by the PBX to Carol, so per the > legacy draft Carol reflects it in her responses/requests back to the PBX > for that dialog. The legacy draft only had rules around the header value, > and allowed arbitrary parameters but had no rules around them. So it is legal, then, to change the header value between initially established between Bob and Carol (value 'B') to some new value 'A' at any time? > > So, where I get confused with the previous draft is how it will deal > with > > things like these PBX-managed call transfers (especially transfer out of > > consultation or joining two calls or conferencing calls legs together > and > > one leg dropping out), IVR interactions in call centers (that are like > > transfers), etc. These are all real things we have to deal with and not > > because we did something strange in our systems. As a practical matter, > we > > cannot send a REFER outside the enterprise in many cases. > > Yup, understood. But all we have to do for legacy compatibility is have > the sender of an out-of-dialog request send a UUID as the header value, > and that value cannot change for the duration of the dialog. We can > create new parameters, and they can change during a dialog if need be. > And there's nothing to prevent you from using the same "A" UUID you got > from Alice in a new INVITE to Carol 10 minutes later, so long as it's the > same session, which you're saying it is. There's no OOD messaging here. Bob puts Carol on hold and then the PBX sends a new INVITE to Carol with a new Session-ID header value that must replace the previous one. That's legal? > So all we have to figure out is what to put in parameters, how they get > used (e.g., replaced if need be), etc., to support the same scenarios/use- > cases/requirements that the current solutions draft supports. In the > worst case, we could literally take the "local-uuid" and "remote-uuid" > fields of your draft and put them as two separate *parameters* and do the > send/receive swapping there, if that's what we have to do. I'm hoping we > don't have to go that far, but instead can figure out how to do it with > just the main header value and one parameter. Yeah, once I understand exactly what is legal and can be changed, then working out the details in the current solution spec is not so difficult. I'm still not clear on this. It seems like there is a statement that the Session-ID established with Carol can never change, but now it seems like it can. But, I don't think that's your meaning. I just need to understand clearly. Paul From hadriel.kaplan@oracle.com Thu Aug 1 16:20:34 2013 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 939BE11E82E2 for ; Thu, 1 Aug 2013 16:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_00=-2.599, J_BACKHAIR_53=1, J_BACKHAIR_55=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVHgOrAXJ9WO for ; Thu, 1 Aug 2013 16:20:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0A26A11E8296 for ; Thu, 1 Aug 2013 15:46:55 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r71MkrU7026835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 22:46:54 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71Mkqm3004603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 22:46:52 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71MkpRP014272; Thu, 1 Aug 2013 22:46:51 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 15:46:51 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <009c01ce8ef8$7906b780$6b142680$@packetizer.com> Date: Thu, 1 Aug 2013 18:15:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6A36BEEC-B69D-4B39-A1E5-C988462DDB61@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> <009c01ce8ef8$7906b780$6b142680$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 23:20:34 -0000 As a side note: none of this discussion seems to have anything to do = with swapping directionality of value+parameter based on sender of = messages. This is really more about whether you can change the = Session-ID header value mid-dialog or not. I don't think that is actually required in the requirement document - = the relevant requirement is REQ2, but my impression is we don't need the = header value in particular to be updated and changed end-to-end... it = just required us to be able to correlate the two sessions = transferred/joined by a PBX *somehow*. I.e., as long as one UUID in = either a header value or param is the same on both sides, we'd be ok. = Would that be ok? [I'm not trying to be nit-picky and a stickler to the = requirements doc, but more asking if that's sufficient for your needs.] Other comments inline=85 On Aug 1, 2013, at 4:48 PM, Paul E. Jones wrote: > Bob calls Carol, so the Session-ID is some value we'll call 'B'. > Bob was on a call with Alice with some value Alice assigned 'A'. >=20 > Now, we want to join these two calls together so that Alice is talking = with > Carol (no REFER ... all local stuff). What is the Session-ID value in = this > case? =20 The *header value* would remain "A" on the Alice<->PBX call leg, and "B" = on the Carol<->Carol call leg. The header *parameter* can change, so we can tie it together there. So it would be: 1) Alice <-PBX-> Bob call: A;B 2) Bob <-PBX-> Carol call: B;C 3) Bob pushes some button to make PBX join Alice and Carol 4) Alice <-PBX is now A;C and PBX->Carol call is now B;A (or B;C if we = want it to be that instead) >> Well it feels like you want to hide the changes from Alice, but at = the >> same time you want Alice to know things changed because you want to = send >> her a new/updated UUID pairing. Isn't that revealing things changed = to >> Alice? This seems like a contradiction. >=20 > No, Alice knows the call transferred. That's not a problem. But, we = would > not want to reveal Carol's phone number or URI to Alice, and likely = might > want to hide other signaling elements. You know B2BUAs do strange = things. >=20 > But, we would like these random numbers to go end-to-end. Nothing is > revealed in the random number. OK I understand. I would point out though, that this is one case where = I bet people would have SBCs block this change from propagating out. = Some people don't like re-INVITEs/UPDATEs propagating out, for changes = that occur inside an Enterprise... whatsoever. I.e., if Alice is = calling into an Enterprise from a SIP Trunk, my guess is there'll be = some cases where the SBCs are configured to locally answer = re-INVITES/UPDATEs coming from the Enterprise side. We've been told to = do this both in cases when we get deployed as Service Provider-side and = cases where we're Enterprise-side SBCs, of SIP Trunks.[1] > So it is legal, then, to change the header value between initially > established between Bob and Carol (value 'B') to some new value 'A' at = any > time? No - I just meant the header parameter(s) can change anytime. -hadriel [1] We tried to argue against doing that for years, but eventually = relented when our competitors were willing to do it, and when we found = re-INVITE/UPDATE storms causing overloads. It turned out some = relatively popular Enterprise PBXs generate re-INVITEs numerous times in = the first several seconds, for every single received call, with nothing = significant changing. From hadriel.kaplan@oracle.com Thu Aug 1 17:55:22 2013 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 91A5311E8199 for ; Thu, 1 Aug 2013 17:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.538 X-Spam-Level: X-Spam-Status: No, score=-5.538 tagged_above=-999 required=5 tests=[AWL=-0.939, BAYES_00=-2.599, J_BACKHAIR_53=1, J_BACKHAIR_55=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR8CEnOnJOhA for ; Thu, 1 Aug 2013 17:55:06 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCC411E818B for ; Thu, 1 Aug 2013 16:57:13 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r71NvCf1017006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Aug 2013 23:57:12 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71NvBDU028449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 23:57:12 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r71NvAW3028042; Thu, 1 Aug 2013 23:57:11 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 16:57:10 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <009c01ce8ef8$7906b780$6b142680$@packetizer.com> Date: Thu, 1 Aug 2013 19:57:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E179BD5-29A4-4B77-BF2C-D81756996F78@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> <009c01ce8ef8$7906b780$6b142680$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 00:55:22 -0000 As a side note: none of this discussion seems to have anything to do = with swapping directionality of value+parameter based on sender of = messages. This is really more about whether you can change the = Session-ID header value mid-dialog or not. I don't think that is actually required in the requirement document - = the relevant requirement is REQ2, but my impression is we don't need the = header value in particular to be updated and changed end-to-end... it = just required us to be able to correlate the two sessions = transferred/joined by a PBX *somehow*. I.e., as long as one UUID in = either a header value or param is the same on both sides, we'd be ok. = Would that be ok? [I'm not trying to be nit-picky and a stickler to the = requirements doc, but more asking if that's sufficient for your needs.] Other comments inline=85 On Aug 1, 2013, at 4:48 PM, Paul E. Jones wrote: > Bob calls Carol, so the Session-ID is some value we'll call 'B'. > Bob was on a call with Alice with some value Alice assigned 'A'. >=20 > Now, we want to join these two calls together so that Alice is talking = with > Carol (no REFER ... all local stuff). What is the Session-ID value in = this > case? =20 The *header value* would remain "A" on the Alice<->PBX call leg, and "B" = on the Carol<->Carol call leg. The header *parameter* can change, so we can tie it together there. So it would be: 1) Alice <-PBX-> Bob call: A;B 2) Bob <-PBX-> Carol call: B;C 3) Bob pushes some button to make PBX join Alice and Carol 4) Alice <-PBX is now A;C and PBX->Carol call is now B;A (or B;C if we = want it to be that instead) >> Well it feels like you want to hide the changes from Alice, but at = the >> same time you want Alice to know things changed because you want to = send >> her a new/updated UUID pairing. Isn't that revealing things changed = to >> Alice? This seems like a contradiction. >=20 > No, Alice knows the call transferred. That's not a problem. But, we = would > not want to reveal Carol's phone number or URI to Alice, and likely = might > want to hide other signaling elements. You know B2BUAs do strange = things. >=20 > But, we would like these random numbers to go end-to-end. Nothing is > revealed in the random number. OK I understand. I would point out though, that this is one case where = I bet people would have SBCs block this change from propagating out. = Some people don't like re-INVITEs/UPDATEs propagating out, for changes = that occur inside an Enterprise... whatsoever. I.e., if Alice is = calling into an Enterprise from a SIP Trunk, my guess is there'll be = some cases where the SBCs are configured to locally answer = re-INVITES/UPDATEs coming from the Enterprise side. We've been told to = do this both in cases when we get deployed as Service Provider-side and = cases where we're Enterprise-side SBCs, of SIP Trunks.[1] > So it is legal, then, to change the header value between initially > established between Bob and Carol (value 'B') to some new value 'A' at = any > time? No - I just meant the header parameter(s) can change anytime. -hadriel [1] We tried to argue against doing that for years, but eventually = relented when our competitors were willing to do it, and when we found = re-INVITE/UPDATE storms causing overloads. It turned out some = relatively popular Enterprise PBXs generate re-INVITEs numerous times in = the first several seconds, for every single received call, with nothing = significant changing. From hadriel.kaplan@oracle.com Thu Aug 1 18:27:34 2013 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 E424B11E8335 for ; Thu, 1 Aug 2013 18:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YhApg1QOQiw for ; Thu, 1 Aug 2013 18:27:21 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6211E83B8 for ; Thu, 1 Aug 2013 17:28:43 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r720Serc009713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 00:28:41 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r720Sdq2020023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 00:28:40 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r720SdAN024881; Fri, 2 Aug 2013 00:28:39 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 01 Aug 2013 17:28:39 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> Date: Thu, 1 Aug 2013 20:28:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: insipid@ietf.org, Laura Liess Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 01:27:35 -0000 On Aug 1, 2013, at 11:59 AM, Paul E. Jones = wrote: > Laura, >=20 > The example I show below is a real call center example. I show use of = the old session ID. Tell me how that works. Forget about the new = solution for the moment. >=20 Forgetting about the new solution... the old solution worked because it = never claimed or attempted to solve the problem you're trying to solve. = It was just to help with troubleshooting; and because it was just to = help with troubleshooting it was kept as simple as possible in order to = make it easy to implement, and so as not to cause a need to troubleshoot = the troubleshooting tool. Due to that, it does support call transfers = being tracked by a Session-ID when REFERs and INVITE w/replaces were = used for the transfer; but not when SIP itself didn't change at all, and = instead a media-bridge switches around what media is going to whom. = Session-ID wasn't really meant to be a media-flow tracking mechanism = originally. When this was in DISPATCH, we talked about sending re-INVITEs/UPDATEs to = modify the Session-ID in case of hidden transfers and such - but the = general consensus at that time was not to bother. It would be insane to = expect things to send re-INVITEs/UPDATEs all over the place to = update/change Session-ID values just to help troubleshooting - who would = want a troubleshooting-aid thing to do that really? So we basically = decided not to do that, and instead keep it simple and lightweight. That's why I argued so much originally against adding the extra = requirements to track hidden transfers and conference servers and such. = It requires sending re-INVITEs/UPDATEs to all parties, and I had a hard = time believing folks would really want that to happen in practice. But = the WG decided it was worth it, and to have the requirement; but = meanwhile to not break backwards compatibility. So I think there're two = ways to go about it: either (1) work around the limitations of the = legacy individual draft, or (2) pick a new header name "Media-ID" or = some such and not be constrained by the old draft. -hadriel p.s. personally I'd be ok with either option-1 or option-2, fwiw. From prvs=19265d221f=aallen@blackberry.com Thu Aug 1 23:55:16 2013 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 60F7311E824D for ; Thu, 1 Aug 2013 23:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+ViegEtskLb for ; Thu, 1 Aug 2013 23:55:11 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 821D611E8248 for ; Thu, 1 Aug 2013 23:55:11 -0700 (PDT) X-AuditID: 0a41282f-b7f9b6d000002847-be-51fb57c7decf Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 5F.4E.10311.8C75BF15; Fri, 2 Aug 2013 01:55:04 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 01:55:03 -0500 From: Andrew Allen To: "hadriel.kaplan@oracle.com" , "paulej@packetizer.com" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: Ac6ObL8bHmdBy9j3R4y13v8TdvwiwQAU+ioAAAj8mIAABgtWgAAHRSeAAAEC1gAAC9PUwA== Date: Fri, 2 Aug 2013 06:55:02 +0000 Message-ID: In-Reply-To: <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXC5ZyvpXsi/Hegwd0b/BafNn1itph//xmT xfkLG5gcmD2WLPnJ5PHx6S0Wj4Z9R9kDmKMaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5Nt lXxS0xNzFAKKMssSkysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4 FDCADVBZZp5Cal5yfkpmXrqtkmewv66FhamlrqGSnW5CJ0/GhfXbWAu2GVfMa73B1MC4TaOL kYNDQsBEYv9mky5GTiBTTOLCvfVsXYxcHEICKxkleq92MEM4mxgl9iyeyghSxSagJbH/8HQm EFtEIE+iuakXLM4soCmxYvFtdhBbWMBb4u63mawQNT4SH2a/YoewwyTWvf4CZrMIqEgsOX8N rIZXwEPi3rpmMJtTwE7i3+0XzCA2o4CsxO6z15kg5otL3HoynwniUgGJJXvOM0PYohIvH/9j hbAVJWbsmc8KUa8ncWPqFDYIW1ti2cLXzBC7BCVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZV jIK5GcUGZgbJecl6RZm5enmpJZsYQSnCUUN/B+Pb9xaHGAU4GJV4eDVdfwcKsSaWFVfmHmKU 4GBWEuH9M/tXoBBvSmJlVWpRfnxRaU5q8SFGV2BITGSW4k7OB6avvJJ4YwMD3BwlcV5XlQ+B QgLpwOSTnZpakFoEM4eJgxNkD5eUSDEwhaQWJZaWZMSDEl18MTDVSTUwakzIaZj1c+PU7cc1 yvm8YiasuBJwv+6oDd/q9sOefNxrty0qtv9+kXHyPvbMnC8LY4NeBb39/tZw/6XTSbWHX99a s3VvystV60PX9Vaq8fW6v1tTXbBycutNCbZwl14j43iNLf0K+1oeNrdc313L2Fp6oOenuIjZ tEN5rV+ypBfttflYdEz3uRJLcUaioRZzUXEiAHoFcMZSAwAA Cc: "insipid@ietf.org" Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:55:16 -0000 +1 ----- Original Message ----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: Thursday, August 01, 2013 03:16 PM Central Standard Time=0A= To: Paul E. Jones Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility On Aug 1, 2013, at 3:47 PM, "Paul E. Jones" wrote: >>> If we utilized the former proposal, what would these UUID values be? >>> 1) Alice calls Bob {A,B} >>> 2) Bob puts Alice on hold (perhaps {A,B}, or {A,P} if there is a parking >>> server?) >> >> I'm not sure what "if there is a parking server" means - I mean I know >> what parking servers are, but I don't know how it's involved here from a >> SIP protocol layer between Alice and Bob, in your example. Is Bob sendin= g >> a REFER to Alice to have her move to the parking server, or is Bob sendin= g >> a REFER to the parking server to have it send Alice an INVITE with >> replaces, or is Bob making a separate call to the parking server and >> sending Alice a re-INVITE/UPDATE just to move the media to the parking >> server? > > The parking server was optional, but basically Bob is putting Alice on hol= d. > This might just be a local hold or it might mean Bob moves Alice to a > parking server. In the latter case, there would be no REFER to Alice sinc= e > we would not want those messages going outside the enterprise and resultin= g > in what appears to be a new phone call established. (Introduces billing > issues and also introduces internal infrastructure details.) Right, so why do you need the Session-ID to change on the call leg between A= lice and Bob, if nothing changes in SIP between Alice and Bob? I mean you g= ot {A} from Alice, and Bob made it into {A,B} on that leg, and then you sent= an INVITE to the park server to park this call, so send {A} to the park ser= ver, and let that call leg be {A,P}. The SEssion-ID value "A" ties them tog= ether. Or heck, even send {A,B} to the parking server. Regardless, if we need it to change we can - just the header value (the part= not including the parameters) doesn't change. The parameters can change al= l day long and it would still be compatible with the legacy draft. >>> 3) Bob calls Carol {B,C} >>> 4) Bob transfers the call from Alice to Carol {?,?} >> >> Same question as above - how is it doing it? >> I ask these questions because the old draft-kaplan session-id had rules >> about what to do for REFERs and INVITE with replaces, so I'm trying to se= e >> where it breaks. > > Here, it would be a transfer managed on the PBX. Again, no REFER to Alice= , > but perhaps this: > 1) PBX puts Carol on hold > 2) PBX sends INVITE without SDP to take Carol off hold and to get SDP > 3) PBX sends that SDP in an INVITE to Alice > 4) Reply send to Carol > Etc. > > Again, a REFER would not be wanted since Carol might be in a high-toll are= a > and Bob should be handling the billing charges. Also, this is a call cent= er > type environment and Alice should never have direct contact information fo= r > Carol. So, the PBX wants to keep this local. Right, as I would expect - so again same answer as I had above. >>> Perhaps that last one might be {A,C}, which might work for Bob. But if >>> Carol was an older endpoint, what would she do seeing this "A" value as >> the >>> first value? >> >> Carol sees it when? She see's it in a new INVITE? In a REFER? In a re- >> INVITE? > > I meant to say {A,C} might work for Alice. If the PBX sends an INVITE to > Carol with the Session-ID {A,C}, what will Carol do (assuming Carol is an > old endpoint). See also my note to Laura. I removed the two UUID values > and focus only on the one. When the PBX sends an INVITE to Carol followin= g > the transfer, it has only one of two values it could send: either A or C. > Which does it choose? And if it sends C to Carol and sends A to Alice, th= en > we do not have an end-to-end ID. We have an end-to-PBX ID. Well it feels like you want to hide the changes from Alice, but at the same= time you want Alice to know things changed because you want to send her a n= ew/updated UUID pairing. Isn't that revealing things changed to Alice? Thi= s seems like a contradiction. But anyway... if you send a new INVITE to Carol, you can put the same "A" in= the Session-ID, or you could even put "A;C" in the Session-id. The header= value is "A", and its generated by the PBX to Carol, so per the legacy draf= t Carol reflects it in her responses/requests back to the PBX for that dialo= g. The legacy draft only had rules around the header value, and allowed arb= itrary parameters but had no rules around them. > So, where I get confused with the previous draft is how it will deal with > things like these PBX-managed call transfers (especially transfer out of > consultation or joining two calls or conferencing calls legs together and > one leg dropping out), IVR interactions in call centers (that are like > transfers), etc. These are all real things we have to deal with and not > because we did something strange in our systems. As a practical matter, w= e > cannot send a REFER outside the enterprise in many cases. Yup, understood. But all we have to do for legacy compatibility is have the= sender of an out-of-dialog request send a UUID as the header value, and tha= t value cannot change for the duration of the dialog. We can create new par= ameters, and they can change during a dialog if need be. And there's nothin= g to prevent you from using the same "A" UUID you got from Alice in a new IN= VITE to Carol 10 minutes later, so long as it's the same session, which you'= re saying it is. So all we have to figure out is what to put in parameters, how they get used= (e.g., replaced if need be), etc., to support the same scenarios/use-cases/= requirements that the current solutions draft supports. In the worst case,= we could literally take the "local-uuid" and "remote-uuid" fields of your d= raft and put them as two separate *parameters* and do the send/receive swapp= ing there, if that's what we have to do. I'm hoping we don't have to go tha= t far, but instead can figure out how to do it with just the main header val= ue and one parameter. -hadriel _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From keith.drage@alcatel-lucent.com Fri Aug 2 00:43:44 2013 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 7D7E611E82A2 for ; Fri, 2 Aug 2013 00:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.335 X-Spam-Level: X-Spam-Status: No, score=-110.335 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7Dzu8YxDk2d for ; Fri, 2 Aug 2013 00:43:38 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5C211E8286 for ; Fri, 2 Aug 2013 00:43:32 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r727hTHY018175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2013 02:43:30 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r727hSgb028650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 09:43:28 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 09:43:28 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Laura Liess'" , "insipid@ietf.org" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: AQKz7rH6HmdBy9j3R4y13v8TdvwiwQFpbrGEArQAdNoCZGOF7ZeBoOPAgAERBdA= Date: Fri, 2 Aug 2013 07:43:27 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07A940@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> In-Reply-To: <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B07A940FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:43:44 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B07A940FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let us get this clear. The Kaplan draft is not expected to meet all the requirements. If it did, w= e would probably be progressing it as the solution document. What the previous decision of the working group effectively required, when = it desired compatibility, was that sensible things should happen as far as = possible when the two solutions interoperated. There is also no implication= that when Kaplan draft meets WG solution that all the requirements are met= . The desire for compatibility is based on the fact that the previous solutio= n is out there in the field. One solution will meet the other. One solution= should not bomb the other one out. Implementors of the Kaplan solution wil= l migrate to the real solution at some point and that intent has been expre= ssed in the meeting several times. But that migration will not happen overn= ight as soon as the WG RFCs are published. Regards Keith ________________________________ From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: 01 August 2013 16:00 To: 'Laura Liess'; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Laura, I assert that old draft will not work for some "real-world" calls. Calls d= o get manipulated in enterprise environments and call centers for billing p= urposes, privacy reasons, etc. Consider a common case: if you call into a call center and the agent puts y= ou on hold while they transfer you to a specialist (transfer out of consult= ation), for example, your SIP UA does not receive a REFER to initiate a new= call directly to the specialist. This is handled at the call center. So rather specifically, how would this be handled (with the old draft)? 1) Alice calls Bob (Session-ID: A) 2) Bob puts Alice on hold and calls Carol (Session-ID: B) 3) Bob transfers the call from Alice to Carol using a local transfer functi= on on the PBX (Session-ID: ??) The PBX could send different values to Alice and Carol, but we totally lose= the end-to-end identification of the call. Alice could not send "A" to Carol, since Carol is expecting B. Likewise, C= arol cannot send "B" to Alice, since Alice is expecting "A". Well, they co= uld, and it would be no worse than our current proposal in terms of backwar= d-compatibility. Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Laura Liess Sent: Thursday, August 01, 2013 9:13 AM To: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Hadriel's proposal works for us. Thank you Laura 2013/8/1 Hadriel Kaplan > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vend= or. This is just about a Working Group document, and whether the mechanism= defined in it should change the Session-ID header value vs. parameter base= d on direction of messages, or not. I totally get the need to have a disti= nguishing Session-ID identifier for party-A vs. party-B. What I don't get = is why they need to change the encoding of the Session-ID header value vs. = parameter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" This second model keeps the Session-ID header value as "foo" the whole time= , while adding a parameter of "bar" for Bob that remains a parameter the wh= ole time. Neither Alice nor Bob are confused about which one is "their" UUID value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why it = had to be swapped, but I don't remember what it is and I don't see it in th= e draft. So I'm trying to find out why we need to do it the way the draft = currently has it. The other topic of whether SBCs will change things is completely orthogonal= to the ordering or backwards compatibility issues, and really shouldn't be= conflated with it at all. It has nothing to do with the solutions documen= t, or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones > wrote: > Folks, > > I step away for a couple of days and the floodgate opens. :) > > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to effectively > deal with things like forking, call transfer, park, bridging, conferencin= g, > etc. > > When initiating a call and using a single UUID value, that has the potent= ial > to go end-to-end. However, if a call is forked there are multiple "ends". > How do we track each of those? For proper diagnostics and troubleshootin= g, > it would be ideal to be able to identify which devices have an issue. > > Once a call has been placed, there is a Session-ID established between Al= ice > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > different country) to a some location in a high-toll country, who pays th= e > bill? Well, to address that, we do call transfer locally on PBXes. The = PBX > maintains control over the call and Alice would pay the bill for the call > transfer. But if Alice was talking to Carol before the transfer, there i= s a > Session-ID for that call. If Bob is put in communication with Carol, wha= t > is the Session-ID value? Bob had one and Carol had a different one. Wha= t > is the new ID? > > It's issues like this that led us to using a two-part value. In this way= , > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > transfers the call to Carol, each device understands that the Session-ID > changed to {B,C}. Not only that, but intermediaries along the path that > were not privy to signaling that resulted in this change can take note of > the fact the value changed. This can provide a useful historical record, > since previously they might see a call to Carol identified as {A,C}, but > then it changed to {B,C}. > > This property extends quite naturally to other signaling scenarios, as it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value out = of > the two. > > Hadriel mentioned the desire to use the Session-ID to correlate media flo= ws > and calls. That's certainly something Cisco would like to do, but it is = not > the driver behind the solution. Having a valid end-to-end identifier (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a soluti= on > that allows us to properly identify calls end-to-end and we recognize tha= t, > due to various service interactions in the network, these UUID values can > change. > > I would hope that UUID values will not change to the extent that SBCs cha= nge > them for business reasons. It would certainly defeat the point. Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that su= ch > a request effectively breaks the end-to-end model. We can't do much abou= t > that if they do go down that path. > > As for backward-compatibility, the simplest approach (IMO) is to just use= a > header value not already in use. Originally, we had proposed Session-UUI= D. > That was changed at the request of the group to be Session-ID. However, > when we have a two UUID solution interacting with a one-UUID solution, we > immediately face some challenges. > > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=3DX > > Does this break things? If so, how do current implementations deal with > such things as mid-call transfers that happen on a PBX like the one I > described above? > > We could switch the order like this: > Session-ID: X; remote=3DY > > However, that does not work for similar reasons. If we have a call trans= fer > where Alice transfers a call with Bob to Carol, then each has a different > idea about what the proper value is for the first position. > > Originally, the proposed solution did not indicate position information a= nd > just had single UUID values going in each direction. We then proposed a > concatenated string (X:Y). However, that presented the same issues for th= e > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end has f= or > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) > > So, that's why we are where we are. There has been an effort to maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been told > explicitly what the issues are. Further, if there are such issues, we ne= ed > to also understand how those would be handled in the face of call transfe= r > or "joining" a call locally on a PBX. Those are real-world scenarios tha= t > we must address. > > Anyway, nothing is set in stone. Anything can be changed, but I would ho= pe > we can find a solution that works for the enterprise use cases as well as > the service provider networks. > > 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 --_000_949EF20990823C4C85C18D59AA11AD8B07A940FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let us get this clear.

 

The Kaplan draft is not expected to me= et all the requirements. If it did, we would probably be progressing it as = the solution document.

 

What the previous decision of the work= ing group effectively required, when it desired compatibility, was that sen= sible things should happen as far as possible when the two solutions interoperated. There is a= lso no implication that when Kaplan draft meets WG solution that all the re= quirements are met.

 

The desire for compatibility is based = on the fact that the previous solution is out there in the field. One solut= ion will meet the other. One solution should not bomb the other one out. Implementors of the Kaplan= solution will migrate to the real solution at some point and that intent h= as been expressed in the meeting several times. But that migration will not= happen overnight as soon as the WG RFCs are published.

 

Regards

 

Keith

 

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On B= ehalf Of Paul E. Jones
Sent: 01 August 2013 16:00 To: 'Laura Liess'; insipid@i= etf.org
Subject: Re: [Insipid] Propo= sed INSIPID solution and backward compatibility

 

= Laura,

=  

= I assert that old draft will not work for some “real-worldR= 21; calls.  Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc.

=  

= Consider a common case: if you call into a call center and the agent= puts you on hold while they transfer you to a specialist (transfer out of consultation), for example, your SIP UA does= not receive a REFER to ini= tiate a new call directly to the specialist.  This is handled at the c= all center.

=  

= So rather specifically, how would this be handled (with the old draf= t)?

=  

= 1) Alice c= alls Bob (Session-ID: A)

= 2) Bob puts Alice o= n hold and calls Carol (Session-ID: B)

= 3) Bob transfers the call from Alice t= o Carol using a local transfer function on the PBX (Session-ID: ??)

=  

= The PBX could send different values to Alice and Carol, but we total= ly lose the end-to-end identification of the call.

=  

Alice could not send “A” to Carol, since Carol is expecting B. = Likewise, Carol cannot send “B” to Alice, since Alice is expecting “A”.&= nbsp; Well, they could, and it would be no worse than our current proposal = in terms of backward-compatibility.

=  

= Paul

=  

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On B= ehalf Of Laura Liess
Sent: Thursday, August 01, 2013 9= :13 AM
To: insipid@ietf.org
Subject: Re: [Insipid] Propo= sed INSIPID solution and backward compatibility

 


Hadriel's proposal works for us.

Thank you
Laura

&= nbsp;

2013/8/1 Hadriel Kaplan <hadriel.kaplan@orac= le.com>


This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor. &nb= sp;This is just about a Working Group document, and whether the mechanism d= efined in it should change the Session-ID header value vs. parameter based on direction of messages, or not.  I= totally get the need to have a distinguishing Session-ID identifier for pa= rty-A vs. party-B.  What I don't get is why they need to change the en= coding of the Session-ID header value vs. parameter, on a message direction basis.

In other words, today the draft has this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: bar;remote= =3Dfoo"
3) Alice sends ACK with        "Session-ID: foo;remote=3D= bar"
4) Bob   sends BYE with        "Session-ID: b= ar;remote=3Dfoo"
5) Alice sends 200 with        "Session-ID: foo;remote=3D= bar"

But we could instead do this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: foo;remote= =3Dbar"
3) Alice sends ACK with        "Session-ID: foo;remote=3D= bar"
4) Bob   sends BYE with        "Session-ID: f= oo;remote=3Dbar"
5) Alice sends 200 with        "Session-ID: foo;remote=3D= bar"

This second model keeps the Session-ID header value as "foo" the = whole time, while adding a parameter of "bar" for Bob that remain= s a parameter the whole time.
Neither Alice nor Bob are confused about which one is "their" UUI= D value.
And it's backward-compatible with the previous kaplan-draft.
And it's arguably easier to implement, for the common cases.

I *think* there was a reason someone came up with at one time as to why it = had to be swapped, but I don't remember what it is and I don't see it in th= e draft.  So I'm trying to find out why we need to do it the way the d= raft currently has it.

The other topic of whether SBCs will change things is completely orthogonal= to the ordering or backwards compatibility issues, and really shouldn't be= conflated with it at all.  It has nothing to do with the solutions do= cument, or the direction stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones <paulej@packetizer.com> wrote:

> Folks,
>
> I step away for a couple of days and the floodgate opens. :)
>
> I think it's important to understand why we proposed using a two-part<= br> > Session Identifier.  The reason is that we have to be able to eff= ectively
> deal with things like forking, call transfer, park, bridging, conferen= cing,
> etc.
>
> When initiating a call and using a single UUID value, that has the pot= ential
> to go end-to-end. However, if a call is forked there are multiple &quo= t;ends".
> How do we track each of those?  For proper diagnostics and troubl= eshooting,
> it would be ideal to be able to identify which devices have an issue.<= br> >
> Once a call has been placed, there is a Session-ID established between= Alice
> and Bob.  If Alice (in one country) transfers Bob (perhaps in the same o= r
> different country) to a some location in a high-toll country, who pays= the
> bill?  Well, to address that, we do call transfer locally on PBXe= s.  The PBX
> maintains control over the call and Alice would pay the bill for the call
> transfer.  But if Al= ice was talking to Carol before the transfer, there = is a
> Session-ID for that call.  If Bob is put in communication with Ca= rol, what
> is the Session-ID value?  Bob had one and Carol had a different o= ne.  What
> is the new ID?
>
> It's issues like this that led us to using a two-part value.  In = this way,
> we could see the call from Alice to Bob has a Session-ID {A,B}.  If Alice > transfers the call to Carol, each device understands that the Session-= ID
> changed to {B,C}.  Not only that, but intermediaries along the pa= th that
> were not privy to signaling that resulted in this change can take note= of
> the fact the value changed.  This can provide a useful historical= record,
> since previously they might see a call to Carol identified as {A,C}, b= ut
> then it changed to {B,C}.
>
> This property extends quite naturally to other signaling scenarios, as= it
> allows one to identify a call end-to-end, but also establish some
> relationship between other calls that shared at least one UUID value o= ut of
> the two.
>
> Hadriel mentioned the desire to use the Session-ID to correlate media = flows
> and calls.  That's certainly something Cisco would like to do, bu= t it is not
> the driver behind the solution.  Having a valid end-to-end identi= fier (in
> whatever form) allows us to do that.  We're not suggesting to fit= the
> solution to meet that business use case, but rather we just want a sol= ution
> that allows us to properly identify calls end-to-end and we recognize = that,
> due to various service interactions in the network, these UUID values = can
> change.
>
> I would hope that UUID values will not change to the extent that SBCs = change
> them for business reasons.  It would certainly defeat the point. =  Hadriel
> might be right that an SBC vendor might manipulate those values at the
> request of a customer, but I would hope said customer appreciates that= such
> a request effectively breaks the end-to-end model.  We can't do m= uch about
> that if they do go down that path.
>
> As for backward-compatibility, the simplest approach (IMO) is to just use a
> header value not already in use.  Originally, we had proposed Ses= sion-UUID.
> That was changed at the request of the group to be Session-ID.  H= owever,
> when we have a two UUID solution interacting with a one-UUID solution,= we
> immediately face some challenges.
>
> What happens if an older system sends this:
>  Session-ID: X
> But then receives this:
>  Session-ID: Y; remote=3DX
>
> Does this break things?  If so, how do current implementations de= al with
> such things as mid-call transfers that happen on a PBX like the one I<= br> > described above?
>
> We could switch the order like this:
>  Session-ID: X; remote=3DY
>
> However, that does not work for similar reasons.  If we have a ca= ll transfer
> where Alice transfers a call with Bob to Carol, then each has a different
> idea about what the proper value is for the first position.
>
> Originally, the proposed solution did not indicate position informatio= n and
> just had single UUID values going in each direction.  We then pro= posed a
> concatenated string (X:Y). However, that presented the same issues for= the
> call transfer case, so we indicate values by position (sender's value<= br> > first), so it is clear what value the receive thinks the remote end ha= s for
> the local end.  It might be wrong, but that will be corrected in = the
> following response. (Intermediaries can take note of the change.)
>
> So, that's why we are where we are.  There has been an effort to = maintain
> backward-compatibility, but there are challenges in meeting that
> requirement.  Where it falls short, we do not know: we've not bee= n told
> explicitly what the issues are.  Further, if there are such issue= s, we need
> to also understand how those would be handled in the face of call tran= sfer
> or "joining" a call locally on a PBX.  Those are real-w= orld scenarios that
> we must address.
>
> Anyway, nothing is set in stone.  Anything can be changed, but I = would hope
> we can find a solution that works for the enterprise use cases as well= as
> the service provider networks.
>
> Paul
>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org=
> https://www.ietf.org/mailman/listinfo/insipid

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

 

 

--_000_949EF20990823C4C85C18D59AA11AD8B07A940FR712WXCHMBA11zeu_-- From prvs=5926943971=aallen@blackberry.com Fri Aug 2 00:56:49 2013 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 C369421E8249 for ; Fri, 2 Aug 2013 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.733 X-Spam-Level: X-Spam-Status: No, score=-5.733 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2vnnHiPtHkl for ; Fri, 2 Aug 2013 00:56:43 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id B99D111E8283 for ; Fri, 2 Aug 2013 00:56:42 -0700 (PDT) X-AuditID: 0a41282f-b7f9b6d000002847-98-51fb662410a3 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 92.CE.10311.4266BF15; Fri, 2 Aug 2013 02:56:21 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 02:56:20 -0500 From: Andrew Allen To: "keith.drage@alcatel-lucent.com" , "paulej@packetizer.com" , "laura.liess.dt@googlemail.com" , "insipid@ietf.org" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: AQHOj1XF0NEH5jKMHUSVtl/o795Uuw== Date: Fri, 2 Aug 2013 07:56:18 +0000 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07A940@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338DF08AFXMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsXC5Zyvpaua9jvQYOUsbov5958xWTxtPMto MeeKocX5CxuYHFg8Wp/tZfV4OmEyu8eSJT+ZPBr2HWUPYIlqYLRJSiwpC85Mz9O3s0nMy8sv SSxJVUhJLU62VfJJTU/MUQgoyixLTK5UcMksTs5JzMxNLVJSyEyxVTJRUijISUxOzU3NK7FV SiwoSM1LUbLjUsAANkBlmXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZKdroJnTwZb2efYCtomshc cfHoSsYGxhNtzF2MnBwSAiYS/36tY4GwxSQu3FvP1sXIxSEksJJR4mDfNkYIZxOjROv1l2wg VWwCWhL7D09nAkmICDxhlHh49gnYKGEBb4m732aygtgiAj4SH2a/Yoew9STOnN4I1MzBwSKg InF4Ntg2XgEPiZcd78FaOQWiJQ60dIDFGQVkJXafvc4EYjMLiEvcejKfCeI6AYkle85DXS0q 8fLxP1YIW1Fixp75rBD1+RK9U26wQcwXlDg58wnLBEbhWUhGzUJSNgtJ2Syg65gFNCXW79KH KFGUmNL9kB3C1pBonTOXHVl8ASP7KkbB3IxiAzOD5LxkvaLMXL281JJNjKCE4qihv4Px7XuL Q4wCHIxKPLz1Ub8DhVgTy4orcw8xSnAwK4nw/pn9K1CINyWxsiq1KD++qDQntfgQYxAwfCYy S3En5wOTXV5JvLGBAZEcJXFeV5UPgUIC6cCUlZ2aWpBaBDOUiYMTZCmXlEgxMPGkFiWWlmTE g9JjfDEwQUo1MC5Isjwb0Wmx7PVCha8h83sXXftit/lyzY5XgW+YJQ5/nlfx/3Cj5xel+ceC FBo8q2YbfNmwRMPRfUF8n8XqkheNby5VLvM0Xz33N7/fBvNvn/z77+R8SjCrn/26Jn9nqIN3 +myVhh6R+8/UZWIYeV/9qWgoT7nuLS63wMPl1K/bhkyFroqMc5RYijMSDbWYi4oTAf3IZNt2 AwAA Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:56:50 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338DF08AFXMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpQdXR0aW5nIGl0IGFub3RoZXIgd2F5Og0KDQpUaGluZ3MgdGhhdCB3b3JrIHdpdGggdGhl IGthcGxhbiBkcmFmdCBzaG91bGQgY29udGludWUgdG8gd29yayB3aGVuIGEga2FwbGFuIGNv bXBsaWFudCBpbXBsZW1lbnRhdGlvbiBpbnRlcndvcmtzIHdpdGggdGhlIFdHIHNvbHV0aW9u IGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMuDQoNClRoaW5ncyB0aGF0IGRvbid0IHdvcmsg d2l0aCB0aGUga2FwbGFuIGRyYWZ0IGFyZSBub3QgZXhwZWN0ZWQgdG8gd29yayB3aGVuIGEg a2FwbGFuIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBpbnRlcndvcmtzIHdpdGggdGhlIFdH IHNvbHV0aW9uIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgaG93ZXZlciB0aGUgZGVncmFk ZWQgYmVoYXZpb3Igc2hvdWxkIGJlIG5vIHdvcnNlIHRoYW4gYmV0d2VlbiBrYXBsYW4gY29t cGxpYW50IGltcGxlbWVudGF0aW9ucy4NCg0KQW5kcmV3DQoNCkZyb206IERSQUdFLCBLZWl0 aCAoS2VpdGgpIFttYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tXQ0KU2Vu dDogRnJpZGF5LCBBdWd1c3QgMDIsIDIwMTMgMDI6NDMgQU0gQ2VudHJhbCBTdGFuZGFyZCBU aW1lDQpUbzogUGF1bCBFLiBKb25lcyA8cGF1bGVqQHBhY2tldGl6ZXIuY29tPjsgJ0xhdXJh IExpZXNzJyA8bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb20+OyBpbnNpcGlkQGlldGYu b3JnIDxpbnNpcGlkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJbnNpcGlkXSBQcm9wb3Nl ZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQoNCkxldCB1 cyBnZXQgdGhpcyBjbGVhci4NCg0KVGhlIEthcGxhbiBkcmFmdCBpcyBub3QgZXhwZWN0ZWQg dG8gbWVldCBhbGwgdGhlIHJlcXVpcmVtZW50cy4gSWYgaXQgZGlkLCB3ZSB3b3VsZCBwcm9i YWJseSBiZSBwcm9ncmVzc2luZyBpdCBhcyB0aGUgc29sdXRpb24gZG9jdW1lbnQuDQoNCldo YXQgdGhlIHByZXZpb3VzIGRlY2lzaW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGVmZmVjdGl2 ZWx5IHJlcXVpcmVkLCB3aGVuIGl0IGRlc2lyZWQgY29tcGF0aWJpbGl0eSwgd2FzIHRoYXQg c2Vuc2libGUgdGhpbmdzIHNob3VsZCBoYXBwZW4gYXMgZmFyIGFzIHBvc3NpYmxlIHdoZW4g dGhlIHR3byBzb2x1dGlvbnMgaW50ZXJvcGVyYXRlZC4gVGhlcmUgaXMgYWxzbyBubyBpbXBs aWNhdGlvbiB0aGF0IHdoZW4gS2FwbGFuIGRyYWZ0IG1lZXRzIFdHIHNvbHV0aW9uIHRoYXQg YWxsIHRoZSByZXF1aXJlbWVudHMgYXJlIG1ldC4NCg0KVGhlIGRlc2lyZSBmb3IgY29tcGF0 aWJpbGl0eSBpcyBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IHRoZSBwcmV2aW91cyBzb2x1dGlv biBpcyBvdXQgdGhlcmUgaW4gdGhlIGZpZWxkLiBPbmUgc29sdXRpb24gd2lsbCBtZWV0IHRo ZSBvdGhlci4gT25lIHNvbHV0aW9uIHNob3VsZCBub3QgYm9tYiB0aGUgb3RoZXIgb25lIG91 dC4gSW1wbGVtZW50b3JzIG9mIHRoZSBLYXBsYW4gc29sdXRpb24gd2lsbCBtaWdyYXRlIHRv IHRoZSByZWFsIHNvbHV0aW9uIGF0IHNvbWUgcG9pbnQgYW5kIHRoYXQgaW50ZW50IGhhcyBi ZWVuIGV4cHJlc3NlZCBpbiB0aGUgbWVldGluZyBzZXZlcmFsIHRpbWVzLiBCdXQgdGhhdCBt aWdyYXRpb24gd2lsbCBub3QgaGFwcGVuIG92ZXJuaWdodCBhcyBzb29uIGFzIHRoZSBXRyBS RkNzIGFyZSBwdWJsaXNoZWQuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkZyb206IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhdWwgRS4g Sm9uZXMNClNlbnQ6IDAxIEF1Z3VzdCAyMDEzIDE2OjAwDQpUbzogJ0xhdXJhIExpZXNzJzsg aW5zaXBpZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJbnNpcGlkXSBQcm9wb3NlZCBJTlNJ UElEIHNvbHV0aW9uIGFuZCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQoNCkxhdXJhLA0KDQpJ IGFzc2VydCB0aGF0IG9sZCBkcmFmdCB3aWxsIG5vdCB3b3JrIGZvciBzb21lIOKAnHJlYWwt d29ybGTigJ0gY2FsbHMuICBDYWxscyBkbyBnZXQgbWFuaXB1bGF0ZWQgaW4gZW50ZXJwcmlz ZSBlbnZpcm9ubWVudHMgYW5kIGNhbGwgY2VudGVycyBmb3IgYmlsbGluZyBwdXJwb3Nlcywg cHJpdmFjeSByZWFzb25zLCBldGMuDQoNCkNvbnNpZGVyIGEgY29tbW9uIGNhc2U6IGlmIHlv dSBjYWxsIGludG8gYSBjYWxsIGNlbnRlciBhbmQgdGhlIGFnZW50IHB1dHMgeW91IG9uIGhv bGQgd2hpbGUgdGhleSB0cmFuc2ZlciB5b3UgdG8gYSBzcGVjaWFsaXN0ICh0cmFuc2ZlciBv dXQgb2YgY29uc3VsdGF0aW9uKSwgZm9yIGV4YW1wbGUsIHlvdXIgU0lQIFVBIGRvZXMgbm90 IHJlY2VpdmUgYSBSRUZFUiB0byBpbml0aWF0ZSBhIG5ldyBjYWxsIGRpcmVjdGx5IHRvIHRo ZSBzcGVjaWFsaXN0LiAgVGhpcyBpcyBoYW5kbGVkIGF0IHRoZSBjYWxsIGNlbnRlci4NCg0K U28gcmF0aGVyIHNwZWNpZmljYWxseSwgaG93IHdvdWxkIHRoaXMgYmUgaGFuZGxlZCAod2l0 aCB0aGUgb2xkIGRyYWZ0KT8NCg0KMSkgQWxpY2UgY2FsbHMgQm9iIChTZXNzaW9uLUlEOiBB KQ0KMikgQm9iIHB1dHMgQWxpY2Ugb24gaG9sZCBhbmQgY2FsbHMgQ2Fyb2wgKFNlc3Npb24t SUQ6IEIpDQozKSBCb2IgdHJhbnNmZXJzIHRoZSBjYWxsIGZyb20gQWxpY2UgdG8gQ2Fyb2wg dXNpbmcgYSBsb2NhbCB0cmFuc2ZlciBmdW5jdGlvbiBvbiB0aGUgUEJYIChTZXNzaW9uLUlE OiA/PykNCg0KVGhlIFBCWCBjb3VsZCBzZW5kIGRpZmZlcmVudCB2YWx1ZXMgdG8gQWxpY2Ug YW5kIENhcm9sLCBidXQgd2UgdG90YWxseSBsb3NlIHRoZSBlbmQtdG8tZW5kIGlkZW50aWZp Y2F0aW9uIG9mIHRoZSBjYWxsLg0KDQpBbGljZSBjb3VsZCBub3Qgc2VuZCDigJxB4oCdIHRv IENhcm9sLCBzaW5jZSBDYXJvbCBpcyBleHBlY3RpbmcgQi4gIExpa2V3aXNlLCBDYXJvbCBj YW5ub3Qgc2VuZCDigJxC4oCdIHRvIEFsaWNlLCBzaW5jZSBBbGljZSBpcyBleHBlY3Rpbmcg 4oCcQeKAnS4gIFdlbGwsIHRoZXkgY291bGQsIGFuZCBpdCB3b3VsZCBiZSBubyB3b3JzZSB0 aGFuIG91ciBjdXJyZW50IHByb3Bvc2FsIGluIHRlcm1zIG9mIGJhY2t3YXJkLWNvbXBhdGli aWxpdHkuDQoNClBhdWwNCg0KRnJvbTogaW5zaXBpZC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGF1cmEgTGllc3MN ClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDEsIDIwMTMgOToxMyBBTQ0KVG86IGluc2lwaWRA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gUHJvcG9zZWQgSU5TSVBJRCBzb2x1 dGlvbiBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0KDQoNCkhhZHJpZWwncyBwcm9wb3Nh bCB3b3JrcyBmb3IgdXMuDQoNClRoYW5rIHlvdQ0KTGF1cmENCg0KMjAxMy84LzEgSGFkcmll bCBLYXBsYW4gPGhhZHJpZWwua2FwbGFuQG9yYWNsZS5jb208bWFpbHRvOmhhZHJpZWwua2Fw bGFuQG9yYWNsZS5jb20+Pg0KDQpUaGlzIGlzbid0IGFib3V0IEVudGVycHJpc2UgdnMuIFNl cnZpY2UtUHJvdmlkZXIsIG9yIENpc2NvIHZzLiBhbm90aGVyIHZlbmRvci4gIFRoaXMgaXMg anVzdCBhYm91dCBhIFdvcmtpbmcgR3JvdXAgZG9jdW1lbnQsIGFuZCB3aGV0aGVyIHRoZSBt ZWNoYW5pc20gZGVmaW5lZCBpbiBpdCBzaG91bGQgY2hhbmdlIHRoZSBTZXNzaW9uLUlEIGhl YWRlciB2YWx1ZSB2cy4gcGFyYW1ldGVyIGJhc2VkIG9uIGRpcmVjdGlvbiBvZiBtZXNzYWdl cywgb3Igbm90LiAgSSB0b3RhbGx5IGdldCB0aGUgbmVlZCB0byBoYXZlIGEgZGlzdGluZ3Vp c2hpbmcgU2Vzc2lvbi1JRCBpZGVudGlmaWVyIGZvciBwYXJ0eS1BIHZzLiBwYXJ0eS1CLiAg V2hhdCBJIGRvbid0IGdldCBpcyB3aHkgdGhleSBuZWVkIHRvIGNoYW5nZSB0aGUgZW5jb2Rp bmcgb2YgdGhlIFNlc3Npb24tSUQgaGVhZGVyIHZhbHVlIHZzLiBwYXJhbWV0ZXIsIG9uIGEg bWVzc2FnZSBkaXJlY3Rpb24gYmFzaXMuDQoNCkluIG90aGVyIHdvcmRzLCB0b2RheSB0aGUg ZHJhZnQgaGFzIHRoaXM6DQoxKSBBbGljZSBzZW5kcyBJTlZJVEUgd2l0aCAgICAgIlNlc3Np b24tSUQ6IGZvbyINCjIpIEJvYiAgIHNlbmRzIDE4eC8yMDAgd2l0aCAgICAiU2Vzc2lvbi1J RDogYmFyO3JlbW90ZT1mb28iDQozKSBBbGljZSBzZW5kcyBBQ0sgd2l0aCAgICAgICAgIlNl c3Npb24tSUQ6IGZvbztyZW1vdGU9YmFyIg0KNCkgQm9iICAgc2VuZHMgQllFIHdpdGggICAg ICAgICJTZXNzaW9uLUlEOiBiYXI7cmVtb3RlPWZvbyINCjUpIEFsaWNlIHNlbmRzIDIwMCB3 aXRoICAgICAgICAiU2Vzc2lvbi1JRDogZm9vO3JlbW90ZT1iYXIiDQoNCkJ1dCB3ZSBjb3Vs ZCBpbnN0ZWFkIGRvIHRoaXM6DQoxKSBBbGljZSBzZW5kcyBJTlZJVEUgd2l0aCAgICAgIlNl c3Npb24tSUQ6IGZvbyINCjIpIEJvYiAgIHNlbmRzIDE4eC8yMDAgd2l0aCAgICAiU2Vzc2lv bi1JRDogZm9vO3JlbW90ZT1iYXIiDQozKSBBbGljZSBzZW5kcyBBQ0sgd2l0aCAgICAgICAg IlNlc3Npb24tSUQ6IGZvbztyZW1vdGU9YmFyIg0KNCkgQm9iICAgc2VuZHMgQllFIHdpdGgg ICAgICAgICJTZXNzaW9uLUlEOiBmb287cmVtb3RlPWJhciINCjUpIEFsaWNlIHNlbmRzIDIw MCB3aXRoICAgICAgICAiU2Vzc2lvbi1JRDogZm9vO3JlbW90ZT1iYXIiDQoNClRoaXMgc2Vj b25kIG1vZGVsIGtlZXBzIHRoZSBTZXNzaW9uLUlEIGhlYWRlciB2YWx1ZSBhcyAiZm9vIiB0 aGUgd2hvbGUgdGltZSwgd2hpbGUgYWRkaW5nIGEgcGFyYW1ldGVyIG9mICJiYXIiIGZvciBC b2IgdGhhdCByZW1haW5zIGEgcGFyYW1ldGVyIHRoZSB3aG9sZSB0aW1lLg0KTmVpdGhlciBB bGljZSBub3IgQm9iIGFyZSBjb25mdXNlZCBhYm91dCB3aGljaCBvbmUgaXMgInRoZWlyIiBV VUlEIHZhbHVlLg0KQW5kIGl0J3MgYmFja3dhcmQtY29tcGF0aWJsZSB3aXRoIHRoZSBwcmV2 aW91cyBrYXBsYW4tZHJhZnQuDQpBbmQgaXQncyBhcmd1YWJseSBlYXNpZXIgdG8gaW1wbGVt ZW50LCBmb3IgdGhlIGNvbW1vbiBjYXNlcy4NCg0KSSAqdGhpbmsqIHRoZXJlIHdhcyBhIHJl YXNvbiBzb21lb25lIGNhbWUgdXAgd2l0aCBhdCBvbmUgdGltZSBhcyB0byB3aHkgaXQgaGFk IHRvIGJlIHN3YXBwZWQsIGJ1dCBJIGRvbid0IHJlbWVtYmVyIHdoYXQgaXQgaXMgYW5kIEkg ZG9uJ3Qgc2VlIGl0IGluIHRoZSBkcmFmdC4gIFNvIEknbSB0cnlpbmcgdG8gZmluZCBvdXQg d2h5IHdlIG5lZWQgdG8gZG8gaXQgdGhlIHdheSB0aGUgZHJhZnQgY3VycmVudGx5IGhhcyBp dC4NCg0KVGhlIG90aGVyIHRvcGljIG9mIHdoZXRoZXIgU0JDcyB3aWxsIGNoYW5nZSB0aGlu Z3MgaXMgY29tcGxldGVseSBvcnRob2dvbmFsIHRvIHRoZSBvcmRlcmluZyBvciBiYWNrd2Fy ZHMgY29tcGF0aWJpbGl0eSBpc3N1ZXMsIGFuZCByZWFsbHkgc2hvdWxkbid0IGJlIGNvbmZs YXRlZCB3aXRoIGl0IGF0IGFsbC4gIEl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHNv bHV0aW9ucyBkb2N1bWVudCwgb3IgdGhlIGRpcmVjdGlvbiBzdHVmZiwgZXRjLg0KDQotaGFk cmllbA0KDQoNCk9uIEF1ZyAxLCAyMDEzLCBhdCAxMjozOCBBTSwgUGF1bCBFLiBKb25lcyA8 cGF1bGVqQHBhY2tldGl6ZXIuY29tPG1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20+PiB3 cm90ZToNCg0KPiBGb2xrcywNCj4NCj4gSSBzdGVwIGF3YXkgZm9yIGEgY291cGxlIG9mIGRh eXMgYW5kIHRoZSBmbG9vZGdhdGUgb3BlbnMuIDopDQo+DQo+IEkgdGhpbmsgaXQncyBpbXBv cnRhbnQgdG8gdW5kZXJzdGFuZCB3aHkgd2UgcHJvcG9zZWQgdXNpbmcgYSB0d28tcGFydA0K PiBTZXNzaW9uIElkZW50aWZpZXIuICBUaGUgcmVhc29uIGlzIHRoYXQgd2UgaGF2ZSB0byBi ZSBhYmxlIHRvIGVmZmVjdGl2ZWx5DQo+IGRlYWwgd2l0aCB0aGluZ3MgbGlrZSBmb3JraW5n LCBjYWxsIHRyYW5zZmVyLCBwYXJrLCBicmlkZ2luZywgY29uZmVyZW5jaW5nLA0KPiBldGMu DQo+DQo+IFdoZW4gaW5pdGlhdGluZyBhIGNhbGwgYW5kIHVzaW5nIGEgc2luZ2xlIFVVSUQg dmFsdWUsIHRoYXQgaGFzIHRoZSBwb3RlbnRpYWwNCj4gdG8gZ28gZW5kLXRvLWVuZC4gSG93 ZXZlciwgaWYgYSBjYWxsIGlzIGZvcmtlZCB0aGVyZSBhcmUgbXVsdGlwbGUgImVuZHMiLg0K PiBIb3cgZG8gd2UgdHJhY2sgZWFjaCBvZiB0aG9zZT8gIEZvciBwcm9wZXIgZGlhZ25vc3Rp Y3MgYW5kIHRyb3VibGVzaG9vdGluZywNCj4gaXQgd291bGQgYmUgaWRlYWwgdG8gYmUgYWJs ZSB0byBpZGVudGlmeSB3aGljaCBkZXZpY2VzIGhhdmUgYW4gaXNzdWUuDQo+DQo+IE9uY2Ug YSBjYWxsIGhhcyBiZWVuIHBsYWNlZCwgdGhlcmUgaXMgYSBTZXNzaW9uLUlEIGVzdGFibGlz aGVkIGJldHdlZW4gQWxpY2UNCj4gYW5kIEJvYi4gIElmIEFsaWNlIChpbiBvbmUgY291bnRy eSkgdHJhbnNmZXJzIEJvYiAocGVyaGFwcyBpbiB0aGUgc2FtZSBvcg0KPiBkaWZmZXJlbnQg Y291bnRyeSkgdG8gYSBzb21lIGxvY2F0aW9uIGluIGEgaGlnaC10b2xsIGNvdW50cnksIHdo byBwYXlzIHRoZQ0KPiBiaWxsPyAgV2VsbCwgdG8gYWRkcmVzcyB0aGF0LCB3ZSBkbyBjYWxs IHRyYW5zZmVyIGxvY2FsbHkgb24gUEJYZXMuICBUaGUgUEJYDQo+IG1haW50YWlucyBjb250 cm9sIG92ZXIgdGhlIGNhbGwgYW5kIEFsaWNlIHdvdWxkIHBheSB0aGUgYmlsbCBmb3IgdGhl IGNhbGwNCj4gdHJhbnNmZXIuICBCdXQgaWYgQWxpY2Ugd2FzIHRhbGtpbmcgdG8gQ2Fyb2wg YmVmb3JlIHRoZSB0cmFuc2ZlciwgdGhlcmUgaXMgYQ0KPiBTZXNzaW9uLUlEIGZvciB0aGF0 IGNhbGwuICBJZiBCb2IgaXMgcHV0IGluIGNvbW11bmljYXRpb24gd2l0aCBDYXJvbCwgd2hh dA0KPiBpcyB0aGUgU2Vzc2lvbi1JRCB2YWx1ZT8gIEJvYiBoYWQgb25lIGFuZCBDYXJvbCBo YWQgYSBkaWZmZXJlbnQgb25lLiAgV2hhdA0KPiBpcyB0aGUgbmV3IElEPw0KPg0KPiBJdCdz IGlzc3VlcyBsaWtlIHRoaXMgdGhhdCBsZWQgdXMgdG8gdXNpbmcgYSB0d28tcGFydCB2YWx1 ZS4gIEluIHRoaXMgd2F5LA0KPiB3ZSBjb3VsZCBzZWUgdGhlIGNhbGwgZnJvbSBBbGljZSB0 byBCb2IgaGFzIGEgU2Vzc2lvbi1JRCB7QSxCfS4gIElmIEFsaWNlDQo+IHRyYW5zZmVycyB0 aGUgY2FsbCB0byBDYXJvbCwgZWFjaCBkZXZpY2UgdW5kZXJzdGFuZHMgdGhhdCB0aGUgU2Vz c2lvbi1JRA0KPiBjaGFuZ2VkIHRvIHtCLEN9LiAgTm90IG9ubHkgdGhhdCwgYnV0IGludGVy bWVkaWFyaWVzIGFsb25nIHRoZSBwYXRoIHRoYXQNCj4gd2VyZSBub3QgcHJpdnkgdG8gc2ln bmFsaW5nIHRoYXQgcmVzdWx0ZWQgaW4gdGhpcyBjaGFuZ2UgY2FuIHRha2Ugbm90ZSBvZg0K PiB0aGUgZmFjdCB0aGUgdmFsdWUgY2hhbmdlZC4gIFRoaXMgY2FuIHByb3ZpZGUgYSB1c2Vm dWwgaGlzdG9yaWNhbCByZWNvcmQsDQo+IHNpbmNlIHByZXZpb3VzbHkgdGhleSBtaWdodCBz ZWUgYSBjYWxsIHRvIENhcm9sIGlkZW50aWZpZWQgYXMge0EsQ30sIGJ1dA0KPiB0aGVuIGl0 IGNoYW5nZWQgdG8ge0IsQ30uDQo+DQo+IFRoaXMgcHJvcGVydHkgZXh0ZW5kcyBxdWl0ZSBu YXR1cmFsbHkgdG8gb3RoZXIgc2lnbmFsaW5nIHNjZW5hcmlvcywgYXMgaXQNCj4gYWxsb3dz IG9uZSB0byBpZGVudGlmeSBhIGNhbGwgZW5kLXRvLWVuZCwgYnV0IGFsc28gZXN0YWJsaXNo IHNvbWUNCj4gcmVsYXRpb25zaGlwIGJldHdlZW4gb3RoZXIgY2FsbHMgdGhhdCBzaGFyZWQg YXQgbGVhc3Qgb25lIFVVSUQgdmFsdWUgb3V0IG9mDQo+IHRoZSB0d28uDQo+DQo+IEhhZHJp ZWwgbWVudGlvbmVkIHRoZSBkZXNpcmUgdG8gdXNlIHRoZSBTZXNzaW9uLUlEIHRvIGNvcnJl bGF0ZSBtZWRpYSBmbG93cw0KPiBhbmQgY2FsbHMuICBUaGF0J3MgY2VydGFpbmx5IHNvbWV0 aGluZyBDaXNjbyB3b3VsZCBsaWtlIHRvIGRvLCBidXQgaXQgaXMgbm90DQo+IHRoZSBkcml2 ZXIgYmVoaW5kIHRoZSBzb2x1dGlvbi4gIEhhdmluZyBhIHZhbGlkIGVuZC10by1lbmQgaWRl bnRpZmllciAoaW4NCj4gd2hhdGV2ZXIgZm9ybSkgYWxsb3dzIHVzIHRvIGRvIHRoYXQuICBX ZSdyZSBub3Qgc3VnZ2VzdGluZyB0byBmaXQgdGhlDQo+IHNvbHV0aW9uIHRvIG1lZXQgdGhh dCBidXNpbmVzcyB1c2UgY2FzZSwgYnV0IHJhdGhlciB3ZSBqdXN0IHdhbnQgYSBzb2x1dGlv bg0KPiB0aGF0IGFsbG93cyB1cyB0byBwcm9wZXJseSBpZGVudGlmeSBjYWxscyBlbmQtdG8t ZW5kIGFuZCB3ZSByZWNvZ25pemUgdGhhdCwNCj4gZHVlIHRvIHZhcmlvdXMgc2VydmljZSBp bnRlcmFjdGlvbnMgaW4gdGhlIG5ldHdvcmssIHRoZXNlIFVVSUQgdmFsdWVzIGNhbg0KPiBj aGFuZ2UuDQo+DQo+IEkgd291bGQgaG9wZSB0aGF0IFVVSUQgdmFsdWVzIHdpbGwgbm90IGNo YW5nZSB0byB0aGUgZXh0ZW50IHRoYXQgU0JDcyBjaGFuZ2UNCj4gdGhlbSBmb3IgYnVzaW5l c3MgcmVhc29ucy4gIEl0IHdvdWxkIGNlcnRhaW5seSBkZWZlYXQgdGhlIHBvaW50LiAgSGFk cmllbA0KPiBtaWdodCBiZSByaWdodCB0aGF0IGFuIFNCQyB2ZW5kb3IgbWlnaHQgbWFuaXB1 bGF0ZSB0aG9zZSB2YWx1ZXMgYXQgdGhlDQo+IHJlcXVlc3Qgb2YgYSBjdXN0b21lciwgYnV0 IEkgd291bGQgaG9wZSBzYWlkIGN1c3RvbWVyIGFwcHJlY2lhdGVzIHRoYXQgc3VjaA0KPiBh IHJlcXVlc3QgZWZmZWN0aXZlbHkgYnJlYWtzIHRoZSBlbmQtdG8tZW5kIG1vZGVsLiAgV2Ug Y2FuJ3QgZG8gbXVjaCBhYm91dA0KPiB0aGF0IGlmIHRoZXkgZG8gZ28gZG93biB0aGF0IHBh dGguDQo+DQo+IEFzIGZvciBiYWNrd2FyZC1jb21wYXRpYmlsaXR5LCB0aGUgc2ltcGxlc3Qg YXBwcm9hY2ggKElNTykgaXMgdG8ganVzdCB1c2UgYQ0KPiBoZWFkZXIgdmFsdWUgbm90IGFs cmVhZHkgaW4gdXNlLiAgT3JpZ2luYWxseSwgd2UgaGFkIHByb3Bvc2VkIFNlc3Npb24tVVVJ RC4NCj4gVGhhdCB3YXMgY2hhbmdlZCBhdCB0aGUgcmVxdWVzdCBvZiB0aGUgZ3JvdXAgdG8g YmUgU2Vzc2lvbi1JRC4gIEhvd2V2ZXIsDQo+IHdoZW4gd2UgaGF2ZSBhIHR3byBVVUlEIHNv bHV0aW9uIGludGVyYWN0aW5nIHdpdGggYSBvbmUtVVVJRCBzb2x1dGlvbiwgd2UNCj4gaW1t ZWRpYXRlbHkgZmFjZSBzb21lIGNoYWxsZW5nZXMuDQo+DQo+IFdoYXQgaGFwcGVucyBpZiBh biBvbGRlciBzeXN0ZW0gc2VuZHMgdGhpczoNCj4gIFNlc3Npb24tSUQ6IFgNCj4gQnV0IHRo ZW4gcmVjZWl2ZXMgdGhpczoNCj4gIFNlc3Npb24tSUQ6IFk7IHJlbW90ZT1YDQo+DQo+IERv ZXMgdGhpcyBicmVhayB0aGluZ3M/ICBJZiBzbywgaG93IGRvIGN1cnJlbnQgaW1wbGVtZW50 YXRpb25zIGRlYWwgd2l0aA0KPiBzdWNoIHRoaW5ncyBhcyBtaWQtY2FsbCB0cmFuc2ZlcnMg dGhhdCBoYXBwZW4gb24gYSBQQlggbGlrZSB0aGUgb25lIEkNCj4gZGVzY3JpYmVkIGFib3Zl Pw0KPg0KPiBXZSBjb3VsZCBzd2l0Y2ggdGhlIG9yZGVyIGxpa2UgdGhpczoNCj4gIFNlc3Np b24tSUQ6IFg7IHJlbW90ZT1ZDQo+DQo+IEhvd2V2ZXIsIHRoYXQgZG9lcyBub3Qgd29yayBm b3Igc2ltaWxhciByZWFzb25zLiAgSWYgd2UgaGF2ZSBhIGNhbGwgdHJhbnNmZXINCj4gd2hl cmUgQWxpY2UgdHJhbnNmZXJzIGEgY2FsbCB3aXRoIEJvYiB0byBDYXJvbCwgdGhlbiBlYWNo IGhhcyBhIGRpZmZlcmVudA0KPiBpZGVhIGFib3V0IHdoYXQgdGhlIHByb3BlciB2YWx1ZSBp cyBmb3IgdGhlIGZpcnN0IHBvc2l0aW9uLg0KPg0KPiBPcmlnaW5hbGx5LCB0aGUgcHJvcG9z ZWQgc29sdXRpb24gZGlkIG5vdCBpbmRpY2F0ZSBwb3NpdGlvbiBpbmZvcm1hdGlvbiBhbmQN Cj4ganVzdCBoYWQgc2luZ2xlIFVVSUQgdmFsdWVzIGdvaW5nIGluIGVhY2ggZGlyZWN0aW9u LiAgV2UgdGhlbiBwcm9wb3NlZCBhDQo+IGNvbmNhdGVuYXRlZCBzdHJpbmcgKFg6WSkuIEhv d2V2ZXIsIHRoYXQgcHJlc2VudGVkIHRoZSBzYW1lIGlzc3VlcyBmb3IgdGhlDQo+IGNhbGwg dHJhbnNmZXIgY2FzZSwgc28gd2UgaW5kaWNhdGUgdmFsdWVzIGJ5IHBvc2l0aW9uIChzZW5k ZXIncyB2YWx1ZQ0KPiBmaXJzdCksIHNvIGl0IGlzIGNsZWFyIHdoYXQgdmFsdWUgdGhlIHJl Y2VpdmUgdGhpbmtzIHRoZSByZW1vdGUgZW5kIGhhcyBmb3INCj4gdGhlIGxvY2FsIGVuZC4g IEl0IG1pZ2h0IGJlIHdyb25nLCBidXQgdGhhdCB3aWxsIGJlIGNvcnJlY3RlZCBpbiB0aGUN Cj4gZm9sbG93aW5nIHJlc3BvbnNlLiAoSW50ZXJtZWRpYXJpZXMgY2FuIHRha2Ugbm90ZSBv ZiB0aGUgY2hhbmdlLikNCj4NCj4gU28sIHRoYXQncyB3aHkgd2UgYXJlIHdoZXJlIHdlIGFy ZS4gIFRoZXJlIGhhcyBiZWVuIGFuIGVmZm9ydCB0byBtYWludGFpbg0KPiBiYWNrd2FyZC1j b21wYXRpYmlsaXR5LCBidXQgdGhlcmUgYXJlIGNoYWxsZW5nZXMgaW4gbWVldGluZyB0aGF0 DQo+IHJlcXVpcmVtZW50LiAgV2hlcmUgaXQgZmFsbHMgc2hvcnQsIHdlIGRvIG5vdCBrbm93 OiB3ZSd2ZSBub3QgYmVlbiB0b2xkDQo+IGV4cGxpY2l0bHkgd2hhdCB0aGUgaXNzdWVzIGFy ZS4gIEZ1cnRoZXIsIGlmIHRoZXJlIGFyZSBzdWNoIGlzc3Vlcywgd2UgbmVlZA0KPiB0byBh bHNvIHVuZGVyc3RhbmQgaG93IHRob3NlIHdvdWxkIGJlIGhhbmRsZWQgaW4gdGhlIGZhY2Ug b2YgY2FsbCB0cmFuc2Zlcg0KPiBvciAiam9pbmluZyIgYSBjYWxsIGxvY2FsbHkgb24gYSBQ QlguICBUaG9zZSBhcmUgcmVhbC13b3JsZCBzY2VuYXJpb3MgdGhhdA0KPiB3ZSBtdXN0IGFk ZHJlc3MuDQo+DQo+IEFueXdheSwgbm90aGluZyBpcyBzZXQgaW4gc3RvbmUuICBBbnl0aGlu ZyBjYW4gYmUgY2hhbmdlZCwgYnV0IEkgd291bGQgaG9wZQ0KPiB3ZSBjYW4gZmluZCBhIHNv bHV0aW9uIHRoYXQgd29ya3MgZm9yIHRoZSBlbnRlcnByaXNlIHVzZSBjYXNlcyBhcyB3ZWxs IGFzDQo+IHRoZSBzZXJ2aWNlIHByb3ZpZGVyIG5ldHdvcmtzLg0KPg0KPiBQYXVsDQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGluc2lwaWQgbWFpbGluZyBsaXN0DQo+IGluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lw aWRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aW5zaXBpZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KaW5zaXBpZCBtYWlsaW5nIGxpc3QNCmluc2lwaWRAaWV0Zi5vcmc8bWFpbHRvOmlu c2lwaWRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2luc2lwaWQNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGlu Y2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv cm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3Rl Y3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZp bGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ug b2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJh bnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNl LCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlz IHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338DF08AFXMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpuczA9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1 aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4N CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZp bHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVo YXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxvOlNt YXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncyIgbmFtZT0iQ2l0eSIgLz48bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNl dXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIG5hbWU9 InBsYWNlIiAvPjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0idGltZSIgLz48bzpTbWFydFRh Z1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpz bWFydHRhZ3MiIG5hbWU9InN0b2NrdGlja2VyIiAvPjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3Bh Y2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFt ZT0iZGF0ZSIgLz48IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48c3R5bGU+DQo8 IS0tYTpsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTt9DQpzcGFuLk1TT0hZUEVSTElO Sw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7fQ0KYTp2aXNpdGVkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTt9DQpzcGFuLk1TT0hZUEVSTElOS0ZPTExPV0VEDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTt9DQpwLk1TT0xJU1RQQVJBR1JBUEgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0O30NCmxpLk1TT0xJU1RQQVJBR1JBUEgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0O30N CmRpdi5NU09MSVNUUEFSQUdSQVBIDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDt9DQoNCiAv KiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMg TWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1p bmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbGlzdHBhcmFncmFw aCwgbGkubXNvbGlzdHBhcmFncmFwaCwgZGl2Lm1zb2xpc3RwYXJhZ3JhcGgNCgl7bWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5h dnk7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGZvbnQgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NClB1dHRpbmcgaXQgYW5vdGhlciB3 YXk6PGJyPg0KPGJyPg0KVGhpbmdzIHRoYXQgd29yayB3aXRoIHRoZSBrYXBsYW4gZHJhZnQg c2hvdWxkIGNvbnRpbnVlIHRvIHdvcmsgd2hlbiBhIGthcGxhbiBjb21wbGlhbnQgaW1wbGVt ZW50YXRpb24gaW50ZXJ3b3JrcyB3aXRoIHRoZSBXRyBzb2x1dGlvbiBjb21wbGlhbnQgaW1w bGVtZW50YXRpb25zLg0KPGJyPg0KPGJyPg0KVGhpbmdzIHRoYXQgZG9uJ3Qgd29yayB3aXRo IHRoZSBrYXBsYW4gZHJhZnQgYXJlIG5vdCBleHBlY3RlZCB0byB3b3JrIHdoZW4gYSBrYXBs YW4gY29tcGxpYW50IGltcGxlbWVudGF0aW9uIGludGVyd29ya3Mgd2l0aCB0aGUgV0cgc29s dXRpb24gY29tcGxpYW50IGltcGxlbWVudGF0aW9ucyBob3dldmVyIHRoZSBkZWdyYWRlZCBi ZWhhdmlvciBzaG91bGQgYmUgbm8gd29yc2UgdGhhbiBiZXR3ZWVuIGthcGxhbiBjb21wbGlh bnQgaW1wbGVtZW50YXRpb25zLjxicj4NCjxicj4NCkFuZHJldzwvZm9udD48YnI+DQombmJz cDs8YnI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8Zm9udCBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGI+RnJvbTwvYj46IERSQUdFLCBLZWl0aCAoS2VpdGgpIFttYWls dG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tXQ0KPGJyPg0KPGI+U2VudDwvYj46 IEZyaWRheSwgQXVndXN0IDAyLCAyMDEzIDAyOjQzIEFNIENlbnRyYWwgU3RhbmRhcmQgVGlt ZTxicj4NCjxiPlRvPC9iPjogUGF1bCBFLiBKb25lcyAmbHQ7cGF1bGVqQHBhY2tldGl6ZXIu Y29tJmd0OzsgJ0xhdXJhIExpZXNzJyAmbHQ7bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5j b20mZ3Q7OyBpbnNpcGlkQGlldGYub3JnICZsdDtpbnNpcGlkQGlldGYub3JnJmd0Ow0KPGJy Pg0KPGI+U3ViamVjdDwvYj46IFJlOiBbSW5zaXBpZF0gUHJvcG9zZWQgSU5TSVBJRCBzb2x1 dGlvbiBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0KPGJyPg0KPC9mb250PiZuYnNwOzxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPkxl dCB1cyBnZXQgdGhpcyBjbGVhci48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9IkFy aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJp YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eSI+VGhlIEthcGxhbiBkcmFmdCBpcyBub3QgZXhwZWN0ZWQgdG8gbWVldCBh bGwgdGhlIHJlcXVpcmVtZW50cy4gSWYgaXQgZGlkLCB3ZSB3b3VsZCBwcm9iYWJseSBiZSBw cm9ncmVzc2luZyBpdCBhcyB0aGUgc29sdXRpb24gZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+V2hhdCB0aGUgcHJldmlvdXMgZGVj aXNpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgZWZmZWN0aXZlbHkgcmVxdWlyZWQsIHdoZW4g aXQgZGVzaXJlZCBjb21wYXRpYmlsaXR5LCB3YXMgdGhhdCBzZW5zaWJsZSB0aGluZ3Mgc2hv dWxkDQogaGFwcGVuIGFzIGZhciBhcyBwb3NzaWJsZSB3aGVuIHRoZSB0d28gc29sdXRpb25z IGludGVyb3BlcmF0ZWQuIFRoZXJlIGlzIGFsc28gbm8gaW1wbGljYXRpb24gdGhhdCB3aGVu IEthcGxhbiBkcmFmdCBtZWV0cyBXRyBzb2x1dGlvbiB0aGF0IGFsbCB0aGUgcmVxdWlyZW1l bnRzIGFyZSBtZXQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpu YXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5h dnkiPlRoZSBkZXNpcmUgZm9yIGNvbXBhdGliaWxpdHkgaXMgYmFzZWQgb24gdGhlIGZhY3Qg dGhhdCB0aGUgcHJldmlvdXMgc29sdXRpb24gaXMgb3V0IHRoZXJlIGluIHRoZSBmaWVsZC4g T25lIHNvbHV0aW9uIHdpbGwgbWVldCB0aGUgb3RoZXIuDQogT25lIHNvbHV0aW9uIHNob3Vs ZCBub3QgYm9tYiB0aGUgb3RoZXIgb25lIG91dC4gSW1wbGVtZW50b3JzIG9mIHRoZSBLYXBs YW4gc29sdXRpb24gd2lsbCBtaWdyYXRlIHRvIHRoZSByZWFsIHNvbHV0aW9uIGF0IHNvbWUg cG9pbnQgYW5kIHRoYXQgaW50ZW50IGhhcyBiZWVuIGV4cHJlc3NlZCBpbiB0aGUgbWVldGlu ZyBzZXZlcmFsIHRpbWVzLiBCdXQgdGhhdCBtaWdyYXRpb24gd2lsbCBub3QgaGFwcGVuIG92 ZXJuaWdodCBhcyBzb29uIGFzIHRoZQ0KIFdHIFJGQ3MgYXJlIHB1Ymxpc2hlZC48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+UmVnYXJkczxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij5LZWl0aDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXIiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4NCjxociBzaXplPSIyIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciIgdGFiaW5kZXg9Ii0xIj4NCjwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNl PSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTo8L3NwYW4+PC9mb250 PjwvYj48Zm9udCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPiBpbnNpcGlkLWJv dW5jZXNAaWV0Zi5vcmcNCiBbbWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZ10gPGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBPZg0KPC9zcGFuPjwv Yj5QYXVsIEUuIEpvbmVzPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PlNlbnQ6PC9zcGFuPjwvYj4gMDEgQXVndXN0IDIwMTMgMTY6MDA8YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gJ0xhdXJhIExpZXNzJzsg aW5zaXBpZEBpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJlOiBbSW5zaXBpZF0gUHJvcG9zZWQgSU5TSVBJRCBz b2x1dGlvbiBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eTwvc3Bhbj48L2ZvbnQ+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOg0KMTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkxhdXJh LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5JIGFzc2VydCB0aGF0IG9sZCBk cmFmdCB3aWxsIG5vdCB3b3JrIGZvciBzb21lIOKAnHJlYWwtd29ybGTigJ0gY2FsbHMuJm5i c3A7IENhbGxzIGRvIGdldCBtYW5pcHVsYXRlZCBpbiBlbnRlcnByaXNlIGVudmlyb25tZW50 cw0KIGFuZCBjYWxsIGNlbnRlcnMgZm9yIGJpbGxpbmcgcHVycG9zZXMsIHByaXZhY3kgcmVh c29ucywgZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0 OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5Db25zaWRlciBh IGNvbW1vbiBjYXNlOiBpZiB5b3UgY2FsbCBpbnRvIGEgY2FsbCBjZW50ZXIgYW5kIHRoZSBh Z2VudCBwdXRzIHlvdSBvbiBob2xkIHdoaWxlIHRoZXkgdHJhbnNmZXIgeW91IHRvDQogYSBz cGVjaWFsaXN0ICh0cmFuc2ZlciBvdXQgb2YgY29uc3VsdGF0aW9uKSwgZm9yIGV4YW1wbGUs IHlvdXIgU0lQIFVBIGRvZXMgPGk+PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6aXRhbGljIj5u b3Q8L3NwYW4+PC9pPiByZWNlaXZlIGEgUkVGRVIgdG8gaW5pdGlhdGUgYSBuZXcgY2FsbCBk aXJlY3RseSB0byB0aGUgc3BlY2lhbGlzdC4mbmJzcDsgVGhpcyBpcyBoYW5kbGVkIGF0IHRo ZSBjYWxsIGNlbnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+U28gcmF0 aGVyIHNwZWNpZmljYWxseSwgaG93IHdvdWxkIHRoaXMgYmUgaGFuZGxlZCAod2l0aCB0aGUg b2xkIGRyYWZ0KT88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmki PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+MSkNCjxzdDE6 Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpwbGFjZT48 L3N0MTpDaXR5PiBjYWxscyBCb2IgKFNlc3Npb24tSUQ6IEEpPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4yKSBC b2IgcHV0cw0KPHN0MTpDaXR5IHc6c3Q9Im9uIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj5BbGlj ZTwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+IG9uIGhvbGQgYW5kIGNhbGxzIENhcm9sIChTZXNz aW9uLUlEOiBCKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+MykgQm9iIHRyYW5zZmVycyB0aGUgY2FsbCBmcm9t DQo8c3QxOkNpdHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6 cGxhY2U+PC9zdDE6Q2l0eT4gdG8gQ2Fyb2wgdXNpbmcgYSBsb2NhbCB0cmFuc2ZlciBmdW5j dGlvbiBvbiB0aGUgUEJYIChTZXNzaW9uLUlEOiA/Pyk8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCI+VGhlIFBCWCBjb3VsZCBzZW5kIGRpZmZlcmVudCB2YWx1ZXMgdG8gQWxp Y2UgYW5kIENhcm9sLCBidXQgd2UgdG90YWxseSBsb3NlIHRoZSBlbmQtdG8tZW5kIGlkZW50 aWZpY2F0aW9uIG9mIHRoZQ0KIGNhbGwuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0MTpDaXR5IHc6 c3Q9Im9uIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ow0KICBmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkFsaWNl PC9zcGFuPjwvZm9udD48L3N0MTpwbGFjZT48L3N0MTpDaXR5Pjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0Qi Pg0KIGNvdWxkIG5vdCBzZW5kIOKAnEHigJ0gdG8gQ2Fyb2wsIHNpbmNlIENhcm9sIGlzIGV4 cGVjdGluZyBCLiZuYnNwOyBMaWtld2lzZSwgQ2Fyb2wgY2Fubm90IHNlbmQg4oCcQuKAnSB0 bw0KPHN0MTpDaXR5IHc6c3Q9Im9uIj5BbGljZTwvc3QxOkNpdHk+LCBzaW5jZSA8c3QxOkNp dHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+PC9z dDE6Q2l0eT4gaXMgZXhwZWN0aW5nIOKAnEHigJ0uJm5ic3A7IFdlbGwsIHRoZXkgY291bGQs IGFuZCBpdCB3b3VsZCBiZSBubyB3b3JzZSB0aGFuIG91ciBjdXJyZW50IHByb3Bvc2FsIGlu IHRlcm1zIG9mIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIj MWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO2Nv bG9yOiMxRjQ5N0QiPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250 IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkIj5Gcm9t Ojwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9t YSI+IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZw0KIFttYWlsdG86aW5zaXBpZC1ib3VuY2Vz QGlldGYub3JnXSA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxm IE9mDQo8L3NwYW4+PC9iPkxhdXJhIExpZXNzPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gVGh1cnNkYXksIDxzdDE6ZGF0ZSBZZWFy PSIyMDEzIiBEYXk9IjAxIiBNb250aD0iOCIgbHM9InRyYW5zIiB3OnN0PSJvbiI+DQpBdWd1 c3QgMDEsIDIwMTM8L3N0MTpkYXRlPiA8c3QxOnRpbWUgTWludXRlPSIxMyIgSG91cj0iOSIg dzpzdD0ib24iPjk6MTMgQU08L3N0MTp0aW1lPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiBpbnNpcGlkQGlldGYub3JnPGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6 IFtJbnNpcGlkXSBQcm9wb3NlZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBiYWNrd2FyZCBjb21w YXRpYmlsaXR5PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PGJyPg0KSGFkcmllbCdzIHBy b3Bvc2FsIHdvcmtzIGZvciB1cy4gPGJyPg0KPGJyPg0KVGhhbmsgeW91PGZvbnQgY29sb3I9 IiM4ODg4ODgiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQpMYXVyYTwvc3Bh bj48L2ZvbnQ+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+MjAxMy84LzEgSGFkcmllbCBLYXBsYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpo YWRyaWVsLmthcGxhbkBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aGFkcmllbC5rYXBs YW5Ab3JhY2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQpU aGlzIGlzbid0IGFib3V0IDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJv biI+RW50ZXJwcmlzZTwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+IHZzLiBTZXJ2aWNlLVByb3Zp ZGVyLCBvciBDaXNjbyB2cy4gYW5vdGhlciB2ZW5kb3IuICZuYnNwO1RoaXMgaXMganVzdCBh Ym91dCBhIFdvcmtpbmcgR3JvdXAgZG9jdW1lbnQsIGFuZCB3aGV0aGVyIHRoZSBtZWNoYW5p c20gZGVmaW5lZCBpbiBpdCBzaG91bGQgY2hhbmdlIHRoZSBTZXNzaW9uLUlEDQogaGVhZGVy IHZhbHVlIHZzLiBwYXJhbWV0ZXIgYmFzZWQgb24gZGlyZWN0aW9uIG9mIG1lc3NhZ2VzLCBv ciBub3QuICZuYnNwO0kgdG90YWxseSBnZXQgdGhlIG5lZWQgdG8gaGF2ZSBhIGRpc3Rpbmd1 aXNoaW5nIFNlc3Npb24tSUQgaWRlbnRpZmllciBmb3IgcGFydHktQSB2cy4gcGFydHktQi4g Jm5ic3A7V2hhdCBJIGRvbid0IGdldCBpcyB3aHkgdGhleSBuZWVkIHRvIGNoYW5nZSB0aGUg ZW5jb2Rpbmcgb2YgdGhlIFNlc3Npb24tSUQgaGVhZGVyIHZhbHVlIHZzLg0KIHBhcmFtZXRl ciwgb24gYSBtZXNzYWdlIGRpcmVjdGlvbiBiYXNpcy48YnI+DQo8YnI+DQpJbiBvdGhlciB3 b3JkcywgdG9kYXkgdGhlIGRyYWZ0IGhhcyB0aGlzOjxicj4NCjEpIDxzdDE6Q2l0eSB3OnN0 PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpwbGFjZT48L3N0MTpDaXR5 PiBzZW5kcyBJTlZJVEUgd2l0aCAmbmJzcDsgJm5ic3A7ICZxdW90O1Nlc3Npb24tSUQ6IGZv byZxdW90Ozxicj4NCjIpIEJvYiAmbmJzcDsgc2VuZHMgMTh4LzIwMCB3aXRoICZuYnNwOyAm bmJzcDsmcXVvdDtTZXNzaW9uLUlEOiBiYXI7cmVtb3RlPWZvbyZxdW90Ozxicj4NCjMpIDxz dDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpwbGFj ZT48L3N0MTpDaXR5PiBzZW5kcyBBQ0sgd2l0aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmcXVvdDtTZXNzaW9uLUlEOiBmb287cmVtb3RlPWJhciZxdW90Ozxicj4NCjQpIEJvYiAm bmJzcDsgc2VuZHMgQllFIHdpdGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 U2Vzc2lvbi1JRDogYmFyO3JlbW90ZT1mb28mcXVvdDs8YnI+DQo1KSA8c3QxOkNpdHkgdzpz dD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+PC9zdDE6Q2l0 eT4gc2VuZHMgMjAwIHdpdGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7U2Vz c2lvbi1JRDogZm9vO3JlbW90ZT1iYXImcXVvdDs8YnI+DQo8YnI+DQpCdXQgd2UgY291bGQg aW5zdGVhZCBkbyB0aGlzOjxicj4NCjEpIDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFj ZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpwbGFjZT48L3N0MTpDaXR5PiBzZW5kcyBJTlZJVEUg d2l0aCAmbmJzcDsgJm5ic3A7ICZxdW90O1Nlc3Npb24tSUQ6IGZvbyZxdW90Ozxicj4NCjIp IEJvYiAmbmJzcDsgc2VuZHMgMTh4LzIwMCB3aXRoICZuYnNwOyAmbmJzcDsmcXVvdDtTZXNz aW9uLUlEOiBmb287cmVtb3RlPWJhciZxdW90Ozxicj4NCjMpIDxzdDE6Q2l0eSB3OnN0PSJv biI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpwbGFjZT48L3N0MTpDaXR5PiBz ZW5kcyBBQ0sgd2l0aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtTZXNzaW9u LUlEOiBmb287cmVtb3RlPWJhciZxdW90Ozxicj4NCjQpIEJvYiAmbmJzcDsgc2VuZHMgQllF IHdpdGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7U2Vzc2lvbi1JRDogZm9v O3JlbW90ZT1iYXImcXVvdDs8YnI+DQo1KSA8c3QxOkNpdHkgdzpzdD0ib24iPjxzdDE6cGxh Y2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT4gc2VuZHMgMjAwIHdp dGggJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7U2Vzc2lvbi1JRDogZm9vO3Jl bW90ZT1iYXImcXVvdDs8YnI+DQo8YnI+DQpUaGlzIHNlY29uZCBtb2RlbCBrZWVwcyB0aGUg U2Vzc2lvbi1JRCBoZWFkZXIgdmFsdWUgYXMgJnF1b3Q7Zm9vJnF1b3Q7IHRoZSB3aG9sZSB0 aW1lLCB3aGlsZSBhZGRpbmcgYSBwYXJhbWV0ZXIgb2YgJnF1b3Q7YmFyJnF1b3Q7IGZvciBC b2IgdGhhdCByZW1haW5zIGEgcGFyYW1ldGVyIHRoZSB3aG9sZSB0aW1lLjxicj4NCk5laXRo ZXIgQWxpY2Ugbm9yIEJvYiBhcmUgY29uZnVzZWQgYWJvdXQgd2hpY2ggb25lIGlzICZxdW90 O3RoZWlyJnF1b3Q7IFVVSUQgdmFsdWUuPGJyPg0KQW5kIGl0J3MgYmFja3dhcmQtY29tcGF0 aWJsZSB3aXRoIHRoZSBwcmV2aW91cyBrYXBsYW4tZHJhZnQuPGJyPg0KQW5kIGl0J3MgYXJn dWFibHkgZWFzaWVyIHRvIGltcGxlbWVudCwgZm9yIHRoZSBjb21tb24gY2FzZXMuPGJyPg0K PGJyPg0KSSAqdGhpbmsqIHRoZXJlIHdhcyBhIHJlYXNvbiBzb21lb25lIGNhbWUgdXAgd2l0 aCBhdCBvbmUgdGltZSBhcyB0byB3aHkgaXQgaGFkIHRvIGJlIHN3YXBwZWQsIGJ1dCBJIGRv bid0IHJlbWVtYmVyIHdoYXQgaXQgaXMgYW5kIEkgZG9uJ3Qgc2VlIGl0IGluIHRoZSBkcmFm dC4gJm5ic3A7U28gSSdtIHRyeWluZyB0byBmaW5kIG91dCB3aHkgd2UgbmVlZCB0byBkbyBp dCB0aGUgd2F5IHRoZSBkcmFmdCBjdXJyZW50bHkgaGFzIGl0Ljxicj4NCjxicj4NClRoZSBv dGhlciB0b3BpYyBvZiB3aGV0aGVyIFNCQ3Mgd2lsbCBjaGFuZ2UgdGhpbmdzIGlzIGNvbXBs ZXRlbHkgb3J0aG9nb25hbCB0byB0aGUgb3JkZXJpbmcgb3IgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkgaXNzdWVzLCBhbmQgcmVhbGx5IHNob3VsZG4ndCBiZSBjb25mbGF0ZWQgd2l0aCBp dCBhdCBhbGwuICZuYnNwO0l0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHNvbHV0aW9u cyBkb2N1bWVudCwgb3IgdGhlIGRpcmVjdGlvbiBzdHVmZiwgZXRjLjxicj4NCjxmb250IGNv bG9yPSIjODg4ODg4Ij48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KLWhhZHJp ZWw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48YnI+DQo8YnI+DQpPbiBBdWcgMSwgMjAxMywgYXQgMTI6MzggQU0sIFBhdWwgRS4gSm9u ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb20iIHRhcmdldD0i X2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+ DQomZ3Q7IEZvbGtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgc3RlcCBhd2F5IGZvciBhIGNv dXBsZSBvZiBkYXlzIGFuZCB0aGUgZmxvb2RnYXRlIG9wZW5zLiA6KTxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgdGhpbmsgaXQncyBpbXBvcnRhbnQgdG8gdW5kZXJzdGFuZCB3aHkgd2UgcHJv cG9zZWQgdXNpbmcgYSB0d28tcGFydDxicj4NCiZndDsgU2Vzc2lvbiBJZGVudGlmaWVyLiAm bmJzcDtUaGUgcmVhc29uIGlzIHRoYXQgd2UgaGF2ZSB0byBiZSBhYmxlIHRvIGVmZmVjdGl2 ZWx5PGJyPg0KJmd0OyBkZWFsIHdpdGggdGhpbmdzIGxpa2UgZm9ya2luZywgY2FsbCB0cmFu c2ZlciwgcGFyaywgYnJpZGdpbmcsIGNvbmZlcmVuY2luZyw8YnI+DQomZ3Q7IGV0Yy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBXaGVuIGluaXRpYXRpbmcgYSBjYWxsIGFuZCB1c2luZyBhIHNp bmdsZSBVVUlEIHZhbHVlLCB0aGF0IGhhcyB0aGUgcG90ZW50aWFsPGJyPg0KJmd0OyB0byBn byBlbmQtdG8tZW5kLiBIb3dldmVyLCBpZiBhIGNhbGwgaXMgZm9ya2VkIHRoZXJlIGFyZSBt dWx0aXBsZSAmcXVvdDtlbmRzJnF1b3Q7Ljxicj4NCiZndDsgSG93IGRvIHdlIHRyYWNrIGVh Y2ggb2YgdGhvc2U/ICZuYnNwO0ZvciBwcm9wZXIgZGlhZ25vc3RpY3MgYW5kIHRyb3VibGVz aG9vdGluZyw8YnI+DQomZ3Q7IGl0IHdvdWxkIGJlIGlkZWFsIHRvIGJlIGFibGUgdG8gaWRl bnRpZnkgd2hpY2ggZGV2aWNlcyBoYXZlIGFuIGlzc3VlLjxicj4NCiZndDs8YnI+DQomZ3Q7 IE9uY2UgYSBjYWxsIGhhcyBiZWVuIHBsYWNlZCwgdGhlcmUgaXMgYSBTZXNzaW9uLUlEIGVz dGFibGlzaGVkIGJldHdlZW4gPHN0MTpDaXR5IHc6c3Q9Im9uIj4NCjxzdDE6cGxhY2Ugdzpz dD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+PC9zdDE6Q2l0eT48YnI+DQomZ3Q7IGFuZCBCb2Iu ICZuYnNwO0lmIDxzdDE6Q2l0eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+QWxp Y2U8L3N0MTpwbGFjZT48L3N0MTpDaXR5PiAoaW4gb25lIGNvdW50cnkpIHRyYW5zZmVycyBC b2IgKHBlcmhhcHMgaW4gdGhlIHNhbWUgb3I8YnI+DQomZ3Q7IGRpZmZlcmVudCBjb3VudHJ5 KSB0byBhIHNvbWUgbG9jYXRpb24gaW4gYSBoaWdoLXRvbGwgY291bnRyeSwgd2hvIHBheXMg dGhlPGJyPg0KJmd0OyBiaWxsPyAmbmJzcDtXZWxsLCB0byBhZGRyZXNzIHRoYXQsIHdlIGRv IGNhbGwgdHJhbnNmZXIgbG9jYWxseSBvbiBQQlhlcy4gJm5ic3A7VGhlIFBCWDxicj4NCiZn dDsgbWFpbnRhaW5zIGNvbnRyb2wgb3ZlciB0aGUgY2FsbCBhbmQgPHN0MTpDaXR5IHc6c3Q9 Im9uIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj5BbGljZTwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+ IHdvdWxkIHBheSB0aGUgYmlsbCBmb3IgdGhlIGNhbGw8YnI+DQomZ3Q7IHRyYW5zZmVyLiAm bmJzcDtCdXQgaWYgPHN0MTpDaXR5IHc6c3Q9Im9uIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj5B bGljZTwvc3QxOnBsYWNlPjwvc3QxOkNpdHk+IHdhcyB0YWxraW5nIHRvIENhcm9sIGJlZm9y ZSB0aGUgdHJhbnNmZXIsIHRoZXJlIGlzIGE8YnI+DQomZ3Q7IFNlc3Npb24tSUQgZm9yIHRo YXQgY2FsbC4gJm5ic3A7SWYgQm9iIGlzIHB1dCBpbiBjb21tdW5pY2F0aW9uIHdpdGggQ2Fy b2wsIHdoYXQ8YnI+DQomZ3Q7IGlzIHRoZSBTZXNzaW9uLUlEIHZhbHVlPyAmbmJzcDtCb2Ig aGFkIG9uZSBhbmQgQ2Fyb2wgaGFkIGEgZGlmZmVyZW50IG9uZS4gJm5ic3A7V2hhdDxicj4N CiZndDsgaXMgdGhlIG5ldyBJRD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCdzIGlzc3VlcyBs aWtlIHRoaXMgdGhhdCBsZWQgdXMgdG8gdXNpbmcgYSB0d28tcGFydCB2YWx1ZS4gJm5ic3A7 SW4gdGhpcyB3YXksPGJyPg0KJmd0OyB3ZSBjb3VsZCBzZWUgdGhlIGNhbGwgZnJvbSA8c3Qx OkNpdHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+ PC9zdDE6Q2l0eT4gdG8gQm9iIGhhcyBhIFNlc3Npb24tSUQge0EsQn0uICZuYnNwO0lmDQo8 c3QxOkNpdHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxh Y2U+PC9zdDE6Q2l0eT48YnI+DQomZ3Q7IHRyYW5zZmVycyB0aGUgY2FsbCB0byBDYXJvbCwg ZWFjaCBkZXZpY2UgdW5kZXJzdGFuZHMgdGhhdCB0aGUgU2Vzc2lvbi1JRDxicj4NCiZndDsg Y2hhbmdlZCB0byB7QixDfS4gJm5ic3A7Tm90IG9ubHkgdGhhdCwgYnV0IGludGVybWVkaWFy aWVzIGFsb25nIHRoZSBwYXRoIHRoYXQ8YnI+DQomZ3Q7IHdlcmUgbm90IHByaXZ5IHRvIHNp Z25hbGluZyB0aGF0IHJlc3VsdGVkIGluIHRoaXMgY2hhbmdlIGNhbiB0YWtlIG5vdGUgb2Y8 YnI+DQomZ3Q7IHRoZSBmYWN0IHRoZSB2YWx1ZSBjaGFuZ2VkLiAmbmJzcDtUaGlzIGNhbiBw cm92aWRlIGEgdXNlZnVsIGhpc3RvcmljYWwgcmVjb3JkLDxicj4NCiZndDsgc2luY2UgcHJl dmlvdXNseSB0aGV5IG1pZ2h0IHNlZSBhIGNhbGwgdG8gQ2Fyb2wgaWRlbnRpZmllZCBhcyB7 QSxDfSwgYnV0PGJyPg0KJmd0OyB0aGVuIGl0IGNoYW5nZWQgdG8ge0IsQ30uPGJyPg0KJmd0 Ozxicj4NCiZndDsgVGhpcyBwcm9wZXJ0eSBleHRlbmRzIHF1aXRlIG5hdHVyYWxseSB0byBv dGhlciBzaWduYWxpbmcgc2NlbmFyaW9zLCBhcyBpdDxicj4NCiZndDsgYWxsb3dzIG9uZSB0 byBpZGVudGlmeSBhIGNhbGwgZW5kLXRvLWVuZCwgYnV0IGFsc28gZXN0YWJsaXNoIHNvbWU8 YnI+DQomZ3Q7IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIG90aGVyIGNhbGxzIHRoYXQgc2hhcmVk IGF0IGxlYXN0IG9uZSBVVUlEIHZhbHVlIG91dCBvZjxicj4NCiZndDsgdGhlIHR3by48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBIYWRyaWVsIG1lbnRpb25lZCB0aGUgZGVzaXJlIHRvIHVzZSB0 aGUgU2Vzc2lvbi1JRCB0byBjb3JyZWxhdGUgbWVkaWEgZmxvd3M8YnI+DQomZ3Q7IGFuZCBj YWxscy4gJm5ic3A7VGhhdCdzIGNlcnRhaW5seSBzb21ldGhpbmcgQ2lzY28gd291bGQgbGlr ZSB0byBkbywgYnV0IGl0IGlzIG5vdDxicj4NCiZndDsgdGhlIGRyaXZlciBiZWhpbmQgdGhl IHNvbHV0aW9uLiAmbmJzcDtIYXZpbmcgYSB2YWxpZCBlbmQtdG8tZW5kIGlkZW50aWZpZXIg KGluPGJyPg0KJmd0OyB3aGF0ZXZlciBmb3JtKSBhbGxvd3MgdXMgdG8gZG8gdGhhdC4gJm5i c3A7V2UncmUgbm90IHN1Z2dlc3RpbmcgdG8gZml0IHRoZTxicj4NCiZndDsgc29sdXRpb24g dG8gbWVldCB0aGF0IGJ1c2luZXNzIHVzZSBjYXNlLCBidXQgcmF0aGVyIHdlIGp1c3Qgd2Fu dCBhIHNvbHV0aW9uPGJyPg0KJmd0OyB0aGF0IGFsbG93cyB1cyB0byBwcm9wZXJseSBpZGVu dGlmeSBjYWxscyBlbmQtdG8tZW5kIGFuZCB3ZSByZWNvZ25pemUgdGhhdCw8YnI+DQomZ3Q7 IGR1ZSB0byB2YXJpb3VzIHNlcnZpY2UgaW50ZXJhY3Rpb25zIGluIHRoZSBuZXR3b3JrLCB0 aGVzZSBVVUlEIHZhbHVlcyBjYW48YnI+DQomZ3Q7IGNoYW5nZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIHdvdWxkIGhvcGUgdGhhdCBVVUlEIHZhbHVlcyB3aWxsIG5vdCBjaGFuZ2UgdG8g dGhlIGV4dGVudCB0aGF0IFNCQ3MgY2hhbmdlPGJyPg0KJmd0OyB0aGVtIGZvciBidXNpbmVz cyByZWFzb25zLiAmbmJzcDtJdCB3b3VsZCBjZXJ0YWlubHkgZGVmZWF0IHRoZSBwb2ludC4g Jm5ic3A7SGFkcmllbDxicj4NCiZndDsgbWlnaHQgYmUgcmlnaHQgdGhhdCBhbiA8c3QxOnN0 b2NrdGlja2VyIHc6c3Q9Im9uIj5TQkM8L3N0MTpzdG9ja3RpY2tlcj4gdmVuZG9yIG1pZ2h0 IG1hbmlwdWxhdGUgdGhvc2UgdmFsdWVzIGF0IHRoZTxicj4NCiZndDsgcmVxdWVzdCBvZiBh IGN1c3RvbWVyLCBidXQgSSB3b3VsZCBob3BlIHNhaWQgY3VzdG9tZXIgYXBwcmVjaWF0ZXMg dGhhdCBzdWNoPGJyPg0KJmd0OyBhIHJlcXVlc3QgZWZmZWN0aXZlbHkgYnJlYWtzIHRoZSBl bmQtdG8tZW5kIG1vZGVsLiAmbmJzcDtXZSBjYW4ndCBkbyBtdWNoIGFib3V0PGJyPg0KJmd0 OyB0aGF0IGlmIHRoZXkgZG8gZ28gZG93biB0aGF0IHBhdGguPGJyPg0KJmd0Ozxicj4NCiZn dDsgQXMgZm9yIGJhY2t3YXJkLWNvbXBhdGliaWxpdHksIHRoZSBzaW1wbGVzdCBhcHByb2Fj aCAoPHN0MTpzdG9ja3RpY2tlciB3OnN0PSJvbiI+SU1PPC9zdDE6c3RvY2t0aWNrZXI+KSBp cyB0byBqdXN0IHVzZSBhPGJyPg0KJmd0OyBoZWFkZXIgdmFsdWUgbm90IGFscmVhZHkgaW4g dXNlLiAmbmJzcDtPcmlnaW5hbGx5LCB3ZSBoYWQgcHJvcG9zZWQgU2Vzc2lvbi1VVUlELjxi cj4NCiZndDsgVGhhdCB3YXMgY2hhbmdlZCBhdCB0aGUgcmVxdWVzdCBvZiB0aGUgZ3JvdXAg dG8gYmUgU2Vzc2lvbi1JRC4gJm5ic3A7SG93ZXZlciw8YnI+DQomZ3Q7IHdoZW4gd2UgaGF2 ZSBhIHR3byBVVUlEIHNvbHV0aW9uIGludGVyYWN0aW5nIHdpdGggYSBvbmUtVVVJRCBzb2x1 dGlvbiwgd2U8YnI+DQomZ3Q7IGltbWVkaWF0ZWx5IGZhY2Ugc29tZSBjaGFsbGVuZ2VzLjxi cj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgaGFwcGVucyBpZiBhbiBvbGRlciBzeXN0ZW0gc2Vu ZHMgdGhpczo8YnI+DQomZ3Q7ICZuYnNwO1Nlc3Npb24tSUQ6IFg8YnI+DQomZ3Q7IEJ1dCB0 aGVuIHJlY2VpdmVzIHRoaXM6PGJyPg0KJmd0OyAmbmJzcDtTZXNzaW9uLUlEOiBZOyByZW1v dGU9WDxicj4NCiZndDs8YnI+DQomZ3Q7IERvZXMgdGhpcyBicmVhayB0aGluZ3M/ICZuYnNw O0lmIHNvLCBob3cgZG8gY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgZGVhbCB3aXRoPGJyPg0K Jmd0OyBzdWNoIHRoaW5ncyBhcyBtaWQtY2FsbCB0cmFuc2ZlcnMgdGhhdCBoYXBwZW4gb24g YSBQQlggbGlrZSB0aGUgb25lIEk8YnI+DQomZ3Q7IGRlc2NyaWJlZCBhYm92ZT88YnI+DQom Z3Q7PGJyPg0KJmd0OyBXZSBjb3VsZCBzd2l0Y2ggdGhlIG9yZGVyIGxpa2UgdGhpczo8YnI+ DQomZ3Q7ICZuYnNwO1Nlc3Npb24tSUQ6IFg7IHJlbW90ZT1ZPGJyPg0KJmd0Ozxicj4NCiZn dDsgSG93ZXZlciwgdGhhdCBkb2VzIG5vdCB3b3JrIGZvciBzaW1pbGFyIHJlYXNvbnMuICZu YnNwO0lmIHdlIGhhdmUgYSBjYWxsIHRyYW5zZmVyPGJyPg0KJmd0OyB3aGVyZSA8c3QxOkNp dHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgdzpzdD0ib24iPkFsaWNlPC9zdDE6cGxhY2U+PC9z dDE6Q2l0eT4gdHJhbnNmZXJzIGEgY2FsbCB3aXRoIEJvYiB0byBDYXJvbCwgdGhlbiBlYWNo IGhhcyBhIGRpZmZlcmVudDxicj4NCiZndDsgaWRlYSBhYm91dCB3aGF0IHRoZSBwcm9wZXIg dmFsdWUgaXMgZm9yIHRoZSBmaXJzdCBwb3NpdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBP cmlnaW5hbGx5LCB0aGUgcHJvcG9zZWQgc29sdXRpb24gZGlkIG5vdCBpbmRpY2F0ZSBwb3Np dGlvbiBpbmZvcm1hdGlvbiBhbmQ8YnI+DQomZ3Q7IGp1c3QgaGFkIHNpbmdsZSBVVUlEIHZh bHVlcyBnb2luZyBpbiBlYWNoIGRpcmVjdGlvbi4gJm5ic3A7V2UgdGhlbiBwcm9wb3NlZCBh PGJyPg0KJmd0OyBjb25jYXRlbmF0ZWQgc3RyaW5nIChYOlkpLiBIb3dldmVyLCB0aGF0IHBy ZXNlbnRlZCB0aGUgc2FtZSBpc3N1ZXMgZm9yIHRoZTxicj4NCiZndDsgY2FsbCB0cmFuc2Zl ciBjYXNlLCBzbyB3ZSBpbmRpY2F0ZSB2YWx1ZXMgYnkgcG9zaXRpb24gKHNlbmRlcidzIHZh bHVlPGJyPg0KJmd0OyBmaXJzdCksIHNvIGl0IGlzIGNsZWFyIHdoYXQgdmFsdWUgdGhlIHJl Y2VpdmUgdGhpbmtzIHRoZSByZW1vdGUgZW5kIGhhcyBmb3I8YnI+DQomZ3Q7IHRoZSBsb2Nh bCBlbmQuICZuYnNwO0l0IG1pZ2h0IGJlIHdyb25nLCBidXQgdGhhdCB3aWxsIGJlIGNvcnJl Y3RlZCBpbiB0aGU8YnI+DQomZ3Q7IGZvbGxvd2luZyByZXNwb25zZS4gKEludGVybWVkaWFy aWVzIGNhbiB0YWtlIG5vdGUgb2YgdGhlIGNoYW5nZS4pPGJyPg0KJmd0Ozxicj4NCiZndDsg U28sIHRoYXQncyB3aHkgd2UgYXJlIHdoZXJlIHdlIGFyZS4gJm5ic3A7VGhlcmUgaGFzIGJl ZW4gYW4gZWZmb3J0IHRvIG1haW50YWluPGJyPg0KJmd0OyBiYWNrd2FyZC1jb21wYXRpYmls aXR5LCBidXQgdGhlcmUgYXJlIGNoYWxsZW5nZXMgaW4gbWVldGluZyB0aGF0PGJyPg0KJmd0 OyByZXF1aXJlbWVudC4gJm5ic3A7V2hlcmUgaXQgZmFsbHMgc2hvcnQsIHdlIGRvIG5vdCBr bm93OiB3ZSd2ZSBub3QgYmVlbiB0b2xkPGJyPg0KJmd0OyBleHBsaWNpdGx5IHdoYXQgdGhl IGlzc3VlcyBhcmUuICZuYnNwO0Z1cnRoZXIsIGlmIHRoZXJlIGFyZSBzdWNoIGlzc3Vlcywg d2UgbmVlZDxicj4NCiZndDsgdG8gYWxzbyB1bmRlcnN0YW5kIGhvdyB0aG9zZSB3b3VsZCBi ZSBoYW5kbGVkIGluIHRoZSBmYWNlIG9mIGNhbGwgdHJhbnNmZXI8YnI+DQomZ3Q7IG9yICZx dW90O2pvaW5pbmcmcXVvdDsgYSBjYWxsIGxvY2FsbHkgb24gYSBQQlguICZuYnNwO1Rob3Nl IGFyZSByZWFsLXdvcmxkIHNjZW5hcmlvcyB0aGF0PGJyPg0KJmd0OyB3ZSBtdXN0IGFkZHJl c3MuPGJyPg0KJmd0Ozxicj4NCiZndDsgQW55d2F5LCBub3RoaW5nIGlzIHNldCBpbiBzdG9u ZS4gJm5ic3A7QW55dGhpbmcgY2FuIGJlIGNoYW5nZWQsIGJ1dCBJIHdvdWxkIGhvcGU8YnI+ DQomZ3Q7IHdlIGNhbiBmaW5kIGEgc29sdXRpb24gdGhhdCB3b3JrcyBmb3IgdGhlIGVudGVy cHJpc2UgdXNlIGNhc2VzIGFzIHdlbGwgYXM8YnI+DQomZ3Q7IHRoZSBzZXJ2aWNlIHByb3Zp ZGVyIG5ldHdvcmtzLjxicj4NCiZndDs8YnI+DQomZ3Q7IFBhdWw8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IGluc2lwaWQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBo cmVmPSJtYWlsdG86aW5zaXBpZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmluc2lwaWRA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQppbnNpcGlk IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppbnNpcGlkQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8L2E+ PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBi eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338DF08AFXMB104ADSrimnet_-- From laura.liess.dt@googlemail.com Fri Aug 2 01:47:00 2013 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 C9F5C11E81E4 for ; Fri, 2 Aug 2013 01:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHZ2b0tzOrT3 for ; Fri, 2 Aug 2013 01:46:59 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C89D411E82CC for ; Fri, 2 Aug 2013 01:46:55 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id o7so264557lbv.17 for ; Fri, 02 Aug 2013 01:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/w3voBZEChD5+S1jMtW2l8bJGu1emdGSXMvj6S21rHg=; b=SUqMigGMkySxOaRVN1ch5ouxBifUZUtLslHfonHOH2kzjN70CKPOKNz0TyavEiF2gf YsDD7wFkiOkNcTOt1q/nzkMMyzdIDrQQ2j/pjlMtK0gYp5mDGyW4wMm1fVkOVmU5njk9 ovO3I6VlEKTdaKSJeQ0aWwNmTUG+E/hRwIqMvpZ/D1FNq28iegP+piA5IymbnkFMf1ii w55ziOv2bY3T28KVK/eqZb9loJHjPEUQQ9MkXRO119vsKmU1EoLyNlEirDENxLO81yQK +6zL2SuuWZ6EOBMkKe2Ksnj04TbSNELRFJvCSsuDop5B+UpeEtgQwuwJPo5Lvfi7apvD H08A== MIME-Version: 1.0 X-Received: by 10.152.5.197 with SMTP id u5mr2480691lau.59.1375433213303; Fri, 02 Aug 2013 01:46:53 -0700 (PDT) Received: by 10.114.75.144 with HTTP; Fri, 2 Aug 2013 01:46:53 -0700 (PDT) In-Reply-To: <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> Date: Fri, 2 Aug 2013 10:46:53 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=089e013d100217609f04e2f30079 Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:47:01 -0000 --089e013d100217609f04e2f30079 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, As I said, we never used the old Session-ID to do more than correlate bothe legs of the same dialog. So in your example we have: - Alice to Bob: Session-ID A - Bob to Carol: Session-ID B - Alice to Carol: Session-ID C There is no correlation between them. We just correlate both legs of the same dialog across the SBC between Alice and Bob. Thank you Laura 2013/8/1 Paul E. Jones > Laura, > > The example I show below is a real call center example. I show use of the > old session ID. Tell me how that works. Forget about the new solution for > the moment. > > If you say it will not work, then I'm not sure how we can make something > work with something that does not work. If there is a way to make this > work, then we can try to figure out how to interwork with it. > > Paul > > > ------------------------------ > *From:* Laura Liess > *Sent:* Thu Aug 01 11:51:26 EDT 2013 > > *To:* "Paul E. Jones" > *Cc:* insipid@ietf.org > > *Subject:* Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > Paul, > We use the old Session-ID only accross SBCs, to correlate both legs of th= e > same dialog. And it works fine for this use case. We never tried, intend > or were required to do more with it. > We are not against the new mechanism, we just want it to interwork with > the old one which we have in thousands of customer end devices. If it doe= s, > we can add new end devices and application servers which support the new > Session-ID. Otherwise we can't. > > Let's see if it works when we keep the UUID order unchanged, as Hadriel > proposed. > > Thank you > Laura > > > 2013/8/1 Paul E. Jones > >> Laura,**** >> >> ** ** >> >> I assert that old draft will not work for some =93real-world=94 calls. = Calls >> do get manipulated in enterprise environments and call centers for billi= ng >> purposes, privacy reasons, etc.**** >> >> ** ** >> >> Consider a common case: if you call into a call center and the agent put= s >> you on hold while they transfer you to a specialist (transfer out of >> consultation), for example, your SIP UA does *not* receive a REFER to >> initiate a new call directly to the specialist. This is handled at the >> call center.**** >> >> ** ** >> >> So rather specifically, how would this be handled (with the old draft)?*= * >> ** >> >> ** ** >> >> 1) Alice calls Bob (Session-ID: A)**** >> >> 2) Bob puts Alice on hold and calls Carol (Session-ID: B)**** >> >> 3) Bob transfers the call from Alice to Carol using a local transfer >> function on the PBX (Session-ID: ??)**** >> >> ** ** >> >> The PBX could send different values to Alice and Carol, but we totally >> lose the end-to-end identification of the call.**** >> >> ** ** >> >> Alice could not send =93A=94 to Carol, since Carol is expecting B. Like= wise, >> Carol cannot send =93B=94 to Alice, since Alice is expecting =93A=94. W= ell, they >> could, and it would be no worse than our current proposal in terms of >> backward-compatibility.**** >> >> ** ** >> >> Paul**** >> >> ** ** >> >> *From:* insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On >> Behalf Of *Laura Liess >> *Sent:* Thursday, August 01, 2013 9:13 AM >> *To:* insipid@ietf.org >> >> *Subject:* Re: [Insipid] Proposed INSIPID solution and backward >> compatibility**** >> >> ** ** >> >> >> Hadriel's proposal works for us. >> >> Thank you >> Laura**** >> >> ** ** >> >> 2013/8/1 Hadriel Kaplan **** >> >> >> This isn't about Enterprise vs. Service-Provider, or Cisco vs. another >> vendor. This is just about a Working Group document, and whether the >> mechanism defined in it should change the Session-ID header value vs. >> parameter based on direction of messages, or not. I totally get the nee= d >> to have a distinguishing Session-ID identifier for party-A vs. party-B. >> What I don't get is why they need to change the encoding of the Session= -ID >> header value vs. parameter, on a message direction basis. >> >> In other words, today the draft has this: >> 1) Alice sends INVITE with "Session-ID: foo" >> 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" >> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >> 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" >> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >> >> But we could instead do this: >> 1) Alice sends INVITE with "Session-ID: foo" >> 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" >> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >> 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" >> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >> >> This second model keeps the Session-ID header value as "foo" the whole >> time, while adding a parameter of "bar" for Bob that remains a parameter >> the whole time. >> Neither Alice nor Bob are confused about which one is "their" UUID value= . >> And it's backward-compatible with the previous kaplan-draft. >> And it's arguably easier to implement, for the common cases. >> >> I *think* there was a reason someone came up with at one time as to why >> it had to be swapped, but I don't remember what it is and I don't see it= in >> the draft. So I'm trying to find out why we need to do it the way the >> draft currently has it. >> >> The other topic of whether SBCs will change things is completely >> orthogonal to the ordering or backwards compatibility issues, and really >> shouldn't be conflated with it at all. It has nothing to do with the >> solutions document, or the direction stuff, etc. >> >> -hadriel**** >> >> >> >> On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote= : >> >> > Folks, >> > >> > I step away for a couple of days and the floodgate opens. :) >> > >> > I think it's important to understand why we proposed using a two-part >> > Session Identifier. The reason is that we have to be able to >> effectively >> > deal with things like forking, call transfer, park, bridging, >> conferencing, >> > etc. >> > >> > When initiating a call and using a single UUID value, that has the >> potential >> > to go end-to-end. However, if a call is forked there are multiple >> "ends". >> > How do we track each of those? For proper diagnostics and >> troubleshooting, >> > it would be ideal to be able to identify which devices have an issue. >> > >> > Once a call has been placed, there is a Session-ID established between >> Alice >> > and Bob. If Alice (in one country) transfers Bob (perhaps in the same >> or >> > different country) to a some location in a high-toll country, who pays >> the >> > bill? Well, to address that, we do call transfer locally on PBXes. >> The PBX >> > maintains control over the call and Alice would pay the bill for the >> call >> > transfer. But if Alice was talking to Carol before the transfer, ther= e >> is a >> > Session-ID for that call. If Bob is put in communication with Carol, >> what >> > is the Session-ID value? Bob had one and Carol had a different one. >> What >> > is the new ID? >> > >> > It's issues like this that led us to using a two-part value. In this >> way, >> > we could see the call from Alice to Bob has a Session-ID {A,B}. If >> Alice >> > transfers the call to Carol, each device understands that the Session-= ID >> > changed to {B,C}. Not only that, but intermediaries along the path th= at >> > were not privy to signaling that resulted in this change can take note >> of >> > the fact the value changed. This can provide a useful historical >> record, >> > since previously they might see a call to Carol identified as {A,C}, b= ut >> > then it changed to {B,C}. >> > >> > This property extends quite naturally to other signaling scenarios, as >> it >> > allows one to identify a call end-to-end, but also establish some >> > relationship between other calls that shared at least one UUID value >> out of >> > the two. >> > >> > Hadriel mentioned the desire to use the Session-ID to correlate media >> flows >> > and calls. That's certainly something Cisco would like to do, but it >> is not >> > the driver behind the solution. Having a valid end-to-end identifier >> (in >> > whatever form) allows us to do that. We're not suggesting to fit the >> > solution to meet that business use case, but rather we just want a >> solution >> > that allows us to properly identify calls end-to-end and we recognize >> that, >> > due to various service interactions in the network, these UUID values >> can >> > change. >> > >> > I would hope that UUID values will not change to the extent that SBCs >> change >> > them for business reasons. It would certainly defeat the point. >> Hadriel >> > might be right that an SBC vendor might manipulate those values at the >> > request of a customer, but I would hope said customer appreciates that >> such >> > a request effectively breaks the end-to-end model. We can't do much >> about >> > that if they do go down that path. >> > >> > As for backward-compatibility, the simplest approach (IMO) is to just >> use a >> > header value not already in use. Originally, we had proposed >> Session-UUID. >> > That was changed at the request of the group to be Session-ID. Howeve= r, >> > when we have a two UUID solution interacting with a one-UUID solution, >> we >> > immediately face some challenges. >> > >> > What happens if an older system sends this: >> > Session-ID: X >> > But then receives this: >> > Session-ID: Y; remote=3DX >> > >> > Does this break things? If so, how do current implementations deal wi= th >> > such things as mid-call transfers that happen on a PBX like the one I >> > described above? >> > >> > We could switch the order like this: >> > Session-ID: X; remote=3DY >> > >> > However, that does not work for similar reasons. If we have a call >> transfer >> > where Alice transfers a call with Bob to Carol, then each has a >> different >> > idea about what the proper value is for the first position. >> > >> > Originally, the proposed solution did not indicate position informatio= n >> and >> > just had single UUID values going in each direction. We then proposed= a >> > concatenated string (X:Y). However, that presented the same issues for >> the >> > call transfer case, so we indicate values by position (sender's value >> > first), so it is clear what value the receive thinks the remote end ha= s >> for >> > the local end. It might be wrong, but that will be corrected in the >> > following response. (Intermediaries can take note of the change.) >> > >> > So, that's why we are where we are. There has been an effort to >> maintain >> > backward-compatibility, but there are challenges in meeting that >> > requirement. Where it falls short, we do not know: we've not been tol= d >> > explicitly what the issues are. Further, if there are such issues, we >> need >> > to also understand how those would be handled in the face of call >> transfer >> > or "joining" a call locally on a PBX. Those are real-world scenarios >> that >> > we must address. >> > >> > Anyway, nothing is set in stone. Anything can be changed, but I would >> hope >> > we can find a solution that works for the enterprise use cases as well >> as >> > the service provider networks. >> > >> > 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**** >> >> ** ** >> >> ** ** >> > > --089e013d100217609f04e2f30079 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul,

As I said, we never used the old Session-ID to do more than co= rrelate bothe legs of the same dialog.=A0 So in your example we have:
-= Alice to Bob: Session-ID A
- Bob to Carol: Session-ID B
- Alice to C= arol: Session-ID C

There is no correlation between them. We just correlate both legs of th= e same dialog=A0 across the SBC between Alice and Bob.=A0

Thank you=
Laura



2013/8/1 Paul E. Jones = <paulej@packetizer.com>

Laura,

The example I show below is a real call center example. I sh= ow use of the old session ID. Tell me how that works. Forget about the new = solution for the moment.

If you say it will not work, then I'm not sure how we ca= n make something work with something that does not work. If there is a way = to make this work, then we can try to figure out how to interwork with it.<= /p>

Paul



From: Laura Liess <laura.liess.dt@googlemail.com>
Sent: Thu Aug 01 11:51:26 EDT 2013

To: "Paul E. Jones" <paulej@packetizer.com>
Cc: insi= pid@ietf.org

Subject: Re: [Insipid] Proposed INSIPID solution and backward compat= ibility

Paul,
We use the old Session-ID only accross SBCs, to c= orrelate both legs of the same dialog. And it works fine for this use case.= We never tried, intend=A0 or were required to do more with it.
=A0We ar= e not against the new mechanism, we just want it to interwork with the old = one which we have in thousands of customer end devices. If it does, we can = add new end devices and application servers which support the new Session-I= D. Otherwise we can't.=A0

Let's see if it works when we keep the UUID order = unchanged, as Hadriel proposed.

Thank youLaura


2013/8/1 Paul E. Jones= <paulej@packetizer.com>

Laura,=

=A0<= /p>

I assert that old draf= t will not work for some =93real-world=94 calls.=A0 Calls do get manipulate= d in enterprise environments and call centers for billing purposes, privacy= reasons, etc.

=A0<= /p>

Consider a common case= : if you call into a call center and the agent puts you on hold while they = transfer you to a specialist (transfer out of consultation), for example, y= our SIP UA does not receive a REFER to initiate a new call directly = to the specialist.=A0 This is handled at the call center.

=A0<= /p>

So rather specifically= , how would this be handled (with the old draft)?

=A0<= /p>

1) Alice calls Bob (Se= ssion-ID: A)

2) Bob puts Alice on hold= and calls Carol (Session-ID: B)

3) Bob transfers the call from Alice to Carol us= ing a local transfer function on the PBX (Session-ID: ??)

=A0<= /p>

The PBX could send dif= ferent values to Alice and Carol, but we totally lose the end-to-end identi= fication of the call.

=A0<= /p>

Alice could not send = =93A=94 to Carol, since Carol is expecting B.=A0 Likewise, Carol cannot sen= d =93B=94 to Alice, since Alice is expecting =93A=94.=A0 Well, they could, = and it would be no worse than our current proposal in terms of backward-com= patibility.

=A0<= /p>

Paul

=A0<= /p>

From: insipid= -bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Li= ess
Sent: Thursday, August 01, 2013 9:13 AM
To: insipid@ietf.org


Subject: Re: [Insipid] Proposed INSIPID solution and backward c= ompatibility

=A0


Hadriel's proposal works for us.
=
Thank you
Laura

=A0

2013/8/1 Hadri= el Kaplan <hadriel.kaplan@oracle.com>


This isn't about Enterprise vs. Service-Prov= ider, or Cisco vs. another vendor. =A0This is just about a Working Group do= cument, and whether the mechanism defined in it should change the Session-I= D header value vs. parameter based on direction of messages, or not. =A0I t= otally get the need to have a distinguishing Session-ID identifier for part= y-A vs. party-B. =A0What I don't get is why they need to change the enc= oding of the Session-ID header value vs. parameter, on a message direction = basis.

In other words, today the draft has this:
1) Alice sends INVITE with= =A0 =A0 "Session-ID: foo"
2) Bob =A0 sends 18x/200 with =A0 = =A0"Session-ID: bar;remote=3Dfoo"
3) Alice sends ACK with =A0 = =A0 =A0 =A0"Session-ID: foo;remote=3Dbar"
4) Bob =A0 sends BYE with =A0 =A0 =A0 =A0"Session-ID: bar;remote=3Dfoo= "
5) Alice sends 200 with =A0 =A0 =A0 =A0"Session-ID: foo;remo= te=3Dbar"

But we could instead do this:
1) Alice sends INVIT= E with =A0 =A0 "Session-ID: foo"
2) Bob =A0 sends 18x/200 with =A0 =A0"Session-ID: foo;remote=3Dbar&quo= t;
3) Alice sends ACK with =A0 =A0 =A0 =A0"Session-ID: foo;remote= =3Dbar"
4) Bob =A0 sends BYE with =A0 =A0 =A0 =A0"Session-ID: = foo;remote=3Dbar"
5) Alice sends 200 with =A0 =A0 =A0 =A0"Sess= ion-ID: foo;remote=3Dbar"

This second model keeps the Session-ID header value as "foo" = the whole time, while adding a parameter of "bar" for Bob that re= mains a parameter the whole time.
Neither Alice nor Bob are confused abo= ut which one is "their" UUID value.
And it's backward-compatible with the previous kaplan-draft.
And it&= #39;s arguably easier to implement, for the common cases.

I *think* = there was a reason someone came up with at one time as to why it had to be = swapped, but I don't remember what it is and I don't see it in the = draft. =A0So I'm trying to find out why we need to do it the way the dr= aft currently has it.

The other topic of whether SBCs will change things is completely orthog= onal to the ordering or backwards compatibility issues, and really shouldn&= #39;t be conflated with it at all. =A0It has nothing to do with the solutio= ns document, or the direction stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones= <paulej@pack= etizer.com> wrote:

> Folks,
>
> I step away for a couple of days and the fl= oodgate opens. :)
>
> I think it's important to understand = why we proposed using a two-part
> Session Identifier. =A0The reason = is that we have to be able to effectively
> deal with things like forking, call transfer, park, bridging, conferen= cing,
> etc.
>
> When initiating a call and using a singl= e UUID value, that has the potential
> to go end-to-end. However, if = a call is forked there are multiple "ends".
> How do we track each of those? =A0For proper diagnostics and troublesh= ooting,
> it would be ideal to be able to identify which devices have= an issue.
>
> Once a call has been placed, there is a Session-= ID established between Alice
> and Bob. =A0If Alice (in one country) transfers Bob (perhaps in the sa= me or
> different country) to a some location in a high-toll country,= who pays the
> bill? =A0Well, to address that, we do call transfer l= ocally on PBXes. =A0The PBX
> maintains control over the call and Alice would pay the bill for the c= all
> transfer. =A0But if Alice was talking to Carol before the trans= fer, there is a
> Session-ID for that call. =A0If Bob is put in commu= nication with Carol, what
> is the Session-ID value? =A0Bob had one and Carol had a different one.= =A0What
> is the new ID?
>
> It's issues like this t= hat led us to using a two-part value. =A0In this way,
> we could see = the call from Alice to Bob has a Session-ID {A,B}. =A0If Alice
> transfers the call to Carol, each device understands that the Session-= ID
> changed to {B,C}. =A0Not only that, but intermediaries along the= path that
> were not privy to signaling that resulted in this change= can take note of
> the fact the value changed. =A0This can provide a useful historical re= cord,
> since previously they might see a call to Carol identified as= {A,C}, but
> then it changed to {B,C}.
>
> This property= extends quite naturally to other signaling scenarios, as it
> allows one to identify a call end-to-end, but also establish some
&= gt; relationship between other calls that shared at least one UUID value ou= t of
> the two.
>
> Hadriel mentioned the desire to use t= he Session-ID to correlate media flows
> and calls. =A0That's certainly something Cisco would like to do, b= ut it is not
> the driver behind the solution. =A0Having a valid end-= to-end identifier (in
> whatever form) allows us to do that. =A0We= 9;re not suggesting to fit the
> solution to meet that business use case, but rather we just want a sol= ution
> that allows us to properly identify calls end-to-end and we r= ecognize that,
> due to various service interactions in the network, = these UUID values can
> change.
>
> I would hope that UUID values will not change = to the extent that SBCs change
> them for business reasons. =A0It wou= ld certainly defeat the point. =A0Hadriel
> might be right that an SB= C vendor might manipulate those values at the
> request of a customer, but I would hope said customer appreciates that= such
> a request effectively breaks the end-to-end model. =A0We can&= #39;t do much about
> that if they do go down that path.
>
> As for backward-compatibility, the simplest approach (IMO) is to just = use a
> header value not already in use. =A0Originally, we had propos= ed Session-UUID.
> That was changed at the request of the group to be= Session-ID. =A0However,
> when we have a two UUID solution interacting with a one-UUID solution,= we
> immediately face some challenges.
>
> What happens = if an older system sends this:
> =A0Session-ID: X
> But then re= ceives this:
> =A0Session-ID: Y; remote=3DX
>
> Does this break things? = =A0If so, how do current implementations deal with
> such things as m= id-call transfers that happen on a PBX like the one I
> described abo= ve?
>
> We could switch the order like this:
> =A0Session-ID: X;= remote=3DY
>
> However, that does not work for similar reasons= . =A0If we have a call transfer
> where Alice transfers a call with B= ob to Carol, then each has a different
> idea about what the proper value is for the first position.
>> Originally, the proposed solution did not indicate position informati= on and
> just had single UUID values going in each direction. =A0We t= hen proposed a
> concatenated string (X:Y). However, that presented the same issues for= the
> call transfer case, so we indicate values by position (sender&= #39;s value
> first), so it is clear what value the receive thinks th= e remote end has for
> the local end. =A0It might be wrong, but that will be corrected in the=
> following response. (Intermediaries can take note of the change.)<= br>>
> So, that's why we are where we are. =A0There has been a= n effort to maintain
> backward-compatibility, but there are challenges in meeting that
&g= t; requirement. =A0Where it falls short, we do not know: we've not been= told
> explicitly what the issues are. =A0Further, if there are such= issues, we need
> to also understand how those would be handled in the face of call tran= sfer
> or "joining" a call locally on a PBX. =A0Those are r= eal-world scenarios that
> we must address.
>
> Anyway, n= othing is set in stone. =A0Anything can be changed, but I would hope
> we can find a solution that works for the enterprise use cases as well= as
> the service provider networks.
>
> Paul
>
= >
> _______________________________________________
> insipi= d 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

=A0

<= /div>

=A0



--089e013d100217609f04e2f30079-- From keith.drage@alcatel-lucent.com Fri Aug 2 02:45:40 2013 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 8ED4E11E8329 for ; Fri, 2 Aug 2013 02:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.622 X-Spam-Level: X-Spam-Status: No, score=-110.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUcmeZjpwn4n for ; Fri, 2 Aug 2013 02:45:35 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 678BD11E82FA for ; Fri, 2 Aug 2013 02:45:33 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r729jVfo006998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 2 Aug 2013 04:45:32 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r729jUdA020644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Aug 2013 11:45:30 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 11:45:30 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: Progressing logme requirements Thread-Index: Ac6PZQWgUa72ilUASuuIGhSA03pWuQ== Date: Fri, 2 Aug 2013 09:45:30 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07AB6E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [Insipid] Progressing logme requirements X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 09:45:40 -0000 (As WG chair) At the WG meeting we agreed to progress work on the logme proposals. Formal= ly if anyone on the WG list has issues with this, then they should indicate= their concerns to the list. Note that no draft has yet been adopted as a w= orking group item. I've had a discussion with the relevant area director (Gonzalo) and he is h= appy to progress the charter change and the new milestones. The proposed charter revisions can be found at http://www.ietf.org/proceedings/87/slides/slides-87-insipid-2.pdf On slide 9. The way this will be progressed is that Gonzalo has to take the charter cha= nge to IESG and the IESG decide whether they can approve the changes direct= ly or whether it needs to go to IETF consensus. My suspicion is that it wil= l be the former. This will occur in September when Gonzalo comes back from = vacation. If there is anything in the charter revisions you think should be changed o= r improved (or indeed rejected) then please feel free to post to the list w= ithin that time frame. In the meantime there is no reason why work cannot start on the requirement= s draft. Please feel free to either comment on, or improve on Peter's docum= ent=20 https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/=20 or to propose your own drafts to meet this need. We will be looking to see what can become a working group draft sometime ar= ound the Vancouver meeting timeframe. Regards Keith From keith.drage@alcatel-lucent.com Fri Aug 2 03:24:04 2013 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 38BAE21E82D3 for ; Fri, 2 Aug 2013 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.32 X-Spam-Level: X-Spam-Status: No, score=-110.32 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VOY328XD3OX for ; Fri, 2 Aug 2013 03:23:58 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F3CDD11E8217 for ; Fri, 2 Aug 2013 03:23:41 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r72AN9rD026603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2013 05:23:10 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r72AN83J002172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 12:23:08 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 12:23:08 +0200 From: "DRAGE, Keith (Keith)" To: Andrew Allen , "paulej@packetizer.com" , "laura.liess.dt@googlemail.com" , "insipid@ietf.org" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: AQHOj1XFHmdBy9j3R4y13v8TdvwiwZmBtV+Q Date: Fri, 2 Aug 2013 10:23:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07ACBB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B07A940@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B07ACBBFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:24:04 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B07ACBBFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As WG chair That corresponds to my understanding, with one caveat If the compatibility prevents the solution document meeting a requirement i= n the requirements draft, then that probably overrides the compatibility ag= reement to the extent that we need to meet the requirement. Regards Keith ________________________________ From: Andrew Allen [mailto:aallen@blackberry.com] Sent: 02 August 2013 08:56 To: DRAGE, Keith (Keith); paulej@packetizer.com; laura.liess.dt@googlemail.= com; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Putting it another way: Things that work with the kaplan draft should continue to work when a kapla= n compliant implementation interworks with the WG solution compliant implem= entations. Things that don't work with the kaplan draft are not expected to work when = a kaplan compliant implementation interworks with the WG solution compliant= implementations however the degraded behavior should be no worse than betw= een kaplan compliant implementations. Andrew From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Friday, August 02, 2013 02:43 AM Central Standard Time To: Paul E. Jones ; 'Laura Liess' ; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Let us get this clear. The Kaplan draft is not expected to meet all the requirements. If it did, w= e would probably be progressing it as the solution document. What the previous decision of the working group effectively required, when = it desired compatibility, was that sensible things should happen as far as = possible when the two solutions interoperated. There is also no implication= that when Kaplan draft meets WG solution that all the requirements are met= . The desire for compatibility is based on the fact that the previous solutio= n is out there in the field. One solution will meet the other. One solution= should not bomb the other one out. Implementors of the Kaplan solution wil= l migrate to the real solution at some point and that intent has been expre= ssed in the meeting several times. But that migration will not happen overn= ight as soon as the WG RFCs are published. Regards Keith ________________________________ From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: 01 August 2013 16:00 To: 'Laura Liess'; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Laura, I assert that old draft will not work for some "real-world" calls. Calls d= o get manipulated in enterprise environments and call centers for billing p= urposes, privacy reasons, etc. Consider a common case: if you call into a call center and the agent puts y= ou on hold while they transfer you to a specialist (transfer out of consult= ation), for example, your SIP UA does not receive a REFER to initiate a new= call directly to the specialist. This is handled at the call center. So rather specifically, how would this be handled (with the old draft)? 1) Alice calls Bob (Session-ID: A) 2) Bob puts Alice on hold and calls Carol (Session-ID: B) 3) Bob transfers the call from Alice to Carol using a local transfer functi= on on the PBX (Session-ID: ??) The PBX could send different values to Alice and Carol, but we totally lose= the end-to-end identification of the call. Alice could not send "A" to Carol, since Carol is expecting B. Likewise, C= arol cannot send "B" to Alice, since Alice is expecting "A". Well, they co= uld, and it would be no worse than our current proposal in terms of backwar= d-compatibility. Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Laura Liess Sent: Thursday, August 01, 2013 9:13 AM To: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Hadriel's proposal works for us. Thank you Laura 2013/8/1 Hadriel Kaplan > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vend= or. This is just about a Working Group document, and whether the mechanism= defined in it should change the Session-ID header value vs. parameter base= d on direction of messages, or not. I totally get the need to have a disti= nguishing Session-ID identifier for party-A vs. party-B. What I don't get = is why they need to change the encoding of the Session-ID header value vs. = parameter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" This second model keeps the Session-ID header value as "foo" the whole time= , while adding a parameter of "bar" for Bob that remains a parameter the wh= ole time. Neither Alice nor Bob are confused about which one is "their" UUID value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why it = had to be swapped, but I don't remember what it is and I don't see it in th= e draft. So I'm trying to find out why we need to do it the way the draft = currently has it. The other topic of whether SBCs will change things is completely orthogonal= to the ordering or backwards compatibility issues, and really shouldn't be= conflated with it at all. It has nothing to do with the solutions documen= t, or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones > wrote: > Folks, > > I step away for a couple of days and the floodgate opens. :) > > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to effectively > deal with things like forking, call transfer, park, bridging, conferencin= g, > etc. > > When initiating a call and using a single UUID value, that has the potent= ial > to go end-to-end. However, if a call is forked there are multiple "ends". > How do we track each of those? For proper diagnostics and troubleshootin= g, > it would be ideal to be able to identify which devices have an issue. > > Once a call has been placed, there is a Session-ID established between Al= ice > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > different country) to a some location in a high-toll country, who pays th= e > bill? Well, to address that, we do call transfer locally on PBXes. The = PBX > maintains control over the call and Alice would pay the bill for the call > transfer. But if Alice was talking to Carol before the transfer, there i= s a > Session-ID for that call. If Bob is put in communication with Carol, wha= t > is the Session-ID value? Bob had one and Carol had a different one. Wha= t > is the new ID? > > It's issues like this that led us to using a two-part value. In this way= , > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > transfers the call to Carol, each device understands that the Session-ID > changed to {B,C}. Not only that, but intermediaries along the path that > were not privy to signaling that resulted in this change can take note of > the fact the value changed. This can provide a useful historical record, > since previously they might see a call to Carol identified as {A,C}, but > then it changed to {B,C}. > > This property extends quite naturally to other signaling scenarios, as it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value out = of > the two. > > Hadriel mentioned the desire to use the Session-ID to correlate media flo= ws > and calls. That's certainly something Cisco would like to do, but it is = not > the driver behind the solution. Having a valid end-to-end identifier (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a soluti= on > that allows us to properly identify calls end-to-end and we recognize tha= t, > due to various service interactions in the network, these UUID values can > change. > > I would hope that UUID values will not change to the extent that SBCs cha= nge > them for business reasons. It would certainly defeat the point. Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that su= ch > a request effectively breaks the end-to-end model. We can't do much abou= t > that if they do go down that path. > > As for backward-compatibility, the simplest approach (IMO) is to just use= a > header value not already in use. Originally, we had proposed Session-UUI= D. > That was changed at the request of the group to be Session-ID. However, > when we have a two UUID solution interacting with a one-UUID solution, we > immediately face some challenges. > > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=3DX > > Does this break things? If so, how do current implementations deal with > such things as mid-call transfers that happen on a PBX like the one I > described above? > > We could switch the order like this: > Session-ID: X; remote=3DY > > However, that does not work for similar reasons. If we have a call trans= fer > where Alice transfers a call with Bob to Carol, then each has a different > idea about what the proper value is for the first position. > > Originally, the proposed solution did not indicate position information a= nd > just had single UUID values going in each direction. We then proposed a > concatenated string (X:Y). However, that presented the same issues for th= e > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end has f= or > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) > > So, that's why we are where we are. There has been an effort to maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been told > explicitly what the issues are. Further, if there are such issues, we ne= ed > to also understand how those would be handled in the face of call transfe= r > or "joining" a call locally on a PBX. Those are real-world scenarios tha= t > we must address. > > Anyway, nothing is set in stone. Anything can be changed, but I would ho= pe > we can find a solution that works for the enterprise use cases as well as > the service provider networks. > > 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_949EF20990823C4C85C18D59AA11AD8B07ACBBFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As WG chair

 

That corresponds to my understanding, = with one caveat

 

If the compatibility prevents the solu= tion document meeting a requirement in the requirements draft, then that pr= obably overrides the compatibility agreement to the extent that we need to meet the requirement= .

 

Regards

 

Keith

 

From: Andrew Allen [mailto:aallen@blackberry.com]
Sent: 02 August 2013 08:56 To: DRAGE, Keith (Keith); pa= ulej@packetizer.com; laura.liess.dt@googlemail.com; insipid@ietf.org
Subject: Re: [Insipid] Propo= sed INSIPID solution and backward compatibility

 

=
Putting it another way:

Things that work with the kaplan draft should continue to work when a kapla= n compliant implementation interworks with the WG solution compliant implem= entations.

Things that don't work with the kaplan draft are not expected to work when = a kaplan compliant implementation interworks with the WG solution compliant= implementations however the degraded behavior should be no worse than betw= een kaplan compliant implementations.

Andrew
 

From: DRAG= E, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Friday, August 02, 2013 02:43 AM Central Standard Time
To: Paul E. Jones <paulej= @packetizer.com>; 'Laura Liess' <laura.liess.dt@googlemail.com>; i= nsipid@ietf.org <insipid@ietf.org>
Subject: Re: [Insipid] Propo= sed INSIPID solution and backward compatibility
 

Let us get this clear.

 

The Kaplan draft is not expected to me= et all the requirements. If it did, we would probably be progressing it as = the solution document.

 

What the previous decision of the work= ing group effectively required, when it desired compatibility, was that sen= sible things should happen as far as possible when the two solutions interoperated. There is a= lso no implication that when Kaplan draft meets WG solution that all the re= quirements are met.

 

The desire for compatibility is based = on the fact that the previous solution is out there in the field. One solut= ion will meet the other. One solution should not bomb the other one out. Implementors of the Kaplan= solution will migrate to the real solution at some point and that intent h= as been expressed in the meeting several times. But that migration will not= happen overnight as soon as the WG RFCs are published.

 

Regards

 

Keith

 

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On B= ehalf Of Paul E. Jones
Sent: 01 August 2013 16:00 To: 'Laura Liess'; insipid@i= etf.org
Subject: Re: [Insipid] Propo= sed INSIPID solution and backward compatibility

 

= Laura,

=  

= I assert that old draft will not work for some “real-worldR= 21; calls.  Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc.

=  

= Consider a common case: if you call into a call center and the agent= puts you on hold while they transfer you to a specialist (transfer out of consultation), for example, your SIP UA does= not receive a REFER to ini= tiate a new call directly to the specialist.  This is handled at the c= all center.

=  

= So rather specifically, how would this be handled (with the old draf= t)?

=  

= 1) Alice c= alls Bob (Session-ID: A)

= 2) Bob puts Alice o= n hold and calls Carol (Session-ID: B)

= 3) Bob transfers the call from Alice t= o Carol using a local transfer function on the PBX (Session-ID: ??)

=  

= The PBX could send different values to Alice and Carol, but we total= ly lose the end-to-end identification of the call.

=  

Alice could not send “A” to Carol, since Carol is expecting B. = Likewise, Carol cannot send “B” to Alice, since Alice is expecting “A”.&= nbsp; Well, they could, and it would be no worse than our current proposal = in terms of backward-compatibility.

=  

= Paul

=  

From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On B= ehalf Of Laura Liess
Sent: Thursday, August 01, 2013 9= :13 AM
To: insipid@ietf.org
Subject: Re: [Insipid] Propo= sed INSIPID solution and backward compatibility

 


Hadriel's proposal works for us.

Thank you
Laura

&= nbsp;

2013/8/1 Hadriel Kaplan <hadriel.kaplan@orac= le.com>


This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor. &nb= sp;This is just about a Working Group document, and whether the mechanism d= efined in it should change the Session-ID header value vs. parameter based on direction of messages, or not.  I= totally get the need to have a distinguishing Session-ID identifier for pa= rty-A vs. party-B.  What I don't get is why they need to change the en= coding of the Session-ID header value vs. parameter, on a message direction basis.

In other words, today the draft has this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: bar;remote= =3Dfoo"
3) Alice sends ACK with        "Session-ID: foo;remote=3D= bar"
4) Bob   sends BYE with        "Session-ID: b= ar;remote=3Dfoo"
5) Alice sends 200 with        "Session-ID: foo;remote=3D= bar"

But we could instead do this:
1) Alice sends INVITE with     "Session-ID: foo"
2) Bob   sends 18x/200 with    "Session-ID: foo;remote= =3Dbar"
3) Alice sends ACK with        "Session-ID: foo;remote=3D= bar"
4) Bob   sends BYE with        "Session-ID: f= oo;remote=3Dbar"
5) Alice sends 200 with        "Session-ID: foo;remote=3D= bar"

This second model keeps the Session-ID header value as "foo" the = whole time, while adding a parameter of "bar" for Bob that remain= s a parameter the whole time.
Neither Alice nor Bob are confused about which one is "their" UUI= D value.
And it's backward-compatible with the previous kaplan-draft.
And it's arguably easier to implement, for the common cases.

I *think* there was a reason someone came up with at one time as to why it = had to be swapped, but I don't remember what it is and I don't see it in th= e draft.  So I'm trying to find out why we need to do it the way the d= raft currently has it.

The other topic of whether SBCs will change things is completely orthogonal= to the ordering or backwards compatibility issues, and really shouldn't be= conflated with it at all.  It has nothing to do with the solutions do= cument, or the direction stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones <paulej@packetizer.com> wrote:

> Folks,
>
> I step away for a couple of days and the floodgate opens. :)
>
> I think it's important to understand why we proposed using a two-part<= br> > Session Identifier.  The reason is that we have to be able to eff= ectively
> deal with things like forking, call transfer, park, bridging, conferen= cing,
> etc.
>
> When initiating a call and using a single UUID value, that has the pot= ential
> to go end-to-end. However, if a call is forked there are multiple &quo= t;ends".
> How do we track each of those?  For proper diagnostics and troubl= eshooting,
> it would be ideal to be able to identify which devices have an issue.<= br> >
> Once a call has been placed, there is a Session-ID established between= Alice
> and Bob.  If Alice (in one country) transfers Bob (perhaps in the same o= r
> different country) to a some location in a high-toll country, who pays= the
> bill?  Well, to address that, we do call transfer locally on PBXe= s.  The PBX
> maintains control over the call and Alice would pay the bill for the call
> transfer.  But if Al= ice was talking to Carol before the transfer, there = is a
> Session-ID for that call.  If Bob is put in communication with Ca= rol, what
> is the Session-ID value?  Bob had one and Carol had a different o= ne.  What
> is the new ID?
>
> It's issues like this that led us to using a two-part value.  In = this way,
> we could see the call from Alice to Bob has a Session-ID {A,B}.  If Alice > transfers the call to Carol, each device understands that the Session-= ID
> changed to {B,C}.  Not only that, but intermediaries along the pa= th that
> were not privy to signaling that resulted in this change can take note= of
> the fact the value changed.  This can provide a useful historical= record,
> since previously they might see a call to Carol identified as {A,C}, b= ut
> then it changed to {B,C}.
>
> This property extends quite naturally to other signaling scenarios, as= it
> allows one to identify a call end-to-end, but also establish some
> relationship between other calls that shared at least one UUID value o= ut of
> the two.
>
> Hadriel mentioned the desire to use the Session-ID to correlate media = flows
> and calls.  That's certainly something Cisco would like to do, bu= t it is not
> the driver behind the solution.  Having a valid end-to-end identi= fier (in
> whatever form) allows us to do that.  We're not suggesting to fit= the
> solution to meet that business use case, but rather we just want a sol= ution
> that allows us to properly identify calls end-to-end and we recognize = that,
> due to various service interactions in the network, these UUID values = can
> change.
>
> I would hope that UUID values will not change to the extent that SBCs = change
> them for business reasons.  It would certainly defeat the point. =  Hadriel
> might be right that an SBC vendor might manipulate those values at the
> request of a customer, but I would hope said customer appreciates that= such
> a request effectively breaks the end-to-end model.  We can't do m= uch about
> that if they do go down that path.
>
> As for backward-compatibility, the simplest approach (IMO) is to just use a
> header value not already in use.  Originally, we had proposed Ses= sion-UUID.
> That was changed at the request of the group to be Session-ID.  H= owever,
> when we have a two UUID solution interacting with a one-UUID solution,= we
> immediately face some challenges.
>
> What happens if an older system sends this:
>  Session-ID: X
> But then receives this:
>  Session-ID: Y; remote=3DX
>
> Does this break things?  If so, how do current implementations de= al with
> such things as mid-call transfers that happen on a PBX like the one I<= br> > described above?
>
> We could switch the order like this:
>  Session-ID: X; remote=3DY
>
> However, that does not work for similar reasons.  If we have a ca= ll transfer
> where Alice transfers a call with Bob to Carol, then each has a different
> idea about what the proper value is for the first position.
>
> Originally, the proposed solution did not indicate position informatio= n and
> just had single UUID values going in each direction.  We then pro= posed a
> concatenated string (X:Y). However, that presented the same issues for= the
> call transfer case, so we indicate values by position (sender's value<= br> > first), so it is clear what value the receive thinks the remote end ha= s for
> the local end.  It might be wrong, but that will be corrected in = the
> following response. (Intermediaries can take note of the change.)
>
> So, that's why we are where we are.  There has been an effort to = maintain
> backward-compatibility, but there are challenges in meeting that
> requirement.  Where it falls short, we do not know: we've not bee= n told
> explicitly what the issues are.  Further, if there are such issue= s, we need
> to also understand how those would be handled in the face of call tran= sfer
> or "joining" a call locally on a PBX.  Those are real-w= orld scenarios that
> we must address.
>
> Anyway, nothing is set in stone.  Anything can be changed, but I = would hope
> we can find a solution that works for the enterprise use cases as well= as
> the service provider networks.
>
> Paul
>
>
> _______________________________________________
> insipid mailing list
> insipid@ietf.org=
> https://www.ietf.org/mailman/listinfo/insipid

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

 

 

-------------------------------------------------------------------= --
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--_000_949EF20990823C4C85C18D59AA11AD8B07ACBBFR712WXCHMBA11zeu_-- From prvs=29260092cd=aallen@blackberry.com Fri Aug 2 03:52:46 2013 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 C483721E8335 for ; Fri, 2 Aug 2013 03:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtxTuKsRbZDy for ; Fri, 2 Aug 2013 03:52:41 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 822F721E82DB for ; Fri, 2 Aug 2013 03:52:26 -0700 (PDT) X-AuditID: 0a41282f-b7f9b6d000002847-80-51fb8f62fab2 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id C4.C0.10311.36F8BF15; Fri, 2 Aug 2013 05:52:19 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 05:52:18 -0500 From: Andrew Allen To: "keith.drage@alcatel-lucent.com" , "paulej@packetizer.com" , "laura.liess.dt@googlemail.com" , "insipid@ietf.org" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: AQHOj1XF0NEH5jKMHUSVtl/o795Uu5mCCbYA//+0VSY= Date: Fri, 2 Aug 2013 10:52:18 +0000 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07ACBB@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338DF0B33XMB104ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEKsWRmVeSWpSXmKPExsXC5ZyvpZvc/zvQ4MgOfov5958xWTxtPMto MeeKocX5CxuYHFg8Wp/tZfV4OmEyu8eSJT+ZPBr2HWUPYIlqYLRJSiwpC85Mz9O3s0nMy8sv SSxJVUhJLU62VfJJTU/MUQgoyixLTK5UcMksTs5JzMxNLVJSyEyxVTJRUijISUxOzU3NK7FV SiwoSM1LUbLjUsAANkBlmXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZKdroJnTwZd6dfYC6Y9IK5 omvdfeYGxj23mbsYOTkkBEwkfrzrZYKwxSQu3FvP1sXIxSEksJJRYv7aX+wQziZGiQ+XjoBV sQloSew/PJ0JJCEi8IRR4uHZJ2CjhAW8Je5+m8kKYosI+Eh8mP2KHcK2kji34hsjiM0ioCJx /OdysBpeAQ+JM2t3gvVyCkRLXHx0CyzOKCArsfvsdbBlzALiEreezIc6T0BiyZ7zUGeLSrx8 /I8VwlaUmLFnPpDNAVSfL9F3VwRivKDEyZlPWCYwCs9CMmkWQtUsJFUQYU2J9bv0IaoVJaZ0 P2SHsDUkWufMZUcWX8DIvopRMDej2MDMIDkvWa8oM1cvL7VkEyMonThq6O9gfPve4hCjAAej Eg/vuebfgUKsiWXFlbmHGCU4mJVEeP/M/hUoxJuSWFmVWpQfX1Sak1p8iDEIGDwTmaW4k/OB qS6vJN7YwIBIjpI4r6vKh0AhgXRgwspOTS1ILYIZysTBCbKUS0qkGJh2UosSS0sy4kHJMb4Y mB6lGhjZVa+oWvYoyG98WucdfS0/1zR11foVl4K1D7te+Jv8L/hHuIxxa9nKHcdzZVQYw9qX LBDpLvskvnqZ5u+CTZd75U899PlUY/hfucBOcBHXNGur+LUmk2W1VS55tgTMfutqdP5XhRbn wQP/BBmcdEVFLmv9dzhXWBX9OcP20rmkCX3fGuwFHiuxFGckGmoxFxUnAgBUM6ApdQMAAA== Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:52:46 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338DF0B33XMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpJIGRvbid0IHNlZSB0aGF0IHdlIGV2ZXIgbmVlZCB0byBnZXQgaW50byB0aGF0IHNpdHVh dGlvbi4NCg0KQXMgd2UgZGlzY3Vzc2VkIHllc3RlcmRheSB3ZSBoYXZlIHR3byBwYXJ0cy4g VGhlIGhlYWRlciBmaWVsZCBwYXJ0IGFuZCB0aGUgaGVhZGVyIHBhcmFtZXRlciBwYXJ0KHMp Lg0KDQpJbiBvcmRlciB0byBiZSBjb21wYXRpYmxlIHdpdGggdGhlIGthcGxhbiBkcmFmdCB0 aGUgaGVhZGVyIGZpZWxkIHBhcnQgaXMgaW5zZXJ0ZWQgYnkgdGhlIHBhcnR5IHRoYXQgZmly c3QgaW5jbHVkZXMgdGhlIHNlc3Npb24gSUQgYW5kIHRoaXMgdmFsdWUgTVVTVCBOT1QgYmUg bW9kaWZpZWQuIFRoZSBoZWFkZXIgcGFyYW1ldGVyIHBhcnQgb3IgcGFydHMgY2FuIGJlIGNo YW5nZWQgYXMgbXVjaCBhcyB5b3UgbGlrZSBhbmQgc3RpbGwgYmUgYmFja3dhcmQgY29tcGF0 aWJsZSB3aXRoIGthcGxhbi4NCg0KSWYgd2UgbmVlZCB0byByZXZlcnNlIG9yZGVycyBvciBv dGhlcndpc2UgbW9kaWZ5IHNlc3Npb24gSURzIGxldCdzIGRlZmluZWQgYWRkaXRpb25hbCBo ZWFkZXIgcGFyYW1ldGVycyB0aGF0IGNhbiBiZSBjaGFuZ2VkIHVuZGVyIGNlcnRhaW4gc2l0 dWF0aW9ucyBkdXJpbmcgYSBzZXNzaW9uIHdoaWxlIGxlYXZpbmcgdGhlIGhlYWRlciBmaWVs ZCB2YWx1ZSB1bmNoYW5nZWQuIFRoYXQgd2F5IHdlIGNhbiBoYXZlIG91ciBjYWtlIGFuZCBl YXQgaXQuDQoNCkFuZHJldw0KDQpGcm9tOiBEUkFHRSwgS2VpdGggKEtlaXRoKSBbbWFpbHRv OmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbV0NClNlbnQ6IEZyaWRheSwgQXVndXN0 IDAyLCAyMDEzIDA1OjIzIEFNIENlbnRyYWwgU3RhbmRhcmQgVGltZQ0KVG86IEFuZHJldyBB bGxlbjsgcGF1bGVqQHBhY2tldGl6ZXIuY29tIDxwYXVsZWpAcGFja2V0aXplci5jb20+OyBs YXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbSA8bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFp bC5jb20+OyBpbnNpcGlkQGlldGYub3JnIDxpbnNpcGlkQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtJbnNpcGlkXSBQcm9wb3NlZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBiYWNrd2FyZCBj b21wYXRpYmlsaXR5DQoNCkFzIFdHIGNoYWlyDQoNClRoYXQgY29ycmVzcG9uZHMgdG8gbXkg dW5kZXJzdGFuZGluZywgd2l0aCBvbmUgY2F2ZWF0DQoNCklmIHRoZSBjb21wYXRpYmlsaXR5 IHByZXZlbnRzIHRoZSBzb2x1dGlvbiBkb2N1bWVudCBtZWV0aW5nIGEgcmVxdWlyZW1lbnQg aW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCwgdGhlbiB0aGF0IHByb2JhYmx5IG92ZXJyaWRl cyB0aGUgY29tcGF0aWJpbGl0eSBhZ3JlZW1lbnQgdG8gdGhlIGV4dGVudCB0aGF0IHdlIG5l ZWQgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnQuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEFuZHJldyBBbGxlbiBbbWFp bHRvOmFhbGxlbkBibGFja2JlcnJ5LmNvbV0NClNlbnQ6IDAyIEF1Z3VzdCAyMDEzIDA4OjU2 DQpUbzogRFJBR0UsIEtlaXRoIChLZWl0aCk7IHBhdWxlakBwYWNrZXRpemVyLmNvbTsgbGF1 cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb207IGluc2lwaWRAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbSW5zaXBpZF0gUHJvcG9zZWQgSU5TSVBJRCBzb2x1dGlvbiBhbmQgYmFja3dhcmQg Y29tcGF0aWJpbGl0eQ0KDQoNClB1dHRpbmcgaXQgYW5vdGhlciB3YXk6DQoNClRoaW5ncyB0 aGF0IHdvcmsgd2l0aCB0aGUga2FwbGFuIGRyYWZ0IHNob3VsZCBjb250aW51ZSB0byB3b3Jr IHdoZW4gYSBrYXBsYW4gY29tcGxpYW50IGltcGxlbWVudGF0aW9uIGludGVyd29ya3Mgd2l0 aCB0aGUgV0cgc29sdXRpb24gY29tcGxpYW50IGltcGxlbWVudGF0aW9ucy4NCg0KVGhpbmdz IHRoYXQgZG9uJ3Qgd29yayB3aXRoIHRoZSBrYXBsYW4gZHJhZnQgYXJlIG5vdCBleHBlY3Rl ZCB0byB3b3JrIHdoZW4gYSBrYXBsYW4gY29tcGxpYW50IGltcGxlbWVudGF0aW9uIGludGVy d29ya3Mgd2l0aCB0aGUgV0cgc29sdXRpb24gY29tcGxpYW50IGltcGxlbWVudGF0aW9ucyBo b3dldmVyIHRoZSBkZWdyYWRlZCBiZWhhdmlvciBzaG91bGQgYmUgbm8gd29yc2UgdGhhbiBi ZXR3ZWVuIGthcGxhbiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zLg0KDQpBbmRyZXcNCg0K RnJvbTogRFJBR0UsIEtlaXRoIChLZWl0aCkgW21haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVs LWx1Y2VudC5jb21dDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAwMiwgMjAxMyAwMjo0MyBBTSBD ZW50cmFsIFN0YW5kYXJkIFRpbWUNClRvOiBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0 aXplci5jb20+OyAnTGF1cmEgTGllc3MnIDxsYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNv bT47IGluc2lwaWRAaWV0Zi5vcmcgPGluc2lwaWRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0luc2lwaWRdIFByb3Bvc2VkIElOU0lQSUQgc29sdXRpb24gYW5kIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkNCg0KTGV0IHVzIGdldCB0aGlzIGNsZWFyLg0KDQpUaGUgS2FwbGFuIGRyYWZ0 IGlzIG5vdCBleHBlY3RlZCB0byBtZWV0IGFsbCB0aGUgcmVxdWlyZW1lbnRzLiBJZiBpdCBk aWQsIHdlIHdvdWxkIHByb2JhYmx5IGJlIHByb2dyZXNzaW5nIGl0IGFzIHRoZSBzb2x1dGlv biBkb2N1bWVudC4NCg0KV2hhdCB0aGUgcHJldmlvdXMgZGVjaXNpb24gb2YgdGhlIHdvcmtp bmcgZ3JvdXAgZWZmZWN0aXZlbHkgcmVxdWlyZWQsIHdoZW4gaXQgZGVzaXJlZCBjb21wYXRp YmlsaXR5LCB3YXMgdGhhdCBzZW5zaWJsZSB0aGluZ3Mgc2hvdWxkIGhhcHBlbiBhcyBmYXIg YXMgcG9zc2libGUgd2hlbiB0aGUgdHdvIHNvbHV0aW9ucyBpbnRlcm9wZXJhdGVkLiBUaGVy ZSBpcyBhbHNvIG5vIGltcGxpY2F0aW9uIHRoYXQgd2hlbiBLYXBsYW4gZHJhZnQgbWVldHMg V0cgc29sdXRpb24gdGhhdCBhbGwgdGhlIHJlcXVpcmVtZW50cyBhcmUgbWV0Lg0KDQpUaGUg ZGVzaXJlIGZvciBjb21wYXRpYmlsaXR5IGlzIGJhc2VkIG9uIHRoZSBmYWN0IHRoYXQgdGhl IHByZXZpb3VzIHNvbHV0aW9uIGlzIG91dCB0aGVyZSBpbiB0aGUgZmllbGQuIE9uZSBzb2x1 dGlvbiB3aWxsIG1lZXQgdGhlIG90aGVyLiBPbmUgc29sdXRpb24gc2hvdWxkIG5vdCBib21i IHRoZSBvdGhlciBvbmUgb3V0LiBJbXBsZW1lbnRvcnMgb2YgdGhlIEthcGxhbiBzb2x1dGlv biB3aWxsIG1pZ3JhdGUgdG8gdGhlIHJlYWwgc29sdXRpb24gYXQgc29tZSBwb2ludCBhbmQg dGhhdCBpbnRlbnQgaGFzIGJlZW4gZXhwcmVzc2VkIGluIHRoZSBtZWV0aW5nIHNldmVyYWwg dGltZXMuIEJ1dCB0aGF0IG1pZ3JhdGlvbiB3aWxsIG5vdCBoYXBwZW4gb3Zlcm5pZ2h0IGFz IHNvb24gYXMgdGhlIFdHIFJGQ3MgYXJlIHB1Ymxpc2hlZC4NCg0KUmVnYXJkcw0KDQpLZWl0 aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogaW5zaXBpZC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgUGF1bCBFLiBKb25lcw0KU2VudDogMDEgQXVndXN0IDIwMTMgMTY6MDANClRv OiAnTGF1cmEgTGllc3MnOyBpbnNpcGlkQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0luc2lw aWRdIFByb3Bvc2VkIElOU0lQSUQgc29sdXRpb24gYW5kIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkNCg0KTGF1cmEsDQoNCkkgYXNzZXJ0IHRoYXQgb2xkIGRyYWZ0IHdpbGwgbm90IHdvcmsg Zm9yIHNvbWUg4oCccmVhbC13b3JsZOKAnSBjYWxscy4gIENhbGxzIGRvIGdldCBtYW5pcHVs YXRlZCBpbiBlbnRlcnByaXNlIGVudmlyb25tZW50cyBhbmQgY2FsbCBjZW50ZXJzIGZvciBi aWxsaW5nIHB1cnBvc2VzLCBwcml2YWN5IHJlYXNvbnMsIGV0Yy4NCg0KQ29uc2lkZXIgYSBj b21tb24gY2FzZTogaWYgeW91IGNhbGwgaW50byBhIGNhbGwgY2VudGVyIGFuZCB0aGUgYWdl bnQgcHV0cyB5b3Ugb24gaG9sZCB3aGlsZSB0aGV5IHRyYW5zZmVyIHlvdSB0byBhIHNwZWNp YWxpc3QgKHRyYW5zZmVyIG91dCBvZiBjb25zdWx0YXRpb24pLCBmb3IgZXhhbXBsZSwgeW91 ciBTSVAgVUEgZG9lcyBub3QgcmVjZWl2ZSBhIFJFRkVSIHRvIGluaXRpYXRlIGEgbmV3IGNh bGwgZGlyZWN0bHkgdG8gdGhlIHNwZWNpYWxpc3QuICBUaGlzIGlzIGhhbmRsZWQgYXQgdGhl IGNhbGwgY2VudGVyLg0KDQpTbyByYXRoZXIgc3BlY2lmaWNhbGx5LCBob3cgd291bGQgdGhp cyBiZSBoYW5kbGVkICh3aXRoIHRoZSBvbGQgZHJhZnQpPw0KDQoxKSBBbGljZSBjYWxscyBC b2IgKFNlc3Npb24tSUQ6IEEpDQoyKSBCb2IgcHV0cyBBbGljZSBvbiBob2xkIGFuZCBjYWxs cyBDYXJvbCAoU2Vzc2lvbi1JRDogQikNCjMpIEJvYiB0cmFuc2ZlcnMgdGhlIGNhbGwgZnJv bSBBbGljZSB0byBDYXJvbCB1c2luZyBhIGxvY2FsIHRyYW5zZmVyIGZ1bmN0aW9uIG9uIHRo ZSBQQlggKFNlc3Npb24tSUQ6ID8/KQ0KDQpUaGUgUEJYIGNvdWxkIHNlbmQgZGlmZmVyZW50 IHZhbHVlcyB0byBBbGljZSBhbmQgQ2Fyb2wsIGJ1dCB3ZSB0b3RhbGx5IGxvc2UgdGhlIGVu ZC10by1lbmQgaWRlbnRpZmljYXRpb24gb2YgdGhlIGNhbGwuDQoNCkFsaWNlIGNvdWxkIG5v dCBzZW5kIOKAnEHigJ0gdG8gQ2Fyb2wsIHNpbmNlIENhcm9sIGlzIGV4cGVjdGluZyBCLiAg TGlrZXdpc2UsIENhcm9sIGNhbm5vdCBzZW5kIOKAnELigJ0gdG8gQWxpY2UsIHNpbmNlIEFs aWNlIGlzIGV4cGVjdGluZyDigJxB4oCdLiAgV2VsbCwgdGhleSBjb3VsZCwgYW5kIGl0IHdv dWxkIGJlIG5vIHdvcnNlIHRoYW4gb3VyIGN1cnJlbnQgcHJvcG9zYWwgaW4gdGVybXMgb2Yg YmFja3dhcmQtY29tcGF0aWJpbGl0eS4NCg0KUGF1bA0KDQpGcm9tOiBpbnNpcGlkLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMYXVyYSBMaWVzcw0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAwMSwgMjAxMyA5OjEz IEFNDQpUbzogaW5zaXBpZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJbnNpcGlkXSBQcm9w b3NlZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5DQoNCg0K SGFkcmllbCdzIHByb3Bvc2FsIHdvcmtzIGZvciB1cy4NCg0KVGhhbmsgeW91DQpMYXVyYQ0K DQoyMDEzLzgvMSBIYWRyaWVsIEthcGxhbiA8aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbTxt YWlsdG86aGFkcmllbC5rYXBsYW5Ab3JhY2xlLmNvbT4+DQoNClRoaXMgaXNuJ3QgYWJvdXQg RW50ZXJwcmlzZSB2cy4gU2VydmljZS1Qcm92aWRlciwgb3IgQ2lzY28gdnMuIGFub3RoZXIg dmVuZG9yLiAgVGhpcyBpcyBqdXN0IGFib3V0IGEgV29ya2luZyBHcm91cCBkb2N1bWVudCwg YW5kIHdoZXRoZXIgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGluIGl0IHNob3VsZCBjaGFuZ2Ug dGhlIFNlc3Npb24tSUQgaGVhZGVyIHZhbHVlIHZzLiBwYXJhbWV0ZXIgYmFzZWQgb24gZGly ZWN0aW9uIG9mIG1lc3NhZ2VzLCBvciBub3QuICBJIHRvdGFsbHkgZ2V0IHRoZSBuZWVkIHRv IGhhdmUgYSBkaXN0aW5ndWlzaGluZyBTZXNzaW9uLUlEIGlkZW50aWZpZXIgZm9yIHBhcnR5 LUEgdnMuIHBhcnR5LUIuICBXaGF0IEkgZG9uJ3QgZ2V0IGlzIHdoeSB0aGV5IG5lZWQgdG8g Y2hhbmdlIHRoZSBlbmNvZGluZyBvZiB0aGUgU2Vzc2lvbi1JRCBoZWFkZXIgdmFsdWUgdnMu IHBhcmFtZXRlciwgb24gYSBtZXNzYWdlIGRpcmVjdGlvbiBiYXNpcy4NCg0KSW4gb3RoZXIg d29yZHMsIHRvZGF5IHRoZSBkcmFmdCBoYXMgdGhpczoNCjEpIEFsaWNlIHNlbmRzIElOVklU RSB3aXRoICAgICAiU2Vzc2lvbi1JRDogZm9vIg0KMikgQm9iICAgc2VuZHMgMTh4LzIwMCB3 aXRoICAgICJTZXNzaW9uLUlEOiBiYXI7cmVtb3RlPWZvbyINCjMpIEFsaWNlIHNlbmRzIEFD SyB3aXRoICAgICAgICAiU2Vzc2lvbi1JRDogZm9vO3JlbW90ZT1iYXIiDQo0KSBCb2IgICBz ZW5kcyBCWUUgd2l0aCAgICAgICAgIlNlc3Npb24tSUQ6IGJhcjtyZW1vdGU9Zm9vIg0KNSkg QWxpY2Ugc2VuZHMgMjAwIHdpdGggICAgICAgICJTZXNzaW9uLUlEOiBmb287cmVtb3RlPWJh ciINCg0KQnV0IHdlIGNvdWxkIGluc3RlYWQgZG8gdGhpczoNCjEpIEFsaWNlIHNlbmRzIElO VklURSB3aXRoICAgICAiU2Vzc2lvbi1JRDogZm9vIg0KMikgQm9iICAgc2VuZHMgMTh4LzIw MCB3aXRoICAgICJTZXNzaW9uLUlEOiBmb287cmVtb3RlPWJhciINCjMpIEFsaWNlIHNlbmRz IEFDSyB3aXRoICAgICAgICAiU2Vzc2lvbi1JRDogZm9vO3JlbW90ZT1iYXIiDQo0KSBCb2Ig ICBzZW5kcyBCWUUgd2l0aCAgICAgICAgIlNlc3Npb24tSUQ6IGZvbztyZW1vdGU9YmFyIg0K NSkgQWxpY2Ugc2VuZHMgMjAwIHdpdGggICAgICAgICJTZXNzaW9uLUlEOiBmb287cmVtb3Rl PWJhciINCg0KVGhpcyBzZWNvbmQgbW9kZWwga2VlcHMgdGhlIFNlc3Npb24tSUQgaGVhZGVy IHZhbHVlIGFzICJmb28iIHRoZSB3aG9sZSB0aW1lLCB3aGlsZSBhZGRpbmcgYSBwYXJhbWV0 ZXIgb2YgImJhciIgZm9yIEJvYiB0aGF0IHJlbWFpbnMgYSBwYXJhbWV0ZXIgdGhlIHdob2xl IHRpbWUuDQpOZWl0aGVyIEFsaWNlIG5vciBCb2IgYXJlIGNvbmZ1c2VkIGFib3V0IHdoaWNo IG9uZSBpcyAidGhlaXIiIFVVSUQgdmFsdWUuDQpBbmQgaXQncyBiYWNrd2FyZC1jb21wYXRp YmxlIHdpdGggdGhlIHByZXZpb3VzIGthcGxhbi1kcmFmdC4NCkFuZCBpdCdzIGFyZ3VhYmx5 IGVhc2llciB0byBpbXBsZW1lbnQsIGZvciB0aGUgY29tbW9uIGNhc2VzLg0KDQpJICp0aGlu ayogdGhlcmUgd2FzIGEgcmVhc29uIHNvbWVvbmUgY2FtZSB1cCB3aXRoIGF0IG9uZSB0aW1l IGFzIHRvIHdoeSBpdCBoYWQgdG8gYmUgc3dhcHBlZCwgYnV0IEkgZG9uJ3QgcmVtZW1iZXIg d2hhdCBpdCBpcyBhbmQgSSBkb24ndCBzZWUgaXQgaW4gdGhlIGRyYWZ0LiAgU28gSSdtIHRy eWluZyB0byBmaW5kIG91dCB3aHkgd2UgbmVlZCB0byBkbyBpdCB0aGUgd2F5IHRoZSBkcmFm dCBjdXJyZW50bHkgaGFzIGl0Lg0KDQpUaGUgb3RoZXIgdG9waWMgb2Ygd2hldGhlciBTQkNz IHdpbGwgY2hhbmdlIHRoaW5ncyBpcyBjb21wbGV0ZWx5IG9ydGhvZ29uYWwgdG8gdGhlIG9y ZGVyaW5nIG9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGlzc3VlcywgYW5kIHJlYWxseSBz aG91bGRuJ3QgYmUgY29uZmxhdGVkIHdpdGggaXQgYXQgYWxsLiAgSXQgaGFzIG5vdGhpbmcg dG8gZG8gd2l0aCB0aGUgc29sdXRpb25zIGRvY3VtZW50LCBvciB0aGUgZGlyZWN0aW9uIHN0 dWZmLCBldGMuDQoNCi1oYWRyaWVsDQoNCg0KT24gQXVnIDEsIDIwMTMsIGF0IDEyOjM4IEFN LCBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFja2V0aXplci5jb208bWFpbHRvOnBhdWxlakBw YWNrZXRpemVyLmNvbT4+IHdyb3RlOg0KDQo+IEZvbGtzLA0KPg0KPiBJIHN0ZXAgYXdheSBm b3IgYSBjb3VwbGUgb2YgZGF5cyBhbmQgdGhlIGZsb29kZ2F0ZSBvcGVucy4gOikNCj4NCj4g SSB0aGluayBpdCdzIGltcG9ydGFudCB0byB1bmRlcnN0YW5kIHdoeSB3ZSBwcm9wb3NlZCB1 c2luZyBhIHR3by1wYXJ0DQo+IFNlc3Npb24gSWRlbnRpZmllci4gIFRoZSByZWFzb24gaXMg dGhhdCB3ZSBoYXZlIHRvIGJlIGFibGUgdG8gZWZmZWN0aXZlbHkNCj4gZGVhbCB3aXRoIHRo aW5ncyBsaWtlIGZvcmtpbmcsIGNhbGwgdHJhbnNmZXIsIHBhcmssIGJyaWRnaW5nLCBjb25m ZXJlbmNpbmcsDQo+IGV0Yy4NCj4NCj4gV2hlbiBpbml0aWF0aW5nIGEgY2FsbCBhbmQgdXNp bmcgYSBzaW5nbGUgVVVJRCB2YWx1ZSwgdGhhdCBoYXMgdGhlIHBvdGVudGlhbA0KPiB0byBn byBlbmQtdG8tZW5kLiBIb3dldmVyLCBpZiBhIGNhbGwgaXMgZm9ya2VkIHRoZXJlIGFyZSBt dWx0aXBsZSAiZW5kcyIuDQo+IEhvdyBkbyB3ZSB0cmFjayBlYWNoIG9mIHRob3NlPyAgRm9y IHByb3BlciBkaWFnbm9zdGljcyBhbmQgdHJvdWJsZXNob290aW5nLA0KPiBpdCB3b3VsZCBi ZSBpZGVhbCB0byBiZSBhYmxlIHRvIGlkZW50aWZ5IHdoaWNoIGRldmljZXMgaGF2ZSBhbiBp c3N1ZS4NCj4NCj4gT25jZSBhIGNhbGwgaGFzIGJlZW4gcGxhY2VkLCB0aGVyZSBpcyBhIFNl c3Npb24tSUQgZXN0YWJsaXNoZWQgYmV0d2VlbiBBbGljZQ0KPiBhbmQgQm9iLiAgSWYgQWxp Y2UgKGluIG9uZSBjb3VudHJ5KSB0cmFuc2ZlcnMgQm9iIChwZXJoYXBzIGluIHRoZSBzYW1l IG9yDQo+IGRpZmZlcmVudCBjb3VudHJ5KSB0byBhIHNvbWUgbG9jYXRpb24gaW4gYSBoaWdo LXRvbGwgY291bnRyeSwgd2hvIHBheXMgdGhlDQo+IGJpbGw/ICBXZWxsLCB0byBhZGRyZXNz IHRoYXQsIHdlIGRvIGNhbGwgdHJhbnNmZXIgbG9jYWxseSBvbiBQQlhlcy4gIFRoZSBQQlgN Cj4gbWFpbnRhaW5zIGNvbnRyb2wgb3ZlciB0aGUgY2FsbCBhbmQgQWxpY2Ugd291bGQgcGF5 IHRoZSBiaWxsIGZvciB0aGUgY2FsbA0KPiB0cmFuc2Zlci4gIEJ1dCBpZiBBbGljZSB3YXMg dGFsa2luZyB0byBDYXJvbCBiZWZvcmUgdGhlIHRyYW5zZmVyLCB0aGVyZSBpcyBhDQo+IFNl c3Npb24tSUQgZm9yIHRoYXQgY2FsbC4gIElmIEJvYiBpcyBwdXQgaW4gY29tbXVuaWNhdGlv biB3aXRoIENhcm9sLCB3aGF0DQo+IGlzIHRoZSBTZXNzaW9uLUlEIHZhbHVlPyAgQm9iIGhh ZCBvbmUgYW5kIENhcm9sIGhhZCBhIGRpZmZlcmVudCBvbmUuICBXaGF0DQo+IGlzIHRoZSBu ZXcgSUQ/DQo+DQo+IEl0J3MgaXNzdWVzIGxpa2UgdGhpcyB0aGF0IGxlZCB1cyB0byB1c2lu ZyBhIHR3by1wYXJ0IHZhbHVlLiAgSW4gdGhpcyB3YXksDQo+IHdlIGNvdWxkIHNlZSB0aGUg Y2FsbCBmcm9tIEFsaWNlIHRvIEJvYiBoYXMgYSBTZXNzaW9uLUlEIHtBLEJ9LiAgSWYgQWxp Y2UNCj4gdHJhbnNmZXJzIHRoZSBjYWxsIHRvIENhcm9sLCBlYWNoIGRldmljZSB1bmRlcnN0 YW5kcyB0aGF0IHRoZSBTZXNzaW9uLUlEDQo+IGNoYW5nZWQgdG8ge0IsQ30uICBOb3Qgb25s eSB0aGF0LCBidXQgaW50ZXJtZWRpYXJpZXMgYWxvbmcgdGhlIHBhdGggdGhhdA0KPiB3ZXJl IG5vdCBwcml2eSB0byBzaWduYWxpbmcgdGhhdCByZXN1bHRlZCBpbiB0aGlzIGNoYW5nZSBj YW4gdGFrZSBub3RlIG9mDQo+IHRoZSBmYWN0IHRoZSB2YWx1ZSBjaGFuZ2VkLiAgVGhpcyBj YW4gcHJvdmlkZSBhIHVzZWZ1bCBoaXN0b3JpY2FsIHJlY29yZCwNCj4gc2luY2UgcHJldmlv dXNseSB0aGV5IG1pZ2h0IHNlZSBhIGNhbGwgdG8gQ2Fyb2wgaWRlbnRpZmllZCBhcyB7QSxD fSwgYnV0DQo+IHRoZW4gaXQgY2hhbmdlZCB0byB7QixDfS4NCj4NCj4gVGhpcyBwcm9wZXJ0 eSBleHRlbmRzIHF1aXRlIG5hdHVyYWxseSB0byBvdGhlciBzaWduYWxpbmcgc2NlbmFyaW9z LCBhcyBpdA0KPiBhbGxvd3Mgb25lIHRvIGlkZW50aWZ5IGEgY2FsbCBlbmQtdG8tZW5kLCBi dXQgYWxzbyBlc3RhYmxpc2ggc29tZQ0KPiByZWxhdGlvbnNoaXAgYmV0d2VlbiBvdGhlciBj YWxscyB0aGF0IHNoYXJlZCBhdCBsZWFzdCBvbmUgVVVJRCB2YWx1ZSBvdXQgb2YNCj4gdGhl IHR3by4NCj4NCj4gSGFkcmllbCBtZW50aW9uZWQgdGhlIGRlc2lyZSB0byB1c2UgdGhlIFNl c3Npb24tSUQgdG8gY29ycmVsYXRlIG1lZGlhIGZsb3dzDQo+IGFuZCBjYWxscy4gIFRoYXQn cyBjZXJ0YWlubHkgc29tZXRoaW5nIENpc2NvIHdvdWxkIGxpa2UgdG8gZG8sIGJ1dCBpdCBp cyBub3QNCj4gdGhlIGRyaXZlciBiZWhpbmQgdGhlIHNvbHV0aW9uLiAgSGF2aW5nIGEgdmFs aWQgZW5kLXRvLWVuZCBpZGVudGlmaWVyIChpbg0KPiB3aGF0ZXZlciBmb3JtKSBhbGxvd3Mg dXMgdG8gZG8gdGhhdC4gIFdlJ3JlIG5vdCBzdWdnZXN0aW5nIHRvIGZpdCB0aGUNCj4gc29s dXRpb24gdG8gbWVldCB0aGF0IGJ1c2luZXNzIHVzZSBjYXNlLCBidXQgcmF0aGVyIHdlIGp1 c3Qgd2FudCBhIHNvbHV0aW9uDQo+IHRoYXQgYWxsb3dzIHVzIHRvIHByb3Blcmx5IGlkZW50 aWZ5IGNhbGxzIGVuZC10by1lbmQgYW5kIHdlIHJlY29nbml6ZSB0aGF0LA0KPiBkdWUgdG8g dmFyaW91cyBzZXJ2aWNlIGludGVyYWN0aW9ucyBpbiB0aGUgbmV0d29yaywgdGhlc2UgVVVJ RCB2YWx1ZXMgY2FuDQo+IGNoYW5nZS4NCj4NCj4gSSB3b3VsZCBob3BlIHRoYXQgVVVJRCB2 YWx1ZXMgd2lsbCBub3QgY2hhbmdlIHRvIHRoZSBleHRlbnQgdGhhdCBTQkNzIGNoYW5nZQ0K PiB0aGVtIGZvciBidXNpbmVzcyByZWFzb25zLiAgSXQgd291bGQgY2VydGFpbmx5IGRlZmVh dCB0aGUgcG9pbnQuICBIYWRyaWVsDQo+IG1pZ2h0IGJlIHJpZ2h0IHRoYXQgYW4gU0JDIHZl bmRvciBtaWdodCBtYW5pcHVsYXRlIHRob3NlIHZhbHVlcyBhdCB0aGUNCj4gcmVxdWVzdCBv ZiBhIGN1c3RvbWVyLCBidXQgSSB3b3VsZCBob3BlIHNhaWQgY3VzdG9tZXIgYXBwcmVjaWF0 ZXMgdGhhdCBzdWNoDQo+IGEgcmVxdWVzdCBlZmZlY3RpdmVseSBicmVha3MgdGhlIGVuZC10 by1lbmQgbW9kZWwuICBXZSBjYW4ndCBkbyBtdWNoIGFib3V0DQo+IHRoYXQgaWYgdGhleSBk byBnbyBkb3duIHRoYXQgcGF0aC4NCj4NCj4gQXMgZm9yIGJhY2t3YXJkLWNvbXBhdGliaWxp dHksIHRoZSBzaW1wbGVzdCBhcHByb2FjaCAoSU1PKSBpcyB0byBqdXN0IHVzZSBhDQo+IGhl YWRlciB2YWx1ZSBub3QgYWxyZWFkeSBpbiB1c2UuICBPcmlnaW5hbGx5LCB3ZSBoYWQgcHJv cG9zZWQgU2Vzc2lvbi1VVUlELg0KPiBUaGF0IHdhcyBjaGFuZ2VkIGF0IHRoZSByZXF1ZXN0 IG9mIHRoZSBncm91cCB0byBiZSBTZXNzaW9uLUlELiAgSG93ZXZlciwNCj4gd2hlbiB3ZSBo YXZlIGEgdHdvIFVVSUQgc29sdXRpb24gaW50ZXJhY3Rpbmcgd2l0aCBhIG9uZS1VVUlEIHNv bHV0aW9uLCB3ZQ0KPiBpbW1lZGlhdGVseSBmYWNlIHNvbWUgY2hhbGxlbmdlcy4NCj4NCj4g V2hhdCBoYXBwZW5zIGlmIGFuIG9sZGVyIHN5c3RlbSBzZW5kcyB0aGlzOg0KPiAgU2Vzc2lv bi1JRDogWA0KPiBCdXQgdGhlbiByZWNlaXZlcyB0aGlzOg0KPiAgU2Vzc2lvbi1JRDogWTsg cmVtb3RlPVgNCj4NCj4gRG9lcyB0aGlzIGJyZWFrIHRoaW5ncz8gIElmIHNvLCBob3cgZG8g Y3VycmVudCBpbXBsZW1lbnRhdGlvbnMgZGVhbCB3aXRoDQo+IHN1Y2ggdGhpbmdzIGFzIG1p ZC1jYWxsIHRyYW5zZmVycyB0aGF0IGhhcHBlbiBvbiBhIFBCWCBsaWtlIHRoZSBvbmUgSQ0K PiBkZXNjcmliZWQgYWJvdmU/DQo+DQo+IFdlIGNvdWxkIHN3aXRjaCB0aGUgb3JkZXIgbGlr ZSB0aGlzOg0KPiAgU2Vzc2lvbi1JRDogWDsgcmVtb3RlPVkNCj4NCj4gSG93ZXZlciwgdGhh dCBkb2VzIG5vdCB3b3JrIGZvciBzaW1pbGFyIHJlYXNvbnMuICBJZiB3ZSBoYXZlIGEgY2Fs bCB0cmFuc2Zlcg0KPiB3aGVyZSBBbGljZSB0cmFuc2ZlcnMgYSBjYWxsIHdpdGggQm9iIHRv IENhcm9sLCB0aGVuIGVhY2ggaGFzIGEgZGlmZmVyZW50DQo+IGlkZWEgYWJvdXQgd2hhdCB0 aGUgcHJvcGVyIHZhbHVlIGlzIGZvciB0aGUgZmlyc3QgcG9zaXRpb24uDQo+DQo+IE9yaWdp bmFsbHksIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBkaWQgbm90IGluZGljYXRlIHBvc2l0aW9u IGluZm9ybWF0aW9uIGFuZA0KPiBqdXN0IGhhZCBzaW5nbGUgVVVJRCB2YWx1ZXMgZ29pbmcg aW4gZWFjaCBkaXJlY3Rpb24uICBXZSB0aGVuIHByb3Bvc2VkIGENCj4gY29uY2F0ZW5hdGVk IHN0cmluZyAoWDpZKS4gSG93ZXZlciwgdGhhdCBwcmVzZW50ZWQgdGhlIHNhbWUgaXNzdWVz IGZvciB0aGUNCj4gY2FsbCB0cmFuc2ZlciBjYXNlLCBzbyB3ZSBpbmRpY2F0ZSB2YWx1ZXMg YnkgcG9zaXRpb24gKHNlbmRlcidzIHZhbHVlDQo+IGZpcnN0KSwgc28gaXQgaXMgY2xlYXIg d2hhdCB2YWx1ZSB0aGUgcmVjZWl2ZSB0aGlua3MgdGhlIHJlbW90ZSBlbmQgaGFzIGZvcg0K PiB0aGUgbG9jYWwgZW5kLiAgSXQgbWlnaHQgYmUgd3JvbmcsIGJ1dCB0aGF0IHdpbGwgYmUg Y29ycmVjdGVkIGluIHRoZQ0KPiBmb2xsb3dpbmcgcmVzcG9uc2UuIChJbnRlcm1lZGlhcmll cyBjYW4gdGFrZSBub3RlIG9mIHRoZSBjaGFuZ2UuKQ0KPg0KPiBTbywgdGhhdCdzIHdoeSB3 ZSBhcmUgd2hlcmUgd2UgYXJlLiAgVGhlcmUgaGFzIGJlZW4gYW4gZWZmb3J0IHRvIG1haW50 YWluDQo+IGJhY2t3YXJkLWNvbXBhdGliaWxpdHksIGJ1dCB0aGVyZSBhcmUgY2hhbGxlbmdl cyBpbiBtZWV0aW5nIHRoYXQNCj4gcmVxdWlyZW1lbnQuICBXaGVyZSBpdCBmYWxscyBzaG9y dCwgd2UgZG8gbm90IGtub3c6IHdlJ3ZlIG5vdCBiZWVuIHRvbGQNCj4gZXhwbGljaXRseSB3 aGF0IHRoZSBpc3N1ZXMgYXJlLiAgRnVydGhlciwgaWYgdGhlcmUgYXJlIHN1Y2ggaXNzdWVz LCB3ZSBuZWVkDQo+IHRvIGFsc28gdW5kZXJzdGFuZCBob3cgdGhvc2Ugd291bGQgYmUgaGFu ZGxlZCBpbiB0aGUgZmFjZSBvZiBjYWxsIHRyYW5zZmVyDQo+IG9yICJqb2luaW5nIiBhIGNh bGwgbG9jYWxseSBvbiBhIFBCWC4gIFRob3NlIGFyZSByZWFsLXdvcmxkIHNjZW5hcmlvcyB0 aGF0DQo+IHdlIG11c3QgYWRkcmVzcy4NCj4NCj4gQW55d2F5LCBub3RoaW5nIGlzIHNldCBp biBzdG9uZS4gIEFueXRoaW5nIGNhbiBiZSBjaGFuZ2VkLCBidXQgSSB3b3VsZCBob3BlDQo+ IHdlIGNhbiBmaW5kIGEgc29sdXRpb24gdGhhdCB3b3JrcyBmb3IgdGhlIGVudGVycHJpc2Ug dXNlIGNhc2VzIGFzIHdlbGwgYXMNCj4gdGhlIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3Mu DQo+DQo+IFBhdWwNCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gaW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4gaW5zaXBpZEBpZXRm Lm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pbnNpcGlkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQppbnNpcGlkIG1haWxpbmcgbGlzdA0KaW5zaXBpZEBp ZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0 cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5n IG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBh cHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3Jt YXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhh biB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkg cmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5 b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJv ZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMg aXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFs IChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50 IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1 YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9u ZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1h dGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv biwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQg cmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K --_000_BBF5DDFE515C3946BC18D733B20DAD2338DF0B33XMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxuczpuczA9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1 aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4N CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZp bHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVo YXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxvOlNt YXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOnNtYXJ0dGFncyIgbmFtZT0iQ2l0eSIgLz48bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNl dXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIG5hbWU9 InBsYWNlIiAvPjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0idGltZSIgLz48bzpTbWFydFRh Z1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpz bWFydHRhZ3MiIG5hbWU9InN0b2NrdGlja2VyIiAvPjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3Bh Y2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFt ZT0iZGF0ZSIgLz48IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT48c3R5bGU+DQo8 IS0tYTpsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTt9DQpzcGFuLk1TT0hZUEVSTElO Sw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7fQ0KYTp2aXNpdGVkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTt9DQpzcGFuLk1TT0hZUEVSTElOS0ZPTExPV0VEDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTt9DQpwLk1TT0xJU1RQQVJBR1JBUEgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0O30NCmxpLk1TT0xJU1RQQVJBR1JBUEgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0O30N CmRpdi5NU09MSVNUUEFSQUdSQVBIDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDt9DQoNCiAv KiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMg TWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1p bmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbGlzdHBhcmFncmFw aCwgbGkubXNvbGlzdHBhcmFncmFwaCwgZGl2Lm1zb2xpc3RwYXJhZ3JhcGgNCgl7bWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5hdnk7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PGJyPg0KSSBkb24ndCBzZWUgdGhhdCB3ZSBldmVyIG5lZWQgdG8gZ2V0IGludG8gdGhh dCBzaXR1YXRpb24uPGJyPg0KPGJyPg0KQXMgd2UgZGlzY3Vzc2VkIHllc3RlcmRheSB3ZSBo YXZlIHR3byBwYXJ0cy4gVGhlIGhlYWRlciBmaWVsZCBwYXJ0IGFuZCB0aGUgaGVhZGVyIHBh cmFtZXRlciBwYXJ0KHMpLjxicj4NCjxicj4NCkluIG9yZGVyIHRvIGJlIGNvbXBhdGlibGUg d2l0aCB0aGUga2FwbGFuIGRyYWZ0IHRoZSBoZWFkZXIgZmllbGQgcGFydCBpcyBpbnNlcnRl ZCBieSB0aGUgcGFydHkgdGhhdCBmaXJzdCBpbmNsdWRlcyB0aGUgc2Vzc2lvbiBJRCBhbmQg dGhpcyB2YWx1ZSBNVVNUIE5PVCBiZSBtb2RpZmllZC4gVGhlIGhlYWRlciBwYXJhbWV0ZXIg cGFydCBvciBwYXJ0cyBjYW4gYmUgY2hhbmdlZCBhcyBtdWNoIGFzIHlvdSBsaWtlIGFuZCBz dGlsbCBiZSBiYWNrd2FyZA0KIGNvbXBhdGlibGUgd2l0aCBrYXBsYW4uPGJyPg0KPGJyPg0K SWYgd2UgbmVlZCB0byByZXZlcnNlIG9yZGVycyBvciBvdGhlcndpc2UgbW9kaWZ5IHNlc3Np b24gSURzIGxldCdzIGRlZmluZWQgYWRkaXRpb25hbCBoZWFkZXIgcGFyYW1ldGVycyB0aGF0 IGNhbiBiZSBjaGFuZ2VkIHVuZGVyIGNlcnRhaW4gc2l0dWF0aW9ucyBkdXJpbmcgYSBzZXNz aW9uIHdoaWxlIGxlYXZpbmcgdGhlIGhlYWRlciBmaWVsZCB2YWx1ZSB1bmNoYW5nZWQuIFRo YXQgd2F5IHdlIGNhbiBoYXZlIG91ciBjYWtlIGFuZCBlYXQgaXQuPGJyPg0KPGJyPg0KQW5k cmV3PC9mb250Pjxicj4NCiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48Yj5Gcm9tPC9iPjogRFJBR0Us IEtlaXRoIChLZWl0aCkgW21haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb21d DQo8YnI+DQo8Yj5TZW50PC9iPjogRnJpZGF5LCBBdWd1c3QgMDIsIDIwMTMgMDU6MjMgQU0g Q2VudHJhbCBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBBbmRyZXcgQWxsZW47IHBh dWxlakBwYWNrZXRpemVyLmNvbSAmbHQ7cGF1bGVqQHBhY2tldGl6ZXIuY29tJmd0OzsgbGF1 cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb20gJmx0O2xhdXJhLmxpZXNzLmR0QGdvb2dsZW1h aWwuY29tJmd0OzsgaW5zaXBpZEBpZXRmLm9yZyAmbHQ7aW5zaXBpZEBpZXRmLm9yZyZndDsN Cjxicj4NCjxiPlN1YmplY3Q8L2I+OiBSRTogW0luc2lwaWRdIFByb3Bvc2VkIElOU0lQSUQg c29sdXRpb24gYW5kIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkNCjxicj4NCjwvZm9udD4mbmJz cDs8YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IlNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 Ij5BcyBXRyBjaGFpcjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpu YXZ5Ij5UaGF0IGNvcnJlc3BvbmRzIHRvIG15IHVuZGVyc3RhbmRpbmcsIHdpdGggb25lIGNh dmVhdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij5JZiB0 aGUgY29tcGF0aWJpbGl0eSBwcmV2ZW50cyB0aGUgc29sdXRpb24gZG9jdW1lbnQgbWVldGlu ZyBhIHJlcXVpcmVtZW50IGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnQsIHRoZW4gdGhhdCBw cm9iYWJseSBvdmVycmlkZXMgdGhlDQogY29tcGF0aWJpbGl0eSBhZ3JlZW1lbnQgdG8gdGhl IGV4dGVudCB0aGF0IHdlIG5lZWQgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnQuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0K MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPlJlZ2FyZHM8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0K MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+S2VpdGg8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+DQo8aHIgc2l6ZT0iMiIgd2lk dGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiIHRhYmluZGV4PSItMSI+DQo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i VGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48 L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hIj4gQW5kcmV3IEFsbGVu DQogW21haWx0bzphYWxsZW5AYmxhY2tiZXJyeS5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IDAyIEF1Z3VzdCAyMDEzIDA4 OjU2PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48 L2I+IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBwYXVsZWpAcGFja2V0aXplci5jb207IGxhdXJh LmxpZXNzLmR0QGdvb2dsZW1haWwuY29tOyBpbnNpcGlkQGlldGYub3JnPGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtJ bnNpcGlkXSBQcm9wb3NlZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBiYWNrd2FyZCBjb21wYXRp YmlsaXR5PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjoj MUY0OTdEIj48YnI+DQpQdXR0aW5nIGl0IGFub3RoZXIgd2F5Ojxicj4NCjxicj4NClRoaW5n cyB0aGF0IHdvcmsgd2l0aCB0aGUga2FwbGFuIGRyYWZ0IHNob3VsZCBjb250aW51ZSB0byB3 b3JrIHdoZW4gYSBrYXBsYW4gY29tcGxpYW50IGltcGxlbWVudGF0aW9uIGludGVyd29ya3Mg d2l0aCB0aGUgV0cgc29sdXRpb24gY29tcGxpYW50IGltcGxlbWVudGF0aW9ucy4NCjxicj4N Cjxicj4NClRoaW5ncyB0aGF0IGRvbid0IHdvcmsgd2l0aCB0aGUga2FwbGFuIGRyYWZ0IGFy ZSBub3QgZXhwZWN0ZWQgdG8gd29yayB3aGVuIGEga2FwbGFuIGNvbXBsaWFudCBpbXBsZW1l bnRhdGlvbiBpbnRlcndvcmtzIHdpdGggdGhlIFdHIHNvbHV0aW9uIGNvbXBsaWFudCBpbXBs ZW1lbnRhdGlvbnMgaG93ZXZlciB0aGUgZGVncmFkZWQgYmVoYXZpb3Igc2hvdWxkIGJlIG5v IHdvcnNlIHRoYW4gYmV0d2VlbiBrYXBsYW4gY29tcGxpYW50IGltcGxlbWVudGF0aW9ucy48 YnI+DQo8YnI+DQpBbmRyZXc8L3NwYW4+PC9mb250Pjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkIj5Gcm9t PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPjogRFJBR0UsIEtl aXRoIChLZWl0aCkgW21haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb21dDQo8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDwvc3Bhbj48L2I+ OiBGcmlkYXksIDxzdDE6ZGF0ZSBZZWFyPSIyMDEzIiBEYXk9IjAyIiBNb250aD0iOCIgbHM9 InRyYW5zIiB3OnN0PSJvbiI+DQpBdWd1c3QgMDIsIDIwMTM8L3N0MTpkYXRlPiAwMjo0MyBB TSBDZW50cmFsIFN0YW5kYXJkIFRpbWU8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+VG88L3NwYW4+PC9iPjogUGF1bCBFLiBKb25lcyAmbHQ7cGF1bGVqQHBhY2tl dGl6ZXIuY29tJmd0OzsgJ0xhdXJhIExpZXNzJyAmbHQ7bGF1cmEubGllc3MuZHRAZ29vZ2xl bWFpbC5jb20mZ3Q7OyBpbnNpcGlkQGlldGYub3JnICZsdDtpbnNpcGlkQGlldGYub3JnJmd0 Ow0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q8L3Nw YW4+PC9iPjogUmU6IFtJbnNpcGlkXSBQcm9wb3NlZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBi YWNrd2FyZCBjb21wYXRpYmlsaXR5DQo8YnI+DQo8L3NwYW4+PC9mb250PiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+TGV0IHVzIGdldCB0aGlzIGNs ZWFyLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij5UaGUg S2FwbGFuIGRyYWZ0IGlzIG5vdCBleHBlY3RlZCB0byBtZWV0IGFsbCB0aGUgcmVxdWlyZW1l bnRzLiBJZiBpdCBkaWQsIHdlIHdvdWxkIHByb2JhYmx5IGJlIHByb2dyZXNzaW5nIGl0IGFz IHRoZSBzb2x1dGlvbiBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2eSIgZmFj ZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBmYWNl PSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjpuYXZ5Ij5XaGF0IHRoZSBwcmV2aW91cyBkZWNpc2lvbiBvZiB0aGUgd29y a2luZyBncm91cCBlZmZlY3RpdmVseSByZXF1aXJlZCwgd2hlbiBpdCBkZXNpcmVkIGNvbXBh dGliaWxpdHksIHdhcyB0aGF0IHNlbnNpYmxlIHRoaW5ncyBzaG91bGQNCiBoYXBwZW4gYXMg ZmFyIGFzIHBvc3NpYmxlIHdoZW4gdGhlIHR3byBzb2x1dGlvbnMgaW50ZXJvcGVyYXRlZC4g VGhlcmUgaXMgYWxzbyBubyBpbXBsaWNhdGlvbiB0aGF0IHdoZW4gS2FwbGFuIGRyYWZ0IG1l ZXRzIFdHIHNvbHV0aW9uIHRoYXQgYWxsIHRoZSByZXF1aXJlbWVudHMgYXJlIG1ldC48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9Im5hdnkiIGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0ibmF2eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+VGhlIGRlc2lyZSBm b3IgY29tcGF0aWJpbGl0eSBpcyBiYXNlZCBvbiB0aGUgZmFjdCB0aGF0IHRoZSBwcmV2aW91 cyBzb2x1dGlvbiBpcyBvdXQgdGhlcmUgaW4gdGhlIGZpZWxkLiBPbmUgc29sdXRpb24gd2ls bCBtZWV0IHRoZSBvdGhlci4NCiBPbmUgc29sdXRpb24gc2hvdWxkIG5vdCBib21iIHRoZSBv dGhlciBvbmUgb3V0LiBJbXBsZW1lbnRvcnMgb2YgdGhlIEthcGxhbiBzb2x1dGlvbiB3aWxs IG1pZ3JhdGUgdG8gdGhlIHJlYWwgc29sdXRpb24gYXQgc29tZSBwb2ludCBhbmQgdGhhdCBp bnRlbnQgaGFzIGJlZW4gZXhwcmVzc2VkIGluIHRoZSBtZWV0aW5nIHNldmVyYWwgdGltZXMu IEJ1dCB0aGF0IG1pZ3JhdGlvbiB3aWxsIG5vdCBoYXBwZW4gb3Zlcm5pZ2h0IGFzIHNvb24g YXMgdGhlDQogV0cgUkZDcyBhcmUgcHVibGlzaGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0ibmF2 eSIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5 IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5 IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9Im5hdnki IGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm5hdnkiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJuYXZ5IiBm YWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpuYXZ5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGln bj0iY2VudGVyIiB0YWJpbmRleD0iLTEiPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9t YTtmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9 IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSI+IGluc2lwaWQtYm91bmNlc0BpZXRmLm9yZw0K IFttYWlsdG86aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mDQo8L3NwYW4+PC9iPlBhdWwgRS4gSm9uZXM8 YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9i PiAwMSBBdWd1c3QgMjAxMyAxNjowMDxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5Ubzo8L3NwYW4+PC9iPiAnTGF1cmEgTGllc3MnOyBpbnNpcGlkQGlldGYub3Jn PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFu PjwvYj4gUmU6IFtJbnNpcGlkXSBQcm9wb3NlZCBJTlNJUElEIHNvbHV0aW9uIGFuZCBiYWNr d2FyZCBjb21wYXRpYmlsaXR5PC9zcGFuPjwvZm9udD48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6DQoxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+TGF1cmEsPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOiMxRjQ5N0QiPkkgYXNzZXJ0IHRoYXQgb2xkIGRyYWZ0IHdpbGwgbm90IHdv cmsgZm9yIHNvbWUg4oCccmVhbC13b3JsZOKAnSBjYWxscy4mbmJzcDsgQ2FsbHMgZG8gZ2V0 IG1hbmlwdWxhdGVkIGluIGVudGVycHJpc2UgZW52aXJvbm1lbnRzDQogYW5kIGNhbGwgY2Vu dGVycyBmb3IgYmlsbGluZyBwdXJwb3NlcywgcHJpdmFjeSByZWFzb25zLCBldGMuPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPkNvbnNpZGVyIGEgY29tbW9uIGNhc2U6IGlm IHlvdSBjYWxsIGludG8gYSBjYWxsIGNlbnRlciBhbmQgdGhlIGFnZW50IHB1dHMgeW91IG9u IGhvbGQgd2hpbGUgdGhleSB0cmFuc2ZlciB5b3UgdG8NCiBhIHNwZWNpYWxpc3QgKHRyYW5z ZmVyIG91dCBvZiBjb25zdWx0YXRpb24pLCBmb3IgZXhhbXBsZSwgeW91ciBTSVAgVUEgZG9l cyA8aT48c3BhbiBzdHlsZT0iZm9udC1zdHlsZTppdGFsaWMiPm5vdDwvc3Bhbj48L2k+IHJl Y2VpdmUgYSBSRUZFUiB0byBpbml0aWF0ZSBhIG5ldyBjYWxsIGRpcmVjdGx5IHRvIHRoZSBz cGVjaWFsaXN0LiZuYnNwOyBUaGlzIGlzIGhhbmRsZWQgYXQgdGhlIGNhbGwgY2VudGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5TbyByYXRoZXIgc3BlY2lmaWNhbGx5 LCBob3cgd291bGQgdGhpcyBiZSBoYW5kbGVkICh3aXRoIHRoZSBvbGQgZHJhZnQpPzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj4xKQ0KPHN0MTpwbGFjZSB3OnN0PSJvbiI+ PHN0MTpDaXR5IHc6c3Q9Im9uIj5BbGljZTwvc3QxOkNpdHk+PC9zdDE6cGxhY2U+IGNhbGxz IEJvYiAoU2Vzc2lvbi1JRDogQSk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjIpIEJvYiBwdXRzDQo8c3QxOnBs YWNlIHc6c3Q9Im9uIj48c3QxOkNpdHkgdzpzdD0ib24iPkFsaWNlPC9zdDE6Q2l0eT48L3N0 MTpwbGFjZT4gb24gaG9sZCBhbmQgY2FsbHMgQ2Fyb2wgKFNlc3Npb24tSUQ6IEIpPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjoj MUY0OTdEIj4zKSBCb2IgdHJhbnNmZXJzIHRoZSBjYWxsIGZyb20NCjxzdDE6cGxhY2Ugdzpz dD0ib24iPjxzdDE6Q2l0eSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNl PiB0byBDYXJvbCB1c2luZyBhIGxvY2FsIHRyYW5zZmVyIGZ1bmN0aW9uIG9uIHRoZSBQQlgg KFNlc3Npb24tSUQ6ID8/KTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjojMUY0OTdEIj5UaGUg UEJYIGNvdWxkIHNlbmQgZGlmZmVyZW50IHZhbHVlcyB0byBBbGljZSBhbmQgQ2Fyb2wsIGJ1 dCB3ZSB0b3RhbGx5IGxvc2UgdGhlIGVuZC10by1lbmQgaWRlbnRpZmljYXRpb24gb2YgdGhl DQogY2FsbC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpD YWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOkNp dHkgdzpzdD0ib24iPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7DQogIGZv bnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+QWxpY2U8L3NwYW4+PC9mb250Pjwv c3QxOkNpdHk+PC9zdDE6cGxhY2U+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDsNCmZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+DQogY291bGQgbm90IHNl bmQg4oCcQeKAnSB0byBDYXJvbCwgc2luY2UgQ2Fyb2wgaXMgZXhwZWN0aW5nIEIuJm5ic3A7 IExpa2V3aXNlLCBDYXJvbCBjYW5ub3Qgc2VuZCDigJxC4oCdIHRvDQo8c3QxOkNpdHkgdzpz dD0ib24iPkFsaWNlPC9zdDE6Q2l0eT4sIHNpbmNlIDxzdDE6cGxhY2UgdzpzdD0ib24iPjxz dDE6Q2l0eSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNlPiBpcyBleHBl Y3Rpbmcg4oCcQeKAnS4mbmJzcDsgV2VsbCwgdGhleSBjb3VsZCwgYW5kIGl0IHdvdWxkIGJl IG5vIHdvcnNlIHRoYW4gb3VyIGN1cnJlbnQgcHJvcG9zYWwgaW4gdGVybXMgb2YgYmFja3dh cmQtY29tcGF0aWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpDYWxpYnJpO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6IzFGNDk3RCI+UGF1 bDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i VGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48 L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hIj4gaW5zaXBpZC1ib3Vu Y2VzQGlldGYub3JnDQogW21haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmddIDxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYgT2YNCjwvc3Bhbj48L2I+ TGF1cmEgTGllc3M8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2Vu dDo8L3NwYW4+PC9iPiBUaHVyc2RheSwgPHN0MTpkYXRlIFllYXI9IjIwMTMiIERheT0iMDEi IE1vbnRoPSI4IiBscz0idHJhbnMiIHc6c3Q9Im9uIj4NCkF1Z3VzdCAwMSwgMjAxMzwvc3Qx OmRhdGU+IDxzdDE6dGltZSBNaW51dGU9IjEzIiBIb3VyPSI5IiB3OnN0PSJvbiI+OToxMyBB TTwvc3QxOnRpbWU+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv Ojwvc3Bhbj48L2I+IGluc2lwaWRAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW0luc2lwaWRdIFByb3Bv c2VkIElOU0lQSUQgc29sdXRpb24gYW5kIGJhY2t3YXJkIGNvbXBhdGliaWxpdHk8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48YnI+DQpIYWRyaWVsJ3MgcHJvcG9zYWwgd29ya3MgZm9y IHVzLiA8YnI+DQo8YnI+DQpUaGFuayB5b3U8Zm9udCBjb2xvcj0iIzg4ODg4OCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCkxhdXJhPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4yMDEzLzgv MSBIYWRyaWVsIEthcGxhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhZHJpZWwua2FwbGFuQG9y YWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5oYWRyaWVsLmthcGxhbkBvcmFjbGUuY29tPC9h PiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NClRoaXMgaXNuJ3QgYWJvdXQg PHN0MTpwbGFjZSB3OnN0PSJvbiI+PHN0MTpDaXR5IHc6c3Q9Im9uIj5FbnRlcnByaXNlPC9z dDE6Q2l0eT48L3N0MTpwbGFjZT4gdnMuIFNlcnZpY2UtUHJvdmlkZXIsIG9yIENpc2NvIHZz LiBhbm90aGVyIHZlbmRvci4gJm5ic3A7VGhpcyBpcyBqdXN0IGFib3V0IGEgV29ya2luZyBH cm91cCBkb2N1bWVudCwgYW5kIHdoZXRoZXIgdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGluIGl0 IHNob3VsZCBjaGFuZ2UgdGhlIFNlc3Npb24tSUQNCiBoZWFkZXIgdmFsdWUgdnMuIHBhcmFt ZXRlciBiYXNlZCBvbiBkaXJlY3Rpb24gb2YgbWVzc2FnZXMsIG9yIG5vdC4gJm5ic3A7SSB0 b3RhbGx5IGdldCB0aGUgbmVlZCB0byBoYXZlIGEgZGlzdGluZ3Vpc2hpbmcgU2Vzc2lvbi1J RCBpZGVudGlmaWVyIGZvciBwYXJ0eS1BIHZzLiBwYXJ0eS1CLiAmbmJzcDtXaGF0IEkgZG9u J3QgZ2V0IGlzIHdoeSB0aGV5IG5lZWQgdG8gY2hhbmdlIHRoZSBlbmNvZGluZyBvZiB0aGUg U2Vzc2lvbi1JRCBoZWFkZXIgdmFsdWUgdnMuDQogcGFyYW1ldGVyLCBvbiBhIG1lc3NhZ2Ug ZGlyZWN0aW9uIGJhc2lzLjxicj4NCjxicj4NCkluIG90aGVyIHdvcmRzLCB0b2RheSB0aGUg ZHJhZnQgaGFzIHRoaXM6PGJyPg0KMSkgPHN0MTpwbGFjZSB3OnN0PSJvbiI+PHN0MTpDaXR5 IHc6c3Q9Im9uIj5BbGljZTwvc3QxOkNpdHk+PC9zdDE6cGxhY2U+IHNlbmRzIElOVklURSB3 aXRoICZuYnNwOyAmbmJzcDsgJnF1b3Q7U2Vzc2lvbi1JRDogZm9vJnF1b3Q7PGJyPg0KMikg Qm9iICZuYnNwOyBzZW5kcyAxOHgvMjAwIHdpdGggJm5ic3A7ICZuYnNwOyZxdW90O1Nlc3Np b24tSUQ6IGJhcjtyZW1vdGU9Zm9vJnF1b3Q7PGJyPg0KMykgPHN0MTpwbGFjZSB3OnN0PSJv biI+PHN0MTpDaXR5IHc6c3Q9Im9uIj5BbGljZTwvc3QxOkNpdHk+PC9zdDE6cGxhY2U+IHNl bmRzIEFDSyB3aXRoICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O1Nlc3Npb24t SUQ6IGZvbztyZW1vdGU9YmFyJnF1b3Q7PGJyPg0KNCkgQm9iICZuYnNwOyBzZW5kcyBCWUUg d2l0aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtTZXNzaW9uLUlEOiBiYXI7 cmVtb3RlPWZvbyZxdW90Ozxicj4NCjUpIDxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6Q2l0 eSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNlPiBzZW5kcyAyMDAgd2l0 aCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtTZXNzaW9uLUlEOiBmb287cmVt b3RlPWJhciZxdW90Ozxicj4NCjxicj4NCkJ1dCB3ZSBjb3VsZCBpbnN0ZWFkIGRvIHRoaXM6 PGJyPg0KMSkgPHN0MTpwbGFjZSB3OnN0PSJvbiI+PHN0MTpDaXR5IHc6c3Q9Im9uIj5BbGlj ZTwvc3QxOkNpdHk+PC9zdDE6cGxhY2U+IHNlbmRzIElOVklURSB3aXRoICZuYnNwOyAmbmJz cDsgJnF1b3Q7U2Vzc2lvbi1JRDogZm9vJnF1b3Q7PGJyPg0KMikgQm9iICZuYnNwOyBzZW5k cyAxOHgvMjAwIHdpdGggJm5ic3A7ICZuYnNwOyZxdW90O1Nlc3Npb24tSUQ6IGZvbztyZW1v dGU9YmFyJnF1b3Q7PGJyPg0KMykgPHN0MTpwbGFjZSB3OnN0PSJvbiI+PHN0MTpDaXR5IHc6 c3Q9Im9uIj5BbGljZTwvc3QxOkNpdHk+PC9zdDE6cGxhY2U+IHNlbmRzIEFDSyB3aXRoICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O1Nlc3Npb24tSUQ6IGZvbztyZW1vdGU9 YmFyJnF1b3Q7PGJyPg0KNCkgQm9iICZuYnNwOyBzZW5kcyBCWUUgd2l0aCAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtTZXNzaW9uLUlEOiBmb287cmVtb3RlPWJhciZxdW90 Ozxicj4NCjUpIDxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6Q2l0eSB3OnN0PSJvbiI+QWxp Y2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNlPiBzZW5kcyAyMDAgd2l0aCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmcXVvdDtTZXNzaW9uLUlEOiBmb287cmVtb3RlPWJhciZxdW90Ozxi cj4NCjxicj4NClRoaXMgc2Vjb25kIG1vZGVsIGtlZXBzIHRoZSBTZXNzaW9uLUlEIGhlYWRl ciB2YWx1ZSBhcyAmcXVvdDtmb28mcXVvdDsgdGhlIHdob2xlIHRpbWUsIHdoaWxlIGFkZGlu ZyBhIHBhcmFtZXRlciBvZiAmcXVvdDtiYXImcXVvdDsgZm9yIEJvYiB0aGF0IHJlbWFpbnMg YSBwYXJhbWV0ZXIgdGhlIHdob2xlIHRpbWUuPGJyPg0KTmVpdGhlciBBbGljZSBub3IgQm9i IGFyZSBjb25mdXNlZCBhYm91dCB3aGljaCBvbmUgaXMgJnF1b3Q7dGhlaXImcXVvdDsgVVVJ RCB2YWx1ZS48YnI+DQpBbmQgaXQncyBiYWNrd2FyZC1jb21wYXRpYmxlIHdpdGggdGhlIHBy ZXZpb3VzIGthcGxhbi1kcmFmdC48YnI+DQpBbmQgaXQncyBhcmd1YWJseSBlYXNpZXIgdG8g aW1wbGVtZW50LCBmb3IgdGhlIGNvbW1vbiBjYXNlcy48YnI+DQo8YnI+DQpJICp0aGluayog dGhlcmUgd2FzIGEgcmVhc29uIHNvbWVvbmUgY2FtZSB1cCB3aXRoIGF0IG9uZSB0aW1lIGFz IHRvIHdoeSBpdCBoYWQgdG8gYmUgc3dhcHBlZCwgYnV0IEkgZG9uJ3QgcmVtZW1iZXIgd2hh dCBpdCBpcyBhbmQgSSBkb24ndCBzZWUgaXQgaW4gdGhlIGRyYWZ0LiAmbmJzcDtTbyBJJ20g dHJ5aW5nIHRvIGZpbmQgb3V0IHdoeSB3ZSBuZWVkIHRvIGRvIGl0IHRoZSB3YXkgdGhlIGRy YWZ0IGN1cnJlbnRseSBoYXMgaXQuPGJyPg0KPGJyPg0KVGhlIG90aGVyIHRvcGljIG9mIHdo ZXRoZXIgU0JDcyB3aWxsIGNoYW5nZSB0aGluZ3MgaXMgY29tcGxldGVseSBvcnRob2dvbmFs IHRvIHRoZSBvcmRlcmluZyBvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBpc3N1ZXMsIGFu ZCByZWFsbHkgc2hvdWxkbid0IGJlIGNvbmZsYXRlZCB3aXRoIGl0IGF0IGFsbC4gJm5ic3A7 SXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgc29sdXRpb25zIGRvY3VtZW50LCBvciB0 aGUgZGlyZWN0aW9uIHN0dWZmLCBldGMuPGJyPg0KPGZvbnQgY29sb3I9IiM4ODg4ODgiPjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQotaGFkcmllbDwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCjxicj4NCk9u IEF1ZyAxLCAyMDEzLCBhdCAxMjozOCBBTSwgUGF1bCBFLiBKb25lcyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhdWxlakBw YWNrZXRpemVyLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgRm9sa3MsPGJy Pg0KJmd0Ozxicj4NCiZndDsgSSBzdGVwIGF3YXkgZm9yIGEgY291cGxlIG9mIGRheXMgYW5k IHRoZSBmbG9vZGdhdGUgb3BlbnMuIDopPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB0aGluayBp dCdzIGltcG9ydGFudCB0byB1bmRlcnN0YW5kIHdoeSB3ZSBwcm9wb3NlZCB1c2luZyBhIHR3 by1wYXJ0PGJyPg0KJmd0OyBTZXNzaW9uIElkZW50aWZpZXIuICZuYnNwO1RoZSByZWFzb24g aXMgdGhhdCB3ZSBoYXZlIHRvIGJlIGFibGUgdG8gZWZmZWN0aXZlbHk8YnI+DQomZ3Q7IGRl YWwgd2l0aCB0aGluZ3MgbGlrZSBmb3JraW5nLCBjYWxsIHRyYW5zZmVyLCBwYXJrLCBicmlk Z2luZywgY29uZmVyZW5jaW5nLDxicj4NCiZndDsgZXRjLjxicj4NCiZndDs8YnI+DQomZ3Q7 IFdoZW4gaW5pdGlhdGluZyBhIGNhbGwgYW5kIHVzaW5nIGEgc2luZ2xlIFVVSUQgdmFsdWUs IHRoYXQgaGFzIHRoZSBwb3RlbnRpYWw8YnI+DQomZ3Q7IHRvIGdvIGVuZC10by1lbmQuIEhv d2V2ZXIsIGlmIGEgY2FsbCBpcyBmb3JrZWQgdGhlcmUgYXJlIG11bHRpcGxlICZxdW90O2Vu ZHMmcXVvdDsuPGJyPg0KJmd0OyBIb3cgZG8gd2UgdHJhY2sgZWFjaCBvZiB0aG9zZT8gJm5i c3A7Rm9yIHByb3BlciBkaWFnbm9zdGljcyBhbmQgdHJvdWJsZXNob290aW5nLDxicj4NCiZn dDsgaXQgd291bGQgYmUgaWRlYWwgdG8gYmUgYWJsZSB0byBpZGVudGlmeSB3aGljaCBkZXZp Y2VzIGhhdmUgYW4gaXNzdWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgT25jZSBhIGNhbGwgaGFz IGJlZW4gcGxhY2VkLCB0aGVyZSBpcyBhIFNlc3Npb24tSUQgZXN0YWJsaXNoZWQgYmV0d2Vl biA8c3QxOnBsYWNlIHc6c3Q9Im9uIj4NCjxzdDE6Q2l0eSB3OnN0PSJvbiI+QWxpY2U8L3N0 MTpDaXR5Pjwvc3QxOnBsYWNlPjxicj4NCiZndDsgYW5kIEJvYi4gJm5ic3A7SWYgPHN0MTpw bGFjZSB3OnN0PSJvbiI+PHN0MTpDaXR5IHc6c3Q9Im9uIj5BbGljZTwvc3QxOkNpdHk+PC9z dDE6cGxhY2U+IChpbiBvbmUgY291bnRyeSkgdHJhbnNmZXJzIEJvYiAocGVyaGFwcyBpbiB0 aGUgc2FtZSBvcjxicj4NCiZndDsgZGlmZmVyZW50IGNvdW50cnkpIHRvIGEgc29tZSBsb2Nh dGlvbiBpbiBhIGhpZ2gtdG9sbCBjb3VudHJ5LCB3aG8gcGF5cyB0aGU8YnI+DQomZ3Q7IGJp bGw/ICZuYnNwO1dlbGwsIHRvIGFkZHJlc3MgdGhhdCwgd2UgZG8gY2FsbCB0cmFuc2ZlciBs b2NhbGx5IG9uIFBCWGVzLiAmbmJzcDtUaGUgUEJYPGJyPg0KJmd0OyBtYWludGFpbnMgY29u dHJvbCBvdmVyIHRoZSBjYWxsIGFuZCA8c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOkNpdHkg dzpzdD0ib24iPkFsaWNlPC9zdDE6Q2l0eT48L3N0MTpwbGFjZT4gd291bGQgcGF5IHRoZSBi aWxsIGZvciB0aGUgY2FsbDxicj4NCiZndDsgdHJhbnNmZXIuICZuYnNwO0J1dCBpZiA8c3Qx OnBsYWNlIHc6c3Q9Im9uIj48c3QxOkNpdHkgdzpzdD0ib24iPkFsaWNlPC9zdDE6Q2l0eT48 L3N0MTpwbGFjZT4gd2FzIHRhbGtpbmcgdG8gQ2Fyb2wgYmVmb3JlIHRoZSB0cmFuc2Zlciwg dGhlcmUgaXMgYTxicj4NCiZndDsgU2Vzc2lvbi1JRCBmb3IgdGhhdCBjYWxsLiAmbmJzcDtJ ZiBCb2IgaXMgcHV0IGluIGNvbW11bmljYXRpb24gd2l0aCBDYXJvbCwgd2hhdDxicj4NCiZn dDsgaXMgdGhlIFNlc3Npb24tSUQgdmFsdWU/ICZuYnNwO0JvYiBoYWQgb25lIGFuZCBDYXJv bCBoYWQgYSBkaWZmZXJlbnQgb25lLiAmbmJzcDtXaGF0PGJyPg0KJmd0OyBpcyB0aGUgbmV3 IElEPzxicj4NCiZndDs8YnI+DQomZ3Q7IEl0J3MgaXNzdWVzIGxpa2UgdGhpcyB0aGF0IGxl ZCB1cyB0byB1c2luZyBhIHR3by1wYXJ0IHZhbHVlLiAmbmJzcDtJbiB0aGlzIHdheSw8YnI+ DQomZ3Q7IHdlIGNvdWxkIHNlZSB0aGUgY2FsbCBmcm9tIDxzdDE6cGxhY2UgdzpzdD0ib24i PjxzdDE6Q2l0eSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNlPiB0byBC b2IgaGFzIGEgU2Vzc2lvbi1JRCB7QSxCfS4gJm5ic3A7SWYNCjxzdDE6cGxhY2UgdzpzdD0i b24iPjxzdDE6Q2l0eSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNlPjxi cj4NCiZndDsgdHJhbnNmZXJzIHRoZSBjYWxsIHRvIENhcm9sLCBlYWNoIGRldmljZSB1bmRl cnN0YW5kcyB0aGF0IHRoZSBTZXNzaW9uLUlEPGJyPg0KJmd0OyBjaGFuZ2VkIHRvIHtCLEN9 LiAmbmJzcDtOb3Qgb25seSB0aGF0LCBidXQgaW50ZXJtZWRpYXJpZXMgYWxvbmcgdGhlIHBh dGggdGhhdDxicj4NCiZndDsgd2VyZSBub3QgcHJpdnkgdG8gc2lnbmFsaW5nIHRoYXQgcmVz dWx0ZWQgaW4gdGhpcyBjaGFuZ2UgY2FuIHRha2Ugbm90ZSBvZjxicj4NCiZndDsgdGhlIGZh Y3QgdGhlIHZhbHVlIGNoYW5nZWQuICZuYnNwO1RoaXMgY2FuIHByb3ZpZGUgYSB1c2VmdWwg aGlzdG9yaWNhbCByZWNvcmQsPGJyPg0KJmd0OyBzaW5jZSBwcmV2aW91c2x5IHRoZXkgbWln aHQgc2VlIGEgY2FsbCB0byBDYXJvbCBpZGVudGlmaWVkIGFzIHtBLEN9LCBidXQ8YnI+DQom Z3Q7IHRoZW4gaXQgY2hhbmdlZCB0byB7QixDfS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlz IHByb3BlcnR5IGV4dGVuZHMgcXVpdGUgbmF0dXJhbGx5IHRvIG90aGVyIHNpZ25hbGluZyBz Y2VuYXJpb3MsIGFzIGl0PGJyPg0KJmd0OyBhbGxvd3Mgb25lIHRvIGlkZW50aWZ5IGEgY2Fs bCBlbmQtdG8tZW5kLCBidXQgYWxzbyBlc3RhYmxpc2ggc29tZTxicj4NCiZndDsgcmVsYXRp b25zaGlwIGJldHdlZW4gb3RoZXIgY2FsbHMgdGhhdCBzaGFyZWQgYXQgbGVhc3Qgb25lIFVV SUQgdmFsdWUgb3V0IG9mPGJyPg0KJmd0OyB0aGUgdHdvLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEhhZHJpZWwgbWVudGlvbmVkIHRoZSBkZXNpcmUgdG8gdXNlIHRoZSBTZXNzaW9uLUlEIHRv IGNvcnJlbGF0ZSBtZWRpYSBmbG93czxicj4NCiZndDsgYW5kIGNhbGxzLiAmbmJzcDtUaGF0 J3MgY2VydGFpbmx5IHNvbWV0aGluZyBDaXNjbyB3b3VsZCBsaWtlIHRvIGRvLCBidXQgaXQg aXMgbm90PGJyPg0KJmd0OyB0aGUgZHJpdmVyIGJlaGluZCB0aGUgc29sdXRpb24uICZuYnNw O0hhdmluZyBhIHZhbGlkIGVuZC10by1lbmQgaWRlbnRpZmllciAoaW48YnI+DQomZ3Q7IHdo YXRldmVyIGZvcm0pIGFsbG93cyB1cyB0byBkbyB0aGF0LiAmbmJzcDtXZSdyZSBub3Qgc3Vn Z2VzdGluZyB0byBmaXQgdGhlPGJyPg0KJmd0OyBzb2x1dGlvbiB0byBtZWV0IHRoYXQgYnVz aW5lc3MgdXNlIGNhc2UsIGJ1dCByYXRoZXIgd2UganVzdCB3YW50IGEgc29sdXRpb248YnI+ DQomZ3Q7IHRoYXQgYWxsb3dzIHVzIHRvIHByb3Blcmx5IGlkZW50aWZ5IGNhbGxzIGVuZC10 by1lbmQgYW5kIHdlIHJlY29nbml6ZSB0aGF0LDxicj4NCiZndDsgZHVlIHRvIHZhcmlvdXMg c2VydmljZSBpbnRlcmFjdGlvbnMgaW4gdGhlIG5ldHdvcmssIHRoZXNlIFVVSUQgdmFsdWVz IGNhbjxicj4NCiZndDsgY2hhbmdlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd291bGQgaG9w ZSB0aGF0IFVVSUQgdmFsdWVzIHdpbGwgbm90IGNoYW5nZSB0byB0aGUgZXh0ZW50IHRoYXQg U0JDcyBjaGFuZ2U8YnI+DQomZ3Q7IHRoZW0gZm9yIGJ1c2luZXNzIHJlYXNvbnMuICZuYnNw O0l0IHdvdWxkIGNlcnRhaW5seSBkZWZlYXQgdGhlIHBvaW50LiAmbmJzcDtIYWRyaWVsPGJy Pg0KJmd0OyBtaWdodCBiZSByaWdodCB0aGF0IGFuIDxzdDE6c3RvY2t0aWNrZXIgdzpzdD0i b24iPlNCQzwvc3QxOnN0b2NrdGlja2VyPiB2ZW5kb3IgbWlnaHQgbWFuaXB1bGF0ZSB0aG9z ZSB2YWx1ZXMgYXQgdGhlPGJyPg0KJmd0OyByZXF1ZXN0IG9mIGEgY3VzdG9tZXIsIGJ1dCBJ IHdvdWxkIGhvcGUgc2FpZCBjdXN0b21lciBhcHByZWNpYXRlcyB0aGF0IHN1Y2g8YnI+DQom Z3Q7IGEgcmVxdWVzdCBlZmZlY3RpdmVseSBicmVha3MgdGhlIGVuZC10by1lbmQgbW9kZWwu ICZuYnNwO1dlIGNhbid0IGRvIG11Y2ggYWJvdXQ8YnI+DQomZ3Q7IHRoYXQgaWYgdGhleSBk byBnbyBkb3duIHRoYXQgcGF0aC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBcyBmb3IgYmFja3dh cmQtY29tcGF0aWJpbGl0eSwgdGhlIHNpbXBsZXN0IGFwcHJvYWNoICg8c3QxOnN0b2NrdGlj a2VyIHc6c3Q9Im9uIj5JTU88L3N0MTpzdG9ja3RpY2tlcj4pIGlzIHRvIGp1c3QgdXNlIGE8 YnI+DQomZ3Q7IGhlYWRlciB2YWx1ZSBub3QgYWxyZWFkeSBpbiB1c2UuICZuYnNwO09yaWdp bmFsbHksIHdlIGhhZCBwcm9wb3NlZCBTZXNzaW9uLVVVSUQuPGJyPg0KJmd0OyBUaGF0IHdh cyBjaGFuZ2VkIGF0IHRoZSByZXF1ZXN0IG9mIHRoZSBncm91cCB0byBiZSBTZXNzaW9uLUlE LiAmbmJzcDtIb3dldmVyLDxicj4NCiZndDsgd2hlbiB3ZSBoYXZlIGEgdHdvIFVVSUQgc29s dXRpb24gaW50ZXJhY3Rpbmcgd2l0aCBhIG9uZS1VVUlEIHNvbHV0aW9uLCB3ZTxicj4NCiZn dDsgaW1tZWRpYXRlbHkgZmFjZSBzb21lIGNoYWxsZW5nZXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgV2hhdCBoYXBwZW5zIGlmIGFuIG9sZGVyIHN5c3RlbSBzZW5kcyB0aGlzOjxicj4NCiZn dDsgJm5ic3A7U2Vzc2lvbi1JRDogWDxicj4NCiZndDsgQnV0IHRoZW4gcmVjZWl2ZXMgdGhp czo8YnI+DQomZ3Q7ICZuYnNwO1Nlc3Npb24tSUQ6IFk7IHJlbW90ZT1YPGJyPg0KJmd0Ozxi cj4NCiZndDsgRG9lcyB0aGlzIGJyZWFrIHRoaW5ncz8gJm5ic3A7SWYgc28sIGhvdyBkbyBj dXJyZW50IGltcGxlbWVudGF0aW9ucyBkZWFsIHdpdGg8YnI+DQomZ3Q7IHN1Y2ggdGhpbmdz IGFzIG1pZC1jYWxsIHRyYW5zZmVycyB0aGF0IGhhcHBlbiBvbiBhIFBCWCBsaWtlIHRoZSBv bmUgSTxicj4NCiZndDsgZGVzY3JpYmVkIGFib3ZlPzxicj4NCiZndDs8YnI+DQomZ3Q7IFdl IGNvdWxkIHN3aXRjaCB0aGUgb3JkZXIgbGlrZSB0aGlzOjxicj4NCiZndDsgJm5ic3A7U2Vz c2lvbi1JRDogWDsgcmVtb3RlPVk8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3dldmVyLCB0aGF0 IGRvZXMgbm90IHdvcmsgZm9yIHNpbWlsYXIgcmVhc29ucy4gJm5ic3A7SWYgd2UgaGF2ZSBh IGNhbGwgdHJhbnNmZXI8YnI+DQomZ3Q7IHdoZXJlIDxzdDE6cGxhY2UgdzpzdD0ib24iPjxz dDE6Q2l0eSB3OnN0PSJvbiI+QWxpY2U8L3N0MTpDaXR5Pjwvc3QxOnBsYWNlPiB0cmFuc2Zl cnMgYSBjYWxsIHdpdGggQm9iIHRvIENhcm9sLCB0aGVuIGVhY2ggaGFzIGEgZGlmZmVyZW50 PGJyPg0KJmd0OyBpZGVhIGFib3V0IHdoYXQgdGhlIHByb3BlciB2YWx1ZSBpcyBmb3IgdGhl IGZpcnN0IHBvc2l0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9yaWdpbmFsbHksIHRoZSBw cm9wb3NlZCBzb2x1dGlvbiBkaWQgbm90IGluZGljYXRlIHBvc2l0aW9uIGluZm9ybWF0aW9u IGFuZDxicj4NCiZndDsganVzdCBoYWQgc2luZ2xlIFVVSUQgdmFsdWVzIGdvaW5nIGluIGVh Y2ggZGlyZWN0aW9uLiAmbmJzcDtXZSB0aGVuIHByb3Bvc2VkIGE8YnI+DQomZ3Q7IGNvbmNh dGVuYXRlZCBzdHJpbmcgKFg6WSkuIEhvd2V2ZXIsIHRoYXQgcHJlc2VudGVkIHRoZSBzYW1l IGlzc3VlcyBmb3IgdGhlPGJyPg0KJmd0OyBjYWxsIHRyYW5zZmVyIGNhc2UsIHNvIHdlIGlu ZGljYXRlIHZhbHVlcyBieSBwb3NpdGlvbiAoc2VuZGVyJ3MgdmFsdWU8YnI+DQomZ3Q7IGZp cnN0KSwgc28gaXQgaXMgY2xlYXIgd2hhdCB2YWx1ZSB0aGUgcmVjZWl2ZSB0aGlua3MgdGhl IHJlbW90ZSBlbmQgaGFzIGZvcjxicj4NCiZndDsgdGhlIGxvY2FsIGVuZC4gJm5ic3A7SXQg bWlnaHQgYmUgd3JvbmcsIGJ1dCB0aGF0IHdpbGwgYmUgY29ycmVjdGVkIGluIHRoZTxicj4N CiZndDsgZm9sbG93aW5nIHJlc3BvbnNlLiAoSW50ZXJtZWRpYXJpZXMgY2FuIHRha2Ugbm90 ZSBvZiB0aGUgY2hhbmdlLik8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTbywgdGhhdCdzIHdoeSB3 ZSBhcmUgd2hlcmUgd2UgYXJlLiAmbmJzcDtUaGVyZSBoYXMgYmVlbiBhbiBlZmZvcnQgdG8g bWFpbnRhaW48YnI+DQomZ3Q7IGJhY2t3YXJkLWNvbXBhdGliaWxpdHksIGJ1dCB0aGVyZSBh cmUgY2hhbGxlbmdlcyBpbiBtZWV0aW5nIHRoYXQ8YnI+DQomZ3Q7IHJlcXVpcmVtZW50LiAm bmJzcDtXaGVyZSBpdCBmYWxscyBzaG9ydCwgd2UgZG8gbm90IGtub3c6IHdlJ3ZlIG5vdCBi ZWVuIHRvbGQ8YnI+DQomZ3Q7IGV4cGxpY2l0bHkgd2hhdCB0aGUgaXNzdWVzIGFyZS4gJm5i c3A7RnVydGhlciwgaWYgdGhlcmUgYXJlIHN1Y2ggaXNzdWVzLCB3ZSBuZWVkPGJyPg0KJmd0 OyB0byBhbHNvIHVuZGVyc3RhbmQgaG93IHRob3NlIHdvdWxkIGJlIGhhbmRsZWQgaW4gdGhl IGZhY2Ugb2YgY2FsbCB0cmFuc2Zlcjxicj4NCiZndDsgb3IgJnF1b3Q7am9pbmluZyZxdW90 OyBhIGNhbGwgbG9jYWxseSBvbiBhIFBCWC4gJm5ic3A7VGhvc2UgYXJlIHJlYWwtd29ybGQg c2NlbmFyaW9zIHRoYXQ8YnI+DQomZ3Q7IHdlIG11c3QgYWRkcmVzcy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBBbnl3YXksIG5vdGhpbmcgaXMgc2V0IGluIHN0b25lLiAmbmJzcDtBbnl0aGlu ZyBjYW4gYmUgY2hhbmdlZCwgYnV0IEkgd291bGQgaG9wZTxicj4NCiZndDsgd2UgY2FuIGZp bmQgYSBzb2x1dGlvbiB0aGF0IHdvcmtzIGZvciB0aGUgZW50ZXJwcmlzZSB1c2UgY2FzZXMg YXMgd2VsbCBhczxicj4NCiZndDsgdGhlIHNlcnZpY2UgcHJvdmlkZXIgbmV0d29ya3MuPGJy Pg0KJmd0Ozxicj4NCiZndDsgUGF1bDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgaW5zaXBpZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzppbnNp cGlkQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aW5zaXBpZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaW5zaXBpZDwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmluc2lwaWQgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOmluc2lwaWRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p bnNpcGlkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaW5zaXBpZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6DQoxMi4wcHQiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPGJyPg0KVGhpcyB0cmFuc21p c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy aWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24u IEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbg0KIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBs eSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIg c3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0 aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uDQogYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlz IG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIDxicj4NClRo aXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFp biBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1 ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3Ro ZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGlu Zm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVy IHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0 ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZy b20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGll bnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BBF5DDFE515C3946BC18D733B20DAD2338DF0B33XMB104ADSrimnet_-- From keith.drage@alcatel-lucent.com Fri Aug 2 04:29:09 2013 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 846B421F9F52 for ; Fri, 2 Aug 2013 04:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.609 X-Spam-Level: X-Spam-Status: No, score=-110.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Kn0zaEyQSGe for ; Fri, 2 Aug 2013 04:28:30 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EA86321E8323 for ; Fri, 2 Aug 2013 04:28:21 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r72BSDMK029638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 2 Aug 2013 06:28:15 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r72BSDV3002593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Aug 2013 13:28:13 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 2 Aug 2013 13:28:13 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: draft-kaplan-insipid-session-id Thread-Index: Ac6Pc171lfdnZEywSYiW/9hbaMlCaQ== Date: Fri, 2 Aug 2013 11:28:12 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07AE83@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [Insipid] draft-kaplan-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, 02 Aug 2013 11:29:10 -0000 For information: draft-kaplan-insipid-session-id-03.txt is now in IETF last call https://www.ietf.org/ibin/c5i?mid=3D6&rid=3D49&gid=3D0&k1=3D934&k2=3D12219&= tid=3D1375442761 If you consider you have comments, please do not comment on this list (it i= s not an INSIPID WG item), but follow the instructions on the announcement. Regards Keith From paulej@packetizer.com Fri Aug 2 08:09:38 2013 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 8073121E80F3 for ; Fri, 2 Aug 2013 08:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, J_BACKHAIR_53=1, J_BACKHAIR_55=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFCya7lJ5RwM for ; Fri, 2 Aug 2013 08:09:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 14B6221E8096 for ; Fri, 2 Aug 2013 08:08: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 r72F8og7018397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 11:08:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375456131; bh=JIwKZgH/XVpwN6+yLkv+CF670uR/Dc/jx4J1dOCKJuk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=scwMkn8rBxDTLAlSRwRL7YLuqEFiDFrtyOCq42Qwgr/lFMYHmrGqu7VQ+7GJ5hIFo L9WP+ZTaQlznotkAh+fBejrEyq+BVLfmpkIEDfet0Mz/4VzfZHaTynSGfiJDDDSm9V lQ/zwu3lQS7pLTusET/I1oV6UZoJrujIC0RVxq4A= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> <009c01ce8ef8$7906b780$6b142680$@packetizer.com> <6A36BEEC-B69D-4B39-A1E5-C988462DDB61@oracle.com> In-Reply-To: <6A36BEEC-B69D-4B39-A1E5-C988462DDB61@oracle.com> Date: Fri, 2 Aug 2013 11:08:48 -0400 Message-ID: <01ba01ce8f92$316b35f0$9441a1d0$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEAul1PlEC084uXwHoWQp5AJYnTYwCzQ18qAGq11dul0Zbs1A= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:09:38 -0000 Hadriel, > As a side note: none of this discussion seems to have anything to do with > swapping directionality of value+parameter based on sender of messages. > This is really more about whether you can change the Session-ID header > value mid-dialog or not. Right. I'm trying to understand the constraints that limit interoperability with the former draft. > I don't think that is actually required in the requirement document - the > relevant requirement is REQ2, but my impression is we don't need the > header value in particular to be updated and changed end-to-end... it just > required us to be able to correlate the two sessions transferred/joined by > a PBX *somehow*. I.e., as long as one UUID in either a header value or > param is the same on both sides, we'd be ok. Would that be ok? [I'm not > trying to be nit-picky and a stickler to the requirements doc, but more > asking if that's sufficient for your needs.] Yeah, for the solution we proposed, we can correlate the two calls by looking at the individual UUIDs after a transfer. What I'm interested in understanding in this thread is how the Session-ID header value can change (if at all) when a call is "joined" at a PBX under the old scheme. > > Bob calls Carol, so the Session-ID is some value we'll call 'B'. > > Bob was on a call with Alice with some value Alice assigned 'A'. > > > > Now, we want to join these two calls together so that Alice is talking > with > > Carol (no REFER ... all local stuff). What is the Session-ID value in > this > > case? > > The *header value* would remain "A" on the Alice<->PBX call leg, and "B" > on the Carol<->Carol call leg. > The header *parameter* can change, so we can tie it together there. > > So it would be: > 1) Alice <-PBX-> Bob call: A;B > 2) Bob <-PBX-> Carol call: B;C > 3) Bob pushes some button to make PBX join Alice and Carol > 4) Alice <-PBX is now A;C and PBX->Carol call is now B;A (or B;C if we > want it to be that instead) But, now we no longer have an end-to-end identifier. Now we have two entirely different identifiers: one from Alice to PBX and one from the PBX to Carol. > >> Well it feels like you want to hide the changes from Alice, but at the > >> same time you want Alice to know things changed because you want to > send > >> her a new/updated UUID pairing. Isn't that revealing things changed to > >> Alice? This seems like a contradiction. > > > > No, Alice knows the call transferred. That's not a problem. But, we > would > > not want to reveal Carol's phone number or URI to Alice, and likely > might > > want to hide other signaling elements. You know B2BUAs do strange > things. > > > > But, we would like these random numbers to go end-to-end. Nothing is > > revealed in the random number. > > OK I understand. I would point out though, that this is one case where I > bet people would have SBCs block this change from propagating out. Some > people don't like re-INVITEs/UPDATEs propagating out, for changes that > occur inside an Enterprise... whatsoever. I.e., if Alice is calling into > an Enterprise from a SIP Trunk, my guess is there'll be some cases where > the SBCs are configured to locally answer re-INVITES/UPDATEs coming from > the Enterprise side. We've been told to do this both in cases when we get > deployed as Service Provider-side and cases where we're Enterprise-side > SBCs, of SIP Trunks.[1] You might be right, but then those folks lose the benefits of having an end-to-end identifier. I can't force people not to do something, even if the standard says not to do it :-( Paul From paulej@packetizer.com Fri Aug 2 08:12:38 2013 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 1762B21E8096 for ; Fri, 2 Aug 2013 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1gAiCGI9Epk for ; Fri, 2 Aug 2013 08:12:33 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D285E11E80FA for ; Fri, 2 Aug 2013 08:12:32 -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 r72FCVBw018674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 11:12:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375456351; bh=UefQpZcxnBncCsHSG9jDWfvA1uTJfXkdU5miGMrhBIk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Fy9MIk906jRJyawMC6bcZJJcHFJjGHYQ5+BGvu3nTHpYHg5/XEsr0j14nsHO9rZh5 +RoTzyzxL7I1KUav1WpbI3DJHEYiXJhej7QPJe2hc+laqVi0f9Ps7N7KRf7Owz0UUD bm3Dw4gs9gNwJPpj9boi6IvO+I9KM/JSBndKCwVc= From: "Paul E. Jones" To: "'Laura Liess'" , References: In-Reply-To: Date: Fri, 2 Aug 2013 11:12:29 -0400 Message-ID: <01bc01ce8f92$b488bb60$1d9a3220$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BD_01CE8F71.2D77B7A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7Az1VSDdQ1XC6ETtWr5EncMz++ZopHlsw Content-Language: en-us Subject: Re: [Insipid] Generation of a new Session-ID on behalf of an end device X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:12:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01BD_01CE8F71.2D77B7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Laura, The latest solutions draft has text that explains how an intermediary device can generate the Session-ID. However, it does not use a secret key of any sort. You had previously stated that you wanted the value to be consistently regenerated, even in the face of calls being routed somewhere else in the network. So, there is a prescription for generating random values that use the Call-ID and from/to tag. The end result is a UUID value, following the procedures specified in the UUID RFC. Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Liess Sent: Thursday, August 01, 2013 12:50 PM To: insipid@ietf.org Subject: [Insipid] Generation of a new Session-ID on behalf of an end device Hi, As agreed in the insipid meeting, please find below the text on how SBCs should generate the Session-ID (or a part of it) on behalf of an end device. It is "copy & paste" from Hadriel's draft, parts of the Sections 4.1 and 4.5.1. However, I think we should replace B2BUA by SBC. Application servers and PBXs may want to insert their own UUID. I am fine if they do not add the received Call-ID. ******Text from Hadriel's draft *************************************************************** If an out-of-dialog request is received by a B2BUA compliant with this document, and the request does *not* contain a Session-ID header field, the B2BUA MAY generate a new one. The new Session-ID value MUST be generated by taking the Call-ID header value, and SHA-1 hashing it based on [RFC2104] HMAC using a locally generated pseudo-random 128-bit system secret key, to create a 128- bit resultant HMAC value. Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value, secret_key), and the 128-bit result is encoded using lowercase alphanumeric hex representation, as defined in the ABNF section of this document. In order to enable trouble-shooting of in-dialog messages, a generator needs to remember or re-create the same Session-ID value for the duration of a given dialog(s). If any received message already had a Session-ID, a B2BUA compliant with this document would not replace it. ************************************************************************** Thank you Laura ------=_NextPart_000_01BD_01CE8F71.2D77B7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Laura,

 

The latest solutions draft has text that explains how an intermediary = device can generate the Session-ID.  However, it does not use a = secret key of any sort.  You had previously stated that you wanted = the value to be consistently regenerated, even in the face of calls = being routed somewhere else in the network.

 

So, there is a prescription for generating random values that use the = Call-ID and from/to tag.  The end result is a UUID value, following = the procedures specified in the UUID RFC.

 

Paul

 

From:= = insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Laura Liess
Sent: Thursday, August 01, 2013 12:50 = PM
To: insipid@ietf.org
Subject: [Insipid] = Generation of a new Session-ID on behalf of an end = device

 

Hi,

As agreed in the =
insipid meeting, please find below the text on how SBCs should =

generate the Session-ID (or a part of it) on behalf of an end =
device. 
It is  "copy =
& paste" from Hadriel's draft, parts of the =
Sections 4.1 and 4.5.1. 

However, I think =
we should replace B2BUA by SBC. Application servers and PBXs may want to =
insert their own UUID. I am fine 
if they do not add the received =
Call-ID. 


******Text from Hadriel's draft =
*************************************************************** &nbs=
p;  
   If an out-of-dialog =
request is received by a B2BUA compliant with =

   this document, and the request =
does *not* contain a Session-ID =

   header field, the B2BUA MAY =
generate a new one.  The new Session-ID =

   value MUST be generated by =
taking the Call-ID header 
   value, =
and SHA-1 hashing it based on [RFC2104] HMAC using a locally =

   generated pseudo-random 128-bit =
system secret key, to create a 128-
   =
bit resultant HMAC value. Per [RFC2104], the algorithm is thus =
HMAC-SHA-1-128(Call-ID_value, =

   secret_key), and the 128-bit =
result is encoded using lowercase =

   alphanumeric hex representation, =
as defined in the ABNF section of =

   this =
document.     =

   In order to enable =
trouble-shooting of in-dialog messages, a =

   generator needs to remember or =
re-create the same Session-ID value =

   for the duration of a given =
dialog(s). 
   If any received message already had a =

   Session-ID, a B2BUA compliant =
with this document would not replace =

   it. =

*********************************************************************=
*****

Thank =
you
Laura
------=_NextPart_000_01BD_01CE8F71.2D77B7A0-- From paulej@packetizer.com Fri Aug 2 08:22:27 2013 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 1C70B11E80D3 for ; Fri, 2 Aug 2013 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1lrWMOJUP8H for ; Fri, 2 Aug 2013 08:22:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 010AF11E80EC for ; Fri, 2 Aug 2013 08:22:21 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r72FMKM2019298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 11:22:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375456940; bh=h7JTyu2yICGQ9Ie+MxkNKHpCyYDIYkKJIKZVaMuyyUo=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lHp7HsnmpankT/zn8M6r+D14Iod2MMLifeguVJT93gJiZaCegUCD62OYKlz00hRwq 6PDe0ngtJGhAS/bkVMN7P/h5AYX+XzWHMQLBjTT+nE4rCF09vPIK6B15lbSmHEox/n ATTk/s6iaAol4f3TCxsDTplUNOLk3D3lxbSKm2nU= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> In-Reply-To: Date: Fri, 2 Aug 2013 11:22:18 -0400 Message-ID: <01c901ce8f94$13beb480$3b3c1d80$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwH9WYgfl09TRKA= Content-Language: en-us Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:22:27 -0000 Hadriel, The new solution is not focused on media flow tracking. Let me be clear. We just need a Session-ID. Once we have one, then we can do other interesting things with it. We did want to solve then end-to-end problem, appreciating the fact that the ends do move around sometimes. So, while Alice might start out talking to Bob, she might get switched over to Carol. This is extremely common, especially in call centers (but also if you call my desk and I transfer you somewhere else). Re-INVITE for transfers is often needed, because audio/video capabilities change. Media ports might change, too. In most transfer cases, calls are put on hold and sometimes media is halted entirely, at least in one direction. I'm certainly OK with trying to figure out how to interwork with the previous draft, but it looks like it might be too constraining by not supporting transfers and such. In effect, it's not always end-to-end. I'm certainly OK, too, with a new header value, though "Media-ID" is not quite right. This is intended to identify the session. Perhaps just "Sess-ID"? Paul > Forgetting about the new solution... the old solution worked because it > never claimed or attempted to solve the problem you're trying to solve. It > was just to help with troubleshooting; and because it was just to help > with troubleshooting it was kept as simple as possible in order to make it > easy to implement, and so as not to cause a need to troubleshoot the > troubleshooting tool. Due to that, it does support call transfers being > tracked by a Session-ID when REFERs and INVITE w/replaces were used for > the transfer; but not when SIP itself didn't change at all, and instead a > media-bridge switches around what media is going to whom. Session-ID > wasn't really meant to be a media-flow tracking mechanism originally. > > When this was in DISPATCH, we talked about sending re-INVITEs/UPDATEs to > modify the Session-ID in case of hidden transfers and such - but the > general consensus at that time was not to bother. It would be insane to > expect things to send re-INVITEs/UPDATEs all over the place to > update/change Session-ID values just to help troubleshooting - who would > want a troubleshooting-aid thing to do that really? So we basically > decided not to do that, and instead keep it simple and lightweight. > > That's why I argued so much originally against adding the extra > requirements to track hidden transfers and conference servers and such. > It requires sending re-INVITEs/UPDATEs to all parties, and I had a hard > time believing folks would really want that to happen in practice. But > the WG decided it was worth it, and to have the requirement; but meanwhile > to not break backwards compatibility. So I think there're two ways to go > about it: either (1) work around the limitations of the legacy individual > draft, or (2) pick a new header name "Media-ID" or some such and not be > constrained by the old draft. > > -hadriel > p.s. personally I'd be ok with either option-1 or option-2, fwiw. From paulej@packetizer.com Fri Aug 2 08:45:08 2013 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 F379211E80DF for ; Fri, 2 Aug 2013 08:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZLoCpr3whe2 for ; Fri, 2 Aug 2013 08:45:03 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3D811E80D3 for ; Fri, 2 Aug 2013 08:45: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 r72FivmG020608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 11:44:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375458297; bh=PjkQYk+FIn8BZZZtNCig5lAiRiRBdqw04D8sc7MyhU8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Uc/9pGIvoEZghLTnZa02b4UgeetsDERgjTIzGEPMRGySaiJRWVauOGzPSz/tlSom5 jWhGEyvcLFLeyz92r0VYnfJmCd/7whk6uWh7KufZyv/uSjuDsX+2/6/At6HyFlFAos Vq8i6c1OaMfpl7YuvVT9nl4AsfuScRFScOFDfFuc= From: "Paul E. Jones" To: "'Andrew Allen'" , , , References: <949EF20990823C4C85C18D59AA11AD8B07A940@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Date: Fri, 2 Aug 2013 11:44:55 -0400 Message-ID: <01d401ce8f97$3ca17150$b5e453f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D5_01CE8F75.B5929070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGimQjVTwzQp6/jQ1aGdBUzxRMg3ZnZ915g Content-Language: en-us Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:45:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D5_01CE8F75.B5929070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andrew, =20 Given what Hadriel explained in the email earlier (if I understood it = correctly), the old draft would likely be broken by any PBX that merrily = passed the Session-ID header through end-to-end. =20 Review that flow I presented before: 1) Alice calls Bob (Session-ID: A) 2) Bob puts Alice on hold 3) Bob calls Carol (Session-ID: B) 4) Bob =E2=80=9Ctransfers=E2=80=9D (local join) Alice to Carol =20 At step 4, Alice would send Session-ID =E2=80=9CA=E2=80=9D to Carol and = Carol would send Session-ID =E2=80=9CB=E2=80=9D to Alice. Basically, = the two endpoints have a different concept of what the end-to-end value = is. =20 We could try to order the UUIDs in the current solution draft so that we = =E2=80=9Cdo not make it worse=E2=80=9D or we could just pick a different = header value to use, as Hadriel suggested. But, it appears the = end-to-end value will get lost with the old draft due to the way call = interactions are handled in enterprise and call center environments. =20 Paul =20 From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: Friday, August 02, 2013 3:56 AM To: keith.drage@alcatel-lucent.com; paulej@packetizer.com; = laura.liess.dt@googlemail.com; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility =20 Putting it another way: Things that work with the kaplan draft should continue to work when a = kaplan compliant implementation interworks with the WG solution = compliant implementations.=20 Things that don't work with the kaplan draft are not expected to work = when a kaplan compliant implementation interworks with the WG solution = compliant implementations however the degraded behavior should be no = worse than between kaplan compliant implementations. Andrew =20 From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Friday, August 02, 2013 02:43 AM Central Standard Time To: Paul E. Jones ; 'Laura Liess' = ; insipid@ietf.org =20 Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility=20 =20 Let us get this clear. =20 The Kaplan draft is not expected to meet all the requirements. If it = did, we would probably be progressing it as the solution document.=20 =20 What the previous decision of the working group effectively required, = when it desired compatibility, was that sensible things should happen as = far as possible when the two solutions interoperated. There is also no = implication that when Kaplan draft meets WG solution that all the = requirements are met. =20 The desire for compatibility is based on the fact that the previous = solution is out there in the field. One solution will meet the other. = One solution should not bomb the other one out. Implementors of the = Kaplan solution will migrate to the real solution at some point and that = intent has been expressed in the meeting several times. But that = migration will not happen overnight as soon as the WG RFCs are = published. =20 Regards =20 Keith =20 _____ =20 From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf Of Paul E. Jones Sent: 01 August 2013 16:00 To: 'Laura Liess'; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility =20 Laura, =20 I assert that old draft will not work for some = =E2=80=9Creal-world=E2=80=9D calls. Calls do get manipulated in = enterprise environments and call centers for billing purposes, privacy = reasons, etc. =20 Consider a common case: if you call into a call center and the agent = puts you on hold while they transfer you to a specialist (transfer out = of consultation), for example, your SIP UA does not receive a REFER to = initiate a new call directly to the specialist. This is handled at the = call center. =20 So rather specifically, how would this be handled (with the old draft)? =20 1) Alice calls Bob (Session-ID: A) 2) Bob puts Alice on hold and calls Carol (Session-ID: B) 3) Bob transfers the call from Alice to Carol using a local transfer = function on the PBX (Session-ID: ??) =20 The PBX could send different values to Alice and Carol, but we totally = lose the end-to-end identification of the call. =20 Alice could not send =E2=80=9CA=E2=80=9D to Carol, since Carol is = expecting B. Likewise, Carol cannot send =E2=80=9CB=E2=80=9D to Alice, = since Alice is expecting =E2=80=9CA=E2=80=9D. Well, they could, and it = would be no worse than our current proposal in terms of = backward-compatibility. =20 Paul =20 From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf Of Laura Liess Sent: Thursday, August 01, 2013 9:13 AM To: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility =20 Hadriel's proposal works for us.=20 Thank you Laura =20 2013/8/1 Hadriel Kaplan This isn't about Enterprise vs. Service-Provider, or Cisco vs. another = vendor. This is just about a Working Group document, and whether the = mechanism defined in it should change the Session-ID header value vs. = parameter based on direction of messages, or not. I totally get the = need to have a distinguishing Session-ID identifier for party-A vs. = party-B. What I don't get is why they need to change the encoding of = the Session-ID header value vs. parameter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" This second model keeps the Session-ID header value as "foo" the whole = time, while adding a parameter of "bar" for Bob that remains a parameter = the whole time. Neither Alice nor Bob are confused about which one is "their" UUID = value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why = it had to be swapped, but I don't remember what it is and I don't see it = in the draft. So I'm trying to find out why we need to do it the way = the draft currently has it. The other topic of whether SBCs will change things is completely = orthogonal to the ordering or backwards compatibility issues, and really = shouldn't be conflated with it at all. It has nothing to do with the = solutions document, or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones = wrote: > Folks, > > I step away for a couple of days and the floodgate opens. :) > > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to = effectively > deal with things like forking, call transfer, park, bridging, = conferencing, > etc. > > When initiating a call and using a single UUID value, that has the = potential > to go end-to-end. However, if a call is forked there are multiple = "ends". > How do we track each of those? For proper diagnostics and = troubleshooting, > it would be ideal to be able to identify which devices have an issue. > > Once a call has been placed, there is a Session-ID established between = Alice > and Bob. If Alice (in one country) transfers Bob (perhaps in the same = or > different country) to a some location in a high-toll country, who pays = the > bill? Well, to address that, we do call transfer locally on PBXes. = The PBX > maintains control over the call and Alice would pay the bill for the = call > transfer. But if Alice was talking to Carol before the transfer, = there is a > Session-ID for that call. If Bob is put in communication with Carol, = what > is the Session-ID value? Bob had one and Carol had a different one. = What > is the new ID? > > It's issues like this that led us to using a two-part value. In this = way, > we could see the call from Alice to Bob has a Session-ID {A,B}. If = Alice > transfers the call to Carol, each device understands that the = Session-ID > changed to {B,C}. Not only that, but intermediaries along the path = that > were not privy to signaling that resulted in this change can take note = of > the fact the value changed. This can provide a useful historical = record, > since previously they might see a call to Carol identified as {A,C}, = but > then it changed to {B,C}. > > This property extends quite naturally to other signaling scenarios, as = it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value = out of > the two. > > Hadriel mentioned the desire to use the Session-ID to correlate media = flows > and calls. That's certainly something Cisco would like to do, but it = is not > the driver behind the solution. Having a valid end-to-end identifier = (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a = solution > that allows us to properly identify calls end-to-end and we recognize = that, > due to various service interactions in the network, these UUID values = can > change. > > I would hope that UUID values will not change to the extent that SBCs = change > them for business reasons. It would certainly defeat the point. = Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that = such > a request effectively breaks the end-to-end model. We can't do much = about > that if they do go down that path. > > As for backward-compatibility, the simplest approach (IMO) is to just = use a > header value not already in use. Originally, we had proposed = Session-UUID. > That was changed at the request of the group to be Session-ID. = However, > when we have a two UUID solution interacting with a one-UUID solution, = we > immediately face some challenges. > > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=3DX > > Does this break things? If so, how do current implementations deal = with > such things as mid-call transfers that happen on a PBX like the one I > described above? > > We could switch the order like this: > Session-ID: X; remote=3DY > > However, that does not work for similar reasons. If we have a call = transfer > where Alice transfers a call with Bob to Carol, then each has a = different > idea about what the proper value is for the first position. > > Originally, the proposed solution did not indicate position = information and > just had single UUID values going in each direction. We then proposed = a > concatenated string (X:Y). However, that presented the same issues for = the > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end = has for > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) > > So, that's why we are where we are. There has been an effort to = maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been = told > explicitly what the issues are. Further, if there are such issues, we = need > to also understand how those would be handled in the face of call = transfer > or "joining" a call locally on a PBX. Those are real-world scenarios = that > we must address. > > Anyway, nothing is set in stone. Anything can be changed, but I would = hope > we can find a solution that works for the enterprise use cases as well = as > the service provider networks. > > 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 =20 =20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful.=20 ------=_NextPart_000_01D5_01CE8F75.B5929070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andrew,

 

Given what Hadriel explained in the email earlier (if I understood it = correctly), the old draft would likely be broken by any PBX that merrily = passed the Session-ID header through end-to-end.

 

Review that flow I presented before:

1)      = Alice calls Bob (Session-ID: A)

2)      = Bob puts Alice on hold

3)      = Bob calls Carol (Session-ID: B)

4)      = Bob =E2=80=9Ctransfers=E2=80=9D (local join) Alice to = Carol

 

At step 4, Alice would send Session-ID =E2=80=9CA=E2=80=9D to Carol = and Carol would send Session-ID =E2=80=9CB=E2=80=9D to Alice.=C2=A0 = Basically, the two endpoints have a different concept of what the = end-to-end value is.

 

We could try to order the UUIDs in the current solution draft so that = we =E2=80=9Cdo not make it worse=E2=80=9D or we could just pick a = different header value to use, as Hadriel suggested.=C2=A0 But, it = appears the end-to-end value will get lost with the old draft due to the = way call interactions are handled in enterprise and call center = environments.

 

Paul

 

From:= = Andrew Allen [mailto:aallen@blackberry.com]
Sent: Friday, = August 02, 2013 3:56 AM
To: keith.drage@alcatel-lucent.com; = paulej@packetizer.com; laura.liess.dt@googlemail.com; = insipid@ietf.org
Subject: Re: [Insipid] Proposed INSIPID = solution and backward compatibility

 


Putting it another way:

Things that work with the kaplan = draft should continue to work when a kaplan compliant implementation = interworks with the WG solution compliant implementations. =

Things that don't work with the kaplan draft are not expected to = work when a kaplan compliant implementation interworks with the WG = solution compliant implementations however the degraded behavior should = be no worse than between kaplan compliant = implementations.

Andrew
 

From<= /b>: DRAGE, = Keith (Keith) [mailto:keith.drage@alcatel= -lucent.com]
Sent: Friday, August 02, 2013 02:43 AM = Central Standard Time
To: Paul E. Jones <paulej@packetizer.com>; = 'Laura Liess' <laura.liess.dt@googlemail.c= om>; insipid@ietf.org = <insipid@ietf.org> =
Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility
 

Le= t us get this clear.

 

Th= e Kaplan draft is not expected to meet all the requirements. If it did, = we would probably be progressing it as the solution document. =

 

Wh= at the previous decision of the working group effectively required, when = it desired compatibility, was that sensible things should happen as far = as possible when the two solutions interoperated. There is also no = implication that when Kaplan draft meets WG solution that all the = requirements are met.

 

Th= e desire for compatibility is based on the fact that the previous = solution is out there in the field. One solution will meet the other. = One solution should not bomb the other one out. Implementors of the = Kaplan solution will migrate to the real solution at some point and that = intent has been expressed in the meeting several times. But that = migration will not happen overnight as soon as the WG RFCs are = published.

 

Re= gards

 

Ke= ith

 

 

Laura,

 

I assert that old draft will not work for some = =E2=80=9Creal-world=E2=80=9D calls.  Calls do get manipulated in = enterprise environments and call centers for billing purposes, privacy = reasons, etc.

 

Consider a common case: if you call into a call center and the agent = puts you on hold while they transfer you to a specialist (transfer out = of consultation), for example, your SIP UA does not receive a = REFER to initiate a new call directly to the specialist.  This is = handled at the call center.

 

So rather specifically, how would this be handled (with the old = draft)?

 

1) Alice calls Bob (Session-ID: A)

2) Bob puts Alice on hold and calls Carol (Session-ID: = B)

3) Bob transfers the call from Alice to Carol using a local transfer = function on the PBX (Session-ID: ??)

 

The PBX could send different values to Alice and Carol, but we = totally lose the end-to-end identification of the = call.

 

Alice could not send =E2=80=9CA=E2=80=9D to Carol, since Carol is = expecting B.  Likewise, Carol cannot send =E2=80=9CB=E2=80=9D to = Alice, since Alice is expecting =E2=80=9CA=E2=80=9D.  Well, they = could, and it would be no worse than our current proposal in terms of = backward-compatibility.

 

Paul

 

 


Hadriel's proposal works for us.

Thank = you
Laura

 

2013/8/1 Hadriel Kaplan <hadriel.kaplan@oracle.com>


This isn't about Enterprise vs. Service-Provider, = or Cisco vs. another vendor.  This is just about a Working Group = document, and whether the mechanism defined in it should change the = Session-ID header value vs. parameter based on direction of messages, or = not.  I totally get the need to have a distinguishing Session-ID = identifier for party-A vs. party-B.  What I don't get is why they = need to change the encoding of the Session-ID header value vs. = parameter, on a message direction basis.

In other words, today = the draft has this:
1) Alice sends INVITE with     = "Session-ID: foo"
2) Bob   sends 18x/200 with   =  "Session-ID: bar;remote=3Dfoo"
3) Alice sends ACK = with        "Session-ID: = foo;remote=3Dbar"
4) Bob   sends BYE with     =    "Session-ID: bar;remote=3Dfoo"
5) Alice sends = 200 with        "Session-ID: = foo;remote=3Dbar"

But we could instead do this:
1) Alice = sends INVITE with     "Session-ID: foo"
2) Bob =   sends 18x/200 with    "Session-ID: = foo;remote=3Dbar"
3) Alice sends ACK with       =  "Session-ID: foo;remote=3Dbar"
4) Bob   sends = BYE with        "Session-ID: = foo;remote=3Dbar"
5) Alice sends 200 with       =  "Session-ID: foo;remote=3Dbar"

This second model = keeps the Session-ID header value as "foo" the whole time, = while adding a parameter of "bar" for Bob that remains a = parameter the whole time.
Neither Alice nor Bob are confused about = which one is "their" UUID value.
And it's = backward-compatible with the previous kaplan-draft.
And it's arguably = easier to implement, for the common cases.

I *think* there was a = reason someone came up with at one time as to why it had to be swapped, = but I don't remember what it is and I don't see it in the draft. =  So I'm trying to find out why we need to do it the way the draft = currently has it.

The other topic of whether SBCs will change = things is completely orthogonal to the ordering or backwards = compatibility issues, and really shouldn't be conflated with it at all. =  It has nothing to do with the solutions document, or the direction = stuff, etc.

-hadriel



On Aug 1, 2013, at 12:38 AM, Paul E. Jones = <paulej@packetizer.com> wrote:

> = Folks,
>
> I step away for a couple of days and the = floodgate opens. :)
>
> I think it's important to understand = why we proposed using a two-part
> Session Identifier.  The = reason is that we have to be able to effectively
> deal with = things like forking, call transfer, park, bridging, = conferencing,
> etc.
>
> When initiating a call and = using a single UUID value, that has the potential
> to go = end-to-end. However, if a call is forked there are multiple = "ends".
> How do we track each of those?  For = proper diagnostics and troubleshooting,
> it would be ideal to be = able to identify which devices have an issue.
>
> Once a = call has been placed, there is a Session-ID established between = Alice
> and Bob.  If Alice (in one country) transfers Bob = (perhaps in the same or
> different country) to a some location in = a high-toll country, who pays the
> bill?  Well, to address = that, we do call transfer locally on PBXes.  The PBX
> = maintains control over the call and Alice would pay the bill for the = call
> transfer.  But if Alice was talking to Carol before = the transfer, there is a
> Session-ID for that call.  If Bob = is put in communication with Carol, what
> is the Session-ID = value?  Bob had one and Carol had a different one. =  What
> is the new ID?
>
> It's issues like this = that led us to using a two-part value.  In this way,
> we = could see the call from Alice to Bob has a Session-ID {A,B}.  If = Alice
> transfers the call to Carol, each device understands that = the Session-ID
> changed to {B,C}.  Not only that, but = intermediaries along the path that
> were not privy to signaling = that resulted in this change can take note of
> the fact the value = changed.  This can provide a useful historical record,
> = since previously they might see a call to Carol identified as {A,C}, = but
> then it changed to {B,C}.
>
> This property = extends quite naturally to other signaling scenarios, as it
> = allows one to identify a call end-to-end, but also establish = some
> relationship between other calls that shared at least one = UUID value out of
> the two.
>
> Hadriel mentioned the = desire to use the Session-ID to correlate media flows
> and calls. =  That's certainly something Cisco would like to do, but it is = not
> the driver behind the solution.  Having a valid = end-to-end identifier (in
> whatever form) allows us to do that. =  We're not suggesting to fit the
> solution to meet that = business use case, but rather we just want a solution
> that = allows us to properly identify calls end-to-end and we recognize = that,
> due to various service interactions in the network, these = UUID values can
> change.
>
> I would hope that UUID = values will not change to the extent that SBCs change
> them for = business reasons.  It would certainly defeat the point. =  Hadriel
> might be right that an SBC vendor might manipulate = those values at the
> request of a customer, but I would hope said = customer appreciates that such
> a request effectively breaks the = end-to-end model.  We can't do much about
> that if they do = go down that path.
>
> As for backward-compatibility, the = simplest approach (IMO) is to just use a
> header value not = already in use.  Originally, we had proposed Session-UUID.
> = That was changed at the request of the group to be Session-ID. =  However,
> when we have a two UUID solution interacting with = a one-UUID solution, we
> immediately face some = challenges.
>
> What happens if an older system sends = this:
>  Session-ID: X
> But then receives = this:
>  Session-ID: Y; remote=3DX
>
> Does this = break things?  If so, how do current implementations deal = with
> such things as mid-call transfers that happen on a PBX like = the one I
> described above?
>
> We could switch the = order like this:
>  Session-ID: X; remote=3DY
>
> = However, that does not work for similar reasons.  If we have a call = transfer
> where Alice transfers a call with Bob to Carol, then = each has a different
> idea about what the proper value is for the = first position.
>
> Originally, the proposed solution did = not indicate position information and
> just had single UUID = values going in each direction.  We then proposed a
> = concatenated string (X:Y). However, that presented the same issues for = the
> call transfer case, so we indicate values by position = (sender's value
> first), so it is clear what value the receive = thinks the remote end has for
> the local end.  It might be = wrong, but that will be corrected in the
> following response. = (Intermediaries can take note of the change.)
>
> So, that's = why we are where we are.  There has been an effort to = maintain
> backward-compatibility, but there are challenges in = meeting that
> requirement.  Where it falls short, we do not = know: we've not been told
> explicitly what the issues are. =  Further, if there are such issues, we need
> to also = understand how those would be handled in the face of call = transfer
> or "joining" a call locally on a PBX. =  Those are real-world scenarios that
> we must = address.
>
> Anyway, nothing is set in stone.  Anything = can be changed, but I would hope
> we can find a solution that = works for the enterprise use cases as well as
> the service = provider networks.
>
> 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<= /o:p>

 

 

------------------------------------------------------------= ---------
This transmission (including any attachments) may contain = confidential information, privileged material (including material = protected by the solicitor-client or other applicable privileges), or = constitute non-public information. Any use of this information by anyone = other than the intended recipient is prohibited. If you have received = this transmission in error, please immediately reply to the sender and = delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is not authorized and may be unlawful. =

------=_NextPart_000_01D5_01CE8F75.B5929070-- From paulej@packetizer.com Fri Aug 2 08:48:24 2013 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 C06BF11E8113 for ; Fri, 2 Aug 2013 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBViV0iMKo5L for ; Fri, 2 Aug 2013 08:48:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 232E711E8158 for ; Fri, 2 Aug 2013 08:48:08 -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 r72Fm601020850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 11:48:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1375458487; bh=89I0G0Cfgta8vHzYHPk5xA9oXldyv4mJCTWqF6MF+VI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=O0L4B6TOo++yOWdM62C5SrsJuFeKvmVC1HmHhyiGY3nypPnmTgJUUubPER9OUuWKQ T6twJtpxAy87TIC6Fkg4cCDkLobPX1BE23DGhuJay58Hae3orOLh3qX4cEqnXKt+bc WByU86esCK+BcQ1wz2Jb5jJwBH/pMB6yFIs4jNLQ= From: "Paul E. Jones" To: "'Laura Liess'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> In-Reply-To: Date: Fri, 2 Aug 2013 11:48:04 -0400 Message-ID: <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E2_01CE8F76.264A27B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVl1P35UA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 15:48:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01E2_01CE8F76.264A27B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Larua, So in effect, the current deployments are not end-to-end, but edge-to-edge somewhere. I can appreciate that, but it does make it more challenging to try to work with when we go all the way end-to-end. Paul From: Laura Liess [mailto:laura.liess.dt@googlemail.com] Sent: Friday, August 02, 2013 4:47 AM To: Paul E. Jones Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Paul, As I said, we never used the old Session-ID to do more than correlate bothe legs of the same dialog. So in your example we have: - Alice to Bob: Session-ID A - Bob to Carol: Session-ID B - Alice to Carol: Session-ID C There is no correlation between them. We just correlate both legs of the same dialog across the SBC between Alice and Bob. Thank you Laura 2013/8/1 Paul E. Jones Laura, The example I show below is a real call center example. I show use of the old session ID. Tell me how that works. Forget about the new solution for the moment. If you say it will not work, then I'm not sure how we can make something work with something that does not work. If there is a way to make this work, then we can try to figure out how to interwork with it. Paul _____ From: Laura Liess Sent: Thu Aug 01 11:51:26 EDT 2013 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Paul, We use the old Session-ID only accross SBCs, to correlate both legs of the same dialog. And it works fine for this use case. We never tried, intend or were required to do more with it. We are not against the new mechanism, we just want it to interwork with the old one which we have in thousands of customer end devices. If it does, we can add new end devices and application servers which support the new Session-ID. Otherwise we can't. Let's see if it works when we keep the UUID order unchanged, as Hadriel proposed. Thank you Laura 2013/8/1 Paul E. Jones Laura, I assert that old draft will not work for some "real-world" calls. Calls do get manipulated in enterprise environments and call centers for billing purposes, privacy reasons, etc. Consider a common case: if you call into a call center and the agent puts you on hold while they transfer you to a specialist (transfer out of consultation), for example, your SIP UA does not receive a REFER to initiate a new call directly to the specialist. This is handled at the call center. So rather specifically, how would this be handled (with the old draft)? 1) Alice calls Bob (Session-ID: A) 2) Bob puts Alice on hold and calls Carol (Session-ID: B) 3) Bob transfers the call from Alice to Carol using a local transfer function on the PBX (Session-ID: ??) The PBX could send different values to Alice and Carol, but we totally lose the end-to-end identification of the call. Alice could not send "A" to Carol, since Carol is expecting B. Likewise, Carol cannot send "B" to Alice, since Alice is expecting "A". Well, they could, and it would be no worse than our current proposal in terms of backward-compatibility. Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Laura Liess Sent: Thursday, August 01, 2013 9:13 AM To: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Hadriel's proposal works for us. Thank you Laura 2013/8/1 Hadriel Kaplan This isn't about Enterprise vs. Service-Provider, or Cisco vs. another vendor. This is just about a Working Group document, and whether the mechanism defined in it should change the Session-ID header value vs. parameter based on direction of messages, or not. I totally get the need to have a distinguishing Session-ID identifier for party-A vs. party-B. What I don't get is why they need to change the encoding of the Session-ID header value vs. parameter, on a message direction basis. In other words, today the draft has this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" 3) Alice sends ACK with "Session-ID: foo;remote=bar" 4) Bob sends BYE with "Session-ID: bar;remote=foo" 5) Alice sends 200 with "Session-ID: foo;remote=bar" But we could instead do this: 1) Alice sends INVITE with "Session-ID: foo" 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" 3) Alice sends ACK with "Session-ID: foo;remote=bar" 4) Bob sends BYE with "Session-ID: foo;remote=bar" 5) Alice sends 200 with "Session-ID: foo;remote=bar" This second model keeps the Session-ID header value as "foo" the whole time, while adding a parameter of "bar" for Bob that remains a parameter the whole time. Neither Alice nor Bob are confused about which one is "their" UUID value. And it's backward-compatible with the previous kaplan-draft. And it's arguably easier to implement, for the common cases. I *think* there was a reason someone came up with at one time as to why it had to be swapped, but I don't remember what it is and I don't see it in the draft. So I'm trying to find out why we need to do it the way the draft currently has it. The other topic of whether SBCs will change things is completely orthogonal to the ordering or backwards compatibility issues, and really shouldn't be conflated with it at all. It has nothing to do with the solutions document, or the direction stuff, etc. -hadriel On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > Folks, > > I step away for a couple of days and the floodgate opens. :) > > I think it's important to understand why we proposed using a two-part > Session Identifier. The reason is that we have to be able to effectively > deal with things like forking, call transfer, park, bridging, conferencing, > etc. > > When initiating a call and using a single UUID value, that has the potential > to go end-to-end. However, if a call is forked there are multiple "ends". > How do we track each of those? For proper diagnostics and troubleshooting, > it would be ideal to be able to identify which devices have an issue. > > Once a call has been placed, there is a Session-ID established between Alice > and Bob. If Alice (in one country) transfers Bob (perhaps in the same or > different country) to a some location in a high-toll country, who pays the > bill? Well, to address that, we do call transfer locally on PBXes. The PBX > maintains control over the call and Alice would pay the bill for the call > transfer. But if Alice was talking to Carol before the transfer, there is a > Session-ID for that call. If Bob is put in communication with Carol, what > is the Session-ID value? Bob had one and Carol had a different one. What > is the new ID? > > It's issues like this that led us to using a two-part value. In this way, > we could see the call from Alice to Bob has a Session-ID {A,B}. If Alice > transfers the call to Carol, each device understands that the Session-ID > changed to {B,C}. Not only that, but intermediaries along the path that > were not privy to signaling that resulted in this change can take note of > the fact the value changed. This can provide a useful historical record, > since previously they might see a call to Carol identified as {A,C}, but > then it changed to {B,C}. > > This property extends quite naturally to other signaling scenarios, as it > allows one to identify a call end-to-end, but also establish some > relationship between other calls that shared at least one UUID value out of > the two. > > Hadriel mentioned the desire to use the Session-ID to correlate media flows > and calls. That's certainly something Cisco would like to do, but it is not > the driver behind the solution. Having a valid end-to-end identifier (in > whatever form) allows us to do that. We're not suggesting to fit the > solution to meet that business use case, but rather we just want a solution > that allows us to properly identify calls end-to-end and we recognize that, > due to various service interactions in the network, these UUID values can > change. > > I would hope that UUID values will not change to the extent that SBCs change > them for business reasons. It would certainly defeat the point. Hadriel > might be right that an SBC vendor might manipulate those values at the > request of a customer, but I would hope said customer appreciates that such > a request effectively breaks the end-to-end model. We can't do much about > that if they do go down that path. > > As for backward-compatibility, the simplest approach (IMO) is to just use a > header value not already in use. Originally, we had proposed Session-UUID. > That was changed at the request of the group to be Session-ID. However, > when we have a two UUID solution interacting with a one-UUID solution, we > immediately face some challenges. > > What happens if an older system sends this: > Session-ID: X > But then receives this: > Session-ID: Y; remote=X > > Does this break things? If so, how do current implementations deal with > such things as mid-call transfers that happen on a PBX like the one I > described above? > > We could switch the order like this: > Session-ID: X; remote=Y > > However, that does not work for similar reasons. If we have a call transfer > where Alice transfers a call with Bob to Carol, then each has a different > idea about what the proper value is for the first position. > > Originally, the proposed solution did not indicate position information and > just had single UUID values going in each direction. We then proposed a > concatenated string (X:Y). However, that presented the same issues for the > call transfer case, so we indicate values by position (sender's value > first), so it is clear what value the receive thinks the remote end has for > the local end. It might be wrong, but that will be corrected in the > following response. (Intermediaries can take note of the change.) > > So, that's why we are where we are. There has been an effort to maintain > backward-compatibility, but there are challenges in meeting that > requirement. Where it falls short, we do not know: we've not been told > explicitly what the issues are. Further, if there are such issues, we need > to also understand how those would be handled in the face of call transfer > or "joining" a call locally on a PBX. Those are real-world scenarios that > we must address. > > Anyway, nothing is set in stone. Anything can be changed, but I would hope > we can find a solution that works for the enterprise use cases as well as > the service provider networks. > > 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 ------=_NextPart_000_01E2_01CE8F76.264A27B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Larua,

 

So in effect, the current deployments are not end-to-end, but = edge-to-edge somewhere.  I can appreciate that, but it does make it = more challenging to try to work with when we go all the way = end-to-end.

 

Paul

 

From:= = Laura Liess [mailto:laura.liess.dt@googlemail.com]
Sent: = Friday, August 02, 2013 4:47 AM
To: Paul E. = Jones
Cc: insipid@ietf.org
Subject: Re: [Insipid] = Proposed INSIPID solution and backward = compatibility

 

Paul,

As I said, we never used the = old Session-ID to do more than correlate bothe legs of the same = dialog.  So in your example we have:
- Alice to Bob: Session-ID = A
- Bob to Carol: Session-ID B
- Alice to Carol: Session-ID = C

There is no correlation between them. We just correlate both = legs of the same dialog  across the SBC between Alice and = Bob. 

Thank you
Laura


2013/8/1 Paul E. Jones <paulej@packetizer.com>

Lau= ra,

The example I show below is a real call center = example. I show use of the old session ID. Tell me how that works. = Forget about the new solution for the moment.

If you = say it will not work, then I'm not sure how we can make something work = with something that does not work. If there is a way to make this work, = then we can try to figure out how to interwork with = it.

Paul

 

From:= = Laura Liess <laura.liess.dt@googlemail.com>
Sent: = Thu Aug 01 11:51:26 EDT 2013


To: "Paul E. Jones" <paulej@packetizer.com>

Cc: insipid@ietf.org


Subje= ct: Re: [Insipid] Proposed INSIPID solution and backward = compatibility


Paul,
We use the old Session-ID only = accross SBCs, to correlate both legs of the same dialog. And it works = fine for this use case. We never tried, intend  or were required to = do more with it.
 We are not against the new mechanism, we just = want it to interwork with the old one which we have in thousands of = customer end devices. If it does, we can add new end devices and = application servers which support the new Session-ID. Otherwise we = can't. 

Let's see if = it works when we keep the UUID order unchanged, as Hadriel proposed. =

Thank = you
Laura

2013/8/1 Paul E. Jones <paulej@packetizer.com>

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Laura,

 

I assert that old draft will not work for some = “real-world” calls.  Calls do get manipulated in = enterprise environments and call centers for billing purposes, privacy = reasons, etc.

 

Consider a common case: if you call into a call center and the agent = puts you on hold while they transfer you to a specialist (transfer out = of consultation), for example, your SIP UA does not receive a = REFER to initiate a new call directly to the specialist.  This is = handled at the call center.

 

So rather specifically, how would this be handled (with the old = draft)?

 

1) Alice calls Bob (Session-ID: A)

2) Bob puts Alice on hold and calls Carol (Session-ID: = B)

3) Bob transfers the call from Alice to Carol using a local transfer = function on the PBX (Session-ID: ??)

 

The PBX could send different values to Alice and Carol, but we = totally lose the end-to-end identification of the = call.

 

Alice could not send “A” to Carol, since Carol is = expecting B.  Likewise, Carol cannot send “B” to Alice, = since Alice is expecting “A”.  Well, they could, and it = would be no worse than our current proposal in terms of = backward-compatibility.

 

Paul

 

From:= = insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of = Laura Liess
Sent: Thursday, August 01, 2013 9:13 = AM
To: insipid@ietf.org


Subject: Re: [Insipid] Proposed INSIPID = solution and backward compatibility

 <= /o:p>

 <= /o:p>

Hadriel's proposal works for us. =

Thank you
Laura

<= div>

 <= /p>

2013/8/1 = Hadriel Kaplan <hadriel.kaplan@oracle.com>


This = isn't about Enterprise vs. Service-Provider, or Cisco vs. another = vendor.  This is just about a Working Group document, and whether = the mechanism defined in it should change the Session-ID header value = vs. parameter based on direction of messages, or not.  I totally = get the need to have a distinguishing Session-ID identifier for party-A = vs. party-B.  What I don't get is why they need to change the = encoding of the Session-ID header value vs. parameter, on a message = direction basis.

In other words, today the draft has this:
1) = Alice sends INVITE with     "Session-ID: foo"
2) = Bob   sends 18x/200 with    "Session-ID: = bar;remote=3Dfoo"
3) Alice sends ACK with       =  "Session-ID: foo;remote=3Dbar"
4) Bob   sends = BYE with        "Session-ID: = bar;remote=3Dfoo"
5) Alice sends 200 with       =  "Session-ID: foo;remote=3Dbar"

But we could = instead do this:
1) Alice sends INVITE with     = "Session-ID: foo"
2) Bob   sends 18x/200 with   =  "Session-ID: foo;remote=3Dbar"
3) Alice sends ACK = with        "Session-ID: = foo;remote=3Dbar"
4) Bob   sends BYE with     =    "Session-ID: foo;remote=3Dbar"
5) Alice sends = 200 with        "Session-ID: = foo;remote=3Dbar"

This second model keeps the Session-ID = header value as "foo" the whole time, while adding a parameter = of "bar" for Bob that remains a parameter the whole = time.
Neither Alice nor Bob are confused about which one is = "their" UUID value.
And it's backward-compatible with the = previous kaplan-draft.
And it's arguably easier to implement, for the = common cases.

I *think* there was a reason someone came up with = at one time as to why it had to be swapped, but I don't remember what it = is and I don't see it in the draft.  So I'm trying to find out why = we need to do it the way the draft currently has it.

The other = topic of whether SBCs will change things is completely orthogonal to the = ordering or backwards compatibility issues, and really shouldn't be = conflated with it at all.  It has nothing to do with the solutions = document, or the direction stuff, etc.

-hadriel



On = Aug 1, 2013, at 12:38 AM, Paul E. Jones <paulej@packetizer.com> wrote:

> = Folks,
>
> I step away for a couple of days and the = floodgate opens. :)
>
> I think it's important to understand = why we proposed using a two-part
> Session Identifier.  The = reason is that we have to be able to effectively
> deal with = things like forking, call transfer, park, bridging, = conferencing,
> etc.
>
> When initiating a call and = using a single UUID value, that has the potential
> to go = end-to-end. However, if a call is forked there are multiple = "ends".
> How do we track each of those?  For = proper diagnostics and troubleshooting,
> it would be ideal to be = able to identify which devices have an issue.
>
> Once a = call has been placed, there is a Session-ID established between = Alice
> and Bob.  If Alice (in one country) transfers Bob = (perhaps in the same or
> different country) to a some location in = a high-toll country, who pays the
> bill?  Well, to address = that, we do call transfer locally on PBXes.  The PBX
> = maintains control over the call and Alice would pay the bill for the = call
> transfer.  But if Alice was talking to Carol before = the transfer, there is a
> Session-ID for that call.  If Bob = is put in communication with Carol, what
> is the Session-ID = value?  Bob had one and Carol had a different one. =  What
> is the new ID?
>
> It's issues like this = that led us to using a two-part value.  In this way,
> we = could see the call from Alice to Bob has a Session-ID {A,B}.  If = Alice
> transfers the call to Carol, each device understands that = the Session-ID
> changed to {B,C}.  Not only that, but = intermediaries along the path that
> were not privy to signaling = that resulted in this change can take note of
> the fact the value = changed.  This can provide a useful historical record,
> = since previously they might see a call to Carol identified as {A,C}, = but
> then it changed to {B,C}.
>
> This property = extends quite naturally to other signaling scenarios, as it
> = allows one to identify a call end-to-end, but also establish = some
> relationship between other calls that shared at least one = UUID value out of
> the two.
>
> Hadriel mentioned the = desire to use the Session-ID to correlate media flows
> and calls. =  That's certainly something Cisco would like to do, but it is = not
> the driver behind the solution.  Having a valid = end-to-end identifier (in
> whatever form) allows us to do that. =  We're not suggesting to fit the
> solution to meet that = business use case, but rather we just want a solution
> that = allows us to properly identify calls end-to-end and we recognize = that,
> due to various service interactions in the network, these = UUID values can
> change.
>
> I would hope that UUID = values will not change to the extent that SBCs change
> them for = business reasons.  It would certainly defeat the point. =  Hadriel
> might be right that an SBC vendor might manipulate = those values at the
> request of a customer, but I would hope said = customer appreciates that such
> a request effectively breaks the = end-to-end model.  We can't do much about
> that if they do = go down that path.
>
> As for backward-compatibility, the = simplest approach (IMO) is to just use a
> header value not = already in use.  Originally, we had proposed Session-UUID.
> = That was changed at the request of the group to be Session-ID. =  However,
> when we have a two UUID solution interacting with = a one-UUID solution, we
> immediately face some = challenges.
>
> What happens if an older system sends = this:
>  Session-ID: X
> But then receives = this:
>  Session-ID: Y; remote=3DX
>
> Does this = break things?  If so, how do current implementations deal = with
> such things as mid-call transfers that happen on a PBX like = the one I
> described above?
>
> We could switch the = order like this:
>  Session-ID: X; remote=3DY
>
> = However, that does not work for similar reasons.  If we have a call = transfer
> where Alice transfers a call with Bob to Carol, then = each has a different
> idea about what the proper value is for the = first position.
>
> Originally, the proposed solution did = not indicate position information and
> just had single UUID = values going in each direction.  We then proposed a
> = concatenated string (X:Y). However, that presented the same issues for = the
> call transfer case, so we indicate values by position = (sender's value
> first), so it is clear what value the receive = thinks the remote end has for
> the local end.  It might be = wrong, but that will be corrected in the
> following response. = (Intermediaries can take note of the change.)
>
> So, that's = why we are where we are.  There has been an effort to = maintain
> backward-compatibility, but there are challenges in = meeting that
> requirement.  Where it falls short, we do not = know: we've not been told
> explicitly what the issues are. =  Further, if there are such issues, we need
> to also = understand how those would be handled in the face of call = transfer
> or "joining" a call locally on a PBX. =  Those are real-world scenarios that
> we must = address.
>
> Anyway, nothing is set in stone.  Anything = can be changed, but I would hope
> we can find a solution that = works for the enterprise use cases as well as
> the service = provider networks.
>
> 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<= /o:p>

 <= /o:p>

 <= /o:p>

 

 

------=_NextPart_000_01E2_01CE8F76.264A27B0-- From hadriel.kaplan@oracle.com Fri Aug 2 11:04:33 2013 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 1D53611E8124 for ; Fri, 2 Aug 2013 11:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS87kxoLUGQr for ; Fri, 2 Aug 2013 11:04:26 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 85FE911E80EE for ; Fri, 2 Aug 2013 11:04:21 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r72I4ATw022297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 18:04:11 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72I48Oh016673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 18:04:09 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72I48Sp009102; Fri, 2 Aug 2013 18:04:08 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Aug 2013 11:04:08 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01ba01ce8f92$316b35f0$9441a1d0$@packetizer.com> Date: Fri, 2 Aug 2013 14:04:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66E3AAF9-0D71-468D-8D43-3565634746AB@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <00bc01ce8eba$b20b2860$16217920$@packetizer.com> <008b01ce8eef$f4924e40$ddb6eac0$@packetizer.com> <26ED0D3B-6F85-4C06-B189-70F22CAD53A8@oracle.com> <009c01ce8ef8$7906b780$6b142680$@packetizer.com> <6A36BEEC-B69D-4B39-A1E5-C988462DDB61@oracle.com> <01ba01ce8f92$316b35f0$9441a1d0$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 18:04:33 -0000 On Aug 2, 2013, at 11:08 AM, Paul E. Jones = wrote: >> OK I understand. I would point out though, that this is one case = where I >> bet people would have SBCs block this change from propagating out. = Some >> people don't like re-INVITEs/UPDATEs propagating out, for changes = that >> occur inside an Enterprise... whatsoever. I.e., if Alice is calling = into >> an Enterprise from a SIP Trunk, my guess is there'll be some cases = where >> the SBCs are configured to locally answer re-INVITES/UPDATEs coming = from >> the Enterprise side. We've been told to do this both in cases when = we get >> deployed as Service Provider-side and cases where we're = Enterprise-side >> SBCs, of SIP Trunks.[1] >=20 > You might be right, but then those folks lose the benefits of having = an > end-to-end identifier. I can't force people not to do something, even = if > the standard says not to do it :-( Right, but the basic premise of the old Session-ID was that the = mechanism was "benign", and thus did not have a reason for the admins of = middleboxes to muck with it. Having devices send re-INVITEs/UPDATEs to = change the session-id value, or using it for call success/failure = impacting purposes, makes it no longer benign. In the former case it = generates more message traffic, and in the latter it impacts call = control. I'm not saying we can't do it - I'm just saying we need to be aware of = what we're doing by no longer keeping it a benign mechanism. In = particular, that we can't argue middleboxes shouldn't muck with it, and = any belief it will truly be end-to-end someday across domains can no = longer be assumed. -hadriel From pkyzivat@alum.mit.edu Fri Aug 2 12:50:43 2013 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 63BF411E80A2 for ; Fri, 2 Aug 2013 12:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePXkOmC72hzB for ; Fri, 2 Aug 2013 12:50:38 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id CC20D11E80FB for ; Fri, 2 Aug 2013 12:50:38 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta14.emeryville.ca.mail.comcast.net with comcast id 7pYC1m0021bwxycAEvqes2; Fri, 02 Aug 2013 19:50:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([89.246.150.136]) by omta18.emeryville.ca.mail.comcast.net with comcast id 7voG1m00D2wpE7M8evoNC5; Fri, 02 Aug 2013 19:48:33 +0000 Message-ID: <51FC0CFB.3020400@alum.mit.edu> Date: Fri, 02 Aug 2013 21:48:11 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: insipid@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B07AB6E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07AB6E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375473038; bh=RRlUMyzMZ2mW/3AtP8LH3IhF5ezUMd7kl3FIJ+bnajI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QIQ7JQoWs6+r+s7B+m+Rn3bKHpE4qyHYXAjoXJkjsBo3+law9BHoDNzCys+LKo4oE vfcmKQjT4j5mueTZpBeDHQZF8aVpgfXi8RDKRuddGoGEzKHPxwHixCemV0oHCv4Y6W P9giDpZvyO8z/ESBRL7ArLoO7ygWxd/KSQAfly/piF6+4wENx79dq77Znnxa0sq5Wx RZq7uwoblzrJ7F6E7LkEwLB7CYbdNJhYg/SemSe1tyfnN4OQcVYysXMX1UP3HQi3i7 +vTviFgYiuBPnPTN6hRl4gm5ToQELvMBIprf7ybJjkdlZTbBDOeXGhORsHraDFw1t5 ILT7ARUcsz9Iw== Subject: Re: [Insipid] Progressing logme requirements X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 19:50:43 -0000 I commented on this previously: http://www.ietf.org/mail-archive/web/insipid/current/msg00582.html Thanks, Paul On 8/2/13 11:45 AM, DRAGE, Keith (Keith) wrote: > In the meantime there is no reason why work cannot start on the requirements draft. Please feel free to either comment on, or improve on Peter's document > > https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/ From hadriel.kaplan@oracle.com Fri Aug 2 14:36:10 2013 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 9F7E111E80D2 for ; Fri, 2 Aug 2013 14:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.208 X-Spam-Level: X-Spam-Status: No, score=-6.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEyPe9ES-r12 for ; Fri, 2 Aug 2013 14:36:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3F11E80D7 for ; Fri, 2 Aug 2013 14:36:05 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r72La1BH003811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 21:36:03 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72LZxh4016381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 21:35:59 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72LZwjE006653; Fri, 2 Aug 2013 21:35:58 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Aug 2013 14:35:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01c901ce8f94$13beb480$3b3c1d80$@packetizer.com> Date: Fri, 2 Aug 2013 16:49:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01c901ce8f94$13beb480$3b3c1d80$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 21:36:10 -0000 Ummm... in what way is it *not* about tracking the media? The scenario = you'd like to cover is one where there are two separate SIP sessions = through a PBX, and the PBX "joins" them at a media layer but doesn't = change things at a SIP layer other than to send a re-INVITE/UPDATE to = change the Session-ID value. I totally get that PBXs do that - I know they frequently do it that way. = (heck, some SBCs do too these days) But all that is really being = tracked/correlated is the media. We went through multiple rounds of = discussion in DISPATCH about Session-ID, where I tried to describe what = the "thing" was that it correlated. At one point I even tried to = describe it as correlating things that shared fate (ie, if Alice hangs = up, the other SIP dialogs would too), but conference bridge dialogs = didn't exhibit that behavior, and neither did PBX dialogs in some cases. = We also talked about it correlating media sessions instead, but we knew = that required the re-INVITE/UPDATEs and at the time the consensus was = not to do it. (That changed in the INSIPID WG, obviously) Ultimately the thing we agreed on was that the legacy Session-ID = correlated things as the Call-ID would have done, had B2BUAs not changed = the Call-ID. So the original "call" from Alice through the PBX to Bob = would be the same Session-ID, but the Bob-Carol one was a different one, = and if the PBX joined Alice and Carol at a media layer without really = doing REFER/IWR, then it's still two separate Session-IDs because in = that case the PBX is truly acting as two separate User Agent "ends" and = there is no real *SIP* relationship between Alice and Carol. I get why you want to do it, but my point was it's not what the legacy = draft was trying to accomplish. =20 Other comments inline... On Aug 2, 2013, at 11:22 AM, Paul E. Jones = wrote: > The new solution is not focused on media flow tracking. Let me be = clear. > We just need a Session-ID. Once we have one, then we can do other > interesting things with it. We did want to solve then end-to-end = problem, > appreciating the fact that the ends do move around sometimes. So, = while > Alice might start out talking to Bob, she might get switched over to = Carol. > This is extremely common, especially in call centers (but also if you = call > my desk and I transfer you somewhere else). Yup, I know it's common in call-centers. > Re-INVITE for transfers is often needed, because audio/video = capabilities > change. Media ports might change, too. In most transfer cases, calls = are > put on hold and sometimes media is halted entirely, at least in one > direction. Yup, but in the cases where the SBC on the SIP trunk locally answers the = re-INVITE, it hides those media changes from the Service Provider. The = rest of the world doesn't need to know that the media address/ports = changed, or that it got put on hold. (some PBXs do that too, instead of = the SBC - the PBX doesn't send re-INVITEs up the SIP trunk, but just = locally moves stuff around and plays music on hold and so on) > I'm certainly OK with trying to figure out how to interwork with the > previous draft, but it looks like it might be too constraining by not > supporting transfers and such. In effect, it's not always end-to-end. The legacy draft supports "transfers" - it supports them when they're = truly SIP transfers. It doesn't support identifying media switching. This new draft won't be end-to-end either in the real world. It might = well be end-to-end within a domain, but across domains I'm pretty sure = it won't be.=20 > I'm certainly OK, too, with a new header value, though "Media-ID" is = not > quite right. This is intended to identify the session. =20 What does the word "session" mean to you in this context? > Perhaps just > "Sess-ID"? >=20 > Paul >=20 >> Forgetting about the new solution... the old solution worked because = it >> never claimed or attempted to solve the problem you're trying to = solve. It >> was just to help with troubleshooting; and because it was just to = help >> with troubleshooting it was kept as simple as possible in order to = make it >> easy to implement, and so as not to cause a need to troubleshoot the >> troubleshooting tool. Due to that, it does support call transfers = being >> tracked by a Session-ID when REFERs and INVITE w/replaces were used = for >> the transfer; but not when SIP itself didn't change at all, and = instead a >> media-bridge switches around what media is going to whom. Session-ID >> wasn't really meant to be a media-flow tracking mechanism originally. >>=20 >> When this was in DISPATCH, we talked about sending re-INVITEs/UPDATEs = to >> modify the Session-ID in case of hidden transfers and such - but the >> general consensus at that time was not to bother. It would be insane = to >> expect things to send re-INVITEs/UPDATEs all over the place to >> update/change Session-ID values just to help troubleshooting - who = would >> want a troubleshooting-aid thing to do that really? So we basically >> decided not to do that, and instead keep it simple and lightweight. >>=20 >> That's why I argued so much originally against adding the extra >> requirements to track hidden transfers and conference servers and = such. >> It requires sending re-INVITEs/UPDATEs to all parties, and I had a = hard >> time believing folks would really want that to happen in practice. = But >> the WG decided it was worth it, and to have the requirement; but = meanwhile >> to not break backwards compatibility. So I think there're two ways = to go >> about it: either (1) work around the limitations of the legacy = individual >> draft, or (2) pick a new header name "Media-ID" or some such and not = be >> constrained by the old draft. >>=20 >> -hadriel >> p.s. personally I'd be ok with either option-1 or option-2, fwiw. >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From hadriel.kaplan@oracle.com Fri Aug 2 14:39:50 2013 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 12D4E11E80F9 for ; Fri, 2 Aug 2013 14:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaTFHO7rQP6X for ; Fri, 2 Aug 2013 14:39:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD711E80D7 for ; Fri, 2 Aug 2013 14:39:38 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r72LdY0n015277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 21:39:35 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72LdXOf022712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 21:39:34 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72LdX7G007751; Fri, 2 Aug 2013 21:39:33 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Aug 2013 14:39:32 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> Date: Fri, 2 Aug 2013 17:07:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 21:39:50 -0000 I can't tell if you seriously believe the new mechanism is going to work = end-to-end across all domains, or if you just mean end-to-end within a = domain (like within the call-center). I don't mean that in a negative = way - I just mean I don't understand how you mean the words = "end-to-end". I seriously doubt this thing is going to achieve any more than the = legacy draft did in terms of true end-to-end across-the-world type = thing. In fact it may even do less. When I make a call from my cell phone through my mobile provider, = through N number of carriers, to an Enterprise call-center somewhere in = Timbuktu, I have a hard time believing all the carriers and mobile = providers want to get back and process a re-INVITE each and every time = the call gets moved around inside the call-center's internal PBX = infrastructure. They rarely get that today, and I don't see them = changing in the future to do so... for what benefit? What use is it to = update all the SIP systems along the path, as well as my cell phone, = with a new Session-ID value just because the call got parked/unparked or = internally transferred inside PBX/ACD/etc. systems in a call-center = somewhere? Some call centers move the media around almost a dozen times per call. = You really think the rest of the world wants to get a dozen re-INVITEs, = for no benefit? The SBCs aren't answering the re-INVITEs locally today = to hide the identity of who/what it gets moved around to - that we = already do even when we forward the re-INVITEs - we're answering them = locally because the service providers don't want nor need those = re-INVITEs. It's just extra processing load, log entries, and things = that can go wrong; with no added benefit. -hadriel On Aug 2, 2013, at 11:48 AM, Paul E. Jones = wrote: > Larua, > =20 > So in effect, the current deployments are not end-to-end, but = edge-to-edge somewhere. I can appreciate that, but it does make it more = challenging to try to work with when we go all the way end-to-end. > =20 > Paul > =20 > From: Laura Liess [mailto:laura.liess.dt@googlemail.com]=20 > Sent: Friday, August 02, 2013 4:47 AM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility > =20 > Paul, >=20 > As I said, we never used the old Session-ID to do more than correlate = bothe legs of the same dialog. So in your example we have:=20 > - Alice to Bob: Session-ID A > - Bob to Carol: Session-ID B > - Alice to Carol: Session-ID C >=20 > There is no correlation between them. We just correlate both legs of = the same dialog across the SBC between Alice and Bob. =20 >=20 > Thank you > Laura >=20 >=20 >=20 > 2013/8/1 Paul E. Jones > Laura, >=20 > The example I show below is a real call center example. I show use of = the old session ID. Tell me how that works. Forget about the new = solution for the moment. >=20 > If you say it will not work, then I'm not sure how we can make = something work with something that does not work. If there is a way to = make this work, then we can try to figure out how to interwork with it. >=20 > Paul >=20 > =20 >=20 > From: Laura Liess > Sent: Thu Aug 01 11:51:26 EDT 2013 >=20 > To: "Paul E. Jones" > Cc: insipid@ietf.org >=20 > Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility >=20 > Paul, > We use the old Session-ID only accross SBCs, to correlate both legs of = the same dialog. And it works fine for this use case. We never tried, = intend or were required to do more with it. > We are not against the new mechanism, we just want it to interwork = with the old one which we have in thousands of customer end devices. If = it does, we can add new end devices and application servers which = support the new Session-ID. Otherwise we can't. =20 >=20 > Let's see if it works when we keep the UUID order unchanged, as = Hadriel proposed.=20 >=20 > Thank you > Laura >=20 >=20 > 2013/8/1 Paul E. Jones > Laura, > =20 > I assert that old draft will not work for some =93real-world=94 calls. = Calls do get manipulated in enterprise environments and call centers = for billing purposes, privacy reasons, etc. > =20 > Consider a common case: if you call into a call center and the agent = puts you on hold while they transfer you to a specialist (transfer out = of consultation), for example, your SIP UA does not receive a REFER to = initiate a new call directly to the specialist. This is handled at the = call center. > =20 > So rather specifically, how would this be handled (with the old = draft)? > =20 > 1) Alice calls Bob (Session-ID: A) > 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > 3) Bob transfers the call from Alice to Carol using a local transfer = function on the PBX (Session-ID: ??) > =20 > The PBX could send different values to Alice and Carol, but we totally = lose the end-to-end identification of the call. > =20 > Alice could not send =93A=94 to Carol, since Carol is expecting B. = Likewise, Carol cannot send =93B=94 to Alice, since Alice is expecting = =93A=94. Well, they could, and it would be no worse than our current = proposal in terms of backward-compatibility. > =20 > Paul > =20 > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf Of Laura Liess > Sent: Thursday, August 01, 2013 9:13 AM > To: insipid@ietf.org >=20 > Subject: Re: [Insipid] Proposed INSIPID solution and backward = compatibility > =20 > =20 > Hadriel's proposal works for us.=20 >=20 > Thank you > Laura > =20 >=20 > 2013/8/1 Hadriel Kaplan >=20 > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another = vendor. This is just about a Working Group document, and whether the = mechanism defined in it should change the Session-ID header value vs. = parameter based on direction of messages, or not. I totally get the = need to have a distinguishing Session-ID identifier for party-A vs. = party-B. What I don't get is why they need to change the encoding of = the Session-ID header value vs. parameter, on a message direction basis. >=20 > In other words, today the draft has this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >=20 > But we could instead do this: > 1) Alice sends INVITE with "Session-ID: foo" > 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >=20 > This second model keeps the Session-ID header value as "foo" the whole = time, while adding a parameter of "bar" for Bob that remains a parameter = the whole time. > Neither Alice nor Bob are confused about which one is "their" UUID = value. > And it's backward-compatible with the previous kaplan-draft. > And it's arguably easier to implement, for the common cases. >=20 > I *think* there was a reason someone came up with at one time as to = why it had to be swapped, but I don't remember what it is and I don't = see it in the draft. So I'm trying to find out why we need to do it the = way the draft currently has it. >=20 > The other topic of whether SBCs will change things is completely = orthogonal to the ordering or backwards compatibility issues, and really = shouldn't be conflated with it at all. It has nothing to do with the = solutions document, or the direction stuff, etc. >=20 > -hadriel >=20 >=20 > On Aug 1, 2013, at 12:38 AM, Paul E. Jones = wrote: >=20 > > Folks, > > > > I step away for a couple of days and the floodgate opens. :) > > > > I think it's important to understand why we proposed using a = two-part > > Session Identifier. The reason is that we have to be able to = effectively > > deal with things like forking, call transfer, park, bridging, = conferencing, > > etc. > > > > When initiating a call and using a single UUID value, that has the = potential > > to go end-to-end. However, if a call is forked there are multiple = "ends". > > How do we track each of those? For proper diagnostics and = troubleshooting, > > it would be ideal to be able to identify which devices have an = issue. > > > > Once a call has been placed, there is a Session-ID established = between Alice > > and Bob. If Alice (in one country) transfers Bob (perhaps in the = same or > > different country) to a some location in a high-toll country, who = pays the > > bill? Well, to address that, we do call transfer locally on PBXes. = The PBX > > maintains control over the call and Alice would pay the bill for the = call > > transfer. But if Alice was talking to Carol before the transfer, = there is a > > Session-ID for that call. If Bob is put in communication with = Carol, what > > is the Session-ID value? Bob had one and Carol had a different one. = What > > is the new ID? > > > > It's issues like this that led us to using a two-part value. In = this way, > > we could see the call from Alice to Bob has a Session-ID {A,B}. If = Alice > > transfers the call to Carol, each device understands that the = Session-ID > > changed to {B,C}. Not only that, but intermediaries along the path = that > > were not privy to signaling that resulted in this change can take = note of > > the fact the value changed. This can provide a useful historical = record, > > since previously they might see a call to Carol identified as {A,C}, = but > > then it changed to {B,C}. > > > > This property extends quite naturally to other signaling scenarios, = as it > > allows one to identify a call end-to-end, but also establish some > > relationship between other calls that shared at least one UUID value = out of > > the two. > > > > Hadriel mentioned the desire to use the Session-ID to correlate = media flows > > and calls. That's certainly something Cisco would like to do, but = it is not > > the driver behind the solution. Having a valid end-to-end = identifier (in > > whatever form) allows us to do that. We're not suggesting to fit = the > > solution to meet that business use case, but rather we just want a = solution > > that allows us to properly identify calls end-to-end and we = recognize that, > > due to various service interactions in the network, these UUID = values can > > change. > > > > I would hope that UUID values will not change to the extent that = SBCs change > > them for business reasons. It would certainly defeat the point. = Hadriel > > might be right that an SBC vendor might manipulate those values at = the > > request of a customer, but I would hope said customer appreciates = that such > > a request effectively breaks the end-to-end model. We can't do much = about > > that if they do go down that path. > > > > As for backward-compatibility, the simplest approach (IMO) is to = just use a > > header value not already in use. Originally, we had proposed = Session-UUID. > > That was changed at the request of the group to be Session-ID. = However, > > when we have a two UUID solution interacting with a one-UUID = solution, we > > immediately face some challenges. > > > > What happens if an older system sends this: > > Session-ID: X > > But then receives this: > > Session-ID: Y; remote=3DX > > > > Does this break things? If so, how do current implementations deal = with > > such things as mid-call transfers that happen on a PBX like the one = I > > described above? > > > > We could switch the order like this: > > Session-ID: X; remote=3DY > > > > However, that does not work for similar reasons. If we have a call = transfer > > where Alice transfers a call with Bob to Carol, then each has a = different > > idea about what the proper value is for the first position. > > > > Originally, the proposed solution did not indicate position = information and > > just had single UUID values going in each direction. We then = proposed a > > concatenated string (X:Y). However, that presented the same issues = for the > > call transfer case, so we indicate values by position (sender's = value > > first), so it is clear what value the receive thinks the remote end = has for > > the local end. It might be wrong, but that will be corrected in the > > following response. (Intermediaries can take note of the change.) > > > > So, that's why we are where we are. There has been an effort to = maintain > > backward-compatibility, but there are challenges in meeting that > > requirement. Where it falls short, we do not know: we've not been = told > > explicitly what the issues are. Further, if there are such issues, = we need > > to also understand how those would be handled in the face of call = transfer > > or "joining" a call locally on a PBX. Those are real-world = scenarios that > > we must address. > > > > Anyway, nothing is set in stone. Anything can be changed, but I = would hope > > we can find a solution that works for the enterprise use cases as = well as > > the service provider networks. > > > > Paul > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > =20 > =20 > =20 > =20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From hadriel.kaplan@oracle.com Fri Aug 2 14:39:51 2013 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 984FB21E80B0 for ; Fri, 2 Aug 2013 14:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFZM41d+dmEZ for ; Fri, 2 Aug 2013 14:39:45 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id A88CD11E8108 for ; Fri, 2 Aug 2013 14:39:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r72LdeX0006590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 21:39:40 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72Ldd6T005674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Aug 2013 21:39:39 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r72LdcXe007881; Fri, 2 Aug 2013 21:39:38 GMT Received: from [10.13.41.242] (/217.194.78.58) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 02 Aug 2013 14:39:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> Date: Fri, 2 Aug 2013 17:34:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 21:39:51 -0000 On Aug 2, 2013, at 11:48 AM, Paul E. Jones = wrote: > So in effect, the current deployments are not end-to-end, but = edge-to-edge somewhere. I can appreciate that, but it does make it more = challenging to try to work with when we go all the way end-to-end.=20 Actually I know of one current deployment where it is end-to-end, within = the domain of the provider.=20 But regardless, of course it's not world-wide end-to-end yet. It will = take a very long time for that to happen, assuming it ever does. = There's no "flag day" to switch over all systems in the World, let alone = even all systems within a service provider's domain. This isn't like a = typical medium-sized Enterprise, with all equipment from one or two = vendors in a couple of data rooms. Carriers have hundreds of SIP = systems, from dozens of vendors, doing all kinds of different things. = Even an "IMS-compliant" network doesn't upgrade everything all at once = to a new release. They typically upgrade one cluster of core components = at a time, like the P/I/S-CSCF for a region for example. The = Application Servers appear to upgrade less frequently - the carriers add = new app-servers for new features introduced by a new IMS release, but = they often don't need to upgrade the ones that do features from a = previous release. If it ain't broke, they don't usually fix it. I think any solution we come up with had better not expect all systems = everywhere to change overnight. Even ignoring the legacy kaplan draft = completely - whatever we come up with in INSIPID is going to be deployed = edge-to-edge for a long time. -hadriel From jmpolk@cisco.com Tue Aug 6 12:14:21 2013 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 7CC0F21E8085 for ; Tue, 6 Aug 2013 12:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.549 X-Spam-Level: X-Spam-Status: No, score=-111.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnnDVptgPE6K for ; Tue, 6 Aug 2013 12:14:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFF021E80B8 for ; Tue, 6 Aug 2013 12:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6198; q=dns/txt; s=iport; t=1375816455; x=1377026055; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=4/Vfd5JYPZ0g82Q9XbfSAK0+pYosCfRUCLS4PpMxSDk=; b=BEJ+q/RMPNvTSRPvLY/TAiDYx5SUJKp+SXscFVPk+jpW38GsXHtYvRWJ OIBTGUi4fpdCQ7APNxOsECZAWQdDytydpYsr/RQOzuddyNVHTViaIsa3i pyGM2IPdr0T1HwCpTcN7oJHu1oIwpPGRcaBzfD2V4IvGqMf4ze+z8HIE3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAItKAVKtJV2a/2dsb2JhbABQCgGDBTW/TYEfFnSCJAEBAQQBAQE1Ai0HGwcEDgoJFRAPCg4wBgESG4d1DLcxjkkLBoFHhA4DiSuPYJAkgzUegSwFBBc X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244239463" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 06 Aug 2013 19:14:12 +0000 Received: from jmpolk-WS.cisco.com ([10.89.8.39]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r76JEBAR018455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 19:14:12 GMT Message-Id: <201308061914.r76JEBAR018455@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Aug 2013 14:13:48 -0500 To: Hadriel Kaplan , "insipid@ietf.org" From: James Polk In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] publishing draft-kaplan session-id as historic X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:14:21 -0000 Hadriel https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ shows an intended status of "informational", not "historic" as you agreed. I believe that needs to be corrected. James At 03:36 PM 3/13/2013, Hadriel Kaplan wrote: > From today's meeting action I took... below was the email. >The difference between draft-kaplan-dispatch-session-id-03 and 02 >can be seen here: > >http://tools.ietf.org/rfcdiff?url2=draft-kaplan-dispatch-session-id-03.txt > >It did not change the ABNF nor protocol rules. Therefore I propose >to submit 03 as independent submission to the RFC Editor, for >'Historic' status. Or 'Epic' status if they have that. :) > >-hadriel > > >On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan wrote: > > > > > When we talked about this in Vancouver I was thinking there > wouldn't be any problem going to/from UUID syntax, because going > to/from UUIDs in H.323 was talked about a long, long time ago for > session-id. But I forgot about the bug in the draft-kaplan ABNF... > > > > Since version 01 of draft-kaplan-sip-session-id in 2008, which > later became draft-kaplan-dispatch-session-id, the rules for > generating the session-id always made it lower-case *hex* > characters. I.e., the g-z range wasn't actually possible. The > ABNF for it didn't get fixed until > draft-kaplan-dispatch-session-id-01 in April 2010, but that also > dropped it to 16 characters of hex because the algorithm changed, > and then 3 months later reverted back to 32 characters and the correct ABNF. > > > > So that begs the question of *which* version of draft-kaplan we > want to be backwards compatible with. Since > draft-kaplan-dispatch-session-id-01 only existed for 3 months, I > think we can ignore that one. And since everything else only used > hex characters, except the initial 00-draft which itself only > existed for 4 months, I think we can ignore that one too. > > > > Therefore, as far as I can tell we shouldn't have a problem > converting draft-kaplan session-ids to/from UUIDs for H.323/whatever. > > > > -hadriel > > > > > > On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: > > > >> Hi, > >> > >> In Vancouver, I expressed a wish to make the INSIPID mechanism > backward compatible with the draft-kaplan-session-id one, the > reason being that it has been around for a relatively long time, > and has been implemented and deployed. > >> > >> I compared the suggested draft-jones solution with the > draft-kaplan solution, and I think there are ways to achieve > backward compability. > >> > >> > >> -------------- > >> > >> > >> FIRST, looking purely at the ABNF syntax: > >> > >> The jones ABNF is: > >> > >> > >> Session-ID-UUID = "Session-ID-UUID" HCOLON UUID > >> > >> > >> > >> The kaplan ABNF is: > >> > >> > >> > >> Session-ID = "Session-ID" HCOLON sess-id > >> > >> *( SEMI generic-param ) > >> > >> sess-id = 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > >> > >> > >> > >> > >> > >> Now, assuming 32 chars is enough to carry ONE UUID, jones > applications could put the SECOND UUID in a header field parameter > (generic-param), rather than combining it with the received UUID. > >> > >> > >> > >> Of course, the first UUDI (carried in sess-id) can only contains > characters 0-9 and a-z. > >> > >> > >> > >> A UUID can contain characters 0-9 and a-f and A-F. > >> > >> > >> > >> So, a jones entity would have to be prepared to receive g-z. > >> > >> > >> > >> And, as kaplan entity is not prepared to receive capital A-F, a > jones entity would have to only use small letters. But, that should > not be a problem, afaik, as they have the same meaning as far as > UUID is concerned. > >> > >> > >> > >> -------------- > >> > >> > >> > >> SECOND, looking at it would work functionwise: > >> > >> > >> > >> There are two main alternatives: > >> > >> > >> > >> > >> > >> 1. Second UUID is added even when one entity is kaplan compliant > >> > >> 2. Second UUID is not added when one entity is kaplan compliant > >> > >> > >> > >> > >> > >> Alternative 1: > >> > >> > >> > >> When a kaplan entity inserts the first UUID (I use that as a > general term, eventhough a kaplan entity does not use UUIDs), one > must assume that it is prepared to receive a response from a jones > entity which has added the second UUID into the header field parameter. > >> > >> > >> > >> When a jones entity inserts the first UUID, one must assume that > it is prepared to receive a response from a kaplan entity where the > second UUID has *not* been added. > >> > >> > >> > >> > >> > >> Alternative 2: > >> > >> > >> > >> When a kaplan entity inserts the first UUID, the jones entity > detects (using some identify-a-kaplan-entity mechanism) that it > comes from a kaplan entity, so it does not insert a seoncd UUID in > the first place. > >> > >> > >> > >> As in alternative 1, when a jones entity inserts the first UUID, > it has to be prepared to receive a response where the second UUID > has not been added (the identify-a-kaplan-entity mechanism might > also inform the jones entity that the response comes from a kaplan entity. > >> > >> > >> > >> > >> > >> -------------- > >> > >> > >> > >> Now, there will of course be cases, where two UUIDs are > required, that won't work. But, kaplan entities would be able to > use the session-id for whatever they've used it so far. > >> > >> > >> > >> > >> > >> Regards, > >> > >> > >> > >> Christer > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Tue Aug 6 14:55:40 2013 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 3136E21F89C3 for ; Tue, 6 Aug 2013 14:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.598 X-Spam-Level: X-Spam-Status: No, score=-111.598 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIxMIOUQUXzs for ; Tue, 6 Aug 2013 14:55:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DE92E21F9E9E for ; Tue, 6 Aug 2013 14:55:18 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r76LtEgM029915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2013 16:55:16 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r76LtDXX009114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 23:55:14 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 6 Aug 2013 23:55:14 +0200 From: "DRAGE, Keith (Keith)" To: James Polk , Hadriel Kaplan , "insipid@ietf.org" Thread-Topic: [Insipid] publishing draft-kaplan session-id as historic Thread-Index: AQHOktk68KUK9pm3E0S/jc1qVFKdl5mIs90g Date: Tue, 6 Aug 2013 21:55:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B07D262@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <201308061914.r76JEBAR018455@rcdn-core-3.cisco.com> In-Reply-To: <201308061914.r76JEBAR018455@rcdn-core-3.cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Insipid] publishing draft-kaplan session-id as historic X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:55:40 -0000 I understand this is intentional. It apparently represents a change of philiosphy on the part of IESG, as rel= ayed to us by Gonzalo, on how to represent this type of document. Essentially it appears that they would rather use informational with the hi= storical like status represented in the abstract or introduction, rather th= an use historical. So Hadriel has merely been following instructions. If you go listen to the INSIPID audio recording, you'll find we asked Gonza= lo to explain this during the agenda bash and status discussion. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of James Polk > Sent: 06 August 2013 20:14 > To: Hadriel Kaplan; insipid@ietf.org > Subject: Re: [Insipid] publishing draft-kaplan session-id as historic >=20 > Hadriel >=20 > https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ > shows an intended status of "informational", not "historic" as you > agreed. I believe that needs to be corrected. >=20 > James >=20 > At 03:36 PM 3/13/2013, Hadriel Kaplan wrote: > > From today's meeting action I took... below was the email. > >The difference between draft-kaplan-dispatch-session-id-03 and 02 > >can be seen here: > > > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-kaplan-dispatch-session-id- > 03.txt > > > >It did not change the ABNF nor protocol rules. Therefore I propose > >to submit 03 as independent submission to the RFC Editor, for > >'Historic' status. Or 'Epic' status if they have that. :) > > > >-hadriel > > > > > >On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan > wrote: > > > > > > > > When we talked about this in Vancouver I was thinking there > > wouldn't be any problem going to/from UUID syntax, because going > > to/from UUIDs in H.323 was talked about a long, long time ago for > > session-id. But I forgot about the bug in the draft-kaplan ABNF... > > > > > > Since version 01 of draft-kaplan-sip-session-id in 2008, which > > later became draft-kaplan-dispatch-session-id, the rules for > > generating the session-id always made it lower-case *hex* > > characters. I.e., the g-z range wasn't actually possible. The > > ABNF for it didn't get fixed until > > draft-kaplan-dispatch-session-id-01 in April 2010, but that also > > dropped it to 16 characters of hex because the algorithm changed, > > and then 3 months later reverted back to 32 characters and the correct > ABNF. > > > > > > So that begs the question of *which* version of draft-kaplan we > > want to be backwards compatible with. Since > > draft-kaplan-dispatch-session-id-01 only existed for 3 months, I > > think we can ignore that one. And since everything else only used > > hex characters, except the initial 00-draft which itself only > > existed for 4 months, I think we can ignore that one too. > > > > > > Therefore, as far as I can tell we shouldn't have a problem > > converting draft-kaplan session-ids to/from UUIDs for H.323/whatever. > > > > > > -hadriel > > > > > > > > > On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: > > > > > >> Hi, > > >> > > >> In Vancouver, I expressed a wish to make the INSIPID mechanism > > backward compatible with the draft-kaplan-session-id one, the > > reason being that it has been around for a relatively long time, > > and has been implemented and deployed. > > >> > > >> I compared the suggested draft-jones solution with the > > draft-kaplan solution, and I think there are ways to achieve > > backward compability. > > >> > > >> > > >> -------------- > > >> > > >> > > >> FIRST, looking purely at the ABNF syntax: > > >> > > >> The jones ABNF is: > > >> > > >> > > >> Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID > > >> > > >> > > >> > > >> The kaplan ABNF is: > > >> > > >> > > >> > > >> Session-ID =3D "Session-ID" HCOLON sess-id > > >> > > >> *( SEMI generic-param ) > > >> > > >> sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z= ] > > >> > > >> > > >> > > >> > > >> > > >> Now, assuming 32 chars is enough to carry ONE UUID, jones > > applications could put the SECOND UUID in a header field parameter > > (generic-param), rather than combining it with the received UUID. > > >> > > >> > > >> > > >> Of course, the first UUDI (carried in sess-id) can only contains > > characters 0-9 and a-z. > > >> > > >> > > >> > > >> A UUID can contain characters 0-9 and a-f and A-F. > > >> > > >> > > >> > > >> So, a jones entity would have to be prepared to receive g-z. > > >> > > >> > > >> > > >> And, as kaplan entity is not prepared to receive capital A-F, a > > jones entity would have to only use small letters. But, that should > > not be a problem, afaik, as they have the same meaning as far as > > UUID is concerned. > > >> > > >> > > >> > > >> -------------- > > >> > > >> > > >> > > >> SECOND, looking at it would work functionwise: > > >> > > >> > > >> > > >> There are two main alternatives: > > >> > > >> > > >> > > >> > > >> > > >> 1. Second UUID is added even when one entity is kaplan compliant > > >> > > >> 2. Second UUID is not added when one entity is kaplan compliant > > >> > > >> > > >> > > >> > > >> > > >> Alternative 1: > > >> > > >> > > >> > > >> When a kaplan entity inserts the first UUID (I use that as a > > general term, eventhough a kaplan entity does not use UUIDs), one > > must assume that it is prepared to receive a response from a jones > > entity which has added the second UUID into the header field parameter. > > >> > > >> > > >> > > >> When a jones entity inserts the first UUID, one must assume that > > it is prepared to receive a response from a kaplan entity where the > > second UUID has *not* been added. > > >> > > >> > > >> > > >> > > >> > > >> Alternative 2: > > >> > > >> > > >> > > >> When a kaplan entity inserts the first UUID, the jones entity > > detects (using some identify-a-kaplan-entity mechanism) that it > > comes from a kaplan entity, so it does not insert a seoncd UUID in > > the first place. > > >> > > >> > > >> > > >> As in alternative 1, when a jones entity inserts the first UUID, > > it has to be prepared to receive a response where the second UUID > > has not been added (the identify-a-kaplan-entity mechanism might > > also inform the jones entity that the response comes from a kaplan > entity. > > >> > > >> > > >> > > >> > > >> > > >> -------------- > > >> > > >> > > >> > > >> Now, there will of course be cases, where two UUIDs are > > required, that won't work. But, kaplan entities would be able to > > use the session-id for whatever they've used it so far. > > >> > > >> > > >> > > >> > > >> > > >> Regards, > > >> > > >> > > >> > > >> Christer > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> insipid mailing list > > >> insipid@ietf.org > > >> https://www.ietf.org/mailman/listinfo/insipid > > > > > > _______________________________________________ > > > insipid mailing list > > > insipid@ietf.org > > > https://www.ietf.org/mailman/listinfo/insipid > > > >_______________________________________________ > >insipid mailing list > >insipid@ietf.org > >https://www.ietf.org/mailman/listinfo/insipid >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From ietf-ipr@ietf.org Tue Aug 6 09:54:37 2013 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 38DFD21F9ED2; Tue, 6 Aug 2013 09:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YUCkj6a0WSB; Tue, 6 Aug 2013 09:54:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DDA21F9C26; Tue, 6 Aug 2013 09:54:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: chrep@cisco.com,paulej@packetizer.com,jmpolk@cisco.com,gsalguei@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.61 Message-ID: <20130806165433.27534.29995.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 09:54:33 -0700 X-Mailman-Approved-At: Tue, 06 Aug 2013 15:08:43 -0700 Cc: rlb@ipv.sx, keith.drage@alcatel-lucent.com, gonzalo.camarillo@ericsson.com, gsalguei@cisco.com, insipid@ietf.org, ipr-announce@ietf.org Subject: [Insipid] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-insipid-session-id-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:54:37 -0000 Dear Chris Pearce, Paul Jones, James Polk, Gonzalo Salgueiro: An IPR disclosure that pertains to your Internet-Draft entitled "End-to-End Session Identification in IP-Based Multimedia Communication Networks" (draf= t- ietf-insipid-session-id) was submitted to the IETF Secretariat on 2013-07-3= 1 and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/2160/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-insipid-session-id-02.""); The IETF Secretariat From mary.ietf.barnes@gmail.com Wed Aug 7 08:05:35 2013 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 1BC5621F9B8D for ; Wed, 7 Aug 2013 08:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x9ZZZsubSpb for ; Wed, 7 Aug 2013 08:05:33 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2429D21F9C28 for ; Wed, 7 Aug 2013 08:05:31 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id j10so939184qcx.25 for ; Wed, 07 Aug 2013 08:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HWOEL0cR448d6feXy37st3WZ9MzQBHG+8Rs1Rd3XVXY=; b=HgUSGaderjN0iecHCBrLm2/wGRTaEgt+k7eJ1EWKu1AQmzErT/vLh/Z2QhmTB7F0ms Jdvzq7kSqRKp/tuUwgJ7c0dDQCQTDQeWdGBFjHtjkUKj8TIi6+Hpo2U9wyBnVbOZrW/p eQgjH1L3faYtDxrcMlylWPJfxkwDsqSC2feNGEn2cgvbWG0jaDqmvRXHpJ72RDIVHPg1 JwXp5Hic0GmGU6b3/K40H0Nb5LrJZnLfIP8bc7p1ljQU5x7pzg/aLG+hrtuvRNswkyVh c8+CuTp/9QX76ClnNT8B+QxB7SO4RdpTrlscfSiEDv51yVqJtBf6mAScJVHiE18ljVjN zIjw== MIME-Version: 1.0 X-Received: by 10.224.12.81 with SMTP id w17mr1170210qaw.37.1375887930467; Wed, 07 Aug 2013 08:05:30 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Wed, 7 Aug 2013 08:05:30 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B07D262@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <201308061914.r76JEBAR018455@rcdn-core-3.cisco.com> <949EF20990823C4C85C18D59AA11AD8B07D262@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 7 Aug 2013 10:05:30 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=089e013cb7cc58ab0204e35cdfab Cc: James Polk , "insipid@ietf.org" , Hadriel Kaplan Subject: Re: [Insipid] publishing draft-kaplan session-id as historic 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, 07 Aug 2013 15:05:35 -0000 --089e013cb7cc58ab0204e35cdfab Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 6, 2013 at 4:55 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I understand this is intentional. > > It apparently represents a change of philiosphy on the part of IESG, as > relayed to us by Gonzalo, on how to represent this type of document. > > Essentially it appears that they would rather use informational with the > historical like status represented in the abstract or introduction, rather > than use historical. > > So Hadriel has merely been following instructions. > > If you go listen to the INSIPID audio recording, you'll find we asked > Gonzalo to explain this during the agenda bash and status discussion. > [MB] Probably it would be very helpful to ensure that point is captured in the official minutes as well. [/MB] > > Regards > > Keith > > > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > > Of James Polk > > Sent: 06 August 2013 20:14 > > To: Hadriel Kaplan; insipid@ietf.org > > Subject: Re: [Insipid] publishing draft-kaplan session-id as historic > > > > Hadriel > > > > https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ > > shows an intended status of "informational", not "historic" as you > > agreed. I believe that needs to be corrected. > > > > James > > > > At 03:36 PM 3/13/2013, Hadriel Kaplan wrote: > > > From today's meeting action I took... below was the email. > > >The difference between draft-kaplan-dispatch-session-id-03 and 02 > > >can be seen here: > > > > > >http://tools.ietf.org/rfcdiff?url2=draft-kaplan-dispatch-session-id- > > 03.txt > > > > > >It did not change the ABNF nor protocol rules. Therefore I propose > > >to submit 03 as independent submission to the RFC Editor, for > > >'Historic' status. Or 'Epic' status if they have that. :) > > > > > >-hadriel > > > > > > > > >On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan > > wrote: > > > > > > > > > > > When we talked about this in Vancouver I was thinking there > > > wouldn't be any problem going to/from UUID syntax, because going > > > to/from UUIDs in H.323 was talked about a long, long time ago for > > > session-id. But I forgot about the bug in the draft-kaplan ABNF... > > > > > > > > Since version 01 of draft-kaplan-sip-session-id in 2008, which > > > later became draft-kaplan-dispatch-session-id, the rules for > > > generating the session-id always made it lower-case *hex* > > > characters. I.e., the g-z range wasn't actually possible. The > > > ABNF for it didn't get fixed until > > > draft-kaplan-dispatch-session-id-01 in April 2010, but that also > > > dropped it to 16 characters of hex because the algorithm changed, > > > and then 3 months later reverted back to 32 characters and the correct > > ABNF. > > > > > > > > So that begs the question of *which* version of draft-kaplan we > > > want to be backwards compatible with. Since > > > draft-kaplan-dispatch-session-id-01 only existed for 3 months, I > > > think we can ignore that one. And since everything else only used > > > hex characters, except the initial 00-draft which itself only > > > existed for 4 months, I think we can ignore that one too. > > > > > > > > Therefore, as far as I can tell we shouldn't have a problem > > > converting draft-kaplan session-ids to/from UUIDs for H.323/whatever. > > > > > > > > -hadriel > > > > > > > > > > > > On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: > > > > > > > >> Hi, > > > >> > > > >> In Vancouver, I expressed a wish to make the INSIPID mechanism > > > backward compatible with the draft-kaplan-session-id one, the > > > reason being that it has been around for a relatively long time, > > > and has been implemented and deployed. > > > >> > > > >> I compared the suggested draft-jones solution with the > > > draft-kaplan solution, and I think there are ways to achieve > > > backward compability. > > > >> > > > >> > > > >> -------------- > > > >> > > > >> > > > >> FIRST, looking purely at the ABNF syntax: > > > >> > > > >> The jones ABNF is: > > > >> > > > >> > > > >> Session-ID-UUID = "Session-ID-UUID" HCOLON UUID > > > >> > > > >> > > > >> > > > >> The kaplan ABNF is: > > > >> > > > >> > > > >> > > > >> Session-ID = "Session-ID" HCOLON sess-id > > > >> > > > >> *( SEMI generic-param ) > > > >> > > > >> sess-id = 32(DIGIT / %x61-7A) ; 32 chars of [0-9a-z] > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> Now, assuming 32 chars is enough to carry ONE UUID, jones > > > applications could put the SECOND UUID in a header field parameter > > > (generic-param), rather than combining it with the received UUID. > > > >> > > > >> > > > >> > > > >> Of course, the first UUDI (carried in sess-id) can only contains > > > characters 0-9 and a-z. > > > >> > > > >> > > > >> > > > >> A UUID can contain characters 0-9 and a-f and A-F. > > > >> > > > >> > > > >> > > > >> So, a jones entity would have to be prepared to receive g-z. > > > >> > > > >> > > > >> > > > >> And, as kaplan entity is not prepared to receive capital A-F, a > > > jones entity would have to only use small letters. But, that should > > > not be a problem, afaik, as they have the same meaning as far as > > > UUID is concerned. > > > >> > > > >> > > > >> > > > >> -------------- > > > >> > > > >> > > > >> > > > >> SECOND, looking at it would work functionwise: > > > >> > > > >> > > > >> > > > >> There are two main alternatives: > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> 1. Second UUID is added even when one entity is kaplan compliant > > > >> > > > >> 2. Second UUID is not added when one entity is kaplan compliant > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> Alternative 1: > > > >> > > > >> > > > >> > > > >> When a kaplan entity inserts the first UUID (I use that as a > > > general term, eventhough a kaplan entity does not use UUIDs), one > > > must assume that it is prepared to receive a response from a jones > > > entity which has added the second UUID into the header field parameter. > > > >> > > > >> > > > >> > > > >> When a jones entity inserts the first UUID, one must assume that > > > it is prepared to receive a response from a kaplan entity where the > > > second UUID has *not* been added. > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> Alternative 2: > > > >> > > > >> > > > >> > > > >> When a kaplan entity inserts the first UUID, the jones entity > > > detects (using some identify-a-kaplan-entity mechanism) that it > > > comes from a kaplan entity, so it does not insert a seoncd UUID in > > > the first place. > > > >> > > > >> > > > >> > > > >> As in alternative 1, when a jones entity inserts the first UUID, > > > it has to be prepared to receive a response where the second UUID > > > has not been added (the identify-a-kaplan-entity mechanism might > > > also inform the jones entity that the response comes from a kaplan > > entity. > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> -------------- > > > >> > > > >> > > > >> > > > >> Now, there will of course be cases, where two UUIDs are > > > required, that won't work. But, kaplan entities would be able to > > > use the session-id for whatever they've used it so far. > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> Regards, > > > >> > > > >> > > > >> > > > >> Christer > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> insipid mailing list > > > >> insipid@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/insipid > > > > > > > > _______________________________________________ > > > > insipid mailing list > > > > insipid@ietf.org > > > > https://www.ietf.org/mailman/listinfo/insipid > > > > > >_______________________________________________ > > >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 > --089e013cb7cc58ab0204e35cdfab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 6, 2013 at 4:55 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
I understand this is intentional.

It apparently represents a change of philiosphy on the part of IESG, as rel= ayed to us by Gonzalo, on how to represent this type of document.

Essentially it appears that they would rather use informational with the hi= storical like status represented in the abstract or introduction, rather th= an use historical.

So Hadriel has merely been following instructions.

If you go listen to the INSIPID audio recording, you'll find we asked G= onzalo to explain this during the agenda bash and status discussion.
[MB] Probably it would be very helpful to ensure that point = is captured in the official minutes as well. [/MB]=A0

Regards

Keith



> -----Original Message-----
> From: in= sipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf
> Of James Polk
> Sent: 06 August 2013 20:14
> To: Hadriel Kaplan; insipid@ietf.org
> Subject: Re: [Insipid] publishing draft-kaplan session-id as historic<= br> >
> Hadriel
>
> https://datatracker.ietf.org/doc/draft-kaplan-ins= ipid-session-id/
> shows an intended status of "informational", not "histo= ric" as you
> agreed. I believe that needs to be corrected.
>
> James
>
> At 03:36 PM 3/13/2013, Hadriel Kaplan wrote:
> > From today's meeting action I took... below was the email. > >The difference between draft-kaplan-dispatch-session-id-03 and 02<= br> > >can be seen here:
> >
> >http://tools.ietf.org/rfcdiff?url2=3Ddra= ft-kaplan-dispatch-session-id-
> 03.txt
> >
> >It did not change the ABNF nor protocol rules. =A0Therefore I prop= ose
> >to submit 03 as independent submission to the RFC Editor, for
> >'Historic' status. =A0Or 'Epic' status if they hav= e that. :)
> >
> >-hadriel
> >
> >
> >On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan <HKaplan@acmepacket.com> > wrote:
> >
> > >
> > > When we talked about this in Vancouver I was thinking there<= br> > > wouldn't be any problem going to/from UUID syntax, because go= ing
> > to/from UUIDs in H.323 was talked about a long, long time ago for=
> > session-id. =A0But I forgot about the bug in the draft-kaplan ABN= F...
> > >
> > > Since version 01 of draft-kaplan-sip-session-id in 2008, whi= ch
> > later became draft-kaplan-dispatch-session-id, the rules for
> > generating the session-id always made it lower-case *hex*
> > characters. =A0I.e., the g-z range wasn't actually possible. = =A0The
> > ABNF for it didn't get fixed until
> > draft-kaplan-dispatch-session-id-01 in April 2010, but that also<= br> > > dropped it to 16 characters of hex because the algorithm changed,=
> > and then 3 months later reverted back to 32 characters and the co= rrect
> ABNF.
> > >
> > > So that begs the question of *which* version of draft-kaplan= we
> > want to be backwards compatible with. =A0Since
> > draft-kaplan-dispatch-session-id-01 only existed for 3 months, I<= br> > > think we can ignore that one. =A0And since everything else only u= sed
> > hex characters, except the initial 00-draft which itself only
> > existed for 4 months, I think we can ignore that one too.
> > >
> > > Therefore, as far as I can tell we shouldn't have a prob= lem
> > converting draft-kaplan session-ids to/from UUIDs for H.323/whate= ver.
> > >
> > > -hadriel
> > >
> > >
> > > On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote:
> > >
> > >> Hi,
> > >>
> > >> In Vancouver, I expressed a wish to make the INSIPID mec= hanism
> > backward compatible with the draft-kaplan-session-id one, the
> > reason being that it has been around for a relatively long time,<= br> > > and has been implemented and deployed.
> > >>
> > >> I compared the suggested draft-jones solution with the > > draft-kaplan solution, and I think there are ways to achieve
> > backward compability.
> > >>
> > >>
> > >> --------------
> > >>
> > >>
> > >> FIRST, looking purely at the ABNF syntax:
> > >>
> > >> The jones ABNF is:
> > >>
> > >>
> > >> Session-ID-UUID =3D "Session-ID-UUID" HCOLON U= UID
> > >>
> > >>
> > >>
> > >> The kaplan ABNF is:
> > >>
> > >>
> > >>
> > >> Session-ID =A0 =A0 =A0 =A0 =A0 =3D =A0"Session-ID&q= uot; HCOLON sess-id
> > >>
> > >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*( SE= MI generic-param )
> > >>
> > >> sess-id =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D =A032(DIGIT / %x6= 1-7A) =A0; 32 chars of [0-9a-z]
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Now, assuming 32 chars is enough to carry ONE UUID, jone= s
> > applications could put the SECOND UUID in a header field paramete= r
> > (generic-param), rather than combining it with the received UUID.=
> > >>
> > >>
> > >>
> > >> Of course, the first UUDI (carried in sess-id) can only = contains
> > characters 0-9 and a-z.
> > >>
> > >>
> > >>
> > >> A UUID can contain characters 0-9 and a-f and A-F.
> > >>
> > >>
> > >>
> > >> So, a jones entity would have to be prepared to receive = g-z.
> > >>
> > >>
> > >>
> > >> And, as kaplan entity is not prepared to receive capital= A-F, a
> > jones entity would have to only use small letters. But, that shou= ld
> > not be a problem, afaik, as they have the same meaning as far as<= br> > > UUID is concerned.
> > >>
> > >>
> > >>
> > >> --------------
> > >>
> > >>
> > >>
> > >> SECOND, looking at it would work functionwise:
> > >>
> > >>
> > >>
> > >> There are two main alternatives:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 1. Second UUID is added even when one entity is kaplan c= ompliant
> > >>
> > >> 2. Second UUID is not added when one entity is kaplan co= mpliant
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Alternative 1:
> > >>
> > >>
> > >>
> > >> When a kaplan entity inserts the first UUID (I use that = as a
> > general term, eventhough a kaplan entity does not use UUIDs), one=
> > must assume that it is prepared to receive a response from a jone= s
> > entity which has added the second UUID into the header field para= meter.
> > >>
> > >>
> > >>
> > >> When a jones entity inserts the first UUID, one must ass= ume that
> > it is prepared to receive a response from a kaplan entity where t= he
> > second UUID has *not* been added.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Alternative 2:
> > >>
> > >>
> > >>
> > >> When a kaplan entity inserts the first UUID, the jones e= ntity
> > detects (using some identify-a-kaplan-entity mechanism) that it > > comes from a kaplan entity, so it does not insert a seoncd UUID i= n
> > the first place.
> > >>
> > >>
> > >>
> > >> As in alternative 1, when a jones entity inserts the fir= st UUID,
> > it has to be prepared to receive a response where the second UUID=
> > has not been added (the identify-a-kaplan-entity mechanism might<= br> > > also inform the jones entity that the response comes from a kapla= n
> entity.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --------------
> > >>
> > >>
> > >>
> > >> Now, there will of course be cases, where two UUIDs are<= br> > > required, that won't work. But, kaplan entities would be able= to
> > use the session-id for whatever they've used it so far.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Regards,
> > >>
> > >>
> > >>
> > >> Christer
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> insipid mailing list
> > >> in= sipid@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/insipid
> > >
> > > _______________________________________________
> > > insipid mailing list
> > > insipi= d@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
_______________________________________________
insipid mailing list
insipid@ietf.org<= br> https://www.ietf.org/mailman/listinfo/insipid

--089e013cb7cc58ab0204e35cdfab-- From hadriel.kaplan@oracle.com Wed Aug 7 11:06:33 2013 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 0746F11E8151 for ; Wed, 7 Aug 2013 11:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.505 X-Spam-Level: X-Spam-Status: No, score=-7.505 tagged_above=-999 required=5 tests=[AWL=1.094, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ4MxzEWTGiE for ; Wed, 7 Aug 2013 11:06:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 89C2B11E8158 for ; Wed, 7 Aug 2013 11:06:21 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r77I6ITO029109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Aug 2013 18:06:19 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77I6Hrk012120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 18:06:18 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r77I6HS6028491; Wed, 7 Aug 2013 18:06:17 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Aug 2013 11:06:16 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <201308061914.r76JEBAR018455@rcdn-core-3.cisco.com> Date: Wed, 7 Aug 2013 14:06:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05853408683664@ESESSCMS0356.eemea.ericsson.se> <201308061914.r76JEBAR018455@rcdn-core-3.cisco.com> To: James Polk X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "insipid@ietf.org" Subject: Re: [Insipid] publishing draft-kaplan session-id as historic 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, 07 Aug 2013 18:06:33 -0000 The email you cited from me below was when I announced the intention to = submit. I did actually submit it as 'Historic' in that 00 version - see = here: http://tools.ietf.org/html/draft-kaplan-insipid-session-id-00 I was then told to change it to Informational, which triggered this: http://tools.ietf.org/html/draft-kaplan-insipid-session-id-01 I was told to put in context for why it's being published, which = triggered this: http://tools.ietf.org/html/draft-kaplan-insipid-session-id-02 I was told to fix some I-D nits, which triggered this: http://tools.ietf.org/html/draft-kaplan-insipid-session-id-03 [I don't mean to imply I was told those separate things at separate = times - it just took me several times to grok what I was being told :) ] As you probably know, but others might not so I'm saying it here, you = can view the diff changes between draft versions by clicking on the = "diff1" or "diff2" links at the top of the HTML-based draft pages. -hadriel On Aug 6, 2013, at 3:13 PM, James Polk wrote: > Hadriel >=20 > https://datatracker.ietf.org/doc/draft-kaplan-insipid-session-id/ = shows an intended status of "informational", not "historic" as you = agreed. I believe that needs to be corrected. >=20 > James >=20 > At 03:36 PM 3/13/2013, Hadriel Kaplan wrote: >> =46rom today's meeting action I took... below was the email. >> The difference between draft-kaplan-dispatch-session-id-03 and 02 can = be seen here: >>=20 >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-kaplan-dispatch-session-id-03.t= xt >>=20 >> It did not change the ABNF nor protocol rules. Therefore I propose = to submit 03 as independent submission to the RFC Editor, for 'Historic' = status. Or 'Epic' status if they have that. :) >>=20 >> -hadriel >>=20 >>=20 >> On Aug 17, 2012, at 1:47 PM, Hadriel Kaplan = wrote: >>=20 >>>=20 >>> When we talked about this in Vancouver I was thinking there wouldn't = be any problem going to/from UUID syntax, because going to/from UUIDs in = H.323 was talked about a long, long time ago for session-id. But I = forgot about the bug in the draft-kaplan ABNF... >>>=20 >>> Since version 01 of draft-kaplan-sip-session-id in 2008, which later = became draft-kaplan-dispatch-session-id, the rules for generating the = session-id always made it lower-case *hex* characters. I.e., the g-z = range wasn't actually possible. The ABNF for it didn't get fixed until = draft-kaplan-dispatch-session-id-01 in April 2010, but that also dropped = it to 16 characters of hex because the algorithm changed, and then 3 = months later reverted back to 32 characters and the correct ABNF. >>>=20 >>> So that begs the question of *which* version of draft-kaplan we want = to be backwards compatible with. Since = draft-kaplan-dispatch-session-id-01 only existed for 3 months, I think = we can ignore that one. And since everything else only used hex = characters, except the initial 00-draft which itself only existed for 4 = months, I think we can ignore that one too. >>>=20 >>> Therefore, as far as I can tell we shouldn't have a problem = converting draft-kaplan session-ids to/from UUIDs for H.323/whatever. >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 14, 2012, at 4:27 PM, Christer Holmberg wrote: >>>=20 >>>> Hi, >>>>=20 >>>> In Vancouver, I expressed a wish to make the INSIPID mechanism = backward compatible with the draft-kaplan-session-id one, the reason = being that it has been around for a relatively long time, and has been = implemented and deployed. >>>>=20 >>>> I compared the suggested draft-jones solution with the draft-kaplan = solution, and I think there are ways to achieve backward compability. >>>>=20 >>>>=20 >>>> -------------- >>>>=20 >>>>=20 >>>> FIRST, looking purely at the ABNF syntax: >>>>=20 >>>> The jones ABNF is: >>>>=20 >>>>=20 >>>> Session-ID-UUID =3D "Session-ID-UUID" HCOLON UUID >>>>=20 >>>>=20 >>>>=20 >>>> The kaplan ABNF is: >>>>=20 >>>>=20 >>>>=20 >>>> Session-ID =3D "Session-ID" HCOLON sess-id >>>>=20 >>>> *( SEMI generic-param ) >>>>=20 >>>> sess-id =3D 32(DIGIT / %x61-7A) ; 32 chars of = [0-9a-z] >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Now, assuming 32 chars is enough to carry ONE UUID, jones = applications could put the SECOND UUID in a header field parameter = (generic-param), rather than combining it with the received UUID. >>>>=20 >>>>=20 >>>>=20 >>>> Of course, the first UUDI (carried in sess-id) can only contains = characters 0-9 and a-z. >>>>=20 >>>>=20 >>>>=20 >>>> A UUID can contain characters 0-9 and a-f and A-F. >>>>=20 >>>>=20 >>>>=20 >>>> So, a jones entity would have to be prepared to receive g-z. >>>>=20 >>>>=20 >>>>=20 >>>> And, as kaplan entity is not prepared to receive capital A-F, a = jones entity would have to only use small letters. But, that should not = be a problem, afaik, as they have the same meaning as far as UUID is = concerned. >>>>=20 >>>>=20 >>>>=20 >>>> -------------- >>>>=20 >>>>=20 >>>>=20 >>>> SECOND, looking at it would work functionwise: >>>>=20 >>>>=20 >>>>=20 >>>> There are two main alternatives: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> 1. Second UUID is added even when one entity is kaplan compliant >>>>=20 >>>> 2. Second UUID is not added when one entity is kaplan compliant >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Alternative 1: >>>>=20 >>>>=20 >>>>=20 >>>> When a kaplan entity inserts the first UUID (I use that as a = general term, eventhough a kaplan entity does not use UUIDs), one must = assume that it is prepared to receive a response from a jones entity = which has added the second UUID into the header field parameter. >>>>=20 >>>>=20 >>>>=20 >>>> When a jones entity inserts the first UUID, one must assume that it = is prepared to receive a response from a kaplan entity where the second = UUID has *not* been added. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Alternative 2: >>>>=20 >>>>=20 >>>>=20 >>>> When a kaplan entity inserts the first UUID, the jones entity = detects (using some identify-a-kaplan-entity mechanism) that it comes = from a kaplan entity, so it does not insert a seoncd UUID in the first = place. >>>>=20 >>>>=20 >>>>=20 >>>> As in alternative 1, when a jones entity inserts the first UUID, it = has to be prepared to receive a response where the second UUID has not = been added (the identify-a-kaplan-entity mechanism might also inform the = jones entity that the response comes from a kaplan entity. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -------------- >>>>=20 >>>>=20 >>>>=20 >>>> Now, there will of course be cases, where two UUIDs are required, = that won't work. But, kaplan entities would be able to use the = session-id for whatever they've used it so far. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>>=20 >>>>=20 >>>> Christer >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>>=20 >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >=20 From paulej@packetizer.com Tue Aug 13 15:14:18 2013 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 0B9E221F9815 for ; Tue, 13 Aug 2013 15:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+aSixiIuij3 for ; Tue, 13 Aug 2013 15:14:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BCE7221F9808 for ; Tue, 13 Aug 2013 15:14:09 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r7DME6uh026789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 18:14:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376432047; bh=u/O7IKI2cz5b3nRV7zLKaKjLP3I9uSvP9wT+hA1DJek=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=o5764UqM679xa5HCcGufrSbBCCHs0s0zdh7BivgXKwv9IFYWRlNgdJCl+8HvVF9fM mwRNv4mfgUC+0+3px6VcxlETG0WFVukZtZffTpLgODdpKxEv7vTijaeLN1ZdmaN6Iq 57Fo+AC/qs+TjkGfORLCHU1GBluQzKKRAyIxPMyc= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01c901ce8f94$13beb480$3b3c1d80$@packetizer.com> In-Reply-To: Date: Tue, 13 Aug 2013 18:14:11 -0400 Message-ID: <034a01ce9872$7049c6e0$50dd54a0$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwH9WYgfAp0pqkkBtWu70Zc+dmUA Content-Language: en-us Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:14:18 -0000 Hadriel, > Ummm... in what way is it *not* about tracking the media? The scenario > you'd like to cover is one where there are two separate SIP sessions > through a PBX, and the PBX "joins" them at a media layer but doesn't > change things at a SIP layer other than to send a re-INVITE/UPDATE to > change the Session-ID value. This has nothing to do with the media. The PBX "joins" on the signaling plane; media handled by the endpoints. > I totally get that PBXs do that - I know they frequently do it that way. > (heck, some SBCs do too these days) But all that is really being > tracked/correlated is the media. We went through multiple rounds of > discussion in DISPATCH about Session-ID, where I tried to describe what > the "thing" was that it correlated. At one point I even tried to describe > it as correlating things that shared fate (ie, if Alice hangs up, the > other SIP dialogs would too), but conference bridge dialogs didn't exhibit > that behavior, and neither did PBX dialogs in some cases. We also talked > about it correlating media sessions instead, but we knew that required the > re-INVITE/UPDATEs and at the time the consensus was not to do it. (That > changed in the INSIPID WG, obviously) Re-INVITES are very common in PBXes as calls are put on hold, parked, taken off hold, and "joined" to another call. But, the PBX does not necessarily touch media. > Ultimately the thing we agreed on was that the legacy Session-ID > correlated things as the Call-ID would have done, had B2BUAs not changed > the Call-ID. So the original "call" from Alice through the PBX to Bob > would be the same Session-ID, but the Bob-Carol one was a different one, > and if the PBX joined Alice and Carol at a media layer without really > doing REFER/IWR, then it's still two separate Session-IDs because in that > case the PBX is truly acting as two separate User Agent "ends" and there > is no real *SIP* relationship between Alice and Carol. Except for the media part, yes. We want something end-to end between Alice and Carol, in your example. We cannot rely on Call-ID since each endpoint has a different idea about what the Call-ID is. The Session-ID would allow the two to agree on the two-part value {A,C}. > I get why you want to do it, but my point was it's not what the legacy > draft was trying to accomplish. Yeah, I understand that. They're both trying to address an end-to-end ID, but the real-world signaling scenarios (manipulation in call centers, manipulation in PBXes, and interworking with H.323 devices) necessitate something different to truly have an end-to-end value. Also, we appreciate the fact the end-to-end value might change (e.g., call transfer to Carol). > Other comments inline... > > > On Aug 2, 2013, at 11:22 AM, Paul E. Jones wrote: > > > The new solution is not focused on media flow tracking. Let me be clear. > > We just need a Session-ID. Once we have one, then we can do other > > interesting things with it. We did want to solve then end-to-end > problem, > > appreciating the fact that the ends do move around sometimes. So, while > > Alice might start out talking to Bob, she might get switched over to > Carol. > > This is extremely common, especially in call centers (but also if you > call > > my desk and I transfer you somewhere else). > > Yup, I know it's common in call-centers. > > > > Re-INVITE for transfers is often needed, because audio/video > capabilities > > change. Media ports might change, too. In most transfer cases, calls > are > > put on hold and sometimes media is halted entirely, at least in one > > direction. > > Yup, but in the cases where the SBC on the SIP trunk locally answers the > re-INVITE, it hides those media changes from the Service Provider. The > rest of the world doesn't need to know that the media address/ports > changed, or that it got put on hold. (some PBXs do that too, instead of > the SBC - the PBX doesn't send re-INVITEs up the SIP trunk, but just > locally moves stuff around and plays music on hold and so on) Yeah, some might and I can appreciate not wanting to forward INVITES to the remote UAs too frequently. However, the Session-ID changes would necessitate that. > > I'm certainly OK with trying to figure out how to interwork with the > > previous draft, but it looks like it might be too constraining by not > > supporting transfers and such. In effect, it's not always end-to-end. > > The legacy draft supports "transfers" - it supports them when they're > truly SIP transfers. It doesn't support identifying media switching. Right, but I could not begin to count the number of places where I see "transfers" just done locally. People do the same with H.323, too. Few use H.450.2 to transfer. Rather, they just send a TCS=0 and then a new TCS. Same logic. > This new draft won't be end-to-end either in the real world. It might > well be end-to-end within a domain, but across domains I'm pretty sure it > won't be. Well, that would be rather unfortunate. At least it should be across the public Internet. If service providers want to play with the signaling, there is really nothing I can do about that. > > I'm certainly OK, too, with a new header value, though "Media-ID" is not > > quite right. This is intended to identify the session. > > What does the word "session" mean to you in this context? I'm hesitant to answer that question. Robert spent a lot of time articulating what a "session" is in the requirements document :-) I don't want to get it wrong by paraphrasing. BTW, James will throw out an idea for maintaining backward compatibility soon. Paul From paulej@packetizer.com Tue Aug 13 15:34:15 2013 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 3BFB721F9815 for ; Tue, 13 Aug 2013 15:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tUiw9Ed2CR3 for ; Tue, 13 Aug 2013 15:34:10 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BF34921F90DC for ; Tue, 13 Aug 2013 15:34: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 r7DMY8QD027982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 18:34:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1376433249; bh=IPP1qjdRDUtYK1DtEwbnKezbRZtZn6KXQvfoXLmbnZw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HYt1ZbMCHKjEX8TMj8s15LEJKmcuJwurPXXw7FAPp7eIfkhwVj7B1uG4Z1V41+Fci uYKcHiHGYFOilw+1KjFeXgP6S/gx47WsWxU/KAmYluw8QdWybyaKNphBDhNjOn7pel Qy1dn1PyB6zAcQHR0IUcpdHyLIMHIWWsVLmnoXZU= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> In-Reply-To: <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> Date: Tue, 13 Aug 2013 18:34:13 -0400 Message-ID: <035201ce9875$3c94e6b0$b5beb410$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKZdDx82A Content-Language: en-us Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 22:34:15 -0000 Hadriel, > I can't tell if you seriously believe the new mechanism is going to work > end-to-end across all domains, or if you just mean end-to-end within a > domain (like within the call-center). I don't mean that in a negative way > - I just mean I don't understand how you mean the words "end-to-end". I seriously mean end-to-end. Assuming service providers did not block passage of an INVITE containing a new UUID value, then we can always have an end-to-end value. As an "end" changes, so does the end-to-end value. That's OK. > I seriously doubt this thing is going to achieve any more than the legacy > draft did in terms of true end-to-end across-the-world type thing. In > fact it may even do less. The only reason it would not is if: 1) One endpoint does not support the procedures (can't help that) 2) Something prevents a new INVITE from going to one endpoint (like an SBC) Otherwise, it would work. > When I make a call from my cell phone through my mobile provider, through > N number of carriers, to an Enterprise call-center somewhere in Timbuktu, > I have a hard time believing all the carriers and mobile providers want to > get back and process a re-INVITE each and every time the call gets moved > around inside the call-center's internal PBX infrastructure. They rarely > get that today, and I don't see them changing in the future to do so... > for what benefit? What use is it to update all the SIP systems along the > path, as well as my cell phone, with a new Session-ID value just because > the call got parked/unparked or internally transferred inside PBX/ACD/etc. > systems in a call-center somewhere? > > Some call centers move the media around almost a dozen times per call. > You really think the rest of the world wants to get a dozen re-INVITEs, > for no benefit? The SBCs aren't answering the re-INVITEs locally today to > hide the identity of who/what it gets moved around to - that we already do > even when we forward the re-INVITEs - we're answering them locally because > the service providers don't want nor need those re-INVITEs. It's just > extra processing load, log entries, and things that can go wrong; with no > added benefit. I really cannot do anything about these "noise" issues. I recognize that in practice, much of the use of SIP has been absolutely nothing more than a PSTN replacement. It has been merely a means of moving from TDM to IP. I'm glad it happened, but it's more than unfortunate if that's all we accomplish. As I look to doing more interesting things where I have different applications running in various devices connected to different networks and associated to my "phone" where I can utilize all of them as a part of a "call", I see value in having this end-to-end identifier for even this more complex arrangement. However, I can understand if service providers do not take an active interest in this. From a research perspective, these more advanced communication systems are interesting. From a business perspective, there is a question about ROI for carriers. I get that: there's no money in doing much more than providing the most basic voice service, and even that service has a very small profit margin. However, progress, capabilities, functionality, and improvements in the way we work and communicate should go forward, and they are. Already, we see a number of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect functionality will become much more interesting, with a wider mix of multimedia applications in use at once. Bottom line is that we should not constrain a system, but try to make it as flexible as possible. It might not work everywhere, but don't constrain ourselves to the most basic voice call flow. Paul > -hadriel > > > On Aug 2, 2013, at 11:48 AM, Paul E. Jones wrote: > > > Larua, > > > > So in effect, the current deployments are not end-to-end, but edge-to- > edge somewhere. I can appreciate that, but it does make it more > challenging to try to work with when we go all the way end-to-end. > > > > Paul > > > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > Sent: Friday, August 02, 2013 4:47 AM > > To: Paul E. Jones > > Cc: insipid@ietf.org > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > > Paul, > > > > As I said, we never used the old Session-ID to do more than correlate > bothe legs of the same dialog. So in your example we have: > > - Alice to Bob: Session-ID A > > - Bob to Carol: Session-ID B > > - Alice to Carol: Session-ID C > > > > There is no correlation between them. We just correlate both legs of the > same dialog across the SBC between Alice and Bob. > > > > Thank you > > Laura > > > > > > > > 2013/8/1 Paul E. Jones > > Laura, > > > > The example I show below is a real call center example. I show use of > the old session ID. Tell me how that works. Forget about the new solution > for the moment. > > > > If you say it will not work, then I'm not sure how we can make something > work with something that does not work. If there is a way to make this > work, then we can try to figure out how to interwork with it. > > > > Paul > > > > > > > > From: Laura Liess > > Sent: Thu Aug 01 11:51:26 EDT 2013 > > > > To: "Paul E. Jones" > > Cc: insipid@ietf.org > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > > Paul, > > We use the old Session-ID only accross SBCs, to correlate both legs of > the same dialog. And it works fine for this use case. We never tried, > intend or were required to do more with it. > > We are not against the new mechanism, we just want it to interwork with > the old one which we have in thousands of customer end devices. If it does, > we can add new end devices and application servers which support the new > Session-ID. Otherwise we can't. > > > > Let's see if it works when we keep the UUID order unchanged, as Hadriel > proposed. > > > > Thank you > > Laura > > > > > > 2013/8/1 Paul E. Jones > > Laura, > > > > I assert that old draft will not work for some "real-world" calls. > Calls do get manipulated in enterprise environments and call centers for > billing purposes, privacy reasons, etc. > > > > Consider a common case: if you call into a call center and the agent > puts you on hold while they transfer you to a specialist (transfer out of > consultation), for example, your SIP UA does not receive a REFER to > initiate a new call directly to the specialist. This is handled at the > call center. > > > > So rather specifically, how would this be handled (with the old draft)? > > > > 1) Alice calls Bob (Session-ID: A) > > 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > > 3) Bob transfers the call from Alice to Carol using a local transfer > function on the PBX (Session-ID: ??) > > > > The PBX could send different values to Alice and Carol, but we totally > lose the end-to-end identification of the call. > > > > Alice could not send "A" to Carol, since Carol is expecting B. Likewise, > Carol cannot send "B" to Alice, since Alice is expecting "A". Well, they > could, and it would be no worse than our current proposal in terms of > backward-compatibility. > > > > Paul > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Laura Liess > > Sent: Thursday, August 01, 2013 9:13 AM > > To: insipid@ietf.org > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > > > > Hadriel's proposal works for us. > > > > Thank you > > Laura > > > > > > 2013/8/1 Hadriel Kaplan > > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the need > to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the Session-ID > header value vs. parameter, on a message direction basis. > > > > In other words, today the draft has this: > > 1) Alice sends INVITE with "Session-ID: foo" > > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > > > But we could instead do this: > > 1) Alice sends INVITE with "Session-ID: foo" > > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > > > This second model keeps the Session-ID header value as "foo" the whole > time, while adding a parameter of "bar" for Bob that remains a parameter > the whole time. > > Neither Alice nor Bob are confused about which one is "their" UUID value. > > And it's backward-compatible with the previous kaplan-draft. > > And it's arguably easier to implement, for the common cases. > > > > I *think* there was a reason someone came up with at one time as to why > it had to be swapped, but I don't remember what it is and I don't see it > in the draft. So I'm trying to find out why we need to do it the way the > draft currently has it. > > > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and really > shouldn't be conflated with it at all. It has nothing to do with the > solutions document, or the direction stuff, etc. > > > > -hadriel > > > > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > > > Folks, > > > > > > I step away for a couple of days and the floodgate opens. :) > > > > > > I think it's important to understand why we proposed using a two-part > > > Session Identifier. The reason is that we have to be able to > effectively > > > deal with things like forking, call transfer, park, bridging, > conferencing, > > > etc. > > > > > > When initiating a call and using a single UUID value, that has the > potential > > > to go end-to-end. However, if a call is forked there are multiple > "ends". > > > How do we track each of those? For proper diagnostics and > troubleshooting, > > > it would be ideal to be able to identify which devices have an issue. > > > > > > Once a call has been placed, there is a Session-ID established between > Alice > > > and Bob. If Alice (in one country) transfers Bob (perhaps in the same > or > > > different country) to a some location in a high-toll country, who pays > the > > > bill? Well, to address that, we do call transfer locally on PBXes. > The PBX > > > maintains control over the call and Alice would pay the bill for the > call > > > transfer. But if Alice was talking to Carol before the transfer, > there is a > > > Session-ID for that call. If Bob is put in communication with Carol, > what > > > is the Session-ID value? Bob had one and Carol had a different one. > What > > > is the new ID? > > > > > > It's issues like this that led us to using a two-part value. In this > way, > > > we could see the call from Alice to Bob has a Session-ID {A,B}. If > Alice > > > transfers the call to Carol, each device understands that the Session- > ID > > > changed to {B,C}. Not only that, but intermediaries along the path > that > > > were not privy to signaling that resulted in this change can take note > of > > > the fact the value changed. This can provide a useful historical > record, > > > since previously they might see a call to Carol identified as {A,C}, > but > > > then it changed to {B,C}. > > > > > > This property extends quite naturally to other signaling scenarios, as > it > > > allows one to identify a call end-to-end, but also establish some > > > relationship between other calls that shared at least one UUID value > out of > > > the two. > > > > > > Hadriel mentioned the desire to use the Session-ID to correlate media > flows > > > and calls. That's certainly something Cisco would like to do, but it > is not > > > the driver behind the solution. Having a valid end-to-end identifier > (in > > > whatever form) allows us to do that. We're not suggesting to fit the > > > solution to meet that business use case, but rather we just want a > solution > > > that allows us to properly identify calls end-to-end and we recognize > that, > > > due to various service interactions in the network, these UUID values > can > > > change. > > > > > > I would hope that UUID values will not change to the extent that SBCs > change > > > them for business reasons. It would certainly defeat the point. > Hadriel > > > might be right that an SBC vendor might manipulate those values at the > > > request of a customer, but I would hope said customer appreciates that > such > > > a request effectively breaks the end-to-end model. We can't do much > about > > > that if they do go down that path. > > > > > > As for backward-compatibility, the simplest approach (IMO) is to just > use a > > > header value not already in use. Originally, we had proposed Session- > UUID. > > > That was changed at the request of the group to be Session-ID. > However, > > > when we have a two UUID solution interacting with a one-UUID solution, > we > > > immediately face some challenges. > > > > > > What happens if an older system sends this: > > > Session-ID: X > > > But then receives this: > > > Session-ID: Y; remote=X > > > > > > Does this break things? If so, how do current implementations deal > with > > > such things as mid-call transfers that happen on a PBX like the one I > > > described above? > > > > > > We could switch the order like this: > > > Session-ID: X; remote=Y > > > > > > However, that does not work for similar reasons. If we have a call > transfer > > > where Alice transfers a call with Bob to Carol, then each has a > different > > > idea about what the proper value is for the first position. > > > > > > Originally, the proposed solution did not indicate position > information and > > > just had single UUID values going in each direction. We then proposed > a > > > concatenated string (X:Y). However, that presented the same issues for > the > > > call transfer case, so we indicate values by position (sender's value > > > first), so it is clear what value the receive thinks the remote end > has for > > > the local end. It might be wrong, but that will be corrected in the > > > following response. (Intermediaries can take note of the change.) > > > > > > So, that's why we are where we are. There has been an effort to > maintain > > > backward-compatibility, but there are challenges in meeting that > > > requirement. Where it falls short, we do not know: we've not been > told > > > explicitly what the issues are. Further, if there are such issues, we > need > > > to also understand how those would be handled in the face of call > transfer > > > or "joining" a call locally on a PBX. Those are real-world scenarios > that > > > we must address. > > > > > > Anyway, nothing is set in stone. Anything can be changed, but I would > hope > > > we can find a solution that works for the enterprise use cases as well > as > > > the service provider networks. > > > > > > 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 imcilwaine@opencloud.com Wed Aug 14 02:20:15 2013 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 1BE9611E80E4 for ; Wed, 14 Aug 2013 02:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScZwMNzwWr4j for ; Wed, 14 Aug 2013 02:20:08 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with SMTP id 9C2C821F9DC9 for ; Wed, 14 Aug 2013 02:20:07 -0700 (PDT) Received: from mail-ve0-f174.google.com ([209.85.128.174]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUgtLxV1r++qiKel8xkxEbhItU2FHw4pU@postini.com; Wed, 14 Aug 2013 02:20:07 PDT Received: by mail-ve0-f174.google.com with SMTP id d10so7556608vea.33 for ; Wed, 14 Aug 2013 02:20:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:reply-to:from:references:in-reply-to :mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=rfVshpjYfoLFQwov5A4T9XFAyAwDVt+cR3O6YXcPIZQ=; b=gtV8xi4++pHL7oOiIAIhgpN3R90n/TB1Qs7GulImWLyCjIKQtdeYHbRrk0GCsGo9rA 6hJzhWYBNRmmJDdLs6+gg6RoBi9W3CbQcayAic15VrIXuM4+XaVZmCTBMbgQIHYoX3qK egK7OYFsaXu1TiA7sVlUnh2dsIMVZ7n8uDR0n8On1N3HBor8VK2ECRmiMz3j/XFb6F9i dceufXPxJAFjPJv2CGUaDurHBWeTfnqQH/5MYhUXdCrGkCrQGFiby7nzKAVVlPgbMKNj Vzvo90tpbaxFbdIx2URCCifkj5kdoA52NiRKqVJTle+uoaLm86yXOnWNohfreT9Am6yo 1Tpw== X-Gm-Message-State: ALoCoQma9rY2jbaBSSg424COdoVYrJ7v1hehyZqW7Y8NeJbNeWUxGbiVea5EZROf5c+y5AW2ZpEVg0ZZRv746OTlt5KOlrTH6DWr+rsXPMVLB89zfJrOVkNbiObgLw1WIyN1Ybe50mLytjO9uFFQR+bYlOxHxMhtvw== X-Received: by 10.58.196.132 with SMTP id im4mr8746vec.28.1376472005383; Wed, 14 Aug 2013 02:20:05 -0700 (PDT) X-Received: by 10.58.196.132 with SMTP id im4mr8740vec.28.1376472005249; Wed, 14 Aug 2013 02:20:05 -0700 (PDT) From: Iain McIlwaine References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> In-Reply-To: <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKQJk1zw7lzFWvkA= Date: Wed, 14 Aug 2013 10:20:03 +0100 Message-ID: <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> To: "Paul E. Jones" , Hadriel Kaplan , Laura Liess Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iain.mcilwaine@opencloud.com List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:20:15 -0000 Folks, I see a lot of discussion for enterprise transfer scenarios but I would like to highlight a problematic use case to gauge your opinions. Using Hadriel's method which designates local:remote of the UUID according to the issuer of the INVITE I can see a potential problem for Access Transfer when the party being transferred is in the "proceeding" state. So: Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=bar" Bob' INVITE - "Transfer AS" Session-ID:foo' Note: the "Transfer AS" can be an ATCF or an SCC. We can see in this case using Hadriel's syntax we now require the Transfer AS to perform manipulation of the Session-ID header which runs contrary to a stated objective of no intermediary meddling of the header. If we revert to interpreting the local:remote syntax being within the context of the receiver I believe we would avert this situation. Of course it could be I've misunderstood something so happy to be shown the light. Kind regards, Iain -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: 13 August 2013 23:34 To: 'Hadriel Kaplan' Cc: insipid@ietf.org; 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility Hadriel, > I can't tell if you seriously believe the new mechanism is going to > work end-to-end across all domains, or if you just mean end-to-end > within a domain (like within the call-center). I don't mean that in a > negative way > - I just mean I don't understand how you mean the words "end-to-end". I seriously mean end-to-end. Assuming service providers did not block passage of an INVITE containing a new UUID value, then we can always have an end-to-end value. As an "end" changes, so does the end-to-end value. That's OK. > I seriously doubt this thing is going to achieve any more than the > legacy draft did in terms of true end-to-end across-the-world type > thing. In fact it may even do less. The only reason it would not is if: 1) One endpoint does not support the procedures (can't help that) 2) Something prevents a new INVITE from going to one endpoint (like an SBC) Otherwise, it would work. > When I make a call from my cell phone through my mobile provider, > through N number of carriers, to an Enterprise call-center somewhere > in Timbuktu, I have a hard time believing all the carriers and mobile > providers want to get back and process a re-INVITE each and every time > the call gets moved around inside the call-center's internal PBX > infrastructure. They rarely get that today, and I don't see them changing in the future to do so... > for what benefit? What use is it to update all the SIP systems along > the path, as well as my cell phone, with a new Session-ID value just > because the call got parked/unparked or internally transferred inside PBX/ACD/etc. > systems in a call-center somewhere? > > Some call centers move the media around almost a dozen times per call. > You really think the rest of the world wants to get a dozen > re-INVITEs, for no benefit? The SBCs aren't answering the re-INVITEs > locally today to hide the identity of who/what it gets moved around to > - that we already do even when we forward the re-INVITEs - we're > answering them locally because the service providers don't want nor > need those re-INVITEs. It's just extra processing load, log entries, > and things that can go wrong; with no added benefit. I really cannot do anything about these "noise" issues. I recognize that in practice, much of the use of SIP has been absolutely nothing more than a PSTN replacement. It has been merely a means of moving from TDM to IP. I'm glad it happened, but it's more than unfortunate if that's all we accomplish. As I look to doing more interesting things where I have different applications running in various devices connected to different networks and associated to my "phone" where I can utilize all of them as a part of a "call", I see value in having this end-to-end identifier for even this more complex arrangement. However, I can understand if service providers do not take an active interest in this. From a research perspective, these more advanced communication systems are interesting. From a business perspective, there is a question about ROI for carriers. I get that: there's no money in doing much more than providing the most basic voice service, and even that service has a very small profit margin. However, progress, capabilities, functionality, and improvements in the way we work and communicate should go forward, and they are. Already, we see a number of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect functionality will become much more interesting, with a wider mix of multimedia applications in use at once. Bottom line is that we should not constrain a system, but try to make it as flexible as possible. It might not work everywhere, but don't constrain ourselves to the most basic voice call flow. Paul > -hadriel > > > On Aug 2, 2013, at 11:48 AM, Paul E. Jones wrote: > > > Larua, > > > > So in effect, the current deployments are not end-to-end, but > > edge-to- > edge somewhere. I can appreciate that, but it does make it more > challenging to try to work with when we go all the way end-to-end. > > > > Paul > > > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > Sent: Friday, August 02, 2013 4:47 AM > > To: Paul E. Jones > > Cc: insipid@ietf.org > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > > Paul, > > > > As I said, we never used the old Session-ID to do more than > > correlate > bothe legs of the same dialog. So in your example we have: > > - Alice to Bob: Session-ID A > > - Bob to Carol: Session-ID B > > - Alice to Carol: Session-ID C > > > > There is no correlation between them. We just correlate both legs of > > the > same dialog across the SBC between Alice and Bob. > > > > Thank you > > Laura > > > > > > > > 2013/8/1 Paul E. Jones Laura, > > > > The example I show below is a real call center example. I show use > > of > the old session ID. Tell me how that works. Forget about the new > solution for the moment. > > > > If you say it will not work, then I'm not sure how we can make > > something > work with something that does not work. If there is a way to make this > work, then we can try to figure out how to interwork with it. > > > > Paul > > > > > > > > From: Laura Liess > > Sent: Thu Aug 01 11:51:26 EDT 2013 > > > > To: "Paul E. Jones" > > Cc: insipid@ietf.org > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > > Paul, > > We use the old Session-ID only accross SBCs, to correlate both legs > > of > the same dialog. And it works fine for this use case. We never tried, > intend or were required to do more with it. > > We are not against the new mechanism, we just want it to interwork > > with > the old one which we have in thousands of customer end devices. If it does, > we can add new end devices and application servers which support the > new Session-ID. Otherwise we can't. > > > > Let's see if it works when we keep the UUID order unchanged, as > > Hadriel > proposed. > > > > Thank you > > Laura > > > > > > 2013/8/1 Paul E. Jones Laura, > > > > I assert that old draft will not work for some "real-world" calls. > Calls do get manipulated in enterprise environments and call centers > for billing purposes, privacy reasons, etc. > > > > Consider a common case: if you call into a call center and the agent > puts you on hold while they transfer you to a specialist (transfer out > of consultation), for example, your SIP UA does not receive a REFER to > initiate a new call directly to the specialist. This is handled at > the call center. > > > > So rather specifically, how would this be handled (with the old draft)? > > > > 1) Alice calls Bob (Session-ID: A) > > 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > > 3) Bob transfers the call from Alice to Carol using a local transfer > function on the PBX (Session-ID: ??) > > > > The PBX could send different values to Alice and Carol, but we > > totally > lose the end-to-end identification of the call. > > > > Alice could not send "A" to Carol, since Carol is expecting B. Likewise, > Carol cannot send "B" to Alice, since Alice is expecting "A". Well, > they could, and it would be no worse than our current proposal in > terms of backward-compatibility. > > > > Paul > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Laura Liess > > Sent: Thursday, August 01, 2013 9:13 AM > > To: insipid@ietf.org > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > > > > Hadriel's proposal works for us. > > > > Thank you > > Laura > > > > > > 2013/8/1 Hadriel Kaplan > > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. > > another > vendor. This is just about a Working Group document, and whether the > mechanism defined in it should change the Session-ID header value vs. > parameter based on direction of messages, or not. I totally get the > need to have a distinguishing Session-ID identifier for party-A vs. party-B. > What I don't get is why they need to change the encoding of the > Session-ID header value vs. parameter, on a message direction basis. > > > > In other words, today the draft has this: > > 1) Alice sends INVITE with "Session-ID: foo" > > 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > > 4) Bob sends BYE with "Session-ID: bar;remote=foo" > > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > > > But we could instead do this: > > 1) Alice sends INVITE with "Session-ID: foo" > > 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > > 3) Alice sends ACK with "Session-ID: foo;remote=bar" > > 4) Bob sends BYE with "Session-ID: foo;remote=bar" > > 5) Alice sends 200 with "Session-ID: foo;remote=bar" > > > > This second model keeps the Session-ID header value as "foo" the > > whole > time, while adding a parameter of "bar" for Bob that remains a > parameter the whole time. > > Neither Alice nor Bob are confused about which one is "their" UUID value. > > And it's backward-compatible with the previous kaplan-draft. > > And it's arguably easier to implement, for the common cases. > > > > I *think* there was a reason someone came up with at one time as to > > why > it had to be swapped, but I don't remember what it is and I don't see > it in the draft. So I'm trying to find out why we need to do it the > way the draft currently has it. > > > > The other topic of whether SBCs will change things is completely > orthogonal to the ordering or backwards compatibility issues, and > really shouldn't be conflated with it at all. It has nothing to do > with the solutions document, or the direction stuff, etc. > > > > -hadriel > > > > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones wrote: > > > > > Folks, > > > > > > I step away for a couple of days and the floodgate opens. :) > > > > > > I think it's important to understand why we proposed using a > > > two-part Session Identifier. The reason is that we have to be > > > able to > effectively > > > deal with things like forking, call transfer, park, bridging, > conferencing, > > > etc. > > > > > > When initiating a call and using a single UUID value, that has the > potential > > > to go end-to-end. However, if a call is forked there are multiple > "ends". > > > How do we track each of those? For proper diagnostics and > troubleshooting, > > > it would be ideal to be able to identify which devices have an issue. > > > > > > Once a call has been placed, there is a Session-ID established > > > between > Alice > > > and Bob. If Alice (in one country) transfers Bob (perhaps in the > > > same > or > > > different country) to a some location in a high-toll country, who > > > pays > the > > > bill? Well, to address that, we do call transfer locally on PBXes. > The PBX > > > maintains control over the call and Alice would pay the bill for > > > the > call > > > transfer. But if Alice was talking to Carol before the transfer, > there is a > > > Session-ID for that call. If Bob is put in communication with > > > Carol, > what > > > is the Session-ID value? Bob had one and Carol had a different one. > What > > > is the new ID? > > > > > > It's issues like this that led us to using a two-part value. In > > > this > way, > > > we could see the call from Alice to Bob has a Session-ID {A,B}. > > > If > Alice > > > transfers the call to Carol, each device understands that the > > > Session- > ID > > > changed to {B,C}. Not only that, but intermediaries along the > > > path > that > > > were not privy to signaling that resulted in this change can take > > > note > of > > > the fact the value changed. This can provide a useful historical > record, > > > since previously they might see a call to Carol identified as > > > {A,C}, > but > > > then it changed to {B,C}. > > > > > > This property extends quite naturally to other signaling > > > scenarios, as > it > > > allows one to identify a call end-to-end, but also establish some > > > relationship between other calls that shared at least one UUID > > > value > out of > > > the two. > > > > > > Hadriel mentioned the desire to use the Session-ID to correlate > > > media > flows > > > and calls. That's certainly something Cisco would like to do, but > > > it > is not > > > the driver behind the solution. Having a valid end-to-end > > > identifier > (in > > > whatever form) allows us to do that. We're not suggesting to fit > > > the solution to meet that business use case, but rather we just > > > want a > solution > > > that allows us to properly identify calls end-to-end and we > > > recognize > that, > > > due to various service interactions in the network, these UUID > > > values > can > > > change. > > > > > > I would hope that UUID values will not change to the extent that > > > SBCs > change > > > them for business reasons. It would certainly defeat the point. > Hadriel > > > might be right that an SBC vendor might manipulate those values at > > > the request of a customer, but I would hope said customer > > > appreciates that > such > > > a request effectively breaks the end-to-end model. We can't do > > > much > about > > > that if they do go down that path. > > > > > > As for backward-compatibility, the simplest approach (IMO) is to > > > just > use a > > > header value not already in use. Originally, we had proposed > > > Session- > UUID. > > > That was changed at the request of the group to be Session-ID. > However, > > > when we have a two UUID solution interacting with a one-UUID > > > solution, > we > > > immediately face some challenges. > > > > > > What happens if an older system sends this: > > > Session-ID: X > > > But then receives this: > > > Session-ID: Y; remote=X > > > > > > Does this break things? If so, how do current implementations > > > deal > with > > > such things as mid-call transfers that happen on a PBX like the > > > one I described above? > > > > > > We could switch the order like this: > > > Session-ID: X; remote=Y > > > > > > However, that does not work for similar reasons. If we have a > > > call > transfer > > > where Alice transfers a call with Bob to Carol, then each has a > different > > > idea about what the proper value is for the first position. > > > > > > Originally, the proposed solution did not indicate position > information and > > > just had single UUID values going in each direction. We then > > > proposed > a > > > concatenated string (X:Y). However, that presented the same issues > > > for > the > > > call transfer case, so we indicate values by position (sender's > > > value first), so it is clear what value the receive thinks the > > > remote end > has for > > > the local end. It might be wrong, but that will be corrected in > > > the following response. (Intermediaries can take note of the > > > change.) > > > > > > So, that's why we are where we are. There has been an effort to > maintain > > > backward-compatibility, but there are challenges in meeting that > > > requirement. Where it falls short, we do not know: we've not been > told > > > explicitly what the issues are. Further, if there are such > > > issues, we > need > > > to also understand how those would be handled in the face of call > transfer > > > or "joining" a call locally on a PBX. Those are real-world > > > scenarios > that > > > we must address. > > > > > > Anyway, nothing is set in stone. Anything can be changed, but I > > > would > hope > > > we can find a solution that works for the enterprise use cases as > > > well > as > > > the service provider networks. > > > > > > 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 _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed Aug 14 02:56:19 2013 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 8206E11E811E for ; Wed, 14 Aug 2013 02:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4gazbY-WDOb for ; Wed, 14 Aug 2013 02:56:14 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BDCC611E8101 for ; Wed, 14 Aug 2013 02:56:13 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r7E9u97x007524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Aug 2013 04:56:10 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r7E9u57K026721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 11:56:06 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 14 Aug 2013 11:56:05 +0200 From: "DRAGE, Keith (Keith)" To: "iain.mcilwaine@opencloud.com" , "Paul E. Jones" , Hadriel Kaplan , Laura Liess Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKZdDx82AgACYdICAACsJYA== Date: Wed, 14 Aug 2013 09:56:04 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0820DB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> In-Reply-To: <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "insipid@ietf.org" Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 09:56:19 -0000 Hopefully Hadriel will soon solve lots of the confusion by performing the a= ction he took at the INSIPID meeting, which was to post revisions of the ca= ll flows with the changes needed to ensure compatibility. That will then provide a more secure basis for argument. That action I believe expires on Friday/Saturday/Sunday. Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Iain McIlwaine > Sent: 14 August 2013 10:20 > To: Paul E. Jones; Hadriel Kaplan; Laura Liess > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility >=20 > Folks, >=20 > I see a lot of discussion for enterprise transfer scenarios but I would > like to highlight a problematic use case to gauge your opinions. >=20 > Using Hadriel's method which designates local:remote of the UUID accordin= g > to the issuer of the INVITE I can see a potential problem for Access > Transfer when the party being transferred is in the "proceeding" state. > So: >=20 > Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" > Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=3Dbar" > Bob' INVITE - "Transfer AS" Session-ID:foo' >=20 > Note: the "Transfer AS" can be an ATCF or an SCC. >=20 > We can see in this case using Hadriel's syntax we now require the Transfe= r > AS to perform manipulation of the Session-ID header which runs contrary t= o > a stated objective of no intermediary meddling of the header. >=20 > If we revert to interpreting the local:remote syntax being within the > context of the receiver I believe we would avert this situation. >=20 > Of course it could be I've misunderstood something so happy to be shown > the light. >=20 > Kind regards, > Iain >=20 >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: 13 August 2013 23:34 > To: 'Hadriel Kaplan' > Cc: insipid@ietf.org; 'Laura Liess' > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility >=20 > Hadriel, >=20 > > I can't tell if you seriously believe the new mechanism is going to > > work end-to-end across all domains, or if you just mean end-to-end > > within a domain (like within the call-center). I don't mean that in a > > negative way > > - I just mean I don't understand how you mean the words "end-to-end". >=20 > I seriously mean end-to-end. Assuming service providers did not block > passage of an INVITE containing a new UUID value, then we can always have > an end-to-end value. As an "end" changes, so does the end-to-end value. > That's OK. >=20 > > I seriously doubt this thing is going to achieve any more than the > > legacy draft did in terms of true end-to-end across-the-world type > > thing. In fact it may even do less. >=20 > The only reason it would not is if: > 1) One endpoint does not support the procedures (can't help that) > 2) Something prevents a new INVITE from going to one endpoint (like an > SBC) >=20 > Otherwise, it would work. >=20 > > When I make a call from my cell phone through my mobile provider, > > through N number of carriers, to an Enterprise call-center somewhere > > in Timbuktu, I have a hard time believing all the carriers and mobile > > providers want to get back and process a re-INVITE each and every time > > the call gets moved around inside the call-center's internal PBX > > infrastructure. They rarely get that today, and I don't see them > changing in the future to do so... > > for what benefit? What use is it to update all the SIP systems along > > the path, as well as my cell phone, with a new Session-ID value just > > because the call got parked/unparked or internally transferred inside > PBX/ACD/etc. > > systems in a call-center somewhere? > > > > Some call centers move the media around almost a dozen times per call. > > You really think the rest of the world wants to get a dozen > > re-INVITEs, for no benefit? The SBCs aren't answering the re-INVITEs > > locally today to hide the identity of who/what it gets moved around to > > - that we already do even when we forward the re-INVITEs - we're > > answering them locally because the service providers don't want nor > > need those re-INVITEs. It's just extra processing load, log entries, > > and things that can go wrong; with no added benefit. >=20 > I really cannot do anything about these "noise" issues. I recognize that > in practice, much of the use of SIP has been absolutely nothing more tha= n > a PSTN replacement. It has been merely a means of moving from TDM to IP. > I'm glad it happened, but it's more than unfortunate if that's all we > accomplish. >=20 > As I look to doing more interesting things where I have different > applications running in various devices connected to different networks > and associated to my "phone" where I can utilize all of them as a part of > a "call", I see value in having this end-to-end identifier for even this > more complex arrangement. However, I can understand if service providers > do not take an active interest in this. From a research perspective, > these more advanced communication systems are interesting. From a > business perspective, there is a question about ROI for carriers. I get > that: > there's no money in doing much more than providing the most basic voice > service, and even that service has a very small profit margin. However, > progress, capabilities, functionality, and improvements in the way we wor= k > and communicate should go forward, and they are. Already, we see a numbe= r > of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect > functionality will become much more interesting, with a wider mix of > multimedia applications in use at once. >=20 > Bottom line is that we should not constrain a system, but try to make it > as flexible as possible. It might not work everywhere, but don't > constrain ourselves to the most basic voice call flow. >=20 > Paul >=20 > > -hadriel > > > > > > On Aug 2, 2013, at 11:48 AM, Paul E. Jones > wrote: > > > > > Larua, > > > > > > So in effect, the current deployments are not end-to-end, but > > > edge-to- > > edge somewhere. I can appreciate that, but it does make it more > > challenging to try to work with when we go all the way end-to-end. > > > > > > Paul > > > > > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > > Sent: Friday, August 02, 2013 4:47 AM > > > To: Paul E. Jones > > > Cc: insipid@ietf.org > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > Paul, > > > > > > As I said, we never used the old Session-ID to do more than > > > correlate > > bothe legs of the same dialog. So in your example we have: > > > - Alice to Bob: Session-ID A > > > - Bob to Carol: Session-ID B > > > - Alice to Carol: Session-ID C > > > > > > There is no correlation between them. We just correlate both legs of > > > the > > same dialog across the SBC between Alice and Bob. > > > > > > Thank you > > > Laura > > > > > > > > > > > > 2013/8/1 Paul E. Jones Laura, > > > > > > The example I show below is a real call center example. I show use > > > of > > the old session ID. Tell me how that works. Forget about the new > > solution for the moment. > > > > > > If you say it will not work, then I'm not sure how we can make > > > something > > work with something that does not work. If there is a way to make this > > work, then we can try to figure out how to interwork with it. > > > > > > Paul > > > > > > > > > > > > From: Laura Liess > > > Sent: Thu Aug 01 11:51:26 EDT 2013 > > > > > > To: "Paul E. Jones" > > > Cc: insipid@ietf.org > > > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > Paul, > > > We use the old Session-ID only accross SBCs, to correlate both legs > > > of > > the same dialog. And it works fine for this use case. We never tried, > > intend or were required to do more with it. > > > We are not against the new mechanism, we just want it to interwork > > > with > > the old one which we have in thousands of customer end devices. If it > does, > > we can add new end devices and application servers which support the > > new Session-ID. Otherwise we can't. > > > > > > Let's see if it works when we keep the UUID order unchanged, as > > > Hadriel > > proposed. > > > > > > Thank you > > > Laura > > > > > > > > > 2013/8/1 Paul E. Jones Laura, > > > > > > I assert that old draft will not work for some "real-world" calls. > > Calls do get manipulated in enterprise environments and call centers > > for billing purposes, privacy reasons, etc. > > > > > > Consider a common case: if you call into a call center and the agent > > puts you on hold while they transfer you to a specialist (transfer out > > of consultation), for example, your SIP UA does not receive a REFER to > > initiate a new call directly to the specialist. This is handled at > > the call center. > > > > > > So rather specifically, how would this be handled (with the old > draft)? > > > > > > 1) Alice calls Bob (Session-ID: A) > > > 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > > > 3) Bob transfers the call from Alice to Carol using a local transfer > > function on the PBX (Session-ID: ??) > > > > > > The PBX could send different values to Alice and Carol, but we > > > totally > > lose the end-to-end identification of the call. > > > > > > Alice could not send "A" to Carol, since Carol is expecting B. > Likewise, > > Carol cannot send "B" to Alice, since Alice is expecting "A". Well, > > they could, and it would be no worse than our current proposal in > > terms of backward-compatibility. > > > > > > Paul > > > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Laura Liess > > > Sent: Thursday, August 01, 2013 9:13 AM > > > To: insipid@ietf.org > > > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > > > > Hadriel's proposal works for us. > > > > > > Thank you > > > Laura > > > > > > > > > 2013/8/1 Hadriel Kaplan > > > > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. > > > another > > vendor. This is just about a Working Group document, and whether the > > mechanism defined in it should change the Session-ID header value vs. > > parameter based on direction of messages, or not. I totally get the > > need to have a distinguishing Session-ID identifier for party-A vs. > party-B. > > What I don't get is why they need to change the encoding of the > > Session-ID header value vs. parameter, on a message direction basis. > > > > > > In other words, today the draft has this: > > > 1) Alice sends INVITE with "Session-ID: foo" > > > 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" > > > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > > > 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" > > > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" > > > > > > But we could instead do this: > > > 1) Alice sends INVITE with "Session-ID: foo" > > > 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" > > > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > > > 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" > > > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" > > > > > > This second model keeps the Session-ID header value as "foo" the > > > whole > > time, while adding a parameter of "bar" for Bob that remains a > > parameter the whole time. > > > Neither Alice nor Bob are confused about which one is "their" UUID > value. > > > And it's backward-compatible with the previous kaplan-draft. > > > And it's arguably easier to implement, for the common cases. > > > > > > I *think* there was a reason someone came up with at one time as to > > > why > > it had to be swapped, but I don't remember what it is and I don't see > > it in the draft. So I'm trying to find out why we need to do it the > > way the draft currently has it. > > > > > > The other topic of whether SBCs will change things is completely > > orthogonal to the ordering or backwards compatibility issues, and > > really shouldn't be conflated with it at all. It has nothing to do > > with the solutions document, or the direction stuff, etc. > > > > > > -hadriel > > > > > > > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones > wrote: > > > > > > > Folks, > > > > > > > > I step away for a couple of days and the floodgate opens. :) > > > > > > > > I think it's important to understand why we proposed using a > > > > two-part Session Identifier. The reason is that we have to be > > > > able to > > effectively > > > > deal with things like forking, call transfer, park, bridging, > > conferencing, > > > > etc. > > > > > > > > When initiating a call and using a single UUID value, that has the > > potential > > > > to go end-to-end. However, if a call is forked there are multiple > > "ends". > > > > How do we track each of those? For proper diagnostics and > > troubleshooting, > > > > it would be ideal to be able to identify which devices have an > issue. > > > > > > > > Once a call has been placed, there is a Session-ID established > > > > between > > Alice > > > > and Bob. If Alice (in one country) transfers Bob (perhaps in the > > > > same > > or > > > > different country) to a some location in a high-toll country, who > > > > pays > > the > > > > bill? Well, to address that, we do call transfer locally on PBXes. > > The PBX > > > > maintains control over the call and Alice would pay the bill for > > > > the > > call > > > > transfer. But if Alice was talking to Carol before the transfer, > > there is a > > > > Session-ID for that call. If Bob is put in communication with > > > > Carol, > > what > > > > is the Session-ID value? Bob had one and Carol had a different one= . > > What > > > > is the new ID? > > > > > > > > It's issues like this that led us to using a two-part value. In > > > > this > > way, > > > > we could see the call from Alice to Bob has a Session-ID {A,B}. > > > > If > > Alice > > > > transfers the call to Carol, each device understands that the > > > > Session- > > ID > > > > changed to {B,C}. Not only that, but intermediaries along the > > > > path > > that > > > > were not privy to signaling that resulted in this change can take > > > > note > > of > > > > the fact the value changed. This can provide a useful historical > > record, > > > > since previously they might see a call to Carol identified as > > > > {A,C}, > > but > > > > then it changed to {B,C}. > > > > > > > > This property extends quite naturally to other signaling > > > > scenarios, as > > it > > > > allows one to identify a call end-to-end, but also establish some > > > > relationship between other calls that shared at least one UUID > > > > value > > out of > > > > the two. > > > > > > > > Hadriel mentioned the desire to use the Session-ID to correlate > > > > media > > flows > > > > and calls. That's certainly something Cisco would like to do, but > > > > it > > is not > > > > the driver behind the solution. Having a valid end-to-end > > > > identifier > > (in > > > > whatever form) allows us to do that. We're not suggesting to fit > > > > the solution to meet that business use case, but rather we just > > > > want a > > solution > > > > that allows us to properly identify calls end-to-end and we > > > > recognize > > that, > > > > due to various service interactions in the network, these UUID > > > > values > > can > > > > change. > > > > > > > > I would hope that UUID values will not change to the extent that > > > > SBCs > > change > > > > them for business reasons. It would certainly defeat the point. > > Hadriel > > > > might be right that an SBC vendor might manipulate those values at > > > > the request of a customer, but I would hope said customer > > > > appreciates that > > such > > > > a request effectively breaks the end-to-end model. We can't do > > > > much > > about > > > > that if they do go down that path. > > > > > > > > As for backward-compatibility, the simplest approach (IMO) is to > > > > just > > use a > > > > header value not already in use. Originally, we had proposed > > > > Session- > > UUID. > > > > That was changed at the request of the group to be Session-ID. > > However, > > > > when we have a two UUID solution interacting with a one-UUID > > > > solution, > > we > > > > immediately face some challenges. > > > > > > > > What happens if an older system sends this: > > > > Session-ID: X > > > > But then receives this: > > > > Session-ID: Y; remote=3DX > > > > > > > > Does this break things? If so, how do current implementations > > > > deal > > with > > > > such things as mid-call transfers that happen on a PBX like the > > > > one I described above? > > > > > > > > We could switch the order like this: > > > > Session-ID: X; remote=3DY > > > > > > > > However, that does not work for similar reasons. If we have a > > > > call > > transfer > > > > where Alice transfers a call with Bob to Carol, then each has a > > different > > > > idea about what the proper value is for the first position. > > > > > > > > Originally, the proposed solution did not indicate position > > information and > > > > just had single UUID values going in each direction. We then > > > > proposed > > a > > > > concatenated string (X:Y). However, that presented the same issues > > > > for > > the > > > > call transfer case, so we indicate values by position (sender's > > > > value first), so it is clear what value the receive thinks the > > > > remote end > > has for > > > > the local end. It might be wrong, but that will be corrected in > > > > the following response. (Intermediaries can take note of the > > > > change.) > > > > > > > > So, that's why we are where we are. There has been an effort to > > maintain > > > > backward-compatibility, but there are challenges in meeting that > > > > requirement. Where it falls short, we do not know: we've not been > > told > > > > explicitly what the issues are. Further, if there are such > > > > issues, we > > need > > > > to also understand how those would be handled in the face of call > > transfer > > > > or "joining" a call locally on a PBX. Those are real-world > > > > scenarios > > that > > > > we must address. > > > > > > > > Anyway, nothing is set in stone. Anything can be changed, but I > > > > would > > hope > > > > we can find a solution that works for the enterprise use cases as > > > > well > > as > > > > the service provider networks. > > > > > > > > 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 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Wed Aug 14 03:13:41 2013 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 414A311E8122 for ; Wed, 14 Aug 2013 03:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.999 X-Spam-Level: X-Spam-Status: No, score=-110.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76MDXcmegSmw for ; Wed, 14 Aug 2013 03:13:35 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 98CB521F9E54 for ; Wed, 14 Aug 2013 03:13:34 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r7EADU0j022889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Aug 2013 05:13:32 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r7EADUFo013278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Aug 2013 12:13:30 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 14 Aug 2013 12:13:30 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "'Hadriel Kaplan'" Thread-Topic: [Insipid] Proposed INSIPID solution and backward compatibility Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKZdDx82AgADH2aA= Date: Wed, 14 Aug 2013 10:13:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B082146@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> In-Reply-To: <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "insipid@ietf.org" , 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 10:13:41 -0000 The bottom line is that we attempt to meet the agreed requirements. Your statement at the bottom could be an invitation to feature creep, and w= e already excluded stuff in the requirements discussion. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: 13 August 2013 23:34 > To: 'Hadriel Kaplan' > Cc: insipid@ietf.org; 'Laura Liess' > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility >=20 > Hadriel, >=20 > > I can't tell if you seriously believe the new mechanism is going to wor= k > > end-to-end across all domains, or if you just mean end-to-end within a > > domain (like within the call-center). I don't mean that in a negative > way > > - I just mean I don't understand how you mean the words "end-to-end". >=20 > I seriously mean end-to-end. Assuming service providers did not block > passage of an INVITE containing a new UUID value, then we can always have > an > end-to-end value. As an "end" changes, so does the end-to-end value. > That's OK. >=20 > > I seriously doubt this thing is going to achieve any more than the > legacy > > draft did in terms of true end-to-end across-the-world type thing. In > > fact it may even do less. >=20 > The only reason it would not is if: > 1) One endpoint does not support the procedures (can't help that) > 2) Something prevents a new INVITE from going to one endpoint (like an > SBC) >=20 > Otherwise, it would work. >=20 > > When I make a call from my cell phone through my mobile provider, > through > > N number of carriers, to an Enterprise call-center somewhere in Timbukt= u, > > I have a hard time believing all the carriers and mobile providers want > to > > get back and process a re-INVITE each and every time the call gets move= d > > around inside the call-center's internal PBX infrastructure. They > rarely > > get that today, and I don't see them changing in the future to do so... > > for what benefit? What use is it to update all the SIP systems along > the > > path, as well as my cell phone, with a new Session-ID value just becaus= e > > the call got parked/unparked or internally transferred inside > PBX/ACD/etc. > > systems in a call-center somewhere? > > > > Some call centers move the media around almost a dozen times per call. > > You really think the rest of the world wants to get a dozen re-INVITEs, > > for no benefit? The SBCs aren't answering the re-INVITEs locally today > to > > hide the identity of who/what it gets moved around to - that we already > do > > even when we forward the re-INVITEs - we're answering them locally > because > > the service providers don't want nor need those re-INVITEs. It's just > > extra processing load, log entries, and things that can go wrong; with > no > > added benefit. >=20 > I really cannot do anything about these "noise" issues. I recognize that > in > practice, much of the use of SIP has been absolutely nothing more than a > PSTN replacement. It has been merely a means of moving from TDM to IP. > I'm > glad it happened, but it's more than unfortunate if that's all we > accomplish. >=20 > As I look to doing more interesting things where I have different > applications running in various devices connected to different networks > and > associated to my "phone" where I can utilize all of them as a part of a > "call", I see value in having this end-to-end identifier for even this > more > complex arrangement. However, I can understand if service providers do > not > take an active interest in this. From a research perspective, these more > advanced communication systems are interesting. From a business > perspective, there is a question about ROI for carriers. I get that: > there's no money in doing much more than providing the most basic voice > service, and even that service has a very small profit margin. However, > progress, capabilities, functionality, and improvements in the way we wor= k > and communicate should go forward, and they are. Already, we see a numbe= r > of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect > functionality will become much more interesting, with a wider mix of > multimedia applications in use at once. >=20 > Bottom line is that we should not constrain a system, but try to make it > as > flexible as possible. It might not work everywhere, but don't constrain > ourselves to the most basic voice call flow. >=20 > Paul >=20 > > -hadriel > > > > > > On Aug 2, 2013, at 11:48 AM, Paul E. Jones > wrote: > > > > > Larua, > > > > > > So in effect, the current deployments are not end-to-end, but edge-to= - > > edge somewhere. I can appreciate that, but it does make it more > > challenging to try to work with when we go all the way end-to-end. > > > > > > Paul > > > > > > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > > > Sent: Friday, August 02, 2013 4:47 AM > > > To: Paul E. Jones > > > Cc: insipid@ietf.org > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > Paul, > > > > > > As I said, we never used the old Session-ID to do more than correlate > > bothe legs of the same dialog. So in your example we have: > > > - Alice to Bob: Session-ID A > > > - Bob to Carol: Session-ID B > > > - Alice to Carol: Session-ID C > > > > > > There is no correlation between them. We just correlate both legs of > the > > same dialog across the SBC between Alice and Bob. > > > > > > Thank you > > > Laura > > > > > > > > > > > > 2013/8/1 Paul E. Jones > > > Laura, > > > > > > The example I show below is a real call center example. I show use of > > the old session ID. Tell me how that works. Forget about the new > solution > > for the moment. > > > > > > If you say it will not work, then I'm not sure how we can make > something > > work with something that does not work. If there is a way to make this > > work, then we can try to figure out how to interwork with it. > > > > > > Paul > > > > > > > > > > > > From: Laura Liess > > > Sent: Thu Aug 01 11:51:26 EDT 2013 > > > > > > To: "Paul E. Jones" > > > Cc: insipid@ietf.org > > > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > Paul, > > > We use the old Session-ID only accross SBCs, to correlate both legs o= f > > the same dialog. And it works fine for this use case. We never tried, > > intend or were required to do more with it. > > > We are not against the new mechanism, we just want it to interwork > with > > the old one which we have in thousands of customer end devices. If it > does, > > we can add new end devices and application servers which support the ne= w > > Session-ID. Otherwise we can't. > > > > > > Let's see if it works when we keep the UUID order unchanged, as > Hadriel > > proposed. > > > > > > Thank you > > > Laura > > > > > > > > > 2013/8/1 Paul E. Jones > > > Laura, > > > > > > I assert that old draft will not work for some "real-world" calls. > > Calls do get manipulated in enterprise environments and call centers fo= r > > billing purposes, privacy reasons, etc. > > > > > > Consider a common case: if you call into a call center and the agent > > puts you on hold while they transfer you to a specialist (transfer out > of > > consultation), for example, your SIP UA does not receive a REFER to > > initiate a new call directly to the specialist. This is handled at the > > call center. > > > > > > So rather specifically, how would this be handled (with the old > draft)? > > > > > > 1) Alice calls Bob (Session-ID: A) > > > 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > > > 3) Bob transfers the call from Alice to Carol using a local transfer > > function on the PBX (Session-ID: ??) > > > > > > The PBX could send different values to Alice and Carol, but we totall= y > > lose the end-to-end identification of the call. > > > > > > Alice could not send "A" to Carol, since Carol is expecting B. > Likewise, > > Carol cannot send "B" to Alice, since Alice is expecting "A". Well, > they > > could, and it would be no worse than our current proposal in terms of > > backward-compatibility. > > > > > > Paul > > > > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Laura Liess > > > Sent: Thursday, August 01, 2013 9:13 AM > > > To: insipid@ietf.org > > > > > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > > > > Hadriel's proposal works for us. > > > > > > Thank you > > > Laura > > > > > > > > > 2013/8/1 Hadriel Kaplan > > > > > > This isn't about Enterprise vs. Service-Provider, or Cisco vs. anothe= r > > vendor. This is just about a Working Group document, and whether the > > mechanism defined in it should change the Session-ID header value vs. > > parameter based on direction of messages, or not. I totally get the > need > > to have a distinguishing Session-ID identifier for party-A vs. party-B. > > What I don't get is why they need to change the encoding of the Session= - > ID > > header value vs. parameter, on a message direction basis. > > > > > > In other words, today the draft has this: > > > 1) Alice sends INVITE with "Session-ID: foo" > > > 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" > > > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > > > 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" > > > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" > > > > > > But we could instead do this: > > > 1) Alice sends INVITE with "Session-ID: foo" > > > 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" > > > 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" > > > 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" > > > 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" > > > > > > This second model keeps the Session-ID header value as "foo" the whol= e > > time, while adding a parameter of "bar" for Bob that remains a paramete= r > > the whole time. > > > Neither Alice nor Bob are confused about which one is "their" UUID > value. > > > And it's backward-compatible with the previous kaplan-draft. > > > And it's arguably easier to implement, for the common cases. > > > > > > I *think* there was a reason someone came up with at one time as to > why > > it had to be swapped, but I don't remember what it is and I don't see i= t > > in the draft. So I'm trying to find out why we need to do it the way > the > > draft currently has it. > > > > > > The other topic of whether SBCs will change things is completely > > orthogonal to the ordering or backwards compatibility issues, and reall= y > > shouldn't be conflated with it at all. It has nothing to do with the > > solutions document, or the direction stuff, etc. > > > > > > -hadriel > > > > > > > > > On Aug 1, 2013, at 12:38 AM, Paul E. Jones > wrote: > > > > > > > Folks, > > > > > > > > I step away for a couple of days and the floodgate opens. :) > > > > > > > > I think it's important to understand why we proposed using a two- > part > > > > Session Identifier. The reason is that we have to be able to > > effectively > > > > deal with things like forking, call transfer, park, bridging, > > conferencing, > > > > etc. > > > > > > > > When initiating a call and using a single UUID value, that has the > > potential > > > > to go end-to-end. However, if a call is forked there are multiple > > "ends". > > > > How do we track each of those? For proper diagnostics and > > troubleshooting, > > > > it would be ideal to be able to identify which devices have an issu= e. > > > > > > > > Once a call has been placed, there is a Session-ID established > between > > Alice > > > > and Bob. If Alice (in one country) transfers Bob (perhaps in the > same > > or > > > > different country) to a some location in a high-toll country, who > pays > > the > > > > bill? Well, to address that, we do call transfer locally on PBXes. > > The PBX > > > > maintains control over the call and Alice would pay the bill for th= e > > call > > > > transfer. But if Alice was talking to Carol before the transfer, > > there is a > > > > Session-ID for that call. If Bob is put in communication with Caro= l, > > what > > > > is the Session-ID value? Bob had one and Carol had a different one= . > > What > > > > is the new ID? > > > > > > > > It's issues like this that led us to using a two-part value. In > this > > way, > > > > we could see the call from Alice to Bob has a Session-ID {A,B}. If > > Alice > > > > transfers the call to Carol, each device understands that the > Session- > > ID > > > > changed to {B,C}. Not only that, but intermediaries along the path > > that > > > > were not privy to signaling that resulted in this change can take > note > > of > > > > the fact the value changed. This can provide a useful historical > > record, > > > > since previously they might see a call to Carol identified as {A,C}= , > > but > > > > then it changed to {B,C}. > > > > > > > > This property extends quite naturally to other signaling scenarios, > as > > it > > > > allows one to identify a call end-to-end, but also establish some > > > > relationship between other calls that shared at least one UUID valu= e > > out of > > > > the two. > > > > > > > > Hadriel mentioned the desire to use the Session-ID to correlate > media > > flows > > > > and calls. That's certainly something Cisco would like to do, but > it > > is not > > > > the driver behind the solution. Having a valid end-to-end > identifier > > (in > > > > whatever form) allows us to do that. We're not suggesting to fit > the > > > > solution to meet that business use case, but rather we just want a > > solution > > > > that allows us to properly identify calls end-to-end and we > recognize > > that, > > > > due to various service interactions in the network, these UUID > values > > can > > > > change. > > > > > > > > I would hope that UUID values will not change to the extent that > SBCs > > change > > > > them for business reasons. It would certainly defeat the point. > > Hadriel > > > > might be right that an SBC vendor might manipulate those values at > the > > > > request of a customer, but I would hope said customer appreciates > that > > such > > > > a request effectively breaks the end-to-end model. We can't do muc= h > > about > > > > that if they do go down that path. > > > > > > > > As for backward-compatibility, the simplest approach (IMO) is to > just > > use a > > > > header value not already in use. Originally, we had proposed > Session- > > UUID. > > > > That was changed at the request of the group to be Session-ID. > > However, > > > > when we have a two UUID solution interacting with a one-UUID > solution, > > we > > > > immediately face some challenges. > > > > > > > > What happens if an older system sends this: > > > > Session-ID: X > > > > But then receives this: > > > > Session-ID: Y; remote=3DX > > > > > > > > Does this break things? If so, how do current implementations deal > > with > > > > such things as mid-call transfers that happen on a PBX like the one > I > > > > described above? > > > > > > > > We could switch the order like this: > > > > Session-ID: X; remote=3DY > > > > > > > > However, that does not work for similar reasons. If we have a call > > transfer > > > > where Alice transfers a call with Bob to Carol, then each has a > > different > > > > idea about what the proper value is for the first position. > > > > > > > > Originally, the proposed solution did not indicate position > > information and > > > > just had single UUID values going in each direction. We then > proposed > > a > > > > concatenated string (X:Y). However, that presented the same issues > for > > the > > > > call transfer case, so we indicate values by position (sender's > value > > > > first), so it is clear what value the receive thinks the remote end > > has for > > > > the local end. It might be wrong, but that will be corrected in th= e > > > > following response. (Intermediaries can take note of the change.) > > > > > > > > So, that's why we are where we are. There has been an effort to > > maintain > > > > backward-compatibility, but there are challenges in meeting that > > > > requirement. Where it falls short, we do not know: we've not been > > told > > > > explicitly what the issues are. Further, if there are such issues, > we > > need > > > > to also understand how those would be handled in the face of call > > transfer > > > > or "joining" a call locally on a PBX. Those are real-world > scenarios > > that > > > > we must address. > > > > > > > > Anyway, nothing is set in stone. Anything can be changed, but I > would > > hope > > > > we can find a solution that works for the enterprise use cases as > well > > as > > > > the service provider networks. > > > > > > > > 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 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From hadriel.kaplan@oracle.com Wed Aug 14 07:22:26 2013 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 C702F21E8084 for ; Wed, 14 Aug 2013 07:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdyLTMNriJB7 for ; Wed, 14 Aug 2013 07:22:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 553CA11E81EC for ; Wed, 14 Aug 2013 07:21:44 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7EELeCo032422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 14:21:42 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EELd2i017857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 14:21:40 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EELdR1006893; Wed, 14 Aug 2013 14:21:39 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 07:21:38 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> Date: Wed, 14 Aug 2013 10:21:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> To: iain.mcilwaine@opencloud.com X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:22:29 -0000 I think it depends on how the "Transfer AS" is going to work, and what = you think "manipulation" means or why it matters. How is it any = different than a PBX call transfer scenario? Is the problem you're = describing a real transfer where Bob just didn't send a 200 yet, or do = you really mean a call-forwarding scenario, with early media? If you just mean the equivalent of call-forwarding type thing, where the = forwarding app server sends a 18x to generate "please wait while we = locate your party" media, then that's still ok (I think). Nothing ever = said the header parameter value couldn't change between responses. So = it would be like this: Alice INVITE through AS to Bob =3D "Session-ID:foo" Bob 18x through AS to Alice =3D "Session-ID:foo;remote=3Dbar" Bob INVITE through AS to Carol =3D "Session-ID:foo" Carol 18x/2xx through AS to Bob =3D "Session-ID:foo;remote=3Dqux" Bob 2xx through AS to Alice =3D "Session-ID:foo;remote=3Dqux" If you mean a real call transfer, it's going to be uglier: Alice INVITE through PBX to Bob =3D "Session-ID:foo" Bob 18x through PBX to Alice =3D "Session-ID:foo;remote=3Dbar" Bob INVITE through PBX to Carol =3D "Session-ID:zab" Carol 18x/2xx through PBX to Bob =3D "Session-ID:zab;remote=3Dqux" [ Bob presses some transfer button thingy, PBX transfers the = Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx to Alice of =3D "Session-ID:foo;remote=3Dqux"=20 Or PBX can send 2xx to Alice of "Session-ID:foo;remote=3Dzab", and send = re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=3Dfoo". I personally think sending re-INVITE/UPDATEs for this thing is going to = cause headaches, but if that's what people want, they can do it. Clearly the PBX has to keep track of these Session-IDs separately on = each call leg for some of these scenarios, but that's hardly a big deal = - it's *already* keeping track of these as separate call-legs with a = bunch of SIP state, because by definition it's acting as a SIP B2BUA = with two separate SIP dialogs. -hadriel On Aug 14, 2013, at 5:20 AM, Iain McIlwaine = wrote: > Folks, >=20 > I see a lot of discussion for enterprise transfer scenarios but I = would > like to highlight a problematic use case to gauge your opinions. >=20 > Using Hadriel's method which designates local:remote of the UUID = according > to the issuer of the INVITE I can see a potential problem for Access > Transfer when the party being transferred is in the "proceeding" = state. > So: >=20 > Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" > Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=3Dbar" > Bob' INVITE - "Transfer AS" Session-ID:foo' >=20 > Note: the "Transfer AS" can be an ATCF or an SCC. >=20 > We can see in this case using Hadriel's syntax we now require the = Transfer > AS to perform manipulation of the Session-ID header which runs = contrary to > a stated objective of no intermediary meddling of the header. >=20 > If we revert to interpreting the local:remote syntax being within the > context of the receiver I believe we would avert this situation. >=20 > Of course it could be I've misunderstood something so happy to be = shown > the light. >=20 > Kind regards, > Iain >=20 >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf > Of Paul E. Jones > Sent: 13 August 2013 23:34 > To: 'Hadriel Kaplan' > Cc: insipid@ietf.org; 'Laura Liess' > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility >=20 > Hadriel, >=20 >> I can't tell if you seriously believe the new mechanism is going to >> work end-to-end across all domains, or if you just mean end-to-end >> within a domain (like within the call-center). I don't mean that in = a >> negative way >> - I just mean I don't understand how you mean the words "end-to-end". >=20 > I seriously mean end-to-end. Assuming service providers did not block > passage of an INVITE containing a new UUID value, then we can always = have > an end-to-end value. As an "end" changes, so does the end-to-end = value. > That's OK. >=20 >> I seriously doubt this thing is going to achieve any more than the >> legacy draft did in terms of true end-to-end across-the-world type >> thing. In fact it may even do less. >=20 > The only reason it would not is if: > 1) One endpoint does not support the procedures (can't help that) > 2) Something prevents a new INVITE from going to one endpoint (like an > SBC) >=20 > Otherwise, it would work. >=20 >> When I make a call from my cell phone through my mobile provider, >> through N number of carriers, to an Enterprise call-center somewhere >> in Timbuktu, I have a hard time believing all the carriers and mobile >> providers want to get back and process a re-INVITE each and every = time >> the call gets moved around inside the call-center's internal PBX >> infrastructure. They rarely get that today, and I don't see them > changing in the future to do so... >> for what benefit? What use is it to update all the SIP systems along >> the path, as well as my cell phone, with a new Session-ID value just >> because the call got parked/unparked or internally transferred inside > PBX/ACD/etc. >> systems in a call-center somewhere? >>=20 >> Some call centers move the media around almost a dozen times per = call. >> You really think the rest of the world wants to get a dozen >> re-INVITEs, for no benefit? The SBCs aren't answering the re-INVITEs >> locally today to hide the identity of who/what it gets moved around = to >> - that we already do even when we forward the re-INVITEs - we're >> answering them locally because the service providers don't want nor >> need those re-INVITEs. It's just extra processing load, log entries, >> and things that can go wrong; with no added benefit. >=20 > I really cannot do anything about these "noise" issues. I recognize = that > in practice, much of the use of SIP has been absolutely nothing more = than > a PSTN replacement. It has been merely a means of moving from TDM to = IP. > I'm glad it happened, but it's more than unfortunate if that's all we > accomplish. >=20 > As I look to doing more interesting things where I have different > applications running in various devices connected to different = networks > and associated to my "phone" where I can utilize all of them as a part = of > a "call", I see value in having this end-to-end identifier for even = this > more complex arrangement. However, I can understand if service = providers > do not take an active interest in this. =46rom a research = perspective, > these more advanced communication systems are interesting. =46rom a > business perspective, there is a question about ROI for carriers. I = get > that: > there's no money in doing much more than providing the most basic = voice > service, and even that service has a very small profit margin. = However, > progress, capabilities, functionality, and improvements in the way we = work > and communicate should go forward, and they are. Already, we see a = number > of alternatives like Skype, Facetime, Google Hangouts, etc. and I = expect > functionality will become much more interesting, with a wider mix of > multimedia applications in use at once. >=20 > Bottom line is that we should not constrain a system, but try to make = it > as flexible as possible. It might not work everywhere, but don't > constrain ourselves to the most basic voice call flow. >=20 > Paul >=20 >> -hadriel >>=20 >>=20 >> On Aug 2, 2013, at 11:48 AM, Paul E. Jones > wrote: >>=20 >>> Larua, >>>=20 >>> So in effect, the current deployments are not end-to-end, but >>> edge-to- >> edge somewhere. I can appreciate that, but it does make it more >> challenging to try to work with when we go all the way end-to-end. >>>=20 >>> Paul >>>=20 >>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >>> Sent: Friday, August 02, 2013 4:47 AM >>> To: Paul E. Jones >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>>=20 >>> Paul, >>>=20 >>> As I said, we never used the old Session-ID to do more than >>> correlate >> bothe legs of the same dialog. So in your example we have: >>> - Alice to Bob: Session-ID A >>> - Bob to Carol: Session-ID B >>> - Alice to Carol: Session-ID C >>>=20 >>> There is no correlation between them. We just correlate both legs of >>> the >> same dialog across the SBC between Alice and Bob. >>>=20 >>> Thank you >>> Laura >>>=20 >>>=20 >>>=20 >>> 2013/8/1 Paul E. Jones Laura, >>>=20 >>> The example I show below is a real call center example. I show use >>> of >> the old session ID. Tell me how that works. Forget about the new >> solution for the moment. >>>=20 >>> If you say it will not work, then I'm not sure how we can make >>> something >> work with something that does not work. If there is a way to make = this >> work, then we can try to figure out how to interwork with it. >>>=20 >>> Paul >>>=20 >>>=20 >>>=20 >>> From: Laura Liess >>> Sent: Thu Aug 01 11:51:26 EDT 2013 >>>=20 >>> To: "Paul E. Jones" >>> Cc: insipid@ietf.org >>>=20 >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>>=20 >>> Paul, >>> We use the old Session-ID only accross SBCs, to correlate both legs >>> of >> the same dialog. And it works fine for this use case. We never tried, >> intend or were required to do more with it. >>> We are not against the new mechanism, we just want it to interwork >>> with >> the old one which we have in thousands of customer end devices. If it > does, >> we can add new end devices and application servers which support the >> new Session-ID. Otherwise we can't. >>>=20 >>> Let's see if it works when we keep the UUID order unchanged, as >>> Hadriel >> proposed. >>>=20 >>> Thank you >>> Laura >>>=20 >>>=20 >>> 2013/8/1 Paul E. Jones Laura, >>>=20 >>> I assert that old draft will not work for some "real-world" calls. >> Calls do get manipulated in enterprise environments and call centers >> for billing purposes, privacy reasons, etc. >>>=20 >>> Consider a common case: if you call into a call center and the agent >> puts you on hold while they transfer you to a specialist (transfer = out >> of consultation), for example, your SIP UA does not receive a REFER = to >> initiate a new call directly to the specialist. This is handled at >> the call center. >>>=20 >>> So rather specifically, how would this be handled (with the old > draft)? >>>=20 >>> 1) Alice calls Bob (Session-ID: A) >>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) >>> 3) Bob transfers the call from Alice to Carol using a local transfer >> function on the PBX (Session-ID: ??) >>>=20 >>> The PBX could send different values to Alice and Carol, but we >>> totally >> lose the end-to-end identification of the call. >>>=20 >>> Alice could not send "A" to Carol, since Carol is expecting B. > Likewise, >> Carol cannot send "B" to Alice, since Alice is expecting "A". Well, >> they could, and it would be no worse than our current proposal in >> terms of backward-compatibility. >>>=20 >>> Paul >>>=20 >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Laura Liess >>> Sent: Thursday, August 01, 2013 9:13 AM >>> To: insipid@ietf.org >>>=20 >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>>=20 >>>=20 >>> Hadriel's proposal works for us. >>>=20 >>> Thank you >>> Laura >>>=20 >>>=20 >>> 2013/8/1 Hadriel Kaplan >>>=20 >>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. >>> another >> vendor. This is just about a Working Group document, and whether the >> mechanism defined in it should change the Session-ID header value vs. >> parameter based on direction of messages, or not. I totally get the >> need to have a distinguishing Session-ID identifier for party-A vs. > party-B. >> What I don't get is why they need to change the encoding of the >> Session-ID header value vs. parameter, on a message direction basis. >>>=20 >>> In other words, today the draft has this: >>> 1) Alice sends INVITE with "Session-ID: foo" >>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" >>> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >>> 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" >>> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >>>=20 >>> But we could instead do this: >>> 1) Alice sends INVITE with "Session-ID: foo" >>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" >>> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >>> 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" >>> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >>>=20 >>> This second model keeps the Session-ID header value as "foo" the >>> whole >> time, while adding a parameter of "bar" for Bob that remains a >> parameter the whole time. >>> Neither Alice nor Bob are confused about which one is "their" UUID > value. >>> And it's backward-compatible with the previous kaplan-draft. >>> And it's arguably easier to implement, for the common cases. >>>=20 >>> I *think* there was a reason someone came up with at one time as to >>> why >> it had to be swapped, but I don't remember what it is and I don't see >> it in the draft. So I'm trying to find out why we need to do it the >> way the draft currently has it. >>>=20 >>> The other topic of whether SBCs will change things is completely >> orthogonal to the ordering or backwards compatibility issues, and >> really shouldn't be conflated with it at all. It has nothing to do >> with the solutions document, or the direction stuff, etc. >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones > wrote: >>>=20 >>>> Folks, >>>>=20 >>>> I step away for a couple of days and the floodgate opens. :) >>>>=20 >>>> I think it's important to understand why we proposed using a >>>> two-part Session Identifier. The reason is that we have to be >>>> able to >> effectively >>>> deal with things like forking, call transfer, park, bridging, >> conferencing, >>>> etc. >>>>=20 >>>> When initiating a call and using a single UUID value, that has the >> potential >>>> to go end-to-end. However, if a call is forked there are multiple >> "ends". >>>> How do we track each of those? For proper diagnostics and >> troubleshooting, >>>> it would be ideal to be able to identify which devices have an > issue. >>>>=20 >>>> Once a call has been placed, there is a Session-ID established >>>> between >> Alice >>>> and Bob. If Alice (in one country) transfers Bob (perhaps in the >>>> same >> or >>>> different country) to a some location in a high-toll country, who >>>> pays >> the >>>> bill? Well, to address that, we do call transfer locally on PBXes. >> The PBX >>>> maintains control over the call and Alice would pay the bill for >>>> the >> call >>>> transfer. But if Alice was talking to Carol before the transfer, >> there is a >>>> Session-ID for that call. If Bob is put in communication with >>>> Carol, >> what >>>> is the Session-ID value? Bob had one and Carol had a different = one. >> What >>>> is the new ID? >>>>=20 >>>> It's issues like this that led us to using a two-part value. In >>>> this >> way, >>>> we could see the call from Alice to Bob has a Session-ID {A,B}. >>>> If >> Alice >>>> transfers the call to Carol, each device understands that the >>>> Session- >> ID >>>> changed to {B,C}. Not only that, but intermediaries along the >>>> path >> that >>>> were not privy to signaling that resulted in this change can take >>>> note >> of >>>> the fact the value changed. This can provide a useful historical >> record, >>>> since previously they might see a call to Carol identified as >>>> {A,C}, >> but >>>> then it changed to {B,C}. >>>>=20 >>>> This property extends quite naturally to other signaling >>>> scenarios, as >> it >>>> allows one to identify a call end-to-end, but also establish some >>>> relationship between other calls that shared at least one UUID >>>> value >> out of >>>> the two. >>>>=20 >>>> Hadriel mentioned the desire to use the Session-ID to correlate >>>> media >> flows >>>> and calls. That's certainly something Cisco would like to do, but >>>> it >> is not >>>> the driver behind the solution. Having a valid end-to-end >>>> identifier >> (in >>>> whatever form) allows us to do that. We're not suggesting to fit >>>> the solution to meet that business use case, but rather we just >>>> want a >> solution >>>> that allows us to properly identify calls end-to-end and we >>>> recognize >> that, >>>> due to various service interactions in the network, these UUID >>>> values >> can >>>> change. >>>>=20 >>>> I would hope that UUID values will not change to the extent that >>>> SBCs >> change >>>> them for business reasons. It would certainly defeat the point. >> Hadriel >>>> might be right that an SBC vendor might manipulate those values at >>>> the request of a customer, but I would hope said customer >>>> appreciates that >> such >>>> a request effectively breaks the end-to-end model. We can't do >>>> much >> about >>>> that if they do go down that path. >>>>=20 >>>> As for backward-compatibility, the simplest approach (IMO) is to >>>> just >> use a >>>> header value not already in use. Originally, we had proposed >>>> Session- >> UUID. >>>> That was changed at the request of the group to be Session-ID. >> However, >>>> when we have a two UUID solution interacting with a one-UUID >>>> solution, >> we >>>> immediately face some challenges. >>>>=20 >>>> What happens if an older system sends this: >>>> Session-ID: X >>>> But then receives this: >>>> Session-ID: Y; remote=3DX >>>>=20 >>>> Does this break things? If so, how do current implementations >>>> deal >> with >>>> such things as mid-call transfers that happen on a PBX like the >>>> one I described above? >>>>=20 >>>> We could switch the order like this: >>>> Session-ID: X; remote=3DY >>>>=20 >>>> However, that does not work for similar reasons. If we have a >>>> call >> transfer >>>> where Alice transfers a call with Bob to Carol, then each has a >> different >>>> idea about what the proper value is for the first position. >>>>=20 >>>> Originally, the proposed solution did not indicate position >> information and >>>> just had single UUID values going in each direction. We then >>>> proposed >> a >>>> concatenated string (X:Y). However, that presented the same issues >>>> for >> the >>>> call transfer case, so we indicate values by position (sender's >>>> value first), so it is clear what value the receive thinks the >>>> remote end >> has for >>>> the local end. It might be wrong, but that will be corrected in >>>> the following response. (Intermediaries can take note of the >>>> change.) >>>>=20 >>>> So, that's why we are where we are. There has been an effort to >> maintain >>>> backward-compatibility, but there are challenges in meeting that >>>> requirement. Where it falls short, we do not know: we've not been >> told >>>> explicitly what the issues are. Further, if there are such >>>> issues, we >> need >>>> to also understand how those would be handled in the face of call >> transfer >>>> or "joining" a call locally on a PBX. Those are real-world >>>> scenarios >> that >>>> we must address. >>>>=20 >>>> Anyway, nothing is set in stone. Anything can be changed, but I >>>> would >> hope >>>> we can find a solution that works for the enterprise use cases as >>>> well >> as >>>> the service provider networks. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>>=20 >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From imcilwaine@opencloud.com Wed Aug 14 07:54:40 2013 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 248CA21F9BF2 for ; Wed, 14 Aug 2013 07:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.032 X-Spam-Level: X-Spam-Status: No, score=-4.032 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10zU8zO5NPCx for ; Wed, 14 Aug 2013 07:54:13 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with SMTP id 901F511E81ED for ; Wed, 14 Aug 2013 07:54:10 -0700 (PDT) Received: from mail-vb0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKUguaEblQa/Glu76pSzcP7yio+Gwa18fZ@postini.com; Wed, 14 Aug 2013 07:54:10 PDT Received: by mail-vb0-f47.google.com with SMTP id h10so7554418vbh.6 for ; Wed, 14 Aug 2013 07:54:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:reply-to:from:references:in-reply-to :mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=EaNYXXkkrb7Yx2aSMyvx0jAzD8IpzlmikdPWj5jjXV4=; b=C/KBTUvCNv35nmQtYkFW91WpQ7D4xKnKwNMBLxHFrmSVEnqaXpy9QBJPRjj8omjX/u xfBRv9qdCZ0rlBEm8+o9PTLeP2CeD9iQjhGZ/R3pXdHEKwI7XPRIM+numA797wIKk5M9 dCjXb6Lv3j8bUg2eq5MumNbtQpXCP4pwpI8U8RiYRRTBgrvMOxIY6QZomfuXXB8Dzi4j QZzHG/0dxhpCKF/IW4a2267YuOrtAN4BJKLu8TEbYDE6qIvferFU44lZLmRKbDIiU1df CWzOWmYjBPLgMeeymSvi4BrBxwDG+w+IxNR32zWAwpGCkHh/ZH2rqzH2Z7qHIPwCZyl1 m1Tg== X-Gm-Message-State: ALoCoQk4kYD7O99rT9SW7Y07vSNExhdSttGgxWeo19VgqjSs3RTCC+RRAtuwsgLkxAUs+PfCkzXWTKz/tmQWA+GsH+poLCMyktkyc65V/G6tJZIxtt3Uz7sk7enADkk9MGpMuTT1XblyMkgsAA47taVjkGuOL4At6g== X-Received: by 10.58.136.4 with SMTP id pw4mr9040084veb.10.1376492049836; Wed, 14 Aug 2013 07:54:09 -0700 (PDT) X-Received: by 10.58.136.4 with SMTP id pw4mr9040070veb.10.1376492049630; Wed, 14 Aug 2013 07:54:09 -0700 (PDT) From: Iain McIlwaine References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKQJk1zw7AyhdJqEBmNnempcLpl0g Date: Wed, 14 Aug 2013 15:54:07 +0100 Message-ID: <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iain.mcilwaine@opencloud.com List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 14:54:41 -0000 The scenario in question is for an IMS access network transfer during call setup as described by 3GPP 24.237. After receiving the INVITE and replying with a 18x (and thus establishing an early dialog) Bob's access network changes. In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP signalling on Bob's behalf and thus have no access to what the previous Session-ID was. The MSC-S/MGCF initiates a call for Bob which is reconciled at the Transfer AS using 3PCC & Access Transfer mechanisms. In this scenario and using the proposed syntax, both Alice and Bob (well, Bob's MSC-S/MGCF) have an equal right to assert their UUID first as they've both created the INVITE. How this is handled in the Transfer AS (i.e. the ATCF or the SCC) doesn't bother me so much as they're just 3PCC/B2BUAs, what it does do however is invalidate the Session-ID as a meaningful end 2 end tag for any service provider offering access transfer. Again, could be I'm misinterpreting something so happy to be corrected. Cheers, Iain -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: 14 August 2013 15:22 To: iain.mcilwaine@opencloud.com Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility I think it depends on how the "Transfer AS" is going to work, and what you think "manipulation" means or why it matters. How is it any different than a PBX call transfer scenario? Is the problem you're describing a real transfer where Bob just didn't send a 200 yet, or do you really mean a call-forwarding scenario, with early media? If you just mean the equivalent of call-forwarding type thing, where the forwarding app server sends a 18x to generate "please wait while we locate your party" media, then that's still ok (I think). Nothing ever said the header parameter value couldn't change between responses. So it would be like this: Alice INVITE through AS to Bob = "Session-ID:foo" Bob 18x through AS to Alice = "Session-ID:foo;remote=bar" Bob INVITE through AS to Carol = "Session-ID:foo" Carol 18x/2xx through AS to Bob = "Session-ID:foo;remote=qux" Bob 2xx through AS to Alice = "Session-ID:foo;remote=qux" If you mean a real call transfer, it's going to be uglier: Alice INVITE through PBX to Bob = "Session-ID:foo" Bob 18x through PBX to Alice = "Session-ID:foo;remote=bar" Bob INVITE through PBX to Carol = "Session-ID:zab" Carol 18x/2xx through PBX to Bob = "Session-ID:zab;remote=qux" [ Bob presses some transfer button thingy, PBX transfers the Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx to Alice of = "Session-ID:foo;remote=qux" Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and send re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo". I personally think sending re-INVITE/UPDATEs for this thing is going to cause headaches, but if that's what people want, they can do it. Clearly the PBX has to keep track of these Session-IDs separately on each call leg for some of these scenarios, but that's hardly a big deal - it's *already* keeping track of these as separate call-legs with a bunch of SIP state, because by definition it's acting as a SIP B2BUA with two separate SIP dialogs. -hadriel On Aug 14, 2013, at 5:20 AM, Iain McIlwaine wrote: > Folks, > > I see a lot of discussion for enterprise transfer scenarios but I > would like to highlight a problematic use case to gauge your opinions. > > Using Hadriel's method which designates local:remote of the UUID > according to the issuer of the INVITE I can see a potential problem > for Access Transfer when the party being transferred is in the "proceeding" state. > So: > > Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" > Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=bar" > Bob' INVITE - "Transfer AS" Session-ID:foo' > > Note: the "Transfer AS" can be an ATCF or an SCC. > > We can see in this case using Hadriel's syntax we now require the > Transfer AS to perform manipulation of the Session-ID header which > runs contrary to a stated objective of no intermediary meddling of the header. > > If we revert to interpreting the local:remote syntax being within the > context of the receiver I believe we would avert this situation. > > Of course it could be I've misunderstood something so happy to be > shown the light. > > Kind regards, > Iain > > > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: 13 August 2013 23:34 > To: 'Hadriel Kaplan' > Cc: insipid@ietf.org; 'Laura Liess' > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > Hadriel, > >> I can't tell if you seriously believe the new mechanism is going to >> work end-to-end across all domains, or if you just mean end-to-end >> within a domain (like within the call-center). I don't mean that in >> a negative way >> - I just mean I don't understand how you mean the words "end-to-end". > > I seriously mean end-to-end. Assuming service providers did not block > passage of an INVITE containing a new UUID value, then we can always > have an end-to-end value. As an "end" changes, so does the end-to-end value. > That's OK. > >> I seriously doubt this thing is going to achieve any more than the >> legacy draft did in terms of true end-to-end across-the-world type >> thing. In fact it may even do less. > > The only reason it would not is if: > 1) One endpoint does not support the procedures (can't help that) > 2) Something prevents a new INVITE from going to one endpoint (like an > SBC) > > Otherwise, it would work. > >> When I make a call from my cell phone through my mobile provider, >> through N number of carriers, to an Enterprise call-center somewhere >> in Timbuktu, I have a hard time believing all the carriers and mobile >> providers want to get back and process a re-INVITE each and every >> time the call gets moved around inside the call-center's internal PBX >> infrastructure. They rarely get that today, and I don't see them > changing in the future to do so... >> for what benefit? What use is it to update all the SIP systems along >> the path, as well as my cell phone, with a new Session-ID value just >> because the call got parked/unparked or internally transferred inside > PBX/ACD/etc. >> systems in a call-center somewhere? >> >> Some call centers move the media around almost a dozen times per call. >> You really think the rest of the world wants to get a dozen >> re-INVITEs, for no benefit? The SBCs aren't answering the re-INVITEs >> locally today to hide the identity of who/what it gets moved around >> to >> - that we already do even when we forward the re-INVITEs - we're >> answering them locally because the service providers don't want nor >> need those re-INVITEs. It's just extra processing load, log entries, >> and things that can go wrong; with no added benefit. > > I really cannot do anything about these "noise" issues. I recognize > that in practice, much of the use of SIP has been absolutely nothing > more than a PSTN replacement. It has been merely a means of moving from TDM to IP. > I'm glad it happened, but it's more than unfortunate if that's all we > accomplish. > > As I look to doing more interesting things where I have different > applications running in various devices connected to different > networks and associated to my "phone" where I can utilize all of them > as a part of a "call", I see value in having this end-to-end > identifier for even this more complex arrangement. However, I can > understand if service providers do not take an active interest in > this. From a research perspective, these more advanced communication > systems are interesting. From a business perspective, there is a > question about ROI for carriers. I get > that: > there's no money in doing much more than providing the most basic > voice service, and even that service has a very small profit margin. > However, progress, capabilities, functionality, and improvements in > the way we work and communicate should go forward, and they are. > Already, we see a number of alternatives like Skype, Facetime, Google > Hangouts, etc. and I expect functionality will become much more > interesting, with a wider mix of multimedia applications in use at once. > > Bottom line is that we should not constrain a system, but try to make > it as flexible as possible. It might not work everywhere, but don't > constrain ourselves to the most basic voice call flow. > > Paul > >> -hadriel >> >> >> On Aug 2, 2013, at 11:48 AM, Paul E. Jones > wrote: >> >>> Larua, >>> >>> So in effect, the current deployments are not end-to-end, but >>> edge-to- >> edge somewhere. I can appreciate that, but it does make it more >> challenging to try to work with when we go all the way end-to-end. >>> >>> Paul >>> >>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >>> Sent: Friday, August 02, 2013 4:47 AM >>> To: Paul E. Jones >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>> >>> Paul, >>> >>> As I said, we never used the old Session-ID to do more than >>> correlate >> bothe legs of the same dialog. So in your example we have: >>> - Alice to Bob: Session-ID A >>> - Bob to Carol: Session-ID B >>> - Alice to Carol: Session-ID C >>> >>> There is no correlation between them. We just correlate both legs of >>> the >> same dialog across the SBC between Alice and Bob. >>> >>> Thank you >>> Laura >>> >>> >>> >>> 2013/8/1 Paul E. Jones Laura, >>> >>> The example I show below is a real call center example. I show use >>> of >> the old session ID. Tell me how that works. Forget about the new >> solution for the moment. >>> >>> If you say it will not work, then I'm not sure how we can make >>> something >> work with something that does not work. If there is a way to make >> this work, then we can try to figure out how to interwork with it. >>> >>> Paul >>> >>> >>> >>> From: Laura Liess >>> Sent: Thu Aug 01 11:51:26 EDT 2013 >>> >>> To: "Paul E. Jones" >>> Cc: insipid@ietf.org >>> >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>> >>> Paul, >>> We use the old Session-ID only accross SBCs, to correlate both legs >>> of >> the same dialog. And it works fine for this use case. We never tried, >> intend or were required to do more with it. >>> We are not against the new mechanism, we just want it to interwork >>> with >> the old one which we have in thousands of customer end devices. If it > does, >> we can add new end devices and application servers which support the >> new Session-ID. Otherwise we can't. >>> >>> Let's see if it works when we keep the UUID order unchanged, as >>> Hadriel >> proposed. >>> >>> Thank you >>> Laura >>> >>> >>> 2013/8/1 Paul E. Jones Laura, >>> >>> I assert that old draft will not work for some "real-world" calls. >> Calls do get manipulated in enterprise environments and call centers >> for billing purposes, privacy reasons, etc. >>> >>> Consider a common case: if you call into a call center and the agent >> puts you on hold while they transfer you to a specialist (transfer >> out of consultation), for example, your SIP UA does not receive a >> REFER to initiate a new call directly to the specialist. This is >> handled at the call center. >>> >>> So rather specifically, how would this be handled (with the old > draft)? >>> >>> 1) Alice calls Bob (Session-ID: A) >>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) >>> 3) Bob transfers the call from Alice to Carol using a local transfer >> function on the PBX (Session-ID: ??) >>> >>> The PBX could send different values to Alice and Carol, but we >>> totally >> lose the end-to-end identification of the call. >>> >>> Alice could not send "A" to Carol, since Carol is expecting B. > Likewise, >> Carol cannot send "B" to Alice, since Alice is expecting "A". Well, >> they could, and it would be no worse than our current proposal in >> terms of backward-compatibility. >>> >>> Paul >>> >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Laura Liess >>> Sent: Thursday, August 01, 2013 9:13 AM >>> To: insipid@ietf.org >>> >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>> >>> >>> Hadriel's proposal works for us. >>> >>> Thank you >>> Laura >>> >>> >>> 2013/8/1 Hadriel Kaplan >>> >>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. >>> another >> vendor. This is just about a Working Group document, and whether the >> mechanism defined in it should change the Session-ID header value vs. >> parameter based on direction of messages, or not. I totally get the >> need to have a distinguishing Session-ID identifier for party-A vs. > party-B. >> What I don't get is why they need to change the encoding of the >> Session-ID header value vs. parameter, on a message direction basis. >>> >>> In other words, today the draft has this: >>> 1) Alice sends INVITE with "Session-ID: foo" >>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" >>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" >>> 4) Bob sends BYE with "Session-ID: bar;remote=foo" >>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" >>> >>> But we could instead do this: >>> 1) Alice sends INVITE with "Session-ID: foo" >>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" >>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" >>> 4) Bob sends BYE with "Session-ID: foo;remote=bar" >>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" >>> >>> This second model keeps the Session-ID header value as "foo" the >>> whole >> time, while adding a parameter of "bar" for Bob that remains a >> parameter the whole time. >>> Neither Alice nor Bob are confused about which one is "their" UUID > value. >>> And it's backward-compatible with the previous kaplan-draft. >>> And it's arguably easier to implement, for the common cases. >>> >>> I *think* there was a reason someone came up with at one time as to >>> why >> it had to be swapped, but I don't remember what it is and I don't see >> it in the draft. So I'm trying to find out why we need to do it the >> way the draft currently has it. >>> >>> The other topic of whether SBCs will change things is completely >> orthogonal to the ordering or backwards compatibility issues, and >> really shouldn't be conflated with it at all. It has nothing to do >> with the solutions document, or the direction stuff, etc. >>> >>> -hadriel >>> >>> >>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones > wrote: >>> >>>> Folks, >>>> >>>> I step away for a couple of days and the floodgate opens. :) >>>> >>>> I think it's important to understand why we proposed using a >>>> two-part Session Identifier. The reason is that we have to be able >>>> to >> effectively >>>> deal with things like forking, call transfer, park, bridging, >> conferencing, >>>> etc. >>>> >>>> When initiating a call and using a single UUID value, that has the >> potential >>>> to go end-to-end. However, if a call is forked there are multiple >> "ends". >>>> How do we track each of those? For proper diagnostics and >> troubleshooting, >>>> it would be ideal to be able to identify which devices have an > issue. >>>> >>>> Once a call has been placed, there is a Session-ID established >>>> between >> Alice >>>> and Bob. If Alice (in one country) transfers Bob (perhaps in the >>>> same >> or >>>> different country) to a some location in a high-toll country, who >>>> pays >> the >>>> bill? Well, to address that, we do call transfer locally on PBXes. >> The PBX >>>> maintains control over the call and Alice would pay the bill for >>>> the >> call >>>> transfer. But if Alice was talking to Carol before the transfer, >> there is a >>>> Session-ID for that call. If Bob is put in communication with >>>> Carol, >> what >>>> is the Session-ID value? Bob had one and Carol had a different one. >> What >>>> is the new ID? >>>> >>>> It's issues like this that led us to using a two-part value. In >>>> this >> way, >>>> we could see the call from Alice to Bob has a Session-ID {A,B}. >>>> If >> Alice >>>> transfers the call to Carol, each device understands that the >>>> Session- >> ID >>>> changed to {B,C}. Not only that, but intermediaries along the path >> that >>>> were not privy to signaling that resulted in this change can take >>>> note >> of >>>> the fact the value changed. This can provide a useful historical >> record, >>>> since previously they might see a call to Carol identified as >>>> {A,C}, >> but >>>> then it changed to {B,C}. >>>> >>>> This property extends quite naturally to other signaling scenarios, >>>> as >> it >>>> allows one to identify a call end-to-end, but also establish some >>>> relationship between other calls that shared at least one UUID >>>> value >> out of >>>> the two. >>>> >>>> Hadriel mentioned the desire to use the Session-ID to correlate >>>> media >> flows >>>> and calls. That's certainly something Cisco would like to do, but >>>> it >> is not >>>> the driver behind the solution. Having a valid end-to-end >>>> identifier >> (in >>>> whatever form) allows us to do that. We're not suggesting to fit >>>> the solution to meet that business use case, but rather we just >>>> want a >> solution >>>> that allows us to properly identify calls end-to-end and we >>>> recognize >> that, >>>> due to various service interactions in the network, these UUID >>>> values >> can >>>> change. >>>> >>>> I would hope that UUID values will not change to the extent that >>>> SBCs >> change >>>> them for business reasons. It would certainly defeat the point. >> Hadriel >>>> might be right that an SBC vendor might manipulate those values at >>>> the request of a customer, but I would hope said customer >>>> appreciates that >> such >>>> a request effectively breaks the end-to-end model. We can't do >>>> much >> about >>>> that if they do go down that path. >>>> >>>> As for backward-compatibility, the simplest approach (IMO) is to >>>> just >> use a >>>> header value not already in use. Originally, we had proposed >>>> Session- >> UUID. >>>> That was changed at the request of the group to be Session-ID. >> However, >>>> when we have a two UUID solution interacting with a one-UUID >>>> solution, >> we >>>> immediately face some challenges. >>>> >>>> What happens if an older system sends this: >>>> Session-ID: X >>>> But then receives this: >>>> Session-ID: Y; remote=X >>>> >>>> Does this break things? If so, how do current implementations deal >> with >>>> such things as mid-call transfers that happen on a PBX like the one >>>> I described above? >>>> >>>> We could switch the order like this: >>>> Session-ID: X; remote=Y >>>> >>>> However, that does not work for similar reasons. If we have a call >> transfer >>>> where Alice transfers a call with Bob to Carol, then each has a >> different >>>> idea about what the proper value is for the first position. >>>> >>>> Originally, the proposed solution did not indicate position >> information and >>>> just had single UUID values going in each direction. We then >>>> proposed >> a >>>> concatenated string (X:Y). However, that presented the same issues >>>> for >> the >>>> call transfer case, so we indicate values by position (sender's >>>> value first), so it is clear what value the receive thinks the >>>> remote end >> has for >>>> the local end. It might be wrong, but that will be corrected in >>>> the following response. (Intermediaries can take note of the >>>> change.) >>>> >>>> So, that's why we are where we are. There has been an effort to >> maintain >>>> backward-compatibility, but there are challenges in meeting that >>>> requirement. Where it falls short, we do not know: we've not been >> told >>>> explicitly what the issues are. Further, if there are such issues, >>>> we >> need >>>> to also understand how those would be handled in the face of call >> transfer >>>> or "joining" a call locally on a PBX. Those are real-world >>>> scenarios >> that >>>> we must address. >>>> >>>> Anyway, nothing is set in stone. Anything can be changed, but I >>>> would >> hope >>>> we can find a solution that works for the enterprise use cases as >>>> well >> as >>>> the service provider networks. >>>> >>>> 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 > > > _______________________________________________ > 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 hadriel.kaplan@oracle.com Wed Aug 14 09:45:06 2013 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 180FF11E8181 for ; Wed, 14 Aug 2013 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe5Tk8nBBP3e for ; Wed, 14 Aug 2013 09:45:00 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 56B7221F9D69 for ; Wed, 14 Aug 2013 09:45:00 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7EGiwof012112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Aug 2013 16:44:59 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EGiv2s000781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Aug 2013 16:44:57 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7EGivZd010460; Wed, 14 Aug 2013 16:44:57 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 Aug 2013 09:44:56 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> Date: Wed, 14 Aug 2013 12:44:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> To: iain.mcilwaine@opencloud.com X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 16:45:06 -0000 Ahh right - it's been a while since I read that spec, and it's painfully = long and complicated. :) So in the case of the MSC performing a continuity transfer on behalf of = Bob, I essentially think of it as a INVITE with Replaces model, except = without the Replaces info. The ATCF is like a PBX, and the scenario is = almost like a PBX barge-in feature, from a 50k-foot view. And just like = a barge-in, if you really want all sides to get updated to have a = consistent Session-ID param value, it might require a re-INVITE/UPDATE = be sent everywhere. =20 With the legacy way of doing Session-ID but with also a remote param, it = could be like this: Alice INVITE through ATCF to Bob =3D "Session-ID:foo" Bob 18x through ATCF to Alice =3D "Session-ID:foo;remote=3Dbar" [ Bob loses PS and MSC triggers call continuity ] MSC INVITE to ATCF =3D "Session-ID:zab" ATCF 200 to MSC =3D "Session-ID:zab;remote=3Dfoo" ATCF 200 to Alice =3D "Session-ID:foo;remote=3Dzab" Or depending on state of call and also depending on logic of ATCF, ATCF = could instead send back something else and eventually sends = re-INVITE/UPDATE to both parties, to create a consistent parameter = value. I have a hard time believing an IMS provider would want to send SIP = re-INVITEs across their peering connections to the other carriers the = call came in from, just because their local UE switched from VoLTE to = 3GPP or whatever. Nor do I think the other carriers want to get such = re-INVITEs from them. With regards to "it invalidates the Session-ID as a meaningful e2e tag", = yes it does - the parameter might be consistent (eventually), but the = header value itself isn't. But the real question is what would the = Session-ID be *used for* - just having an e2e tag is not an end goal... = there has to be some purpose to it. With the original Session-ID draft, = the purpose was troubleshooting, and when we debated whether to send = re-INVITE/UPDATEs everywhere in order to handle the more complicated = scenarios, the consensus was that no one wanted to do that (for obvious = reasons). I think what some people have in mind is simply a value that is = consistent within their local domain. But that's a horse of a different = color, I think. -hadriel On Aug 14, 2013, at 10:54 AM, Iain McIlwaine = wrote: > The scenario in question is for an IMS access network transfer during = call > setup as described by 3GPP 24.237. After receiving the INVITE and > replying with a 18x (and thus establishing an early dialog) Bob's = access > network changes. >=20 > In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP > signalling on Bob's behalf and thus have no access to what the = previous > Session-ID was. The MSC-S/MGCF initiates a call for Bob which is > reconciled at the Transfer AS using 3PCC & Access Transfer mechanisms. >=20 > In this scenario and using the proposed syntax, both Alice and Bob = (well, > Bob's MSC-S/MGCF) have an equal right to assert their UUID first as > they've both created the INVITE. >=20 > How this is handled in the Transfer AS (i.e. the ATCF or the SCC) = doesn't > bother me so much as they're just 3PCC/B2BUAs, what it does do however = is > invalidate the Session-ID as a meaningful end 2 end tag for any = service > provider offering access transfer. >=20 > Again, could be I'm misinterpreting something so happy to be = corrected. >=20 > Cheers, > Iain >=20 >=20 >=20 >=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: 14 August 2013 15:22 > To: iain.mcilwaine@opencloud.com > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility >=20 >=20 > I think it depends on how the "Transfer AS" is going to work, and what = you > think "manipulation" means or why it matters. How is it any different > than a PBX call transfer scenario? Is the problem you're describing a > real transfer where Bob just didn't send a 200 yet, or do you really = mean > a call-forwarding scenario, with early media? >=20 > If you just mean the equivalent of call-forwarding type thing, where = the > forwarding app server sends a 18x to generate "please wait while we = locate > your party" media, then that's still ok (I think). Nothing ever said = the > header parameter value couldn't change between responses. So it would = be > like this: >=20 > Alice INVITE through AS to Bob =3D "Session-ID:foo" > Bob 18x through AS to Alice =3D "Session-ID:foo;remote=3Dbar" > Bob INVITE through AS to Carol =3D "Session-ID:foo" > Carol 18x/2xx through AS to Bob =3D "Session-ID:foo;remote=3Dqux" > Bob 2xx through AS to Alice =3D "Session-ID:foo;remote=3Dqux" >=20 >=20 > If you mean a real call transfer, it's going to be uglier: >=20 > Alice INVITE through PBX to Bob =3D "Session-ID:foo" > Bob 18x through PBX to Alice =3D "Session-ID:foo;remote=3Dbar" > Bob INVITE through PBX to Carol =3D "Session-ID:zab" > Carol 18x/2xx through PBX to Bob =3D "Session-ID:zab;remote=3Dqux" > [ Bob presses some transfer button thingy, PBX transfers the > Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx to > Alice of =3D "Session-ID:foo;remote=3Dqux" > Or PBX can send 2xx to Alice of "Session-ID:foo;remote=3Dzab", and = send > re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=3Dfoo". >=20 > I personally think sending re-INVITE/UPDATEs for this thing is going = to > cause headaches, but if that's what people want, they can do it. >=20 > Clearly the PBX has to keep track of these Session-IDs separately on = each > call leg for some of these scenarios, but that's hardly a big deal - = it's > *already* keeping track of these as separate call-legs with a bunch of = SIP > state, because by definition it's acting as a SIP B2BUA with two = separate > SIP dialogs. >=20 > -hadriel >=20 >=20 > On Aug 14, 2013, at 5:20 AM, Iain McIlwaine = > wrote: >=20 >> Folks, >>=20 >> I see a lot of discussion for enterprise transfer scenarios but I >> would like to highlight a problematic use case to gauge your = opinions. >>=20 >> Using Hadriel's method which designates local:remote of the UUID >> according to the issuer of the INVITE I can see a potential problem >> for Access Transfer when the party being transferred is in the > "proceeding" state. >> So: >>=20 >> Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" >> Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=3Dbar" >> Bob' INVITE - "Transfer AS" Session-ID:foo' >>=20 >> Note: the "Transfer AS" can be an ATCF or an SCC. >>=20 >> We can see in this case using Hadriel's syntax we now require the >> Transfer AS to perform manipulation of the Session-ID header which >> runs contrary to a stated objective of no intermediary meddling of = the > header. >>=20 >> If we revert to interpreting the local:remote syntax being within the >> context of the receiver I believe we would avert this situation. >>=20 >> Of course it could be I've misunderstood something so happy to be >> shown the light. >>=20 >> Kind regards, >> Iain >>=20 >>=20 >>=20 >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Paul E. Jones >> Sent: 13 August 2013 23:34 >> To: 'Hadriel Kaplan' >> Cc: insipid@ietf.org; 'Laura Liess' >> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>=20 >> Hadriel, >>=20 >>> I can't tell if you seriously believe the new mechanism is going to >>> work end-to-end across all domains, or if you just mean end-to-end >>> within a domain (like within the call-center). I don't mean that in >>> a negative way >>> - I just mean I don't understand how you mean the words = "end-to-end". >>=20 >> I seriously mean end-to-end. Assuming service providers did not = block >> passage of an INVITE containing a new UUID value, then we can always >> have an end-to-end value. As an "end" changes, so does the = end-to-end > value. >> That's OK. >>=20 >>> I seriously doubt this thing is going to achieve any more than the >>> legacy draft did in terms of true end-to-end across-the-world type >>> thing. In fact it may even do less. >>=20 >> The only reason it would not is if: >> 1) One endpoint does not support the procedures (can't help that) >> 2) Something prevents a new INVITE from going to one endpoint (like = an >> SBC) >>=20 >> Otherwise, it would work. >>=20 >>> When I make a call from my cell phone through my mobile provider, >>> through N number of carriers, to an Enterprise call-center somewhere >>> in Timbuktu, I have a hard time believing all the carriers and = mobile >>> providers want to get back and process a re-INVITE each and every >>> time the call gets moved around inside the call-center's internal = PBX >>> infrastructure. They rarely get that today, and I don't see them >> changing in the future to do so... >>> for what benefit? What use is it to update all the SIP systems = along >>> the path, as well as my cell phone, with a new Session-ID value just >>> because the call got parked/unparked or internally transferred = inside >> PBX/ACD/etc. >>> systems in a call-center somewhere? >>>=20 >>> Some call centers move the media around almost a dozen times per = call. >>> You really think the rest of the world wants to get a dozen >>> re-INVITEs, for no benefit? The SBCs aren't answering the = re-INVITEs >>> locally today to hide the identity of who/what it gets moved around >>> to >>> - that we already do even when we forward the re-INVITEs - we're >>> answering them locally because the service providers don't want nor >>> need those re-INVITEs. It's just extra processing load, log = entries, >>> and things that can go wrong; with no added benefit. >>=20 >> I really cannot do anything about these "noise" issues. I recognize >> that in practice, much of the use of SIP has been absolutely nothing >> more than a PSTN replacement. It has been merely a means of moving = from > TDM to IP. >> I'm glad it happened, but it's more than unfortunate if that's all we >> accomplish. >>=20 >> As I look to doing more interesting things where I have different >> applications running in various devices connected to different >> networks and associated to my "phone" where I can utilize all of them >> as a part of a "call", I see value in having this end-to-end >> identifier for even this more complex arrangement. However, I can >> understand if service providers do not take an active interest in >> this. =46rom a research perspective, these more advanced = communication >> systems are interesting. =46rom a business perspective, there is a >> question about ROI for carriers. I get >> that: >> there's no money in doing much more than providing the most basic >> voice service, and even that service has a very small profit margin. >> However, progress, capabilities, functionality, and improvements in >> the way we work and communicate should go forward, and they are. >> Already, we see a number of alternatives like Skype, Facetime, Google >> Hangouts, etc. and I expect functionality will become much more >> interesting, with a wider mix of multimedia applications in use at = once. >>=20 >> Bottom line is that we should not constrain a system, but try to make >> it as flexible as possible. It might not work everywhere, but don't >> constrain ourselves to the most basic voice call flow. >>=20 >> Paul >>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 2, 2013, at 11:48 AM, Paul E. Jones >> wrote: >>>=20 >>>> Larua, >>>>=20 >>>> So in effect, the current deployments are not end-to-end, but >>>> edge-to- >>> edge somewhere. I can appreciate that, but it does make it more >>> challenging to try to work with when we go all the way end-to-end. >>>>=20 >>>> Paul >>>>=20 >>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >>>> Sent: Friday, August 02, 2013 4:47 AM >>>> To: Paul E. Jones >>>> Cc: insipid@ietf.org >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>> compatibility >>>>=20 >>>> Paul, >>>>=20 >>>> As I said, we never used the old Session-ID to do more than >>>> correlate >>> bothe legs of the same dialog. So in your example we have: >>>> - Alice to Bob: Session-ID A >>>> - Bob to Carol: Session-ID B >>>> - Alice to Carol: Session-ID C >>>>=20 >>>> There is no correlation between them. We just correlate both legs = of >>>> the >>> same dialog across the SBC between Alice and Bob. >>>>=20 >>>> Thank you >>>> Laura >>>>=20 >>>>=20 >>>>=20 >>>> 2013/8/1 Paul E. Jones Laura, >>>>=20 >>>> The example I show below is a real call center example. I show use >>>> of >>> the old session ID. Tell me how that works. Forget about the new >>> solution for the moment. >>>>=20 >>>> If you say it will not work, then I'm not sure how we can make >>>> something >>> work with something that does not work. If there is a way to make >>> this work, then we can try to figure out how to interwork with it. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>>=20 >>>> From: Laura Liess >>>> Sent: Thu Aug 01 11:51:26 EDT 2013 >>>>=20 >>>> To: "Paul E. Jones" >>>> Cc: insipid@ietf.org >>>>=20 >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>> compatibility >>>>=20 >>>> Paul, >>>> We use the old Session-ID only accross SBCs, to correlate both legs >>>> of >>> the same dialog. And it works fine for this use case. We never = tried, >>> intend or were required to do more with it. >>>> We are not against the new mechanism, we just want it to interwork >>>> with >>> the old one which we have in thousands of customer end devices. If = it >> does, >>> we can add new end devices and application servers which support the >>> new Session-ID. Otherwise we can't. >>>>=20 >>>> Let's see if it works when we keep the UUID order unchanged, as >>>> Hadriel >>> proposed. >>>>=20 >>>> Thank you >>>> Laura >>>>=20 >>>>=20 >>>> 2013/8/1 Paul E. Jones Laura, >>>>=20 >>>> I assert that old draft will not work for some "real-world" calls. >>> Calls do get manipulated in enterprise environments and call centers >>> for billing purposes, privacy reasons, etc. >>>>=20 >>>> Consider a common case: if you call into a call center and the = agent >>> puts you on hold while they transfer you to a specialist (transfer >>> out of consultation), for example, your SIP UA does not receive a >>> REFER to initiate a new call directly to the specialist. This is >>> handled at the call center. >>>>=20 >>>> So rather specifically, how would this be handled (with the old >> draft)? >>>>=20 >>>> 1) Alice calls Bob (Session-ID: A) >>>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) >>>> 3) Bob transfers the call from Alice to Carol using a local = transfer >>> function on the PBX (Session-ID: ??) >>>>=20 >>>> The PBX could send different values to Alice and Carol, but we >>>> totally >>> lose the end-to-end identification of the call. >>>>=20 >>>> Alice could not send "A" to Carol, since Carol is expecting B. >> Likewise, >>> Carol cannot send "B" to Alice, since Alice is expecting "A". Well, >>> they could, and it would be no worse than our current proposal in >>> terms of backward-compatibility. >>>>=20 >>>> Paul >>>>=20 >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>> Behalf Of Laura Liess >>>> Sent: Thursday, August 01, 2013 9:13 AM >>>> To: insipid@ietf.org >>>>=20 >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>> compatibility >>>>=20 >>>>=20 >>>> Hadriel's proposal works for us. >>>>=20 >>>> Thank you >>>> Laura >>>>=20 >>>>=20 >>>> 2013/8/1 Hadriel Kaplan >>>>=20 >>>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. >>>> another >>> vendor. This is just about a Working Group document, and whether = the >>> mechanism defined in it should change the Session-ID header value = vs. >>> parameter based on direction of messages, or not. I totally get the >>> need to have a distinguishing Session-ID identifier for party-A vs. >> party-B. >>> What I don't get is why they need to change the encoding of the >>> Session-ID header value vs. parameter, on a message direction basis. >>>>=20 >>>> In other words, today the draft has this: >>>> 1) Alice sends INVITE with "Session-ID: foo" >>>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" >>>> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >>>> 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" >>>> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >>>>=20 >>>> But we could instead do this: >>>> 1) Alice sends INVITE with "Session-ID: foo" >>>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" >>>> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >>>> 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" >>>> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >>>>=20 >>>> This second model keeps the Session-ID header value as "foo" the >>>> whole >>> time, while adding a parameter of "bar" for Bob that remains a >>> parameter the whole time. >>>> Neither Alice nor Bob are confused about which one is "their" UUID >> value. >>>> And it's backward-compatible with the previous kaplan-draft. >>>> And it's arguably easier to implement, for the common cases. >>>>=20 >>>> I *think* there was a reason someone came up with at one time as to >>>> why >>> it had to be swapped, but I don't remember what it is and I don't = see >>> it in the draft. So I'm trying to find out why we need to do it the >>> way the draft currently has it. >>>>=20 >>>> The other topic of whether SBCs will change things is completely >>> orthogonal to the ordering or backwards compatibility issues, and >>> really shouldn't be conflated with it at all. It has nothing to do >>> with the solutions document, or the direction stuff, etc. >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones >> wrote: >>>>=20 >>>>> Folks, >>>>>=20 >>>>> I step away for a couple of days and the floodgate opens. :) >>>>>=20 >>>>> I think it's important to understand why we proposed using a >>>>> two-part Session Identifier. The reason is that we have to be = able >>>>> to >>> effectively >>>>> deal with things like forking, call transfer, park, bridging, >>> conferencing, >>>>> etc. >>>>>=20 >>>>> When initiating a call and using a single UUID value, that has the >>> potential >>>>> to go end-to-end. However, if a call is forked there are multiple >>> "ends". >>>>> How do we track each of those? For proper diagnostics and >>> troubleshooting, >>>>> it would be ideal to be able to identify which devices have an >> issue. >>>>>=20 >>>>> Once a call has been placed, there is a Session-ID established >>>>> between >>> Alice >>>>> and Bob. If Alice (in one country) transfers Bob (perhaps in the >>>>> same >>> or >>>>> different country) to a some location in a high-toll country, who >>>>> pays >>> the >>>>> bill? Well, to address that, we do call transfer locally on = PBXes. >>> The PBX >>>>> maintains control over the call and Alice would pay the bill for >>>>> the >>> call >>>>> transfer. But if Alice was talking to Carol before the transfer, >>> there is a >>>>> Session-ID for that call. If Bob is put in communication with >>>>> Carol, >>> what >>>>> is the Session-ID value? Bob had one and Carol had a different = one. >>> What >>>>> is the new ID? >>>>>=20 >>>>> It's issues like this that led us to using a two-part value. In >>>>> this >>> way, >>>>> we could see the call from Alice to Bob has a Session-ID {A,B}. >>>>> If >>> Alice >>>>> transfers the call to Carol, each device understands that the >>>>> Session- >>> ID >>>>> changed to {B,C}. Not only that, but intermediaries along the = path >>> that >>>>> were not privy to signaling that resulted in this change can take >>>>> note >>> of >>>>> the fact the value changed. This can provide a useful historical >>> record, >>>>> since previously they might see a call to Carol identified as >>>>> {A,C}, >>> but >>>>> then it changed to {B,C}. >>>>>=20 >>>>> This property extends quite naturally to other signaling = scenarios, >>>>> as >>> it >>>>> allows one to identify a call end-to-end, but also establish some >>>>> relationship between other calls that shared at least one UUID >>>>> value >>> out of >>>>> the two. >>>>>=20 >>>>> Hadriel mentioned the desire to use the Session-ID to correlate >>>>> media >>> flows >>>>> and calls. That's certainly something Cisco would like to do, but >>>>> it >>> is not >>>>> the driver behind the solution. Having a valid end-to-end >>>>> identifier >>> (in >>>>> whatever form) allows us to do that. We're not suggesting to fit >>>>> the solution to meet that business use case, but rather we just >>>>> want a >>> solution >>>>> that allows us to properly identify calls end-to-end and we >>>>> recognize >>> that, >>>>> due to various service interactions in the network, these UUID >>>>> values >>> can >>>>> change. >>>>>=20 >>>>> I would hope that UUID values will not change to the extent that >>>>> SBCs >>> change >>>>> them for business reasons. It would certainly defeat the point. >>> Hadriel >>>>> might be right that an SBC vendor might manipulate those values at >>>>> the request of a customer, but I would hope said customer >>>>> appreciates that >>> such >>>>> a request effectively breaks the end-to-end model. We can't do >>>>> much >>> about >>>>> that if they do go down that path. >>>>>=20 >>>>> As for backward-compatibility, the simplest approach (IMO) is to >>>>> just >>> use a >>>>> header value not already in use. Originally, we had proposed >>>>> Session- >>> UUID. >>>>> That was changed at the request of the group to be Session-ID. >>> However, >>>>> when we have a two UUID solution interacting with a one-UUID >>>>> solution, >>> we >>>>> immediately face some challenges. >>>>>=20 >>>>> What happens if an older system sends this: >>>>> Session-ID: X >>>>> But then receives this: >>>>> Session-ID: Y; remote=3DX >>>>>=20 >>>>> Does this break things? If so, how do current implementations = deal >>> with >>>>> such things as mid-call transfers that happen on a PBX like the = one >>>>> I described above? >>>>>=20 >>>>> We could switch the order like this: >>>>> Session-ID: X; remote=3DY >>>>>=20 >>>>> However, that does not work for similar reasons. If we have a = call >>> transfer >>>>> where Alice transfers a call with Bob to Carol, then each has a >>> different >>>>> idea about what the proper value is for the first position. >>>>>=20 >>>>> Originally, the proposed solution did not indicate position >>> information and >>>>> just had single UUID values going in each direction. We then >>>>> proposed >>> a >>>>> concatenated string (X:Y). However, that presented the same issues >>>>> for >>> the >>>>> call transfer case, so we indicate values by position (sender's >>>>> value first), so it is clear what value the receive thinks the >>>>> remote end >>> has for >>>>> the local end. It might be wrong, but that will be corrected in >>>>> the following response. (Intermediaries can take note of the >>>>> change.) >>>>>=20 >>>>> So, that's why we are where we are. There has been an effort to >>> maintain >>>>> backward-compatibility, but there are challenges in meeting that >>>>> requirement. Where it falls short, we do not know: we've not been >>> told >>>>> explicitly what the issues are. Further, if there are such = issues, >>>>> we >>> need >>>>> to also understand how those would be handled in the face of call >>> transfer >>>>> or "joining" a call locally on a PBX. Those are real-world >>>>> scenarios >>> that >>>>> we must address. >>>>>=20 >>>>> Anyway, nothing is set in stone. Anything can be changed, but I >>>>> would >>> hope >>>>> we can find a solution that works for the enterprise use cases as >>>>> well >>> as >>>>> the service provider networks. >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>=20 >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> _______________________________________________ >> 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 partha@parthasarathi.co.in Wed Aug 14 15:45:21 2013 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 68D2021F9FA4 for ; Wed, 14 Aug 2013 15:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU2xATInfz8A for ; Wed, 14 Aug 2013 15:45:17 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.154]) by ietfa.amsl.com (Postfix) with ESMTP id EE50A21F8F97 for ; Wed, 14 Aug 2013 15:45:16 -0700 (PDT) Received: from userPC (unknown [122.179.33.33]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 47BEF8685AC; Wed, 14 Aug 2013 22:45:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1376520307; bh=Slrc0feqtw87+jfGlP90vsZ35G3SJjhbNa/k8dJUxvA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hRxUZy3JdEtI7LA0hBXUhVnvirDNk1ORyIg47JtH5/CJR71B7H6xHNtr8ato3oA/w bJPjfSpS+GUtXDZFtpF6Nzm/TyVI973xUccLNevNIMBBC2DFN8Z+CtnoFFJKL6SJ3J psCrryBBENV7edkCRZGd+7rMeycFNcQGI/ENH/8g= From: "Parthasarathi R" To: "'Hadriel Kaplan'" , References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> In-Reply-To: <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> Date: Thu, 15 Aug 2013 04:14:53 +0530 Message-ID: <001601ce993f$e8ae00b0$ba0a0210$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6ZDaMUwuc/zTTiQU2w4C7iHwWlbwALERIQ Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0209.520C0872.00B3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.155 Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 22:45:21 -0000 Hadriel/Iain, I agree with Iain that end-to-end session-id is not possible with eSRVCC (3GPP 24.237) in IMS environment. My understanding is that ATCF is introduced just to avoid the end-to-end signaling callflow. The callflow is as follows: 1) Session is established between Alice & Bob with session id=foo;remote=bar 2) Alice moved from PS to CS. 3) MSC starts new INVITE with session-id=zab 4) ATCF has to send 200 OK to MSC with session-id=zab;remote=bar 5) ATCF shall Re-INVITE with session-id=zab;remote=bar towards SCC-AS 6) SCC-AS sends 200 OK with session-id=zab;remote=bar Please note that bob is not aware of session-id update of "foo" to "zab". There is no end-to-end session-id in these callflows. Thanks Partha > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Wednesday, August 14, 2013 10:15 PM > To: iain.mcilwaine@opencloud.com > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > Ahh right - it's been a while since I read that spec, and it's > painfully long and complicated. :) > > So in the case of the MSC performing a continuity transfer on behalf of > Bob, I essentially think of it as a INVITE with Replaces model, except > without the Replaces info. The ATCF is like a PBX, and the scenario is > almost like a PBX barge-in feature, from a 50k-foot view. And just > like a barge-in, if you really want all sides to get updated to have a > consistent Session-ID param value, it might require a re-INVITE/UPDATE > be sent everywhere. > > With the legacy way of doing Session-ID but with also a remote param, > it could be like this: > > Alice INVITE through ATCF to Bob = "Session-ID:foo" > Bob 18x through ATCF to Alice = "Session-ID:foo;remote=bar" > > [ Bob loses PS and MSC triggers call continuity ] > > MSC INVITE to ATCF = "Session-ID:zab" > ATCF 200 to MSC = "Session-ID:zab;remote=foo" > ATCF 200 to Alice = "Session-ID:foo;remote=zab" > > Or depending on state of call and also depending on logic of ATCF, ATCF > could instead send back something else and eventually sends re- > INVITE/UPDATE to both parties, to create a consistent parameter value. > > I have a hard time believing an IMS provider would want to send SIP re- > INVITEs across their peering connections to the other carriers the call > came in from, just because their local UE switched from VoLTE to 3GPP > or whatever. Nor do I think the other carriers want to get such re- > INVITEs from them. > > With regards to "it invalidates the Session-ID as a meaningful e2e > tag", yes it does - the parameter might be consistent (eventually), but > the header value itself isn't. But the real question is what would the > Session-ID be *used for* - just having an e2e tag is not an end goal... > there has to be some purpose to it. With the original Session-ID > draft, the purpose was troubleshooting, and when we debated whether to > send re-INVITE/UPDATEs everywhere in order to handle the more > complicated scenarios, the consensus was that no one wanted to do that > (for obvious reasons). > > I think what some people have in mind is simply a value that is > consistent within their local domain. But that's a horse of a > different color, I think. > > -hadriel > > > On Aug 14, 2013, at 10:54 AM, Iain McIlwaine > wrote: > > > The scenario in question is for an IMS access network transfer during > call > > setup as described by 3GPP 24.237. After receiving the INVITE and > > replying with a 18x (and thus establishing an early dialog) Bob's > access > > network changes. > > > > In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP > > signalling on Bob's behalf and thus have no access to what the > previous > > Session-ID was. The MSC-S/MGCF initiates a call for Bob which is > > reconciled at the Transfer AS using 3PCC & Access Transfer > mechanisms. > > > > In this scenario and using the proposed syntax, both Alice and Bob > (well, > > Bob's MSC-S/MGCF) have an equal right to assert their UUID first as > > they've both created the INVITE. > > > > How this is handled in the Transfer AS (i.e. the ATCF or the SCC) > doesn't > > bother me so much as they're just 3PCC/B2BUAs, what it does do > however is > > invalidate the Session-ID as a meaningful end 2 end tag for any > service > > provider offering access transfer. > > > > Again, could be I'm misinterpreting something so happy to be > corrected. > > > > Cheers, > > Iain > > > > > > > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > > Sent: 14 August 2013 15:22 > > To: iain.mcilwaine@opencloud.com > > Cc: insipid@ietf.org > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > I think it depends on how the "Transfer AS" is going to work, and > what you > > think "manipulation" means or why it matters. How is it any > different > > than a PBX call transfer scenario? Is the problem you're describing > a > > real transfer where Bob just didn't send a 200 yet, or do you really > mean > > a call-forwarding scenario, with early media? > > > > If you just mean the equivalent of call-forwarding type thing, where > the > > forwarding app server sends a 18x to generate "please wait while we > locate > > your party" media, then that's still ok (I think). Nothing ever said > the > > header parameter value couldn't change between responses. So it > would be > > like this: > > > > Alice INVITE through AS to Bob = "Session-ID:foo" > > Bob 18x through AS to Alice = "Session-ID:foo;remote=bar" > > Bob INVITE through AS to Carol = "Session-ID:foo" > > Carol 18x/2xx through AS to Bob = "Session-ID:foo;remote=qux" > > Bob 2xx through AS to Alice = "Session-ID:foo;remote=qux" > > > > > > If you mean a real call transfer, it's going to be uglier: > > > > Alice INVITE through PBX to Bob = "Session-ID:foo" > > Bob 18x through PBX to Alice = "Session-ID:foo;remote=bar" > > Bob INVITE through PBX to Carol = "Session-ID:zab" > > Carol 18x/2xx through PBX to Bob = "Session-ID:zab;remote=qux" > > [ Bob presses some transfer button thingy, PBX transfers the > > Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx to > > Alice of = "Session-ID:foo;remote=qux" > > Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and send > > re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo". > > > > I personally think sending re-INVITE/UPDATEs for this thing is going > to > > cause headaches, but if that's what people want, they can do it. > > > > Clearly the PBX has to keep track of these Session-IDs separately on > each > > call leg for some of these scenarios, but that's hardly a big deal - > it's > > *already* keeping track of these as separate call-legs with a bunch > of SIP > > state, because by definition it's acting as a SIP B2BUA with two > separate > > SIP dialogs. > > > > -hadriel > > > > > > On Aug 14, 2013, at 5:20 AM, Iain McIlwaine > > > wrote: > > > >> Folks, > >> > >> I see a lot of discussion for enterprise transfer scenarios but I > >> would like to highlight a problematic use case to gauge your > opinions. > >> > >> Using Hadriel's method which designates local:remote of the UUID > >> according to the issuer of the INVITE I can see a potential problem > >> for Access Transfer when the party being transferred is in the > > "proceeding" state. > >> So: > >> > >> Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" > >> Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=bar" > >> Bob' INVITE - "Transfer AS" Session-ID:foo' > >> > >> Note: the "Transfer AS" can be an ATCF or an SCC. > >> > >> We can see in this case using Hadriel's syntax we now require the > >> Transfer AS to perform manipulation of the Session-ID header which > >> runs contrary to a stated objective of no intermediary meddling of > the > > header. > >> > >> If we revert to interpreting the local:remote syntax being within > the > >> context of the receiver I believe we would avert this situation. > >> > >> Of course it could be I've misunderstood something so happy to be > >> shown the light. > >> > >> Kind regards, > >> Iain > >> > >> > >> > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >> Behalf Of Paul E. Jones > >> Sent: 13 August 2013 23:34 > >> To: 'Hadriel Kaplan' > >> Cc: insipid@ietf.org; 'Laura Liess' > >> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >> compatibility > >> > >> Hadriel, > >> > >>> I can't tell if you seriously believe the new mechanism is going to > >>> work end-to-end across all domains, or if you just mean end-to-end > >>> within a domain (like within the call-center). I don't mean that > in > >>> a negative way > >>> - I just mean I don't understand how you mean the words "end-to- > end". > >> > >> I seriously mean end-to-end. Assuming service providers did not > block > >> passage of an INVITE containing a new UUID value, then we can always > >> have an end-to-end value. As an "end" changes, so does the end-to- > end > > value. > >> That's OK. > >> > >>> I seriously doubt this thing is going to achieve any more than the > >>> legacy draft did in terms of true end-to-end across-the-world type > >>> thing. In fact it may even do less. > >> > >> The only reason it would not is if: > >> 1) One endpoint does not support the procedures (can't help that) > >> 2) Something prevents a new INVITE from going to one endpoint (like > an > >> SBC) > >> > >> Otherwise, it would work. > >> > >>> When I make a call from my cell phone through my mobile provider, > >>> through N number of carriers, to an Enterprise call-center > somewhere > >>> in Timbuktu, I have a hard time believing all the carriers and > mobile > >>> providers want to get back and process a re-INVITE each and every > >>> time the call gets moved around inside the call-center's internal > PBX > >>> infrastructure. They rarely get that today, and I don't see them > >> changing in the future to do so... > >>> for what benefit? What use is it to update all the SIP systems > along > >>> the path, as well as my cell phone, with a new Session-ID value > just > >>> because the call got parked/unparked or internally transferred > inside > >> PBX/ACD/etc. > >>> systems in a call-center somewhere? > >>> > >>> Some call centers move the media around almost a dozen times per > call. > >>> You really think the rest of the world wants to get a dozen > >>> re-INVITEs, for no benefit? The SBCs aren't answering the re- > INVITEs > >>> locally today to hide the identity of who/what it gets moved around > >>> to > >>> - that we already do even when we forward the re-INVITEs - we're > >>> answering them locally because the service providers don't want nor > >>> need those re-INVITEs. It's just extra processing load, log > entries, > >>> and things that can go wrong; with no added benefit. > >> > >> I really cannot do anything about these "noise" issues. I recognize > >> that in practice, much of the use of SIP has been absolutely > nothing > >> more than a PSTN replacement. It has been merely a means of moving > from > > TDM to IP. > >> I'm glad it happened, but it's more than unfortunate if that's all > we > >> accomplish. > >> > >> As I look to doing more interesting things where I have different > >> applications running in various devices connected to different > >> networks and associated to my "phone" where I can utilize all of > them > >> as a part of a "call", I see value in having this end-to-end > >> identifier for even this more complex arrangement. However, I can > >> understand if service providers do not take an active interest in > >> this. From a research perspective, these more advanced > communication > >> systems are interesting. From a business perspective, there is a > >> question about ROI for carriers. I get > >> that: > >> there's no money in doing much more than providing the most basic > >> voice service, and even that service has a very small profit margin. > >> However, progress, capabilities, functionality, and improvements in > >> the way we work and communicate should go forward, and they are. > >> Already, we see a number of alternatives like Skype, Facetime, > Google > >> Hangouts, etc. and I expect functionality will become much more > >> interesting, with a wider mix of multimedia applications in use at > once. > >> > >> Bottom line is that we should not constrain a system, but try to > make > >> it as flexible as possible. It might not work everywhere, but don't > >> constrain ourselves to the most basic voice call flow. > >> > >> Paul > >> > >>> -hadriel > >>> > >>> > >>> On Aug 2, 2013, at 11:48 AM, Paul E. Jones > >> wrote: > >>> > >>>> Larua, > >>>> > >>>> So in effect, the current deployments are not end-to-end, but > >>>> edge-to- > >>> edge somewhere. I can appreciate that, but it does make it more > >>> challenging to try to work with when we go all the way end-to-end. > >>>> > >>>> Paul > >>>> > >>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > >>>> Sent: Friday, August 02, 2013 4:47 AM > >>>> To: Paul E. Jones > >>>> Cc: insipid@ietf.org > >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >>> compatibility > >>>> > >>>> Paul, > >>>> > >>>> As I said, we never used the old Session-ID to do more than > >>>> correlate > >>> bothe legs of the same dialog. So in your example we have: > >>>> - Alice to Bob: Session-ID A > >>>> - Bob to Carol: Session-ID B > >>>> - Alice to Carol: Session-ID C > >>>> > >>>> There is no correlation between them. We just correlate both legs > of > >>>> the > >>> same dialog across the SBC between Alice and Bob. > >>>> > >>>> Thank you > >>>> Laura > >>>> > >>>> > >>>> > >>>> 2013/8/1 Paul E. Jones Laura, > >>>> > >>>> The example I show below is a real call center example. I show use > >>>> of > >>> the old session ID. Tell me how that works. Forget about the new > >>> solution for the moment. > >>>> > >>>> If you say it will not work, then I'm not sure how we can make > >>>> something > >>> work with something that does not work. If there is a way to make > >>> this work, then we can try to figure out how to interwork with it. > >>>> > >>>> Paul > >>>> > >>>> > >>>> > >>>> From: Laura Liess > >>>> Sent: Thu Aug 01 11:51:26 EDT 2013 > >>>> > >>>> To: "Paul E. Jones" > >>>> Cc: insipid@ietf.org > >>>> > >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >>> compatibility > >>>> > >>>> Paul, > >>>> We use the old Session-ID only accross SBCs, to correlate both > legs > >>>> of > >>> the same dialog. And it works fine for this use case. We never > tried, > >>> intend or were required to do more with it. > >>>> We are not against the new mechanism, we just want it to interwork > >>>> with > >>> the old one which we have in thousands of customer end devices. If > it > >> does, > >>> we can add new end devices and application servers which support > the > >>> new Session-ID. Otherwise we can't. > >>>> > >>>> Let's see if it works when we keep the UUID order unchanged, as > >>>> Hadriel > >>> proposed. > >>>> > >>>> Thank you > >>>> Laura > >>>> > >>>> > >>>> 2013/8/1 Paul E. Jones Laura, > >>>> > >>>> I assert that old draft will not work for some "real-world" calls. > >>> Calls do get manipulated in enterprise environments and call > centers > >>> for billing purposes, privacy reasons, etc. > >>>> > >>>> Consider a common case: if you call into a call center and the > agent > >>> puts you on hold while they transfer you to a specialist (transfer > >>> out of consultation), for example, your SIP UA does not receive a > >>> REFER to initiate a new call directly to the specialist. This is > >>> handled at the call center. > >>>> > >>>> So rather specifically, how would this be handled (with the old > >> draft)? > >>>> > >>>> 1) Alice calls Bob (Session-ID: A) > >>>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > >>>> 3) Bob transfers the call from Alice to Carol using a local > transfer > >>> function on the PBX (Session-ID: ??) > >>>> > >>>> The PBX could send different values to Alice and Carol, but we > >>>> totally > >>> lose the end-to-end identification of the call. > >>>> > >>>> Alice could not send "A" to Carol, since Carol is expecting B. > >> Likewise, > >>> Carol cannot send "B" to Alice, since Alice is expecting "A". > Well, > >>> they could, and it would be no worse than our current proposal in > >>> terms of backward-compatibility. > >>>> > >>>> Paul > >>>> > >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] > On > >>> Behalf Of Laura Liess > >>>> Sent: Thursday, August 01, 2013 9:13 AM > >>>> To: insipid@ietf.org > >>>> > >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >>> compatibility > >>>> > >>>> > >>>> Hadriel's proposal works for us. > >>>> > >>>> Thank you > >>>> Laura > >>>> > >>>> > >>>> 2013/8/1 Hadriel Kaplan > >>>> > >>>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. > >>>> another > >>> vendor. This is just about a Working Group document, and whether > the > >>> mechanism defined in it should change the Session-ID header value > vs. > >>> parameter based on direction of messages, or not. I totally get > the > >>> need to have a distinguishing Session-ID identifier for party-A vs. > >> party-B. > >>> What I don't get is why they need to change the encoding of the > >>> Session-ID header value vs. parameter, on a message direction > basis. > >>>> > >>>> In other words, today the draft has this: > >>>> 1) Alice sends INVITE with "Session-ID: foo" > >>>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > >>>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" > >>>> 4) Bob sends BYE with "Session-ID: bar;remote=foo" > >>>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" > >>>> > >>>> But we could instead do this: > >>>> 1) Alice sends INVITE with "Session-ID: foo" > >>>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > >>>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" > >>>> 4) Bob sends BYE with "Session-ID: foo;remote=bar" > >>>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" > >>>> > >>>> This second model keeps the Session-ID header value as "foo" the > >>>> whole > >>> time, while adding a parameter of "bar" for Bob that remains a > >>> parameter the whole time. > >>>> Neither Alice nor Bob are confused about which one is "their" UUID > >> value. > >>>> And it's backward-compatible with the previous kaplan-draft. > >>>> And it's arguably easier to implement, for the common cases. > >>>> > >>>> I *think* there was a reason someone came up with at one time as > to > >>>> why > >>> it had to be swapped, but I don't remember what it is and I don't > see > >>> it in the draft. So I'm trying to find out why we need to do it > the > >>> way the draft currently has it. > >>>> > >>>> The other topic of whether SBCs will change things is completely > >>> orthogonal to the ordering or backwards compatibility issues, and > >>> really shouldn't be conflated with it at all. It has nothing to do > >>> with the solutions document, or the direction stuff, etc. > >>>> > >>>> -hadriel > >>>> > >>>> > >>>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones > >> wrote: > >>>> > >>>>> Folks, > >>>>> > >>>>> I step away for a couple of days and the floodgate opens. :) > >>>>> > >>>>> I think it's important to understand why we proposed using a > >>>>> two-part Session Identifier. The reason is that we have to be > able > >>>>> to > >>> effectively > >>>>> deal with things like forking, call transfer, park, bridging, > >>> conferencing, > >>>>> etc. > >>>>> > >>>>> When initiating a call and using a single UUID value, that has > the > >>> potential > >>>>> to go end-to-end. However, if a call is forked there are multiple > >>> "ends". > >>>>> How do we track each of those? For proper diagnostics and > >>> troubleshooting, > >>>>> it would be ideal to be able to identify which devices have an > >> issue. > >>>>> > >>>>> Once a call has been placed, there is a Session-ID established > >>>>> between > >>> Alice > >>>>> and Bob. If Alice (in one country) transfers Bob (perhaps in the > >>>>> same > >>> or > >>>>> different country) to a some location in a high-toll country, who > >>>>> pays > >>> the > >>>>> bill? Well, to address that, we do call transfer locally on > PBXes. > >>> The PBX > >>>>> maintains control over the call and Alice would pay the bill for > >>>>> the > >>> call > >>>>> transfer. But if Alice was talking to Carol before the transfer, > >>> there is a > >>>>> Session-ID for that call. If Bob is put in communication with > >>>>> Carol, > >>> what > >>>>> is the Session-ID value? Bob had one and Carol had a different > one. > >>> What > >>>>> is the new ID? > >>>>> > >>>>> It's issues like this that led us to using a two-part value. In > >>>>> this > >>> way, > >>>>> we could see the call from Alice to Bob has a Session-ID {A,B}. > >>>>> If > >>> Alice > >>>>> transfers the call to Carol, each device understands that the > >>>>> Session- > >>> ID > >>>>> changed to {B,C}. Not only that, but intermediaries along the > path > >>> that > >>>>> were not privy to signaling that resulted in this change can take > >>>>> note > >>> of > >>>>> the fact the value changed. This can provide a useful historical > >>> record, > >>>>> since previously they might see a call to Carol identified as > >>>>> {A,C}, > >>> but > >>>>> then it changed to {B,C}. > >>>>> > >>>>> This property extends quite naturally to other signaling > scenarios, > >>>>> as > >>> it > >>>>> allows one to identify a call end-to-end, but also establish some > >>>>> relationship between other calls that shared at least one UUID > >>>>> value > >>> out of > >>>>> the two. > >>>>> > >>>>> Hadriel mentioned the desire to use the Session-ID to correlate > >>>>> media > >>> flows > >>>>> and calls. That's certainly something Cisco would like to do, > but > >>>>> it > >>> is not > >>>>> the driver behind the solution. Having a valid end-to-end > >>>>> identifier > >>> (in > >>>>> whatever form) allows us to do that. We're not suggesting to fit > >>>>> the solution to meet that business use case, but rather we just > >>>>> want a > >>> solution > >>>>> that allows us to properly identify calls end-to-end and we > >>>>> recognize > >>> that, > >>>>> due to various service interactions in the network, these UUID > >>>>> values > >>> can > >>>>> change. > >>>>> > >>>>> I would hope that UUID values will not change to the extent that > >>>>> SBCs > >>> change > >>>>> them for business reasons. It would certainly defeat the point. > >>> Hadriel > >>>>> might be right that an SBC vendor might manipulate those values > at > >>>>> the request of a customer, but I would hope said customer > >>>>> appreciates that > >>> such > >>>>> a request effectively breaks the end-to-end model. We can't do > >>>>> much > >>> about > >>>>> that if they do go down that path. > >>>>> > >>>>> As for backward-compatibility, the simplest approach (IMO) is to > >>>>> just > >>> use a > >>>>> header value not already in use. Originally, we had proposed > >>>>> Session- > >>> UUID. > >>>>> That was changed at the request of the group to be Session-ID. > >>> However, > >>>>> when we have a two UUID solution interacting with a one-UUID > >>>>> solution, > >>> we > >>>>> immediately face some challenges. > >>>>> > >>>>> What happens if an older system sends this: > >>>>> Session-ID: X > >>>>> But then receives this: > >>>>> Session-ID: Y; remote=X > >>>>> > >>>>> Does this break things? If so, how do current implementations > deal > >>> with > >>>>> such things as mid-call transfers that happen on a PBX like the > one > >>>>> I described above? > >>>>> > >>>>> We could switch the order like this: > >>>>> Session-ID: X; remote=Y > >>>>> > >>>>> However, that does not work for similar reasons. If we have a > call > >>> transfer > >>>>> where Alice transfers a call with Bob to Carol, then each has a > >>> different > >>>>> idea about what the proper value is for the first position. > >>>>> > >>>>> Originally, the proposed solution did not indicate position > >>> information and > >>>>> just had single UUID values going in each direction. We then > >>>>> proposed > >>> a > >>>>> concatenated string (X:Y). However, that presented the same > issues > >>>>> for > >>> the > >>>>> call transfer case, so we indicate values by position (sender's > >>>>> value first), so it is clear what value the receive thinks the > >>>>> remote end > >>> has for > >>>>> the local end. It might be wrong, but that will be corrected in > >>>>> the following response. (Intermediaries can take note of the > >>>>> change.) > >>>>> > >>>>> So, that's why we are where we are. There has been an effort to > >>> maintain > >>>>> backward-compatibility, but there are challenges in meeting that > >>>>> requirement. Where it falls short, we do not know: we've not > been > >>> told > >>>>> explicitly what the issues are. Further, if there are such > issues, > >>>>> we > >>> need > >>>>> to also understand how those would be handled in the face of call > >>> transfer > >>>>> or "joining" a call locally on a PBX. Those are real-world > >>>>> scenarios > >>> that > >>>>> we must address. > >>>>> > >>>>> Anyway, nothing is set in stone. Anything can be changed, but I > >>>>> would > >>> hope > >>>>> we can find a solution that works for the enterprise use cases as > >>>>> well > >>> as > >>>>> the service provider networks. > >>>>> > >>>>> 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 > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From imcilwaine@opencloud.com Thu Aug 15 05:32:56 2013 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 A848011E80F8 for ; Thu, 15 Aug 2013 05:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW-1IHtmmitx for ; Thu, 15 Aug 2013 05:32:50 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with SMTP id 318C821E8087 for ; Thu, 15 Aug 2013 05:32:49 -0700 (PDT) Received: from mail-vb0-f51.google.com ([209.85.212.51]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUgzKbtPQuWARRGDxlkeuc3shvAMznnWF@postini.com; Thu, 15 Aug 2013 05:32:50 PDT Received: by mail-vb0-f51.google.com with SMTP id x16so458993vbf.24 for ; Thu, 15 Aug 2013 05:32:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:reply-to:from:references:in-reply-to :mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=SWffwkoLE6SqUh1+pw1Syv0++EO+PlIa8tKE2Njt6BY=; b=g5+Sjkl53+bg9TKzDavs3mm3Jg33MZDloYwvLYK3TeeyS4e/bvWLQ6XZWkpbGZphP6 Vn/S4kmK9uzfXzQNIYvhC1mOx8hZmHraJSuEpyY0LAJQoAUqeFS7a8Oshi8z1JPh1366 Oi4ybn/pRlL7IcAetJfsgamEiWcrEWb9ilZi2sCsRo6AsRMMvTG8Xxelv0/zYgKQWp2K +/StF5o5cbKazMHQI+10bUGbIYmBG7b2Ux7ZhCy6JZzMP0GLc1t8cpZzatmp1fL/Lwyd of+Wsw7bbnFgbmH6tl76wVE3U/Qieya7jKV3GHAplDOQ+mmqh3NwirILdpmPiiWxVW0P pAVA== X-Gm-Message-State: ALoCoQnmLWrdXs0q9DcCKOVlK35qTs+GJIxWbSxjZ5M9AAoH8Qr63eShBjB+bTTdOOLWOenTCK0aLnLeDEVnU0QGCdhoCZbXlG7Q/AmgSbqIv0auQdaua4g0lfrKcl/DRcn3XnevmX3SgiT29QjoHaE7s3tEZUqTTw== X-Received: by 10.52.73.135 with SMTP id l7mr12506798vdv.9.1376569957946; Thu, 15 Aug 2013 05:32:37 -0700 (PDT) X-Received: by 10.52.73.135 with SMTP id l7mr12506788vdv.9.1376569957790; Thu, 15 Aug 2013 05:32:37 -0700 (PDT) From: Iain McIlwaine References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> <001601ce993f$e8ae00b0$ba0a0210$@co.in> In-Reply-To: <001601ce993f$e8ae00b0$ba0a0210$@co.in> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKQJk1zw7AyhdJqEBmNnemgICOl9WAocGH+sBuC/YTJbbCTSw Date: Thu, 15 Aug 2013 13:32:35 +0100 Message-ID: To: Parthasarathi R , Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iain.mcilwaine@opencloud.com List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 12:32:56 -0000 "> Ahh right - it's been a while since I read that spec, and it's > painfully long and complicated. :)" Yes, yes it is indeed..... So I guess this is one scenario where the syntax doesn't quite work without additional logic of re-INVITE/UPDATE. However, Hadriel does make a good point in asking what this header would be used for. The predecessor Session-ID draft managed to sneak into 24.229 as a means of assisting with the IR.92 approved ad-hoc multi party conference (big thanks to GSMA for selecting the trickiest multi party implementation method there). Now I know this is way out of the scope of the current discussions but if the cap fits folks will wear it. (In the interest of full disclosure, this is actually the angle that got me interested in this draft rather than the troubleshooting aspect). Naturally this puts my concern a tad lower in the priority list. Kind Regards, Iain -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: 14 August 2013 23:45 To: 'Hadriel Kaplan'; iain.mcilwaine@opencloud.com Cc: insipid@ietf.org Subject: RE: [Insipid] Proposed INSIPID solution and backward compatibility Hadriel/Iain, I agree with Iain that end-to-end session-id is not possible with eSRVCC (3GPP 24.237) in IMS environment. My understanding is that ATCF is introduced just to avoid the end-to-end signaling callflow. The callflow is as follows: 1) Session is established between Alice & Bob with session id=foo;remote=bar 2) Alice moved from PS to CS. 3) MSC starts new INVITE with session-id=zab 4) ATCF has to send 200 OK to MSC with session-id=zab;remote=bar 5) ATCF shall Re-INVITE with session-id=zab;remote=bar towards SCC-AS 6) SCC-AS sends 200 OK with session-id=zab;remote=bar Please note that bob is not aware of session-id update of "foo" to "zab". There is no end-to-end session-id in these callflows. Thanks Partha > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Wednesday, August 14, 2013 10:15 PM > To: iain.mcilwaine@opencloud.com > Cc: insipid@ietf.org > Subject: Re: [Insipid] Proposed INSIPID solution and backward > compatibility > > > Ahh right - it's been a while since I read that spec, and it's > painfully long and complicated. :) > > So in the case of the MSC performing a continuity transfer on behalf > of Bob, I essentially think of it as a INVITE with Replaces model, > except without the Replaces info. The ATCF is like a PBX, and the > scenario is almost like a PBX barge-in feature, from a 50k-foot view. > And just like a barge-in, if you really want all sides to get updated > to have a consistent Session-ID param value, it might require a > re-INVITE/UPDATE be sent everywhere. > > With the legacy way of doing Session-ID but with also a remote param, > it could be like this: > > Alice INVITE through ATCF to Bob = "Session-ID:foo" > Bob 18x through ATCF to Alice = "Session-ID:foo;remote=bar" > > [ Bob loses PS and MSC triggers call continuity ] > > MSC INVITE to ATCF = "Session-ID:zab" > ATCF 200 to MSC = "Session-ID:zab;remote=foo" > ATCF 200 to Alice = "Session-ID:foo;remote=zab" > > Or depending on state of call and also depending on logic of ATCF, > ATCF could instead send back something else and eventually sends re- > INVITE/UPDATE to both parties, to create a consistent parameter value. > > I have a hard time believing an IMS provider would want to send SIP > re- INVITEs across their peering connections to the other carriers the > call came in from, just because their local UE switched from VoLTE to > 3GPP or whatever. Nor do I think the other carriers want to get such > re- INVITEs from them. > > With regards to "it invalidates the Session-ID as a meaningful e2e > tag", yes it does - the parameter might be consistent (eventually), > but the header value itself isn't. But the real question is what > would the Session-ID be *used for* - just having an e2e tag is not an end goal... > there has to be some purpose to it. With the original Session-ID > draft, the purpose was troubleshooting, and when we debated whether to > send re-INVITE/UPDATEs everywhere in order to handle the more > complicated scenarios, the consensus was that no one wanted to do that > (for obvious reasons). > > I think what some people have in mind is simply a value that is > consistent within their local domain. But that's a horse of a > different color, I think. > > -hadriel > > > On Aug 14, 2013, at 10:54 AM, Iain McIlwaine > wrote: > > > The scenario in question is for an IMS access network transfer > > during > call > > setup as described by 3GPP 24.237. After receiving the INVITE and > > replying with a 18x (and thus establishing an early dialog) Bob's > access > > network changes. > > > > In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP > > signalling on Bob's behalf and thus have no access to what the > previous > > Session-ID was. The MSC-S/MGCF initiates a call for Bob which is > > reconciled at the Transfer AS using 3PCC & Access Transfer > mechanisms. > > > > In this scenario and using the proposed syntax, both Alice and Bob > (well, > > Bob's MSC-S/MGCF) have an equal right to assert their UUID first as > > they've both created the INVITE. > > > > How this is handled in the Transfer AS (i.e. the ATCF or the SCC) > doesn't > > bother me so much as they're just 3PCC/B2BUAs, what it does do > however is > > invalidate the Session-ID as a meaningful end 2 end tag for any > service > > provider offering access transfer. > > > > Again, could be I'm misinterpreting something so happy to be > corrected. > > > > Cheers, > > Iain > > > > > > > > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > > Sent: 14 August 2013 15:22 > > To: iain.mcilwaine@opencloud.com > > Cc: insipid@ietf.org > > Subject: Re: [Insipid] Proposed INSIPID solution and backward > > compatibility > > > > > > I think it depends on how the "Transfer AS" is going to work, and > what you > > think "manipulation" means or why it matters. How is it any > different > > than a PBX call transfer scenario? Is the problem you're describing > a > > real transfer where Bob just didn't send a 200 yet, or do you really > mean > > a call-forwarding scenario, with early media? > > > > If you just mean the equivalent of call-forwarding type thing, where > the > > forwarding app server sends a 18x to generate "please wait while we > locate > > your party" media, then that's still ok (I think). Nothing ever said > the > > header parameter value couldn't change between responses. So it > would be > > like this: > > > > Alice INVITE through AS to Bob = "Session-ID:foo" > > Bob 18x through AS to Alice = "Session-ID:foo;remote=bar" > > Bob INVITE through AS to Carol = "Session-ID:foo" > > Carol 18x/2xx through AS to Bob = "Session-ID:foo;remote=qux" > > Bob 2xx through AS to Alice = "Session-ID:foo;remote=qux" > > > > > > If you mean a real call transfer, it's going to be uglier: > > > > Alice INVITE through PBX to Bob = "Session-ID:foo" > > Bob 18x through PBX to Alice = "Session-ID:foo;remote=bar" > > Bob INVITE through PBX to Carol = "Session-ID:zab" > > Carol 18x/2xx through PBX to Bob = "Session-ID:zab;remote=qux" > > [ Bob presses some transfer button thingy, PBX transfers the > > Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx > > to Alice of = "Session-ID:foo;remote=qux" > > Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and > > send re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo". > > > > I personally think sending re-INVITE/UPDATEs for this thing is going > to > > cause headaches, but if that's what people want, they can do it. > > > > Clearly the PBX has to keep track of these Session-IDs separately on > each > > call leg for some of these scenarios, but that's hardly a big deal - > it's > > *already* keeping track of these as separate call-legs with a bunch > of SIP > > state, because by definition it's acting as a SIP B2BUA with two > separate > > SIP dialogs. > > > > -hadriel > > > > > > On Aug 14, 2013, at 5:20 AM, Iain McIlwaine > > > wrote: > > > >> Folks, > >> > >> I see a lot of discussion for enterprise transfer scenarios but I > >> would like to highlight a problematic use case to gauge your > opinions. > >> > >> Using Hadriel's method which designates local:remote of the UUID > >> according to the issuer of the INVITE I can see a potential problem > >> for Access Transfer when the party being transferred is in the > > "proceeding" state. > >> So: > >> > >> Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" > >> Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=bar" > >> Bob' INVITE - "Transfer AS" Session-ID:foo' > >> > >> Note: the "Transfer AS" can be an ATCF or an SCC. > >> > >> We can see in this case using Hadriel's syntax we now require the > >> Transfer AS to perform manipulation of the Session-ID header which > >> runs contrary to a stated objective of no intermediary meddling of > the > > header. > >> > >> If we revert to interpreting the local:remote syntax being within > the > >> context of the receiver I believe we would avert this situation. > >> > >> Of course it could be I've misunderstood something so happy to be > >> shown the light. > >> > >> Kind regards, > >> Iain > >> > >> > >> > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >> Behalf Of Paul E. Jones > >> Sent: 13 August 2013 23:34 > >> To: 'Hadriel Kaplan' > >> Cc: insipid@ietf.org; 'Laura Liess' > >> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >> compatibility > >> > >> Hadriel, > >> > >>> I can't tell if you seriously believe the new mechanism is going > >>> to work end-to-end across all domains, or if you just mean > >>> end-to-end within a domain (like within the call-center). I don't > >>> mean that > in > >>> a negative way > >>> - I just mean I don't understand how you mean the words "end-to- > end". > >> > >> I seriously mean end-to-end. Assuming service providers did not > block > >> passage of an INVITE containing a new UUID value, then we can > >> always have an end-to-end value. As an "end" changes, so does the > >> end-to- > end > > value. > >> That's OK. > >> > >>> I seriously doubt this thing is going to achieve any more than the > >>> legacy draft did in terms of true end-to-end across-the-world type > >>> thing. In fact it may even do less. > >> > >> The only reason it would not is if: > >> 1) One endpoint does not support the procedures (can't help that) > >> 2) Something prevents a new INVITE from going to one endpoint (like > an > >> SBC) > >> > >> Otherwise, it would work. > >> > >>> When I make a call from my cell phone through my mobile provider, > >>> through N number of carriers, to an Enterprise call-center > somewhere > >>> in Timbuktu, I have a hard time believing all the carriers and > mobile > >>> providers want to get back and process a re-INVITE each and every > >>> time the call gets moved around inside the call-center's internal > PBX > >>> infrastructure. They rarely get that today, and I don't see them > >> changing in the future to do so... > >>> for what benefit? What use is it to update all the SIP systems > along > >>> the path, as well as my cell phone, with a new Session-ID value > just > >>> because the call got parked/unparked or internally transferred > inside > >> PBX/ACD/etc. > >>> systems in a call-center somewhere? > >>> > >>> Some call centers move the media around almost a dozen times per > call. > >>> You really think the rest of the world wants to get a dozen > >>> re-INVITEs, for no benefit? The SBCs aren't answering the re- > INVITEs > >>> locally today to hide the identity of who/what it gets moved > >>> around to > >>> - that we already do even when we forward the re-INVITEs - we're > >>> answering them locally because the service providers don't want > >>> nor need those re-INVITEs. It's just extra processing load, log > entries, > >>> and things that can go wrong; with no added benefit. > >> > >> I really cannot do anything about these "noise" issues. I recognize > >> that in practice, much of the use of SIP has been absolutely > nothing > >> more than a PSTN replacement. It has been merely a means of moving > from > > TDM to IP. > >> I'm glad it happened, but it's more than unfortunate if that's all > we > >> accomplish. > >> > >> As I look to doing more interesting things where I have different > >> applications running in various devices connected to different > >> networks and associated to my "phone" where I can utilize all of > them > >> as a part of a "call", I see value in having this end-to-end > >> identifier for even this more complex arrangement. However, I can > >> understand if service providers do not take an active interest in > >> this. From a research perspective, these more advanced > communication > >> systems are interesting. From a business perspective, there is a > >> question about ROI for carriers. I get > >> that: > >> there's no money in doing much more than providing the most basic > >> voice service, and even that service has a very small profit margin. > >> However, progress, capabilities, functionality, and improvements in > >> the way we work and communicate should go forward, and they are. > >> Already, we see a number of alternatives like Skype, Facetime, > Google > >> Hangouts, etc. and I expect functionality will become much more > >> interesting, with a wider mix of multimedia applications in use at > once. > >> > >> Bottom line is that we should not constrain a system, but try to > make > >> it as flexible as possible. It might not work everywhere, but > >> don't constrain ourselves to the most basic voice call flow. > >> > >> Paul > >> > >>> -hadriel > >>> > >>> > >>> On Aug 2, 2013, at 11:48 AM, Paul E. Jones > >> wrote: > >>> > >>>> Larua, > >>>> > >>>> So in effect, the current deployments are not end-to-end, but > >>>> edge-to- > >>> edge somewhere. I can appreciate that, but it does make it more > >>> challenging to try to work with when we go all the way end-to-end. > >>>> > >>>> Paul > >>>> > >>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > >>>> Sent: Friday, August 02, 2013 4:47 AM > >>>> To: Paul E. Jones > >>>> Cc: insipid@ietf.org > >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >>> compatibility > >>>> > >>>> Paul, > >>>> > >>>> As I said, we never used the old Session-ID to do more than > >>>> correlate > >>> bothe legs of the same dialog. So in your example we have: > >>>> - Alice to Bob: Session-ID A > >>>> - Bob to Carol: Session-ID B > >>>> - Alice to Carol: Session-ID C > >>>> > >>>> There is no correlation between them. We just correlate both legs > of > >>>> the > >>> same dialog across the SBC between Alice and Bob. > >>>> > >>>> Thank you > >>>> Laura > >>>> > >>>> > >>>> > >>>> 2013/8/1 Paul E. Jones Laura, > >>>> > >>>> The example I show below is a real call center example. I show > >>>> use of > >>> the old session ID. Tell me how that works. Forget about the new > >>> solution for the moment. > >>>> > >>>> If you say it will not work, then I'm not sure how we can make > >>>> something > >>> work with something that does not work. If there is a way to make > >>> this work, then we can try to figure out how to interwork with it. > >>>> > >>>> Paul > >>>> > >>>> > >>>> > >>>> From: Laura Liess > >>>> Sent: Thu Aug 01 11:51:26 EDT 2013 > >>>> > >>>> To: "Paul E. Jones" > >>>> Cc: insipid@ietf.org > >>>> > >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >>> compatibility > >>>> > >>>> Paul, > >>>> We use the old Session-ID only accross SBCs, to correlate both > legs > >>>> of > >>> the same dialog. And it works fine for this use case. We never > tried, > >>> intend or were required to do more with it. > >>>> We are not against the new mechanism, we just want it to > >>>> interwork with > >>> the old one which we have in thousands of customer end devices. If > it > >> does, > >>> we can add new end devices and application servers which support > the > >>> new Session-ID. Otherwise we can't. > >>>> > >>>> Let's see if it works when we keep the UUID order unchanged, as > >>>> Hadriel > >>> proposed. > >>>> > >>>> Thank you > >>>> Laura > >>>> > >>>> > >>>> 2013/8/1 Paul E. Jones Laura, > >>>> > >>>> I assert that old draft will not work for some "real-world" calls. > >>> Calls do get manipulated in enterprise environments and call > centers > >>> for billing purposes, privacy reasons, etc. > >>>> > >>>> Consider a common case: if you call into a call center and the > agent > >>> puts you on hold while they transfer you to a specialist (transfer > >>> out of consultation), for example, your SIP UA does not receive a > >>> REFER to initiate a new call directly to the specialist. This is > >>> handled at the call center. > >>>> > >>>> So rather specifically, how would this be handled (with the old > >> draft)? > >>>> > >>>> 1) Alice calls Bob (Session-ID: A) > >>>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) > >>>> 3) Bob transfers the call from Alice to Carol using a local > transfer > >>> function on the PBX (Session-ID: ??) > >>>> > >>>> The PBX could send different values to Alice and Carol, but we > >>>> totally > >>> lose the end-to-end identification of the call. > >>>> > >>>> Alice could not send "A" to Carol, since Carol is expecting B. > >> Likewise, > >>> Carol cannot send "B" to Alice, since Alice is expecting "A". > Well, > >>> they could, and it would be no worse than our current proposal in > >>> terms of backward-compatibility. > >>>> > >>>> Paul > >>>> > >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] > On > >>> Behalf Of Laura Liess > >>>> Sent: Thursday, August 01, 2013 9:13 AM > >>>> To: insipid@ietf.org > >>>> > >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward > >>> compatibility > >>>> > >>>> > >>>> Hadriel's proposal works for us. > >>>> > >>>> Thank you > >>>> Laura > >>>> > >>>> > >>>> 2013/8/1 Hadriel Kaplan > >>>> > >>>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. > >>>> another > >>> vendor. This is just about a Working Group document, and whether > the > >>> mechanism defined in it should change the Session-ID header value > vs. > >>> parameter based on direction of messages, or not. I totally get > the > >>> need to have a distinguishing Session-ID identifier for party-A vs. > >> party-B. > >>> What I don't get is why they need to change the encoding of the > >>> Session-ID header value vs. parameter, on a message direction > basis. > >>>> > >>>> In other words, today the draft has this: > >>>> 1) Alice sends INVITE with "Session-ID: foo" > >>>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" > >>>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" > >>>> 4) Bob sends BYE with "Session-ID: bar;remote=foo" > >>>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" > >>>> > >>>> But we could instead do this: > >>>> 1) Alice sends INVITE with "Session-ID: foo" > >>>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" > >>>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" > >>>> 4) Bob sends BYE with "Session-ID: foo;remote=bar" > >>>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" > >>>> > >>>> This second model keeps the Session-ID header value as "foo" the > >>>> whole > >>> time, while adding a parameter of "bar" for Bob that remains a > >>> parameter the whole time. > >>>> Neither Alice nor Bob are confused about which one is "their" > >>>> UUID > >> value. > >>>> And it's backward-compatible with the previous kaplan-draft. > >>>> And it's arguably easier to implement, for the common cases. > >>>> > >>>> I *think* there was a reason someone came up with at one time as > to > >>>> why > >>> it had to be swapped, but I don't remember what it is and I don't > see > >>> it in the draft. So I'm trying to find out why we need to do it > the > >>> way the draft currently has it. > >>>> > >>>> The other topic of whether SBCs will change things is completely > >>> orthogonal to the ordering or backwards compatibility issues, and > >>> really shouldn't be conflated with it at all. It has nothing to > >>> do with the solutions document, or the direction stuff, etc. > >>>> > >>>> -hadriel > >>>> > >>>> > >>>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones > >>>> > >> wrote: > >>>> > >>>>> Folks, > >>>>> > >>>>> I step away for a couple of days and the floodgate opens. :) > >>>>> > >>>>> I think it's important to understand why we proposed using a > >>>>> two-part Session Identifier. The reason is that we have to be > able > >>>>> to > >>> effectively > >>>>> deal with things like forking, call transfer, park, bridging, > >>> conferencing, > >>>>> etc. > >>>>> > >>>>> When initiating a call and using a single UUID value, that has > the > >>> potential > >>>>> to go end-to-end. However, if a call is forked there are > >>>>> multiple > >>> "ends". > >>>>> How do we track each of those? For proper diagnostics and > >>> troubleshooting, > >>>>> it would be ideal to be able to identify which devices have an > >> issue. > >>>>> > >>>>> Once a call has been placed, there is a Session-ID established > >>>>> between > >>> Alice > >>>>> and Bob. If Alice (in one country) transfers Bob (perhaps in > >>>>> the same > >>> or > >>>>> different country) to a some location in a high-toll country, > >>>>> who pays > >>> the > >>>>> bill? Well, to address that, we do call transfer locally on > PBXes. > >>> The PBX > >>>>> maintains control over the call and Alice would pay the bill for > >>>>> the > >>> call > >>>>> transfer. But if Alice was talking to Carol before the > >>>>> transfer, > >>> there is a > >>>>> Session-ID for that call. If Bob is put in communication with > >>>>> Carol, > >>> what > >>>>> is the Session-ID value? Bob had one and Carol had a different > one. > >>> What > >>>>> is the new ID? > >>>>> > >>>>> It's issues like this that led us to using a two-part value. In > >>>>> this > >>> way, > >>>>> we could see the call from Alice to Bob has a Session-ID {A,B}. > >>>>> If > >>> Alice > >>>>> transfers the call to Carol, each device understands that the > >>>>> Session- > >>> ID > >>>>> changed to {B,C}. Not only that, but intermediaries along the > path > >>> that > >>>>> were not privy to signaling that resulted in this change can > >>>>> take note > >>> of > >>>>> the fact the value changed. This can provide a useful > >>>>> historical > >>> record, > >>>>> since previously they might see a call to Carol identified as > >>>>> {A,C}, > >>> but > >>>>> then it changed to {B,C}. > >>>>> > >>>>> This property extends quite naturally to other signaling > scenarios, > >>>>> as > >>> it > >>>>> allows one to identify a call end-to-end, but also establish > >>>>> some relationship between other calls that shared at least one > >>>>> UUID value > >>> out of > >>>>> the two. > >>>>> > >>>>> Hadriel mentioned the desire to use the Session-ID to correlate > >>>>> media > >>> flows > >>>>> and calls. That's certainly something Cisco would like to do, > but > >>>>> it > >>> is not > >>>>> the driver behind the solution. Having a valid end-to-end > >>>>> identifier > >>> (in > >>>>> whatever form) allows us to do that. We're not suggesting to > >>>>> fit the solution to meet that business use case, but rather we > >>>>> just want a > >>> solution > >>>>> that allows us to properly identify calls end-to-end and we > >>>>> recognize > >>> that, > >>>>> due to various service interactions in the network, these UUID > >>>>> values > >>> can > >>>>> change. > >>>>> > >>>>> I would hope that UUID values will not change to the extent that > >>>>> SBCs > >>> change > >>>>> them for business reasons. It would certainly defeat the point. > >>> Hadriel > >>>>> might be right that an SBC vendor might manipulate those values > at > >>>>> the request of a customer, but I would hope said customer > >>>>> appreciates that > >>> such > >>>>> a request effectively breaks the end-to-end model. We can't do > >>>>> much > >>> about > >>>>> that if they do go down that path. > >>>>> > >>>>> As for backward-compatibility, the simplest approach (IMO) is to > >>>>> just > >>> use a > >>>>> header value not already in use. Originally, we had proposed > >>>>> Session- > >>> UUID. > >>>>> That was changed at the request of the group to be Session-ID. > >>> However, > >>>>> when we have a two UUID solution interacting with a one-UUID > >>>>> solution, > >>> we > >>>>> immediately face some challenges. > >>>>> > >>>>> What happens if an older system sends this: > >>>>> Session-ID: X > >>>>> But then receives this: > >>>>> Session-ID: Y; remote=X > >>>>> > >>>>> Does this break things? If so, how do current implementations > deal > >>> with > >>>>> such things as mid-call transfers that happen on a PBX like the > one > >>>>> I described above? > >>>>> > >>>>> We could switch the order like this: > >>>>> Session-ID: X; remote=Y > >>>>> > >>>>> However, that does not work for similar reasons. If we have a > call > >>> transfer > >>>>> where Alice transfers a call with Bob to Carol, then each has a > >>> different > >>>>> idea about what the proper value is for the first position. > >>>>> > >>>>> Originally, the proposed solution did not indicate position > >>> information and > >>>>> just had single UUID values going in each direction. We then > >>>>> proposed > >>> a > >>>>> concatenated string (X:Y). However, that presented the same > issues > >>>>> for > >>> the > >>>>> call transfer case, so we indicate values by position (sender's > >>>>> value first), so it is clear what value the receive thinks the > >>>>> remote end > >>> has for > >>>>> the local end. It might be wrong, but that will be corrected in > >>>>> the following response. (Intermediaries can take note of the > >>>>> change.) > >>>>> > >>>>> So, that's why we are where we are. There has been an effort to > >>> maintain > >>>>> backward-compatibility, but there are challenges in meeting that > >>>>> requirement. Where it falls short, we do not know: we've not > been > >>> told > >>>>> explicitly what the issues are. Further, if there are such > issues, > >>>>> we > >>> need > >>>>> to also understand how those would be handled in the face of > >>>>> call > >>> transfer > >>>>> or "joining" a call locally on a PBX. Those are real-world > >>>>> scenarios > >>> that > >>>>> we must address. > >>>>> > >>>>> Anyway, nothing is set in stone. Anything can be changed, but I > >>>>> would > >>> hope > >>>>> we can find a solution that works for the enterprise use cases > >>>>> as well > >>> as > >>>>> the service provider networks. > >>>>> > >>>>> 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 > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From hadriel.kaplan@oracle.com Thu Aug 15 07:18:53 2013 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 4800821E8154 for ; Thu, 15 Aug 2013 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDBDhZDexOtw for ; Thu, 15 Aug 2013 07:18:47 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 878F221E814A for ; Thu, 15 Aug 2013 07:18:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7FEIjDT032577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Aug 2013 14:18:46 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7FEIgIb021517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Aug 2013 14:18:43 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7FEIfeS019652; Thu, 15 Aug 2013 14:18:41 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Aug 2013 07:18:41 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: Date: Thu, 15 Aug 2013 10:18:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <50E3B10B-4D80-44E4-B104-5D934CF25E7F@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> <001601ce993f$e8ae00b0$ba0a0210$@co.in> To: iain.mcilwaine@opencloud.com X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: insipid@ietf.org, Parthasarathi R Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility 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, 15 Aug 2013 14:18:53 -0000 I haven't kept up with what 3GPP is planning to use this for, but if = it's the resource-list thing from a couple years ago, I think that = wasn't going to work right either. In the old kaplan session-id draft = it talked about such correlation in 3GPP and explains why session-id is = not really a solution for that. This was put in the end of the Appendix in old draft: = http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03#appendix-A.= 1 Somehow that last page or two got cut off in the kaplan draft being = submitted right now for Informational, which is super-annoying. :( -hadriel On Aug 15, 2013, at 8:32 AM, Iain McIlwaine = wrote: > "> Ahh right - it's been a while since I read that spec, and it's >> painfully long and complicated. :)" >=20 > Yes, yes it is indeed..... >=20 > So I guess this is one scenario where the syntax doesn't quite work > without additional logic of re-INVITE/UPDATE. However, Hadriel does = make > a good point in asking what this header would be used for. >=20 > The predecessor Session-ID draft managed to sneak into 24.229 as a = means > of assisting with the IR.92 approved ad-hoc multi party conference = (big > thanks to GSMA for selecting the trickiest multi party implementation > method there). Now I know this is way out of the scope of the current > discussions but if the cap fits folks will wear it. (In the interest = of > full disclosure, this is actually the angle that got me interested in = this > draft rather than the troubleshooting aspect). >=20 > Naturally this puts my concern a tad lower in the priority list. >=20 > Kind Regards, > Iain >=20 >=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 14 August 2013 23:45 > To: 'Hadriel Kaplan'; iain.mcilwaine@opencloud.com > Cc: insipid@ietf.org > Subject: RE: [Insipid] Proposed INSIPID solution and backward > compatibility >=20 > Hadriel/Iain, >=20 > I agree with Iain that end-to-end session-id is not possible with = eSRVCC > (3GPP 24.237) in IMS environment. My understanding is that ATCF is > introduced just to avoid the end-to-end signaling callflow. >=20 > The callflow is as follows: >=20 > 1) Session is established between Alice & Bob with session > id=3Dfoo;remote=3Dbar >=20 > 2) Alice moved from PS to CS. > 3) MSC starts new INVITE with session-id=3Dzab > 4) ATCF has to send 200 OK to MSC with session-id=3Dzab;remote=3Dbar > 5) ATCF shall Re-INVITE with session-id=3Dzab;remote=3Dbar towards = SCC-AS > 6) SCC-AS sends 200 OK with session-id=3Dzab;remote=3Dbar >=20 > Please note that bob is not aware of session-id update of "foo" to = "zab". > There is no end-to-end session-id in these callflows. >=20 > Thanks > Partha >=20 >=20 >=20 >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Wednesday, August 14, 2013 10:15 PM >> To: iain.mcilwaine@opencloud.com >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >>=20 >>=20 >> Ahh right - it's been a while since I read that spec, and it's >> painfully long and complicated. :) >>=20 >> So in the case of the MSC performing a continuity transfer on behalf >> of Bob, I essentially think of it as a INVITE with Replaces model, >> except without the Replaces info. The ATCF is like a PBX, and the >> scenario is almost like a PBX barge-in feature, from a 50k-foot view. >> And just like a barge-in, if you really want all sides to get updated >> to have a consistent Session-ID param value, it might require a >> re-INVITE/UPDATE be sent everywhere. >>=20 >> With the legacy way of doing Session-ID but with also a remote param, >> it could be like this: >>=20 >> Alice INVITE through ATCF to Bob =3D "Session-ID:foo" >> Bob 18x through ATCF to Alice =3D "Session-ID:foo;remote=3Dbar" >>=20 >> [ Bob loses PS and MSC triggers call continuity ] >>=20 >> MSC INVITE to ATCF =3D "Session-ID:zab" >> ATCF 200 to MSC =3D "Session-ID:zab;remote=3Dfoo" >> ATCF 200 to Alice =3D "Session-ID:foo;remote=3Dzab" >>=20 >> Or depending on state of call and also depending on logic of ATCF, >> ATCF could instead send back something else and eventually sends re- >> INVITE/UPDATE to both parties, to create a consistent parameter = value. >>=20 >> I have a hard time believing an IMS provider would want to send SIP >> re- INVITEs across their peering connections to the other carriers = the >> call came in from, just because their local UE switched from VoLTE to >> 3GPP or whatever. Nor do I think the other carriers want to get such >> re- INVITEs from them. >>=20 >> With regards to "it invalidates the Session-ID as a meaningful e2e >> tag", yes it does - the parameter might be consistent (eventually), >> but the header value itself isn't. But the real question is what >> would the Session-ID be *used for* - just having an e2e tag is not an > end goal... >> there has to be some purpose to it. With the original Session-ID >> draft, the purpose was troubleshooting, and when we debated whether = to >> send re-INVITE/UPDATEs everywhere in order to handle the more >> complicated scenarios, the consensus was that no one wanted to do = that >> (for obvious reasons). >>=20 >> I think what some people have in mind is simply a value that is >> consistent within their local domain. But that's a horse of a >> different color, I think. >>=20 >> -hadriel >>=20 >>=20 >> On Aug 14, 2013, at 10:54 AM, Iain McIlwaine >> wrote: >>=20 >>> The scenario in question is for an IMS access network transfer >>> during >> call >>> setup as described by 3GPP 24.237. After receiving the INVITE and >>> replying with a 18x (and thus establishing an early dialog) Bob's >> access >>> network changes. >>>=20 >>> In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP >>> signalling on Bob's behalf and thus have no access to what the >> previous >>> Session-ID was. The MSC-S/MGCF initiates a call for Bob which is >>> reconciled at the Transfer AS using 3PCC & Access Transfer >> mechanisms. >>>=20 >>> In this scenario and using the proposed syntax, both Alice and Bob >> (well, >>> Bob's MSC-S/MGCF) have an equal right to assert their UUID first as >>> they've both created the INVITE. >>>=20 >>> How this is handled in the Transfer AS (i.e. the ATCF or the SCC) >> doesn't >>> bother me so much as they're just 3PCC/B2BUAs, what it does do >> however is >>> invalidate the Session-ID as a meaningful end 2 end tag for any >> service >>> provider offering access transfer. >>>=20 >>> Again, could be I'm misinterpreting something so happy to be >> corrected. >>>=20 >>> Cheers, >>> Iain >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >>> Sent: 14 August 2013 15:22 >>> To: iain.mcilwaine@opencloud.com >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>> compatibility >>>=20 >>>=20 >>> I think it depends on how the "Transfer AS" is going to work, and >> what you >>> think "manipulation" means or why it matters. How is it any >> different >>> than a PBX call transfer scenario? Is the problem you're describing >> a >>> real transfer where Bob just didn't send a 200 yet, or do you really >> mean >>> a call-forwarding scenario, with early media? >>>=20 >>> If you just mean the equivalent of call-forwarding type thing, where >> the >>> forwarding app server sends a 18x to generate "please wait while we >> locate >>> your party" media, then that's still ok (I think). Nothing ever said >> the >>> header parameter value couldn't change between responses. So it >> would be >>> like this: >>>=20 >>> Alice INVITE through AS to Bob =3D "Session-ID:foo" >>> Bob 18x through AS to Alice =3D "Session-ID:foo;remote=3Dbar" >>> Bob INVITE through AS to Carol =3D "Session-ID:foo" >>> Carol 18x/2xx through AS to Bob =3D "Session-ID:foo;remote=3Dqux" >>> Bob 2xx through AS to Alice =3D "Session-ID:foo;remote=3Dqux" >>>=20 >>>=20 >>> If you mean a real call transfer, it's going to be uglier: >>>=20 >>> Alice INVITE through PBX to Bob =3D "Session-ID:foo" >>> Bob 18x through PBX to Alice =3D "Session-ID:foo;remote=3Dbar" >>> Bob INVITE through PBX to Carol =3D "Session-ID:zab" >>> Carol 18x/2xx through PBX to Bob =3D "Session-ID:zab;remote=3Dqux" >>> [ Bob presses some transfer button thingy, PBX transfers the >>> Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx >>> to Alice of =3D "Session-ID:foo;remote=3Dqux" >>> Or PBX can send 2xx to Alice of "Session-ID:foo;remote=3Dzab", and >>> send re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=3Dfoo". >>>=20 >>> I personally think sending re-INVITE/UPDATEs for this thing is going >> to >>> cause headaches, but if that's what people want, they can do it. >>>=20 >>> Clearly the PBX has to keep track of these Session-IDs separately on >> each >>> call leg for some of these scenarios, but that's hardly a big deal - >> it's >>> *already* keeping track of these as separate call-legs with a bunch >> of SIP >>> state, because by definition it's acting as a SIP B2BUA with two >> separate >>> SIP dialogs. >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 14, 2013, at 5:20 AM, Iain McIlwaine >> >>> wrote: >>>=20 >>>> Folks, >>>>=20 >>>> I see a lot of discussion for enterprise transfer scenarios but I >>>> would like to highlight a problematic use case to gauge your >> opinions. >>>>=20 >>>> Using Hadriel's method which designates local:remote of the UUID >>>> according to the issuer of the INVITE I can see a potential problem >>>> for Access Transfer when the party being transferred is in the >>> "proceeding" state. >>>> So: >>>>=20 >>>> Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" >>>> Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=3Dbar" >>>> Bob' INVITE - "Transfer AS" Session-ID:foo' >>>>=20 >>>> Note: the "Transfer AS" can be an ATCF or an SCC. >>>>=20 >>>> We can see in this case using Hadriel's syntax we now require the >>>> Transfer AS to perform manipulation of the Session-ID header which >>>> runs contrary to a stated objective of no intermediary meddling of >> the >>> header. >>>>=20 >>>> If we revert to interpreting the local:remote syntax being within >> the >>>> context of the receiver I believe we would avert this situation. >>>>=20 >>>> Of course it could be I've misunderstood something so happy to be >>>> shown the light. >>>>=20 >>>> Kind regards, >>>> Iain >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Paul E. Jones >>>> Sent: 13 August 2013 23:34 >>>> To: 'Hadriel Kaplan' >>>> Cc: insipid@ietf.org; 'Laura Liess' >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>> compatibility >>>>=20 >>>> Hadriel, >>>>=20 >>>>> I can't tell if you seriously believe the new mechanism is going >>>>> to work end-to-end across all domains, or if you just mean >>>>> end-to-end within a domain (like within the call-center). I don't >>>>> mean that >> in >>>>> a negative way >>>>> - I just mean I don't understand how you mean the words "end-to- >> end". >>>>=20 >>>> I seriously mean end-to-end. Assuming service providers did not >> block >>>> passage of an INVITE containing a new UUID value, then we can >>>> always have an end-to-end value. As an "end" changes, so does the >>>> end-to- >> end >>> value. >>>> That's OK. >>>>=20 >>>>> I seriously doubt this thing is going to achieve any more than the >>>>> legacy draft did in terms of true end-to-end across-the-world type >>>>> thing. In fact it may even do less. >>>>=20 >>>> The only reason it would not is if: >>>> 1) One endpoint does not support the procedures (can't help that) >>>> 2) Something prevents a new INVITE from going to one endpoint (like >> an >>>> SBC) >>>>=20 >>>> Otherwise, it would work. >>>>=20 >>>>> When I make a call from my cell phone through my mobile provider, >>>>> through N number of carriers, to an Enterprise call-center >> somewhere >>>>> in Timbuktu, I have a hard time believing all the carriers and >> mobile >>>>> providers want to get back and process a re-INVITE each and every >>>>> time the call gets moved around inside the call-center's internal >> PBX >>>>> infrastructure. They rarely get that today, and I don't see them >>>> changing in the future to do so... >>>>> for what benefit? What use is it to update all the SIP systems >> along >>>>> the path, as well as my cell phone, with a new Session-ID value >> just >>>>> because the call got parked/unparked or internally transferred >> inside >>>> PBX/ACD/etc. >>>>> systems in a call-center somewhere? >>>>>=20 >>>>> Some call centers move the media around almost a dozen times per >> call. >>>>> You really think the rest of the world wants to get a dozen >>>>> re-INVITEs, for no benefit? The SBCs aren't answering the re- >> INVITEs >>>>> locally today to hide the identity of who/what it gets moved >>>>> around to >>>>> - that we already do even when we forward the re-INVITEs - we're >>>>> answering them locally because the service providers don't want >>>>> nor need those re-INVITEs. It's just extra processing load, log >> entries, >>>>> and things that can go wrong; with no added benefit. >>>>=20 >>>> I really cannot do anything about these "noise" issues. I recognize >>>> that in practice, much of the use of SIP has been absolutely >> nothing >>>> more than a PSTN replacement. It has been merely a means of moving >> from >>> TDM to IP. >>>> I'm glad it happened, but it's more than unfortunate if that's all >> we >>>> accomplish. >>>>=20 >>>> As I look to doing more interesting things where I have different >>>> applications running in various devices connected to different >>>> networks and associated to my "phone" where I can utilize all of >> them >>>> as a part of a "call", I see value in having this end-to-end >>>> identifier for even this more complex arrangement. However, I can >>>> understand if service providers do not take an active interest in >>>> this. =46rom a research perspective, these more advanced >> communication >>>> systems are interesting. =46rom a business perspective, there is a >>>> question about ROI for carriers. I get >>>> that: >>>> there's no money in doing much more than providing the most basic >>>> voice service, and even that service has a very small profit = margin. >>>> However, progress, capabilities, functionality, and improvements in >>>> the way we work and communicate should go forward, and they are. >>>> Already, we see a number of alternatives like Skype, Facetime, >> Google >>>> Hangouts, etc. and I expect functionality will become much more >>>> interesting, with a wider mix of multimedia applications in use at >> once. >>>>=20 >>>> Bottom line is that we should not constrain a system, but try to >> make >>>> it as flexible as possible. It might not work everywhere, but >>>> don't constrain ourselves to the most basic voice call flow. >>>>=20 >>>> Paul >>>>=20 >>>>> -hadriel >>>>>=20 >>>>>=20 >>>>> On Aug 2, 2013, at 11:48 AM, Paul E. Jones >>>> wrote: >>>>>=20 >>>>>> Larua, >>>>>>=20 >>>>>> So in effect, the current deployments are not end-to-end, but >>>>>> edge-to- >>>>> edge somewhere. I can appreciate that, but it does make it more >>>>> challenging to try to work with when we go all the way end-to-end. >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >>>>>> Sent: Friday, August 02, 2013 4:47 AM >>>>>> To: Paul E. Jones >>>>>> Cc: insipid@ietf.org >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>>=20 >>>>>> Paul, >>>>>>=20 >>>>>> As I said, we never used the old Session-ID to do more than >>>>>> correlate >>>>> bothe legs of the same dialog. So in your example we have: >>>>>> - Alice to Bob: Session-ID A >>>>>> - Bob to Carol: Session-ID B >>>>>> - Alice to Carol: Session-ID C >>>>>>=20 >>>>>> There is no correlation between them. We just correlate both legs >> of >>>>>> the >>>>> same dialog across the SBC between Alice and Bob. >>>>>>=20 >>>>>> Thank you >>>>>> Laura >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> 2013/8/1 Paul E. Jones Laura, >>>>>>=20 >>>>>> The example I show below is a real call center example. I show >>>>>> use of >>>>> the old session ID. Tell me how that works. Forget about the new >>>>> solution for the moment. >>>>>>=20 >>>>>> If you say it will not work, then I'm not sure how we can make >>>>>> something >>>>> work with something that does not work. If there is a way to make >>>>> this work, then we can try to figure out how to interwork with it. >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> From: Laura Liess >>>>>> Sent: Thu Aug 01 11:51:26 EDT 2013 >>>>>>=20 >>>>>> To: "Paul E. Jones" >>>>>> Cc: insipid@ietf.org >>>>>>=20 >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>>=20 >>>>>> Paul, >>>>>> We use the old Session-ID only accross SBCs, to correlate both >> legs >>>>>> of >>>>> the same dialog. And it works fine for this use case. We never >> tried, >>>>> intend or were required to do more with it. >>>>>> We are not against the new mechanism, we just want it to >>>>>> interwork with >>>>> the old one which we have in thousands of customer end devices. If >> it >>>> does, >>>>> we can add new end devices and application servers which support >> the >>>>> new Session-ID. Otherwise we can't. >>>>>>=20 >>>>>> Let's see if it works when we keep the UUID order unchanged, as >>>>>> Hadriel >>>>> proposed. >>>>>>=20 >>>>>> Thank you >>>>>> Laura >>>>>>=20 >>>>>>=20 >>>>>> 2013/8/1 Paul E. Jones Laura, >>>>>>=20 >>>>>> I assert that old draft will not work for some "real-world" = calls. >>>>> Calls do get manipulated in enterprise environments and call >> centers >>>>> for billing purposes, privacy reasons, etc. >>>>>>=20 >>>>>> Consider a common case: if you call into a call center and the >> agent >>>>> puts you on hold while they transfer you to a specialist (transfer >>>>> out of consultation), for example, your SIP UA does not receive a >>>>> REFER to initiate a new call directly to the specialist. This is >>>>> handled at the call center. >>>>>>=20 >>>>>> So rather specifically, how would this be handled (with the old >>>> draft)? >>>>>>=20 >>>>>> 1) Alice calls Bob (Session-ID: A) >>>>>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) >>>>>> 3) Bob transfers the call from Alice to Carol using a local >> transfer >>>>> function on the PBX (Session-ID: ??) >>>>>>=20 >>>>>> The PBX could send different values to Alice and Carol, but we >>>>>> totally >>>>> lose the end-to-end identification of the call. >>>>>>=20 >>>>>> Alice could not send "A" to Carol, since Carol is expecting B. >>>> Likewise, >>>>> Carol cannot send "B" to Alice, since Alice is expecting "A". >> Well, >>>>> they could, and it would be no worse than our current proposal in >>>>> terms of backward-compatibility. >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] >> On >>>>> Behalf Of Laura Liess >>>>>> Sent: Thursday, August 01, 2013 9:13 AM >>>>>> To: insipid@ietf.org >>>>>>=20 >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>>=20 >>>>>>=20 >>>>>> Hadriel's proposal works for us. >>>>>>=20 >>>>>> Thank you >>>>>> Laura >>>>>>=20 >>>>>>=20 >>>>>> 2013/8/1 Hadriel Kaplan >>>>>>=20 >>>>>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. >>>>>> another >>>>> vendor. This is just about a Working Group document, and whether >> the >>>>> mechanism defined in it should change the Session-ID header value >> vs. >>>>> parameter based on direction of messages, or not. I totally get >> the >>>>> need to have a distinguishing Session-ID identifier for party-A = vs. >>>> party-B. >>>>> What I don't get is why they need to change the encoding of the >>>>> Session-ID header value vs. parameter, on a message direction >> basis. >>>>>>=20 >>>>>> In other words, today the draft has this: >>>>>> 1) Alice sends INVITE with "Session-ID: foo" >>>>>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=3Dfoo" >>>>>> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >>>>>> 4) Bob sends BYE with "Session-ID: bar;remote=3Dfoo" >>>>>> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >>>>>>=20 >>>>>> But we could instead do this: >>>>>> 1) Alice sends INVITE with "Session-ID: foo" >>>>>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=3Dbar" >>>>>> 3) Alice sends ACK with "Session-ID: foo;remote=3Dbar" >>>>>> 4) Bob sends BYE with "Session-ID: foo;remote=3Dbar" >>>>>> 5) Alice sends 200 with "Session-ID: foo;remote=3Dbar" >>>>>>=20 >>>>>> This second model keeps the Session-ID header value as "foo" the >>>>>> whole >>>>> time, while adding a parameter of "bar" for Bob that remains a >>>>> parameter the whole time. >>>>>> Neither Alice nor Bob are confused about which one is "their" >>>>>> UUID >>>> value. >>>>>> And it's backward-compatible with the previous kaplan-draft. >>>>>> And it's arguably easier to implement, for the common cases. >>>>>>=20 >>>>>> I *think* there was a reason someone came up with at one time as >> to >>>>>> why >>>>> it had to be swapped, but I don't remember what it is and I don't >> see >>>>> it in the draft. So I'm trying to find out why we need to do it >> the >>>>> way the draft currently has it. >>>>>>=20 >>>>>> The other topic of whether SBCs will change things is completely >>>>> orthogonal to the ordering or backwards compatibility issues, and >>>>> really shouldn't be conflated with it at all. It has nothing to >>>>> do with the solutions document, or the direction stuff, etc. >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>>=20 >>>>>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones >>>>>> >>>> wrote: >>>>>>=20 >>>>>>> Folks, >>>>>>>=20 >>>>>>> I step away for a couple of days and the floodgate opens. :) >>>>>>>=20 >>>>>>> I think it's important to understand why we proposed using a >>>>>>> two-part Session Identifier. The reason is that we have to be >> able >>>>>>> to >>>>> effectively >>>>>>> deal with things like forking, call transfer, park, bridging, >>>>> conferencing, >>>>>>> etc. >>>>>>>=20 >>>>>>> When initiating a call and using a single UUID value, that has >> the >>>>> potential >>>>>>> to go end-to-end. However, if a call is forked there are >>>>>>> multiple >>>>> "ends". >>>>>>> How do we track each of those? For proper diagnostics and >>>>> troubleshooting, >>>>>>> it would be ideal to be able to identify which devices have an >>>> issue. >>>>>>>=20 >>>>>>> Once a call has been placed, there is a Session-ID established >>>>>>> between >>>>> Alice >>>>>>> and Bob. If Alice (in one country) transfers Bob (perhaps in >>>>>>> the same >>>>> or >>>>>>> different country) to a some location in a high-toll country, >>>>>>> who pays >>>>> the >>>>>>> bill? Well, to address that, we do call transfer locally on >> PBXes. >>>>> The PBX >>>>>>> maintains control over the call and Alice would pay the bill for >>>>>>> the >>>>> call >>>>>>> transfer. But if Alice was talking to Carol before the >>>>>>> transfer, >>>>> there is a >>>>>>> Session-ID for that call. If Bob is put in communication with >>>>>>> Carol, >>>>> what >>>>>>> is the Session-ID value? Bob had one and Carol had a different >> one. >>>>> What >>>>>>> is the new ID? >>>>>>>=20 >>>>>>> It's issues like this that led us to using a two-part value. In >>>>>>> this >>>>> way, >>>>>>> we could see the call from Alice to Bob has a Session-ID {A,B}. >>>>>>> If >>>>> Alice >>>>>>> transfers the call to Carol, each device understands that the >>>>>>> Session- >>>>> ID >>>>>>> changed to {B,C}. Not only that, but intermediaries along the >> path >>>>> that >>>>>>> were not privy to signaling that resulted in this change can >>>>>>> take note >>>>> of >>>>>>> the fact the value changed. This can provide a useful >>>>>>> historical >>>>> record, >>>>>>> since previously they might see a call to Carol identified as >>>>>>> {A,C}, >>>>> but >>>>>>> then it changed to {B,C}. >>>>>>>=20 >>>>>>> This property extends quite naturally to other signaling >> scenarios, >>>>>>> as >>>>> it >>>>>>> allows one to identify a call end-to-end, but also establish >>>>>>> some relationship between other calls that shared at least one >>>>>>> UUID value >>>>> out of >>>>>>> the two. >>>>>>>=20 >>>>>>> Hadriel mentioned the desire to use the Session-ID to correlate >>>>>>> media >>>>> flows >>>>>>> and calls. That's certainly something Cisco would like to do, >> but >>>>>>> it >>>>> is not >>>>>>> the driver behind the solution. Having a valid end-to-end >>>>>>> identifier >>>>> (in >>>>>>> whatever form) allows us to do that. We're not suggesting to >>>>>>> fit the solution to meet that business use case, but rather we >>>>>>> just want a >>>>> solution >>>>>>> that allows us to properly identify calls end-to-end and we >>>>>>> recognize >>>>> that, >>>>>>> due to various service interactions in the network, these UUID >>>>>>> values >>>>> can >>>>>>> change. >>>>>>>=20 >>>>>>> I would hope that UUID values will not change to the extent that >>>>>>> SBCs >>>>> change >>>>>>> them for business reasons. It would certainly defeat the point. >>>>> Hadriel >>>>>>> might be right that an SBC vendor might manipulate those values >> at >>>>>>> the request of a customer, but I would hope said customer >>>>>>> appreciates that >>>>> such >>>>>>> a request effectively breaks the end-to-end model. We can't do >>>>>>> much >>>>> about >>>>>>> that if they do go down that path. >>>>>>>=20 >>>>>>> As for backward-compatibility, the simplest approach (IMO) is to >>>>>>> just >>>>> use a >>>>>>> header value not already in use. Originally, we had proposed >>>>>>> Session- >>>>> UUID. >>>>>>> That was changed at the request of the group to be Session-ID. >>>>> However, >>>>>>> when we have a two UUID solution interacting with a one-UUID >>>>>>> solution, >>>>> we >>>>>>> immediately face some challenges. >>>>>>>=20 >>>>>>> What happens if an older system sends this: >>>>>>> Session-ID: X >>>>>>> But then receives this: >>>>>>> Session-ID: Y; remote=3DX >>>>>>>=20 >>>>>>> Does this break things? If so, how do current implementations >> deal >>>>> with >>>>>>> such things as mid-call transfers that happen on a PBX like the >> one >>>>>>> I described above? >>>>>>>=20 >>>>>>> We could switch the order like this: >>>>>>> Session-ID: X; remote=3DY >>>>>>>=20 >>>>>>> However, that does not work for similar reasons. If we have a >> call >>>>> transfer >>>>>>> where Alice transfers a call with Bob to Carol, then each has a >>>>> different >>>>>>> idea about what the proper value is for the first position. >>>>>>>=20 >>>>>>> Originally, the proposed solution did not indicate position >>>>> information and >>>>>>> just had single UUID values going in each direction. We then >>>>>>> proposed >>>>> a >>>>>>> concatenated string (X:Y). However, that presented the same >> issues >>>>>>> for >>>>> the >>>>>>> call transfer case, so we indicate values by position (sender's >>>>>>> value first), so it is clear what value the receive thinks the >>>>>>> remote end >>>>> has for >>>>>>> the local end. It might be wrong, but that will be corrected in >>>>>>> the following response. (Intermediaries can take note of the >>>>>>> change.) >>>>>>>=20 >>>>>>> So, that's why we are where we are. There has been an effort to >>>>> maintain >>>>>>> backward-compatibility, but there are challenges in meeting that >>>>>>> requirement. Where it falls short, we do not know: we've not >> been >>>>> told >>>>>>> explicitly what the issues are. Further, if there are such >> issues, >>>>>>> we >>>>> need >>>>>>> to also understand how those would be handled in the face of >>>>>>> call >>>>> transfer >>>>>>> or "joining" a call locally on a PBX. Those are real-world >>>>>>> scenarios >>>>> that >>>>>>> we must address. >>>>>>>=20 >>>>>>> Anyway, nothing is set in stone. Anything can be changed, but I >>>>>>> would >>>>> hope >>>>>>> we can find a solution that works for the enterprise use cases >>>>>>> as well >>>>> as >>>>>>> the service provider networks. >>>>>>>=20 >>>>>>> Paul >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> insipid mailing list >>>>>>> insipid@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>>=20 >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> insipid mailing list >>>>>> insipid@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From imcilwaine@opencloud.com Thu Aug 15 08:20:43 2013 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 3DAE521E8163 for ; Thu, 15 Aug 2013 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.529 X-Spam-Level: X-Spam-Status: No, score=-4.529 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TNgYFym4Adg for ; Thu, 15 Aug 2013 08:20:38 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with SMTP id 87F1521F99EC for ; Thu, 15 Aug 2013 08:19:58 -0700 (PDT) Received: from mail-vb0-f43.google.com ([209.85.212.43]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUgzxmdnCckp+/UxrNyq/v0McO5dTTWe5@postini.com; Thu, 15 Aug 2013 08:19:58 PDT Received: by mail-vb0-f43.google.com with SMTP id h11so679443vbh.30 for ; Thu, 15 Aug 2013 08:19:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:reply-to:from:references:in-reply-to :mime-version:thread-index:date:message-id:subject:to:cc :content-type; bh=lUOtjYGsr8U3xwp0Nuv+nMM7Un8t1yzSBRvyQm/bX+Q=; b=NlQrsaZvvy/kzXcY0Kapp1xEE1EFtCHUR2dPcvpEOs5mjfknznkXxqE8f71zyH2/ov ZVkQSUWk3GN/ochglF1CjdCdmZXdn3tQKC0tFbj3WiDT5p46SLEo2gg+j01WEY5WSmQ2 L2PGxM1sm9WGgQRanmEHl5z6xblBNPETCZIWrWDsuDPuUpyaaqShvIbSc2r1dlhaKsvQ ZUVmAQe+JeA2FEstWkzyF+GVKbaOPHpyrGtFPnJ/1EDbT1jSaY+CTDvu1MCImh0r3kPV nuVCwfWO8R3IevS83RbpptXG0w4IrVzQZHYpa/gw5ihh4+lEBb9K6jYxlvAwHOLCeOil n2xg== X-Gm-Message-State: ALoCoQmsh3KRCroOgB0P8N5rVoSHgIaJpzbAhXnda319S8L2dqUhWxad8umieLhkjUWZwAlM3ESY5QVAxraOR7VluN0qf3p+EOVUtpD3F+B5apvsCGiz6eIIzR1hvHWhe9AKcOYVYZ34xlAnuBp5R/lOXzMSCXYdIw== X-Received: by 10.58.219.68 with SMTP id pm4mr498863vec.49.1376579993075; Thu, 15 Aug 2013 08:19:53 -0700 (PDT) X-Received: by 10.58.219.68 with SMTP id pm4mr498856vec.49.1376579992906; Thu, 15 Aug 2013 08:19:52 -0700 (PDT) From: Iain McIlwaine References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <942d8175ef27dbb82e58f70faead1038@mail.gmail.com> <5acd5207a04d040a0569fbb581b932c1@mail.gmail.com> <888D13B0-84DF-419C-8979-9563ACE18FB7@oracle.com> <001601ce993f$e8ae00b0$ba0a0210$@co.in> <50E3B10B-4D80-44E4-B104-5D934CF25E7F@oracle.com> In-Reply-To: <50E3B10B-4D80-44E4-B104-5D934CF25E7F@oracle.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKQJk1zw7AyhdJqEBmNnemgICOl9WAocGH+sBuC/YTAFBubF6ATyubeyWx0d9AA== Date: Thu, 15 Aug 2013 16:19:51 +0100 Message-ID: <58394fb8162dae76ece155d4fa95cc6f@mail.gmail.com> To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org, Parthasarathi R Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iain.mcilwaine@opencloud.com List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 15:20:43 -0000 Yeah that Appendix seemed to miss a few people around me too, I only spotted it by using the rather handy revision compare tool. So the problem with the GSMA selected ad-hoc conf mechanism is that the conferencing server is responsible for inviting Bob & Carol (who are already in a session with Alice) to the conference and to replace the existing session with Alice. Trouble is, the Replaces-Header has the to/from tags that Alice knows and these may only be relevant between Alice and the first B2BUA. Chances are the tags Bob & Carol know will be different. Session-ID looked like a very tempting augmentation to the Replaces-Header. -iain. -----Original Message----- From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] Sent: 15 August 2013 15:19 To: iain.mcilwaine@opencloud.com Cc: Parthasarathi R; insipid@ietf.org Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility I haven't kept up with what 3GPP is planning to use this for, but if it's the resource-list thing from a couple years ago, I think that wasn't going to work right either. In the old kaplan session-id draft it talked about such correlation in 3GPP and explains why session-id is not really a solution for that. This was put in the end of the Appendix in old draft: http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-03#appendix-A. 1 Somehow that last page or two got cut off in the kaplan draft being submitted right now for Informational, which is super-annoying. :( -hadriel On Aug 15, 2013, at 8:32 AM, Iain McIlwaine wrote: > "> Ahh right - it's been a while since I read that spec, and it's >> painfully long and complicated. :)" > > Yes, yes it is indeed..... > > So I guess this is one scenario where the syntax doesn't quite work > without additional logic of re-INVITE/UPDATE. However, Hadriel does > make a good point in asking what this header would be used for. > > The predecessor Session-ID draft managed to sneak into 24.229 as a > means of assisting with the IR.92 approved ad-hoc multi party > conference (big thanks to GSMA for selecting the trickiest multi party > implementation method there). Now I know this is way out of the scope > of the current discussions but if the cap fits folks will wear it. (In > the interest of full disclosure, this is actually the angle that got > me interested in this draft rather than the troubleshooting aspect). > > Naturally this puts my concern a tad lower in the priority list. > > Kind Regards, > Iain > > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 14 August 2013 23:45 > To: 'Hadriel Kaplan'; iain.mcilwaine@opencloud.com > Cc: insipid@ietf.org > Subject: RE: [Insipid] Proposed INSIPID solution and backward > compatibility > > Hadriel/Iain, > > I agree with Iain that end-to-end session-id is not possible with > eSRVCC (3GPP 24.237) in IMS environment. My understanding is that ATCF > is introduced just to avoid the end-to-end signaling callflow. > > The callflow is as follows: > > 1) Session is established between Alice & Bob with session > id=foo;remote=bar > > 2) Alice moved from PS to CS. > 3) MSC starts new INVITE with session-id=zab > 4) ATCF has to send 200 OK to MSC with session-id=zab;remote=bar > 5) ATCF shall Re-INVITE with session-id=zab;remote=bar towards SCC-AS > 6) SCC-AS sends 200 OK with session-id=zab;remote=bar > > Please note that bob is not aware of session-id update of "foo" to "zab". > There is no end-to-end session-id in these callflows. > > Thanks > Partha > > > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: Wednesday, August 14, 2013 10:15 PM >> To: iain.mcilwaine@opencloud.com >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Proposed INSIPID solution and backward >> compatibility >> >> >> Ahh right - it's been a while since I read that spec, and it's >> painfully long and complicated. :) >> >> So in the case of the MSC performing a continuity transfer on behalf >> of Bob, I essentially think of it as a INVITE with Replaces model, >> except without the Replaces info. The ATCF is like a PBX, and the >> scenario is almost like a PBX barge-in feature, from a 50k-foot view. >> And just like a barge-in, if you really want all sides to get updated >> to have a consistent Session-ID param value, it might require a >> re-INVITE/UPDATE be sent everywhere. >> >> With the legacy way of doing Session-ID but with also a remote param, >> it could be like this: >> >> Alice INVITE through ATCF to Bob = "Session-ID:foo" >> Bob 18x through ATCF to Alice = "Session-ID:foo;remote=bar" >> >> [ Bob loses PS and MSC triggers call continuity ] >> >> MSC INVITE to ATCF = "Session-ID:zab" >> ATCF 200 to MSC = "Session-ID:zab;remote=foo" >> ATCF 200 to Alice = "Session-ID:foo;remote=zab" >> >> Or depending on state of call and also depending on logic of ATCF, >> ATCF could instead send back something else and eventually sends re- >> INVITE/UPDATE to both parties, to create a consistent parameter value. >> >> I have a hard time believing an IMS provider would want to send SIP >> re- INVITEs across their peering connections to the other carriers >> the call came in from, just because their local UE switched from >> VoLTE to 3GPP or whatever. Nor do I think the other carriers want to >> get such >> re- INVITEs from them. >> >> With regards to "it invalidates the Session-ID as a meaningful e2e >> tag", yes it does - the parameter might be consistent (eventually), >> but the header value itself isn't. But the real question is what >> would the Session-ID be *used for* - just having an e2e tag is not an > end goal... >> there has to be some purpose to it. With the original Session-ID >> draft, the purpose was troubleshooting, and when we debated whether >> to send re-INVITE/UPDATEs everywhere in order to handle the more >> complicated scenarios, the consensus was that no one wanted to do >> that (for obvious reasons). >> >> I think what some people have in mind is simply a value that is >> consistent within their local domain. But that's a horse of a >> different color, I think. >> >> -hadriel >> >> >> On Aug 14, 2013, at 10:54 AM, Iain McIlwaine >> wrote: >> >>> The scenario in question is for an IMS access network transfer >>> during >> call >>> setup as described by 3GPP 24.237. After receiving the INVITE and >>> replying with a 18x (and thus establishing an early dialog) Bob's >> access >>> network changes. >>> >>> In the case of a PS-CS transfer an MSC-S/MGCF will perform the SIP >>> signalling on Bob's behalf and thus have no access to what the >> previous >>> Session-ID was. The MSC-S/MGCF initiates a call for Bob which is >>> reconciled at the Transfer AS using 3PCC & Access Transfer >> mechanisms. >>> >>> In this scenario and using the proposed syntax, both Alice and Bob >> (well, >>> Bob's MSC-S/MGCF) have an equal right to assert their UUID first as >>> they've both created the INVITE. >>> >>> How this is handled in the Transfer AS (i.e. the ATCF or the SCC) >> doesn't >>> bother me so much as they're just 3PCC/B2BUAs, what it does do >> however is >>> invalidate the Session-ID as a meaningful end 2 end tag for any >> service >>> provider offering access transfer. >>> >>> Again, could be I'm misinterpreting something so happy to be >> corrected. >>> >>> Cheers, >>> Iain >>> >>> >>> >>> >>> -----Original Message----- >>> From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] >>> Sent: 14 August 2013 15:22 >>> To: iain.mcilwaine@opencloud.com >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>> compatibility >>> >>> >>> I think it depends on how the "Transfer AS" is going to work, and >> what you >>> think "manipulation" means or why it matters. How is it any >> different >>> than a PBX call transfer scenario? Is the problem you're describing >> a >>> real transfer where Bob just didn't send a 200 yet, or do you really >> mean >>> a call-forwarding scenario, with early media? >>> >>> If you just mean the equivalent of call-forwarding type thing, where >> the >>> forwarding app server sends a 18x to generate "please wait while we >> locate >>> your party" media, then that's still ok (I think). Nothing ever said >> the >>> header parameter value couldn't change between responses. So it >> would be >>> like this: >>> >>> Alice INVITE through AS to Bob = "Session-ID:foo" >>> Bob 18x through AS to Alice = "Session-ID:foo;remote=bar" >>> Bob INVITE through AS to Carol = "Session-ID:foo" >>> Carol 18x/2xx through AS to Bob = "Session-ID:foo;remote=qux" >>> Bob 2xx through AS to Alice = "Session-ID:foo;remote=qux" >>> >>> >>> If you mean a real call transfer, it's going to be uglier: >>> >>> Alice INVITE through PBX to Bob = "Session-ID:foo" >>> Bob 18x through PBX to Alice = "Session-ID:foo;remote=bar" >>> Bob INVITE through PBX to Carol = "Session-ID:zab" >>> Carol 18x/2xx through PBX to Bob = "Session-ID:zab;remote=qux" >>> [ Bob presses some transfer button thingy, PBX transfers the >>> Alice-Bob/Bob-Carol calls to be Alice-Carol ] PBX can now send 2xx >>> to Alice of = "Session-ID:foo;remote=qux" >>> Or PBX can send 2xx to Alice of "Session-ID:foo;remote=zab", and >>> send re-INVITE/UPDATE to Carol of "Session-ID:zab;remote=foo". >>> >>> I personally think sending re-INVITE/UPDATEs for this thing is going >> to >>> cause headaches, but if that's what people want, they can do it. >>> >>> Clearly the PBX has to keep track of these Session-IDs separately on >> each >>> call leg for some of these scenarios, but that's hardly a big deal - >> it's >>> *already* keeping track of these as separate call-legs with a bunch >> of SIP >>> state, because by definition it's acting as a SIP B2BUA with two >> separate >>> SIP dialogs. >>> >>> -hadriel >>> >>> >>> On Aug 14, 2013, at 5:20 AM, Iain McIlwaine >> >>> wrote: >>> >>>> Folks, >>>> >>>> I see a lot of discussion for enterprise transfer scenarios but I >>>> would like to highlight a problematic use case to gauge your >> opinions. >>>> >>>> Using Hadriel's method which designates local:remote of the UUID >>>> according to the issuer of the INVITE I can see a potential problem >>>> for Access Transfer when the party being transferred is in the >>> "proceeding" state. >>>> So: >>>> >>>> Alice INVITE - "Transfer AS" - Bob: "Session-ID:foo" >>>> Bob 1XX - "Transfer AS" - Alice "Session-ID:foo;remote=bar" >>>> Bob' INVITE - "Transfer AS" Session-ID:foo' >>>> >>>> Note: the "Transfer AS" can be an ATCF or an SCC. >>>> >>>> We can see in this case using Hadriel's syntax we now require the >>>> Transfer AS to perform manipulation of the Session-ID header which >>>> runs contrary to a stated objective of no intermediary meddling of >> the >>> header. >>>> >>>> If we revert to interpreting the local:remote syntax being within >> the >>>> context of the receiver I believe we would avert this situation. >>>> >>>> Of course it could be I've misunderstood something so happy to be >>>> shown the light. >>>> >>>> Kind regards, >>>> Iain >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Paul E. Jones >>>> Sent: 13 August 2013 23:34 >>>> To: 'Hadriel Kaplan' >>>> Cc: insipid@ietf.org; 'Laura Liess' >>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>> compatibility >>>> >>>> Hadriel, >>>> >>>>> I can't tell if you seriously believe the new mechanism is going >>>>> to work end-to-end across all domains, or if you just mean >>>>> end-to-end within a domain (like within the call-center). I don't >>>>> mean that >> in >>>>> a negative way >>>>> - I just mean I don't understand how you mean the words "end-to- >> end". >>>> >>>> I seriously mean end-to-end. Assuming service providers did not >> block >>>> passage of an INVITE containing a new UUID value, then we can >>>> always have an end-to-end value. As an "end" changes, so does the >>>> end-to- >> end >>> value. >>>> That's OK. >>>> >>>>> I seriously doubt this thing is going to achieve any more than the >>>>> legacy draft did in terms of true end-to-end across-the-world type >>>>> thing. In fact it may even do less. >>>> >>>> The only reason it would not is if: >>>> 1) One endpoint does not support the procedures (can't help that) >>>> 2) Something prevents a new INVITE from going to one endpoint (like >> an >>>> SBC) >>>> >>>> Otherwise, it would work. >>>> >>>>> When I make a call from my cell phone through my mobile provider, >>>>> through N number of carriers, to an Enterprise call-center >> somewhere >>>>> in Timbuktu, I have a hard time believing all the carriers and >> mobile >>>>> providers want to get back and process a re-INVITE each and every >>>>> time the call gets moved around inside the call-center's internal >> PBX >>>>> infrastructure. They rarely get that today, and I don't see them >>>> changing in the future to do so... >>>>> for what benefit? What use is it to update all the SIP systems >> along >>>>> the path, as well as my cell phone, with a new Session-ID value >> just >>>>> because the call got parked/unparked or internally transferred >> inside >>>> PBX/ACD/etc. >>>>> systems in a call-center somewhere? >>>>> >>>>> Some call centers move the media around almost a dozen times per >> call. >>>>> You really think the rest of the world wants to get a dozen >>>>> re-INVITEs, for no benefit? The SBCs aren't answering the re- >> INVITEs >>>>> locally today to hide the identity of who/what it gets moved >>>>> around to >>>>> - that we already do even when we forward the re-INVITEs - we're >>>>> answering them locally because the service providers don't want >>>>> nor need those re-INVITEs. It's just extra processing load, log >> entries, >>>>> and things that can go wrong; with no added benefit. >>>> >>>> I really cannot do anything about these "noise" issues. I recognize >>>> that in practice, much of the use of SIP has been absolutely >> nothing >>>> more than a PSTN replacement. It has been merely a means of moving >> from >>> TDM to IP. >>>> I'm glad it happened, but it's more than unfortunate if that's all >> we >>>> accomplish. >>>> >>>> As I look to doing more interesting things where I have different >>>> applications running in various devices connected to different >>>> networks and associated to my "phone" where I can utilize all of >> them >>>> as a part of a "call", I see value in having this end-to-end >>>> identifier for even this more complex arrangement. However, I can >>>> understand if service providers do not take an active interest in >>>> this. From a research perspective, these more advanced >> communication >>>> systems are interesting. From a business perspective, there is a >>>> question about ROI for carriers. I get >>>> that: >>>> there's no money in doing much more than providing the most basic >>>> voice service, and even that service has a very small profit margin. >>>> However, progress, capabilities, functionality, and improvements in >>>> the way we work and communicate should go forward, and they are. >>>> Already, we see a number of alternatives like Skype, Facetime, >> Google >>>> Hangouts, etc. and I expect functionality will become much more >>>> interesting, with a wider mix of multimedia applications in use at >> once. >>>> >>>> Bottom line is that we should not constrain a system, but try to >> make >>>> it as flexible as possible. It might not work everywhere, but >>>> don't constrain ourselves to the most basic voice call flow. >>>> >>>> Paul >>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Aug 2, 2013, at 11:48 AM, Paul E. Jones >>>> wrote: >>>>> >>>>>> Larua, >>>>>> >>>>>> So in effect, the current deployments are not end-to-end, but >>>>>> edge-to- >>>>> edge somewhere. I can appreciate that, but it does make it more >>>>> challenging to try to work with when we go all the way end-to-end. >>>>>> >>>>>> Paul >>>>>> >>>>>> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >>>>>> Sent: Friday, August 02, 2013 4:47 AM >>>>>> To: Paul E. Jones >>>>>> Cc: insipid@ietf.org >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>> >>>>>> Paul, >>>>>> >>>>>> As I said, we never used the old Session-ID to do more than >>>>>> correlate >>>>> bothe legs of the same dialog. So in your example we have: >>>>>> - Alice to Bob: Session-ID A >>>>>> - Bob to Carol: Session-ID B >>>>>> - Alice to Carol: Session-ID C >>>>>> >>>>>> There is no correlation between them. We just correlate both legs >> of >>>>>> the >>>>> same dialog across the SBC between Alice and Bob. >>>>>> >>>>>> Thank you >>>>>> Laura >>>>>> >>>>>> >>>>>> >>>>>> 2013/8/1 Paul E. Jones Laura, >>>>>> >>>>>> The example I show below is a real call center example. I show >>>>>> use of >>>>> the old session ID. Tell me how that works. Forget about the new >>>>> solution for the moment. >>>>>> >>>>>> If you say it will not work, then I'm not sure how we can make >>>>>> something >>>>> work with something that does not work. If there is a way to make >>>>> this work, then we can try to figure out how to interwork with it. >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> >>>>>> From: Laura Liess >>>>>> Sent: Thu Aug 01 11:51:26 EDT 2013 >>>>>> >>>>>> To: "Paul E. Jones" >>>>>> Cc: insipid@ietf.org >>>>>> >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>> >>>>>> Paul, >>>>>> We use the old Session-ID only accross SBCs, to correlate both >> legs >>>>>> of >>>>> the same dialog. And it works fine for this use case. We never >> tried, >>>>> intend or were required to do more with it. >>>>>> We are not against the new mechanism, we just want it to >>>>>> interwork with >>>>> the old one which we have in thousands of customer end devices. If >> it >>>> does, >>>>> we can add new end devices and application servers which support >> the >>>>> new Session-ID. Otherwise we can't. >>>>>> >>>>>> Let's see if it works when we keep the UUID order unchanged, as >>>>>> Hadriel >>>>> proposed. >>>>>> >>>>>> Thank you >>>>>> Laura >>>>>> >>>>>> >>>>>> 2013/8/1 Paul E. Jones Laura, >>>>>> >>>>>> I assert that old draft will not work for some "real-world" calls. >>>>> Calls do get manipulated in enterprise environments and call >> centers >>>>> for billing purposes, privacy reasons, etc. >>>>>> >>>>>> Consider a common case: if you call into a call center and the >> agent >>>>> puts you on hold while they transfer you to a specialist (transfer >>>>> out of consultation), for example, your SIP UA does not receive a >>>>> REFER to initiate a new call directly to the specialist. This is >>>>> handled at the call center. >>>>>> >>>>>> So rather specifically, how would this be handled (with the old >>>> draft)? >>>>>> >>>>>> 1) Alice calls Bob (Session-ID: A) >>>>>> 2) Bob puts Alice on hold and calls Carol (Session-ID: B) >>>>>> 3) Bob transfers the call from Alice to Carol using a local >> transfer >>>>> function on the PBX (Session-ID: ??) >>>>>> >>>>>> The PBX could send different values to Alice and Carol, but we >>>>>> totally >>>>> lose the end-to-end identification of the call. >>>>>> >>>>>> Alice could not send "A" to Carol, since Carol is expecting B. >>>> Likewise, >>>>> Carol cannot send "B" to Alice, since Alice is expecting "A". >> Well, >>>>> they could, and it would be no worse than our current proposal in >>>>> terms of backward-compatibility. >>>>>> >>>>>> Paul >>>>>> >>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] >> On >>>>> Behalf Of Laura Liess >>>>>> Sent: Thursday, August 01, 2013 9:13 AM >>>>>> To: insipid@ietf.org >>>>>> >>>>>> Subject: Re: [Insipid] Proposed INSIPID solution and backward >>>>> compatibility >>>>>> >>>>>> >>>>>> Hadriel's proposal works for us. >>>>>> >>>>>> Thank you >>>>>> Laura >>>>>> >>>>>> >>>>>> 2013/8/1 Hadriel Kaplan >>>>>> >>>>>> This isn't about Enterprise vs. Service-Provider, or Cisco vs. >>>>>> another >>>>> vendor. This is just about a Working Group document, and whether >> the >>>>> mechanism defined in it should change the Session-ID header value >> vs. >>>>> parameter based on direction of messages, or not. I totally get >> the >>>>> need to have a distinguishing Session-ID identifier for party-A vs. >>>> party-B. >>>>> What I don't get is why they need to change the encoding of the >>>>> Session-ID header value vs. parameter, on a message direction >> basis. >>>>>> >>>>>> In other words, today the draft has this: >>>>>> 1) Alice sends INVITE with "Session-ID: foo" >>>>>> 2) Bob sends 18x/200 with "Session-ID: bar;remote=foo" >>>>>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" >>>>>> 4) Bob sends BYE with "Session-ID: bar;remote=foo" >>>>>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" >>>>>> >>>>>> But we could instead do this: >>>>>> 1) Alice sends INVITE with "Session-ID: foo" >>>>>> 2) Bob sends 18x/200 with "Session-ID: foo;remote=bar" >>>>>> 3) Alice sends ACK with "Session-ID: foo;remote=bar" >>>>>> 4) Bob sends BYE with "Session-ID: foo;remote=bar" >>>>>> 5) Alice sends 200 with "Session-ID: foo;remote=bar" >>>>>> >>>>>> This second model keeps the Session-ID header value as "foo" the >>>>>> whole >>>>> time, while adding a parameter of "bar" for Bob that remains a >>>>> parameter the whole time. >>>>>> Neither Alice nor Bob are confused about which one is "their" >>>>>> UUID >>>> value. >>>>>> And it's backward-compatible with the previous kaplan-draft. >>>>>> And it's arguably easier to implement, for the common cases. >>>>>> >>>>>> I *think* there was a reason someone came up with at one time as >> to >>>>>> why >>>>> it had to be swapped, but I don't remember what it is and I don't >> see >>>>> it in the draft. So I'm trying to find out why we need to do it >> the >>>>> way the draft currently has it. >>>>>> >>>>>> The other topic of whether SBCs will change things is completely >>>>> orthogonal to the ordering or backwards compatibility issues, and >>>>> really shouldn't be conflated with it at all. It has nothing to >>>>> do with the solutions document, or the direction stuff, etc. >>>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>> On Aug 1, 2013, at 12:38 AM, Paul E. Jones >>>>>> >>>> wrote: >>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> I step away for a couple of days and the floodgate opens. :) >>>>>>> >>>>>>> I think it's important to understand why we proposed using a >>>>>>> two-part Session Identifier. The reason is that we have to be >> able >>>>>>> to >>>>> effectively >>>>>>> deal with things like forking, call transfer, park, bridging, >>>>> conferencing, >>>>>>> etc. >>>>>>> >>>>>>> When initiating a call and using a single UUID value, that has >> the >>>>> potential >>>>>>> to go end-to-end. However, if a call is forked there are >>>>>>> multiple >>>>> "ends". >>>>>>> How do we track each of those? For proper diagnostics and >>>>> troubleshooting, >>>>>>> it would be ideal to be able to identify which devices have an >>>> issue. >>>>>>> >>>>>>> Once a call has been placed, there is a Session-ID established >>>>>>> between >>>>> Alice >>>>>>> and Bob. If Alice (in one country) transfers Bob (perhaps in >>>>>>> the same >>>>> or >>>>>>> different country) to a some location in a high-toll country, >>>>>>> who pays >>>>> the >>>>>>> bill? Well, to address that, we do call transfer locally on >> PBXes. >>>>> The PBX >>>>>>> maintains control over the call and Alice would pay the bill for >>>>>>> the >>>>> call >>>>>>> transfer. But if Alice was talking to Carol before the >>>>>>> transfer, >>>>> there is a >>>>>>> Session-ID for that call. If Bob is put in communication with >>>>>>> Carol, >>>>> what >>>>>>> is the Session-ID value? Bob had one and Carol had a different >> one. >>>>> What >>>>>>> is the new ID? >>>>>>> >>>>>>> It's issues like this that led us to using a two-part value. In >>>>>>> this >>>>> way, >>>>>>> we could see the call from Alice to Bob has a Session-ID {A,B}. >>>>>>> If >>>>> Alice >>>>>>> transfers the call to Carol, each device understands that the >>>>>>> Session- >>>>> ID >>>>>>> changed to {B,C}. Not only that, but intermediaries along the >> path >>>>> that >>>>>>> were not privy to signaling that resulted in this change can >>>>>>> take note >>>>> of >>>>>>> the fact the value changed. This can provide a useful >>>>>>> historical >>>>> record, >>>>>>> since previously they might see a call to Carol identified as >>>>>>> {A,C}, >>>>> but >>>>>>> then it changed to {B,C}. >>>>>>> >>>>>>> This property extends quite naturally to other signaling >> scenarios, >>>>>>> as >>>>> it >>>>>>> allows one to identify a call end-to-end, but also establish >>>>>>> some relationship between other calls that shared at least one >>>>>>> UUID value >>>>> out of >>>>>>> the two. >>>>>>> >>>>>>> Hadriel mentioned the desire to use the Session-ID to correlate >>>>>>> media >>>>> flows >>>>>>> and calls. That's certainly something Cisco would like to do, >> but >>>>>>> it >>>>> is not >>>>>>> the driver behind the solution. Having a valid end-to-end >>>>>>> identifier >>>>> (in >>>>>>> whatever form) allows us to do that. We're not suggesting to >>>>>>> fit the solution to meet that business use case, but rather we >>>>>>> just want a >>>>> solution >>>>>>> that allows us to properly identify calls end-to-end and we >>>>>>> recognize >>>>> that, >>>>>>> due to various service interactions in the network, these UUID >>>>>>> values >>>>> can >>>>>>> change. >>>>>>> >>>>>>> I would hope that UUID values will not change to the extent that >>>>>>> SBCs >>>>> change >>>>>>> them for business reasons. It would certainly defeat the point. >>>>> Hadriel >>>>>>> might be right that an SBC vendor might manipulate those values >> at >>>>>>> the request of a customer, but I would hope said customer >>>>>>> appreciates that >>>>> such >>>>>>> a request effectively breaks the end-to-end model. We can't do >>>>>>> much >>>>> about >>>>>>> that if they do go down that path. >>>>>>> >>>>>>> As for backward-compatibility, the simplest approach (IMO) is to >>>>>>> just >>>>> use a >>>>>>> header value not already in use. Originally, we had proposed >>>>>>> Session- >>>>> UUID. >>>>>>> That was changed at the request of the group to be Session-ID. >>>>> However, >>>>>>> when we have a two UUID solution interacting with a one-UUID >>>>>>> solution, >>>>> we >>>>>>> immediately face some challenges. >>>>>>> >>>>>>> What happens if an older system sends this: >>>>>>> Session-ID: X >>>>>>> But then receives this: >>>>>>> Session-ID: Y; remote=X >>>>>>> >>>>>>> Does this break things? If so, how do current implementations >> deal >>>>> with >>>>>>> such things as mid-call transfers that happen on a PBX like the >> one >>>>>>> I described above? >>>>>>> >>>>>>> We could switch the order like this: >>>>>>> Session-ID: X; remote=Y >>>>>>> >>>>>>> However, that does not work for similar reasons. If we have a >> call >>>>> transfer >>>>>>> where Alice transfers a call with Bob to Carol, then each has a >>>>> different >>>>>>> idea about what the proper value is for the first position. >>>>>>> >>>>>>> Originally, the proposed solution did not indicate position >>>>> information and >>>>>>> just had single UUID values going in each direction. We then >>>>>>> proposed >>>>> a >>>>>>> concatenated string (X:Y). However, that presented the same >> issues >>>>>>> for >>>>> the >>>>>>> call transfer case, so we indicate values by position (sender's >>>>>>> value first), so it is clear what value the receive thinks the >>>>>>> remote end >>>>> has for >>>>>>> the local end. It might be wrong, but that will be corrected in >>>>>>> the following response. (Intermediaries can take note of the >>>>>>> change.) >>>>>>> >>>>>>> So, that's why we are where we are. There has been an effort to >>>>> maintain >>>>>>> backward-compatibility, but there are challenges in meeting that >>>>>>> requirement. Where it falls short, we do not know: we've not >> been >>>>> told >>>>>>> explicitly what the issues are. Further, if there are such >> issues, >>>>>>> we >>>>> need >>>>>>> to also understand how those would be handled in the face of >>>>>>> call >>>>> transfer >>>>>>> or "joining" a call locally on a PBX. Those are real-world >>>>>>> scenarios >>>>> that >>>>>>> we must address. >>>>>>> >>>>>>> Anyway, nothing is set in stone. Anything can be changed, but I >>>>>>> would >>>>> hope >>>>>>> we can find a solution that works for the enterprise use cases >>>>>>> as well >>>>> as >>>>>>> the service provider networks. >>>>>>> >>>>>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 hadriel.kaplan@oracle.com Sat Aug 17 07:08:35 2013 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 33DC911E8122 for ; Sat, 17 Aug 2013 07:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5Gica5BKM+l for ; Sat, 17 Aug 2013 07:08:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6E59411E8124 for ; Sat, 17 Aug 2013 07:08:28 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7HE8Q5a025736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Aug 2013 14:08:27 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HE8QAI018254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Aug 2013 14:08:26 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HE8QTw018251 for ; Sat, 17 Aug 2013 14:08:26 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Aug 2013 07:08:26 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 17 Aug 2013 10:08:25 -0400 To: "insipid@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [Insipid] 3pcc INSIPID backwards-compat call flows 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, 17 Aug 2013 14:08:35 -0000 Howdy, I was tasked with providing example call flows for a = backwards-compatible Session-ID mechanism, for the call flows in the = current draft-ietf-insipid-session-id-02. =20 For all the email call-flows, a syntax of "{X;Y}" means the Session-ID = header value is 'X', while the Session-ID header parameter is 'Y'. The = parameter can change within a dialog, including becoming empty/no-value = again, while the Session-ID value cannot change. For all the email call-flows, the Section heading from the current draft = is used, along with a copy of the intro text, to help give context. The = intro text has not been changed. The call flows have been updated to = show the new "{X;Y}" values, and in some cases additional text has been = added below the call flow to explain specific events. This email covers the 3PCC call flow, and the 100 Trying call flow. = --------------------------------------------------------------------------= - 9.7. Basic 3PCC for two UAs External entity sets up call to both Alice and Bob for them to talk to each other. Session ID --- Alice B2BUA Bob Carol | | | {X} |<----INVITE-----| | {X;A} |-----200 OK---->| | {X} | |----INVITE----->| {X;B} | |<---200 OK------| F1 {X;B} |<-----ACK-------| | {X;B} | |------ACK------>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRTP=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| Figure 8 - 3PCC initiated call between Alice and Bob F1 - Note that at this point Alice gets a new Session-ID parameter from = the B2BUA, and this replaces the 'A' she had previously generated. The = Session-ID value itself of 'X' does not change. = --------------------------------------------------------------------------= - 9.8.1. Session ID Handling in a 100 Trying SIP Response The following 100 Trying response is taken from an existing RFC, from =20 [RFC5359] Section 2.9 ("Call Forwarding - No Answer"). Session ID Alice SIP Server Bob-1 Bob-2 | | | | {A} |----INVITE----->| | | {A} | |---INVITE---->| | {A} |<--100 Trying---| | | {A;B1} | |<-180 Ringing-| | {A;B1} |<--180 Ringing--| | | | | | | | *Request Timeout* | | | | | {A;B1} | |---CANCEL---->| | {A;B1} | |<--200 OK-----| | {A;B1} | |<---487-------| | {A;B1} | |---- ACK ---->| | | | | | F1 {A} |<-181 Call Fwd--| | | | | | | {A} | |------------------INVITE------>| {A;B2} | |<----------------180 Ringing---| F2 {A;B2} |<-180 Ringing---| | | {A;B2} | |<-----------------200 OK ------| {A;B2} |<--200 OK-------| | | {A;B2} |----ACK-------->| | | {A;B2} | |------------------ACK--------->| | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Both way RTP = Established =3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | {A;B2} |----BYE-------->| | | {A;B2} | |--------------------BYE------->| {A;B2} | |<------------------200 OK------| {A;B2} |<--200 OK-------| | | | | | | Figure 9 - Session ID in the 100 Trying and CANCEL Messaging F1 - Note that at this point Alice gets no Session-ID parameter from the = SIP Server, while in a previous 180 there was a 'B1'. Alice updates her = stored Session-ID parameter to be empty. F2 - Note that at this point Alice gets a new Session-ID parameter from = the SIP Server of 'B2'. Alice updates her stored Session-ID parameter = to be 'B2'. -hadriel From hadriel.kaplan@oracle.com Sat Aug 17 07:08:57 2013 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 654B311E8125 for ; Sat, 17 Aug 2013 07:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv6qOdoD-8sX for ; Sat, 17 Aug 2013 07:08:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFED11E812B for ; Sat, 17 Aug 2013 07:08:47 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7HE8lm2025779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Aug 2013 14:08:47 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HE8k0K018625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Aug 2013 14:08:47 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HE8klq010786 for ; Sat, 17 Aug 2013 14:08:46 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Aug 2013 07:08:46 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 17 Aug 2013 10:08:45 -0400 To: "insipid@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [Insipid] Call-transfer INSIPID backwards-compat call flows 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, 17 Aug 2013 14:08:57 -0000 Howdy, This email is about the call-transfer call flows in the draft. = --------------------------------------------------------------------------= - 9.1. Basic Session ID Construction with 2 UUIDs Session ID --- Alice B2BUA Bob Carol {A} |----INVITE----->| | {A} | |----INVITE----->| {A;B} | |<---200 OK------| {A;B} |<---200 OK------| | {A;B} |------ACK------>| | {A;B} | |------ACK------>| |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRTP=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| Figure 1 - Session ID Creation when Alice calls Bob = --------------------------------------------------------------------------= - 9.2. Basic Call Transfer using REFER =46rom the example built within Section 9.1 (the basic session ID establishment), we proceed to this 'Basic Call Transfer using REFER' example. Session ID --- Alice B2BUA Bob Carol | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRTP=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | {A;B} | |<---reINVITE----| | {A;B} |<---reINVITE----| (puts Alice on Hold) | {A;B} |-----200 OK---->| | | {A;B} | |-----200 OK---->| | {A;B} | |<-----ACK-------| | {A;B} |<-----ACK-------| | | | | | | F1 {A;B} | |<----REFER------| | {A;B} |<----REFER------| | | {A;B} |-----200 OK---->| | | {A;B} | |-----200 OK---->| | {A;B} |-----NOTIFY---->| | | {A;B} | |-----NOTIFY---->| | {A;B} | |<----200 OK-----| | {A;B} |<----200 OK-----| | | | | | | F2 {A} |-----INVITE---->| | {A} | |-----INVITE-------------------->| {A;C} | |<----200 OK---------------------| {A;C} |<----200 OK-----| | {A;C} |------ACK------>| | {A;C} | |------ACK---------------------->| | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D>| | | | | {A;B} |-----NOTIFY---->| | | {A;B} | |-----NOTIFY---->| | {A;B} | |<----200 OK-----| | {A;B} |<----200 OK-----| | | {A;B} | |<-----BYE-------| | {A;B} |<-----BYE-------| | | {A;B} |-----200 OK---->| | | {A;B} | |-----200 OK---->| | | | | | Figure 2 - Call Transfer using REFER F1 - the REFER request uses a Session-ID header field of {A;B}, but the = Refer-To header contains the Session-ID for the new one to be created = with INVITE with Replaces. Per the legacy kaplan-draft, that Refer-To = value would be the session to-be-replaced, i.e. the Session-ID Bob = already has with Carol. IF that's followed, then F2 would be {C} = instead of {A}. But nothing "breaks" if instead Bob sends a Refer-To = with the same Session-ID value Bob has with Alice - i.e, it's ok for = this to be "A" so that F2 becomes {A} instead, as shown above. F2 - as noted above, the value shown is {A}, but it could be {C} instead = - or whatever Bob puts in the F1 REFER's Refer-To header. = --------------------------------------------------------------------------= - 9.3. Basic Call Transfer using reINVITE =46rom the example built within Section 9.1 (the basic session ID establishment), we proceed to this 'Basic Call Transfer using reINVITE' example. Alice is talking to Bob. Bob pushes a button on his phone to transfer Alice to Carol via the B2BUA (using reINVITE). Session ID --- Alice B2BUA Bob Carol | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DRTP=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| | | | | | {A;B} | |<---reINVITE----| | {A;B} | |-----200 OK---->| | {A;B} | |<-----ACK-------| | | | | | {A} | |-----INVITE-------------------->| {A;C} | |<----200 OK---------------------| {A;C} | |------ACK---------------------->| | | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D>| | | | | {A;B} | |<-----BYE-------| | {A;B} | |-----200 OK---->| | | | | | Figure 3 - Call transfer using reINVITE Note: I don't know why this example in the draft uses a re-INVITE as a = transfer action. The paragraph says Bob pushes a button, but button = pushes aren't sent in re-INVITEs. They're either sent in RTP = (RFC2833/4733) or as INFO or as KPML or whatever. Not re-INVITEs. = --------------------------------------------------------------------------= - 9.9. Session ID in an out-of-dialog REFER Transaction The following call-flow was extracted from Section 6.1 of [RFC5589] ("Successful Transfer"), with the only changes being the names of the UAs to maintain consistency within this document. Alice is the transferee Bob is the transferer and Carol is the transfer-target Session ID Bob Alice Carol | | | {A} |<-----INVITE--------| | {A;B} |------200 OK------->| | {A;B} |<------ACK----------| | | | | {A;B} |--INVITE {hold}---->| | {A;B} |<-200 OK------------| | {A;B} |--- ACK ----------->| | | | | F1 {A} |--REFER------------>|(Target-Dialog:Carol)| {A;X} |<-202 Accepted------| | | | | {A;X} || | | | | F2 {A} | |--INVITE------------>| {A;C} | |<-200 OK-------------| {A;C} | |---ACK-------------->| | | | {A;X} |<--NOTIFY {200 OK}--| | {A;X} |---200 OK---------->| | | | | {A;B} |--BYE-------------->| | {A;B} |<-200 OK------------| | {A;C} | |<------------BYE-----| {A;C} | |-------------200 OK->| Figure 10: Basic Transfer Call Flow F1 - exactly like the in-dialog REFER in section 9.2 earlier in this = email, this out-of-dialog REFER request uses a Session-ID header value = of {A}, but the Refer-To header contains the Session-ID for the new one = to be created by Alice with a new INVITE. Per the legacy kaplan-draft, = that Refer-To value would be the session to-be-replaced, i.e. the = Session-ID Bob already has with Carol. If that's followed, then F2 = would be {C} instead of {A}. But nothing "breaks" if instead Bob sends = a Refer-To with the same Session-ID value Bob has with Alice - i.e, it's = ok for this to be "A" so that F2 becomes {A} instead, as shown above. F2 - as noted above, the value shown is {A}, but it could be {C} instead = - or whatever Bob puts in the F1 REFER's Refer-To header. -hadriel= From hadriel.kaplan@oracle.com Sat Aug 17 07:09:31 2013 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 0A0CF11E8125 for ; Sat, 17 Aug 2013 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGYHE0kcuLqu for ; Sat, 17 Aug 2013 07:09:22 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id AB18A11E8122 for ; Sat, 17 Aug 2013 07:09:22 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7HE9Fk3011690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Aug 2013 14:09:17 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HE9F1D011199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Aug 2013 14:09:15 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HE9E2g012582 for ; Sat, 17 Aug 2013 14:09:14 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Aug 2013 07:09:14 -0700 From: Hadriel Kaplan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5EE2A3AF-4AA0-44A5-BFC2-642F24367AFB@oracle.com> Date: Sat, 17 Aug 2013 10:09:14 -0400 To: "insipid@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: [Insipid] Conference INSIPID backwards-compat call flows 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, 17 Aug 2013 14:09:31 -0000 This email is about the conferencing cases. Note that as far as I'm aware, the INSIPID requirements document does = NOT consider these call flows in-scope, in the sense that it says = they're actually separate, distinct communication sessions.=20 See section 3.2 in the requirements draft: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-08#page-4 Regardless, below are the call flows... = --------------------------------------------------------------------------= - 9.4. Single Focus Conferencing Multiple users call into a conference server (say, an MCU) to attend one of many conferences hosted on or managed by that server. Each user has to identify which conference they want to join, but this information is not necessarily in the SIP messaging. It might be done by having a dedicated address for the conference or via an IVR, as assumed in this example. Each user in this example goes through a two-step process of signaling to gain entry onto their conference call. Session ID Conference --- Alice Focus Bob Carol | | | | | | | | {A} |----INVITE----->| | | {A;M1} |<---200 OK------| | | {A;M1} |-----ACK------->| | | |<=3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D=3D>| = | | {A;M'} |<---reINVITE----| (to change the | | {A;M'} |-----200 OK---->| UUID to M') | | {A;M'} |<-----ACK-------| | | | | | | | | | | {B} | |<----INVITE-----| | {B;M2} | |-----200 OK---->| | {B;M2} | |<-----ACK-------| | | |<=3D=3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D= >| | {B;M'} | (to change the |----reINVITE--->| | {B;M'} | UUID to M') |<----200 OK-----| | {B;M'} | |------ACK------>| | | | | | | | | | {C} | |<--------------------INVITE-----| {C;M3} | |---------------------200 OK---->| {C;M3} | |<---------------------ACK-------| | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D>| {C;M'} | (to change the |--------------------reINVITE--->| {C;M'} | UUID to M') |<--------------------200 OK-----| {C;M'} | |----------------------ACK------>| Figure 4 - Single Focus Conference Bridge = --------------------------------------------------------------------------= - 9.5. Single Focus Conferencing using WebEx Alice, Bob and Carol call into same Webex conference. Session ID Conference --- Alice Focus Bob Carol | | | | |<** HTTPS *****>| | | | Transaction | | | | | | | {M} |<----INVITE-----| | | {M;A} |-----200 OK---->| | | {M;A} |<-----ACK-------| | | |<=3D=3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D>| = | | | | | | | |<** HTTPS *****>| | | | Transaction | | | | | | {M} | |-----INVITE---->| | {M;B} | |<----200 OK-----| | {M;B} | |------ACK------>| | | |<=3D=3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D= >| | | | | | | |<****************** HTTPS *****>| | | Transaction | | | | | {M} | |--------------------INVITE----->| {M;C} | |<-------------------200 OK------| {M;C} | |---------------------ACK------->| | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3DRTP=3D=3D=3D=3D=3D=3D=3D>| Figure 5 - Single Focus Webex Conference = --------------------------------------------------------------------------= - 9.6. Cascading Conference Bridge Support for the Session ID To expand conferencing capabilities requires cascading conference bridges. A conference bridge, or MCU, needs a way to identify itself when contacting another MCU. RFC 4579 [RFC4579] defines the 'isfocus' Contact: header parameter just for this purpose. Session ID --- MCU-1 MCU-2 MCU-3 MCU-4 | | | | {M'} |----INVITE----->| | | {M';J} |<---200 OK------| | | {M';J} |-----ACK------->| | | Figure 6 - MCUs Communicating Session ID UUID for Bridge Session ID --- MCU-1 MCU-2 MCU-3 MCU-4 | | | | {M'} |----INVITE----->| | | {M';J} |<---200 OK------| | | {M';J} |-----ACK------->| | | | | | | {M'} |---------------------INVITE----->| | {M';K} |<--------------------200 OK------| | {M';K} |----------------------ACK------->| | | | | | {M'} |-------------------------------------INVITE----->| {M';L} |<------------------------------------200 OK------| {M';L} |--------------------------------------ACK------->| Figure 7 - MCU Communicating Session ID UUID to More than One -hadriel From hadriel.kaplan@oracle.com Sat Aug 17 08:02:06 2013 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 18E7E21F9702 for ; Sat, 17 Aug 2013 08:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocG5wCpp5mFo for ; Sat, 17 Aug 2013 08:01:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87521F8F09 for ; Sat, 17 Aug 2013 08:01:59 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7HF1ugC017259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Aug 2013 15:01:57 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HF1tGv024765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 Aug 2013 15:01:55 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7HF1sjB000722; Sat, 17 Aug 2013 15:01:54 GMT Received: from [192.168.1.108] (/66.31.4.117) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Aug 2013 08:01:54 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> Date: Sat, 17 Aug 2013 11:01:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67D7B906-B3C6-4D2B-A1E3-E334A905F34D@oracle.com> References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility 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, 17 Aug 2013 15:02:06 -0000 On Aug 13, 2013, at 6:34 PM, Paul E. Jones = wrote: > Hadriel, >=20 >> I can't tell if you seriously believe the new mechanism is going to = work >> end-to-end across all domains, or if you just mean end-to-end within = a >> domain (like within the call-center). I don't mean that in a = negative way >> - I just mean I don't understand how you mean the words "end-to-end". >=20 > I seriously mean end-to-end. Assuming service providers did not block > passage of an INVITE containing a new UUID value, then we can always = have an > end-to-end value. As an "end" changes, so does the end-to-end value. > That's OK. OK, but an end-to-end for what *purpose*. Having a common UUID on all = ends is not a goal in itself - it has to be useful for something. = Expecting a flurry of re-INVITEs to go across the world is a big deal, = in practice. Service providers won't want to deal with that just for = sake of posterity. The whole premise behind Session-ID was everyone = would be ok with passing it through only so long as it was benign. = That's the "contract" we were making, to get B2BUAs to pass it through = without worrying about negative consequences. >> When I make a call from my cell phone through my mobile provider, = through >> N number of carriers, to an Enterprise call-center somewhere in = Timbuktu, >> I have a hard time believing all the carriers and mobile providers = want to >> get back and process a re-INVITE each and every time the call gets = moved >> around inside the call-center's internal PBX infrastructure. They = rarely >> get that today, and I don't see them changing in the future to do = so... >> for what benefit? What use is it to update all the SIP systems along = the >> path, as well as my cell phone, with a new Session-ID value just = because >> the call got parked/unparked or internally transferred inside = PBX/ACD/etc. >> systems in a call-center somewhere? >>=20 >> Some call centers move the media around almost a dozen times per = call. >> You really think the rest of the world wants to get a dozen = re-INVITEs, >> for no benefit? The SBCs aren't answering the re-INVITEs locally = today to >> hide the identity of who/what it gets moved around to - that we = already do >> even when we forward the re-INVITEs - we're answering them locally = because >> the service providers don't want nor need those re-INVITEs. It's = just >> extra processing load, log entries, and things that can go wrong; = with no >> added benefit. >=20 > I really cannot do anything about these "noise" issues. I recognize = that in > practice, much of the use of SIP has been absolutely nothing more = than a > PSTN replacement. It has been merely a means of moving from TDM to = IP. I'm > glad it happened, but it's more than unfortunate if that's all we > accomplish. I think Service Providers don't want just a PSTN replacement forever - = some might, for sure - but a lot of them bought into SIP (and even IMS) = with the goal of eventually being able to do a lot more than just = PSTN-type phone calls. So far they've been heavily constrained due to = having to migrate their existing infrastructure because of course it's = the near-term cost-savings goal. The same is true in Enterprise - most = of them bought into VoIP for its long-term potential for new things, but = the short-term goal was cost-savings and replacing their existing PBXs = and TDM/PRI trunks. Service providers move slowly, because they have an = existing highly-reliable system people pay money for and depend on 911 = service for and so on, and because it's highly regulated by governments = in weird ways... but the long-term vision continues to be to go beyond = just PSTN phone calls. > As I look to doing more interesting things where I have different > applications running in various devices connected to different = networks and > associated to my "phone" where I can utilize all of them as a part of = a > "call", I see value in having this end-to-end identifier for even this = more > complex arrangement. However, I can understand if service providers = do not > take an active interest in this. =46rom a research perspective, these = more > advanced communication systems are interesting. =46rom a business > perspective, there is a question about ROI for carriers. I get that: > there's no money in doing much more than providing the most basic = voice > service, and even that service has a very small profit margin. = However, > progress, capabilities, functionality, and improvements in the way we = work > and communicate should go forward, and they are. Already, we see a = number > of alternatives like Skype, Facetime, Google Hangouts, etc. and I = expect > functionality will become much more interesting, with a wider mix of > multimedia applications in use at once. Actually in my experience Service Providers are quite willing to do new = things so long as there's some benefit in it for them - same with = Enterprises, for that matter. If we can identify some actual *purpose* = for having an end-to-end identifier across service providers beyond = troubleshooting, then we can figure out what benefit or detriment that = might have for Service Providers. IF it just costs them more money = without adding anything, it won't happen. -hadriel From paulej@packetizer.com Tue Aug 20 11:40:07 2013 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 BE40F11E8130 for ; Tue, 20 Aug 2013 11:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUEu-QUJ0cTF for ; Tue, 20 Aug 2013 11:39:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BD71B11E823A for ; Tue, 20 Aug 2013 11:39: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 r7KIdolM018911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Aug 2013 14:39:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1377023991; bh=a1o6x1e9D4rTovGRltOfQq8Pv4nmqIZfoimahATSI9w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tmEdgXJDhKeoUMgMRtSkKYoV3w81ZMVk8CYPxs+yENPkjzlGY2TL6ezeXNLa70a6y kvZgPS+RfdlXQFFVduEZHB4c83+dRmkqvQ4wKWXAeOo9cZ/vtVygigmJ9dHz9Jym+W vYTtbqGxxYDtDDaUOcVHlQwErJJMoPYRFoYoOUXA= From: "Paul E. Jones" To: "'Hadriel Kaplan'" References: <083b01ce8e70$f0ca6380$d25f2a80$@packetizer.com> <90C4A95B-C32E-4D55-9373-7F790017AB23@oracle.com> <004401ce8ec7$ba2e5dc0$2e8b1940$@packetizer.com> <0a60d8c0-8cf2-4ce6-ba64-a8c64cbe397b@email.android.com> <01e101ce8f97$ad597dc0$080c7940$@packetizer.com> <1FCC9EF2-11C9-4720-B7CD-2D9ECBCAFD62@oracle.com> <035201ce9875$3c94e6b0$b5beb410$@packetizer.com> <67D7B906-B3C6-4D2B-A1E3-E334A905F34D@oracle.com> In-Reply-To: <67D7B906-B3C6-4D2B-A1E3-E334A905F34D@oracle.com> Date: Tue, 20 Aug 2013 14:40:04 -0400 Message-ID: <049101ce9dd4$afd6a370$0f83ea50$@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: AQKz7rH6at3CfOd36gKULeT/c9opXwFpbrGEArQAdNoCZGOF7QESgoClAbrwr+cBsgX+YwFp44IVAeURpWICV7apKQJk1zw7Ac09lhWXLPYkkA== Content-Language: en-us Cc: insipid@ietf.org, 'Laura Liess' Subject: Re: [Insipid] Proposed INSIPID solution and backward compatibility 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, 20 Aug 2013 18:40:07 -0000 Hadriel, > > I seriously mean end-to-end. Assuming service providers did not block > > passage of an INVITE containing a new UUID value, then we can always > have an > > end-to-end value. As an "end" changes, so does the end-to-end value. > > That's OK. > > OK, but an end-to-end for what *purpose*. Having a common UUID on all > ends is not a goal in itself - it has to be useful for something. This actually has a variety of purposes. One is troubleshooting, since we can identify precisely through which elements a call passed, including cases where a call started out as an H.323 call and terminated somewhere as a SIP call. We have some features where we can invoke recoding of media, media tests, etc. that can be invoked even when a call is in progress. Having this identifier can be used for those things, plus post-call log inspection. > Expecting a flurry of re-INVITEs to go across the world is a big deal, in > practice. Service providers won't want to deal with that just for sake of > posterity. The whole premise behind Session-ID was everyone would be ok > with passing it through only so long as it was benign. That's the > "contract" we were making, to get B2BUAs to pass it through without > worrying about negative consequences. Right, but if we want to identify a call end-to-end, we must allow those identifiers to pass through end-to-end. Quite likely, it does not matter too much if it does get "terminated", effectively, at the enterprise edge. That's especially true if the call is essentially handed to the SP for delivery. The enterprise would not expect to have visibility into the SP network, anyway. That said, it is important that any over-the-top signaling is unaffected. If there are two remote offices connected via the Internet, it should be possible for a network admin to have visibility of the call legs inside each remote office from the central office. > > I really cannot do anything about these "noise" issues. I recognize that > in > > practice, much of the use of SIP has been absolutely nothing more than > a > > PSTN replacement. It has been merely a means of moving from TDM to IP. > I'm > > glad it happened, but it's more than unfortunate if that's all we > > accomplish. > > I think Service Providers don't want just a PSTN replacement forever - > some might, for sure - but a lot of them bought into SIP (and even IMS) > with the goal of eventually being able to do a lot more than just PSTN- > type phone calls. So far they've been heavily constrained due to having > to migrate their existing infrastructure because of course it's the near- > term cost-savings goal. The same is true in Enterprise - most of them > bought into VoIP for its long-term potential for new things, but the > short-term goal was cost-savings and replacing their existing PBXs and > TDM/PRI trunks. Service providers move slowly, because they have an > existing highly-reliable system people pay money for and depend on 911 > service for and so on, and because it's highly regulated by governments in > weird ways... but the long-term vision continues to be to go beyond just > PSTN phone calls. Perhaps, but I see business challenges to doing anything more than basic voice, given all of the free alternatives popping up everywhere that have a lot of rich multimedia capabilities. This is really a side issue, though, and I'd be fully supportive if the service providers can find a workable business model where richer communications were made possible. With that, though, is definitely going to be a lot more signaling. This notion of reducing messages on the wire really needs a re-think ;-) > > As I look to doing more interesting things where I have different > > applications running in various devices connected to different networks > and > > associated to my "phone" where I can utilize all of them as a part of a > > "call", I see value in having this end-to-end identifier for even this > more > > complex arrangement. However, I can understand if service providers do > not > > take an active interest in this. From a research perspective, these > more > > advanced communication systems are interesting. From a business > > perspective, there is a question about ROI for carriers. I get that: > > there's no money in doing much more than providing the most basic voice > > service, and even that service has a very small profit margin. However, > > progress, capabilities, functionality, and improvements in the way we > work > > and communicate should go forward, and they are. Already, we see a > number > > of alternatives like Skype, Facetime, Google Hangouts, etc. and I expect > > functionality will become much more interesting, with a wider mix of > > multimedia applications in use at once. > > > Actually in my experience Service Providers are quite willing to do new > things so long as there's some benefit in it for them - same with > Enterprises, for that matter. If we can identify some actual *purpose* > for having an end-to-end identifier across service providers beyond > troubleshooting, then we can figure out what benefit or detriment that > might have for Service Providers. IF it just costs them more money > without adding anything, it won't happen. Beyond troubleshooting is a challenge, unless I mention some of the media things we intend to use it for. However, right now we're just talking about the signaling side of things. The utility in signaling seems to relate only to troubleshooting and signaling diagnostics. There are more interesting aspects on the media side of things, but we cannot even consider those without support on the signaling side. Paul From rjsparks@nostrum.com Thu Aug 22 10:08:33 2013 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 276BD21F9C82; Thu, 22 Aug 2013 10:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SAVELE=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-rRvRJ5r3lS; Thu, 22 Aug 2013 10:08:32 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69EEB21F9F3D; Thu, 22 Aug 2013 10:08:29 -0700 (PDT) Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r7MH8QW9078421 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 12:08:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5216458A.5040608@nostrum.com> Date: Thu, 22 Aug 2013 12:08:26 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism) Cc: "gen-art@ietf.org" , "draft-kaplan-insipid-session-id.all@tools.ietf.org" , "insipid@ietf.org" Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:08:33 -0000 Adding the working group. Dan - thanks for this review. I've been working towards trying to=20 express a concern, and this really helped clarify what was bothering me. This document, AFAIK, _is not_ actually trying to register the=20 Session-ID header with IANA, even though there is a section that looks=20 like it does. Rather, that registration is in=20 http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ That is a very good example of how just adding the explanatory paragraph = at the beginning of the document isn't enough to turn this into=20 something that documents an earlier path considered and implementation=20 that exists current deployments - the text needs to be touched in=20 several places to make it clear that's what the document is doing. In=20 the IANA considerations case, one possible adjustment is to change the=20 text to "here's what known implementations have used for syntax. See=20 [draft-ietf-insipid-session-id] for the intended registered syntax", and = not issue instructions to IANA. It's more work for Hadriel, but I think it's necessary. RjS On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: > I am the assigned Gen-ART reviewer for this draft. For background on Ge= n-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments y= ou may receive. > > Document: draft-kaplan-insipid-session-id-03.txt > Reviewer: Dan Romascanu > Review Date: 8/21 > IETF LC End Date: 8/30 > IESG Telechat date: > > Summary: > Ready with Issues > > Major issues: > > 1. In similar situations when IETF WGs decided to document proprietary = solutions that were used as a basis for standards-track RFCs Historic RFC= s were issued rather than Informational RFCs. See for example RFC 5412, 5= 413, 5414 which documented the prior art that was used to create RFC 5415= =2E Publication of these documents was also withhold until the standards-= track RFC was published. None of these precedents is followed here. One o= f the reasons for the WG to prefer Informational rather than Historic is = the fact that the registration of a new SIP header field is required from= IANA, and in conformance with RFC 5727 this can be done in an Informatio= nal RFC, but not in a Historic one. What is missing however is clear text= that the solution described in this document is a legacy solution and th= at the solution going forward is the one that is being defined by the INS= IPID WG. The IESG should also consider whether this document should be ap= proved for publication before the standards-t > rack solution defined by the INSIPID WG is also published. > > 2. The Abstract makes the claim that the Standards-Track RFC that will = be eventually produced by the INSIPID WG will be developped in a backward= s-compatible manner with this document. This does not seem appropriate he= re - if at all such a requirement should be included in draft-ietf-insipi= d-session-id-reqts-08.txt. However it does not appear there, and that doc= ument was recently submitted for publication to the IESG, so the WG did n= ot include it in its consensus. > > Minor issues: > > 1. The IANA considerations sections need to be more explicit in demonst= rating that the conditions for registration of extension SIP header field= s in Informational RFCs have been met as per RFC 5727. That RFC defines t= hat Designated Expert review needs to happen for such new registrations -= I could not find a proof that such a review took place in the shepherd w= rite-up. Actually the question about the expert reviews is not answered d= irectly, instead of an answer wide deployment is mentioned, but that depl= oyment could not use this SIP header field which was not yet approved. Ac= cording to RFC 5727 there are two basic conditions that need to be verifi= ed by the Designated Expert - that the proposed header field must be of a= purely informational nature and must not significantly change the behavi= or of SIP entities that support it, and that the proposed header field mu= st not undermine SIP security in any sense, and that the Informational RF= C defining the header field must address se > curity issues in detail, as if it were a standards-track document. I = believe that both conditions are met by the I-D, but there is no adequate= text in the IANA considerations section to explain this. > > Nits/editorial comments: > > > Regards, > > Dan > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From gsalguei@cisco.com Thu Aug 22 10:30:55 2013 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 4F05821F9E91 for ; Thu, 22 Aug 2013 10:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.157 X-Spam-Level: X-Spam-Status: No, score=-9.157 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7QzsK5G19pf for ; Thu, 22 Aug 2013 10:30:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2621F9E73 for ; Thu, 22 Aug 2013 10:30:50 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MHUkxG024198 for ; Thu, 22 Aug 2013 19:30:46 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MHUhOJ024627; Thu, 22 Aug 2013 13:30:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <5216458A.5040608@nostrum.com> Date: Thu, 22 Aug 2013 13:30:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45C07F42-21DD-45BF-B9F4-CCFC01B022FB@cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1508) Cc: "Romascanu, Dan \(Dan\)" , "gen-art@ietf.org Review Team" , draft-kaplan-insipid-session-id.all@tools.ietf.org, insipid@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:30:55 -0000 On Aug 22, 2013, at 1:08 PM, Robert Sparks wrote: > Adding the working group. >=20 > Dan - thanks for this review. I've been working towards trying to = express a concern, and this really helped clarify what was bothering me. >=20 > This document, AFAIK, _is not_ actually trying to register the = Session-ID header with IANA, even though there is a section that looks = like it does. >=20 > Rather, that registration is in = http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ >=20 > That is a very good example of how just adding the explanatory = paragraph at the beginning of the document isn't enough to turn this = into something that documents an earlier path considered and = implementation that exists current deployments - the text needs to be = touched in several places to make it clear that's what the document is = doing. In the IANA considerations case, one possible adjustment is to = change the text to "here's what known implementations have used for = syntax. See [draft-ietf-insipid-session-id] for the intended registered = syntax", and not issue instructions to IANA. During the shepherd write-up I made a similar same comment. I think the = right thing to do is to write explanatory text detailing that this = document is in fact not registering anything because all relevant IANA = registrations are deferred to the active WG document defining the new = session id (draft-ietf-insipid-session-id). It should also explain that = documeny has the responsibility to assure backwards compatibility with = this document. --G >=20 > It's more work for Hadriel, but I think it's necessary. >=20 > RjS >=20 >=20 > On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: >> I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at >>=20 >> . >>=20 >> Please resolve these comments along with any other Last Call comments = you may receive. >>=20 >> Document: draft-kaplan-insipid-session-id-03.txt >> Reviewer: Dan Romascanu >> Review Date: 8/21 >> IETF LC End Date: 8/30 >> IESG Telechat date: >>=20 >> Summary: >> Ready with Issues >>=20 >> Major issues: >>=20 >> 1. In similar situations when IETF WGs decided to document = proprietary solutions that were used as a basis for standards-track RFCs = Historic RFCs were issued rather than Informational RFCs. See for = example RFC 5412, 5413, 5414 which documented the prior art that was = used to create RFC 5415. Publication of these documents was also = withhold until the standards-track RFC was published. None of these = precedents is followed here. One of the reasons for the WG to prefer = Informational rather than Historic is the fact that the registration of = a new SIP header field is required from IANA, and in conformance with = RFC 5727 this can be done in an Informational RFC, but not in a Historic = one. What is missing however is clear text that the solution described = in this document is a legacy solution and that the solution going = forward is the one that is being defined by the INSIPID WG. The IESG = should also consider whether this document should be approved for = publication before the standards > -t >> rack solution defined by the INSIPID WG is also published. >>=20 >> 2. The Abstract makes the claim that the Standards-Track RFC that = will be eventually produced by the INSIPID WG will be developped in a = backwards-compatible manner with this document. This does not seem = appropriate here - if at all such a requirement should be included in = draft-ietf-insipid-session-id-reqts-08.txt. However it does not appear = there, and that document was recently submitted for publication to the = IESG, so the WG did not include it in its consensus. >>=20 >> Minor issues: >>=20 >> 1. The IANA considerations sections need to be more explicit in = demonstrating that the conditions for registration of extension SIP = header fields in Informational RFCs have been met as per RFC 5727. That = RFC defines that Designated Expert review needs to happen for such new = registrations - I could not find a proof that such a review took place = in the shepherd write-up. Actually the question about the expert reviews = is not answered directly, instead of an answer wide deployment is = mentioned, but that deployment could not use this SIP header field which = was not yet approved. According to RFC 5727 there are two basic = conditions that need to be verified by the Designated Expert - that the = proposed header field must be of a purely informational nature and must = not significantly change the behavior of SIP entities that support it, = and that the proposed header field must not undermine SIP security in = any sense, and that the Informational RFC defining the header field must = address=20 > se >> curity issues in detail, as if it were a standards-track document. I = believe that both conditions are met by the I-D, but there is no = adequate text in the IANA considerations section to explain this. >>=20 >> Nits/editorial comments: >>=20 >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From hadriel.kaplan@oracle.com Thu Aug 22 12:17:07 2013 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 BC04F11E820A; Thu, 22 Aug 2013 12:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfaHwktrZbrn; Thu, 22 Aug 2013 12:16:44 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EB31911E8203; Thu, 22 Aug 2013 12:16:43 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7MJGcjW021701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 19:16:39 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MJGbqF001140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 19:16:37 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MJGaov019607; Thu, 22 Aug 2013 19:16:36 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 12:16:36 -0700 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <5216458A.5040608@nostrum.com> Date: Thu, 22 Aug 2013 15:16:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Romascanu, Dan \(Dan\)" , "gen-art@ietf.org" , "draft-kaplan-insipid-session-id.all@tools.ietf.org" , "insipid@ietf.org" Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 19:17:08 -0000 Actually I consciously left the IANA section as registering the header, = and it was not an oversight. For background: I did not submit the draft as Informational originally = in version-00 - I submitted it as Historic, and was asked by the = shepherding AD to change it to Informational later, based on IESG = feedback (I think; I could be wrong about it being from IESG feedback). Once it became Informational, we (myself, the AD, and the WG chairs) did = actually discuss whether it would register the header in IANA or not. = My understanding was that this Informational draft *would* in fact = register the new header in IANA. Technically there's nothing wrong with = that, afaik, other than I do need to get Designated Expert review as Dan = correctly pointed out. We discussed that once the WG draft-ietf-insipid-session-id is = published, it would then update IANA's entry for the header to point to = the new WG RFC. Whether the WG draft-ietf-insipid-session-id text needs = to change to make that clear or not, or change to extend the = already-registered header or not, etc., is of course also still = change-able. If the WG draft-ietf-insipid-session-id fundamentally changes the = 'Session-ID' header from what it is in draft-kaplan-insipid-session-id, = in a non-backwards-compatible fashion, then it won't have met the = agreement reached in IETF 85 for adopting = draft-jones-insipid-session-id-0 as the new WG document solution. If we = decide that's ok, then I think it actually needs to register a new = header name regardless. We know 'Session-ID' is already in-use in the = wild, and there are plenty of more strings available for header names. -hadriel =20 On Aug 22, 2013, at 1:08 PM, Robert Sparks wrote: > Adding the working group. >=20 > Dan - thanks for this review. I've been working towards trying to = express a concern, and this really helped clarify what was bothering me. >=20 > This document, AFAIK, _is not_ actually trying to register the = Session-ID header with IANA, even though there is a section that looks = like it does. >=20 > Rather, that registration is in = http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ >=20 > That is a very good example of how just adding the explanatory = paragraph at the beginning of the document isn't enough to turn this = into something that documents an earlier path considered and = implementation that exists current deployments - the text needs to be = touched in several places to make it clear that's what the document is = doing. In the IANA considerations case, one possible adjustment is to = change the text to "here's what known implementations have used for = syntax. See [draft-ietf-insipid-session-id] for the intended registered = syntax", and not issue instructions to IANA. >=20 > It's more work for Hadriel, but I think it's necessary. >=20 > RjS >=20 >=20 > On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: >> I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at >>=20 >> . >>=20 >> Please resolve these comments along with any other Last Call comments = you may receive. >>=20 >> Document: draft-kaplan-insipid-session-id-03.txt >> Reviewer: Dan Romascanu >> Review Date: 8/21 >> IETF LC End Date: 8/30 >> IESG Telechat date: >>=20 >> Summary: >> Ready with Issues >>=20 >> Major issues: >>=20 >> 1. In similar situations when IETF WGs decided to document = proprietary solutions that were used as a basis for standards-track RFCs = Historic RFCs were issued rather than Informational RFCs. See for = example RFC 5412, 5413, 5414 which documented the prior art that was = used to create RFC 5415. Publication of these documents was also = withhold until the standards-track RFC was published. None of these = precedents is followed here. One of the reasons for the WG to prefer = Informational rather than Historic is the fact that the registration of = a new SIP header field is required from IANA, and in conformance with = RFC 5727 this can be done in an Informational RFC, but not in a Historic = one. What is missing however is clear text that the solution described = in this document is a legacy solution and that the solution going = forward is the one that is being defined by the INSIPID WG. The IESG = should also consider whether this document should be approved for = publication before the standards-t >> rack solution defined by the INSIPID WG is also published. >>=20 >> 2. The Abstract makes the claim that the Standards-Track RFC that = will be eventually produced by the INSIPID WG will be developped in a = backwards-compatible manner with this document. This does not seem = appropriate here - if at all such a requirement should be included in = draft-ietf-insipid-session-id-reqts-08.txt. However it does not appear = there, and that document was recently submitted for publication to the = IESG, so the WG did not include it in its consensus. >>=20 >> Minor issues: >>=20 >> 1. The IANA considerations sections need to be more explicit in = demonstrating that the conditions for registration of extension SIP = header fields in Informational RFCs have been met as per RFC 5727. That = RFC defines that Designated Expert review needs to happen for such new = registrations - I could not find a proof that such a review took place = in the shepherd write-up. Actually the question about the expert reviews = is not answered directly, instead of an answer wide deployment is = mentioned, but that deployment could not use this SIP header field which = was not yet approved. According to RFC 5727 there are two basic = conditions that need to be verified by the Designated Expert - that the = proposed header field must be of a purely informational nature and must = not significantly change the behavior of SIP entities that support it, = and that the proposed header field must not undermine SIP security in = any sense, and that the Informational RFC defining the header field must = address se >> curity issues in detail, as if it were a standards-track document. I = believe that both conditions are met by the I-D, but there is no = adequate text in the IANA considerations section to explain this. >>=20 >> Nits/editorial comments: >>=20 >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >=20 >=20 From pkyzivat@alum.mit.edu Thu Aug 22 12:49:52 2013 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 8785811E8117 for ; Thu, 22 Aug 2013 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JouU2uzyhvn for ; Thu, 22 Aug 2013 12:49:45 -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 683C021F93F8 for ; Thu, 22 Aug 2013 12:49:45 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id Fndr1m0030Fqzac51vpkbl; Thu, 22 Aug 2013 19:49:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id Fvpk1m0143ZTu2S3UvpkHE; Thu, 22 Aug 2013 19:49:44 +0000 Message-ID: <52166B57.3010504@alum.mit.edu> Date: Thu, 22 Aug 2013 15:49:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: insipid@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <45C07F42-21DD-45BF-B9F4-CCFC01B022FB@cisco.com> In-Reply-To: <45C07F42-21DD-45BF-B9F4-CCFC01B022FB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377200984; bh=Xo80RbZbY4GAv9DHnehqtt6YYgZZH3JKQSHg1HqziwE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s97N3YKZiywyPIhrmr0HMzyko3lPgSTq+i0dfqlNYpdipPrJPSzvRyrjNXP03JFmC KOIYsv+JBhLhARzLItFZhLHd0THdjy8wl6HRXxKiLxAZsWbiucEx/sRVF6niSqpN69 JKbGSYVWeScVohbQt005wZWT1AjAxJwfAMtfJop3GoIIVtM7KXeoHyuTwWFSefEUw7 j8RzW8V/nsyz7nLP4/K+utVXOTHwKFJOz3XzJP+wSNBNKGvQORQ8rizJ22LQHcw3i5 HTfgw4QCYP1QI9cjINV+ZOpzMzIoGUI9pP+FJ58UqTRmwf+VuvdvOjhn/Wtz2MIg7r GGk3QCcFEYe9Q== Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 19:49:52 -0000 On 8/22/13 1:30 PM, Gonzalo Salgueiro wrote: > It should also explain that documeny has the responsibility to assure backwards compatibility with this document. AFAIK the WG has no *responsibility* to assure backwards compatibility. Its not mentioned in the charter, or in the requirements. IMO its a "nice to have", nothing more. Thanks, Paul From gsalguei@cisco.com Thu Aug 22 12:57:46 2013 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 24BDD21F9633 for ; Thu, 22 Aug 2013 12:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3IetKIg9xmG for ; Thu, 22 Aug 2013 12:57:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 30B6421F84B8 for ; Thu, 22 Aug 2013 12:57:37 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MJvVi4012837 for ; Thu, 22 Aug 2013 21:57:31 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MJv7h0016697; Thu, 22 Aug 2013 15:57:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <52166B57.3010504@alum.mit.edu> Date: Thu, 22 Aug 2013 15:57:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8CCA7EA1-84CE-4EB3-BF48-2971C117E3B1@cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <45C07F42-21DD-45BF-B9F4-CCFC01B022FB@cisco.com> <52166B57.3010504@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: insipid@ietf.org, Gonzalo Salgueiro Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 19:57:46 -0000 Well it is documented in the minutes as something the WG agreed to. See = similar post: http://www.ietf.org/mail-archive/web/insipid/current/msg00614.html Cheers, --G On Aug 22, 2013, at 3:49 PM, Paul Kyzivat wrote: > On 8/22/13 1:30 PM, Gonzalo Salgueiro wrote: >=20 >> It should also explain that documeny has the responsibility to assure = backwards compatibility with this document. >=20 > AFAIK the WG has no *responsibility* to assure backwards = compatibility. > Its not mentioned in the charter, or in the requirements. >=20 > IMO its a "nice to have", nothing more. >=20 > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From pkyzivat@alum.mit.edu Thu Aug 22 13:04:14 2013 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 A638C11E81C5 for ; Thu, 22 Aug 2013 13:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBlknGenY6yu for ; Thu, 22 Aug 2013 13:04:09 -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 D76AE11E810A for ; Thu, 22 Aug 2013 13:04:08 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id Fvyz1m00B0mv7h05Dw48Lg; Thu, 22 Aug 2013 20:04:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Fw481m0063ZTu2S3Xw48CF; Thu, 22 Aug 2013 20:04:08 +0000 Message-ID: <52166EB8.7050308@alum.mit.edu> Date: Thu, 22 Aug 2013 16:04:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Gonzalo Salgueiro References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <45C07F42-21DD-45BF-B9F4-CCFC01B022FB@cisco.com> <52166B57.3010504@alum.mit.edu> <8CCA7EA1-84CE-4EB3-BF48-2971C117E3B1@cisco.com> In-Reply-To: <8CCA7EA1-84CE-4EB3-BF48-2971C117E3B1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377201848; bh=88V4npdynsa3H34QY3BGqgT2beRGwxc4Ucli2W3q7qE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DrY7/yD24EZ/Ey41Pi5obVsjbOleWQ+DXfBEUA+aAEYyawQXiOzvYWIytcgB9FIOr cBCIfSOE/U32ZMCS7/jptLgaKbadYd7IPXrQVpKwj6ghc8x1ME3Ex/+CitCHOFUZo0 OqDAU7y3FQ7/xv91Uuah72ucZXXonLeK7Wx0g5y3/itGTFanBs3VjQ/87X8qbzPLXS 40I3SpBQM75zJcf2tvoGgQ+ltgGoE1mcO1BK90Xjd2YH15AJqXTLLydKYRro/BkqKB NiPa2YAn1t5ksUWg6mrUjff4ujaWX4tTN5JA3LhGwfXNhI4/yDMDX2f9lKHAQRH83+ 47gK9EMbSD42A== Cc: insipid@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:04:14 -0000 On 8/22/13 3:57 PM, Gonzalo Salgueiro wrote: > Well it is documented in the minutes as something the WG agreed to. See similar post: > > http://www.ietf.org/mail-archive/web/insipid/current/msg00614.html Then it ought to be recorded in someplace binding. A new requirement would be a good way. Thanks, Paul > Cheers, > > --G > > On Aug 22, 2013, at 3:49 PM, Paul Kyzivat > wrote: > >> On 8/22/13 1:30 PM, Gonzalo Salgueiro wrote: >> >>> It should also explain that documeny has the responsibility to assure backwards compatibility with this document. >> >> AFAIK the WG has no *responsibility* to assure backwards compatibility. >> Its not mentioned in the charter, or in the requirements. >> >> IMO its a "nice to have", nothing more. >> >> Thanks, >> Paul >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >> > > From rjsparks@nostrum.com Thu Aug 22 13:11:24 2013 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 A8E2011E8123; Thu, 22 Aug 2013 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.162 X-Spam-Level: X-Spam-Status: No, score=-101.162 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, MANGLED_SAVELE=2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuBTjw+XloGO; Thu, 22 Aug 2013 13:11:23 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41121F9FDA; Thu, 22 Aug 2013 13:11:23 -0700 (PDT) Received: from unnumerable.local (pool-173-71-53-173.dllstx.fios.verizon.net [173.71.53.173]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r7MKBIYi098763 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 15:11:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <52167066.7040605@nostrum.com> Date: Thu, 22 Aug 2013 15:11:18 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Received-SPF: pass (shaman.nostrum.com: 173.71.53.173 is authenticated by a trusted mechanism) Cc: "Romascanu, Dan \(Dan\)" , "gen-art@ietf.org" , "draft-kaplan-insipid-session-id.all@tools.ietf.org" , "insipid@ietf.org" Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:11:24 -0000 On 8/22/13 2:16 PM, Hadriel Kaplan wrote: > Actually I consciously left the IANA section as registering the header,= and it was not an oversight. > > For background: I did not submit the draft as Informational originally = in version-00 - I submitted it as Historic, and was asked by the shepherd= ing AD to change it to Informational later, based on IESG feedback (I thi= nk; I could be wrong about it being from IESG feedback). > > Once it became Informational, we (myself, the AD, and the WG chairs) di= d actually discuss whether it would register the header in IANA or not. = My understanding was that this Informational draft *would* in fact regist= er the new header in IANA. Technically there's nothing wrong with that, = afaik, other than I do need to get Designated Expert review as Dan correc= tly pointed out. > > We discussed that once the WG draft-ietf-insipid-session-id is publishe= d, it would then update IANA's entry for the header to point to the new W= G RFC. Whether the WG draft-ietf-insipid-session-id text needs to change= to make that clear or not, or change to extend the already-registered he= ader or not, etc., is of course also still change-able. > > If the WG draft-ietf-insipid-session-id fundamentally changes the 'Sess= ion-ID' header from what it is in draft-kaplan-insipid-session-id, in a n= on-backwards-compatible fashion, then it won't have met the agreement rea= ched in IETF 85 for adopting draft-jones-insipid-session-id-0 as the new = WG document solution. If we decide that's ok, then I think it actually n= eeds to register a new header name regardless. We know 'Session-ID' is a= lready in-use in the wild, and there are plenty of more strings available= for header names. As you note, and as RFC5727 allows, we _can_ register a header with an=20 Informational RFC, as long as it meets the two restrictions in that=20 document. (And I believe this one does). I also think the IESG could be convinced=20 that a Historic RFC would meet those requirements, and I don't think it=20 was the intent to exclude them when RFC5727 was put together. I, obviously, expected that since there _was_ a standards effort around=20 this concept, and an expectation that it would use the same name in a=20 backwards compatible way, that the standards track document would do the = registration, and there would be some relationship like the one Dan=20 points to in order to tie in this document. I don't really care if we thread the registration differently, as long=20 as we leave a _very_ clear record of what's happening since there is=20 standards activity here. I don't think we have that in the current docume= nt. But my _main_ concern is that this still reads like a PS, and I would=20 rather we take the time to change the language to be clear it's=20 documenting a current situation rather than providing instructions to=20 new implementers. RjS > > -hadriel > =20 > > On Aug 22, 2013, at 1:08 PM, Robert Sparks wrote= : > >> Adding the working group. >> >> Dan - thanks for this review. I've been working towards trying to expr= ess a concern, and this really helped clarify what was bothering me. >> >> This document, AFAIK, _is not_ actually trying to register the Session= -ID header with IANA, even though there is a section that looks like it d= oes. >> >> Rather, that registration is in http://datatracker.ietf.org/doc/draft-= ietf-insipid-session-id/ >> >> That is a very good example of how just adding the explanatory paragra= ph at the beginning of the document isn't enough to turn this into someth= ing that documents an earlier path considered and implementation that exi= sts current deployments - the text needs to be touched in several places = to make it clear that's what the document is doing. In the IANA consider= ations case, one possible adjustment is to change the text to "here's wha= t known implementations have used for syntax. See [draft-ietf-insipid-ses= sion-id] for the intended registered syntax", and not issue instructions = to IANA. >> >> It's more work for Hadriel, but I think it's necessary. >> >> RjS >> >> >> On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: >>> I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at >>> >>> . >>> >>> Please resolve these comments along with any other Last Call comments= you may receive. >>> >>> Document: draft-kaplan-insipid-session-id-03.txt >>> Reviewer: Dan Romascanu >>> Review Date: 8/21 >>> IETF LC End Date: 8/30 >>> IESG Telechat date: >>> >>> Summary: >>> Ready with Issues >>> >>> Major issues: >>> >>> 1. In similar situations when IETF WGs decided to document proprietar= y solutions that were used as a basis for standards-track RFCs Historic R= FCs were issued rather than Informational RFCs. See for example RFC 5412,= 5413, 5414 which documented the prior art that was used to create RFC 54= 15. Publication of these documents was also withhold until the standards-= track RFC was published. None of these precedents is followed here. One o= f the reasons for the WG to prefer Informational rather than Historic is = the fact that the registration of a new SIP header field is required from= IANA, and in conformance with RFC 5727 this can be done in an Informatio= nal RFC, but not in a Historic one. What is missing however is clear text= that the solution described in this document is a legacy solution and th= at the solution going forward is the one that is being defined by the INS= IPID WG. The IESG should also consider whether this document should be ap= proved for publication before the standards-t >>> rack solution defined by the INSIPID WG is also published. >>> >>> 2. The Abstract makes the claim that the Standards-Track RFC that wil= l be eventually produced by the INSIPID WG will be developped in a backwa= rds-compatible manner with this document. This does not seem appropriate = here - if at all such a requirement should be included in draft-ietf-insi= pid-session-id-reqts-08.txt. However it does not appear there, and that d= ocument was recently submitted for publication to the IESG, so the WG did= not include it in its consensus. >>> >>> Minor issues: >>> >>> 1. The IANA considerations sections need to be more explicit in demon= strating that the conditions for registration of extension SIP header fie= lds in Informational RFCs have been met as per RFC 5727. That RFC defines= that Designated Expert review needs to happen for such new registrations= - I could not find a proof that such a review took place in the shepherd= write-up. Actually the question about the expert reviews is not answered= directly, instead of an answer wide deployment is mentioned, but that de= ployment could not use this SIP header field which was not yet approved. = According to RFC 5727 there are two basic conditions that need to be veri= fied by the Designated Expert - that the proposed header field must be of= a purely informational nature and must not significantly change the beha= vior of SIP entities that support it, and that the proposed header field = must not undermine SIP security in any sense, and that the Informational = RFC defining the header field must address se >>> curity issues in detail, as if it were a standards-track document. = I believe that both conditions are met by the I-D, but there is no adequa= te text in the IANA considerations section to explain this. >>> >>> Nits/editorial comments: >>> >>> >>> Regards, >>> >>> Dan >>> >>> >>> _______________________________________________ >>> Gen-art mailing list >>> Gen-art@ietf.org >>> https://www.ietf.org/mailman/listinfo/gen-art >> From pkyzivat@alum.mit.edu Thu Aug 22 13:27:12 2013 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 6580111E8225 for ; Thu, 22 Aug 2013 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.807 X-Spam-Level: X-Spam-Status: No, score=0.807 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, MANGLED_SAVELE=2.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDYH7UZ9-Hxo for ; Thu, 22 Aug 2013 13:27:04 -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 72AC911E8222 for ; Thu, 22 Aug 2013 13:27:04 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id Fvye1m00X0cZkys5DwT3YK; Thu, 22 Aug 2013 20:27:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id FwT31m00c3ZTu2S3WwT3N1; Thu, 22 Aug 2013 20:27:03 +0000 Message-ID: <52167416.2000900@alum.mit.edu> Date: Thu, 22 Aug 2013 16:27:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: insipid@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <52167066.7040605@nostrum.com> In-Reply-To: <52167066.7040605@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377203223; bh=1VTxllJKv+xuRBZ0TZH0W20Yz300YbObegwbPKkYSBI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NscTXEthVVY4e3usY3uoSS6j3BfOv//N59a/CiE+HgKAWVeS946ssGzNjClrkU5nl XYAZlYzmMJcitUvBEMeqzTJBBb8MCeS95paJ4Xelpwu8jytMhOAFRjZggANhSolB7I n+0vNviQlxYHKxnmHxDzcEnPacj5EMH2QcK7ohMY7lUVlhvjGsYn8ae/DFy1i6MHy4 KjRvoEpPrkZKXvVc8OxhmyjpQPdtRNiw8/N1NCa1Lm+ugGEX5GvxuIUGxdf1PC4Dhw k/3Rm33SqJnMy1fXpCeRPJ5S/9+ulmyjhu0Dd0GFUCnANs4nZo3dX33cLra9zI09r2 DYaHWFqw5Fplw== Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:27:12 -0000 At this point I am half tempted to suggest that we just agree to publish the Kaplan draft as historic, and then close this WG. I say this because I don't think: - we can reach agreement to make the Kaplan draft an RFC. - the current work is going to yield something that will achieve its goals and be backward compatible - pursuing the current work with a new header name would achieve wide deployment, given that a fairly large community is committed to Session-ID. Thanks, Paul On 8/22/13 4:11 PM, Robert Sparks wrote: > On 8/22/13 2:16 PM, Hadriel Kaplan wrote: >> Actually I consciously left the IANA section as registering the >> header, and it was not an oversight. >> >> For background: I did not submit the draft as Informational originally >> in version-00 - I submitted it as Historic, and was asked by the >> shepherding AD to change it to Informational later, based on IESG >> feedback (I think; I could be wrong about it being from IESG feedback). >> >> Once it became Informational, we (myself, the AD, and the WG chairs) >> did actually discuss whether it would register the header in IANA or >> not. My understanding was that this Informational draft *would* in >> fact register the new header in IANA. Technically there's nothing >> wrong with that, afaik, other than I do need to get Designated Expert >> review as Dan correctly pointed out. >> >> We discussed that once the WG draft-ietf-insipid-session-id is >> published, it would then update IANA's entry for the header to point >> to the new WG RFC. Whether the WG draft-ietf-insipid-session-id text >> needs to change to make that clear or not, or change to extend the >> already-registered header or not, etc., is of course also still >> change-able. >> >> If the WG draft-ietf-insipid-session-id fundamentally changes the >> 'Session-ID' header from what it is in >> draft-kaplan-insipid-session-id, in a non-backwards-compatible >> fashion, then it won't have met the agreement reached in IETF 85 for >> adopting draft-jones-insipid-session-id-0 as the new WG document >> solution. If we decide that's ok, then I think it actually needs to >> register a new header name regardless. We know 'Session-ID' is >> already in-use in the wild, and there are plenty of more strings >> available for header names. > As you note, and as RFC5727 allows, we _can_ register a header with an > Informational RFC, as long as it meets the two restrictions in that > document. > (And I believe this one does). I also think the IESG could be convinced > that a Historic RFC would meet those requirements, and I don't think it > was the intent to exclude them when RFC5727 was put together. > > I, obviously, expected that since there _was_ a standards effort around > this concept, and an expectation that it would use the same name in a > backwards compatible way, that the standards track document would do the > registration, and there would be some relationship like the one Dan > points to in order to tie in this document. > > I don't really care if we thread the registration differently, as long > as we leave a _very_ clear record of what's happening since there is > standards activity here. I don't think we have that in the current > document. > > But my _main_ concern is that this still reads like a PS, and I would > rather we take the time to change the language to be clear it's > documenting a current situation rather than providing instructions to > new implementers. > > RjS >> >> -hadriel >> >> On Aug 22, 2013, at 1:08 PM, Robert Sparks wrote: >> >>> Adding the working group. >>> >>> Dan - thanks for this review. I've been working towards trying to >>> express a concern, and this really helped clarify what was bothering me. >>> >>> This document, AFAIK, _is not_ actually trying to register the >>> Session-ID header with IANA, even though there is a section that >>> looks like it does. >>> >>> Rather, that registration is in >>> http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ >>> >>> That is a very good example of how just adding the explanatory >>> paragraph at the beginning of the document isn't enough to turn this >>> into something that documents an earlier path considered and >>> implementation that exists current deployments - the text needs to be >>> touched in several places to make it clear that's what the document >>> is doing. In the IANA considerations case, one possible adjustment >>> is to change the text to "here's what known implementations have used >>> for syntax. See [draft-ietf-insipid-session-id] for the intended >>> registered syntax", and not issue instructions to IANA. >>> >>> It's more work for Hadriel, but I think it's necessary. >>> >>> RjS >>> >>> >>> On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> . >>>> >>>> Please resolve these comments along with any other Last Call >>>> comments you may receive. >>>> >>>> Document: draft-kaplan-insipid-session-id-03.txt >>>> Reviewer: Dan Romascanu >>>> Review Date: 8/21 >>>> IETF LC End Date: 8/30 >>>> IESG Telechat date: >>>> >>>> Summary: >>>> Ready with Issues >>>> >>>> Major issues: >>>> >>>> 1. In similar situations when IETF WGs decided to document >>>> proprietary solutions that were used as a basis for standards-track >>>> RFCs Historic RFCs were issued rather than Informational RFCs. See >>>> for example RFC 5412, 5413, 5414 which documented the prior art that >>>> was used to create RFC 5415. Publication of these documents was also >>>> withhold until the standards-track RFC was published. None of these >>>> precedents is followed here. One of the reasons for the WG to prefer >>>> Informational rather than Historic is the fact that the registration >>>> of a new SIP header field is required from IANA, and in conformance >>>> with RFC 5727 this can be done in an Informational RFC, but not in a >>>> Historic one. What is missing however is clear text that the >>>> solution described in this document is a legacy solution and that >>>> the solution going forward is the one that is being defined by the >>>> INSIPID WG. The IESG should also consider whether this document >>>> should be approved for publication before the standar > ds-t >>>> rack solution defined by the INSIPID WG is also published. >>>> >>>> 2. The Abstract makes the claim that the Standards-Track RFC that >>>> will be eventually produced by the INSIPID WG will be developped in >>>> a backwards-compatible manner with this document. This does not seem >>>> appropriate here - if at all such a requirement should be included >>>> in draft-ietf-insipid-session-id-reqts-08.txt. However it does not >>>> appear there, and that document was recently submitted for >>>> publication to the IESG, so the WG did not include it in its consensus. >>>> >>>> Minor issues: >>>> >>>> 1. The IANA considerations sections need to be more explicit in >>>> demonstrating that the conditions for registration of extension SIP >>>> header fields in Informational RFCs have been met as per RFC 5727. >>>> That RFC defines that Designated Expert review needs to happen for >>>> such new registrations - I could not find a proof that such a review >>>> took place in the shepherd write-up. Actually the question about the >>>> expert reviews is not answered directly, instead of an answer wide >>>> deployment is mentioned, but that deployment could not use this SIP >>>> header field which was not yet approved. According to RFC 5727 there >>>> are two basic conditions that need to be verified by the Designated >>>> Expert - that the proposed header field must be of a purely >>>> informational nature and must not significantly change the behavior >>>> of SIP entities that support it, and that the proposed header field >>>> must not undermine SIP security in any sense, and that the >>>> Informational RFC defining the header field must addres > s se >>>> curity issues in detail, as if it were a standards-track document. >>>> I believe that both conditions are met by the I-D, but there is no >>>> adequate text in the IANA considerations section to explain this. >>>> >>>> Nits/editorial comments: >>>> >>>> >>>> Regards, >>>> >>>> Dan >>>> >>>> >>>> _______________________________________________ >>>> Gen-art mailing list >>>> Gen-art@ietf.org >>>> https://www.ietf.org/mailman/listinfo/gen-art >>> > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From gsalguei@cisco.com Thu Aug 22 13:27:50 2013 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 7DD4521F850D for ; Thu, 22 Aug 2013 13:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.236 X-Spam-Level: X-Spam-Status: No, score=-10.236 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iq4VUpQ9szP for ; Thu, 22 Aug 2013 13:27:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 159E021F99C2 for ; Thu, 22 Aug 2013 13:27:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MKRhwU016811 for ; Thu, 22 Aug 2013 22:27:43 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MKRg99014828; Thu, 22 Aug 2013 16:27:42 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <52166EB8.7050308@alum.mit.edu> Date: Thu, 22 Aug 2013 16:27:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <45C07F42-21DD-45BF-B9F4-CCFC01B022FB@cisco.com> <52166B57.3010504@alum.mit.edu> <8CCA7EA1-84CE-4EB3-BF48-2971C117E3B1@cisco.com> <52166EB8.7050308@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: insipid@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:27:50 -0000 On Aug 22, 2013, at 4:04 PM, Paul Kyzivat wrote: > On 8/22/13 3:57 PM, Gonzalo Salgueiro wrote: >> Well it is documented in the minutes as something the WG agreed to. = See similar post: >>=20 >> http://www.ietf.org/mail-archive/web/insipid/current/msg00614.html >=20 > Then it ought to be recorded in someplace binding. > A new requirement would be a good way. If I recall correctly, that was proposed but the WG felt it wasn't = proper to add it to the requirements doc because of certain potential = feasibility unknowns relative to interworking scenarios between old and = new Sess-IDs. It was instead used as a conditional to WG adoption of = the solution doc and it was added as a new section to that solution doc. Based on what I've seen, there is enough strong support for backwards = compatibility that I am certain they will not let us forget its = priority. ;-) --G > Thanks, > Paul >=20 >> Cheers, >>=20 >> --G >>=20 >> On Aug 22, 2013, at 3:49 PM, Paul Kyzivat >> wrote: >>=20 >>> On 8/22/13 1:30 PM, Gonzalo Salgueiro wrote: >>>=20 >>>> It should also explain that documeny has the responsibility to = assure backwards compatibility with this document. >>>=20 >>> AFAIK the WG has no *responsibility* to assure backwards = compatibility. >>> Its not mentioned in the charter, or in the requirements. >>>=20 >>> IMO its a "nice to have", nothing more. >>>=20 >>> Thanks, >>> Paul >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >>>=20 >>=20 >>=20 >=20 From gsalguei@cisco.com Thu Aug 22 13:38:49 2013 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 42C3311E8123 for ; Thu, 22 Aug 2013 13:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.127 X-Spam-Level: X-Spam-Status: No, score=-9.127 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdDV8NWsmzay for ; Thu, 22 Aug 2013 13:38:45 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C330B21F9F9B for ; Thu, 22 Aug 2013 13:38:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MKcgeZ018145 for ; Thu, 22 Aug 2013 22:38:43 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MKcgn4025586; Thu, 22 Aug 2013 16:38:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: <52167416.2000900@alum.mit.edu> Date: Thu, 22 Aug 2013 16:38:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <67427D45-7AA2-4DFE-87CC-A8FBC4A28451@cisco.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <52167066.7040605@nostrum.com> <52167416.2000900@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) Cc: insipid@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 20:38:49 -0000 My thoughts are we don't need to continue beating this lifeless horse, = but alas I'll comment... On Aug 22, 2013, at 4:27 PM, Paul Kyzivat wrote: > At this point I am half tempted to suggest that we just agree to = publish the Kaplan draft as historic, and then close this WG. >=20 > I say this because I don't think: > - we can reach agreement to make the Kaplan draft an RFC. Agreed. > - the current work is going to yield something > that will achieve its goals and be backward compatible Speculative at best. > - pursuing the current work with a new header name would > achieve wide deployment, given that a fairly large > community is committed to Session-ID. Discussions in Berlin with Laura and other strong supporters of the 3GPP = solution (i.e., the Kaplan draft) have assured me that they plan to = adopt the new Session-ID mechanism, so long during the transition it can = be backwards compatible with the old Sess-ID that is widely deployed on = their networks. Cheers, Gonzalo >=20 > Thanks, > Paul >=20 >=20 > On 8/22/13 4:11 PM, Robert Sparks wrote: >> On 8/22/13 2:16 PM, Hadriel Kaplan wrote: >>> Actually I consciously left the IANA section as registering the >>> header, and it was not an oversight. >>>=20 >>> For background: I did not submit the draft as Informational = originally >>> in version-00 - I submitted it as Historic, and was asked by the >>> shepherding AD to change it to Informational later, based on IESG >>> feedback (I think; I could be wrong about it being from IESG = feedback). >>>=20 >>> Once it became Informational, we (myself, the AD, and the WG chairs) >>> did actually discuss whether it would register the header in IANA or >>> not. My understanding was that this Informational draft *would* in >>> fact register the new header in IANA. Technically there's nothing >>> wrong with that, afaik, other than I do need to get Designated = Expert >>> review as Dan correctly pointed out. >>>=20 >>> We discussed that once the WG draft-ietf-insipid-session-id is >>> published, it would then update IANA's entry for the header to point >>> to the new WG RFC. Whether the WG draft-ietf-insipid-session-id = text >>> needs to change to make that clear or not, or change to extend the >>> already-registered header or not, etc., is of course also still >>> change-able. >>>=20 >>> If the WG draft-ietf-insipid-session-id fundamentally changes the >>> 'Session-ID' header from what it is in >>> draft-kaplan-insipid-session-id, in a non-backwards-compatible >>> fashion, then it won't have met the agreement reached in IETF 85 for >>> adopting draft-jones-insipid-session-id-0 as the new WG document >>> solution. If we decide that's ok, then I think it actually needs to >>> register a new header name regardless. We know 'Session-ID' is >>> already in-use in the wild, and there are plenty of more strings >>> available for header names. >> As you note, and as RFC5727 allows, we _can_ register a header with = an >> Informational RFC, as long as it meets the two restrictions in that >> document. >> (And I believe this one does). I also think the IESG could be = convinced >> that a Historic RFC would meet those requirements, and I don't think = it >> was the intent to exclude them when RFC5727 was put together. >>=20 >> I, obviously, expected that since there _was_ a standards effort = around >> this concept, and an expectation that it would use the same name in a >> backwards compatible way, that the standards track document would do = the >> registration, and there would be some relationship like the one Dan >> points to in order to tie in this document. >>=20 >> I don't really care if we thread the registration differently, as = long >> as we leave a _very_ clear record of what's happening since there is >> standards activity here. I don't think we have that in the current >> document. >>=20 >> But my _main_ concern is that this still reads like a PS, and I would >> rather we take the time to change the language to be clear it's >> documenting a current situation rather than providing instructions to >> new implementers. >>=20 >> RjS >>>=20 >>> -hadriel >>>=20 >>> On Aug 22, 2013, at 1:08 PM, Robert Sparks = wrote: >>>=20 >>>> Adding the working group. >>>>=20 >>>> Dan - thanks for this review. I've been working towards trying to >>>> express a concern, and this really helped clarify what was = bothering me. >>>>=20 >>>> This document, AFAIK, _is not_ actually trying to register the >>>> Session-ID header with IANA, even though there is a section that >>>> looks like it does. >>>>=20 >>>> Rather, that registration is in >>>> http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ >>>>=20 >>>> That is a very good example of how just adding the explanatory >>>> paragraph at the beginning of the document isn't enough to turn = this >>>> into something that documents an earlier path considered and >>>> implementation that exists current deployments - the text needs to = be >>>> touched in several places to make it clear that's what the document >>>> is doing. In the IANA considerations case, one possible adjustment >>>> is to change the text to "here's what known implementations have = used >>>> for syntax. See [draft-ietf-insipid-session-id] for the intended >>>> registered syntax", and not issue instructions to IANA. >>>>=20 >>>> It's more work for Hadriel, but I think it's necessary. >>>>=20 >>>> RjS >>>>=20 >>>>=20 >>>> On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: >>>>> I am the assigned Gen-ART reviewer for this draft. For background = on >>>>> Gen-ART, please see the FAQ at >>>>>=20 >>>>> . >>>>>=20 >>>>> Please resolve these comments along with any other Last Call >>>>> comments you may receive. >>>>>=20 >>>>> Document: draft-kaplan-insipid-session-id-03.txt >>>>> Reviewer: Dan Romascanu >>>>> Review Date: 8/21 >>>>> IETF LC End Date: 8/30 >>>>> IESG Telechat date: >>>>>=20 >>>>> Summary: >>>>> Ready with Issues >>>>>=20 >>>>> Major issues: >>>>>=20 >>>>> 1. In similar situations when IETF WGs decided to document >>>>> proprietary solutions that were used as a basis for = standards-track >>>>> RFCs Historic RFCs were issued rather than Informational RFCs. See >>>>> for example RFC 5412, 5413, 5414 which documented the prior art = that >>>>> was used to create RFC 5415. Publication of these documents was = also >>>>> withhold until the standards-track RFC was published. None of = these >>>>> precedents is followed here. One of the reasons for the WG to = prefer >>>>> Informational rather than Historic is the fact that the = registration >>>>> of a new SIP header field is required from IANA, and in = conformance >>>>> with RFC 5727 this can be done in an Informational RFC, but not in = a >>>>> Historic one. What is missing however is clear text that the >>>>> solution described in this document is a legacy solution and that >>>>> the solution going forward is the one that is being defined by the >>>>> INSIPID WG. The IESG should also consider whether this document >>>>> should be approved for publication before the standar >> ds-t >>>>> rack solution defined by the INSIPID WG is also published. >>>>>=20 >>>>> 2. The Abstract makes the claim that the Standards-Track RFC that >>>>> will be eventually produced by the INSIPID WG will be developped = in >>>>> a backwards-compatible manner with this document. This does not = seem >>>>> appropriate here - if at all such a requirement should be included >>>>> in draft-ietf-insipid-session-id-reqts-08.txt. However it does not >>>>> appear there, and that document was recently submitted for >>>>> publication to the IESG, so the WG did not include it in its = consensus. >>>>>=20 >>>>> Minor issues: >>>>>=20 >>>>> 1. The IANA considerations sections need to be more explicit in >>>>> demonstrating that the conditions for registration of extension = SIP >>>>> header fields in Informational RFCs have been met as per RFC 5727. >>>>> That RFC defines that Designated Expert review needs to happen for >>>>> such new registrations - I could not find a proof that such a = review >>>>> took place in the shepherd write-up. Actually the question about = the >>>>> expert reviews is not answered directly, instead of an answer wide >>>>> deployment is mentioned, but that deployment could not use this = SIP >>>>> header field which was not yet approved. According to RFC 5727 = there >>>>> are two basic conditions that need to be verified by the = Designated >>>>> Expert - that the proposed header field must be of a purely >>>>> informational nature and must not significantly change the = behavior >>>>> of SIP entities that support it, and that the proposed header = field >>>>> must not undermine SIP security in any sense, and that the >>>>> Informational RFC defining the header field must addres >> s se >>>>> curity issues in detail, as if it were a standards-track = document. >>>>> I believe that both conditions are met by the I-D, but there is no >>>>> adequate text in the IANA considerations section to explain this. >>>>>=20 >>>>> Nits/editorial comments: >>>>>=20 >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Dan >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Gen-art mailing list >>>>> Gen-art@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/gen-art >>>>=20 >>=20 >>=20 >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >>=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From hadriel.kaplan@oracle.com Thu Aug 22 15:29:42 2013 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 D99F321F9CF5 for ; Thu, 22 Aug 2013 15:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnEAoakq0OTS for ; Thu, 22 Aug 2013 15:29:36 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 433C821F9CC3 for ; Thu, 22 Aug 2013 15:29:36 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7MMTX9g021577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 22:29:34 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MMTXRk019722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 22:29:33 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MMTXlj010392; Thu, 22 Aug 2013 22:29:33 GMT Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 15:29:32 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <52167416.2000900@alum.mit.edu> Date: Thu, 22 Aug 2013 18:29:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8CF6DFC8-FA1F-4F65-BE10-DBF53950665E@oracle.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <52167066.7040605@nostrum.com> <52167416.2000900@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: insipid@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 22:29:43 -0000 On Aug 22, 2013, at 4:27 PM, Paul Kyzivat wrote: > At this point I am half tempted to suggest that we just agree to = publish the Kaplan draft as historic, and then close this WG. >=20 > I say this because I don't think: > - we can reach agreement to make the Kaplan draft an RFC. We don't need to "reach agreement" to publish an Informational RFC. = It's not standards-track, and not even a WG doc. All it was ever going = to be published as was Informational, as far back as 2010. > - the current work is going to yield something > that will achieve its goals and be backward compatible I think it's premature to give up on it. I mean we haven't failed yet, = afaik. We only really started getting down to the nitty-gritty stuff = this past month. > - pursuing the current work with a new header name would > achieve wide deployment, given that a fairly large > community is committed to Session-ID. I think there might be conflicting goals/requirements within the WG. = Fulfilling one might conflict with fulfilling the other. It's not just = about backwards-compatibility, but also about the need for = re-INVITEs/UPDATEs. A new header name might avoid those conflicts. For = vendors that want/need to handle conference servers and updating all = participants with the new correlation value, a new header would be = usable. For ones that just need to correlate the basic call scenarios = without extra messages, the legacy one would be usable. -hadriel From pkyzivat@alum.mit.edu Fri Aug 23 07:30:20 2013 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 7790921F9C2E for ; Fri, 23 Aug 2013 07:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUdH3mW5YGPM for ; Fri, 23 Aug 2013 07:30:14 -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 C419F11E8161 for ; Fri, 23 Aug 2013 07:30:10 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id GD1S1m00A1ei1Bg53EWAk8; Fri, 23 Aug 2013 14:30:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id GEW91m0103ZTu2S3kEWAm6; Fri, 23 Aug 2013 14:30:10 +0000 Message-ID: <521771F0.3090804@alum.mit.edu> Date: Fri, 23 Aug 2013 10:30:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hadriel Kaplan References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <52167066.7040605@nostrum.com> <52167416.2000900@alum.mit.edu> <8CF6DFC8-FA1F-4F65-BE10-DBF53950665E@oracle.com> In-Reply-To: <8CF6DFC8-FA1F-4F65-BE10-DBF53950665E@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377268210; bh=ywXpmedP32qOmgEu0ySzkkpqmrzImsCzYHH5MJiwX+w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=db84sWLLXX6nD4ZQWG2LVIjcZTgQkZaFcL53zBjd7JMd62dW0NfH12//XTvoOxDwZ 4P6SEWgvoTwRq+gyZ2KRBPoGUBk9FmFT/0YSBKHY1dDuPKcnxaI+TEYFdMQjdDbwFA s/0bfgZCZRGx3ExztCdygBonhTrIaUL4rIMWVXo8J7WgqEIJMDaH1A0CICpHY7BoAk 6HfGOwOSDt4g38JviEBjHa7K+wiAwe0LFANOybTc+4IR+j1KvQ7yxFGl0b37RgCjUE FMs6B5i+RIEBFIBCp+51lvKk3XjnhoB0UqKiIVXl0FnwBvLK1NvrU02WVGa2gq7Vvy fT5DbpS/xvDXg== Cc: insipid@ietf.org Subject: [Insipid] Are we getting anywhere? 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, 23 Aug 2013 14:30:20 -0000 On 8/22/13 6:29 PM, Hadriel Kaplan wrote: > > On Aug 22, 2013, at 4:27 PM, Paul Kyzivat wrote: > >> At this point I am half tempted to suggest that we just agree to publish the Kaplan draft as historic, and then close this WG. Note that I said I was "half tempted", not that I am proposing it. Its an expression of frustration. >> I say this because I don't think: >> - we can reach agreement to make the Kaplan draft an RFC. > > We don't need to "reach agreement" to publish an Informational RFC. It's not standards-track, and not even a WG doc. All it was ever going to be published as was Informational, as far back as 2010. I should have been clearer. I was talking about an alternative that hasn't been discussed recently - just take up the Kaplan draft again and *make it a standard*. Different from publishing it in a non-normative way. >> - the current work is going to yield something >> that will achieve its goals and be backward compatible > > I think it's premature to give up on it. I mean we haven't failed yet, afaik. We only really started getting down to the nitty-gritty stuff this past month. Yes, we are still at it. But I see a lot of going in circles. The impression I get is that the most recent proposed changes lose what Paul J was trying to accomplish. ISTM that the result of that will be more complex than the Kaplan draft but have no advantages over it. And your repeated comments that B2BUAs often won't propagate reINVITEs that update the value on transfer call into question the workability of any two-halved approach. >> - pursuing the current work with a new header name would >> achieve wide deployment, given that a fairly large >> community is committed to Session-ID. > > I think there might be conflicting goals/requirements within the WG. Fulfilling one might conflict with fulfilling the other. It's not just about backwards-compatibility, but also about the need for re-INVITEs/UPDATEs. A new header name might avoid those conflicts. For vendors that want/need to handle conference servers and updating all participants with the new correlation value, a new header would be usable. For ones that just need to correlate the basic call scenarios without extra messages, the legacy one would be usable. Certainly publishing with a new name is a technical possibility. But then backward compatibility will require new implementers to include both. Will people do that? Or will we just end up with two competing standards? Thanks, Paul From keith.drage@alcatel-lucent.com Fri Aug 30 05:18:01 2013 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 7FCAB21E80CB for ; Fri, 30 Aug 2013 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.434 X-Spam-Level: X-Spam-Status: No, score=-109.434 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSKmAkcG1zXZ for ; Fri, 30 Aug 2013 05:17:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC9321E80D1 for ; Fri, 30 Aug 2013 05:17:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7UCHkJa020501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 30 Aug 2013 07:17:47 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r7UCHhcg024097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 30 Aug 2013 14:17:45 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 30 Aug 2013 14:17:43 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Thread-Topic: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt Thread-Index: AQHOn1pMPF3uydR82kyF/6GCM0GeY5mhd/8AgAAPSwCAAARlAIAMIy2g Date: Fri, 30 Aug 2013 12:17:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B08B70D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <52167066.7040605@nostrum.com> <52167416.2000900@alum.mit.edu> In-Reply-To: <52167416.2000900@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 12:18:01 -0000 (As WG cochair) Formally, none of these comments made it into the IETF last call, because a= s far as I can tell they were not made in the appropriate place, which is t= he IETF discussion list. Moreover, I made a post to this list at the time the IETF last call was ann= ounced stating that the INSIPID WG list should not be used, but rather the = IETF discussion list. I am not seeing anything in either Robert's or Paul's comment that can be t= aken as a specific comment beyond what is already in the gen-art review. If= they want to reformulate any comments that are not already reflected in th= e gen-art review so that they are more specific, then I am sure they are we= lcome to post them on the IETF discussion list. These above are issues that are not part of the WG. To respond to concerns about how the IANA registration impacts the working = group output (as this was discussed by the WG chairs with the AD before the= publication request for the kaplan draft was made)... It was our understanding that the kaplan draft does make an IANA registrati= on in the header field tables. The fact that an entry appears in the IANA t= ables conveys no seal of approval or correctness, and I can find nothing in= RFC 5226 that states otherwise. The seal of approval and correctness is co= nveyed by the RFC itself and its contents. All that happens is that the pro= cess is followed and the value appears. Whether that process (RFC 5727) is = complete in this instance (as queried in the gen-art review) is a separate = issue that the AD will presumably address. When we get to the insipid solution document, there is nothing that prevent= s that document (within its IANA considerations) entirely rewriting that en= try, either to remove references to the kaplan draft (or its RFC successor)= or to show both references. How those statements appear in the insipid sol= ution document is up to the WG. Therefore I do not believe there is an issue here. What is clear is that there are implementations out in the field that do us= e the existing kaplan draft, and therefore if an RFC does exist, an entry i= n the IANA tables would assist recipients of the header field in determinin= g the functionality. For completeness, I would also say that those people w= ho identified those implementations have also stated that they intend to mi= grate to the insipid solutions draft when it is available. We do have decisions already made in the WG (and documented in the the proc= eedings) that the solutions document should remain compatible with the exis= ting solution. That implies that the header field name is the same, the val= ue conforms to the same ABNF, but that the solution can add as many paramet= ers as it likes. I do not see that as unduly constraining on the working gr= oup, and apparently also the working group has not in its previous discussi= ons. Obviously we do also have an agreed set of requirements to meet (which are = not met by the kaplan draft). As those are also a WG decision and will pres= umably shortly also be an IETF decision, they can be taken as overriding th= e backwards compatibility decision if the two decisions prove to be incompa= tible. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 22 August 2013 21:27 > To: insipid@ietf.org > Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid- > session-id-03.txt >=20 > At this point I am half tempted to suggest that we just agree to publish > the Kaplan draft as historic, and then close this WG. >=20 > I say this because I don't think: > - we can reach agreement to make the Kaplan draft an RFC. > - the current work is going to yield something > that will achieve its goals and be backward compatible > - pursuing the current work with a new header name would > achieve wide deployment, given that a fairly large > community is committed to Session-ID. >=20 > Thanks, > Paul >=20 >=20 > On 8/22/13 4:11 PM, Robert Sparks wrote: > > On 8/22/13 2:16 PM, Hadriel Kaplan wrote: > >> Actually I consciously left the IANA section as registering the > >> header, and it was not an oversight. > >> > >> For background: I did not submit the draft as Informational originally > >> in version-00 - I submitted it as Historic, and was asked by the > >> shepherding AD to change it to Informational later, based on IESG > >> feedback (I think; I could be wrong about it being from IESG feedback)= . > >> > >> Once it became Informational, we (myself, the AD, and the WG chairs) > >> did actually discuss whether it would register the header in IANA or > >> not. My understanding was that this Informational draft *would* in > >> fact register the new header in IANA. Technically there's nothing > >> wrong with that, afaik, other than I do need to get Designated Expert > >> review as Dan correctly pointed out. > >> > >> We discussed that once the WG draft-ietf-insipid-session-id is > >> published, it would then update IANA's entry for the header to point > >> to the new WG RFC. Whether the WG draft-ietf-insipid-session-id text > >> needs to change to make that clear or not, or change to extend the > >> already-registered header or not, etc., is of course also still > >> change-able. > >> > >> If the WG draft-ietf-insipid-session-id fundamentally changes the > >> 'Session-ID' header from what it is in > >> draft-kaplan-insipid-session-id, in a non-backwards-compatible > >> fashion, then it won't have met the agreement reached in IETF 85 for > >> adopting draft-jones-insipid-session-id-0 as the new WG document > >> solution. If we decide that's ok, then I think it actually needs to > >> register a new header name regardless. We know 'Session-ID' is > >> already in-use in the wild, and there are plenty of more strings > >> available for header names. > > As you note, and as RFC5727 allows, we _can_ register a header with an > > Informational RFC, as long as it meets the two restrictions in that > > document. > > (And I believe this one does). I also think the IESG could be convinced > > that a Historic RFC would meet those requirements, and I don't think it > > was the intent to exclude them when RFC5727 was put together. > > > > I, obviously, expected that since there _was_ a standards effort around > > this concept, and an expectation that it would use the same name in a > > backwards compatible way, that the standards track document would do th= e > > registration, and there would be some relationship like the one Dan > > points to in order to tie in this document. > > > > I don't really care if we thread the registration differently, as long > > as we leave a _very_ clear record of what's happening since there is > > standards activity here. I don't think we have that in the current > > document. > > > > But my _main_ concern is that this still reads like a PS, and I would > > rather we take the time to change the language to be clear it's > > documenting a current situation rather than providing instructions to > > new implementers. > > > > RjS > >> > >> -hadriel > >> > >> On Aug 22, 2013, at 1:08 PM, Robert Sparks > wrote: > >> > >>> Adding the working group. > >>> > >>> Dan - thanks for this review. I've been working towards trying to > >>> express a concern, and this really helped clarify what was bothering > me. > >>> > >>> This document, AFAIK, _is not_ actually trying to register the > >>> Session-ID header with IANA, even though there is a section that > >>> looks like it does. > >>> > >>> Rather, that registration is in > >>> http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ > >>> > >>> That is a very good example of how just adding the explanatory > >>> paragraph at the beginning of the document isn't enough to turn this > >>> into something that documents an earlier path considered and > >>> implementation that exists current deployments - the text needs to be > >>> touched in several places to make it clear that's what the document > >>> is doing. In the IANA considerations case, one possible adjustment > >>> is to change the text to "here's what known implementations have used > >>> for syntax. See [draft-ietf-insipid-session-id] for the intended > >>> registered syntax", and not issue instructions to IANA. > >>> > >>> It's more work for Hadriel, but I think it's necessary. > >>> > >>> RjS > >>> > >>> > >>> On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: > >>>> I am the assigned Gen-ART reviewer for this draft. For background on > >>>> Gen-ART, please see the FAQ at > >>>> > >>>> . > >>>> > >>>> Please resolve these comments along with any other Last Call > >>>> comments you may receive. > >>>> > >>>> Document: draft-kaplan-insipid-session-id-03.txt > >>>> Reviewer: Dan Romascanu > >>>> Review Date: 8/21 > >>>> IETF LC End Date: 8/30 > >>>> IESG Telechat date: > >>>> > >>>> Summary: > >>>> Ready with Issues > >>>> > >>>> Major issues: > >>>> > >>>> 1. In similar situations when IETF WGs decided to document > >>>> proprietary solutions that were used as a basis for standards-track > >>>> RFCs Historic RFCs were issued rather than Informational RFCs. See > >>>> for example RFC 5412, 5413, 5414 which documented the prior art that > >>>> was used to create RFC 5415. Publication of these documents was also > >>>> withhold until the standards-track RFC was published. None of these > >>>> precedents is followed here. One of the reasons for the WG to prefer > >>>> Informational rather than Historic is the fact that the registration > >>>> of a new SIP header field is required from IANA, and in conformance > >>>> with RFC 5727 this can be done in an Informational RFC, but not in a > >>>> Historic one. What is missing however is clear text that the > >>>> solution described in this document is a legacy solution and that > >>>> the solution going forward is the one that is being defined by the > >>>> INSIPID WG. The IESG should also consider whether this document > >>>> should be approved for publication before the standar > > ds-t > >>>> rack solution defined by the INSIPID WG is also published. > >>>> > >>>> 2. The Abstract makes the claim that the Standards-Track RFC that > >>>> will be eventually produced by the INSIPID WG will be developped in > >>>> a backwards-compatible manner with this document. This does not seem > >>>> appropriate here - if at all such a requirement should be included > >>>> in draft-ietf-insipid-session-id-reqts-08.txt. However it does not > >>>> appear there, and that document was recently submitted for > >>>> publication to the IESG, so the WG did not include it in its > consensus. > >>>> > >>>> Minor issues: > >>>> > >>>> 1. The IANA considerations sections need to be more explicit in > >>>> demonstrating that the conditions for registration of extension SIP > >>>> header fields in Informational RFCs have been met as per RFC 5727. > >>>> That RFC defines that Designated Expert review needs to happen for > >>>> such new registrations - I could not find a proof that such a review > >>>> took place in the shepherd write-up. Actually the question about the > >>>> expert reviews is not answered directly, instead of an answer wide > >>>> deployment is mentioned, but that deployment could not use this SIP > >>>> header field which was not yet approved. According to RFC 5727 there > >>>> are two basic conditions that need to be verified by the Designated > >>>> Expert - that the proposed header field must be of a purely > >>>> informational nature and must not significantly change the behavior > >>>> of SIP entities that support it, and that the proposed header field > >>>> must not undermine SIP security in any sense, and that the > >>>> Informational RFC defining the header field must addres > > s se > >>>> curity issues in detail, as if it were a standards-track document. > >>>> I believe that both conditions are met by the I-D, but there is no > >>>> adequate text in the IANA considerations section to explain this. > >>>> > >>>> Nits/editorial comments: > >>>> > >>>> > >>>> Regards, > >>>> > >>>> Dan > >>>> > >>>> > >>>> _______________________________________________ > >>>> Gen-art mailing list > >>>> Gen-art@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/gen-art > >>> > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid