From paulej@packetizer.com Tue Jul 3 17:59:19 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FD411E80BF for ; Tue, 3 Jul 2012 17:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 qFNmKE-FAiGr for ; Tue, 3 Jul 2012 17:59:18 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AD37911E80AE for ; Tue, 3 Jul 2012 17:59:18 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q640xQki002986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2012 20:59:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341363566; bh=bYvY0BeOgh3oeCK0JU4uzg1HAdwBru7EpytUztL2cg8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CI3GrI05qXMXnt8mhEhEKyIXJahC1uIWZwIwlVUtyJ9MWQ2+bHdwaPa+AmpWFEZ+V PCTzvirysPY9vwsvGhHkLoYfuJ8A5CKRJRyvTNhlhPtMbCQG3tCJZVdKMoWUNT/nDp a3nZ9sAJrr79XairOgaOixzJN4NF+HpYsPNun8+k= From: "Paul E. Jones" To: "'Laura Liess'" References: In-Reply-To: Date: Tue, 3 Jul 2012 20:59:32 -0400 Message-ID: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAJi8h2CA Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 04 Jul 2012 00:59:19 -0000 Laura, I re-worded what you proposed. Tell me if this is acceptable: User Agent A (A) and User Agent B (B) communicate using SIP messaging = with a SIP B2BUA acting as a middlebox. For privacy reasons, the B2BUA changes = SIP headers that reveal information related to the SIP user, device or = domain identity. The service provider uses an external device to monitor and = log all SIP traffic coming from the B2BUA. In the case of failures reported = by the customer or when security issue arise (e.g. theft of service), the service provider has to analyze the logs, including its own logs and = perhaps logs provided by the customer, for the past several days or weeks and correlate those messages which were messages for a single end-to-end SIP session. For this scenario, we must consider three particular use cases: a) The software on A and B can be upgraded by the service provider to support a single end-to-end Session Identifier. Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8. b) Only software on A can be upgraded by the service provider to support = the new identifier. Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. c) Neither the software on A nor B can be upgraded by the service = provider to support the new identifier. Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. Should I remove "eventually REQ1a" and just put "REQ1a"? Paul > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Wednesday, June 27, 2012 5:19 AM > To: Paul Jones > Cc: insipid@ietf.org > Subject: Text proposal for the "SIP traffic monitoring" use case >=20 > Paul, >=20 > Please find enclosed a text proposal for the use case "SIP traffic > monitoring": >=20 >=20 > SIP traffic monitoring >=20 > UA-A and UA-B communicate using SIP phone calls and SIP messaging with = a > SIP B2BUA acting as a middlebox. The B2BUA changes any SIP header > revealing information related to the SIP user, device or domain = identity. > The service provider uses an external device to monitor and log =93on = the > wire=94 all SIP traffic passed through the B2BUA. =A0In case of = failures being > reported by the customers or of security issues (e.g. theft of = service), > the service provider has to analyse the logs for the past days or = weeks > and correlate those messages which where, at some point in time, > components of a single end-to-end SIP session (e.g., parts of the same > phone call or transfer of the same message). >=20 > For this scenario, we must consider three particular use cases: >=20 > a) =A0 =A0 =A0The UA-A and UA-B software can be upgraded by the = service provider > to support the new identifier. . > =A0 =A0 =A0 =A0Derived Requirements: REQ1, (eventually REQ1a), REQ4, = REQ5, REQ8. >=20 > b) =A0 =A0 =A0Only the UA-A software can be upgraded by the service = provider to > support the new identifier, the UA-B software can not. > =A0 =A0 =A0 =A0Derived Requirements: REQ1, (eventually REQ1a), REQ4, = REQ5, REQ7, > REQ8. >=20 > c) =A0 =A0 =A0Neither the UA-A nor the UA-B software can be upgraded = by the > service provider to support the new identifier, the UA-B software can = not. > =A0 =A0 =A0 =A0Derived Requirements: REQ1, (eventually REQ1a), REQ4, = REQ5, REQ7, > REQ8. >=20 > Thanks > Laura From paulej@packetizer.com Tue Jul 3 17:59:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7976011E80B3 for ; Tue, 3 Jul 2012 17:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_31=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 adboFwuMhNgg for ; Tue, 3 Jul 2012 17:59:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D695211E80AE for ; Tue, 3 Jul 2012 17:59:47 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q640xq8s003002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2012 20:59:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341363593; bh=7jWV9/6IaFMJfWKxD0tJvJo0Q9ZdJCShqC+iS4aVVWQ=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=EGFenM2siEA2tfwlKJIo3VQjSVZM1S72LIDFY2I2X+3ocN/egw5sirbch3yPQNH0E +wvwp9rBoFlHgfCeTm2Lzvw0V0YauN+e8jM4xMC1NZz6ZNHZTW+9PxJY2PJ3g/ncQU xcj6qCPCAfTipQxJLZ91EmGZp0qR0IEH1WIme934= From: "Paul E. Jones" To: "'Laura Liess'" , References: In-Reply-To: Date: Tue, 3 Jul 2012 20:59:58 -0400 Message-ID: <04e701cd5980$55c210c0$01463240$@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: AQIuHJdKmGgxCYljrJXnqV249zLBMJZWx27g Content-Language: en-us Subject: Re: [Insipid] REQ1a 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, 04 Jul 2012 00:59:48 -0000 Is this correct? It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify those dialogs, transactions and messages which were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call). Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Laura Liess > Sent: Wednesday, June 27, 2012 5:25 AM > To: insipid@ietf.org > Subject: [Insipid] REQ1a > > Hi, > > I think REQ 1a is needed. But I propose, instead of an additional REQ1a, > to extend REQ1 and write "..to identify those dialogs, > transactions and messages which were at some point." instead of > "..to identify those dialogs which were at some point." . > > What do you think? > > Thanks > Laura > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Jul 3 18:39:55 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1701221F85CE for ; Tue, 3 Jul 2012 18:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, J_CHICKENPOX_32=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 omaybMXmm1hq for ; Tue, 3 Jul 2012 18:39:54 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F24A021F85CD for ; Tue, 3 Jul 2012 18:39:53 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q641dxD4004006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jul 2012 21:40:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341366000; bh=H8+30JGa45k1OR0AA55+Q6yK6auggfnC9V/BX0AjLCw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=f15OnG4/fQBFO3mAMF2CUR65PxSBcNhH26DBl6eRc4YjVgMqs29at1BtqHaQSjmBp ytM+JUW/2v3gWu88qke6+0AG6Je820FAOMlukZVbtWMc8RA5jUNzvUbqdv1xNuOH+7 mBjXLw5mkMoTNAbWmmCa2T5YyxOrqBPejhCfsdrk= From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'James Polk'" References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> In-Reply-To: <4FEF211C.8030806@alum.mit.edu> Date: Tue, 3 Jul 2012 21:40:05 -0400 Message-ID: <04e901cd5985$f062ed70$d128c850$@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: AQK7RB41zBRhsBQ7e9n1g4StVSTSxQHV1wfwAlkbTJgCnzjdJwHoS8GOAqbHfBEBLNh5fgJQM/rUlMWn5BA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 01:39:55 -0000 Sorry I did not reply on this thread sooner. What the proposed solution document currently says is that we concatenate the two strings in a particular order. Obviously, I was happy with that, but felt like I'd open that up for discussion since there had been some dialog about the construction of the ID. I appreciated having a simple header like this: Session-ID-UUID: This would be the UUID of the sender of the message. I like that for a variety of reasons. The "Session-ID" itself is a derived value, taking components from the left-hand side (Alice) and right-hand side (Bob). The construction rules should be well-defined. Question is, do we *need* to signal the entire Session-ID in the header: Session-ID: (Putting in "s" or "from" or ":" or whatever) Or is it enough to only send Session-ID-UUID? Note that there are some cases (complicated to explain and even harder to debug) where we could have two ends changing UUID values simultaneously and boxes in the middle of the network could receive messages that totally have the wrong Session-ID header. I prefer signaling only one UUID. Do we *need* to include both in messages? Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Saturday, June 30, 2012 11:54 AM > To: James Polk > Cc: insipid@ietf.org > Subject: Re: [Insipid] Query on solution draft > > On 6/29/12 2:22 PM, James Polk wrote: > > At 08:53 AM 6/29/2012, Paul Kyzivat wrote: > >> On 6/28/12 10:19 PM, Paul E. Jones wrote: > >>> James, > >>> > >>>> If we agree that once the whole Session-ID is compiled, meaning the > >>>> GUID from UA1 and the GUID from UA2 are concatenated in some order, > >>>> that header value remains on in all SIP messages between those 2 > >>>> UAs until session termination or a transfer or join operation > >>>> occurs. > >>>> > >>>> I think this is the right way forward. Is this agreeable to everyone? > >>> > >>> I'm OK with that so long as we indicate directionality. In the rare > >>> event that two ends are joined to different calls are roughly the > >>> same time, I would want intermediaries and the remote system to be > >>> able to tell which of the two values UUIDs belong to the remote > >>> device. Thus, something like: > >>> > >>> Session-ID: S:x;R:y > >>> > >>> (referring to the sender (S) of the message and the assumed > >>> recipient (R)). > >>> > >>> If we do not do this, then Carol might receive this: > >>> > >>> Session-ID: XY > >>> > >>> And Carol knows her UUID is L and has no idea which value (X or Y) > >>> belongs to the remote device. It's a rare case, but we can avoid it > >>> ever becoming an issue by keeping the two UUIDs separated somehow. > >>> This can be through "S:" tags or the order of placement (sender || > >>> receiver). > >> > >> Be careful here. You seem to be trying to pile on two different > >> semantics. On one hand you are trying to associate each "half" of the > >> id with the end that assigned it. On the other hand, for comparing > >> two IDs you don't care what end is associated with what half - you > >> want the IDs from two messages sent in opposite directions to compare > equal. > >> > >> For precedent, what you are describing is very comparable to the > >> from-tag and to-tag. > >> > >> What Paul J is suggesting (S:, R:) can work as long as comparison > >> rules are properly defined. E.g. (as I already proposed) to compare > >> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to > >> max(Ys, Yr). > >> > >> I'm inclined to suggest the following format: > >> > >> Session-ID: from=x; to=y > >> > >> to show the similarity to from and to tags. > > > > What I originally proposed was to order Alice's GUID first, then > > Bob's, but make it implicit in which all observers of the Session-ID > > header value could easily determine which was the initiator and which > > was the responder - but only if the GUIDs were always of a known/fixed > > length (i.e., always 24 or 32 bytes for each GUID). This is instead of > > the analysis of which GUID is a greater value vs. which is a lessor > > value and concatenate that way. > > I don't understand. Once a dialog is established, it needs to be the case > that the sessionid is the same for messages sent by Alice and those sent > by Bob. And I don't think you can count of figuring out which end > initiated the dialog. (In some cases with B2BUAs, both ends may initiate, > or sometimes the middle initiates toward both ends.) > > Thanks, > Paul > > > With that model, when Bob transfers Alice to Carol, Alice's GUID would > > remain part of the Session-ID while Bob's would be replaced by Carol's > > (once she responds). > > > > Now, I know I haven't thought about all versions of joins to > > appreciate if there is a corner case of join that breaks this model. > > But, I'm not sure we need to include the 'S:' & 'R:' or 'from=' & > > 'to=' unless we determine we need to be explicit. If that's the case, > > I'd like to see (i.e., a diagram of) an example of that corner case. > > > > WRT the idea of whether or not to have the GUIDs present in the > > Session-ID header value, this is clean and not left to assumption as > > to what is the other GUID value that is not in that SIP message. It's > > not like we're attempting to hide one GUID from being seen on the > > wire, that's what TLS is for if that's a concern. > > > > James > > > > > >> Thanks, > >> Paul > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Jul 3 19:00:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3D011E80AE for ; Tue, 3 Jul 2012 19:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 lg+jyTUOclBp for ; Tue, 3 Jul 2012 19:00:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EB8B721F8692 for ; Tue, 3 Jul 2012 19:00:30 -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 q6420cXd004617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Jul 2012 22:00:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341367240; bh=z3jk1xNwZ/Laa4cNL3R47glQV8CoSdqZ4qC/R6xecSA=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=bzIRv3Dq83Pg+e7MqVKw7u35TTpjUgf8o7ABmPh6ZttHTG/+X9GL7TY0kPhno2ysf 9HPKMbg7f745DLv8Ut7ZRcKhT+6hcTDBURKM+D0gpkYRJBnek8NCtk2ixGt/520vEJ k3iKjfxtl10lz8dMZxdKsTTHee3q8oDFeDtSKJDE= From: "Paul E. Jones" To: Date: Tue, 3 Jul 2012 22:00:44 -0400 Message-ID: <04f101cd5988$d346cfb0$79d46f10$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F2_01CD5967.4C357DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1Zhf9nuB/hMpyFQwaRN/ErxWZekg== Content-Language: en-us Subject: [Insipid] Session-ID UUID vs something else 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, 04 Jul 2012 02:00:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F2_01CD5967.4C357DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, We proposed using UUIDs since they are unique in time and space. The downside, though, is that they are large. We could make them smaller, perhaps just assigning random values. I suppose this is a requirements question. What is the requirement with respect to uniqueness in time and space for a Session-ID or the Session-ID component contributed by one endpoint? The present proposal we made would guarantee uniqueness in time and space (depending on the UUID version employed), but if the requirement is only to have a certain probability of no collisions, we could use a smaller string of random bits. Paul ------=_NextPart_000_04F2_01CD5967.4C357DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We proposed = using UUIDs since they are unique in time and space.  The downside, = though, is that they are large.

 

We could = make them smaller, perhaps just assigning random = values.

 

I suppose this is a requirements question.  What = is the requirement with respect to uniqueness in time and space for a = Session-ID or the Session-ID component contributed by one = endpoint?  The present proposal we made would guarantee uniqueness = in time and space (depending on the UUID version employed), but if the = requirement is only to have a certain probability of no collisions, we = could use a smaller string of random bits.

 

Paul

 

------=_NextPart_000_04F2_01CD5967.4C357DD0-- From pkyzivat@alum.mit.edu Tue Jul 3 20:34:49 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AC311E80F4 for ; Tue, 3 Jul 2012 20:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_32=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 hvRO-XVLuJtr for ; Tue, 3 Jul 2012 20:34:47 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1711E80E9 for ; Tue, 3 Jul 2012 20:34:46 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id W3UE1j00116LCl0543axPG; Wed, 04 Jul 2012 03:34:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id W3as1j0093ZTu2S3S3asjN; Wed, 04 Jul 2012 03:34:52 +0000 Message-ID: <4FF3B9DE.4020202@alum.mit.edu> Date: Tue, 03 Jul 2012 23:34:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> <04e901cd5985$f062ed70$d128c850$@packetizer.com> In-Reply-To: <04e901cd5985$f062ed70$d128c850$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 03:34:49 -0000 If you only signal the sending end's id in each message, it complicates logging, or else it complicates log analysis. Somebody needs to save state to fill in the "other" half of the id for log analysis. Paul K On 7/3/12 9:40 PM, Paul E. Jones wrote: > Sorry I did not reply on this thread sooner. > > What the proposed solution document currently says is that we concatenate > the two strings in a particular order. Obviously, I was happy with that, > but felt like I'd open that up for discussion since there had been some > dialog about the construction of the ID. > > I appreciated having a simple header like this: > > Session-ID-UUID: > > This would be the UUID of the sender of the message. I like that for a > variety of reasons. The "Session-ID" itself is a derived value, taking > components from the left-hand side (Alice) and right-hand side (Bob). The > construction rules should be well-defined. > > Question is, do we *need* to signal the entire Session-ID in the header: > > Session-ID: > > (Putting in "s" or "from" or ":" or whatever) > > Or is it enough to only send Session-ID-UUID? > > Note that there are some cases (complicated to explain and even harder to > debug) where we could have two ends changing UUID values simultaneously and > boxes in the middle of the network could receive messages that totally have > the wrong Session-ID header. > > I prefer signaling only one UUID. Do we *need* to include both in messages? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Saturday, June 30, 2012 11:54 AM >> To: James Polk >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Query on solution draft >> >> On 6/29/12 2:22 PM, James Polk wrote: >>> At 08:53 AM 6/29/2012, Paul Kyzivat wrote: >>>> On 6/28/12 10:19 PM, Paul E. Jones wrote: >>>>> James, >>>>> >>>>>> If we agree that once the whole Session-ID is compiled, meaning the >>>>>> GUID from UA1 and the GUID from UA2 are concatenated in some order, >>>>>> that header value remains on in all SIP messages between those 2 >>>>>> UAs until session termination or a transfer or join operation >>>>>> occurs. >>>>>> >>>>>> I think this is the right way forward. Is this agreeable to everyone? >>>>> >>>>> I'm OK with that so long as we indicate directionality. In the rare >>>>> event that two ends are joined to different calls are roughly the >>>>> same time, I would want intermediaries and the remote system to be >>>>> able to tell which of the two values UUIDs belong to the remote >>>>> device. Thus, something like: >>>>> >>>>> Session-ID: S:x;R:y >>>>> >>>>> (referring to the sender (S) of the message and the assumed >>>>> recipient (R)). >>>>> >>>>> If we do not do this, then Carol might receive this: >>>>> >>>>> Session-ID: XY >>>>> >>>>> And Carol knows her UUID is L and has no idea which value (X or Y) >>>>> belongs to the remote device. It's a rare case, but we can avoid it >>>>> ever becoming an issue by keeping the two UUIDs separated somehow. >>>>> This can be through "S:" tags or the order of placement (sender || >>>>> receiver). >>>> >>>> Be careful here. You seem to be trying to pile on two different >>>> semantics. On one hand you are trying to associate each "half" of the >>>> id with the end that assigned it. On the other hand, for comparing >>>> two IDs you don't care what end is associated with what half - you >>>> want the IDs from two messages sent in opposite directions to compare >> equal. >>>> >>>> For precedent, what you are describing is very comparable to the >>>> from-tag and to-tag. >>>> >>>> What Paul J is suggesting (S:, R:) can work as long as comparison >>>> rules are properly defined. E.g. (as I already proposed) to compare >>>> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to >>>> max(Ys, Yr). >>>> >>>> I'm inclined to suggest the following format: >>>> >>>> Session-ID: from=x; to=y >>>> >>>> to show the similarity to from and to tags. >>> >>> What I originally proposed was to order Alice's GUID first, then >>> Bob's, but make it implicit in which all observers of the Session-ID >>> header value could easily determine which was the initiator and which >>> was the responder - but only if the GUIDs were always of a known/fixed >>> length (i.e., always 24 or 32 bytes for each GUID). This is instead of >>> the analysis of which GUID is a greater value vs. which is a lessor >>> value and concatenate that way. >> >> I don't understand. Once a dialog is established, it needs to be the case >> that the sessionid is the same for messages sent by Alice and those sent >> by Bob. And I don't think you can count of figuring out which end >> initiated the dialog. (In some cases with B2BUAs, both ends may initiate, >> or sometimes the middle initiates toward both ends.) >> >> Thanks, >> Paul >> >>> With that model, when Bob transfers Alice to Carol, Alice's GUID would >>> remain part of the Session-ID while Bob's would be replaced by Carol's >>> (once she responds). >>> >>> Now, I know I haven't thought about all versions of joins to >>> appreciate if there is a corner case of join that breaks this model. >>> But, I'm not sure we need to include the 'S:'& 'R:' or 'from='& >>> 'to=' unless we determine we need to be explicit. If that's the case, >>> I'd like to see (i.e., a diagram of) an example of that corner case. >>> >>> WRT the idea of whether or not to have the GUIDs present in the >>> Session-ID header value, this is clean and not left to assumption as >>> to what is the other GUID value that is not in that SIP message. It's >>> not like we're attempting to hide one GUID from being seen on the >>> wire, that's what TLS is for if that's a concern. >>> >>> James >>> >>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> >>> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > From pravindran@sonusnet.com Tue Jul 3 20:55:48 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3288E11E80E9 for ; Tue, 3 Jul 2012 20:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 OQQqcjLeIcw0 for ; Tue, 3 Jul 2012 20:55:46 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 23DCB21F8634 for ; Tue, 3 Jul 2012 20:55:46 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT/O+y0YHWVoF13AyzmgdikkkZKyymQyc@postini.com; Tue, 03 Jul 2012 20:55:56 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 3 Jul 2012 23:55:54 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 4 Jul 2012 09:25:51 +0530 From: "Ravindran, Parthasarathi" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] Session-ID UUID vs something else Thread-Index: Ac1Zhf9nuB/hMpyFQwaRN/ErxWZekgAETLGw Date: Wed, 4 Jul 2012 03:55:50 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1605CDC7@inba-mail01.sonusnet.com> References: <04f101cd5988$d346cfb0$79d46f10$@packetizer.com> In-Reply-To: <04f101cd5988$d346cfb0$79d46f10$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C1605CDC7inbamail01sonus_" MIME-Version: 1.0 Subject: Re: [Insipid] Session-ID UUID vs something else 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, 04 Jul 2012 03:55:48 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C1605CDC7inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, The concern of large URN UUID string(RFC 4122) is raised in SIPREC metadat= a unique-id as well. The base 64 URN UUID representation reduces the size o= f the URN UUID and it is mentioned in http://tools.ietf.org/html/draft-ietf= -siprec-metadata-07. The sample base64 URN UUID is "hVpd7YQgRW2= nD22h7q60JQ=3D=3D". Here, there is no compromise in uniqueness w.r.t time a= nd space as it is just a different encoding format in the wire. Please let= me know opinion on base64 URN UUID usage. >From the requirement perspective, the unique id SHOULD meet uniqueness crit= eria w.r.t time and space as well as the size of the unique id has to be o= ptimal. Thanks Partha From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: Wednesday, July 04, 2012 7:31 AM To: insipid@ietf.org Subject: [Insipid] Session-ID UUID vs something else Folks, We proposed using UUIDs since they are unique in time and space. The downs= ide, though, is that they are large. We could make them smaller, perhaps just assigning random values. I suppose this is a requirements question. What is the requirement with re= spect to uniqueness in time and space for a Session-ID or the Session-ID co= mponent contributed by one endpoint? The present proposal we made would gu= arantee uniqueness in time and space (depending on the UUID version employe= d), but if the requirement is only to have a certain probability of no coll= isions, we could use a smaller string of random bits. Paul --_000_387F9047F55E8C42850AD6B3A7A03C6C1605CDC7inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,


The concern of large URN UUID string(RFC 4122)  is raised in SIPREC me= tadata unique-id as well. The base 64 URN UUID representation reduces the s= ize of the URN UUID and it is mentioned in http://tools.ietf.org/html/draft-ietf-siprec-metadata-07.  The sample = base64 URN UUID is “hVpd7YQgRW2nD22h7q60JQ=3D=3D”. Here, th= ere is no compromise in uniqueness w.r.t time and space as it is just a dif= ferent encoding format in the wire.  Please let me know opinion on base64 URN UUID usage.

 

From the requirement p= erspective, the unique id SHOULD meet uniqueness criteria w.r.t time and sp= ace as well as the  size of the unique id has to be optimal.

 

Thanks

Partha

 

From: insipid-= bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, July 04, 2012 7:31 AM
To: insipid@ietf.org
Subject: [Insipid] Session-ID UUID vs something else

 

Folks,

 

We proposed using UUIDs since they are unique in tim= e and space.  The downside, though, is that they are large.=

 

We could make them smaller, perhaps just assigning r= andom values.

 

I suppose this is a requirements question.  Wha= t is the requirement with respect to uniqueness in time and space for a Ses= sion-ID or the Session-ID component contributed by one endpoint?  The = present proposal we made would guarantee uniqueness in time and space (depending on the UUID version employed), but if the req= uirement is only to have a certain probability of no collisions, we could u= se a smaller string of random bits.

 

Paul

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C1605CDC7inbamail01sonus_-- From laura.liess.dt@googlemail.com Wed Jul 4 01:05:12 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37E421F87B8 for ; Wed, 4 Jul 2012 01:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqonxxuL9pWs for ; Wed, 4 Jul 2012 01:05:12 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61BF321F873A for ; Wed, 4 Jul 2012 01:05:12 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6817498ghb.31 for ; Wed, 04 Jul 2012 01:05:22 -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=la6aBj6j2p7Bmj2T7+92Sj4p+xyCAioQlUctsh/jWZw=; b=kB/Rtsr/cYuFOh2rdgJOM44TKh9PrrvHC3LRU82yparTrU23GqzZ3GwYcSPIKE7JQw WPqXyzC6XSlFNmmrTQ77lyNmCkFAvTE8myNXclKYIANdQd9XsuYv9SrQLPnMKEEh160s fhk8QCHRAh/yGxZmO8Z0JcAJ2iu6pv6YbsNfCnvNz6KBhO1UAdPQdjfzSt9vIcGbR4uG 9EXyyb68HGX3PHn7jnPxXqihMKBYk7DKJGc9s/8zYgXqiI5sjEIOumRZzH2dnhUjVW8S HOJmREN7yBKuSOdw3xYaGRMJQfriEGd12W1yv1iFx+ERkFU3qOzuhDMl84s1NOXIdvvj 6GyA== MIME-Version: 1.0 Received: by 10.50.91.233 with SMTP id ch9mr12456657igb.8.1341389121986; Wed, 04 Jul 2012 01:05:21 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Wed, 4 Jul 2012 01:05:21 -0700 (PDT) In-Reply-To: <04e701cd5980$55c210c0$01463240$@packetizer.com> References: <04e701cd5980$55c210c0$01463240$@packetizer.com> Date: Wed, 4 Jul 2012 10:05:21 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] REQ1a 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, 04 Jul 2012 08:05:13 -0000 Yes, from my point of view. Thank you Laura 2012/7/4 Paul E. Jones : > Is this correct? > > It must be possible for an administrator or an external device which > monitors the SIP-traffic to use the identifier to identify those dialogs, > transactions and messages which were at some point in time components of a > single end-to-end SIP session (e.g., parts of the same call). > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Laura Liess >> Sent: Wednesday, June 27, 2012 5:25 AM >> To: insipid@ietf.org >> Subject: [Insipid] REQ1a >> >> Hi, >> >> I think REQ 1a is needed. But I propose, instead of an additional REQ1a, >> to extend REQ1 and write "..to identify those dialogs, >> transactions and messages which were at some point." instead of >> "..to identify those dialogs which were at some point." . >> >> What do you think? >> >> Thanks >> Laura >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > From laura.liess.dt@googlemail.com Wed Jul 4 01:14:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB65E21F8818 for ; Wed, 4 Jul 2012 01:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-qrXdx2jHOZ for ; Wed, 4 Jul 2012 01:14:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C69DD21F880B for ; Wed, 4 Jul 2012 01:14:29 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6807665ggn.31 for ; Wed, 04 Jul 2012 01:14:38 -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:content-transfer-encoding; bh=a+BbUmkK/lyktWt/u9jPugMFY562KKf5MhxyR9ZlMEk=; b=RpSLcKD/7yFh2Ufl9A9AmfOj7GmYPMytphCNM0x9+Uo1UCFBZSv90EMONmeOCbTRCj U7mwudTpAmuGFHo85LTUrg6ZSqshhTUb36xPcuNBdQirG2dm/Zxoda1H/NUqcFlmpPRl Ngd3vMvbhghWCUkLg8bsoW0YB9AmSrYi0SNb4oFbseFytpy9qO6lRMTGBcYgganfDJGL CcF2cVG5QIxOO7eInpwhNq1TkZr/X5UycgjAVHAbc+PESjSpMy9+cY6xuAfC9uO4VvAo q6ad9Nr9sNqJVb6ye6gixlKTmSprvBWnX04OdQbbFURNthIgerGoRQw+EhCJuzK4WeNu sIig== MIME-Version: 1.0 Received: by 10.50.94.163 with SMTP id dd3mr10531543igb.8.1341389677821; Wed, 04 Jul 2012 01:14:37 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Wed, 4 Jul 2012 01:14:37 -0700 (PDT) In-Reply-To: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> Date: Wed, 4 Jul 2012 10:14:37 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 04 Jul 2012 08:14:32 -0000 Paul, I am fine with the text. For use case c) please just remove "(eventually REQ1a)" because REQ 1a is now included into REQ1. Thank you Laura 2012/7/4 Paul E. Jones : > Laura, > > I re-worded what you proposed. Tell me if this is acceptable: > > User Agent A (A) and User Agent B (B) communicate using SIP messaging wit= h a > SIP B2BUA acting as a middlebox. For privacy reasons, the B2BUA changes S= IP > headers that reveal information related to the SIP user, device or domain > identity. The service provider uses an external device to monitor and log > all SIP traffic coming from the B2BUA. In the case of failures reported = by > the customer or when security issue arise (e.g. theft of service), the > service provider has to analyze the logs, including its own logs and perh= aps > logs provided by the customer, for the past several days or weeks and > correlate those messages which were messages for a single end-to-end SIP > session. > > For this scenario, we must consider three particular use cases: > > a) The software on A and B can be upgraded by the service provider to > support a single end-to-end Session Identifier. > > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8. > > b) Only software on A can be upgraded by the service provider to support = the > new identifier. > > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. > > c) Neither the software on A nor B can be upgraded by the service provide= r > to support the new identifier. > > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. > > Should I remove "eventually REQ1a" and just put "REQ1a"? > > Paul > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Wednesday, June 27, 2012 5:19 AM >> To: Paul Jones >> Cc: insipid@ietf.org >> Subject: Text proposal for the "SIP traffic monitoring" use case >> >> Paul, >> >> Please find enclosed a text proposal for the use case "SIP traffic >> monitoring": >> >> >> SIP traffic monitoring >> >> UA-A and UA-B communicate using SIP phone calls and SIP messaging with a >> SIP B2BUA acting as a middlebox. The B2BUA changes any SIP header >> revealing information related to the SIP user, device or domain identity= . >> The service provider uses an external device to monitor and log =93on th= e >> wire=94 all SIP traffic passed through the B2BUA. In case of failures b= eing >> reported by the customers or of security issues (e.g. theft of service), >> the service provider has to analyse the logs for the past days or weeks >> and correlate those messages which where, at some point in time, >> components of a single end-to-end SIP session (e.g., parts of the same >> phone call or transfer of the same message). >> >> For this scenario, we must consider three particular use cases: >> >> a) The UA-A and UA-B software can be upgraded by the service provid= er >> to support the new identifier. . >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8. >> >> b) Only the UA-A software can be upgraded by the service provider t= o >> support the new identifier, the UA-B software can not. >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, >> REQ8. >> >> c) Neither the UA-A nor the UA-B software can be upgraded by the >> service provider to support the new identifier, the UA-B software can no= t. >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, >> REQ8. >> >> Thanks >> Laura > From pravindran@sonusnet.com Wed Jul 4 01:25:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FF821F8797 for ; Wed, 4 Jul 2012 01:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_32=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 DWCRjiJCSyOU for ; Wed, 4 Jul 2012 01:25:38 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF721F8631 for ; Wed, 4 Jul 2012 01:25:38 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT/P+DOg7kdCRgUZ4071CIIY65LGW9SEj@postini.com; Wed, 04 Jul 2012 01:25:48 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Jul 2012 04:25:46 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 4 Jul 2012 13:55:43 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "Paul E. Jones" Thread-Topic: [Insipid] Query on solution draft Thread-Index: AQHNVWauNqQDLqPuRV2Mj6m+ovNjUJcQNBoAgADCCoCAAEsuAIABaNIAgAVauoCAACAUAIAArBiA Date: Wed, 4 Jul 2012 08:25:42 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1605CE89@inba-mail01.sonusnet.com> References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> <04e901cd5985$f062ed70$d128c850$@packetizer.com> <4FF3B9DE.4020202@alum.mit.edu> In-Reply-To: <4FF3B9DE.4020202@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'James Polk' , "insipid@ietf.org" Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 08:25:40 -0000 It is preferred to have two piece of information rather than one as each en= d form its own id and make the unique id based on its concatenation. There is no need to spell out in the session-id whether it is "from" piece = or "to" piece as it does not matter during the mid-dialog and it is subject= ed to change due to different SIP application/services. Thanks Partha=20 >-----Original Message----- >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Wednesday, July 04, 2012 9:05 AM >To: Paul E. Jones >Cc: 'James Polk'; insipid@ietf.org >Subject: Re: [Insipid] Query on solution draft > >If you only signal the sending end's id in each message, it complicates >logging, or else it complicates log analysis. Somebody needs to save >state to fill in the "other" half of the id for log analysis. > > Paul K > >On 7/3/12 9:40 PM, Paul E. Jones wrote: >> Sorry I did not reply on this thread sooner. >> >> What the proposed solution document currently says is that we >> concatenate the two strings in a particular order. Obviously, I was >> happy with that, but felt like I'd open that up for discussion since >> there had been some dialog about the construction of the ID. >> >> I appreciated having a simple header like this: >> >> Session-ID-UUID: >> >> This would be the UUID of the sender of the message. I like that for >> a variety of reasons. The "Session-ID" itself is a derived value, >> taking components from the left-hand side (Alice) and right-hand side >> (Bob). The construction rules should be well-defined. >> >> Question is, do we *need* to signal the entire Session-ID in the >header: >> >> Session-ID: >> >> (Putting in "s" or "from" or ":" or whatever) >> >> Or is it enough to only send Session-ID-UUID? >> >> Note that there are some cases (complicated to explain and even harder >> to >> debug) where we could have two ends changing UUID values >> simultaneously and boxes in the middle of the network could receive >> messages that totally have the wrong Session-ID header. >> >> I prefer signaling only one UUID. Do we *need* to include both in >messages? >> >> Paul >> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Saturday, June 30, 2012 11:54 AM >>> To: James Polk >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Query on solution draft >>> >>> On 6/29/12 2:22 PM, James Polk wrote: >>>> At 08:53 AM 6/29/2012, Paul Kyzivat wrote: >>>>> On 6/28/12 10:19 PM, Paul E. Jones wrote: >>>>>> James, >>>>>> >>>>>>> If we agree that once the whole Session-ID is compiled, meaning >>>>>>> the GUID from UA1 and the GUID from UA2 are concatenated in some >>>>>>> order, that header value remains on in all SIP messages between >>>>>>> those 2 UAs until session termination or a transfer or join >>>>>>> operation occurs. >>>>>>> >>>>>>> I think this is the right way forward. Is this agreeable to >everyone? >>>>>> >>>>>> I'm OK with that so long as we indicate directionality. In the >>>>>> rare event that two ends are joined to different calls are roughly >>>>>> the same time, I would want intermediaries and the remote system >>>>>> to be able to tell which of the two values UUIDs belong to the >>>>>> remote device. Thus, something like: >>>>>> >>>>>> Session-ID: S:x;R:y >>>>>> >>>>>> (referring to the sender (S) of the message and the assumed >>>>>> recipient (R)). >>>>>> >>>>>> If we do not do this, then Carol might receive this: >>>>>> >>>>>> Session-ID: XY >>>>>> >>>>>> And Carol knows her UUID is L and has no idea which value (X or Y) >>>>>> belongs to the remote device. It's a rare case, but we can avoid >>>>>> it ever becoming an issue by keeping the two UUIDs separated >somehow. >>>>>> This can be through "S:" tags or the order of placement (sender || >>>>>> receiver). >>>>> >>>>> Be careful here. You seem to be trying to pile on two different >>>>> semantics. On one hand you are trying to associate each "half" of >>>>> the id with the end that assigned it. On the other hand, for >>>>> comparing two IDs you don't care what end is associated with what >>>>> half - you want the IDs from two messages sent in opposite >>>>> directions to compare >>> equal. >>>>> >>>>> For precedent, what you are describing is very comparable to the >>>>> from-tag and to-tag. >>>>> >>>>> What Paul J is suggesting (S:, R:) can work as long as comparison >>>>> rules are properly defined. E.g. (as I already proposed) to compare >>>>> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to >>>>> max(Ys, Yr). >>>>> >>>>> I'm inclined to suggest the following format: >>>>> >>>>> Session-ID: from=3Dx; to=3Dy >>>>> >>>>> to show the similarity to from and to tags. >>>> >>>> What I originally proposed was to order Alice's GUID first, then >>>> Bob's, but make it implicit in which all observers of the Session-ID >>>> header value could easily determine which was the initiator and >>>> which was the responder - but only if the GUIDs were always of a >>>> known/fixed length (i.e., always 24 or 32 bytes for each GUID). This >>>> is instead of the analysis of which GUID is a greater value vs. >>>> which is a lessor value and concatenate that way. >>> >>> I don't understand. Once a dialog is established, it needs to be the >>> case that the sessionid is the same for messages sent by Alice and >>> those sent by Bob. And I don't think you can count of figuring out >>> which end initiated the dialog. (In some cases with B2BUAs, both ends >>> may initiate, or sometimes the middle initiates toward both ends.) >>> >>> Thanks, >>> Paul >>> >>>> With that model, when Bob transfers Alice to Carol, Alice's GUID >>>> would remain part of the Session-ID while Bob's would be replaced by >>>> Carol's (once she responds). >>>> >>>> Now, I know I haven't thought about all versions of joins to >>>> appreciate if there is a corner case of join that breaks this model. >>>> But, I'm not sure we need to include the 'S:'& 'R:' or 'from=3D'& >>>> 'to=3D' unless we determine we need to be explicit. If that's the >>>> case, I'd like to see (i.e., a diagram of) an example of that corner >case. >>>> >>>> WRT the idea of whether or not to have the GUIDs present in the >>>> Session-ID header value, this is clean and not left to assumption as >>>> to what is the other GUID value that is not in that SIP message. >>>> It's not like we're attempting to hide one GUID from being seen on >>>> the wire, that's what TLS is for if that's a concern. >>>> >>>> James >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> >>>> >>> >>> _______________________________________________ >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> >> > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed Jul 4 08:57:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3A021F8757 for ; Wed, 4 Jul 2012 08:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 rH+Sf+41Xy+L for ; Wed, 4 Jul 2012 08:57:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 15E8121F8700 for ; Wed, 4 Jul 2012 08:57:19 -0700 (PDT) Received: from dyn-157.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 q64FvRcq003942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 4 Jul 2012 11:57:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341417448; bh=mFtuCxojy+993gU6Aac1bMe3FGLM3nVjlfYIY/O4gv0=; h=References:In-Reply-To:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=RzhUGpqDK1MAQ+6FRvcYimC8LmW6qwHso8H5ibalMo5Mg0/F4+IW6r0QtGfg33DOO y6cfgPF2Sm/t4cUdM1CsWWj5UbTvxFAQ3uJSSZHcTZ8maL+61vE7aBaDgHrusBy4i/ EwpmVG+EVOGo0n32kocbTP8lBIvz+loPcQP/7iLE= References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> <04e901cd5985$f062ed70$d128c850$@packetizer.com> <4FF3B9DE.4020202@alum.mit.edu> User-Agent: K-9 Mail for Android In-Reply-To: <4FF3B9DE.4020202@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----M9YZ3SDNTM7OV6AXGR2286UKHFS1WH" From: "Paul E. Jones" Date: Wed, 04 Jul 2012 11:57:25 -0400 To: Paul Kyzivat Message-ID: <827e51eb-6667-4db4-8b38-46e0a209ecab@email.android.com> Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 15:57:20 -0000 ------M9YZ3SDNTM7OV6AXGR2286UKHFS1WH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Yes, that's the trade off. Signaling both without somehow indicating which one belongs to the remote end can also cause confusion. I think the SIP header should allow each end to signals its value such that it is clear which value belongs to the other end. Its possible in a call join scenario where both ends do a join at the same time for an invite to come across the wire that has two uuids, one right and one wrong, but the receiver cannot tell what's right and intermediaries will log the wrong values. Rare case, but can happen. So, I like Session-ID: alice/bob Or similar. Paul _____________________________________________ From: Paul Kyzivat Sent: Tue Jul 03 23:34:54 EDT 2012 To: "Paul E. Jones" Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Query on solution draft If you only signal the sending end's id in each message, it complicates logging, or else it complicates log analysis. Somebody needs to save state to fill in the "other" half of the id for log analysis. Paul K On 7/3/12 9:40 PM, Paul E. Jones wrote: > Sorry I did not reply on this thread sooner. > > What the proposed solution document currently says is that we concatenate > the two strings in a particular order. Obviously, I was happy with that, > but felt like I'd open that up for discussion since there had been some > dialog about the construction of the ID. > > I appreciated having a simple header like this: > > Session-ID-UUID: > > This would be the UUID of the sender of the message. I like that for a > variety of reasons. The "Session-ID" itself is a derived value, taking > components from the left-hand side (Alice) and right-hand side (Bob). The > construction rules should be well-defined. > > Question is, do we *need* to signal the entire Session-ID in the header: > > Session-ID: > > (Putting in "s" or "from" or ":" or whatever) > > Or is it enough to only send Session-ID-UUID? > > Note that there are some cases (complicated to explain and even harder to > debug) where we could have two ends changing UUID values simultaneously and > boxes in the middle of the network could receive messages that totally have > the wrong Session-ID header. > > I prefer signaling only one UUID. Do we *need* to include both in messages? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Saturday, June 30, 2012 11:54 AM >> To: James Polk >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Query on solution draft >> >> On 6/29/12 2:22 PM, James Polk wrote: >>> At 08:53 AM 6/29/2012, Paul Kyzivat wrote: >>>> On 6/28/12 10:19 PM, Paul E. Jones wrote: >>>>> James, >>>>> >>>>>> If we agree that once the whole Session-ID is compiled, meaning the >>>>>> GUID from UA1 and the GUID from UA2 are concatenated in some order, >>>>>> that header value remains on in all SIP messages between those 2 >>>>>> UAs until session termination or a transfer or join operation >>>>>> occurs. >>>>>> >>>>>> I think this is the right way forward. Is this agreeable to everyone? >>>>> >>>>> I'm OK with that so long as we indicate directionality. In the rare >>>>> event that two ends are joined to different calls are roughly the >>>>> same time, I would want intermediaries and the remote system to be >>>>> able to tell which of the two values UUIDs belong to the remote >>>>> device. Thus, something like: >>>>> >>>>> Session-ID: S:x;R:y >>>>> >>>>> (referring to the sender (S) of the message and the assumed >>>>> recipient (R)). >>>>> >>>>> If we do not do this, then Carol might receive this: >>>>> >>>>> Session-ID: XY >>>>> >>>>> And Carol knows her UUID is L and has no idea which value (X or Y) >>>>> belongs to the remote device. It's a rare case, but we can avoid it >>>>> ever becoming an issue by keeping the two UUIDs separated somehow. >>>>> This can be through "S:" tags or the order of placement (sender || >>>>> receiver). >>>> >>>> Be careful here. You seem to be trying to pile on two different >>>> semantics. On one hand you are trying to associate each "half" of the >>>> id with the end that assigned it. On the other hand, for comparing >>>> two IDs you don't care what end is associated with what half - you >>>> want the IDs from two messages sent in opposite directions to compare >> equal. >>>> >>>> For precedent, what you are describing is very comparable to the >>>> from-tag and to-tag. >>>> >>>> What Paul J is suggesting (S:, R:) can work as long as comparison >>>> rules are properly defined. E.g. (as I already proposed) to compare >>>> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to >>>> max(Ys, Yr). >>>> >>>> I'm inclined to suggest the following format: >>>> >>>> Session-ID: from=x; to=y >>>> >>>> to show the similarity to from and to tags. >>> >>> What I originally proposed was to order Alice's GUID first, then >>> Bob's, but make it implicit in which all observers of the Session-ID >>> header value could easily determine which was the initiator and which >>> was the responder - but only if the GUIDs were always of a known/fixed >>> length (i.e., always 24 or 32 bytes for each GUID). This is instead of >>> the analysis of which GUID is a greater value vs. which is a lessor >>> value and concatenate that way. >> >> I don't understand. Once a dialog is established, it needs to be the case >> that the sessionid is the same for messages sent by Alice and those sent >> by Bob. And I don't think you can count of figuring out which end >> initiated the dialog. (In some cases with B2BUAs, both ends may initiate, >> or sometimes the middle initiates toward both ends.) >> >> Thanks, >> Paul >> >>> With that model, when Bob transfers Alice to Carol, Alice's GUID would >>> remain part of the Session-ID while Bob's would be replaced by Carol's >>> (once she responds). >>> >>> Now, I know I haven't thought about all versions of joins to >>> appreciate if there is a corner case of join that breaks this model. >>> But, I'm not sure we need to include the 'S:'& 'R:' or 'from='& >>> 'to=' unless we determine we need to be explicit. If that's the case, >>> I'd like to see (i.e., a diagram of) an example of that corner case. >>> >>> WRT the idea of whether or not to have the GUIDs present in the >>> Session-ID header value, this is clean and not left to assumption as >>> to what is the other GUID value that is not in that SIP message. It's >>> not like we're attempting to hide one GUID from being seen on the >>> wire, that's what TLS is for if that's a concern. >>> >>> James >>> >>> >>>> Thanks, >>>> Paul >>>>_____________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> >>> >> >>_____________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > ------M9YZ3SDNTM7OV6AXGR2286UKHFS1WH Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yes, that's the trade off. Signaling both without somehow indicating which one belongs to the remote end can also cause confusion. I think the SIP header should allow each end to signals its value such that it is clear which value belongs to the other end. Its possible in a call join scenario where both ends do a join at the same time for an invite to come across the wire that has two uuids, one right and one wrong, but the receiver cannot tell what's right and intermediaries will log the wrong values.

Rare case, but can happen.

So, I like

Session-ID: alice/bob

Or similar.

Paul

From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Sent: Tue Jul 03 23:34:54 EDT 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: 'James Polk' <jmpolk@cisco.com>, insipid@ietf.org
Subject: Re: [Insipid] Query on solution draft

If you only signal the sending end's id in each message, it complicates 
logging, or else it complicates log analysis. Somebody needs to save 
state to fill in the "other" half of the id for log analysis.

	Paul K

On 7/3/12 9:40 PM, Paul E. Jones wrote:
> Sorry I did not reply on this thread sooner.
>
> What the proposed solution document currently says is that we concatenate
> the two strings in a particular order.  Obviously, I was happy with that,
> but felt like I'd open that up for discussion since there had been some
> dialog about the construction of the ID.
>
> I appreciated having a simple header like this:
>
> Session-ID-UUID:<uuid>
>
> This would be the UUID of the sender of the message.  I like that for a
> variety of reasons.  The "Session-ID" !
 itself
is a derived value, taking
> components from the left-hand side (Alice) and right-hand side (Bob).  The
> construction rules should be well-defined.
>
> Question is, do we *need* to signal the entire Session-ID in the header:
>
> Session-ID:<uuid-1><uuid-2>
>
> (Putting in "s" or "from" or ":" or whatever)
>
> Or is it enough to only send Session-ID-UUID?
>
> Note that there are some cases (complicated to explain and even harder to
> debug) where we could have two ends changing UUID values simultaneously and
> boxes in the middle of the network could receive messages that totally have
> the wrong Session-ID header.
>
> I prefer signaling only one UUID.  Do we *need* to include both in messages?
>
> Paul
>
>> -----Original Message-----
>> From: insipid-bounces@ietf.org
[mailto:insipid-bounces@ietf.org] On Behalf
>> Of Paul Kyzivat
>> Sent: Saturday, June 30, 2012 11:54 AM
>> To: James Polk
>> Cc: insipid@ietf.org
>> Subject: Re: [Insipid] Query on solution draft
>>
>> On 6/29/12 2:22 PM, James Polk wrote:
>>> At 08:53 AM 6/29/2012, Paul Kyzivat wrote:
>>>> On 6/28/12 10:19 PM, Paul E. Jones wrote:
>>>>> James,
>>>>>
>>>>>> If we agree that once the whole Session-ID is compiled, meaning the
>>>>>> GUID from UA1 and the GUID from UA2 are concatenated in some order,
>>>>>> that header value remains on in all SIP messages between those 2
>>>>>> UAs until session termination or a transfer or join operation
>>>>>> occurs.
>>>>>>
>>>>>> I thin!
 k this
is the right way forward. Is this agreeable to everyone?
>>>>>
>>>>> I'm OK with that so long as we indicate directionality. In the rare
>>>>> event that two ends are joined to different calls are roughly the
>>>>> same time, I would want intermediaries and the remote system to be
>>>>> able to tell which of the two values UUIDs belong to the remote
>>>>> device. Thus, something like:
>>>>>
>>>>> Session-ID: S:x;R:y
>>>>>
>>>>> (referring to the sender (S) of the message and the assumed
>>>>> recipient (R)).
>>>>>
>>>>> If we do not do this, then Carol might receive this:
>>>>>
>>>>> Session-ID: XY
>>>>>
>>>>> And Carol knows her UUID is L a!
 nd has
no idea which value (X or Y)
>>>>> belongs to the remote device. It's a rare case, but we can avoid it
>>>>> ever becoming an issue by keeping the two UUIDs separated somehow.
>>>>> This can be through "S:" tags or the order of placement (sender ||
>>>>> receiver).
>>>>
>>>> Be careful here. You seem to be trying to pile on two different
>>>> semantics. On one hand you are trying to associate each "half" of the
>>>> id with the end that assigned it. On the other hand, for comparing
>>>> two IDs you don't care what end is associated with what half - you
>>>> want the IDs from two messages sent in opposite directions to compare
>> equal.
>>>>
>>>> For precedent, what you are describing is very comparable to the
>>>> from-tag and to-tag.>>>>
>>>> What Paul J is suggesting (S:, R:) can work as long as comparison
>>>> rules are properly defined. E.g. (as I already proposed) to compare
>>>> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to
>>>> max(Ys, Yr).
>>>>
>>>> I'm inclined to suggest the following format:
>>>>
>>>> Session-ID: from=x; to=y
>>>>
>>>> to show the similarity to from and to tags.
>>>
>>> What I originally proposed was to order Alice's GUID first, then
>>> Bob's, but make it implicit in which all observers of the Session-ID
>>> header value could easily determine which was the initiator and which
>>> was the responder - but only if the GUIDs were always of a known/fixed
>>> length (i.e., always 24 or 32 bytes fo!
 r each
GUID). This is instead of
>>> the analysis of which GUID is a greater value vs. which is a lessor
>>> value and concatenate that way.
>>
>> I don't understand. Once a dialog is established, it needs to be the case
>> that the sessionid is the same for messages sent by Alice and those sent
>> by Bob. And I don't think you can count of figuring out which end
>> initiated the dialog. (In some cases with B2BUAs, both ends may initiate,
>> or sometimes the middle initiates toward both ends.)
>>
>> 	Thanks,
>> 	Paul
>>
>>> With that model, when Bob transfers Alice to Carol, Alice's GUID would
>>> remain part of the Session-ID while Bob's would be replaced by Carol's
>>> (once she responds).
>>>
>>> Now, I know I haven't thought about all versions of joins to
>>>
appreciate if there is a corner case of join that breaks this model.
>>> But, I'm not sure we need to include the 'S:'&  'R:' or 'from='&
>>> 'to=' unless we determine we need to be explicit. If that's the case,
>>> I'd like to see (i.e., a diagram of) an example of that corner case.
>>>
>>> WRT the idea of whether or not to have the GUIDs present in the
>>> Session-ID header value, this is clean and not left to assumption as
>>> to what is the other GUID value that is not in that SIP message. It's
>>> not like we're attempting to hide one GUID from being seen on the
>>> wire, that's what TLS is for if that's a concern.
>>>
>>> James
>>>
>>>
>>>> Thanks,
>>>> Paul
>>>>

>>>> insipid mailing list
>>>>
insipid@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/insipid
>>>
>>>
>>
>>

>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
>
>

------M9YZ3SDNTM7OV6AXGR2286UKHFS1WH-- From pkyzivat@alum.mit.edu Wed Jul 4 09:18:27 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2149D21F8724 for ; Wed, 4 Jul 2012 09:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_32=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 kLSVol9gyYLl for ; Wed, 4 Jul 2012 09:18:26 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 07AF821F874A for ; Wed, 4 Jul 2012 09:18:25 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id WBPh1j0081uE5Es53GJefq; Wed, 04 Jul 2012 16:18:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id WGJj1j00F3ZTu2S3cGJjgn; Wed, 04 Jul 2012 16:18:43 +0000 Message-ID: <4FF46CDB.2080704@alum.mit.edu> Date: Wed, 04 Jul 2012 12:18:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> <04e901cd5985$f062ed70$d128c850$@packetizer.com> <4FF3B9DE.4020202@alum.mit.edu> <827e51eb-6667-4db4-8b38-46e0a209ecab@email.android.com> In-Reply-To: <827e51eb-6667-4db4-8b38-46e0a209ecab@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 16:18:27 -0000 OK, it seems there are some conflicting desires here. Specifically, it seems hard to encode both "halves" of the id in a way that is the same for requests traveling in either direction, and to identify which half belongs to which end. This may be because the only way that has been suggested for distinguishing the two ends is by the direction of a request. This could be solved by carrying the half-id as a parameter of the From/To headers. (IOW a new and improved tag.) But this probably doesn't work because proxies aren't allowed to modify the From/To. It could also be addressed by tagging the half-ids with a param indicating if it is for the sender or receiver. This would have to be flipped for requests in the other direction. And this would need to be ignored when comparing IDs. If we just beefed up the requirements on from-tags and to-tags, then they could serve this purpose. But that would mean that for UAs that don't support this you could only fix it in B2BUAs, not proxies. But this might still be a most expedient way to go. Thanks, Paul Thanks, Paul On 7/4/12 11:57 AM, Paul E. Jones wrote: > Yes, that's the trade off. Signaling both without somehow indicating > which one belongs to the remote end can also cause confusion. I think > the SIP header should allow each end to signals its value such that it > is clear which value belongs to the other end. Its possible in a call > join scenario where both ends do a join at the same time for an invite > to come across the wire that has two uuids, one right and one wrong, but > the receiver cannot tell what's right and intermediaries will log the > wrong values. > > Rare case, but can happen. > > So, I like > > Session-ID: alice/bob > > Or similar. > > Paul > > ------------------------------------------------------------------------ > *From:* Paul Kyzivat > *Sent:* Tue Jul 03 23:34:54 EDT 2012 > *To:* "Paul E. Jones" > *Cc:* 'James Polk' , insipid@ietf.org > *Subject:* Re: [Insipid] Query on solution draft > > If you only signal the sending end's id in each message, it complicates > logging, or else it complicates log analysis. Somebody needs to save > state to fill in the "other" half of the id for log analysis. > > Paul K > > On 7/3/12 9:40 PM, Paul E. Jones wrote: >> Sorry I did not reply on this thread sooner. >> >> What the proposed solution document currently says is that we concatenate >> the two strings in a particular order. Obviously, I was happy with that, >> but felt like I'd open that up for discussion since there had been some >> dialog about the construction of the ID. >> >> I appreciated having a simple header like this: >> >> Session-ID-UUID: >> >> This would be the UUID of the sender of the message. I like that for a >> variety of reasons. The "Session-ID" ! > itself > is a derived value, taking >> components from the left-hand side (Alice) and right-hand side (Bob). The >> construction rules should be well-defined. >> >> Question is, do we *need* to signal the entire Session-ID in the header: >> >> Session-ID: >> >> (Putting in "s" or "from" or ":" or whatever) >> >> Or is it enough to only send Session-ID-UUID? >> >> Note that there are some cases (complicated to explain and even harder to >> debug) where we could have two ends changing UUID values simultaneously and >> boxes in the middle of the network could receive messages that totally have >> the wrong Session-ID header. >> >> I prefer signaling only one UUID. Do we *need* to include both in messages? >> >> Paul >> >>> -----Original Message----- >>> From: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Saturday, June 30, 2012 11:54 AM >>> To: James Polk >>> Cc: insipid@ietf.org >>> Subject: Re: [Insipid] Query on solution draft >>> >>> On 6/29/12 2:22 PM, James Polk wrote: >>>> At 08:53 AM 6/29/2012, Paul Kyzivat wrote: >>>>> On 6/28/12 10:19 PM, Paul E. Jones wrote: >>>>>> James, >>>>>> >>>>>>> If we agree that once the whole Session-ID is compiled, meaning the >>>>>>> GUID from UA1 and the GUID from UA2 are concatenated in some order, >>>>>>> that header value remains on in all SIP messages between those 2 >>>>>>> UAs until session termination or a transfer or join operation >>>>>>> occurs. >>>>>>> >>>>>>> I thin! > k this > is the right way forward. Is this agreeable to everyone? >>>>>> >>>>>> I'm OK with that so long as we indicate directionality. In the rare >>>>>> event that two ends are joined to different calls are roughly the >>>>>> same time, I would want intermediaries and the remote system to be >>>>>> able to tell which of the two values UUIDs belong to the remote >>>>>> device. Thus, something like: >>>>>> >>>>>> Session-ID: S:x;R:y >>>>>> >>>>>> (referring to the sender (S) of the message and the assumed >>>>>> recipient (R)). >>>>>> >>>>>> If we do not do this, then Carol might receive this: >>>>>> >>>>>> Session-ID: XY >>>>>> >>>>>> And Carol knows her UUID is L a! > nd has > no idea which value (X or Y) >>>>>> belongs to the remote device. It's a rare case, but we can avoid it >>>>>> ever becoming an issue by keeping the two UUIDs separated somehow. >>>>>> This can be through "S:" tags or the order of placement (sender || >>>>>> receiver). >>>>> >>>>> Be careful here. You seem to be trying to pile on two different >>>>> semantics. On one hand you are trying to associate each "half" of the >>>>> id with the end that assigned it. On the other hand, for comparing >>>>> two IDs you don't care what end is associated with what half - you >>>>> want the IDs from two messages sent in opposite directions to compare >>> equal. >>>>> >>>>> For precedent, what you are describing is very comparable to the >>>>> from-tag and to-tag.>>>> >>>>> What Paul J is suggesting (S:, R:) can work as long as comparison >>>>> rules are properly defined. E.g. (as I already proposed) to compare >>>>> IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and max(Xs, Xr) to >>>>> max(Ys, Yr). >>>>> >>>>> I'm inclined to suggest the following format: >>>>> >>>>> Session-ID: from=x; to=y >>>>> >>>>> to show the similarity to from and to tags. >>>> >>>> What I originally proposed was to order Alice's GUID first, then >>>> Bob's, but make it implicit in which all observers of the Session-ID >>>> header value could easily determine which was the initiator and which >>>> was the responder - but only if the GUIDs were always of a known/fixed >>>> length (i.e., always 24 or 32 bytes fo! > r each > GUID). This is instead of >>>> the analysis of which GUID is a greater value vs. which is a lessor >>>> value and concatenate that way. >>> >>> I don't understand. Once a dialog is established, it needs to be the case >>> that the sessionid is the same for messages sent by Alice and those sent >>> by Bob. And I don't think you can count of figuring out which end >>> initiated the dialog. (In some cases with B2BUAs, both ends may initiate, >>> or sometimes the middle initiates toward both ends.) >>> >>> Thanks, >>> Paul >>> >>>> With that model, when Bob transfers Alice to Carol, Alice's GUID would >>>> remain part of the Session-ID while Bob's would be replaced by Carol's >>>> (once she responds). >>>> >>>> Now, I know I haven't thought about all versions of joins to >>>> > appreciate if there is a corner case of join that breaks this model. >>>> But, I'm not sure we need to include the 'S:'& 'R:' or 'from='& >>>> 'to=' unless we determine we need to be explicit. If that's the case, >>>> I'd like to see (i.e., a diagram of) an example of that corner case. >>>> >>>> WRT the idea of whether or not to have the GUIDs present in the >>>> Session-ID header value, this is clean and not left to assumption as >>>> to what is the other GUID value that is not in that SIP message. It's >>>> not like we're attempting to hide one GUID from being seen on the >>>> wire, that's what TLS is for if that's a concern. >>>> >>>> James >>>> >>>> >>>>> Thanks, >>>>> Paul >>>>> > ------------------------------------------------------------------------ > >>>>> insipid mailing list >>>>> > insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>> >>>> >>> >>> > ------------------------------------------------------------------------ > >>> insipid mailing list >>> insipid@ietf.org >>> https://www.ietf.org/mailman/listinfo/insipid >> >> > From paulej@packetizer.com Wed Jul 4 17:14:44 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAED121F855A for ; Wed, 4 Jul 2012 17:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 GxVXHMWygM2P for ; Wed, 4 Jul 2012 17:14:43 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D336F21F8551 for ; Wed, 4 Jul 2012 17:14:42 -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 q650ErdQ019397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2012 20:14:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341447294; bh=gGhxvAr8rAXxjRav0VZp3eyLnA+M7DGDKy54rl+mvFk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ZJ13Wy17xD4nhdwpOQJYkRiDQXhCbWbuyKQCHmxV1E6k/58fkx5ZDaXCYeY7S0io0 GbmpxhtMBby3dcoZqWQaBWobZm6j8d0S/EkvJdZApzo1nzWi9FKSWlDAYdB3sEsohu PrSqYmm9kNTpeFAp9gWIZVbUZk/dyP4sMQa2qFUI= From: "Paul E. Jones" To: "'Ravindran, Parthasarathi'" , References: <04f101cd5988$d346cfb0$79d46f10$@packetizer.com> <387F9047F55E8C42850AD6B3A7A03C6C1605CDC7@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1605CDC7@inba-mail01.sonusnet.com> Date: Wed, 4 Jul 2012 20:15:01 -0400 Message-ID: <064001cd5a43$389ca0f0$a9d5e2d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0641_01CD5A21.B18BC440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxqH7wtTxaAUySFlSVSewTyI4r0gFdLTvjl0ZLsWA= Content-Language: en-us Subject: Re: [Insipid] Session-ID UUID vs something else 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, 05 Jul 2012 00:14:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0641_01CD5A21.B18BC440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Partha, Using Base64 is OK. No objection. It saves 8 octets. We could save 10 if we toss those last two "==" signs. They're fairly useless ;-) Paul From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] Sent: Tuesday, July 03, 2012 11:56 PM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] Session-ID UUID vs something else Paul, The concern of large URN UUID string(RFC 4122) is raised in SIPREC metadata unique-id as well. The base 64 URN UUID representation reduces the size of the URN UUID and it is mentioned in http://tools.ietf.org/html/draft-ietf-siprec-metadata-07. The sample base64 URN UUID is "hVpd7YQgRW2nD22h7q60JQ==". Here, there is no compromise in uniqueness w.r.t time and space as it is just a different encoding format in the wire. Please let me know opinion on base64 URN UUID usage. >From the requirement perspective, the unique id SHOULD meet uniqueness criteria w.r.t time and space as well as the size of the unique id has to be optimal. Thanks Partha From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, July 04, 2012 7:31 AM To: insipid@ietf.org Subject: [Insipid] Session-ID UUID vs something else Folks, We proposed using UUIDs since they are unique in time and space. The downside, though, is that they are large. We could make them smaller, perhaps just assigning random values. I suppose this is a requirements question. What is the requirement with respect to uniqueness in time and space for a Session-ID or the Session-ID component contributed by one endpoint? The present proposal we made would guarantee uniqueness in time and space (depending on the UUID version employed), but if the requirement is only to have a certain probability of no collisions, we could use a smaller string of random bits. Paul ------=_NextPart_000_0641_01CD5A21.B18BC440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Partha,

 

Using Base64 is = OK.  No objection.  It saves 8 octets.  We could save 10 = if we toss those last two “=3D=3D” signs.  = They’re fairly useless ;-)

 

Paul

 

 

From:= = Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] =
Sent: Tuesday, July 03, 2012 11:56 PM
To: Paul E. = Jones; insipid@ietf.org
Subject: RE: [Insipid] Session-ID UUID = vs something else

 

Paul,


The concern of large = URN UUID string(RFC 4122)  is raised in SIPREC metadata unique-id = as well. The base 64 URN UUID representation reduces the size of the URN = UUID and it is mentioned in http://tools.ietf.org/html/draft-ietf-siprec-metadat= a-07.  The sample base64 URN UUID is = “hVpd7YQgRW2nD22h7q60JQ=3D=3D”. Here, there is no compromise = in uniqueness w.r.t time and space as it is just a different encoding = format in the wire.  Please let me know opinion on base64 URN UUID = usage.

 

From the requirement = perspective, the unique id SHOULD meet uniqueness criteria w.r.t time = and space as well as the  size of the unique id has to be = optimal.

 

Thanks

Partha

 

From:= = insipid-bounces@ietf.org = [mailto:insipid-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: = Wednesday, July 04, 2012 7:31 AM
To: insipid@ietf.org
Subject: = [Insipid] Session-ID UUID vs something = else

 

Folks,

 

We proposed = using UUIDs since they are unique in time and space.  The downside, = though, is that they are large.

 

We could = make them smaller, perhaps just assigning random = values.

 

I suppose this is a requirements question.  What = is the requirement with respect to uniqueness in time and space for a = Session-ID or the Session-ID component contributed by one = endpoint?  The present proposal we made would guarantee uniqueness = in time and space (depending on the UUID version employed), but if the = requirement is only to have a certain probability of no collisions, we = could use a smaller string of random bits.

 

Paul

 

------=_NextPart_000_0641_01CD5A21.B18BC440-- From paulej@packetizer.com Wed Jul 4 17:18:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD6021F8570 for ; Wed, 4 Jul 2012 17:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_31=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 cmnsNroNnWiM for ; Wed, 4 Jul 2012 17:18:19 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9321F856F for ; Wed, 4 Jul 2012 17:18:19 -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 q650IUAk019502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2012 20:18:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341447510; bh=UfGOwt5Q/79T0XtrNUyAvwTXIx2Qh9tGhYgv0By/C7I=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=n1tkqLmncuyttEqjFYJUWbntbHCUswF0Llqf0qObrhueoj/93zeUVRLIBf86LESTl 9qtWtXct35QHwWX1stQrfWGIKag40XDLHs57UtezEVIvH8nX8EeZAq53Gd15I+Mcvg T68yN+MsMqIwvL93DAhS/6Ro4iaD07oW/GOLoLbo= From: "Paul E. Jones" To: "'Laura Liess'" References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> In-Reply-To: Date: Wed, 4 Jul 2012 20:18:37 -0400 Message-ID: <064d01cd5a43$b97b8100$2c728300$@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: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAAIZ3s8FAiAEuxqYnD/mkA== Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 05 Jul 2012 00:18:20 -0000 I'm confused. We did not add anything to REQ1 recently. REQ1a is an entirely separate requirement. You really want to just remove that text from c)? Paul > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Wednesday, July 04, 2012 4:15 AM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: Text proposal for the "SIP traffic monitoring" use case > > Paul, > > I am fine with the text. For use case c) please just remove "(eventually > REQ1a)" because REQ 1a is now included into REQ1. > > Thank you > Laura > > 2012/7/4 Paul E. Jones : > > Laura, > > > > I re-worded what you proposed. Tell me if this is acceptable: > > > > User Agent A (A) and User Agent B (B) communicate using SIP messaging > > with a SIP B2BUA acting as a middlebox. For privacy reasons, the B2BUA > > changes SIP headers that reveal information related to the SIP user, > > device or domain identity. The service provider uses an external > > device to monitor and log all SIP traffic coming from the B2BUA. In > > the case of failures reported by the customer or when security issue > > arise (e.g. theft of service), the service provider has to analyze the > > logs, including its own logs and perhaps logs provided by the > > customer, for the past several days or weeks and correlate those > > messages which were messages for a single end-to-end SIP session. > > > > For this scenario, we must consider three particular use cases: > > > > a) The software on A and B can be upgraded by the service provider to > > support a single end-to-end Session Identifier. > > > > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8. > > > > b) Only software on A can be upgraded by the service provider to > > support the new identifier. > > > > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. > > > > c) Neither the software on A nor B can be upgraded by the service > > provider to support the new identifier. > > > > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. > > > > Should I remove "eventually REQ1a" and just put "REQ1a"? > > > > Paul > > > >> -----Original Message----- > >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > >> Sent: Wednesday, June 27, 2012 5:19 AM > >> To: Paul Jones > >> Cc: insipid@ietf.org > >> Subject: Text proposal for the "SIP traffic monitoring" use case > >> > >> Paul, > >> > >> Please find enclosed a text proposal for the use case "SIP traffic > >> monitoring": > >> > >> > >> SIP traffic monitoring > >> > >> UA-A and UA-B communicate using SIP phone calls and SIP messaging > >> with a SIP B2BUA acting as a middlebox. The B2BUA changes any SIP > >> header revealing information related to the SIP user, device or domain > identity. > >> The service provider uses an external device to monitor and log "on > >> the wire" all SIP traffic passed through the B2BUA. In case of > >> failures being reported by the customers or of security issues (e.g. > >> theft of service), the service provider has to analyse the logs for > >> the past days or weeks and correlate those messages which where, at > >> some point in time, components of a single end-to-end SIP session > >> (e.g., parts of the same phone call or transfer of the same message). > >> > >> For this scenario, we must consider three particular use cases: > >> > >> a) The UA-A and UA-B software can be upgraded by the service > provider > >> to support the new identifier. . > >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, > REQ8. > >> > >> b) Only the UA-A software can be upgraded by the service provider > to > >> support the new identifier, the UA-B software can not. > >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, > >> REQ7, REQ8. > >> > >> c) Neither the UA-A nor the UA-B software can be upgraded by the > >> service provider to support the new identifier, the UA-B software can > not. > >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, > >> REQ7, REQ8. > >> > >> Thanks > >> Laura > > From paulej@packetizer.com Wed Jul 4 17:27:21 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6841121F857D for ; Wed, 4 Jul 2012 17:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_32=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 EK7RO1Z5E7hR for ; Wed, 4 Jul 2012 17:27:20 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE6A21F853F for ; Wed, 4 Jul 2012 17:27:20 -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 q650RTFX019719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2012 20:27:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341448050; bh=QN+Eh8EpdH8xSH5k3sVQb8zNwcADlWsuzDc3JfOsm8U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ieZo/4rKDR3oNisLyxqYXK81QbFc5WXzpCFTrFSS7Xtn4B/Gqhg//jHrch2z0Os1C NnSfF8vShbzf6OmWAglFkug8xWenC2YV/wYEHn82wZa1ZAVqBY3ieMEjrVMJdgOzff hAW5wNwXfhy41dkkmUB94HztSC/8E45qVfWDXAeY= From: "Paul E. Jones" To: "'Ravindran, Parthasarathi'" , "'Paul Kyzivat'" References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> <04e901cd5985$f062ed70$d128c850$@packetizer.com> <4FF3B9DE.4020202@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C1605CE89@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1605CE89@inba-mail01.sonusnet.com> Date: Wed, 4 Jul 2012 20:27:37 -0400 Message-ID: <065501cd5a44$fb4d3730$f1e7a590$@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: AQK7RB41zBRhsBQ7e9n1g4StVSTSxQHV1wfwAlkbTJgCnzjdJwHoS8GOAqbHfBEBLNh5fgJQM/rUAbc0V4IBwIR8swLi5lYilJRYFOA= Content-Language: en-us Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 00:27:21 -0000 Partha, You're largely correct, but let's suppose you are Alice and you receive an INVITE that has: Session-ID: D||E Neither of those identifiers belong to Alice, so which one belongs to the remote endpoint? This *can* happen when we have two PBXes in the path, for example, that independently perform a call "join" operation and fabricate INVITE messages on behalf of a device and toward a remote device that is now not a party to the call. :-) It's an unusual event, I know, but I prefer to avoid corner cases if we can. What we call the Session-ID should be the concatenation of two values as we've prescribed in the solution document. However, there was a reason for sending each UUID separately. This is one of them. If we put both UUIDs into the message (when available), I'd prefer a format like: Session-ID: [:] So, the sender of the message always puts its value first, then we have a separator of some sort, and then the receiver's UUID. In this way, the device that receives a message with some value "D:E" would know that the remote side's UUID is D and it was unaware of a recent change where messages are now being directed to it (device C). It can then reply and, in parallel, inform the remote side of this change in UUIDs: Session-ID: C:D Just so people do not consider this is the Session-ID, perhaps we continue to use "Session-ID-UUID" as the header? Paul > -----Original Message----- > From: Ravindran, Parthasarathi [mailto:pravindran@sonusnet.com] > Sent: Wednesday, July 04, 2012 4:26 AM > To: Paul Kyzivat; Paul E. Jones > Cc: 'James Polk'; insipid@ietf.org > Subject: RE: [Insipid] Query on solution draft > > It is preferred to have two piece of information rather than one as each > end form its own id and make the unique id based on its concatenation. > > There is no need to spell out in the session-id whether it is "from" piece > or "to" piece as it does not matter during the mid-dialog and it is > subjected to change due to different SIP application/services. > > Thanks > Partha > > >-----Original Message----- > >From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >Behalf Of Paul Kyzivat > >Sent: Wednesday, July 04, 2012 9:05 AM > >To: Paul E. Jones > >Cc: 'James Polk'; insipid@ietf.org > >Subject: Re: [Insipid] Query on solution draft > > > >If you only signal the sending end's id in each message, it complicates > >logging, or else it complicates log analysis. Somebody needs to save > >state to fill in the "other" half of the id for log analysis. > > > > Paul K > > > >On 7/3/12 9:40 PM, Paul E. Jones wrote: > >> Sorry I did not reply on this thread sooner. > >> > >> What the proposed solution document currently says is that we > >> concatenate the two strings in a particular order. Obviously, I was > >> happy with that, but felt like I'd open that up for discussion since > >> there had been some dialog about the construction of the ID. > >> > >> I appreciated having a simple header like this: > >> > >> Session-ID-UUID: > >> > >> This would be the UUID of the sender of the message. I like that for > >> a variety of reasons. The "Session-ID" itself is a derived value, > >> taking components from the left-hand side (Alice) and right-hand side > >> (Bob). The construction rules should be well-defined. > >> > >> Question is, do we *need* to signal the entire Session-ID in the > >header: > >> > >> Session-ID: > >> > >> (Putting in "s" or "from" or ":" or whatever) > >> > >> Or is it enough to only send Session-ID-UUID? > >> > >> Note that there are some cases (complicated to explain and even > >> harder to > >> debug) where we could have two ends changing UUID values > >> simultaneously and boxes in the middle of the network could receive > >> messages that totally have the wrong Session-ID header. > >> > >> I prefer signaling only one UUID. Do we *need* to include both in > >messages? > >> > >> Paul > >> > >>> -----Original Message----- > >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >>> Behalf Of Paul Kyzivat > >>> Sent: Saturday, June 30, 2012 11:54 AM > >>> To: James Polk > >>> Cc: insipid@ietf.org > >>> Subject: Re: [Insipid] Query on solution draft > >>> > >>> On 6/29/12 2:22 PM, James Polk wrote: > >>>> At 08:53 AM 6/29/2012, Paul Kyzivat wrote: > >>>>> On 6/28/12 10:19 PM, Paul E. Jones wrote: > >>>>>> James, > >>>>>> > >>>>>>> If we agree that once the whole Session-ID is compiled, meaning > >>>>>>> the GUID from UA1 and the GUID from UA2 are concatenated in some > >>>>>>> order, that header value remains on in all SIP messages between > >>>>>>> those 2 UAs until session termination or a transfer or join > >>>>>>> operation occurs. > >>>>>>> > >>>>>>> I think this is the right way forward. Is this agreeable to > >everyone? > >>>>>> > >>>>>> I'm OK with that so long as we indicate directionality. In the > >>>>>> rare event that two ends are joined to different calls are > >>>>>> roughly the same time, I would want intermediaries and the remote > >>>>>> system to be able to tell which of the two values UUIDs belong to > >>>>>> the remote device. Thus, something like: > >>>>>> > >>>>>> Session-ID: S:x;R:y > >>>>>> > >>>>>> (referring to the sender (S) of the message and the assumed > >>>>>> recipient (R)). > >>>>>> > >>>>>> If we do not do this, then Carol might receive this: > >>>>>> > >>>>>> Session-ID: XY > >>>>>> > >>>>>> And Carol knows her UUID is L and has no idea which value (X or > >>>>>> Y) belongs to the remote device. It's a rare case, but we can > >>>>>> avoid it ever becoming an issue by keeping the two UUIDs > >>>>>> separated > >somehow. > >>>>>> This can be through "S:" tags or the order of placement (sender > >>>>>> || receiver). > >>>>> > >>>>> Be careful here. You seem to be trying to pile on two different > >>>>> semantics. On one hand you are trying to associate each "half" of > >>>>> the id with the end that assigned it. On the other hand, for > >>>>> comparing two IDs you don't care what end is associated with what > >>>>> half - you want the IDs from two messages sent in opposite > >>>>> directions to compare > >>> equal. > >>>>> > >>>>> For precedent, what you are describing is very comparable to the > >>>>> from-tag and to-tag. > >>>>> > >>>>> What Paul J is suggesting (S:, R:) can work as long as comparison > >>>>> rules are properly defined. E.g. (as I already proposed) to > >>>>> compare IDs X and Y, compare min(Xs, Xr) to min(Ys, Yr) and > >>>>> max(Xs, Xr) to max(Ys, Yr). > >>>>> > >>>>> I'm inclined to suggest the following format: > >>>>> > >>>>> Session-ID: from=x; to=y > >>>>> > >>>>> to show the similarity to from and to tags. > >>>> > >>>> What I originally proposed was to order Alice's GUID first, then > >>>> Bob's, but make it implicit in which all observers of the > >>>> Session-ID header value could easily determine which was the > >>>> initiator and which was the responder - but only if the GUIDs were > >>>> always of a known/fixed length (i.e., always 24 or 32 bytes for > >>>> each GUID). This is instead of the analysis of which GUID is a > greater value vs. > >>>> which is a lessor value and concatenate that way. > >>> > >>> I don't understand. Once a dialog is established, it needs to be the > >>> case that the sessionid is the same for messages sent by Alice and > >>> those sent by Bob. And I don't think you can count of figuring out > >>> which end initiated the dialog. (In some cases with B2BUAs, both > >>> ends may initiate, or sometimes the middle initiates toward both > >>> ends.) > >>> > >>> Thanks, > >>> Paul > >>> > >>>> With that model, when Bob transfers Alice to Carol, Alice's GUID > >>>> would remain part of the Session-ID while Bob's would be replaced > >>>> by Carol's (once she responds). > >>>> > >>>> Now, I know I haven't thought about all versions of joins to > >>>> appreciate if there is a corner case of join that breaks this model. > >>>> But, I'm not sure we need to include the 'S:'& 'R:' or 'from='& > >>>> 'to=' unless we determine we need to be explicit. If that's the > >>>> case, I'd like to see (i.e., a diagram of) an example of that > >>>> corner > >case. > >>>> > >>>> WRT the idea of whether or not to have the GUIDs present in the > >>>> Session-ID header value, this is clean and not left to assumption > >>>> as to what is the other GUID value that is not in that SIP message. > >>>> It's not like we're attempting to hide one GUID from being seen on > >>>> the wire, that's what TLS is for if that's a concern. > >>>> > >>>> James > >>>> > >>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> insipid mailing list > >>>>> insipid@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/insipid > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >> > >> > > > >_______________________________________________ > >insipid mailing list > >insipid@ietf.org > >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Wed Jul 4 17:55:07 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E174021F8493 for ; Wed, 4 Jul 2012 17:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_31=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 QxClRlxV+aI1 for ; Wed, 4 Jul 2012 17:55:07 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5605C21F856F for ; Wed, 4 Jul 2012 17:55:07 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q650tHAH020401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jul 2012 20:55:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341449717; bh=/3I63ZfHkw019w0G2GE7nBmAwiwUukmdaSwNjUIW6T8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=TtMDWCQ3Qluz4d2wapZVURLS4UgR9dD9gD+R5KlQKK7x87U1cXfZ4ix/OvQ7dyYzV vkfJoloywQbOMqpCjJP58AtfMREvSpRAIPZMDC9dS5Cwilnk66x70KRPEwm394v8qf jkNCkU1K6lUi6UMKjLX5tk0jFYNmHvN0KonRWQCU= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <04f201cd54d7$0bb670a0$232351e0$@packetizer.com> <201206281946.q5SJkG0P004325@mtv-core-4.cisco.com> <06a401cd559d$8ecfec70$ac6fc550$@packetizer.com> <4FEDB35D.3020001@alum.mit.edu> <201206291822.q5TIMcbq011640@mtv-core-2.cisco.com> <4FEF211C.8030806@alum.mit.edu> <04e901cd5985$f062ed70$d128c850$@packetizer.com> <4FF3B9DE.4020202@alum.mit.edu> <827e51eb-6667-4db4-8b38-46e0a209ecab@email.android.com> <4FF46CDB.2080704@alum.mit.edu> In-Reply-To: <4FF46CDB.2080704@alum.mit.edu> Date: Wed, 4 Jul 2012 20:55:24 -0400 Message-ID: <066b01cd5a48$dd199980$974ccc80$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7RB41zBRhsBQ7e9n1g4StVSTSxQHV1wfwAlkbTJgCnzjdJwHoS8GOAqbHfBEBLNh5fgJQM/rUAbc0V4IBwIR8swJxSK2eAo3lgGWUg34wkA== Content-Language: en-us Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Query on solution draft X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 00:55:08 -0000 Paul, > OK, it seems there are some conflicting desires here. No, just not being clear, I think. =20 > Specifically, it seems hard to encode both "halves" of the id in a way > that is the same for requests traveling in either direction, and to > identify which half belongs to which end. This may be because the only = way > that has been suggested for distinguishing the two ends is by the > direction of a request. Indeed. So, I never proposed having the same header going in each = direction. In the current solution spec, we propose Alice sends: Session-ID-UUID: A And Bob sends: Session-ID-UUID: B If we wish to include both (or as much as a device knows), Alice might = send: Session-ID-UUID: A:B And Bob would send: Session-ID-UUID: B:A The Session-ID is always: Session_ID =3D min(A,B) || max(A,B) This is computed value may be used by the endpoints or intermediaries. =20 > This could be solved by carrying the half-id as a parameter of the = From/To > headers. (IOW a new and improved tag.) But this probably doesn't work > because proxies aren't allowed to modify the From/To. Perhaps. We also want to ensure transparency and using any existing = header concerns me. =20 > It could also be addressed by tagging the half-ids with a param = indicating > if it is for the sender or receiver. This would have to be flipped for > requests in the other direction. And this would need to be ignored = when > comparing IDs. We can tag it or order it, I don't care. Explicit ordering makes for = faster processing. =20 > If we just beefed up the requirements on from-tags and to-tags, then = they > could serve this purpose. But that would mean that for UAs that don't > support this you could only fix it in B2BUAs, not proxies. But this = might > still be a most expedient way to go. Not sure how this would make life any easier. Not disagreeing, but just = don't see it. Paul From keith.drage@alcatel-lucent.com Thu Jul 5 10:23:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4521F8697 for ; Thu, 5 Jul 2012 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.984 X-Spam-Level: X-Spam-Status: No, score=-109.984 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGZACUWrvLvQ for ; Thu, 5 Jul 2012 10:23:39 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 698E121F86DC for ; Thu, 5 Jul 2012 10:23:39 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q65HNnRW016210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 5 Jul 2012 19:23:49 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 5 Jul 2012 19:23:49 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Thu, 5 Jul 2012 19:23:46 +0200 Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wHTtl+w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [Insipid] Call for WG adoption of text to 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, 05 Jul 2012 17:23:40 -0000 (As WG cochair) A reminder that you have the rest of the day to respond on this if you have= not already done so. I will declare a decision tomorrow morning. Keith -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: 26 June 2012 11:11 To: insipid@ietf.org Subject: [Insipid] Call for WG adoption of text to (As WG cochair) In pursuance of the charter milestone: Aug 2012 Requirements and use cases for new identifier sent to IESG (as in= formational) I'd like to issue a call to adopt the text of: draft-jones-insipid-session-id-reqts-03 http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt=20 for this work. The intent of the milestone is for a document that has: - use cases - requirements - how requirements are derived from the use cases There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads).=20 It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable). Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC. Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84). Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Thu Jul 5 10:25:41 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7655F21F879A for ; Thu, 5 Jul 2012 10:25:41 -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.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIHcvJ8TlNsQ for ; Thu, 5 Jul 2012 10:25:40 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 535E321F8795 for ; Thu, 5 Jul 2012 10:25:40 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q65HPqWT008387 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jul 2012 19:25:53 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 5 Jul 2012 19:25:52 +0200 From: "DRAGE, Keith (Keith)" To: "Hutton, Andrew" , "insipid@ietf.org" Date: Thu, 5 Jul 2012 19:25:48 +0200 Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wBtdaBQAWZRXpA= Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF031381@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF031381@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] Call for WG adoption of text to 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, 05 Jul 2012 17:25:41 -0000 (As WG chair) Can you be more explicit about which text you are unhappy with. Remember the preferred answer was one of: > Please respond (Yes, Yes but only for sections ... / except for > sections ..., or No) by close of business on the 5th July (so that > assuming assent, we can meet the -00 cutoff and issue this as a WG item > before IETF#84). Regards Keith -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 Sent: 28 June 2012 15:30 To: DRAGE, Keith (Keith); insipid@ietf.org Subject: RE: [Insipid] Call for WG adoption of text to Hi, I am ok with adopting this draft. However I still have some concerns about the use case and associated requir= ements relating to associating media with signaling using this identifier. = Although this might be useful in some circumstances I don't think it is wit= hin the scope of the charter and potentially opens up some complexity that = in the interest of getting things done we should avoid. Also we probably need to look more closely at the transfer use cases but we= can do this after adoption. Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 26 June 2012 06:11 > To: insipid@ietf.org > Subject: [Insipid] Call for WG adoption of text to >=20 > (As WG cochair) >=20 > In pursuance of the charter milestone: >=20 > Aug 2012 Requirements and use cases for new identifier sent to IESG > (as informational) >=20 > I'd like to issue a call to adopt the text of: >=20 > draft-jones-insipid-session-id-reqts-03 >=20 > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt >=20 > for this work. >=20 > The intent of the milestone is for a document that has: > - use cases > - requirements > - how requirements are derived from the use cases >=20 > There is still material to be added in this respect, but this can be > done as a WG item. (And I would encourage all to contribute to the use > cases in parallel to this call, i.e. separate mail threads). >=20 > It is also appropriate to respond indicating that only part of the text > is acceptable (in which case we can defer the remaining text for > further consideration as input to the deliverable). >=20 > Note that the text does not have to be perfect at this stage, merely > that you believe the text is appropriate for progressing by comment and > review within the scope of WG discussions and WGLC. >=20 > Please respond (Yes, Yes but only for sections ... / except for > sections ..., or No) by close of business on the 5th July (so that > assuming assent, we can meet the -00 cutoff and issue this as a WG item > before IETF#84). >=20 > Regards >=20 > Keith >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Thu Jul 5 10:53:08 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1B21F8522 for ; Thu, 5 Jul 2012 10:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMXx5VC8tz8h for ; Thu, 5 Jul 2012 10:53:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6DE21F850F for ; Thu, 5 Jul 2012 10:53:07 -0700 (PDT) X-AuditID: c1b4fb25-b7fc16d000005db2-d8-4ff5d4907802 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B6.61.23986.094D5FF4; Thu, 5 Jul 2012 19:53:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 5 Jul 2012 19:53:20 +0200 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Date: Thu, 5 Jul 2012 19:53:10 +0200 Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wHUxfig Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853405AF4190@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvre7EK1/9Db7vZLKYf/8Zk8XTxrOM Dkwerc/2snosWfKTKYApissmJTUnsyy1SN8ugStjyXrNgml8FfPW3WJtYFzJ3cXIySEhYCKx /v0RJghbTOLCvfVsXYxcHEICpxglVi16wgrhzGGUWLB1AXMXIwcHm4CFRPc/bZAGEYEUiUUz 5jCC2CwCKhJ/f7aA2cICZhLTflxjhqgxl7j+ezsjhG0ksX/nO7A4r0C4xL4Tc1lBbCGBWInt t8+B2ZwCcRJdfTtYQGxGoIO+n1oDdhyzgLjErSfzoQ4VkFiy5zwzhC0q8fLxP1aIelGJO+3r GSHqdSQW7P7EBmFrSyxb+Bpqr6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilE4NzEzJ73c SC+1KDO5uDg/T684dRMjMEIObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamDcubOn8np52+UL9UeTJiTPT53i+0po41eVvaY/y+1N+BQ1VFtD7acW+rH5 Hfj73nl/xCq9tJl+327+KLh/clVObkodZ1Db+2fLp0la9Xkl/ZSRLO86u1F3p5KTl/Z3jWe6 Zhm2K3iYNetWzIhoqv63tZz3ydsfr7Y4xp50bXdZf0eQa/GKDGklluKMREMt5qLiRAAbmyXa XgIAAA== Subject: Re: [Insipid] Call for WG adoption of text to 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, 05 Jul 2012 17:53:08 -0000 Yes. Regards, Christer ________________________________________ From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] On Behalf Of DRAG= E, Keith (Keith) [keith.drage@alcatel-lucent.com] Sent: Tuesday, June 26, 2012 1:10 PM To: insipid@ietf.org Subject: [Insipid] Call for WG adoption of text to (As WG cochair) In pursuance of the charter milestone: Aug 2012 Requirements and use cases for new identifier sent to IESG = (as informational) I'd like to issue a call to adopt the text of: draft-jones-insipid-session-id-reqts-03 http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt for this work. The intent of the milestone is for a document that has: - use cases - requirements - how requirements are derived from the use cases There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads). It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable). Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC. Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84). Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid= From gsalguei@cisco.com Thu Jul 5 12:57:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3697821F85C3 for ; Thu, 5 Jul 2012 12:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5lWC+xamSlT for ; Thu, 5 Jul 2012 12:57:30 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD6921F85AA for ; Thu, 5 Jul 2012 12:57:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q65Jvish012303 for ; Thu, 5 Jul 2012 15:57:44 -0400 (EDT) Received: from rtp-gsalguei-8718.cisco.com (rtp-gsalguei-8718.cisco.com [10.116.61.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q65JvhJ9005497 for ; Thu, 5 Jul 2012 15:57:43 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jul 2012 15:57:43 -0400 Message-Id: <120E2743-E9D0-4A05-AD8B-BFC8195BBC70@cisco.com> To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] INSIPID WG Virtual Interim #3 Meeting: Dial-in details via Webex 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, 05 Jul 2012 19:57:31 -0000 Folks -=20 Reminder that, as discussed at the last interim meeting, we will host = the INSIPID Virtual Interim #3 meeting (July 10th at 9 AM Pacific = Daylight Time). See below for the agenda and "dial-in" details. [Note: = slides can be found on the proceedings page for this interim meeting: = http://www.ietf.org/proceedings/interim/2012/07/10/insipid/proceedings.htm= l] Cheers, Gonzalo (as co-chair) ------------------------------------------ Agenda: 1) Note well, agenda bash, notetakers, etc.=20 Presenters: Chairs (5 min) 2) Discussion of requirements draft WG adoption and pending issues = (cont'd)=20 Presenters: Paul Jones, James Polk (30 min) Drafts: draft-jones-insipid-session-id-reqts = http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts 3) Review of proposed solutions=20 Presenters: Paul Jones, James Polk (70 min) Drafts: draft-jones-insipid-session-id-00 http://tools.ietf.org/html/draft-jones-insipid-session-id [Note: We encourage folks to submit any candidate solutions for session = id that they wish to be considered by the WG] 4) Preparation for IETF84 and Next steps=20 Presenters: Chairs (15 min) --------------------------------- WEBEX DETAILS INtermediary-safe SIP session ID (INSIPID) Group invites you to attend = this online meeting.=20 Topic: INSIPID WG Virtual Interm #3=20 Date: Tuesday, July 10, 2012=20 Time: 8:45 pm, Pacific Daylight Time (San Francisco, GMT-07:00)=20 Meeting Number: 968 066 788=20 Meeting Password: insipid=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D194761907&UID=3D128899529= 7&PW=3DNYWNlMDdmNGRh&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: insipid=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D194761907&UID=3D128899529= 7&PW=3DNYWNlMDdmNGRh&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D194761907&tollFree=3D0=20 Access code:968 066 788=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://workgreen.webex.com/workgreen/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 cmorgan@amsl.com=20 1-510-492-4085=20 To add this meeting to your calendar program (for example Microsoft = Outlook), click this link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D194761907&UID=3D128899529= 7&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DLSuJ-uet6/97I8M5a0K34pFVZkK/TtoQgQT= nHgYZq8Y=3D&RT=3DMiM0=20 The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in = the meeting, please check whether you have the players installed on your = computer by going to = https://workgreen.webex.com/workgreen/systemdiagnosis.php.=20 Sign up for a free trial of WebEx=20 http://www.webex.com/go/mcemfreetrial=20 http://www.webex.com=20 CCP:+14087926300x968066788#=20 IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 ------------------------------------------ From jan.van.geel@belgacom.be Thu Jul 5 23:24:42 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E521F876F for ; Thu, 5 Jul 2012 23:24:42 -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 IFFU8ipdAZA1 for ; Thu, 5 Jul 2012 23:24:41 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA521F86FE for ; Thu, 5 Jul 2012 23:24:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,536,1336341600"; d="scan'208";a="13937688" Received: from unknown (HELO A03008.BGC.NET) ([10.121.129.162]) by mx13.belgacom.be with ESMTP; 06 Jul 2012 08:24:54 +0200 X-TM-IMSS-Message-ID: <11e382db00038d19@belgacom.be> Received: from A04022.BGC.NET ([10.120.135.23]) by belgacom.be ([10.121.129.162]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 11e382db00038d19 ; Fri, 6 Jul 2012 08:24:53 +0200 Received: from A04067.BGC.NET ([10.121.135.38]) by A04022.BGC.NET ([10.120.135.23]) with mapi id 14.01.0355.002; Fri, 6 Jul 2012 08:24:53 +0200 From: "VAN GEEL Jan (CIS/SCC)" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wHTtl+wABs7JZA= Date: Fri, 6 Jul 2012 06:24:52 +0000 Message-ID: <1E97FFD1485F1142BC075FF145A53A1E0FF5B5@A04067.BGC.NET> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.29.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Call for WG adoption of text to 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, 06 Jul 2012 06:24:42 -0000 I support the adoption of this draft Jan Van Geel IT and Network Specialist Belgacom SDE/SDV/PSE/FVC Tel: +32 2 202 1035 Tel: +32 2 207 9032 Email : jan.van.geel@belgacom.be -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: Thursday 5 July 2012 19:24 To: insipid@ietf.org Subject: Re: [Insipid] Call for WG adoption of text to (As WG cochair) A reminder that you have the rest of the day to respond on this if you have= not already done so. I will declare a decision tomorrow morning. Keith -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: 26 June 2012 11:11 To: insipid@ietf.org Subject: [Insipid] Call for WG adoption of text to (As WG cochair) In pursuance of the charter milestone: Aug 2012 Requirements and use cases for new identifier sent to IESG = (as informational) I'd like to issue a call to adopt the text of: draft-jones-insipid-session-id-reqts-03 http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt for this work. The intent of the milestone is for a document that has: - use cases - requirements - how requirements are derived from the use cases There is still material to be added in this respect, but this can be done a= s a WG item. (And I would encourage all to contribute to the use cases in p= arallel to this call, i.e. separate mail threads). It is also appropriate to respond indicating that only part of the text is = acceptable (in which case we can defer the remaining text for further consi= deration as input to the deliverable). Note that the text does not have to be perfect at this stage, merely that y= ou believe the text is appropriate for progressing by comment and review wi= thin the scope of WG discussions and WGLC. Please respond (Yes, Yes but only for sections ... / except for sections ..= ., or No) by close of business on the 5th July (so that assuming assent, we= can meet the -00 cutoff and issue this as a WG item before IETF#84). Regards Keith _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer From andrew.hutton@siemens-enterprise.com Fri Jul 6 00:39:00 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807FF21F86DC for ; Fri, 6 Jul 2012 00:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 9kN0UvAQp0Gh for ; Fri, 6 Jul 2012 00:38:59 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9A75221F85C6 for ; Fri, 6 Jul 2012 00:38:59 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1AC8D23F0511; Fri, 6 Jul 2012 09:39:14 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.34]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.01.0339.001; Fri, 6 Jul 2012 09:39:13 +0200 From: "Hutton, Andrew" To: "DRAGE, Keith (Keith)" , "insipid@ietf.org" Thread-Topic: [Insipid] Call for WG adoption of text to Thread-Index: Ac1Tg/KbWPYrQuCaRMCVkuYAj8xh5wBtdaBQAWZRXpAAHcNtMA== Date: Fri, 6 Jul 2012 07:39:13 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0374FD@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF031381@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.27.255.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Call for WG adoption of text to 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, 06 Jul 2012 07:39:00 -0000 Hi Keith, The following use case is the one I have concerns with. "* Association of session signaling and media flows, made possible by inclu= ding the session identifier in media-related messages (e.g., RSVP or RTCP)"= . Regards Andy > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of DRAGE, Keith (Keith) > Sent: 05 July 2012 18:26 > To: Hutton, Andrew; insipid@ietf.org > Subject: Re: [Insipid] Call for WG adoption of text to >=20 > (As WG chair) >=20 > Can you be more explicit about which text you are unhappy with. >=20 > Remember the preferred answer was one of: >=20 > > Please respond (Yes, Yes but only for sections ... / except for > > sections ..., or No) by close of business on the 5th July (so that > > assuming assent, we can meet the -00 cutoff and issue this as a WG > item > > before IETF#84). >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] > Sent: 28 June 2012 15:30 > To: DRAGE, Keith (Keith); insipid@ietf.org > Subject: RE: [Insipid] Call for WG adoption of text to >=20 > Hi, >=20 > I am ok with adopting this draft. >=20 > However I still have some concerns about the use case and associated > requirements relating to associating media with signaling using this > identifier. Although this might be useful in some circumstances I don't > think it is within the scope of the charter and potentially opens up > some complexity that in the interest of getting things done we should > avoid. >=20 > Also we probably need to look more closely at the transfer use cases > but we can do this after adoption. >=20 > Regards > Andy >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of DRAGE, Keith (Keith) > > Sent: 26 June 2012 06:11 > > To: insipid@ietf.org > > Subject: [Insipid] Call for WG adoption of text to > > > > (As WG cochair) > > > > In pursuance of the charter milestone: > > > > Aug 2012 Requirements and use cases for new identifier sent to IESG > > (as informational) > > > > I'd like to issue a call to adopt the text of: > > > > draft-jones-insipid-session-id-reqts-03 > > > > http://www.ietf.org/id/draft-jones-insipid-session-id-reqts-03.txt > > > > for this work. > > > > The intent of the milestone is for a document that has: > > - use cases > > - requirements > > - how requirements are derived from the use cases > > > > There is still material to be added in this respect, but this can be > > done as a WG item. (And I would encourage all to contribute to the > use > > cases in parallel to this call, i.e. separate mail threads). > > > > It is also appropriate to respond indicating that only part of the > text > > is acceptable (in which case we can defer the remaining text for > > further consideration as input to the deliverable). > > > > Note that the text does not have to be perfect at this stage, merely > > that you believe the text is appropriate for progressing by comment > and > > review within the scope of WG discussions and WGLC. > > > > Please respond (Yes, Yes but only for sections ... / except for > > sections ..., or No) by close of business on the 5th July (so that > > assuming assent, we can meet the -00 cutoff and issue this as a WG > item > > before IETF#84). > > > > Regards > > > > Keith > > > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Fri Jul 6 02:32:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814F221F8757 for ; Fri, 6 Jul 2012 02:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.012 X-Spam-Level: X-Spam-Status: No, score=-110.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBqWdJJFdnDL for ; Fri, 6 Jul 2012 02:32:35 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id C89E321F8752 for ; Fri, 6 Jul 2012 02:32:34 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q669U5jG009747 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Jul 2012 11:32:48 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 6 Jul 2012 11:32:05 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Fri, 6 Jul 2012 11:32:04 +0200 Thread-Topic: Working group draft for requirements document Thread-Index: Ac1bWQlAFCEifP6CQgGcZ9Tsf7Eu+w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] Working group draft for requirements document 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, 06 Jul 2012 09:32:36 -0000 (As WG cochair) I've had only positive agreement for the approval of text from: draft-jones-insipid-session-id-reqts-03.txt as a working group draft. Therefore the text (with the exception below) is = approved. The chairs have asked Paul Jones to act as editor for the document on behal= f of the working group and I understand he has agreed. There has been one exception in relation to the following text: "* Association of session signaling and media flows, made possible by including the session identifier in media-related messages (e.g., RSVP or RTCP)" Which I would ask the editor to remove from the submitted draft. I'll submi= t a separate discussion point to the list to take this text further. As soon as the editor has submitted the document as draft-ietf-insipid... t= hen we'll approve it. Regards Keith From keith.drage@alcatel-lucent.com Fri Jul 6 02:48:06 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5893621F85B8 for ; Fri, 6 Jul 2012 02:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.024 X-Spam-Level: X-Spam-Status: No, score=-110.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HtXO+Z7GCbm for ; Fri, 6 Jul 2012 02:48:05 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1F21F85A5 for ; Fri, 6 Jul 2012 02:48:05 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q669mKIJ002831 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Jul 2012 11:48:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 6 Jul 2012 11:48:20 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Fri, 6 Jul 2012 11:48:19 +0200 Thread-Topic: Use case for association of session signaling and media flows Thread-Index: Ac1bWzPj25oMM0jtR5CuSPxgSWfx1w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Insipid] Use case for association of session signaling and media 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: Fri, 06 Jul 2012 09:48:06 -0000 (As WG cochair) We have taken out the text: " * Association of session signaling and media flows, made possible by including the session identifier in media-related messages (e.g., RSVP or RTCP)" In order to keep text that has full consensus as a working group draft. That however does not mean we have consensus not to include it. So I would like people to discuss this use case and whether there is merit = or not in such a use case. I would also note that we need to expand both this text, and the text the o= riginally surrounded it, into some more complete text about a use case, and= maybe one of the ways forward in this discussion is for someone to do this= . Regards Keith From pkyzivat@alum.mit.edu Fri Jul 6 08:19:05 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7021F86C4 for ; Fri, 6 Jul 2012 08:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 G1COAqrZw1lm for ; Fri, 6 Jul 2012 08:19:04 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id EECAF21F86B2 for ; Fri, 6 Jul 2012 08:19:03 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id Wynf1j0051ZXKqc5D3KNuh; Fri, 06 Jul 2012 15:19:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id X3KY1j00a3ZTu2S3h3KZy1; Fri, 06 Jul 2012 15:19:33 +0000 Message-ID: <4FF701F7.8070202@alum.mit.edu> Date: Fri, 06 Jul 2012 11:19:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 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 Subject: Re: [Insipid] Use case for association of session signaling and media 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: Fri, 06 Jul 2012 15:19:05 -0000 On 7/6/12 5:48 AM, DRAGE, Keith (Keith) wrote: > (As WG cochair) > > We have taken out the text: > > " * Association of session signaling and media flows, made possible > by including the session identifier in media-related messages > (e.g., RSVP or RTCP)" > > In order to keep text that has full consensus as a working group draft. > > That however does not mean we have consensus not to include it. > > So I would like people to discuss this use case and whether there is merit or not in such a use case. > > I would also note that we need to expand both this text, and the text the originally surrounded it, into some more complete text about a use case, and maybe one of the ways forward in this discussion is for someone to do this. I have an open mind about this one. But I have questions about it: Is the thought that there is already a suitable field in RSVP, and one in RTCP, for carrying this? Or is this implying that extensions should be made to those to carry this data? If the thinking is that extensions are needed, then I think we should rule this out of scope. If the intent is to use existing fields, then they should be spelled out, with whatever limitations those would imply on this work. Thanks, Paul From paulej@packetizer.com Fri Jul 6 22:00:30 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1788221F856C for ; Fri, 6 Jul 2012 22:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, SARE_FWDLOOK=1.666] 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 H8IVmMe16N50 for ; Fri, 6 Jul 2012 22:00:29 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 368F921F8564 for ; Fri, 6 Jul 2012 22:00:28 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6750iC1030753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 7 Jul 2012 01:00:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341637245; bh=sUTs7eg7ZletXdtx+xxv5qWZ1tCMAxlzbQPaofaLWQU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kat+NhUcJvd8lcU8aailrb4zDUSjesZxyhteuIMyfyHu+1yRya/H861SIlz5tfcus SVZJR/XoKjNL60QUXleo7TafLeRIVCR2ucBq6y6QuTv7OT/qjCfpkSzxQpc/TOrP2e G1rGz2a+l0Xmlwg0BlxFXKBGEqd+vLTaQ8BH0sFI= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <4FF701F7.8070202@alum.mit.edu> In-Reply-To: <4FF701F7.8070202@alum.mit.edu> Date: Sat, 7 Jul 2012 01:00:56 -0400 Message-ID: <09b501cd5bfd$7ee8ec60$7cbac520$@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: AQEnxsoIGcdTmWb5fTF6thkm/Fi0agGq2bnqmFsSdJA= Content-Language: en-us Subject: Re: [Insipid] Use case for association of session signaling and media 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, 07 Jul 2012 05:00:30 -0000 Paul, > > " * Association of session signaling and media flows, made possible > > by including the session identifier in media-related messages > > (e.g., RSVP or RTCP)" > > > Is the thought that there is already a suitable field in RSVP, and one in > RTCP, for carrying this? Or is this implying that extensions should be > made to those to carry this data? There is no suitable field presently, though we could introduce extensions. What form? I do not know right now. I like the thought of inserting it into a PATH message, though, since systems that are logging information could log that value. The correlation could be done in real-time or later. If a user reports poor voice/video quality, for example, one might know the precise path of the media through the network or other information about the call, more than just where the signaling went. > If the thinking is that extensions are needed, then I think we should rule > this out of scope. Extensions would be needed to other protocols, but we're definitely not suggesting this group undertake work on anything related to RTP, RTCP, RSVP, or anything else media related. What missing in that snippet of text above is that the preceding text. What we had written was that the Session-ID should be defined so as to enable its use in other protocols. To do that is not hard. A UUID is workable. Two UUIDs is workable. A 2048-byte string is out of the question. We should not use a value that in any way allows association with a particular person, since the RTCP or RSVP packet might reveal information in the clear. Thus, a Session-ID that is comprised of certain values in SIP headers would be a bad choice. In any case, this is a forward-looking use case, but I can see the benefit in associating signaling and media flows. I just wanted to make sure we did not make a poor choice and then later if we decide we really want that kind of capability, find ourselves stuck and need to define yet another identifier. > If the intent is to use existing fields, then they should be spelled out, > with whatever limitations those would imply on this work. We would not propose use of existing fields, even if something existed. The use case is just that: what we might want to do with it. We're not specifying how to do it, nor is it clear whether we will. (That said, I'd like to think about this, but one step at a time.) Paul From internet-drafts@ietf.org Sat Jul 7 00:47:32 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17B121F854D; Sat, 7 Jul 2012 00:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, 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 SfamDnrSaOkb; Sat, 7 Jul 2012 00:47:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1021F8541; Sat, 7 Jul 2012 00:47:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120707074732.28956.49585.idtracker@ietfa.amsl.com> Date: Sat, 07 Jul 2012 00:47:32 -0700 Cc: insipid@ietf.org Subject: [Insipid] I-D Action: draft-ietf-insipid-session-id-reqts-00.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 07:47:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the INtermediary-safe SIP session ID Working = Group of the IETF. Title : Requirements for an End-to-End Session Identification in= IP-Based Multimedia Communication Networks Author(s) : Paul E. Jones Gonzalo Salgueiro James Polk Laura Liess Hadriel Kaplan Filename : draft-ietf-insipid-session-id-reqts-00.txt Pages : 9 Date : 2012-07-07 Abstract: This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, and track communication sessions when they are redirected. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From oej@edvina.net Sat Jul 7 01:20:47 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0394F21F855B for ; Sat, 7 Jul 2012 01:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 128QqTFcY9UG for ; Sat, 7 Jul 2012 01:20:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B34B321F855A for ; Sat, 7 Jul 2012 01:20:44 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 52B2F754A8AA; Sat, 7 Jul 2012 08:21:01 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4FF701F7.8070202@alum.mit.edu> Date: Sat, 7 Jul 2012 10:21:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF701F7.8070202@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: insipid@ietf.org Subject: Re: [Insipid] Use case for association of session signaling and media 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, 07 Jul 2012 08:20:47 -0000 6 jul 2012 kl. 17:19 skrev Paul Kyzivat: > On 7/6/12 5:48 AM, DRAGE, Keith (Keith) wrote: >> (As WG cochair) >>=20 >> We have taken out the text: >>=20 >> " * Association of session signaling and media flows, made possible >> by including the session identifier in media-related messages >> (e.g., RSVP or RTCP)" >>=20 >> In order to keep text that has full consensus as a working group = draft. >>=20 >> That however does not mean we have consensus not to include it. >>=20 >> So I would like people to discuss this use case and whether there is = merit or not in such a use case. >>=20 >> I would also note that we need to expand both this text, and the text = the originally surrounded it, into some more complete text about a use = case, and maybe one of the ways forward in this discussion is for = someone to do this. >=20 > I have an open mind about this one. But I have questions about it: >=20 > Is the thought that there is already a suitable field in RSVP, and one = in RTCP, for carrying this? Or is this implying that extensions should = be made to those to carry this data? RTCP has application specific fields that can be used for this type of = data, like the APP packet type. But that may be seen as misuse. There is = an IANA registry for new fields. Or... Hmm. According to RFC 3550 there should be a registry for RTCP packet types = at IANA, but I can't find it. /O >=20 > If the thinking is that extensions are needed, then I think we should = rule this out of scope. >=20 > If the intent is to use existing fields, then they should be spelled = out, with whatever limitations those would imply on this work. >=20 > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From laura.liess.dt@googlemail.com Mon Jul 9 06:49:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B9F21F85A0 for ; Mon, 9 Jul 2012 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o+09XjYEzZa for ; Mon, 9 Jul 2012 06:49:36 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2146721F859A for ; Mon, 9 Jul 2012 06:49:35 -0700 (PDT) Received: by ggnc4 with SMTP id c4so11067618ggn.31 for ; Mon, 09 Jul 2012 06:50:00 -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=0V+0jbu666c0OkPVHezkD9G6FNpJ1a+FcQodM8ilRyM=; b=HDNEINTLpWr2cz3xPekJaGNa0B6G/ZjxjIV1HqPoQ4KytI3PxqtShMo/IkdNXFwBDI gc4XnSmhHKIJWLwhbbb1lI2TUxJBhLWoGYpe26G9VM5KU3R2+WDMhAomoGlZjpukDli3 tqu3Nv33mG4jS/15+Ta6VaPUJrcxHnm/iXej/IE7d4GFA3IfmauCCrprdxScqhEZ5y3t qsoN1l44fsiWYIas2Bw88c1DbknyzA5e4f2uEyCiLnFjFCHhDWzKHnc49TOsOjBWCOST iHm/luC0dy+2SZMsevNFysyQm8xBTjmZKyybrOylUf39W061LHfRnQOVGSVJmuqm8Ues c8+Q== MIME-Version: 1.0 Received: by 10.50.91.233 with SMTP id ch9mr8338367igb.8.1341841800489; Mon, 09 Jul 2012 06:50:00 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Mon, 9 Jul 2012 06:50:00 -0700 (PDT) In-Reply-To: <064d01cd5a43$b97b8100$2c728300$@packetizer.com> References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> Date: Mon, 9 Jul 2012 15:50:00 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 13:49:37 -0000 Paul, Sorry. Somehow I missed your e-mail. I think we have a misunderstanding here. 2012/7/5 Paul E. Jones : > I'm confused. We did not add anything to REQ1 recently. REQ1a is an > entirely separate requirement. [LL] I thought, based on http://www.ietf.org/mail-archive/web/insipid/current/msg00166.html, that you intend to merge REQ1 and REQ1a into REQ1. Maybe I misunderstood. > > You really want to just remove that text from c)? [LL] No. I don't. Also in this scenario the service providers monitors and logs all B2BUA traffic, incomming and outgoing. There is no log provided by the customer. >From my point of view, the text would be : -------------------------------------------- User Agent A (A) and User Agent B (B) communicate using SIP messaging with a SIP B2BUA acting as a middlebox which belongs to a SIP service provider. For privacy reasons, the B2BUA changes the SIP headers that reveal information related to the SIP users, device or domain identity. The service provider uses an external device to monitor and log all SIP traffic coming to and from the B2BUA. In the case of failures reported by the customer or when security issue arise (e.g. theft of service), the service provider has to analyze the logs from the past several days or weeks and correlates those messages which were messages for a single end-to-end SIP session. For this scenario, we must consider three particular use cases: a) The UAs A and B support the end-to-end Session Identifier. Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. b) Only the UA A supports the end-to-end Session Identifier, the UA B does not. Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. c) UA A and UA B do not support the end-to-end Session Identifier. Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. ----------------- What do you think? Thank you Laura > > Paul > >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Wednesday, July 04, 2012 4:15 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: Text proposal for the "SIP traffic monitoring" use case >> >> Paul, >> >> I am fine with the text. For use case c) please just remove "(eventually >> REQ1a)" because REQ 1a is now included into REQ1. >> >> Thank you >> Laura >> >> 2012/7/4 Paul E. Jones : >> > Laura, >> > >> > I re-worded what you proposed. Tell me if this is acceptable: >> > >> > User Agent A (A) and User Agent B (B) communicate using SIP messaging >> > with a SIP B2BUA acting as a middlebox. For privacy reasons, the B2BUA >> > changes SIP headers that reveal information related to the SIP user, >> > device or domain identity. The service provider uses an external >> > device to monitor and log all SIP traffic coming from the B2BUA. In >> > the case of failures reported by the customer or when security issue >> > arise (e.g. theft of service), the service provider has to analyze the >> > logs, including its own logs and perhaps logs provided by the >> > customer, for the past several days or weeks and correlate those >> > messages which were messages for a single end-to-end SIP session. >> > >> > For this scenario, we must consider three particular use cases: >> > >> > a) The software on A and B can be upgraded by the service provider to >> > support a single end-to-end Session Identifier. >> > >> > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ8. >> > >> > b) Only software on A can be upgraded by the service provider to >> > support the new identifier. >> > >> > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. >> > >> > c) Neither the software on A nor B can be upgraded by the service >> > provider to support the new identifier. >> > >> > Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, REQ7, REQ8. >> > >> > Should I remove "eventually REQ1a" and just put "REQ1a"? >> > >> > Paul >> > >> >> -----Original Message----- >> >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> >> Sent: Wednesday, June 27, 2012 5:19 AM >> >> To: Paul Jones >> >> Cc: insipid@ietf.org >> >> Subject: Text proposal for the "SIP traffic monitoring" use case >> >> >> >> Paul, >> >> >> >> Please find enclosed a text proposal for the use case "SIP traffic >> >> monitoring": >> >> >> >> >> >> SIP traffic monitoring >> >> >> >> UA-A and UA-B communicate using SIP phone calls and SIP messaging >> >> with a SIP B2BUA acting as a middlebox. The B2BUA changes any SIP >> >> header revealing information related to the SIP user, device or domain >> identity. >> >> The service provider uses an external device to monitor and log "on >> >> the wire" all SIP traffic passed through the B2BUA. In case of >> >> failures being reported by the customers or of security issues (e.g. >> >> theft of service), the service provider has to analyse the logs for >> >> the past days or weeks and correlate those messages which where, at >> >> some point in time, components of a single end-to-end SIP session >> >> (e.g., parts of the same phone call or transfer of the same message). >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UA-A and UA-B software can be upgraded by the service >> provider >> >> to support the new identifier. . >> >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, >> REQ8. >> >> >> >> b) Only the UA-A software can be upgraded by the service provider >> to >> >> support the new identifier, the UA-B software can not. >> >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, >> >> REQ7, REQ8. >> >> >> >> c) Neither the UA-A nor the UA-B software can be upgraded by the >> >> service provider to support the new identifier, the UA-B software can >> not. >> >> Derived Requirements: REQ1, (eventually REQ1a), REQ4, REQ5, >> >> REQ7, REQ8. >> >> >> >> Thanks >> >> Laura >> > > From christer.holmberg@ericsson.com Mon Jul 9 14:12:28 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423C011E821E for ; Mon, 9 Jul 2012 14:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpo8jB-htJ53 for ; Mon, 9 Jul 2012 14:12:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC911E81BA for ; Mon, 9 Jul 2012 14:12:26 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-67-4ffb495319a8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 58.BA.03067.3594BFF4; Mon, 9 Jul 2012 23:12:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 9 Jul 2012 23:12:51 +0200 From: Christer Holmberg To: "'Olle E. Johansson'" , Paul Kyzivat Date: Mon, 9 Jul 2012 23:12:50 +0200 Thread-Topic: [Insipid] Use case for association of session signaling and media flows Thread-Index: Ac1cGXgwzqhpvsKpSFu0NnPu/QI0WAB/ZA6w Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> References: <4FF701F7.8070202@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW6I529/g537OC3m33/GZPFy9SFm ixUbDrA6MHv8ff+ByWPa2pWsHkuW/GQKYI7isklJzcksSy3St0vgyvi71Kjgo0jF+TXL2BoY jwh0MXJySAiYSHS2TmeGsMUkLtxbz9bFyMUhJHCKUWJ3+2UWCGcOo0TfxY3sXYwcHGwCFhLd /7RBGkQEgiT2H17MCmIzC2hKrFh8G6yERUBF4vgePhBTWCBM4udiM4jqcImes6+YQcIiAkYS l9+qgIR5gcIzj9+CWrSZUeLPxOOMIAlOATuJxRc+MYHYjECnfT+1hglik7jErSfzmSBOFpBY suc81PmiEi8f/2OFqBeVuNO+nhGiXk/ixtQpbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFp mYWkZRaSlgWMLKsYhXMTM3PSy831Uosyk4uL8/P0ilM3MQIj6eCW3wY7GDfdFzvEKM3BoiTO q6e6319IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY82Vu5+PZkV85kxOU7uwXEBPr9ypoTaj JfpsWpNi95Q9JwM+y55bYbb+qcS638GT/lT5pwtqbI+xVDu8re+T/cWOGQzLbPPcvj05G2Ft 9uj3t+9BVqtLmLc8Cdl176JA/Mc5B3N6xOMkOxNnPf7xx2BhSK07Z0fEnPRrOUu7Oh5vi1/1 5M9kWyWW4oxEQy3mouJEAFymwAxyAgAA Cc: "insipid@ietf.org" Subject: Re: [Insipid] Use case for association of session signaling and media 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: Mon, 09 Jul 2012 21:12:28 -0000 Hi, I think there are cases where it would be useful to explicitly associate me= dia and signalling, and if the session-id somehow can be used for that - fi= ne. However, isn't such mechanism outside the current charter of INSIPID? Regards, Christer =20 -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Olle E. Johansson Sent: 7. hein=E4kuuta 2012 11:21 To: Paul Kyzivat Cc: insipid@ietf.org Subject: Re: [Insipid] Use case for association of session signaling and me= dia flows 6 jul 2012 kl. 17:19 skrev Paul Kyzivat: > On 7/6/12 5:48 AM, DRAGE, Keith (Keith) wrote: >> (As WG cochair) >>=20 >> We have taken out the text: >>=20 >> " * Association of session signaling and media flows, made possible >> by including the session identifier in media-related messages >> (e.g., RSVP or RTCP)" >>=20 >> In order to keep text that has full consensus as a working group draft. >>=20 >> That however does not mean we have consensus not to include it. >>=20 >> So I would like people to discuss this use case and whether there is mer= it or not in such a use case. >>=20 >> I would also note that we need to expand both this text, and the text th= e originally surrounded it, into some more complete text about a use case, = and maybe one of the ways forward in this discussion is for someone to do t= his. >=20 > I have an open mind about this one. But I have questions about it: >=20 > Is the thought that there is already a suitable field in RSVP, and one in= RTCP, for carrying this? Or is this implying that extensions should be mad= e to those to carry this data? RTCP has application specific fields that can be used for this type of data= , like the APP packet type. But that may be seen as misuse. There is an IAN= A registry for new fields. Or... Hmm. According to RFC 3550 there should be a registry for RTCP packet types at I= ANA, but I can't find it. /O >=20 > If the thinking is that extensions are needed, then I think we should rul= e this out of scope. >=20 > If the intent is to use existing fields, then they should be spelled out,= with whatever limitations those would imply on this work. >=20 > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Jul 9 20:46:24 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4411E8117 for ; Mon, 9 Jul 2012 20:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVXjpIaNpdoq for ; Mon, 9 Jul 2012 20:46:23 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3A64511E8110 for ; Mon, 9 Jul 2012 20:46:18 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6A3kavu016185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jul 2012 23:46:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341891997; bh=XMUoXXPjm76tJ0GWm/zJVUl6OF+I+/Eofvl3344IM1Y=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Gv5tAEUbo/JaiRzB2E5z51PGAuuAIkhKMk1ijt7h3w6ci+UwVQjVz4pb6bLugBpKV /kHzw7nJtwDdEI5gl31jgy3n5FMdfVdMk/taOmTHKxSIYC6j9Qtxkd3Of2he71YUxJ 6lKFBxpdRNHqy+woeCc8IzZAT8IHKV1kDaOCcIKg= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Olle E. Johansson'" , "'Paul Kyzivat'" References: <4FF701F7.8070202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 9 Jul 2012 23:46:40 -0400 Message-ID: <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEnxsoIGcdTmWb5fTF6thkm/Fi0agGq2bnqAcX6I+8CtDlaLJg75g+w Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Use case for association of session signaling and media 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: Tue, 10 Jul 2012 03:46:24 -0000 Christer, The mechanisms certainly are our of scope. All I was hoping for at this point was to ensure that we do not make it difficult or impossible to = one day associate media and signaling by making a poor choice in how we construct the Session-ID. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf > Of Christer Holmberg > Sent: Monday, July 09, 2012 5:13 PM > To: 'Olle E. Johansson'; Paul Kyzivat > Cc: insipid@ietf.org > Subject: Re: [Insipid] Use case for association of session signaling = and > media flows >=20 >=20 > Hi, >=20 > I think there are cases where it would be useful to explicitly = associate > media and signalling, and if the session-id somehow can be used for = that - > fine. >=20 > However, isn't such mechanism outside the current charter of INSIPID? >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf > Of Olle E. Johansson > Sent: 7. hein=E4kuuta 2012 11:21 > To: Paul Kyzivat > Cc: insipid@ietf.org > Subject: Re: [Insipid] Use case for association of session signaling = and > media flows >=20 >=20 > 6 jul 2012 kl. 17:19 skrev Paul Kyzivat: >=20 > > On 7/6/12 5:48 AM, DRAGE, Keith (Keith) wrote: > >> (As WG cochair) > >> > >> We have taken out the text: > >> > >> " * Association of session signaling and media flows, made possible > >> by including the session identifier in media-related messages > >> (e.g., RSVP or RTCP)" > >> > >> In order to keep text that has full consensus as a working group = draft. > >> > >> That however does not mean we have consensus not to include it. > >> > >> So I would like people to discuss this use case and whether there = is > merit or not in such a use case. > >> > >> I would also note that we need to expand both this text, and the = text > the originally surrounded it, into some more complete text about a use > case, and maybe one of the ways forward in this discussion is for = someone > to do this. > > > > I have an open mind about this one. But I have questions about it: > > > > Is the thought that there is already a suitable field in RSVP, and = one > in RTCP, for carrying this? Or is this implying that extensions should = be > made to those to carry this data? > RTCP has application specific fields that can be used for this type of > data, like the APP packet type. But that may be seen as misuse. There = is > an IANA registry for new fields. Or... Hmm. >=20 > According to RFC 3550 there should be a registry for RTCP packet types = at > IANA, but I can't find it. >=20 > /O >=20 > > > > If the thinking is that extensions are needed, then I think we = should > rule this out of scope. > > > > If the intent is to use existing fields, then they should be spelled > out, with whatever limitations those would imply on this work. > > > > Thanks, > > Paul > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Mon Jul 9 21:06:43 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F215111E8117 for ; Mon, 9 Jul 2012 21:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_31=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 bYF25Vl-hFyY for ; Mon, 9 Jul 2012 21:06:42 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1C93511E810D for ; Mon, 9 Jul 2012 21:06:42 -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 q6A477wv016792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 00:07:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341893227; bh=YoqbhT8mWN27oBdfSNPqelvb1EImQlu4RasXuYjEpKk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=C+FK2qiHnUsG1UJr547gwFb3mbRLtCyC958NtO+PvZ/4BtjwqsErKKuq/4UbnA/sd AKeYoqTKzIYJjFhDDRo81vhrSFyc0bpKO1zPKHLUxXNW495A1ZQoPwfWM9kkgiz6FB lObKflfupMEAUva2rKs0A7rRqJljGANj1lS6neLA= From: "Paul E. Jones" To: "'Laura Liess'" References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> In-Reply-To: Date: Tue, 10 Jul 2012 00:07:10 -0400 Message-ID: <0c2c01cd5e51$7b525e50$71f71af0$@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: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAAIZ3s8FAiAEuxoBrzjzyAH42j74mIcXMhA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 10 Jul 2012 04:06:43 -0000 Laura, > 2012/7/5 Paul E. Jones : > > I'm confused. We did not add anything to REQ1 recently. REQ1a is an > > entirely separate requirement. > [LL] I thought, based on > http://www.ietf.org/mail-archive/web/insipid/current/msg00166.html, > that you intend to merge REQ1 and REQ1a into REQ1. Maybe I misunderstood. REQ1a exists because somebody wanted to split define something like REQ1 for non-dialog exchanges. What was proposed (by you?) was this: REQ1a: It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify those dialogs, transactions and messages which were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call). This is not presently in the draft that we just submitted to be a WG document since I was told to base that document on the -03 draft. I had that text in my pending -04 draft, but ... it is still sitting there :-) > > You really want to just remove that text from c)? > [LL] No. I don't. > Also in this scenario the service providers monitors and logs all B2BUA > traffic, incomming and outgoing. There is no log provided by the > customer. > > From my point of view, the text would be : > > -------------------------------------------- > User Agent A (A) and User Agent B (B) communicate using SIP messaging with > a SIP B2BUA acting as a middlebox which belongs to a SIP service provider. > For privacy reasons, the B2BUA changes the SIP headers that reveal > information related to the SIP users, device or domain identity. The > service provider uses an external device to monitor and log all SIP > traffic coming to and from the B2BUA. In the case of failures reported by > the customer or when security issue arise (e.g. theft of service), the > service provider has to analyze the logs from the past several days or > weeks and correlates those messages which were messages for a single end- > to-end SIP session. > > For this scenario, we must consider three particular use cases: > > a) The UAs A and B support the end-to-end Session Identifier. > > Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. > > b) Only the UA A supports the end-to-end Session Identifier, the UA B does > not. > > Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > > c) UA A and UA B do not support the end-to-end Session Identifier. > > Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > ----------------- > > > What do you think? Sounds OK to me. I'll put this into me -04 draft and when folks give me the green light, move it into the WG -01 draft. Paul From laura.liess.dt@googlemail.com Tue Jul 10 05:22:40 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D4B21F875A for ; Tue, 10 Jul 2012 05:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqUPAu69YpkQ for ; Tue, 10 Jul 2012 05:22:39 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E83E721F8736 for ; Tue, 10 Jul 2012 05:22:38 -0700 (PDT) Received: by yenq13 with SMTP id q13so12217990yen.31 for ; Tue, 10 Jul 2012 05:23:06 -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=2vReZeuHai9g3wqoMJKY/XoTJx8pWAi3HOTdM9h/ri8=; b=SMouHbbjteMnxTelDUgSeUGODV05VaLy5RjjdxWcdiDFXfZ7/dTuvhADbpN1oiES7C Y8yNLS01Lh36KRiMsG/Wus0ic5JXfYIb4LmINt+sn0AyBdFDPsGFoCbno0eKdUTm6Ovx nLj9rnbrbZy4NChlIxV2gkPuIfz1UvvFq2lY/d6fEo1Nn6YWTFhOBCWDqh1gNFAzEeeR OW/fWNLzVD7/2zSicRtMaqqqqh4+fpzqCH+392L2ShrGZ5JuHivbgZhxQE4DtyQO2N7D FHCukcVSwSMgFewz2V8ADa5L0ZBsDYH2KcWteyQwkIcIZRJwNdwUpUiI2j+Oh6BT0vmz Km5Q== MIME-Version: 1.0 Received: by 10.50.94.163 with SMTP id dd3mr10887008igb.8.1341922986114; Tue, 10 Jul 2012 05:23:06 -0700 (PDT) Received: by 10.231.10.130 with HTTP; Tue, 10 Jul 2012 05:23:06 -0700 (PDT) In-Reply-To: <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> Date: Tue, 10 Jul 2012 14:23:06 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 10 Jul 2012 12:22:40 -0000 Paul, > > What was proposed (by you?) was this: > > REQ1a: It must be possible for an administrator or an external device which > monitors the SIP-traffic to use the identifier to identify those dialogs, > transactions and messages which were at some point in time components of a > single end-to-end SIP session (e.g., parts of the same call). [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is in draft-ietf-insipid-session-id-reqts-00). So I think we could replace the current text of REQ1 by the proposed text of the REQ1a and then drop REQ1a. Thanks Laura > > This is not presently in the draft that we just submitted to be a WG > document since I was told to base that document on the -03 draft. I had > that text in my pending -04 draft, but ... it is still sitting there :-) > >> > You really want to just remove that text from c)? >> [LL] No. I don't. >> Also in this scenario the service providers monitors and logs all B2BUA >> traffic, incomming and outgoing. There is no log provided by the >> customer. >> >> From my point of view, the text would be : >> >> -------------------------------------------- >> User Agent A (A) and User Agent B (B) communicate using SIP messaging with >> a SIP B2BUA acting as a middlebox which belongs to a SIP service provider. >> For privacy reasons, the B2BUA changes the SIP headers that reveal >> information related to the SIP users, device or domain identity. The >> service provider uses an external device to monitor and log all SIP >> traffic coming to and from the B2BUA. In the case of failures reported by >> the customer or when security issue arise (e.g. theft of service), the >> service provider has to analyze the logs from the past several days or >> weeks and correlates those messages which were messages for a single end- >> to-end SIP session. >> >> For this scenario, we must consider three particular use cases: >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B does >> not. >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> ----------------- >> >> >> What do you think? > > > Sounds OK to me. I'll put this into me -04 draft and when folks give me the > green light, move it into the WG -01 draft. > > Paul > > From keith.drage@alcatel-lucent.com Tue Jul 10 09:03:37 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B140711E807F for ; Tue, 10 Jul 2012 09:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.103 X-Spam-Level: X-Spam-Status: No, score=-110.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyk26nON3+qC for ; Tue, 10 Jul 2012 09:03:36 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 88CCC21F85FC for ; Tue, 10 Jul 2012 09:03:36 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6AG421P009964 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 10 Jul 2012 18:04:02 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 10 Jul 2012 18:04:02 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Tue, 10 Jul 2012 18:04:01 +0200 Thread-Topic: [Insipid] INSIPID WG Virtual Interim #3 Meeting: Dial-in details via Webex Thread-Index: Ac1a6Hkspj+d8Z/CT8iwViOHC2DwuwDzQ/cg Message-ID: References: <120E2743-E9D0-4A05-AD8B-BFC8195BBC70@cisco.com> In-Reply-To: <120E2743-E9D0-4A05-AD8B-BFC8195BBC70@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [Insipid] INSIPID WG Virtual Interim #3 Meeting: Dial-in details via Webex 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, 10 Jul 2012 16:03:37 -0000 Looks like the webex bridge got mischeduled. We are creating a new one and details will be available shortly. Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Gonzalo Salgueiro > Sent: 05 July 2012 20:58 > To: insipid@ietf.org > Subject: [Insipid] INSIPID WG Virtual Interim #3 Meeting: Dial-in details > via Webex >=20 > Folks - >=20 > Reminder that, as discussed at the last interim meeting, we will host the > INSIPID Virtual Interim #3 meeting (July 10th at 9 AM Pacific Daylight > Time). See below for the agenda and "dial-in" details. [Note: slides can > be found on the proceedings page for this interim meeting: > http://www.ietf.org/proceedings/interim/2012/07/10/insipid/proceedings.ht= m > l] >=20 > Cheers, >=20 > Gonzalo > (as co-chair) >=20 > ------------------------------------------ > Agenda: >=20 > 1) Note well, agenda bash, notetakers, etc. > Presenters: Chairs (5 min) >=20 > 2) Discussion of requirements draft WG adoption and pending issues > (cont'd) > Presenters: Paul Jones, James Polk (30 min) > Drafts: draft-jones-insipid-session-id-reqts > http://tools.ietf.org/html/draft-jones-insipid-session-id-reqts >=20 > 3) Review of proposed solutions > Presenters: Paul Jones, James Polk (70 min) > Drafts: draft-jones-insipid-session-id-00 > http://tools.ietf.org/html/draft-jones-insipid-session-id > [Note: We encourage folks to submit any candidate solutions for session i= d > that they wish to be considered by the WG] >=20 > 4) Preparation for IETF84 and Next steps > Presenters: Chairs (15 min) >=20 > --------------------------------- >=20 > WEBEX DETAILS >=20 > INtermediary-safe SIP session ID (INSIPID) Group invites you to attend > this online meeting. >=20 > Topic: INSIPID WG Virtual Interm #3 > Date: Tuesday, July 10, 2012 > Time: 8:45 pm, Pacific Daylight Time (San Francisco, GMT-07:00) > Meeting Number: 968 066 788 > Meeting Password: insipid >=20 >=20 > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://workgreen.webex.com/workgreen/j.php?ED=3D194761907&UID=3D12889952= 97&PW > =3DNYWNlMDdmNGRh&RT=3DMiM0 > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: insipid > 4. Click "Join". >=20 > To view in other time zones or languages, please click the link: > https://workgreen.webex.com/workgreen/j.php?ED=3D194761907&UID=3D12889952= 97&PW > =3DNYWNlMDdmNGRh&ORT=3DMiM0 >=20 > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > To receive a call back, provide your phone number when you join the > meeting, or call the number below and enter the access code. > Call-in toll number (US/Canada): 1-408-792-6300 > Global call-in numbers: > https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&E= D=3D1 > 94761907&tollFree=3D0 >=20 > Access code:968 066 788 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://workgreen.webex.com/workgreen/mc > 2. On the left navigation bar, click "Support". >=20 > You can contact me at: > cmorgan@amsl.com > 1-510-492-4085 >=20 > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://workgreen.webex.com/workgreen/j.php?ED=3D194761907&UID=3D12889952= 97&IC > S=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DLSuJ- > uet6/97I8M5a0K34pFVZkK/TtoQgQTnHgYZq8Y=3D&RT=3DMiM0 >=20 > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in th= e > meeting, please check whether you have the players installed on your > computer by going to > https://workgreen.webex.com/workgreen/systemdiagnosis.php. >=20 > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial >=20 > http://www.webex.com >=20 > CCP:+14087926300x968066788# >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the > session to be recorded. By joining this session, you automatically consen= t > to such recordings. If you do not consent to the recording, discuss your > concerns with the meeting host prior to the start of the recording or do > not join the session. Please note that any such recordings may be subject > to discovery in the event of litigation. >=20 > ------------------------------------------ >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From gsalguei@cisco.com Tue Jul 10 09:05:45 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5693521F85FC for ; Tue, 10 Jul 2012 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 vABURbnNYhaG for ; Tue, 10 Jul 2012 09:05:44 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 52CD111E807F for ; Tue, 10 Jul 2012 09:05:44 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6AG6BJT009146 for ; Tue, 10 Jul 2012 12:06:11 -0400 (EDT) Received: from dhcp-64-102-155-2.cisco.com (dhcp-64-102-155-2.cisco.com [64.102.155.2]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6AG6BUX008129 for ; Tue, 10 Jul 2012 12:06:11 -0400 (EDT) From: Gonzalo Salgueiro Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_11A54A3B-2229-41A5-8F2B-37B2A7AE4710" Date: Tue, 10 Jul 2012 12:06:09 -0400 X-Priority: 1 References: <1791089693.3893.1341936278232.JavaMail.nobody@jsj2tc002.webex.com> To: insipid@ietf.org Message-Id: X-Mailer: Apple Mail (2.1278) Subject: [Insipid] Fwd: (Forward to attendees) Please join now, meeting in progress: Gonzalo Instant WebEx Meeting 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, 10 Jul 2012 16:05:45 -0000 --Apple-Mail=_11A54A3B-2229-41A5-8F2B-37B2A7AE4710 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks -=20 Let's use this webex for interim #3 to get around the scheduling issue. Cheers, Gonzalo Begin forwarded message: > From: Gonzalo Salgueiro > Subject: (Forward to attendees) Please join now, meeting in progress: = Gonzalo Instant WebEx Meeting > Date: July 10, 2012 12:04:38 PM EDT > To: gsalguei@cisco.com > Reply-To: gsalguei@cisco.com >=20 > **** You can forward this email invitation to attendees ****=20 >=20 > Hello ,=20 >=20 > Please join my meeting that is currently in progress.=20 >=20 > Topic: Gonzalo Instant WebEx Meeting=20 > Date: Tuesday, July 10, 2012=20 > Time: 12:04 pm, Eastern Daylight Time (New York, GMT-04:00)=20 > Meeting Number: 965 904 997=20 > Meeting Password: cisco=20 >=20 >=20 > -------------------------------------------------------=20 > To join the online meeting (Now from mobile devices!)=20 > -------------------------------------------------------=20 > 1. Go to = https://ciscosupport.webex.com/ciscosupport/e.php?AT=3DMI&EventID=3D195670= 017&UID=3D0&PW=3DNYjM3NWQwYjYz&RT=3DMiMxMQ%3D%3D=20 > 2. Enter your name and email address.=20 > 3. Enter the meeting password: cisco=20 > 4. Click "Join Now".=20 > 5. Follow the instructions that appear on your screen.=20 >=20 > To view in other time zones or languages, please click the link:=20 > = https://ciscosupport.webex.com/ciscosupport/e.php?AT=3DMI&EventID=3D195670= 017&UID=3D0&PW=3DNYjM3NWQwYjYz&ORT=3DMiMxMQ%3D%3D=20 >=20 > ----------------------------------------------------------------=20 > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 > ----------------------------------------------------------------=20 >=20 > The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.=20 >=20 > Please dial the local access number for your area from the list below:=20= > - San Jose/Milpitas (408) area: 525-6800=20 > - RTP (919) area: 392-3330=20 >=20 > -------------------------------------------------------=20 > To join the teleconference only=20 > -------------------------------------------------------=20 > 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 > http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 > 2. Follow the prompts to enter the Meeting Number (listed above) or = Access Code followed by the # sign.=20 >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 > -------------------------------------------------------=20 > For assistance=20 > -------------------------------------------------------=20 > 1. Go to https://ciscosupport.webex.com/ciscosupport/mc=20 > 2. On the left navigation bar, click "Support".=20 >=20 > You can contact me at:=20 > gsalguei@cisco.com=20 > 1-9193923266=20 >=20 >=20 >=20 >=20 > http://www.webex.com=20 >=20 > CCP:+14085256800x965904997#=20 >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 --Apple-Mail=_11A54A3B-2229-41A5-8F2B-37B2A7AE4710 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Folks = - 

Let's use this webex for interim #3 to get = around the scheduling = issue.

Cheers,

Gonzalo


Begin forwarded message:

From: Gonzalo Salgueiro = <messenger@webex.com>
=
Subject: = (Forward to attendees) Please join now, meeting in = progress: Gonzalo Instant WebEx Meeting
Date: July 10, 2012 = 12:04:38 PM EDT
=
Reply-To: = gsalguei@cisco.com
=
**** You can forward this email invitation to attendees **** =

Hello ,

Please join my meeting that is currently in = progress.

Topic: Gonzalo Instant WebEx Meeting
Date: = Tuesday, July 10, 2012
Time: 12:04 pm, Eastern Daylight Time (New = York, GMT-04:00)
Meeting Number: 965 904 997
Meeting Password: = cisco


= -------------------------------------------------------
To join the = online meeting (Now from mobile devices!)
= -------------------------------------------------------
1. Go to https://ciscosupport.webex.com/ciscosupport/e.php?AT=3DM= I&EventID=3D195670017&UID=3D0&PW=3DNYjM3NWQwYjYz&RT=3DMiMx= MQ%3D%3D
2. Enter your name and email address.
3. Enter = the meeting password: cisco
4. Click "Join Now".
5. Follow the = instructions that appear on your screen.

To view in other time = zones or languages, please click the link:
https://ciscosupport.webex.com/ciscosupport/e.php?AT=3DM= I&EventID=3D195670017&UID=3D0&PW=3DNYjM3NWQwYjYz&ORT=3DMiM= xMQ%3D%3D

= ----------------------------------------------------------------
= ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
= ----------------------------------------------------------------
=
The affected toll free numbers are: (866) 432-9903 for the San = Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please = dial the local access number for your area from the list below:
- = San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330 =

-------------------------------------------------------
= To join the teleconference only
= -------------------------------------------------------
1. Dial = into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing= /index.html
2. Follow the prompts to enter the Meeting Number = (listed above) or Access Code followed by the # sign.

San = Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: = +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: = +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: = +81.3.5763.9394 China: +86.10.8515.5666
= -------------------------------------------------------
For = assistance
------------------------------------------------------- =
1. Go to https://ciscosupport.webex.com/ciscosupport/mc =
2. On the left navigation bar, click "Support".

You can = contact me at:
gsalguei@cisco.com
= 1-9193923266




http://www.webex.com

= CCP:+14085256800x965904997#

IMPORTANT NOTICE: This WebEx = service includes a feature that allows audio and any documents and other = materials exchanged or viewed during the session to be recorded. By = joining this session, you automatically consent to such recordings. If = you do not consent to the recording, discuss your concerns with the = meeting host prior to the start of the recording or do not join the = session. Please note that any such recordings may be subject to = discovery in the event of litigation.
=

= --Apple-Mail=_11A54A3B-2229-41A5-8F2B-37B2A7AE4710-- From jmpolk@cisco.com Tue Jul 10 09:11:22 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F2811E8194 for ; Tue, 10 Jul 2012 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPbwvyZdRWEq for ; Tue, 10 Jul 2012 09:11:20 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C829E11E8193 for ; Tue, 10 Jul 2012 09:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=95197; q=dns/txt; s=iport; t=1341936707; x=1343146307; h=message-id:date:to:from:subject:mime-version; bh=gKl4PQW2BAF4axOg8U45xJcJkJK7QfwF6fXRejIt578=; b=cFBtxlO7gmSbQxugXtNDsKzojMiIv00h3Yc03sRBbf7YFjR2lod7Kdtn UOaXg+8mur5vFKdyCIFjS9Y+myO5xia8i6NRv1K7v10lKHAgXIAYmtQd7 Ji93xl69RR8gqHEC4fw77F4wAf8h0wgsgUnf7XJ75ehu/4mmACng+jCw9 4=; X-Files: Session ID reqs for Interim-3 v1.pptx : 69110 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAMtS/E+rRDoJ/2dsb2JhbABFt3mBB4I5AX1MF0Q1h2qbPYEooDWRYgOISYV/lQ2BZoJ9 X-IronPort-AV: E=Sophos;i="4.77,560,1336348800"; d="xml'?pptx'72,48?scan'72,48,208,145,72,48?jpeg'72,48,208,145,72,48,145?rels'72,48,208,145,72,48,145"; a="48439757" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 10 Jul 2012 16:11:46 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6AGBiEi015759 for ; Tue, 10 Jul 2012 16:11:45 GMT Message-Id: <201207101611.q6AGBiEi015759@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Jul 2012 11:11:44 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1890830523==_" Subject: [Insipid] Interim-3 Requirements slides v1 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, 10 Jul 2012 16:11:22 -0000 --=====================_1890830523==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Here are the interim slides from *before* the meeting (i.e., what's being presented). Changes will be made based on comments during the call. James/Paul/Gonzalo/Laura/Hadriel --=====================_1890830523==_ Content-Type: application/octet-stream; name="Session ID reqs for Interim-3 v1.pptx"; x-mac-type="534C4433"; x-mac-creator="50505433" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Session ID reqs for Interim-3 v1.pptx" UEsDBBQABgAIAAAAIQCRtStyigIAAPkUAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE WNtymzAQfe9M/4HhtWNk0jZNMsZ56OWpl8wk/QAV1jYtSBoku/HfdxG+yAw1IkLjF2MZa3XYPWd1 xOz+uSyCDVQy5ywJ42gaBsBSnuVsmYQ/n75MbsJAKsoyWnAGSbgFGd7PX7+aPW0FyABnM5mEK6XE HSEyXUFJZcQFMLyz4FVJFQ6rJRE0/UOXQK6m02uScqaAqYmqY4Tz2Q8EUOUZBA+0Ut9piesQIRSR Bf4om8v7CCOGwcdmar16ElIhijylCrGTDcta6074YpGnkPF0XeJqkahA4lX/vSwiHfxNHZTYIbi+ HIKvdMvXapeJZvDBC5omtlVWOjDdXBAT4wrkY0OY4/d4bETH0FZJ+kalQnE1FG4Go0PSRG5iW2Ha oXk7dmoGC+rdRRDUbeCh4kKOvfohsFUVOuTjJx9ukvbTdt0w+WnEdpgU7nBA9OeVM4F0GCu27DTr p3cMQeD+0C/Zho2su6fAPusdGvXz/Hbc0w22A5OfTn6K6RMs6LpQwedndG6NWfwtYNkyZHlZezx9 A01Vx5wKCtma02PidsYxwpnauclVLuSesR0rnHeJPXbP5Kazus1g6DfNYVTSnO0fwsb9xn5qPAiC n+2pD4I2XHsbZQzc+4BZEKyPEbsP0/+EODomY6FzmPCIox0NQS050xZqhWeQTQSaJKhUDge5WTF1 6oygVZjBvjL2U4dzFWifVmM/+0QfBEV/FfCotgWM7m6N0H0oDNaeHFk91eV0o+ri6EEf6VoqXjoT tAkzVCAdO3fsRyz9GWnz1c/bBCui7Cji593BEAS3zrx4SePa5PDXy3H0ENgqBx3k9JOPfm4e1cor GF6TvWFMcXaHRIl+cTn/BwAA//8DAFBLAwQUAAYACAAAACEAR78a0BMBAAB1AwAACwAIAl9yZWxz Ly5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKzTS0vEMBAA4Lvgfwi5b9NdH4hsuhcR9iZSf8CYTNto8yCZyu6/NxR8FGoV 3GMyj3zJkO3uYHv2hjEZ7yRfFyVn6JTXxrWSP9X3qxvOEoHT0HuHkh8x8V11frZ9xB4oF6XOhMRy F5ck74jCrRBJdWghFT6gy5HGRwuUl7EVAdQrtCg2ZXkt4vcevJr0ZHstedzrC87qY8gn/6e3sEig gUAoH3EVYpZFMvkurIbYIkmuvXrI22nMKLKai3nQ5rQg6gb77MD0M5TPWPESsP0JtP47yDeNUXjn 1WDR0cwQxDTjyxQCiRAx5bJx7EsvdHVKkBoSefvLyMacJdLlKUl4IHQa9TIKQvgQiclnqd4BAAD/ /wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTYu eG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+D eFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQ yRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxz wWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAA AHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5E P2BJtm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7N clFfacBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZx m2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwME FAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVs c4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1 rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRc ZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5By fue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQDwqpwz2AAAAM4BAAAgAAAAcHB0L3Ns aWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOskcFqwzAMhu+DvYPRfXaSQxmjTi9jUNip7R7A2Epi lsjGcsfy9vUOAwcKu+ymX0KfPtD+8L3M4gsT+0AaWtmAQLLBeRo1fFzenp5BcDbkzBwINazIcOgf H/YnnE0uSzz5yKJQiDVMOccXpdhOuBiWISKVyRDSYnKJaVTR2E8zouqaZqdSzYB+wxRHpyEdXQfi ssZy+W92GAZv8TXY64KU75xQFDLyefYOC9WkEbMGKas2V3Urizuo+1rtf2rxj9G7WcM1b7yqPqsq dL9mavOF/gYAAP//AwBQSwMEFAAGAAgAAAAhADMOHgTBAAAANwEAACAAAABwcHQvc2xpZGVzL19y ZWxzL3NsaWRlMi54bWwucmVsc4SPQavCMBCE74L/IezdpL6DijTtRQThnUR/wJJs22CbhGx8vP57 c6wgeJwd5puduv2fRvFHiV3wGrayAkHeBOt8r+F+O28OIDijtzgGTxpmYmib9aq+0oi5hHhwkUWh eNYw5ByPSrEZaEKWIZIvThfShLnI1KuI5oE9qZ+q2qm0ZEDzxhQXqyFd7BbEbY6l+Ts7dJ0zdArm OZHPHyoUj87SL87hmQsWU09Zg5TLOy/FXpb3QTW1epvbvAAAAP//AwBQSwMEFAAGAAgAAAAhAGNc I7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc4SPwWrDMBBE74X8 g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIXvIZaViDIm2CdHzXc +8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q0oK5yDSqiOaBI6lT VX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhopa5Bye+etqGV5H1Tb qN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlNy54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHic HebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOO e6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848K xYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAA ADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9 iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0Izugt DsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0Hwx xdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA //8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU5 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17c6wgeJwd5s1OfXiP g3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQPGvoc457pdj0NCLL EMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5juTzjwrFg7N0wSk8 c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACEA AABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTQueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyII nkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokY Ds1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7 BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBL AwQUAAYACAAAACEAS/U97L8AAAA3AQAAIQAAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMy54bWwu cmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIX vIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cN acRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuoo a5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJ tm2wTUI2iv17c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFf acBcQty7yKJQPGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp /s8ObesMHYN5juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAG AAgAAAAhAEv1Pey/AAAANwEAACEAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTEueG1sLnJlbHOE j8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxA kDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTq VETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7n udjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIQAAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGUxMC54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZtsE1C Nor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nAXELc u8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7PDm3r DB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAIAAAA IQAt8SEchAEAADgLAAAfAAgBcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVscyCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyWzWrDMAyA74O9Q/B9dZz+j6a9jEEPg7F1D+Al ahqW2MHyuvXtZ9KRpqWoF+NLQEoif3yKFS9Wv3UV7cFgqVXKxCBmEahM56UqUvaxeX6YsQitVLms tIKUHQDZanl/t3iDSlr3Eu7KBiNXRWHKdtY2j5xjtoNa4kA3oNydrTa1tC40BW9k9iUL4EkcT7jp 12DLs5rROk+ZWedu/c2hcSvfrq232zKDJ51916DslSU4VmUOrqA0BdiUtSEes9OBI2X8OoQYBqIQ CYnhVca+hJ9Xoxs8CelSFEUoF6SKaaCGTCgTIglEIQSJ4VVGYwAvPosuRVEEc0FBiInPjihtAV8k WjCnPdJLIu8FZIsSN1f9jTErPyt4t4fKDeNumPWSpCGfIO0AvRTUS/7P1uMTpCCvfSPG/Jh0I7zL OfWn/7MRMYUxDkQxoiBEKApBY3jdOMSHMSdlzH22xLrTUe8U0oa8vZJbZOSTgTAxpEx4FUFAzCgI EUqF6Fzws/Pu8g8AAP//AwBQSwMEFAAGAAgAAAAhALQKHI/vAgAAuA8AABQAAABwcHQvcHJlc2Vu dGF0aW9uLnhtbOyX32+bMBDH3yftf0B+nVoC4VeikKrdVKlSJ0VL+we4xjSoxiDbyZL+9TsbZ5jQ h0rdy9S8AXf39fnD+Q4WV/uaeTsqZNXwHAWXE+RRTpqi4s85eny4vciQJxXmBWYNpzk6UImull+/ LNp5K6ikXGEFoR7IcDnHOdoo1c59X5INrbG8bFrKwVY2osYKbsWzXwj8G+Rr5oeTSeLXuOLIxov3 xDdlWRH6oyHbGpbvRARlJg+5qVp5VGvfo+buYpiSxDu63j5Jqm4briTQQUvYtmTFTywVFXfFvVQn T7yqyFEYRGmUTZMI2Im5fgK+AfKXC/+tcN4oKk8kB88ckcSqDOx9Gm5Kd0WXTJw4WYQ63iRxNCex Y56OzLG7h2hkTlzxeGx2o03ug7XTwFk7HUWnoWPORuY4dcyzsXnmmIPJyJ5Aqfdvx7yeQXKJm1ww BpdO3fgxuXSg/wa6QX6GXVce7ktcv3pkn6NZEEWTCQiSQ46SLM7MjTq0cCIlEZTyaG8zMJVhw/56 6rCjhimAgpZ4y9QD3au1OjC6XOA5PFuthL36tRIew7oJUH7xuNb0fNeF7VjQgg9mz9A3GKBQLEe6 e+B7fiNezHUJ5+baODxhSZG3AUE4+astJ0o76LVkS25oaa9WRHk7bIS6BQfW6xKOm4l4y89aYRc6 9xcqdD+DDtOt0rCquK0YMwK6N9HvTHRrqX13NkHZ9dINhXuacYkJcL4WFYZ9kg0W0BJ0+pAinlPs +Hyr+QXFnYHIEwORPUVI0QC1GLUQXIaaaI3FfY6iONW5n/l+mK+GavlOe77daTjz/Xj9aqiWb9Tz DaZpkJwL+F80CE3VAo4dwFmYwRg4V/DHK1hTtYCTHnAYZlDALmAYLQ/4af16nKVvDD34ZjBzo5+B w5mnPyHNGP2/ZpTGYgmlDqE0mg6H1OclpLFYQllPSOOBDzfnkH5eQhqLJTRzCCVxOpwTn5eQxmL+ EQHBydc5/Bm4P6rLPwAAAP//AwBQSwMEFAAGAAgAAAAhADQC9VkbAwAAxgoAABUAAABwcHQvc2xp ZGVzL3NsaWRlMS54bWy0VttS2zAQfe9M/0HjZ1LnUiB4kjAttBRKIUPgA4S9iTXIkpCUkPD1Xck2 F8eE4GlfbF12j3bPXqTB4TLjZAHaMCmGQedLOyAgYpkwMRsGN9c/W/2AGEtFQrkUMAxWYILD0edP AxUZnhDUFiaiwyC1VkVhaOIUMmq+SAUC96ZSZ9TiVM/CRNMHRM142G2398KMMhEU+nobfTmdshiO ZTzPQNgcRAOnFi03KVOmRFPboCkNBmG89iuTRuhZPOGJ+xt1rQHcSCxOtJqosfbbF4uxJixBvgIi aIa0BGGxUYj5qUAxHIQV9VmJRKPlVGejAY3QN7IcBkj+yn1RiUawtCTOF+Pn1Ti9rJGN0x810mF5 AFrwdKjzKvdo3Z3dTrdbenQFMYZ9xoF0n5zLNSginMv4zhAh0d2cBXmUojR801o+pEAT45Zz5+OL RXmUY8QdrlJiVwp5i62+ZpZDIZrve8JKFYOkezbt8rtMVo6ZW/z7RRpxYyd2xcEzhn7RCPHxg/Hh aM8wANG6mQQkYdo+k2hHEzAu41unx+QK7udMg0sqM0DKLEasgLl9HwxFC6nac83jMOhhvr+wgJjM HnGgWG5FpO0I64ScCguaZa1exQgQyZhqelV1qQba8U0jpAEZLOnCYR7wjWHvrYe99x/Dbua3edix ijDFy0x5I/yO2UqlHBy09xyrGNNev7/nGPYpUBbNfru/5wVc6XT2d7tuktOTI3la8mQsmWqUWC4K 3a/vBhib39S2KpGtz646RNDYIrHZ1KQOAzttjFuD12LCMMWSlilKBIeN8TfYreF+rd62J6TO8Ha7 YuemyqnE7KlyfPlg891QdB2fWC87Sl50herbTqwrum4zpnNOzvByNTvkRIpHvGhJxZGtIUlBuK8F 7HKUz+bAtGyKV+DskDO85QwZS363UzXuA1RV87cZb1UUR+I5nWtatawpbecMU78pZXXWrXH2Ycvq UH/RRDPg/9LQxgwWifKbKrx2X6O8dSP5Dpy/r3BYPrlirv9QdbnwDOFLEu/EI7+k8O3oqhRFn0Uc Bj7V/gIAAP//AwBQSwMEFAAGAAgAAAAhAJ9pREJsAwAA7wsAABYAAABwcHQvc2xpZGVzL3NsaWRl MTAueG1s3FbBbts4EL0vsP8w0KkF7ChNt0UjxC5Sp7sIsG3dOP0AmhpbwlKkStKO3a/fR0qy4cR1 4yK91AebomYeZ968GfPi7apStGTrSqMHyYuT04RYS5OXej5Ivtz+3X+TkPNC50IZzYNkzS55O/zz j4s6cyoneGuXiUFSeF9naepkwZVwJ6ZmjXczYyvh8WjnaW7FHVArlZ6dnr5OK1HqpPW3j/E3s1kp +crIRcXaNyCWlfCI3BVl7Tq0+jFotWUHmOi9E9IQmcmJysOvq28tc1jp5T+2ntRjG19/XI4tlTn4 SkiLCrQkafuiNYuPGmZYpPfc5x2SyFYzWw0vRIbcaDVIQP46fMNJZLzyJJtNud2Vxac9trJ4v8c6 7Q5ABJtDQ1ZNRg/TOT97gXI3Gd2wRNnniulsk1zjIYDwr5H/OdIG6TYsmFEBa7601twVLHIXtpvk 5cdld1RgJBxeF+TXNXjzpVfc2jUvI1udvQPjkUq/emfydaBlit+4KTLl/MSvFUe6kJTIAI4vFEch mEHCuv9lklBeWr9l0A8n7ILc+9dXdMNfF6XloChHzy7AmEfBOqDDaOQqP1Is0DdtyfzwZfrq+T0U 1vlYWHFzKCqciPiRepcnlk2ZDhbr/GGxXv7CYgXqE+geouxq+wQ1i02FYupJLQPhrpZj6Wkp1CA5 P8UnymNjEKgKIupqdJ9W922QnP0FL5pGZW6KT2wxZ9Cxe8p28/7zq3tl2y+l76PvQc2OhNyGugeM bgsG9xBqOSvZUrVwHg3oyfKShSKh11TqZuBC3NjGaOScvImvJtdjWji2Pcp5iTlKxlJuwhBuQf36 BEeUDiBSLXJ20Q1el3mOWel6VBvre1QY58OEAFDj3jwE7GbV2vfNrI8ZYmzeow+XIxIdDCDbNc1E Vap1j7wV2gX4OBV65BZTJ205RZrXVz0aCaXQrLATc8SByI0v8C7kFGYNltgL6qRaWPzd0A7xTXPF Dtto53i1fa+NH62IpwnjWFkeFv3rHaKObqk4eP3wp3Xe+u+W68dRHO6TZ9JU01JD+qWG+I/McIt9 gDnLX48dF1vcPb29+5exI5Snld3Tov305P5xGBu6IJEdPn77Mx9eAuJdoLmIYtndTaWyH0T9aRkH Aq7cnu0obtW4ZAfWYLo1CRi40/4PAAD//wMAUEsDBBQABgAIAAAAIQBfgK+gIwMAAAwJAAAWAAAA cHB0L3NsaWRlcy9zbGlkZTExLnhtbLRW224TMRB9R+IfRvsEEumGUC5aNUFQLqoEpTTlA5zdSdbg tY3tpAlfz7E3m5I2DS0SL8nGnjmeOed4Nkevl42iBTsvjR5mTw/6GbEuTSX1bJh9u/jQe5WRD0JX QhnNw2zFPns9evjgyBZeVYRs7QsxzOoQbJHnvqy5Ef7AWNbYmxrXiICfbpZXTlwCtVH5oN9/kTdC 6myd7+6Sb6ZTWfI7U84b1qEFcaxEQOW+ltZ3aPYuaNaxB0zK3ipphM7Ksarit7cXjjk+6cVHZ8f2 zKXt08WZI1mBr4y0aEBLlq831mHpp0YYHvJr6bMOSRTLqWtGR6JAb7QcZiB/FT+RJApeBirbxfJq tay/7Igt6/c7ovPuAFSwOTR21Xa0o53+4HDQtXTOJXSfKabBprs2RQDikyl/eNIG/bY0mOMa0fzG OXNZs6h8XG67L08X3VmRkni6rSmsLIgLMihex7Wbia4u3oPyxGVYvjXVKvIywXdaFIXyYRxWihNf 6EoUAMcH1FEoZpix7n0bZ1RJF64oDKMx++j33sk7Ouefc+k4WsrToyNQFqBYB7QfjXwTjhULXJy1 ZmF0mD9/fA2FdXUmnDjfVxVORP1ovesTj61O+9V6dlOtZ/9Rrch9BufDlp24/000/2uYDQ77uBOT 5LCNiMQOAwNXbwf95++/vrxG/25L3I6+A7W4J+RVqTvA6CRQM/eBJkzWwIgTXLFgwCo8KMOKxidn FJyI444uZahJaMzkqhdMD1/kW/Ou46eSHU2daRBVRZgYUvECo9JTqEWgyuCaBvJza40LWJO4t3z5 R/4TbJY4xtNkRUIpE+d0PFXqwK7hSgq3SiXq7xgKaScVmw5HkAEqbwrzcqaFAsTBFm2txZPPMdxu uRN3lmUL7b4S7zfQq62yu1Fw/fbeWmkaRmH0z55Z59M9q9jruQvI0/orSeZrM8fLGwaca/lzjj1N QTacPOStKBmWkI1UwkXZo7jH8AXm5bakd9FxUxf62hLt7xa4mXpzQKY52b6l8di9uEvlPgv7ZZGM gf8jsPFxWrKwZSwEoVchEQMv/N8AAAD//wMAUEsDBBQABgAIAAAAIQDPP2HG0AIAAOcJAAAWAAAA cHB0L3NsaWRlcy9zbGlkZTEyLnhtbNxWwXLTMBC9M8M/7PgEh8Zp0jLgSdIZ0gKdgTbEKReGw0ZW ak1l2UhKmvD1rOS4mQSbNEPhwMWWpd3nfW+fbPXOlpmEBddG5KofHLfaAXDF8kSo235wM3l39DoA Y1ElKHPF+8GKm+Bs8PxZr4iMTICylYmwH6TWFlEYGpbyDE0rL7iitVmuM7T0qG/DROM9oWYy7LTb r8IMhQrW+fox+flsJhg/z9k848qWIJpLtFS5SUVhKrTiMWiF5oZgfPZWSQNixmKZuLspJppzN1KL 97qIi5H2y1eLkQaRkF4BKMxIliBcL6zD/KOiMBqEO+m3FRJGy5nOBj2MiBss+wGJv3JXSsKILy2w cpJtZll6XRPL0oua6LB6AVXw8FLHqmT0K51ORWcirORw/MCqDEVK/ZizOwMqJ56OfkmPXS0qMMfZ wRcp2FVBylgHtY4rF70eVbwhTb1Ydvk2T1aO+JTufhIjaWxsV5J7QahsjAicLiS/ROdQro5u4gAS oa3XCExmh5IjeXktox3E3Dh3H12ew5h/nwvNnYEMvDgNT1/2SCRLPVojc5WMUOO48QWOMEZUCrGo SqZhqWmzst1K2WGuLL0dRhIZT3OZcA2dP9NZJOSSqhV/TWLzox90Ttpk0an3/UZyrmn/0k6okX58 8fkN7khc38Fm+BrY6EDITa01YDBJOW1maoqYCeqGSfM5fdmmHBh9WKyeM8sTEArMnKWAcI8rQAM2 hwzvKNPSgrA4pQ1DnzuwGpXJhLecy4ovR0CfT/jQ6na6LdiqvHSStxPt9wbrbZRppLGFc6i+e9o3 3aq4aQNuitx1R43i0bYK+zEbibu9+2/aN46/jOBr91trR479XdsjyFbvnhbtiZ3AdqgfCv+/OGEy JCec7DjhwDY+OPo3/xP/WykPIDSsziRM6k9YXC+8+nTUslwP/VRBhyuHRqGbEIdBZ5mfAAAA//8D AFBLAwQUAAYACAAAACEAdRF1dGEDAADcCAAAFgAAAHBwdC9zbGlkZXMvc2xpZGUxMy54bWzEVtFu 2zYUfR+wf7jQU4fVVpymwyZEKbZkaQ2kiVGn6PM1RUdaKJIgKcfe075mH7Yv2SEl1Wibbmk7rC82 TV0e3XPO5b0+frZtFW2k843RZTabHmQktTBVo2/K7PX1+eTHjHxgXbEyWpbZTvrs2cm33xzbwquK cFr7gsusDsEWee5FLVv2U2OlxrO1cS0H/HQ3eeX4Dqityg8PDn7IW250Npx3Dzlv1utGyDMjulbq 0IM4qTggc1831o9o9iFo1kkPmHT6nZROwEwsVRW/vb12UsaV3jx3dmkXLj2+3CwcNRX0ykhzC1my fHgwhKWfGmFY5O8dvxmRuNiuXXtyzAW40bbMIP4ufuIQF3IbSPSbYr8r6qt7YkX96z3R+fgCZPD2 pZFVz+hDOocjnesmKEmzt6z6UMbRCyNuPWkDnpF+T09cbkawyDnC25rCzkKZEKGGuP5h0mOM99A0 iRW2v5hqF4mv8J02uVA+LMNOySQI0uYC4PiA/IpjhUo9eb3MqGpcSBqRb8OpkoxaHmQMJ1eoRZp7 30lPj2b54XfHECbAlwFN6mrBjl99FDSS5AKvR+Zjmlj2On5czSejmqdGB9QaLRQLWRtVSUeHX6Zt U6EyRvn/A1nhArXsLsrs6ezoyVMUYqMr5Fxmk2EjOdOdg0oydg0qZfZ9+9tEhUgFtnU/d8Fcdu1g PCRdNQLKSv0q+Q8JY218locvG920rGgtZbVicUu8Ml2gzsuJYC8pxNuCbkPoMuvw1x9/vuNx716y MCXx/1H919p6v2C/XqqfcbNQ2EI67Qc3lkZ1sRtTZQQJJ9Fc9Q3VklHwnuCXbypJZk3L+WL6EIN+ mh0dHaAW1UalXvvlNalszRefUJT+9zLDuEIO/9hiFs5Y41kVNL8EufkZNX6vAEfCgw6EUTosJxtW HfTQajelF+ZOYgw/pjfP41m+w72JUkHfgElJJtToGrfa3GmyzgQjjEIfxnWgYGglSWAKQl6HDYQj Ou0E14lkCaDiXkxkKX2c9pP52ZTOcWXkllur5GN09YCzQnVwifUOa2TYVCRq3GURookD9B4CqIyO UGOaDjnusxOsI6TvrDUu3Of4hw019dV+6mI5DmKh3Eu2V5tUo/h/gVxO05ZFhcX2jNB9SMTAAP8b AAD//wMAUEsDBBQABgAIAAAAIQAgORZ8FwIAABAFAAAWAAAAcHB0L3NsaWRlcy9zbGlkZTE0Lnht bMSUz2obMRDG74W+w6BTe3DWcaGUxXag7h8CbWJi+wGm0tgrqpVUSXbst+9Iu5uQNIFADr3saqWZ T/P9dqTpxbE1cKAQtbMzcX42FkBWOqXtbiY262+jTwJiQqvQOEszcaIoLuZv30x9HY0Czraxxplo UvJ1VUXZUIvxzHmyvLZ1ocXEn2FXqYC3rNqaajIef6xa1Fb0+eEl+W671ZK+OLlvyaZOJJDBxJXH Rvs4qPmXqPlAkWVK9oOS5uxMrozK7+jXgSiP7OF78Cu/DGX56rAMoBXzEmCxZSyi6hf6sPJpOYwH 1aP03aCE9XEb2vkUa/YGx5lg+Kf85CSs6ZhAdpPyflY210/EyubrE9HVsAFXcLdpdtU5+tfOZLCz 1skQnN+56kKRU384+TuCdewz2+/syavDIJY9Z3nfQDp5JpOyVB/XLRYeQ3xkpgVWOn526pSN/+J3 mcTaxLRKJ0MFCJeNNYvzg/EbzB1KdrRZCVA6pMIIYpsWhpB7uceY5tfci3AZ454ivJtUk/dTBpP4 v/RqZNUSA948K5pNYs3bc+VDmTzsOD5P88NAc+Fs4l6DpUFJjTOKAkxex1Yr7owB///BehmcBbdP sNUWDdy6kC8N4MlNpJHEyLj53oAb+rPXgfKhjQ/Id0wLWO72V/yE8i+6k8rD4fBKE36ivz6UjuE7 KVFYlCnPZfZ9ex+SNfjQ/wUAAP//AwBQSwMEFAAGAAgAAAAhANSTE7ozAwAA8wgAABUAAABwcHQv c2xpZGVzL3NsaWRlOC54bWy0VttuEzEQfUfiH0b7BBLJNgUKWjVB0BZUiUtp2g9wvZOshddebDdN QPw7x95sStP0QgUv2V175njmnJlxdt/Ma00zdl5ZM8wG/a2M2EhbKjMdZqcn73uvM/JBmFJoa3iY Ldhnb0aPH+02hdclwdv4QgyzKoSmyHMvK66F79uGDfYm1tUi4NNN89KJC6DWOt/e2trJa6FMtvR3 9/G3k4mSvG/lec0mtCCOtQiI3Feq8R1acx+0xrEHTPK+EtIImcmxLuPTNyeOOb6Z2QfXjJsjl7Y/ z44cqRJ8ZWREDVqyfLmxNEufBmZ4ydfcpx2SKOYTV492RYHcaD7MQP4i/sJJFDwPJNtFebkqqy8b bGV1sME67w5ABKtDY1ZtRtfT2Rm82OkyOmYJ2aeaaXuVXOshgPDRym+ejEW6LQt2r4I1v3XOXlQs Sh+X2+Tl51l3VGQkHt5UFBYNeAsqaF7atZuJrc7eg/FEZZi/s+Ui0nKGZ1oUhfZhHBaaE11IShQA xw/E0QhmmLHpnY4zKpULlwyG0Zh9LPfe4T4d8/dz5ThWlKcnu2AsQLAO6HY08nXY0yzQN0vJwmiQ v3y6hsKmPBJOHN8WFU5E/Ei9yxOvrUy3ivXquljP/6NYkfoMdY+i7LT9b5r5H8Ns+8UWOuIsFdhK Q2KHcZHOj2IdH3wdrBG+uQguAVdQqW7CqKCHAmyqgMNA9bkPdMbUWNTZGToIY5CEIVHWyigfnAhY aNfQ5eyM0FTyDOONLiolK6qtUbDxFCqm8eFRDz5x/FGwdO45LasSRasmil1cXX4tsGVhUCrM66lf wl2wYxKBvK1jVMoEUoaCwpe0dYPBHsvfTkiQx4hGxCjaXrA9POLx5NuOoSfcn/afUSNcax/D8xiA JIXWT/trPN5U+ZulaHsgNQKG3w1Ns8F1XYQrOHfVwg3FtY7ZVZpYy/Au+FWpbQIs6Oef84cGqU4M BlOrHknHuJ/MlKC+8UKmm65PJ/Fm8FYrqQKXffp1Jagr6f8rGv8CJ878pYhpJD/E9fogTPOwvYzx 2t3PUrtPovkySzLgbwdaaS8tNWAtBgLTS5OIgXv9NwAAAP//AwBQSwMEFAAGAAgAAAAhANVZl0zK AwAApAwAABUAAABwcHQvc2xpZGVzL3NsaWRlOS54bWzUV9tuGzcQfS+QfxjsUwJUkqM4hbuwFMRO WhhoE9Wygb5S3JGW6S7JkpQs9et7yNWubFm1YyBFEj9oeZkL58yZIX36Zl1XtGLnldGj7GX/KCPW 0hRKL0bZ9dUvvZOMfBC6EJXRPMo27LM342c/nNrcVwVBW/tcjLIyBJsPBl6WXAvfN5Y19ubG1SJg 6haDwokbWK2rwfDo6KdBLZTOtvruc/TNfK4kvzNyWbMOjRHHlQg4uS+V9a01+znWrGMPM0n7zpHG iExOqyJ+vb1yzHGkV786O7UTl7Y/rCaOVAG8MtKiBizZYLuxFUtTDTEMBnvqi9aSyNdzV49PRY7Y aD3KAP4m/kJJ5LwOJJtFuVuV5ccDsrJ8f0B60DrACTqnMaomovvhnLz8+biN6JIl0r6omIZdcI2G gIXfjPzLkzYIt0HBnJeQ5rfOmZuSReHjchO8/LBqXUVEonNbUthY4BZUqHgr12wmtFp5D8QTlGF9 ZopNhGWGb1oUeeXDNGwqTnAhKJHDOH6QnAqHGWWse9fTjArlwg7BMJ6yj3TvXbyjS/57qRxHRnl6 fgrEAhLWGnrYGvk6nFcsUDfblIXxcPD6xZ4V1sVEOHH50KngEedH6G2cGDZpejBZr+8n69X/mKwI fQbeg5Rtbr9AzlJRIZl6amUE3Fs5kYFWohplJ0f4S/ToBCJUkURtjvZh9f+MsuExtGiWmNkln9ih z6BiD6Tt8v0fw720HabSzvrO7gF7OV0Eqpc+0IzJGtBthkIKhqRxqWdhcmPQaYteMD18yDec9ITq 0STaOSlPwQnt5zg9F2TQd+ZJt1BzrIG3ragn4Zg+GaUhF8yCQ8mOVkqQ0KR0YFdzoYTb0HPuL/o/ wsnk7M8Xfboq4aRWizIQmuKyCpDGpkwFHccwFNOxZDLwjcmtc3e1VOAoaq7Y9ekOkg21E7+7zD09 1/9VRLt87GU7tp7WaSTLN8KyV3eweTKHU6cL4/yJVjqubvXvZujxU3T6h2rnENNx74NBBa9wY5NJ RAygUyKPNDoRFztzXObg9+2y6OrACheUVBY3tF40jKzBTWVB8BDrIM16FOU2qKvOqEnlAyVUXONg tiEz8+xW0dIef7f+0NVa/vrIchaybAurv4f241zs8PpiLPwaPh/rgHsV1/bXLcfQUo/3gHuiwe+F 7OCvFR48Rmfc0YiWuumgaMalM8tFSdOLCZ0Nz67fgmJuWxa3GrNi/71S7f7LJT1gmtczhu2DWlbu d2E/rhIT8H8CLqXztGRRmrFYILoTiTbwEP8XAAD//wMAUEsDBBQABgAIAAAAIQCDeTF/GwcAAH4g AAAVAAAAcHB0L3NsaWRlcy9zbGlkZTIueG1s7FrbTiM5EH1faf/B6tcVk3vnIsKIwLA70lwQYbQz j6bbSazpdrfcJoR9mg/Z/bn5kj1ltzsJSRgYQOxK8ABO2q52lU9VHVex/3qRJmwudCEzNQwar+oB EyrKYqmmw+DT+cleL2CF4SrmSabEMLgWRfD64Ndf9vNBkcQMq1Ux4MNgZkw+qNWKaCZSXrzKcqHw bJLplBt81NNarPkVpKZJrVmvh7WUSxWU6/Vd1meTiYzEcRZdpkIZJ0SLhBvsvJjJvPDS8rtIy7Uo IMauXtvSATSLxklMf4v8XAtBIzX/Xefj/FTbxx/mp5rJGPYKmOIpzBLUygflNPtRYRoGtRvLp14S HywmOj3Y5wPoxhbDAMa/pt9YxAdiYVjkvoyW30azj1vmRrM3W2bX/Auwg+qlpJXTaFOdplfnXJpE sEallZvKsfRdFn0tmMqgJ6nv1Is+zL0w0pnE5zNmrnNYxpCoANaCKu1mv90Pu81+p1zoZlsDeQEF jGytZxajLL4mS1zgL0nlAwU8HV6abCINm2TKjCOe4B39On6syNXJSWHG5joR1prQmQ+sDI2zSzjB W6i9T2PA+y/sjASwWGqzNLU5eJskl4XRAImaMjMT7FRnF4lIB/swrcHJliIv7iMYi8r5dkt3381h AvwzuCIbZRdsLjkbNUefDlmm2Xh0tLYlvAMKw67eiBi6Y999+B1/+GcigsNPAYA22RTu4I93FQBH M8wRh1pnVzPB42InGhxEVIUQOmB2cfU+i3FyHIcZkB1ueELY7TV6dCQ4jmanX6exPUfvFY16GNoJ 5BthvR9WAPCScl2Y30WWMhoMAw2t7Jv4/F1haFOwUTmFNlBkiYxPZJLYD3p6cZRoNufJMGgd9477 rRJea9MSxa5of0BPwHgyRQSNjLZvWZtXrInrdY57h9vEpdIIYFOmwwCqlZDmAzLvGxVb9Q2XiRtj +4myZ0wGpWPyZ+19AFCJZhliK+3Jrt70CDqL5caZ4O/USH+1gY3OF7g/vVQRzGddfYcH3W6+E/uz TV+K3cqGiQmPAIYjnsgLLQOWSxPNTngqExxuqx2waMZ1IbAN7+VwYnqrOTjiOksejP1wE/s2RD0L 9lu9XogUabHfCfHpBfsv2N+GfaSBByO/u4n8kHy1Qr4drzKZ1URNPujjbclhVtHb6odNio32+J4o ctvM5gJgQdmetpSoMzFxlKPpojHRUlFFdB5F4H6hezTjsXCBvuNjLmKrJbK0wiYKK5AkT5AgKtmN 22RDZ4gp59NSMZkgBVWL6z9eXK2wbwbdqRanEkxom4DEOE6GN7v5LkM4wzx5iqB9xmJy5mgv8quL 0rAhMsdNolORLXq6O13uSh8wbpUELA+6oytECzUuCfARDR10QHGwP6L0fe8QYxA/OZ0ZZjkOO8qU wvmBbPUq/6gEQAGDD1YA0pUlu80S9ir2T+Br9ok7IuthlQS6IyxvCytfu+y+4WYNEB6fJFoYbLhZ s9nDFGQRIkieLTlQeo/19KdkSMR0SeFKU4fvHXyJyAcSsOMjJdfnxAZJ7U1yss03b/Efj+LtjneL 7/iFP+V4fvFPOJ5Z+MVbHA8xKvKw203AG2Grv7yBIVyOsgVrLNFGWGVE8nCTKk1XXceelo03OhTG HSNpdVutTUbSCuvtHkoFBLZWGHYbni/vwNqP2LjKiIrbvOFIdr/T7NiAt/Lksfnylea41CrUOVxo zemqeSLLy8LyFrqdRv88d34MHhxLFGim7O0x+/7t78/fv/3zSOGwdf9wiFO7bzRrN/oND7B2p4t4 doM0vMSx+xAIH4qeL44hCbrC2LmPYzYdVqzyeeJYs9umXGlvVu0eIIeQZWNMxU1b3XodsWsZx+y2 kc5e4tiPawCPF8f2XBz7cvc4dntarWpbFRxtfnpmOHYadVc6QtLcGvWquxSl1Wa90e60LGD/X3i0 /P5+ufRRSlKPAcc/Z9wwWdjir1Dxnsn28AeFYpttZYxrpJxIoV+zLfnWFmHtLeheNTa84JRrjlvU Wp2azPgAlZZSLT239XD3C+/5z9ibuSK3mUmFNgOq/LD956rmvfb1l1cvJn8AHpaX54/nfwDfMDih /JpxLViUpemlkpHrfOCmjptvcs2upEFbB32QDL/0FvPfr+NQkYRlx2E9LLvI4VtOT3zH8Q0FCrUv HYfn6DjQzfnQdlFsW4jd7EA4OEQjMSlHp6ZwlTvfFijylaeHE7ToUJnJo23zyqePUa5aLy4uS3Br Ra2brvpbqvYSUxZLKme04e9OjmXrnq49TeWFsmMdJfo9zz/ObckNjXg0lFDDxFc5WjlUmMHU5RQU BCVKiVPbPVJoi9Eg51iMaeeunIUWd3yJJpJUMJVUaFEFDL1zwzVK0krgXwdA9dHLO3fd3vQsy5xW pSQKCU40jcrXYYj/Hjj4FwAA//8DAFBLAwQUAAYACAAAACEAxXUDgtcCAABdCQAAFQAAAHBwdC9z bGlkZXMvc2xpZGUzLnhtbLxWTXPTMBC9M8N/2NEJDo3TwlDwxOmUFnqBNDTtcFblTaypLAlJdhJ+ PSs7TkhpOp0C8cGWpf14+3a10uBkUSqo0XlpdMYOe30GqIXJpZ5l7Ob688F7Bj5wnXNlNGZsiZ6d DF++GNjUqxxIW/uUZ6wIwaZJ4kWBJfc9Y1HT2tS4kgf6dbMkd3xOVkuVHPX775KSS81W+u4p+mY6 lQLPjahK1KE14lDxQMh9Ia3vrNmnWLMOPZlptLcgDSkyMVF5/Hp77RDjSNcXzk7s2DXLo3rsQObE FwPNS6KFJauFlVjzq0mMBsk99VlniaeLqSuHA55SbLDIGJG/jG9S4ikuAoh2UmxmRXH5gKwoPj0g nXQOCMHaaYyqjejPcI4PjwlCG9EVCkr7TCEcrYNrNThZ+GLEnQdtKNyWBXNWkDSeOmfmBfLcx+k2 eDGqO1eRkejcFhCWlngLMihcybWLDVudvCfGGyrD4qPJl5GWW/o2kzxVPkzCUmFDFwXFUzJOL0qO IjAZQ31wM2GQSxcaBsGX4Uwhp0pfkRyGpzOk4h4QV4FStTJBU2Pu+NVOSzEynpJPgttho2FL7aME r0tmQ/Cb/0hwpItRrVIhdfn4Bzw3G4ESoCdWRMq9FWMRoOYqYx/69DQpXQtEqmLin5WgK6wlzuHG 44HgHj1IDd8vDvr9XliErby1GWnSsna4F4ivvlVS3KnlyWtwLVqHPyrpMHYq/yhGUDVxdsgiOXvB eo4BXSk1wryQogDuEGbG5MCJ2cex7g+j9KLyHuIpQqB8hdvAqDk+eYNuyuHvqN7l0f/M2NFbqvjd beZ+Xe4NyLpLbUjYWw5HtGfpTJAOXKUwha1d8KxGMELMIRgoeI2AnGr3t10GvrLWuEAit0vgAajN +wB0Z4Fq1Tl6WxB2te+mi7fHPg27m4BQ7iu3l3XTxOiCQ3vorJmydKWJNJPoRiTaoBvELwAAAP// AwBQSwMEFAAGAAgAAAAhABTvt4+AAwAAzwkAABUAAABwcHQvc2xpZGVzL3NsaWRlNy54bWzMVm1v 2zYQ/j5g/+GgTxsQS6kTbJ0Qp1iTbjXQFy+2fwBDnSUiFKmRtGPv1++hXpI6cdpubYF+kSjp7njP 89wddfZiW2vasPPKmknyLD1OiI20hTLlJFku/hg9T8gHYQqhreFJsmOfvDj/8YezJve6IHgbn4tJ UoXQ5FnmZcW18Klt2ODbyrpaBDy6MiucuEXUWmfj4+Nfslook/T+7nP87WqlJF9aua7ZhC6IYy0C MveVavwQrfmcaI1jjzCt915K50Am57qId98sHHNcmc2frpk3M9d+freZOVIF+ErIiBq0JFn/oTdr Hw3MsMgeuJdDJJFvV64+PxM5sNF2koD8XbzCSeS8DSS7l/L+razeH7CV1asD1tmwATK42zSi6hA9 hjMe4CxU0EzP7lB1pgKub6y88WQscEb4HTz5bjMEi5hj+KaisGvATIihervuY8vHYO/BaUtW2L60 xS4Cv8a9fSly7cM87DS3hCBtkSM4LqBfi1ihbEbLeUKFcqHliHwdLjQL1HJPYzifs4/VPZpe0tLz SArPnn46zU5/PgNDAQL1YdkUM+HE1ZPRI1qRIw9AGPLFsiP0aVpPBlovrAkoOpppIbmyumBH4y8j WRUokUGHb8av/2eSjE+PUZ/rSeJN+QnGT9JxSjNng5VW0xSg3a11N+j+B4wfVvN+t4/qmtPvJG1d r42SbR8ThI1KU63KKpB1qlRGBCZlSBh6nZ6MTzDdisYqiICZRo3wnkLl7LqsSFBfKfTSuihNlMtZ rbG8ZowyprUOCgON9Y4cC1kBEdwAr44bxaf5dEZrDw9RQumU3qgbvlWej2AnhdaPckO62HjPq01t CMoULR5mn9I00NvlfIHMqLGAfY2GDRZTCduq1Y78WlYDIT6iHgU7wo2EdLAHajjqtRNahR3ZFRW8 wXz1R2Q4RLWwsoBRAJrywQHehqmwcW77dE/HrifaxsDYeqKJDoh610696xdVA/hQwLltWAYuAE+E FuN0sRwt6FaB+oJXygD1UJisOR4lnqBtXx1gsBY3YBLsfMCZV6UBUdB34Dql74+CS3bQqKAr/nut XIct38/zqQF6QB1ih3MZJ9yBkXr16q9f9/D/l7gH4h19qyx/E18zzf2y/3+1/vjoaE+Q7kcDy+Hf Q2r3VjTvN21T4JcK8+CifdWgDGPnwPTeJMbAP8u/AAAA//8DAFBLAwQUAAYACAAAACEAjMsLg8YC AACHBwAAFQAAAHBwdC9zbGlkZXMvc2xpZGU0LnhtbMxV72/TMBD9jsT/cMqnTVqbrkMIRW0nsQ2Y xLaKbhJfD+eaWHNsy3a7lr+es9NslP1QASHxJXHsu5d7757t0fGqUbAk56XR4+ywP8iAtDCl1NU4 u7n+0HuXgQ+oS1RG0zhbk8+OJ69fjWzhVQmcrX2B46wOwRZ57kVNDfq+saR5bW5cg4E/XZWXDu8Y tVH5cDB4mzcodbbJd7vkm/lcCjo1YtGQDi2II4WBK/e1tL5Ds7ugWUeeYVL2VkkTZiZmqoxvb68d URzp5UdnZ3bq0vLlcupAlqxXBhobliXLNwubsPSpOYwH+S/pVYeExWrumskIC+YGq3HG4q/jk5Ow oFUA0U6Kh1lRXz0RK+qzJ6Lz7gdcwf1PI6uW0WM6w47OtQyK4PCeVRuKnPrZiFsP2jDPSL+lJy6X HVjkHOFtDWFtWZkQoTZx7WLSo4v3rGkSK6zem3IdiX/jd5rEQvkwC2tFSRAuGwsG5wfLrzA6lHTv ZpZBKV1IGoFvwokiZC9vZAyTGfno7t75Kdx46gn05GHvMH+zP2KFAjdoA0u6nKLDL8+iR7ZYcB1M oauXh62gz8t61Ml6YnRg08FUoaDaqJIcDP9OZFmyRbo+/DN9/fdxNnwzYH++qPSZLnvB9FhH3h1M VPKOTTsMzBwQhGmahe6muAuxLVs9aNVNEvMGeKYdOxSzhfO0ZXZAieb4E0oQagwgtVCLkq2GYNXC oZJhHXXwstL8oSuwzgQjjII96lf9A5idTw/gU/9oeHQAfOLC14vpdB/uanIkNcNsFINGVnUA42Ql NQaChY9ofDw/IMb0QK75OQC5efM5g7ED73/9n8t//shGJS35GvAQ8DZpiC5KzZITeD6KoVmoIK2R TFIYnegK2mL5W856Ycunnd9eEDzs7gyh3AXaq2VyHV+F3IWTNGW53IjGoQ8hEYPvmh8AAAD//wMA UEsDBBQABgAIAAAAIQA+gzBuwgIAADYHAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTUueG1stFVRT9sw EH6ftP9wyhNIlJQOTVPUFmkwJiQG1Vp+wOFcGgvHtmy3a/frd3aaVh0wdWJ7SRzf3ef7vjtfhher RsGSnJdGj7Kz034GpIUppZ6PsofZde9TBj6gLlEZTaNsTT67GL9/N7SFVyVwtPYFjrI6BFvkuRc1 NehPjSXNtsq4BgN/unleOvzBqI3KB/3+x7xBqbNNvDsk3lSVFHRlxKIhHVoQRwoDZ+5raX2HZg9B s448w6TovZTGzExMVRnf3s4cUVzp5Vdnp3bikvluOXEgS9YrA40Ny5LlG8PGLX1qduNF/lv4vEPC YlW5ZjzEgrnBapSx+Ov45CAsaBVAtJtityvq+xd8Rf3lBe+8O4Az2B4aWbWMntMZdHRmMiiCsy2r 1hU59NaIJw/aMM9Iv6Un7pYdWOQc4W0NYW1ZmRChNn6tMenR+XvWNIkVVp9NuY7EH/mdNrFQPkzD WlEShNPGgsH5wfIrjB1KuvcwzaCULiSNwDfhUhFyL29kDOMp+djdvZsrePDUE+jJw9EgPz8eskKB C7SBJV1O0OH3V9EjWyw4D6bQ5cvLVtDXZf3QyXppdOCmg4lCQbVRJTkYvE1kWXKLdHX4b/r6n6Ns cN7n/vyj0jOH4onvOLDCUXIPwaH2FTlHJVTONMBDhAdMaY1kHYIB1CbULMNeKVqRk9J8D16pygE5 7eG83DkHoMQeuUYhleRxQcDpgiNhXJyRYCqY3kx2hHlSAtvawcT2UBtPO/M/obltw41Cb2J2a+bz SIRHdaJmF85yyj4yQyHMQgc2n8CjVCotSnpcpJATJto0Cy1FmqKx1m31j/xC1IA+YXoSCyfDGrbA UkO8g/EA1rIKceHJLXm6H58ABXG6p9JfdcBWmuc3NF3Udp7zshvxQrlvaO+XSUP+cwVyl2nLMtmI xq47l4jBv4ZfAAAA//8DAFBLAwQUAAYACAAAACEAmKC/1CgDAAAVCQAAFQAAAHBwdC9zbGlkZXMv c2xpZGU2LnhtbNRW224aMRB9r9R/GO1TIhUWSFRVKyAKJK0itQllwwcYe2Cteu2tbQj06zveCykJ adNGeegL6/XOHJ9zPB7TP9vkCtZonTR6EHXbnQhQcyOkXg6i2e3H1ocInGdaMGU0DqItuuhs+PZN v0icEkDZ2iVsEGXeF0kcO55hzlzbFKjp28LYnHl6tctYWHZHqLmKe53O+zhnUkd1vn1OvlksJMcL w1c5al+BWFTME3OXycI1aMVz0AqLjmDK7D1KQ1LGUyXC0xW3FjGM9PqTLdJiYsvP1+uJBSnIrwg0 y8mWKK4/1GHlq6YwGsQP0pcNEks2C5sP+ywhbbAZRGT+NvxSEktw44FXk/x+lmc3B2J5dnkgOm4W IAa7RYOqStFjOb1Gzq30CqG7U1WFMkr9bPg3B9qQziC/ksev1w1Y0Bzgiwz8tiBnfICq46qPpR9N vCNPS7P8ZmTENgif07OcZIlyPvVbhaUhRJslBE4/ZL9ioUJRt2ZpBEJaX3oELvdjhYxqubbRD1N0 obpbVxcwc9jizKGDo5P49LhPDnnaoBoWtZgwy6ZPoge1LCEeJKHhS8PK0KdtPWlsHRvtqehgohjH zCiBFnovM1kKKpFmH17NX/djEPVOO1Sfq0Hk9PIPjp+0u22obYcpcmNDP3ng9uGdvF/pt3uawDmk V5PdItIBUpuaK+kyFDBHf4eoYXbeOgdqXmEwgjvpM2Bl3qg3mtEX7okXMEezuRRC4dxs2jAyFLef ugOnSNsIAiqkUFkNcPP6a4Cl3gpH6TQ9hpULi/kMA4Pp5RgKa7zhRrXhNkxOU9CIwoE3JABIDIah QI82lxphYU1e5ufomWCeBYS1FEHw9gFhnzFfxwrJqIVbZDnptATsnOGSeUorHQmMHHUx4CbPV1ry sinuxB2N0+M27G1edQjKk0B96olTc2And+enTn1RCVyglWvSMMXvK2kxXAou2ef5VLs4QA3Q0i1E /fxAA5lefu3u6f8b3AN4716L5cl/wfL0Act/KaDHDbjsw9V1TcPmBufKfmHFzbqsNPpjQkdpXE4V dBZDOVLofUjAoJv/JwAAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZe RPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a 3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZD OtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQ SwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRl TGF5b3V0Ny54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj 7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz 3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39U KB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4SPwQrC MBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTr fK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo7 9qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualne B9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlv dXRzL19yZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQD lmTbBtskZKPo35tjBcHj7DBvdpr9axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL 5kIj5hLiwUUWheJZw5Bz3CnFZqAJWYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUd S/N/dug6Z+gQzGMin39UKB6dpTNyplSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAG AAgAAAAhABc87WrVAAAAvwEAACoAAABwcHQvbm90ZXNTbGlkZXMvX3JlbHMvbm90ZXNTbGlkZTEu eG1sLnJlbHOskMFqwzAMhu+DvYPRfXbSwhijTi9j0MMupX0AYyuJWSIbSxvr289QCgkUdtlJ/BL6 9KHd/mee1DcWjokstLoBheRTiDRYOJ/en15AsTgKbkqEFi7IsO8eH3ZHnJzUJR5jZlUpxBZGkfxq DPsRZ8c6ZaQ66VOZndRYBpOd/3QDmk3TPJuyZEC3YqpDsFAOYQPqdMn18t/s1PfR41vyXzOS3Dlh eIoBK9CVAcWC1tcOX8tWV1kw9z3a//SgJMgfjgXLymbRZ7MI7c3MrN7e/QIAAP//AwBQSwMEFAAG AAgAAAAhANXRkvG+AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0 OS54bWwucmVsc4SPwQrCMBBE74L/EPZu0noQkaZeRPDgRfQDlmTbBtskZKPo35tjBcHj7DBvdpr9 axrFkxK74DXUsgJB3gTrfK/hdj2utiA4o7c4Bk8a3sSwb5eL5kIj5hLiwUUWheJZw5Bz3CnFZqAJ WYZIvjhdSBPmIlOvIpo79qTWVbVRac6A9ospTlZDOtkaxPUdS/N/dug6Z+gQzGMin39UKB6dpTNy plSwmHrKGqSc33kualneB9U26mtu+wEAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0A AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTAueG1sLnJlbHOEj8EKwjAQRO+C /xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9 rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1 UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNupr bvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0cy9f cmVscy9zbGlkZUxheW91dDExLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG 2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPm EuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L8392 6Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAA ACEAMGEnJ/EHAABeNgAAIQAAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbOxb3XLb Nha+35l9Bw73cke1SFG/E7njOE43M07qqd3Za4iELK5BkAtC/ulOZ/IOfYO+Rbt3+yh5kv0OQFCU JTly6jRupRsLBA4PgQ/n58Mh/eLr20x411yVaS7HfvBV2/e4jPMklZdj//uL162B75WayYSJXPKx f8dL/+vDv/7lRTEqRfKWlZorDzpkOWJjf6Z1MTo4KOMZz1j5VV5wibFprjKmcakuDxLFbqA7Ewdh u907yFgq/ep+tc39+XSaxvxVHs8zLrVVorhgGvMvZ2lROm3FNtoKxUuoMXcvTekQ64vPRUK/k0v7 90wdvmCjMhdp8joVwlzQQvmxUN41E2N/chn4B4cvDu5J8emUx/q01DRG+kiTaZDisrhQnFNLXn+j ivOCRvH0d9dnyksTbIrvSZYBe9JtBioxcykhZvUu3X7pNLHR7VRlNFlA592OfezwHf3FTWzEb7UX 28540RvPvl0jG89O1khjsfYBWFD9UFqVXdGa5bTDnlvRd8CFyUvBvbBenL0DEBaneXxVejLHci0K +fEM0vxIqfxmxllSUrddPOByjyJE6OHFzNN3BXDTqRa8krODmKus5Usg7k1u3uYJZNlc5z4hcw+1 qNuHwRrown7U6wyW8RuE4bBH44RiEESdNi5oZgtFhSr1NzzPPGqMfYWlmwex68oy2MiJ0PNlTkZm NklI72bsD7th19zQGMlScj+RZmN/gCfaZ7IRYXMiE3OzZqmwbcxFSLPpy/ZI6ye89O3LPLkjgQl+ gQnCAiY6y9UPvnejGDah/PecKe574o0E9sMgirBkbS4MQL6nmiOT5oicZ8c5nATmzGQMrWM/1spd HGtcE355VjB9Ks+LmERpNoTKxe0/mSoq6DSs9l1+PmMFX4eglTXY24WQElHqc30nuMEEtgm1WKG4 xoQqVwAGbKSoEzY29rlsfX+O2JfpY8EZYmMlpg+PRRpfeTr3eJJqrwqBxsYQKfEI2nRtHg+VaONp sDeHLprWNx70kP6qh3TInoz7P72HEE4+gg0igXOoJ3CUAB5BTmMwd5FmyVMi2PSwZ1a295SxX/nQ Gk/Rfxo/ITswblKu8RPjLA3XNMYIr9zWNc95nMvEE/yaiy3Um6TzCPUXs1Rtr92Y9SO0v87nSs+2 nnxk/WprbF6n0we0PzpCgRdaVrLI4WZGnylCJfCA8gdkIyamVaQyu4d5P0Gk6oWIREivS5EqDDqd OqdH/V7Y3ad072Mp/XcPVCa5X4uA0jlnp/KlujIcg5giDhpncxmDxFgmkfDpdxAjOwqimqCBBNDd Jlc7mmAIAv3hMjljitFtTV4AQ/nEzD5c9Rtjd5/Jb6ZEsWjBxNxAFivfsSn3032nE4SR48PrnWcw 7O6d55F8+Is6DxOXYLmGkv8B/KiDs8L9/NP7jAwZxY5382ydK5ms9xvSUK/b7TzsSvs8hLP3H8+V EGs/gyNNRWKqQv/pDY5PXg2Hx61Xg/awFXWDoDU8eXnSiob9o1ftfhgO2uGPOJ2bEkiJohXHucJf x6QN60EGNL/68MP7X/724f2vC/6MR35aKjRnXVvdQtPV02Kh3rLCQ7Fs7AuNcoC+RSu5QmtyGVJf SH1oJVdosThGiQ4SVcP1YNz21DId19NxMpHriVxP1/V0XU/P9aAqNROpBH0wP743zcU/bIdr2QCD WHDK7vK5fpOgdEOH8kaP2ZwwiPrRoNOLkO3ViIp46k1iDjObZcEuF7JVOWyT3i6wqvVWhYGNssCn lq0o+kZZIFfLVrRkoywwrWWr0LtRFmjXsv0VFJcw62IfallTZnsAM9RJatnhR/TixFLLBobKP6B4 aeNcTaSxvGrj9a2pKpWmfkZlRnNJ3lKxSq+RVpU21SbYldRHJttOWGlLWGURv+RTug+ts1jberI7 byyNHk1hchvlqtEG00WNrm3c/qHKNdyN0AOnXZKiuro0IWTKYlRH/579qyU0SYIZs3sDnNmBuLw3 EJeVbjsrS7Qd6TZIhcTe/1RIHamUCZQzZ0yVHAcQt5XLENC6K2Pp7CgEtO4KgmhHIaB1VxB0dxQC WncFQY8gyJg6reqhSIs7GBkIhQqQ/gIQ88ZlNwEhFCpABgtAgk6f3jLspIkQDBUiwwYig3CAd4E7 iQjBAHaBl20NKoYX7ni7tcLLbITpROGQwEoljkdI0y3XYUMOMvijSRvO8tBYkakmrduKuE3meMet DG8Y+x/e/2wpVYPOmVoBbfsSUTNfXCw+RMCJys2g+bnCKp2Tm+icbG2gc7K1JZ2zAPcBMJ1saoDD QbdPHc8E4J9WAMa5eRu+/EiAwawfpn4WLvfpQAOvcNAIcM/QIMPtzhe/Fa/7PLHCC9iY4tnCvp4X Xmvsi8LDkzvwin3dJ5UWr7Dd7dN+PVP7+t9/V93x94FrPQENu0FkvO95mteXg2s9PQ2H/cBwjz1c y8F+PXm1XGPvjCuxaz2z7QwGvWcc67+cM9a0t0F0i1GuZ1zVtBf2eGaPCxWXXH2bvRBxtUubM5pk DTIXbHKO98nuKOr4cfNVh+GZ1at43P2xV/EmZFxxRR8g0wY/eXJcKVY+Fbt1X4XWZHZn8blfybSm 44xkj88G+rpcvgC731kDWs9Xg+Vqxi4DtIGhmuPOPkQjZW3gpP3Ifl6xj0EbWChSrjkS7gHawDt7 3f5yCWZng3TNNJvkkuqt9Wtw+uTD/V/Y4f8BAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDgueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk 2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZC I+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvz f3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAI AAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEu eG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/Wsa xZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmG SL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZU sJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQCJQBTOfQQAAHcRAAAhAAAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1s1Jhdkto4EMfftyp3UHmfCRh/4hpIZZjM vkwmVCAHELYYuyJ/RBYEktqqXGv3ODnJdssS4AmTEIfdqn0BY1o/qVvdf7V99WKbc7Jhos7KYmzZ zwcWYUVcJlnxMLbeLW57oUVqSYuE8rJgY2vHauvF5NlvV1VU8+SO7sq1JMAo6oiOrVTKKur36zhl Oa2flxUr4L9VKXIq4ad46CeCfgR2zvvDwcDv5zQrLD1enDO+XK2ymN2U8TpnhWwggnEqYf11mlW1 oVXn0CrBasCo0e0lyV0F3lZZvNhaRJmJDdywrQl4Hs95Qgqaw41ZFsu1YORjJlMypRWuQ9nU1UIw htbF5g9RzauZUEPvNzNBsgRRGmH19R/aTP0swAwu+o+GPxgSjbYrkU+uaAQRIduxBRu3w08YRCO2 lSRubsaHu3H65oRtnL46Yd03E8AK9pPCnleNR9+6MzTuLDLJGbH3XjWmFIbelfH7mhQl+InuN+7F 9xsDQ58RX6WkCb9ElLZr/lTxMPa1iqlZ6D4SdjAaDkPIW/DcDSHLBo+i4rmh78JNgrHxfD9wQjWJ IcEkDbqK5Pa6THYY0iV8w87RIk5LyNQljqARr+Vc7jjsM1xvuA0rIpQ/QClxyAIaJWz1Fm7Vn8YW 5DtMuTSe7+1hk9scCDGNIBDwAUM5xUpkRe/dHCoxl1POKOC1S3Iy5Vn8nsiSsCST5DWtJRNEBQ7q FlaGdKnmUEhWJDMqKC7qmIx7QSOYGXw3Pqsw4H48vemO2XRTBjNOY5aWPIFFDDFEUCxmgzulAFSg BeUCuWwSplsi+PYwCLxm00x1tPLAtW1MlnMT4cndz6m4U9WYFQlIC17iVi7X96CfatRRTjiQFHpG nT1oC5dDTKQG5XoBWpFzeMODBxqiec6BN7Jdlfxn8dCyyQ3gIUTz3APPdgIbS+y8BWIR7IFI0UDv CBhC9XYDIkUD/QMQ1AAW2GmFSNHA4AgYuGrnOriMFA0MD0Cknb8prRgiRQNHR0DfCzpuClJOa9Jl tcM12rHAejwWDgcz5FeFA/UaBBOEN6V8pTVESZI6Q5SPeLjOlbtG8c0RcPIw8Rw4Kpqz4nDEtkQk HMDR0kxiSN85TJQanDpBfkpD7FaN4gmk06GjhtgtTUKI5nXUELuVrhfQkNGFJaTFu4CCtHgXEJAW 7wL60eJdQD5avKfVAxKJwCGyb11UWnXvcFA0VINTtzqcLl2MZ5TohkrWUiL3EkqUyG90yG4OQdSf k0Kk9M/0Yab3fEousDybngIssJds+tD/QsN9E7nbssS+81jFVbP1qyq+kqIJ3oc1FTCD6QV/0Az+ X+IXmPjNeZYwcr/Ol4+i6F8iA+FJHdAnA/mDE/HfC+QKHqHxMfjztevbt/6N13Om4bDnei+d3rUX BD33VeiEo5fubei5f1r6ibDGOBXgCyb9Y/FQBQIyo77l5OuXv37/+uXvgzzAlDjs59sYdYY3j/Nw iU//qj/h4jWt3myUkMHrDkjPqbpVwQsOWAOaHkyQYV6YTP4BAAD//wMAUEsDBBQABgAIAAAAIQCi Baa5uQQAAAgSAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDgueG1s1Fhbcts2FP3v TPeAYb8VCXxINMdyxpbt/iSOp1IWAJGQyQZ8FIQUqZ3OZFvtcrKS3gsQMiUrEWW7M+2PTJMHB/d5 Lsjzt+tckBWXdVYWY4e+GTiEF3GZZMXD2Pk4u+2FDqkVKxImyoKPnQ2vnbcXP/5wXkW1SN6xTblU BDiKOmJjJ1Wqivr9Ok55zuo3ZcULeLYoZc4U/Csf+olkn4E7F313MBj2c5YVTrNedllfLhZZzK/L eJnzQhkSyQVTYH+dZlVt2aoubJXkNdDo1bsmqU0F3pbzX2drh2iYXMEN6lyA5/FUJKRgOdyYlIUC BvI5UymZsArt0Ji6mknOEV2sfpbVtLqXeund6l6SLEGqhsLpNw8amP63ABhc9PeWP1gmFq0XMr84 ZxFEhKzHDiRug7+wiEV8rUhsbsaPd+P0wwFsnN4cQPftBmDBdlPIeWU8euqOa92ZZUpwQrdeGSiD pe/K+FNNihL8RPeNe/HdypKhz0hfpcSEXyFVgzMPdTwsvtYxtYZuI+EHI6gtHQ535A2CvZh4g0Ho Uc8hGBlKh26DaHtsmKtIra/KZIMRncNfSBwr4rSEQp2bOItaTdVGQJpZJFaCgkGEiQfoJAFFwKKE L36BW/XvYwdMApvm1vEtHnIM1y0eiDCLIA7wA0sFw0bkRe/jFBoxVxPBGdA3PqmLicjiT0SVhCeZ Iu9ZrbgkOm7QtmAZsiu9h6bkRXLPJEOj2syYChbBzhBf6zNcmmx/O+cQxN0uuBcs5mkpEjDCfVkF ZAnUry2S7sn3glGACcVmOJT9gFIKCJP9IAw8CqVg3DcNpd02dWgjYbOvW6udqible5n2sPoMZQsA l25Tr+2qCNtYCwCsdwDrt7EWAFj/ABarbWuDBQA2OIa1AMAOj2EtALCjY1gLAGx4DGsBgD07hjWA Qz0EKwkwbJvlhT2Fmqpbqt7pKdM3unngx26pC/eENp7yuCwSIviKiw70urdOoJ+lmezOrhviBPbb cilh+nU13sfCPIU+WxxkhzH3qmrmWzWbYarbUqYDAmPfjqpnDTOcICDhMApSJhYOnAFA4HQi9VBD ydEXU13xKL5463vTjfpeQE2fP478nfHmD8/oYPhigSM5k+/0ESMrEjjt4CWaNl/ewaFQZ7OlaXRH p3AmIhY6EeWtobIzuhPfjp7uaWTDd0Z93JV04tvRxj0dbfioN6LDroRn39Fayxe6IUp9JwN3+Pb0 uOFz3RDMew7fnmZbvpGvx9bp9u3pesOHZJ0TsuPvnvZbvmEwel4+/hvzATrbnib0AQOPud8+VwVW ia6Z4jtKpLXzpUqUqCc6RM1pAd82DgoR9PijB93PQ9sTiFGBQ1P6dTV8aCN3W5Z4Em6reIBz56Wx WyhpgvfbkknYodFxeuSk+n+J38jGbyqyhJO7ZT7fi+LwNaIInw6A+mAgj0zEfy+QC3inx/fyP279 SXgDL4694PJm0vOH3nXv8jakvSvPdb3Ly7PgahT+6TSvqDXGqQBf9JHm6WuVPhOC0fgW9vXLXz99 /fL34/kOtsQnp7eA1hDzfQEu8XOErmwh37Pqw0rPW/j+AuU50bcq+OICNiD0EYIc9gvOxT8AAAD/ /wMAUEsDBBQABgAIAAAAIQD1jtSadwIAAK0GAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDcueG1s1JXhTtswEMe/T9o7WN7nEJJU7YjaokFhX1ipVniAa+KQCMf2bDdrhybxWtvj8CQ7 Owkw6CQ0oUn70jqXu7P/P99dxoebmpOGaVNJMaHR3j4lTGQyr8TVhF5enAbvKTEWRA5cCjahW2bo 4fTtm7FKDc/PYCvXlmAOYVKY0NJalYahyUpWg9mTigl8V0hdg8VHfRXmGr5i7pqH8f7+MKyhErSL 1y+Jl0VRZWwms3XNhG2TaMbB4vlNWSnTZ1MvyaY0M5jGR/9+JLtVqHbFQVxT4t10g4aITlF5tuQ5 EVCj4ch7OKNRF5oxtxLNR62WaqG977xZaFLlLraLoWH3onPzjwLdcBE+Cb/qM0G6KXQ9HUOKCMhm QvGmtu4XgyBlG0uy1pg9WLPyfIdvVp7s8A77DfAE95s6Va2i53LiXs4MLCMLDhkrJc+ZJtG9wDYK MMuZzK4NERIlOxKt0mze9HmdfLeTKkmLPrdYeN/wEoEXFPmhuMiL9YScs1/08QZxe452cyTzrWOy wn9vhJQbu7RbjreD64ZH/m4gzVnxuaX+yIwgHrujfsQr8gVoQGeC942dwURwufQqIEUPPEq/Ly5b Zn8ml/TkTqW0yOsxu/g12BVWt/C+rEHjDj2/nnsL+7/lN+j5LXmVMzJf16snFJPXoIjzDVPvBOlv yfP7x4VY4OBxs+TmwzAaxYODYZDMRqNgMDuNg6N4cBJEySwZxsfJwShOvtOul4zjJFCLq2X9vIix hrtGsdO72x/v7m5/jrENLBY2pLjl37WA74R2JuLSzUw/9rj+BOq8wQaGFD8SWJ7H3qTws9CNhQcX l6P/zEx/AQAA//8DAFBLAwQUAAYACAAAACEA1GG4Rr0CAAD/BwAAIQAAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQ2LnhtbMyVS27bMBCG9wV6B4JdO7JsJ3EF20Ge3eRh1MkBJhIVCaFIlqRV q0WBXKs9Tk7SISUmaeoCaWCg3dgSNfOT/8fhcLK3qjipmTalFFMab/UpYSKVWSlupvTq8qQ3psRY EBlwKdiUNszQvdnbNxOVGJ6dQiOXlqCGMAlMaWGtSqLIpAWrwGxJxQR+y6WuwOKrvokyDZ9Ru+LR oN/fiSooBe3y9UvyZZ6XKTuS6bJiwrYimnGwuH5TlMoENfUSNaWZQRmf/euSbKPQrS0tZxeCN5T4 UF3jYExn6D5d8IwIqHDg0kURH+a+GHWpGXNPov6g1ULNtU84r+ealJkT6BJp1H3owvyrwDB8iJ6l 3wQlSFa5rmYTSJAFWU0pblnjfjEJErayJG0H08fRtLhYE5sWx2uiozABruBhUueqdfS7nUGw03KI H1y1oYCppzK9NURI9Onst/bS8zqIOc9OXhXkCfgurv3oeYR4g0w9LLs6kFnjjF/jvx+EhBu7sA1n HgguGxIUxx/Ez8HVNRO9qwXWdWUPOQOs+w6enR3yMr0lVhKWlZacgbFME18FeApQcoJ0LG5OJ8lE NgcNH58pO3+Q4My46LBCfGwR/hnkMIA8AsvInEPKCskzXMFgE0wzi5a/4LEAnlMsRKyS2Bv3aN0G vIKxA8trHvsihyRjOcJo/T8MI4uwJS7c78hmyY0CuRMp3Y49ZTfcBLvc6hbepyVonCHwC7X86hr9 P/htB34LXmaMnC+r62cUR5ugiDcGSq8F6Sv8XxRijm3cNeWv/eEwHu/v7/aG49GwN9odxL1xf/ug t7M7Hu3E4/ejo+P+N9r1J+M4CfSyrrG0fadrRnZ2f/f93f3dj8fWgVO6tL8/Ar6HtJcLProbyN8f XJ+Buqh9k8NrF8vz0A8pvGjdUcTQxxCnES7u2U8AAAD//wMAUEsDBBQABgAIAAAAIQAdcvXCOgUA AH0bAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDUueG1s7FndcuI2FL7vTN/B415n wcZgwwR2dpPQm2ySKewDCFvE7tqWawsC7XRmX6t9nH2SnnNkgfnxrkPSme2UGxDm0+dzjnQ+HUmX b1dJbCx5XkQiHZrWm7Zp8NQXQZQ+Ds2P0/GFZxqFZGnAYpHyobnmhfl29OMPl9mgiINbthYLaQBH WgzY0AylzAatVuGHPGHFG5HxFP6bizxhEn7mj60gZ0/AncQtu93utRIWpWbZP2/SX8znkc+vhb9I eCoVSc5jJsH+IoyyQrNlTdiynBdAQ713TZLrDLyVT2K6mj6J+9mvpkHgfAmPLXME/vuTODBSlsCD K5FkLI8KkdI/RTbNOUdMuvw5zybZQ04d7pYPuREFSFB2NFvlHyWMfqYAg0Zrr/ujZmKD1TxPRpds ANEwVkMTBm2Nn9CJDfhKGr566G+f+uH9Eawf3hxBt/QLwILNS2G8M+XRoTu2dmcayZgb1sYrBWXQ 9Vb4nwojFeAnuq/c8++Wmgx9RvosNMrQI1WJU39SPDS+gJhSsOTqvQjW6PgMvukhG8SFnMh1DEMA 7WVs0QCwQcDnv6jQVh6Dt1U4OMkGYAp8wGDFDPOApxcfJ5AHibyKOYM8KUMtR1dx5H8ypDB4EEnj Ayskzw1JUSjQgEtglzCUJSVPgweWMzBihxmjwQbwZnBR+wNNFfD6sHc2Yccxf4iZz0MRB2CB/Roj gPE0YbrCXNIDVjMQGK29Kel0XUhwmpdWt9O1rA6atJ2dTttpWx6IC87RXqfv9shmCIMiIvfVlNAR 0SNssNQPBajFTFFWR68cbCNh+S3lRZQGkODYxLfPFnegYmSImgtG8fvQtB20dKbdrMwNatowe0pC 7VUj1vYhK1KhHWBmZ8vatxyyoAmr5R2yIlXJ6mxZrY5r9RDciJaQuyFArpK2W6H1bI9sOJUWuUra 3pbWtj0w4QXWIldJ61ZoXadD8/BUa5GrpPW2tMjZfMiOxBa5Stp+hbbXdV80ZMhFWlLNCVI0fAnM uo100dtPVzgUHBK4YkfhTlExR6vYlUgl5OqOkJFqwFKrF4pnLiWY3SGL56WMKYnBZZXChI3qeoID Ui9jtuU6ntv9iox1+l0LkgMRTXSMZKg6UAcr1VadFGUFAE0tJlUlwxTaYDUAsFoiKlhSkg1WAwCr 876KxVm5wWoAYHUy12I1ALA6Q2uxGgBYnXa1WA0ArM6lWqwGAFYliK4EKL4kkhvfvo8MomIAPnTS 0vr7jLJkwn2RBkbMlzw+kqD79JQXz6CfhlHenL1c+Rsrzlgschk2Nt5RGdmcPpofZYfa5FWrs67W tel+dUYWny5qqj5W1RkK3G8LlkPZWWocRZtK5cYa13O6bRvMhUqsrlazXFC+c602NM+1GtTL51pt aHb+j7VaT2vasVqNSqPTZe1QykgnT5ayunptK2Xneg1jvlv/nOu1mjOdr+549guqc72GR2hqN7gf m++1XnO1tl0zyXc2oT2sME8XNlWvBRIOEHe3o5baU9XuR+mt+6df8HD3wBJ2Nc8+33zdShdO8dQx +FgIPP+snkS6rxG7uYTq9nB9sL5xLPlfiV9fx28SRwE37hbJbC+KdKbw0hkI9zVAfTSQ3zgY+fcC OYcrFLwQ+aPvXb/z3o/fXYw7Y+fCse3uRb8PLevmpnM9vvY898b70yzvBgqMUwq+YC7sH2JRgsDO mb7l6Mvnv3768vnv7S4YXondnp8CdCStLnagibc/pApx/oFl90vaf8KlFyTAFT3K4JoLbEDoFoIc +tps9A8AAAD//wMAUEsDBBQABgAIAAAAIQBGA6Gk4QMAAK4RAAAhAAAAcHB0L3NsaWRlTGF5b3V0 cy9zbGlkZUxheW91dDQueG1s7FjBctowEL13pv+gcc8UDMYhnkAmgdJLm2QK+QDFlmM3suRKgkA7 nelvtZ+TL+lKshJCnAJNeuhMLiDLT0/ap93VygeHi4KiOREy56zv+W9bHiIs5knOLvve+XTc6HlI KswSTDkjfW9JpHc4eP3qoIwkTT7gJZ8pBBxMRrjvZUqVUbMp44wUWL7lJWHwLuWiwAoexWUzEfga uAvabLdaYbPAOfOq8WKb8TxN85iMeDwrCFOWRBCKFaxfZnkpHVu5DVspiAQaM/r+ktSyBGvVNT+9 +OwhgxNz6PG9AZgeT2iCGC6gY3rN0ZAzBTTmlSynghANYvP3opyUZ8KMOJmfCZQnmqEa6TWrFxXM PDKAQaO5NvzSMeFokYpicIAjUAIt+h5s2FL/wiAckYVCse2M73rj7LQGG2fvatBNNwGs4HZS2OvS WvTQnLYzZ5orSpB/a5WFYhj6gcdXEjEOdmrzrXnxydyRaZs1fZmhSnZNVeHsS6OHw0vQ1IilFsc8 WWrDL+DfdOKISjVRS0qMILBsHAE5/ID8FGuvJqxxPgGvLtSQEgxeX4mnBkOax1dIcUSSXKGPWCoi kDJ2SU15AOoo2JyKkrDkDAv8aY1Z24cjmBkW7VYITSvh40J2nJCVN6EzimOScZrAItpPk1V+hWjA NPXAA8E93B48oq2Wa83Lgu4exKtxNT9stXTb6OscLmh1etDvIe12Qbfd3Q87ZgMdkxHAbrPTpHbX 9Nx0Tn0TNjhKSKrl1etv9+ykoO0KAJrtGmywinUAwHZqsK1VrAMANniI9e+twQEA292EdQDAhpuw DgDYvU1YBwBsbxPWAQC7vwlrAVrrKpz0xphogpEIGG7D5onRpT3IBJe8F102gtanNI67Q0BPSMxZ giiZE7oFvYmyHeinWS62ZzcBsQP7mM+EyrZefGAjcuvtGOdpLTucIs+a14I/5TWjCZyn7jDY8bhY y2tm/8xRoTONaayeGXV5LQx6L4kNToSXxBa9JLbbQuglsW1RsHVdYhthRe5VayYV/31Ws0VwoqBG XavbzAY9nuA2F8W15ZUtWOFMt1VX3aH/vEdC6JQbc65L7NVKt/u0StdqlyphxfsywwJmcHXvhsL3 f9Fvz+k3oXlC0MmsuFhTMXwOFeGCD9S1Qm44af+dkClcvPUt+tvxftgehd1xIxj3Ro2g9W7UOAqG fuOofeQHQdeHS0rnu1ddKKXWiYEt2v/Xb4KwWKgzq9ujGtz8+Pnm5sevu3IRptSI3UPA5BD7NQCa +puBufBT8RGXp3NTqMFXEnDPoekq4buIDkWA3kE0h/vOMvgNAAD//wMAUEsDBBQABgAIAAAAIQAz htSpFQQAAEgNAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1s1JfdbuJGFMfv K/UdRu41i22MDVZg1bBJe5HNRiX7AIM9BGvHHx0PNLSqtK/VPs4+Sf9nxsNHSlVKqkq9AWOf+Z05 //Mx5urtcynZRqi2qKuJF7zxPSaqrM6L6mnifXy87Y081mpe5VzWlZh4W9F6b6dff3XVpK3M7/i2 XmsGRtWmfOKttG7Sfr/NVqLk7Zu6ERWeLWtVco2f6qmfK/4T2KXsh74f90teVF63Xp2zvl4ui0y8 q7N1KSptIUpIrrH/dlU0raM159AaJVpgzOrjLeltg2hbkX0veO4xY6g2uBV4U8SezWXOKl7ixlxk 5JyRoVDmads8KiHIrtp8p5p586DMovvNg2JFTpBusdfvHnRm5mcFM1z0Xyx/ciSePi9VOb3iKdRg zxMPSdvSJxbxVDxrltmb2f5utvpwwjZb3Zyw7jsH2MHOKfLd2Ij+HE7ownkstBQs2EVlTTmW3tXZ p5ZVNeKk8G142f3GwShmwjcrZqXXhOrs7EOjh7NvjaZuozslkjAcBAMjRxT58dh/IUqSJGGEm4yk CQZx6CdD48SR4MSim1Q/X9f5liRd4BuZ41W2qlGlmlbwVLZ6rrcSecb1RgbYEePyCW0kUQU8zcXy B9xqf554cAmfC5P4jEMBLmXntluJdB8TITZPIQk+AJGc+lFUvY9z9GOpZ1JwOOqi09OZLLJPTNdM 5IVm73mrhWJGQnQv9kh0bXwYpKjyB644be+QTFnhKTxDBRe9EYQy89fph962FR6p9h4kz8SqlmgG FlKQ6BaX54sqgdT30DaoaVc4FxVEOPbjBMVhkue65Lgghr4fjJIuM7bJzimIhWWeKoiSqzvToEWV Y9LQJeV0sb7HODU7OSgTjESTUSoFW1Bki8uQasuiomECM+hxBi8YHfII0vEGe944QKOcy4sPeQTp eNGeFwySgMzO2yC5tlWHKInSAYcHwFE4ojguABKlA8Z7YBiOsMGLgETpgMkBMIkG5+fkKGSidMDR Hki085NyBCRKBxwfAONhcmFSiHJ6OBEeWdtNIeP38mFFHWlmVXs0rC4ZSJEbSO+4FkcDyXT/awdS rjGDMdVXXC7dYLJlTCe2kYsu5kY5e56YMehGqjtQTPufGBqUPzsVdq1Bh8vpLPy7o3zolLutazpC Dod5RJ36Wu2WWlnxflxzBQ9Ov7+Z7P8X/WKn31wWuWD363LxQkXzuvFaFfHqDfRJIc2Ri0PrPy/E Jd6I6d32l2Q8Gkez2U3vephc96IkHvbGN/63vTD2b0fXN+MkmkW/et1rXks6VYiFiv7l8DANgso3 33r65fNv33z5/Pt+PMAlLfvnLWAOdfuOjkt6mTeVLdV73nzYmEGG/y8oz5m51eAfC/ZApnsTYrh/ QNM/AAAA//8DAFBLAwQUAAYACAAAACEA8v4Imy4DAADcCgAAIQAAAHBwdC9zbGlkZUxheW91dHMv c2xpZGVMYXlvdXQyLnhtbMyW307bMBTG7yftHazsurShhUHUFkELuxlQreUBTOKQDMfObDdrN03i tbbH4Un22Ylh/JnUUqTtJm2c488+Px9/dv9gUXBSMaVzKQZBuNUJCBOxTHJxNQguZietvYBoQ0VC uRRsECyZDg6Gb9/0y0jz5CNdyrkh0BA6ooMgM6aM2m0dZ6ygekuWTOBbKlVBDV7VVTtR9Cu0C97e 7nR22wXNRdD0V6v0l2max2ws43nBhKlFFOPUYP46y0vt1cpV1ErFNGRc74dTMssS2crLzwFxQarC axgMkXc85QkRtEDDLDecEdAhIykMlFyALmeKMRsqqg+qnJYT5fqdVRNF8sTqNP2DdvOhCXOvAmH4 037U/cor0WiRqmLYpxFgkMUgwJot7ROdaMQWhsR1Y3zfGmfnz8TG2fEz0W0/AGZwNyiWu6wzeprO tk+nxhHeZVWHUnT9KONrTYREnjb9Or34rPJiNmcrX2akJm8s2Sau/uh4+HgNpg6WWRzJZGkTv8Sv a6QR12Zqlpw5IJg2jSCOB/BzagubidbFFIVdmBFnFIXfwDPDEc/ja2IkYUluyCnVhiniJoNtAMk+ 6BgsTiPJRDKhin56pGzzoxFGxqT9DPG3Rvh3kF0PsqkmMuE0ZpnkCSaxvRnWPEFRePKvQBQLQHjF 79BtSNiWrQOsHxCuKTqUePghXRprLOqUxRJ7lLOK8RXkHek15GdZrlZX79p1XEP9RM6VyVaefG9d +Tx9Vh1O8qq13fO1PaaGPShsBwS26t3gRX6RGGznb/B8ytMAJmuL3W1qZxvWXF7gH3adUOOhM3Aa JSzFRq/39l0zKtTbjQ13bvO65HY8uRMprRv9aQputTdllxpVw/sypwojeH4bu8X/wW/X85vyPGHk bF5cPqK4s5m11icWrkOQfhakM5R/UYgpbir2wvH96HB8vNfrhq3D952jVm9/P2wdjXb3W91w3D3p heOwMx79CJqzV1tOArk4n3p6tDkndiZmhrc3P9/d3vy6d1UMabutvwXc+VhfnPDXXrLc3YirU1qe V+54wZ0S5TlyTSVukXYrIvQ+xGr4W+nwNwAAAP//AwBQSwMEFAAGAAgAAAAhAKoaF57NAwAA9AwA ACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzUl9uO2zYQhu8L9B0I9dqxztIK aweJnfRms1nEmwfgSvRaCHUoSbt2iwJ5rfZx8iSd4WHl3TjIVjAC9MaWpeFH8v85o/Hly33DyY4J WXftzAte+B5hbdlVdXs/8z7evp3kHpGKthXlXctm3oFJ7+X8558u+0Ly6ooeuq0iwGhlQWfeRqm+ mE5luWENlS+6nrXwbN2Jhir4Ke6nlaC/A7vh09D302lD69az48VzxnfrdV2yZVduG9YqAxGMUwXr l5u6l47WP4fWCyYBo0c/XpI69LBbVSvOPKLDxA5uBN4cdl6ueEVa2sCNW4wgK15XTD+S/a1gDIPa 3a+iX/U3Qo+43t0IUldIsCO9qX1gw/TPFsLgYvpk+L0j0WK/Fs38khYgBNnPPPDrgJ8wiBZsr0hp bpbD3XLz/kRsuXlzInrqJoAVPEwKVvdmR19vJ3TbMUIED7syoRSGXnXlJ0naDvaJ2zfbK693DoZ7 Rny/IUb1UglNs6HmuZbEDZFaVrfWBzHSPMl9o0gYRH4cJo91ybIsjDEA1QnizPdNxPGuDbov1P51 Vx1Q1Tv41q7Qgku1UgfOtNqgCS1g5fAB3nKKGcPayccVZEyjFpxRyCjrjJoveF1+IqojrKoVeUel YoIofXokIi9hEQqct0jWVjdU0A9PyCgeLWBmkMOtEC6NP992KXIurbZ3Zs7wHEbJ7Z0xCk42HDvn 7fMNC6IsSK1jUZ6nUBMeO5aCXdpS7ViWhBhtRDCJoDdvzo/T46RjaBPf8QAODmmouNKZU7cVZL++ pPwe3IKTB1kMgO01VDvtcsXWYIKZ0gIsKxxYcZLh0skIIFIsMBqAF0GsD+oIIFIsMB6AD0qPICLG EpMjYh7m2poRRMRYYjoQwzAHe8fJiBhLzI6IWRyNNQYxlpgPRMSNdQYxlnhxREyTTOfACB0RoyuC K0yIP0NdgsT+UaUpdqVpSRUjN5yWbNPxCopjdI4SVSmoxn9AL0D5GvJTlylTQfAVq9XDi5UWEgup zvWhuH6vmKDgJ0sElOmvTDlvUU+ccm+7Dl8mx9rF59BuDdVQi/fblgqYwen3nToPtfJ/oV/q9NPd G7neNndPVNTtA7R7rlcZ1c1Amwzok0Lql7BubH7wQVxD/4rN6J9BusiS2M8nib9cTuJ4kU0uglev JtmbZZz7yygKXl/85dm+TGKX28Je8NA/7Xn0y9JkDzYyXz7//cuXz/8MXQ1MicP+ewroN7xpquES W2/dN3Pxjvbvd7qgwn8NOJ4LfauHfxf4tobQIQQZ7t/K/F8AAAD//wMAUEsDBBQABgAIAAAAIQDV 0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJl bHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A1 1LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT 5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqk nN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQA0uyvrSAMAABMLAAAiAAAAcHB0L3Ns aWRlTGF5b3V0cy9zbGlkZUxheW91dDEwLnhtbMxWXW/aMBR9n7T/YGXPNIVCyyKgamm7l36gQffu Jk4T1Ykz22SwaVL/1vZz+kt2bON2MCZBW2l7CcG59/jec+89du9wVnBSM6lyUfaD5s5uQFgZiyQv b/vB9eSs0Q2I0rRMKBcl6wdzpoLDwds3vSpSPDmnczHVBBilimg/yLSuojBUccYKqnZExUp8S4Us qMZfeRsmkn4BdsHD1u7ufljQvAwW/nITf5GmecxORDwtWKkdiGScasSvsrxSHq3aBK2STAHGei+H pOcVsgUxejILiLWTNVaawQCpx2OekJIWWJjkmjMCgsgnGOcx5WTCZtqaqWoiGTMOZf1BVuNqJK33 ZT2SJE8M2gIlCBcfFmb2bwkzvIQr7rceiUazVBaDHo3ACpn1AxRvbp5wohGCILFbjJ9W4+xqjW2c na6xDv0GiOBxU9S9chn9mU7Lp+NIaT5m5UwpXM9FfKdIKZCnSd+lF1/WHszkbOCrjLgSaMPvws59 tHx4ewVOLVl6diySuUn8Br92kUZc6bGec2YJQdg0AjgeoJ9T0+GsbFyP0eGFHnJGMQEL8vRgyPP4 jmhBWJJrckGVZpLYYDAPgOyBHY3iLCBZmYyopB9XkE1+NMLOCNpHiFdH4d+J3PNELvUUGXEas0zw BKG0XoNcQ1VAhMwxBK7bA/QlmsZXZhvGjYwAhVETtIluHf8oF+E1fyT6hfUwTW7LoZbq4Ti3xOPh t7RJbdECYxYLzDVnNeMbwNuKbAE/yXK5OfqeY3Rjvs7EVOps4+Db28Ln6Vp06M6rTkLbT8IJ1Wxp ACwhkGKvHc9Sl0Rj+L/iqKA89a1vJcCKjJGiZ6iN7fyaN63c0yhhKWTBKQFa3y2jQ704GXOrTa/L XMczdyaE0a7fxcNW+6XcpVo68j5PqcQOnr/naMeSWvwf/O17/sY8Txi5nBY3Kyx2zMy8lEXcogC9 lkgrKP+iEVPcbsz15Ft7b/+o0zx932gfHePRPug2ugd4tFunnc5w2GkeHHe/B4uTWhmeSuRi6rd6 xNoCu7PanJsP9z/ePdz/fFJVbGncth8Be5q6axZezcXM1oTLC1pd1VYucRVFew7tUoXLpxlFmD6Z GAx/mR38AgAA//8DAFBLAwQUAAYACAAAACEAVLKurZADAADzCwAAIgAAAHBwdC9zbGlkZUxheW91 dHMvc2xpZGVMYXlvdXQxMS54bWzUVtuO2zYQfS/QfyDUZ8f3m7B2kHjjviSbRe30nZGolRCKVEna tVsEyG8ln5MvyeFI9O46LurNJij6IsvSzCHnnJkjXjzdlZJthbGFVrOo+6QTMaESnRbqZha9WS9b k4hZx1XKpVZiFu2FjZ7Of/7pooqtTF/yvd44BgxlYz6LcuequN22SS5Kbp/oSii8y7QpucNfc9NO Df8T2KVs9zqdUbvkhYqafHNOvs6yIhGXOtmUQrkaxAjJHfZv86KyAa06B60ywgKGsu9vye0rVAti 3LpwUjxT6XoXMYo3W7zpRnNQkKxkyhQv8eB3hBYJl4ziGRhja7FzFGartRHCJ6jtr6ZaVdeGsq+2 14YVqUdrUKJ286IJo78KYbhpH6XfBCQe7zJTzi94DHbYbhZBxL2/IonH2ARL6ofJ7dMkf30iNslf nIhuhwWwg8Oi0L+qK/q6nF4o54iU7qG8OocD46VO3lmmNAr2PNR1JlfbgOqL9+tUOas1cV6PiGlT QLlaoiarDiWaQrYlqsP+DwSNRr3poFPT1BsPRv3Jfa56neGY3nvGhpNhd9gb0iIBCYvU0FXsds91 uvdMv8UvBPVNM4sE98XXsNK6ldtLQXqANR6jJFwQLLkfNKFab1YYtNItpOAYxEY7N1/IInnHnGYi LRx7xa0ThhEFGEtAXkAch95oIIVKr7nhvx0he1Z5jJWx77BfKsEz+8869r/W0XfTteSJyLVMsZWe rxCDEAT7Jkk9cUeKYizQs6Efzld2MBzDWKj/Twk76nSnE//+RwmLfmNyKw8KPlJoTzfpbO8JXYtJ iuISliS2HtBbK5Fo2JQUWyHPgCepHwC/zgtzPnq/HpWz+VrqjXH52ZsfPBS+yE6iw0+/64gNwohd cifuTRYR8tjJSh1c5S98CrnMomamyFvIJb2z0s1du6R5DiYRTI2cK9iY9y70eLfx1lRk8JvaYg6P 0aF3w8n0vi9zw8DcUmtvinddidR+LHeZMzV5f2y4wQqBv38xpf8Lf6PA30oWqWBXm/LtEYv0yXss izglAvokkWQo/0UjZji1+WPX36PlsD9eTBatwfPutDUYd0etZ8vpZavTmUwGL/rj3mK6fB81Bw/r eVKo5dS3mwYEA0G/bv75w8dfPn/4dOuqWNKnPXwE6DNdHx9x6w+c9L2V5hWvXm/JLnHURnsu6FGF w7UfRYTehniMcFiffwEAAP//AwBQSwMEFAAGAAgAAAAhAILqtPRcAgAA2AUAAB8AAABwcHQvbm90 ZXNTbGlkZXMvbm90ZXNTbGlkZTEueG1spFRdb9owFH2ftP8Q+T0NDR9lEaEifEyTNoqA/gDPMSSa Y3u2odBp/33XdkK30XZUe0ls55577znnxoPbQ8WCPVW6FDxF11ctFFBORF7ybYru17OwjwJtMM8x E5ym6Eg1uh2+fzeQCReG6gDwXCc4RYUxMokiTQpaYX0lJOXwbSNUhQ1s1TbKFX6AvBWL4larF1W4 5KjGq0vwYrMpCZ0IsqsoNz6Jogwb6F0XpdRNNnlJNqmohjQO/UdLQ+BGViy3by3XilK74vuPSq7k QrnP8/1CBWUOiqGA4wqEQVH9oQ5zWw5hsIj+gm+bTDg5bFQ1HOAEuAWHFIH8R/sEEE7owQTEH5Kn U1LcPRNLiukz0VFTADo4FbWsPKNzOjcNnSUl4PqW0eDmxMyHY4B/FuSbDrgArl4CMS4gmo6UEg8F xbm2x545me+bOlYOW1kWgTlKEE2zfL6rYMIeU/R9h5WhCoGswLlboz3ECdhk0c4EnDDuC/i9TMwh E/nRCvcV3k54CNJmZY6MOkGBNk42LHfO/ci6s/jDddwP++14EnZmWSvMpt1uOO6MJ51RFmfTUe8n OnVa5pRDrzaFAvMZ8E0R5eH9yrsFXbkiZtgegO4GbHfFnJM8X2CFl+c4iIGugF/TPSy9PS+bdN1t 9+Jzo2LbB4xuo/fvRi2FecUocHINwzbNSxflZT3lscN77tunavtWiy6k1j6n1n6F2v/OoB2Weuia kX1h6Jy8jU//mDL6ZsedOv62gWVzARGmvmB5t4f/Bidwr8IfMnZHEm7S2qinEAC6W3n4CwAA//8D AFBLAwQUAAYACAAAACEAaaJfIR4BAADHBwAALAAAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xp ZGVNYXN0ZXIxLnhtbC5yZWxzxNXdasMgFAfw+8HeQc79YpK26Qc1vRmDwq5G9wASTz5YoqJ2LG8/ KQwSKI5CwJuAiuf8+CvmePoZevKNxnZKMsiSFAjKSolONgw+L28vOyDWcSl4ryQyGNHCqXx+On5g z53fZNtOW+KrSMugdU4fKLVViwO3idIo/UqtzMCdH5qGal598QZpnqYFNdMaUM5qkrNgYM7C97+M 2nf+v7aq667CV1VdB5TuTgtq+07gOx/V1fmy3DToGCTJdN5OB7vE84Hel61iylYh2TambBuSZfmS NOevGc4O8jZDb98s5FiU8eitykOybMmAHpUFMytiyopgZnFDC6a2iZnaJpiaf+vjPa1ZGrKtY9LW Idk+pmz/J6Oz32/5CwAA//8DAFBLAwQUAAYACAAAACEAdLFIo2AGAAAyGwAAFAAAAHBwdC90aGVt ZS90aGVtZTIueG1s7FlPbxw1FL8j8R2subfZP03IRt1Uye6mgTZtlN0W9eid9c646xmPbG/SvaH2 iISEKIgLEjcOCKjUSlzKpwkUQZH6FXi2Z3btzCxJ2ggQdCNlZ+yf3//3/Oy9eu1BwtAhEZLytB3U L9cCRNKQj2gatYM7g51L6wGSCqcjzHhK2sGMyODa5rvvXMUbKiYJQbA+lRu4HcRKZRsrKzKEYSwv 84ykMDfmIsEKXkW0MhL4COgmbKVRq62tJJimAUpxAmRvj8c0JGigSQabBfEeg9dUST0QMtHXpEm+ wqBGk7qekyIadphAh5i1g5r5BCubV1fwRg5gqozbMZ8clwNGk8Zp9AyAqTJuvab/5vQMAIchyF/m vb3dq/WaOdYB2ccy7SZ8Wi0P79BvlmT2dLNEDcg+XinhPZs5IPu4WsJ3t3rd3o4njwFZ/FoJ3+g2 uutbHt6AYkbTSQldq7Xgk6PnkDFnu5XwVqvTqRWGX6DA+/OY0SzGPFVeBNmYC/Rcgu9zsQMA/cKw oilSs4yMcQix2cGMDgXV8uANgp0ZOxTK0pDmhWQoaKbawQcZhjhf0Hv1/LtXz5+iV8+fHD98dvzw x+NHj44f/mBpeQt3cRq5C19+8+kfX32Efn/69cvHn1fjpYv/5fuPf/7ps2qgcoEvvnjy67MnL778 5LdvH1fAtwQeuvABTYhEt8gROuAJ6GYM40tOhuJ8KwYxpu6KrTSSOMWaSwX9noo99K0ZZrgCt018 C94VFCpZBfD69L4ncD8WU5W73NPsRpx4wD3O2TYXlVa4oXk5jh9M06iauZi6uAOMD6t4d3Dq+bc3 zaAg0iqSnZh4Yu4znCockZQopOf4hJAKM9yj1LPrHg0Fl3ys0D2KtjGtNMmADr1oWizapQn4ZVYl IPjbs83eXbTNWZXWXXLoIyErMKsQfkCYZ8breKpwUkVygBPmGvwmVnGVkP2ZCF1cTyrwdEQYR70R kbJqzW0B+jpOvwHVo9rte2yW+Eih6KSK5k3MuYvs8kknxklWhe3TNHax78sJhChG+1xVwfe4nyH6 HfyA06XuvkuJ5+7Tq8EdGnkiLQJEz0yF9iVUa68IJzR9W5HPXJG3BK1Mid0TdXgZ7mT17XAxov/+ 4tvF03SfQLyXd6C3tfdt7Q3+87V3WT6fteIuiizUX93n2AbZtMvJ0m55TBnrqxkjN6VpmCVsGKMd GNTrzPmPzE9jWQyPeYH3cJHAZg0SXH1IVdyPcQbNdt3045HMSUcSZVzCoc4MV9LWTKFhV/b0t6qP MrYeSKz2+MgON91D4ZyM2XYic7wsGDU1gbMya773ZszqVqqlZvNVqxvRTKnzVJurDD4sqwaDc2tC J4KgfwErr8EJXMsOhxTMyEjb3W7ChVs06+L5QlwkYzwiuY+03mUf1Y2TilgxZ32InQofrRvR/9Jq DreWJvsG3M7iJJfdlSXsCu+9iZeKU27hGWOck+nIUjc5WYqO2kFrtbEaoBBn7WAM51t4TDLwutTN H2YRXP2EStiwPzWZjeEX3mwVikH0ORlXrxXjJYW9OpAJqbpYxjY0zFQeAizVnKz8jVUw60UpYCP9 NaRorkMw/GNSgB1915LxmITKdbYzom1nX/NSyqeKiH48OkJDNhUHGNyvQxX0GVEJ1xSmIugX0Q60 tc2UX5zzwlhx26a5YZbFOC+3OkWLTLZwE6pzGcybIx7oVim7Ue78qpiUvyBV3DD+n6mi9xO4MmiO tAdCuKgVGOl8bQdcqJhDFcpiGu4IaBxM7YBoQVBd9HaN4LrYfAtyqL9tzlkamhqDk586oBESFPYj FQtC9qEsmeg7hVg937ssyYKQiShHXJlZsYfkkLCBroFrem8PUAyhbqpJXgYM7mT8+e95Bg0j3eS4 +ebVkPnea3Pg7+58bDKDUn4dNg1NYf+5iMZafudj15vlxd7rKqInFm3WlSIrgJmzFbTytH9NEc65 1dqKVdK4sVoIB14sawyD84Yog4sfpP/B/kdFyOxvD3pDHfADqK0Ifk/QxCBsIKov2cYD6QJpB4fQ ONlBG0yalDVt3t1qqxWb9YW0UQsXzPmeMLaW7Cz+Pqex582Zz87LxYs0dm5hz9Z2bKmpwbMnUxSG xsVBxjjG/Gjl/q7Eh/fB0V24658yJU0wkQdwzQetZ9/kASS/5WiWbv4JAAD//wMAUEsDBBQABgAI AAAAIQBhoTDQUQYAAG0iAAAhAAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1s7Fpt b9s2EP4+YP9B0D4Oafwiyy+IUzhO2hVIuqBOsc+0RFtCKEojGcfpMKB/a/s5/SV7jpT81sCwkwZD USdATJHHo+4h7+7hOSev55nwZlzpNJd9v/6q5ntcRnmcymnf/3jz5qjje9owGTORS973H7j2X5/+ /NNJ0ZO54fqKacOVBy1S91jfT4wpesfHOkp4xvSrvOASY5NcZczgUU2PY8XuoT0Tx41aLTzOWCr9 cr7aZX4+maQRP8+ju4xL45QoLpiBBTpJC11pK3bRViiuocbOXnulU1gYjURMn+Op+3utTk9YT+ci jd+kQtgHMpQPhfJmTPT98bTuH5+eHG9I8cmER+ZSGxojfaTJNkixLm4U59SSs7eqGBU0itXfz66V l8bYFt+TLAP6pNsOlGL2UULM6V2bPq00sd58ojJ6WUDnzfs+9viB/mIS6/G58SLXGS17o+T3R2Sj 5OIRaRjrFoBBi0XJKmfRI+YEzSaOlTPpA4Bhciq411hY56YAw+Iyj261J3PY62DIhwmk+UCp/D7h LNbU7awHXtVaBAmtXiSeeSgAXBIrnONPff/PO6ZwYMspTg7vLRdTNdD3xvdXeYxp7M7kPqG0C4KN brveqQFcwjFotXG87TLL2YXS5i3PM48afV/BdKudzcqjwXqVCC0qczpldpeE9O77frfVaNkJKyNZ Sv4n0qzvY3H80JqsR9hcyNi2DUuFa2OrhLS7vn4gyWjCy8zP8viBBMb4BBCIDHjRJFeffO9eMWyC JgS574l3Eth360EAi419sDb7nlodGa+OyLtsmMNLcJ6ZjKC175uqOTR4IvDyrGDmUo6KiATpXQiT m/kfTBUlcAaH9n0+SljBH8PPyVovdGaQEqHNyDwIuBnaM1GnbebsUp6pW/tCdKwQlq7vZASL3cIx n3yAGJ2b+nI3y9lW/6pWnHe4k4yvmWI0TUBj3+fy6OOoPAeQwFmrQEbT+ch2T+l+7SlN0mfjwLf3 lBg7ksYICJVbPdVHmp1OENabj8Wag6dQdPiePIWJKegBYuj34DIUkTaTS7DFZT7k1uORZh5LLui+ Qby5iFMrBc+D427LNVrE77Jp6UU2qWHCU72oXg+aFNQpY4edFuUXG9OrtO3yDMVNCDSDRrfMAIuk vEwpz84668RHTccL2kN5Z5Ht1sS+YXraLV4GC7K0ZBatLZv/XGZBGWadWrjwaWP0Mza+3Gza96CJ 382NbwWdkDod28AxKY/GS2z8gW48mW5YZ7XMgAgHqMOCeINwsZ7a4AmezsxQcIZgWzq6OR2KNLr1 TO5xhCCvvHARBcLFDIRG023DWDYClWi71Uj7Ykmby7HarkuOeJTL2BN8xsUO6m2Q20P9TZKq3bVb T9pD+5v8Tplk55e3mWEf9elki3Z4/H78Lmh8nazCF4xXE7NxE3LhyqLwjHDlMlQHUasBzreWog5s 7wlsb3y4F22vIAS4WWySvPYL+g1Y3fu77LFMb9nFM1xn9aJ0cKBvVVj4Xx3oJa9LExHbouBf4UXY bTfOu0fdMBwcBecXtaOzQff8qDYYhu3mebfWqg3+Rm3GFsA0apYc9RdbL9lkHY6k2CoiUYkvn//5 5cvnf5eJH0s+rbYBr6iKm2hW5dRIqCtWeKiV9n1hwNfNHK34Fq3xtEF9yIlmjlZ8ixaLIlRoIVE2 qh6Mu56FTLPqQWxwQ0HVE1Q9raqnVfWEVU/oe4lIJepB9sP3Jrn4zXVULRdgbOX7q2qS23SBa72x LA/TpRnYi/OYaVep0kV0xicEJlrXkXFVY7rhVbXCNYnBBMRuXXZFrhzdrFJ5t1xRLZ8qVnb2lno1 kCeTwBrXbm1UTZf25ExYhDroQKUMhkUJU5rjGlxdQtmKzK+ZPOLMpf5IbwxEulzGvaxdcVFHswW5 BpHVjKnLRe3UOwC6N6CEIu05sG0uAbVVWjC0A6B7A0ooloAGS0DrzXY9pMv3AdG9ESUYS0RbK4h2 Gh375ckB0b0RJRhLRMMloo1GB0d09Ywi9t6w8QjfZlQBocpUq1VdG/vL70Uwe5fvRV4g41A2EcZl E/7cNEOolAC1VwBqB03KkUsn/mEBIlRKgDpLgAgdW2Jc+OQPCxChUgLUXQEobLXX08APCxChAlZX /ldIyY2rR1ezPP0PAAD//wMAUEsDBBQABgAIAAAAIQCEUtNrqAsAAGNCAAAUAAAAcHB0L3RoZW1l L3RoZW1lMS54bWzsW1tv4zYWfl9g/4Og92lky5KlYDyFLtZ2gWl3MEnRZ1qWbU1kySvJmWR+fc85 JGXRF9ppjLa7EwdIaOqI5Ll850Iy7398WhfGY1Y3eVVOzMEPlmlkZVrN83I5MX+9T955ptG0rJyz oiqzifmcNeaPH/75j/fstl1l68yA98vmlk3MVdtubm9umhS6WfNDtclKeLao6jVr4Wu9vJnX7CuM uy5uhpbl3qxZXppGydYwbJwt2LZojThr8mVpfpDDTwuYo2wb7EiL+g4Hz8Q7Uf6Yp0Q6fxggQfPc REVtPLJiYsJE8+rrffbUmkbBmhYeTEyLPubNh/c37Fa8VLQn3u29l9BHvCdemD8Mac56OesmdUdu 6Lnd+ERQtId0kRMP4nE3HhGwNAVG+Vr6Y8YD1x75grZHxJtHxo7CkWUp9L3x7YM1e1EQB1OFnoj4 +KMj9ONwrI5PRJzeOaRPQsuLlPGJiNO7B/TxwLf2+CWiVZGXDwfUlhXYsZR4R7Koip+Okrv+KLGk 4HdUYA2dceEUi6psFVM7Yp5r9qWqEyDEFwrW5qXRPm/AjFMw56DOWYE8s9uM9fp5V9rsdcH8ynDr vLzq2LvhYKYdc8TqWuX0P4tFnmYmPcqL4q59LrKPDTHZVEU+T6ATHxLMs87yNytoCiUrdMua0TtG XbW/5e3qbsU2IKABzbBsxNDLxthUDQCUuo+OjZOCkFsObweRzKXZsPbnas677T7Au2EI7kvyIXIi Gwe4dDJ7/LrJBnxVJ8WmsjagpZHtKKx1LIMOD1mDzk6aYPoGQ/89cMHR4tqNJmVFNke5c+cn1YJT y/ZVVNSs2DwTOkK+D3U0ICVJWyGHDrZzREceLV0rtd5sPg77itkuUVJ/OnCyR6eT2nuNlmhg1KgA DwlnsQfHouyDsyiNrxPTd4aOaaRsMzEX4JOgud6A1ptyaRqsWEKET9uam/1ZMJPgd9r0JWNgfT3E DSzZf8Cw4gc2ddPGrFlx06BHwgSKEmfi6x86GLuuxAC39D+wCtsDY/jLVgFyVFWbLRZZ2vaV3etB 2fGvwpVW2zar71bzr8as2NafGagfTRX4medNOzHJI+AXyIdQ2vRIdc7CMfazEKLj/azYrJhwtwhR iWROTqbarYG+9ZYHvB1dOzH3clYI8ldipW/G3xkrGE+yMrPnqIEU8vGaGYjXiVnV7aoCL7RZ5WlS Q7JDvgOsBXJqeAxGBVUB/a2zR/zLMcfHIFjny1X7OV8adQ7xqF3VWfYJ3BJZ35nBBiJ28SELMRBZ VG+5zYYve5Y9ZsU9+kAXY7tprMDUyZsIN0B0+/anfhcImi0xyenjTfEhXezlGPizMx8OZmBK9cOU 0Ej5d0skaamZD3+fXpext88IPtilWSOJCpisFwp8Afs/uIQXhlrusQ44HjpycaDFQ46hs0uINqxd GfgL4l9ep8Uuv72vPoNvNaBgxMHAbMCq3/HEw0AHyTtnkDjxTm5MOBQXbRegd8H6KmnUTgXdvHvC xpVdou8XCrtLztTpFCxeU9hCwoqsed9JUYNm9yEKXQtZyJBiaG+iv3lQzb6AokUdR6VAs4FvhIPN p9qYfYUiAgoTtm0rcnJPi3qNT6vFwngiF/csHBzEsKfWSKFzAEkC9MqkWr6Sbpv2X1lFr7NH8Cpk u8u5bLGVbKVPpWzWwg65DcJvEAn8BtMjLbNbNDpODNz2p9B5J15lywUqlNfMGNuno1OcSPrYbV1t yzlJZZWx+bScU0E8MUvYYzLRia+zOcSWDGILtoiyZXlxCSVIh6eUXd7BLakBNaNCZ9X8GRQOe16A 9VVVf4MJIcJBlvzfLath+uLfJZSi/mA0Ql3Ql5EzHqJK+k9m/Sfldh1V4EXAIliZwqgQ7GQzarkq 02oNOvxY3m1SJMS1oIDun35j9UYE3BZM65fqDotkIpDmA0ztaMnCORs4SNHw5BDb82zxCZhbs/oj mQ80PlMDtsNge4mavBAoIApni3s2u/smmEUGW+AB/mbsYxnWD9TG/YKAaocZa1A8uNexe7yCShM2 9T5ty5SGpxUhj9hoNukncK+0IyccEVcGZLgdRShhuKPtHNsm3T0NFnwbojdmj048nW2hmLx/IouZ be++dU3cqum+/AJ2JoxqJgEI0vgMonvYrvN19SUn3gsqo7Py3a93UEODoDAMCFAanGQrrbZp6/wB PEhZ3VFLFBDcpGE/Z82K/Fv2E42LkoQqHahhtGYNu5MZozyKSw9/lxVmIVJaJExNyXYCgH0IgKEc 3aUy0hWrm4yUx6fjkiAr4/ZEzZ2ZgTF2zrMoY6m+Ny/6yrr7hBLfvCg61Dcv+uZF/9+8qHCe4E8P 01NIBGoGseyOqjQIUhgC1E7sSSXF0YM0g6cZ8nzsyI6O8Pj8AE2ehfXpLj37onpExmNxOHbs7Muz 8Efu/fHDMZGlUpDrzx2GU2tqC9oeEW8OD+ht+PjqWRkRcXo61mr64yu89Yh4c3QwvsJjj4g3D8++ 4GAtnibK+rVnX8N4GHuBQq89+/LhI6jPn335fhR1FePpsy8wqJ/ZxpgtBxMT7AEy4CdogQVB2rMc Yt8Q+6AFSoYUlx9bQuHEG7IHnvOejsaWPbakGcmekexxZA/sYvPXXdnjwpYOnulBzo5/TEOyAFvd 4rhPiOIQJIc9Z2AzpOT77wQb38UfwaHAlRD5gZkmYZw4L4BNkvi+K8cWWsNBefPPh00ST6NQXb8W NtOxFzjqEbMGNlFkwybHC2Djuh25tDRKiDsbQlm9wWZZGvbfDjYviTboIBPVW9N1jB4ilOgRwWeP /i+NNlEwHe6tRwub0A/9qbwMwZnUwAZjayRBdj7aBIk77hbzBhv15hKUzL3bTsbo1bCBLMNN5Bac 5oKSksBokrQXRZv+5ShuRlrYeHHkdpbRwxZvHkabaZQEiWqmRMTpX5+kHUkCtbAZJ6F9OWzgopv7 AtjAfSbcYeJZ+RtstLBxXg0bVH0sM+grwGZMnwuTNJxcNWstbND7doZ0AWxw+KnkrYetq8JGrVW0 sBnGGG+EbPgiNNEmSRy4WHJxkoYZ7Bts4GqsSEX5psHxLQFXAxsncDwh9L3rsSfLZi1seqW+Jtqg qXaF7JnaBvzpyB0qZqSFjRu7SaTCTJukBUFkRdLwLoBNDLdnYxUGFJL4q4QIJWkMgtAL1fVoYeMO 3VE4UvjVwMayUJYXwwbJXwgbKvppS4A2B2hLgDYHaEuANgc467BpIBqylP/f3hIYn4SNEw12UrwC bOjEX5qgBjZxEg99WSafgY1S9Aq97Ep8QoRipuF07LtyDZxeC5vICuCjmKk2SXspbKZDQJk6vhY2 QeTGjrqloYGN4oDO1zaxHQwHMpRdlqR9t7DxTsLGsmy723W6AmywtumiiAY2WLR3PvIMbHCFe0mX NtpYVgirUGCghQ2CJlLN+qqwCeLQm6rRUgsbkODOlXHYa2CDsukkeR42kI+OrYEQzhtstLWNfxI2 aJI9MydzFDmY4sHRyDvlaJM0BI7QigY2U3sa9rYYemZNS1DmRmh3a7wg2oxcLxiFL4PNXjS4LmyC IN6DpRY2djKORzISXx021hQuxL3BJrugthnwK+oimig2qdTmVwg3rueGTnweN/CffoNI2vaZcONb vuWp7lobbjzLnwayYLsgS4MKPAjVrOiquIlc+JEenq9Hi5ux7SW+un5NuEmSKOoShvPhZurHUbfh 8BZutOFmcPqegA2OvztcuwZuXCV+URwRsFDwuhe/tPHGtRx/LDF2QbyBJbhdbLwEN14I/yarxKer 4iYEVxLKsv0C3DiRE12+Ba2ca53HDQq+C95vuNHj5vRFAbjLYQ2cLj68Ok9zhvZ0KH23Jk+Lk8jy ZFw6E2+86OB/ufXxJnGSoWqnPVwSJBQMh3aQBPLMkNv1VXETAWpCFffaeOMNHGeo4lgTb6L+f9Kf x40XQTD+HvM0uL6mXrChy2rQS/+E8eF3AAAA//8DAFBLAwQUAAYACAAAACEAtM9YGbsAAAAkAQAA LAAAAHBwdC9ub3Rlc01hc3RlcnMvX3JlbHMvbm90ZXNNYXN0ZXIxLnhtbC5yZWxzhI/BCsIwEETv gv8Q9m7S9iAiTXoRoVepHxDSbRpsk5BEsX9voBcLgpeFmWXfzNbNe57IC0M0znIoaQEErXK9sZrD vbseTkBikraXk7PIYcEIjdjv6htOMuWjOBofSabYyGFMyZ8Zi2rEWUbqPNq8GVyYZcoyaOalekiN rCqKIwvfDBAbJml7DqHtSyDd4nPyf7YbBqPw4tRzRpt+RLCUe2EGyqAxcaB0ddZZ0dwVmKjZ5jfx AQAA//8DAFBLAwQKAAAAAAAAACEAhR6iEgBAAAAAQAAAFwAAAGRvY1Byb3BzL3RodW1ibmFpbC5q cGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/2wBDAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCADAAQAD ASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0 NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKj pKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QA HwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEE BSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZH SElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0 tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+ /iiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOb8ZeJIfBvhDxV4vuLK81KDwr4b 1zxHNp2nRPPqF/FoemXWpyWVjCiSPLeXSWpgto1R2eaRFCsTg/IPw++JP7VvjP4e/DP45aKPgR8S vB3xBTwl4kvPhB4F0HX9B8YaJ4I8ZzW/2htE+N/in4vXPgnxd4l+HenajFqWtWl/8LvBFn4xl0TW tI0yTwvqFzpwH2J4qvvEGmeGfEGo+FNBtfFXiew0bUrzw94ZvdaTw3a+IdZtrOabTdFn8QSWGqxa JHqd2kVk2qTadew2PnfaZbeSONlr8sPF/g7wJ4ohl8T/ALMfwO+OH7N37YOt3PhhJ5PDfwn+L/wf +H8Wt6d4zttc8XJ8YPE1t4c0P9lv4weH9Ohm8Tz6jrWr6n46l8aWDeT4Cudd1bUNAtJ/QyyEalec JwjNSrZenUnThWhh6DljFiva0JVKU5YTE3w/17H0alOvlFDDKdGrRrY2m5Y4ttUISjLktDG3V3BV qnLg/q7eIjGpLDVsMvrLwmHlTnTzWriJQnTqQwE+T71+If7THwY+FviK68K+MfFGqQa1pWi2viXx LHoHgb4geNrDwN4avp54LPxJ8SNb8EeFvEWifDTw7cm0vp4dd8faj4c0qSx07U9RW7Nhpt/c27fH n7TXwY+HNzbWeu+JNb1e6uPCa+PJIPh18PfiR8XZNL8Dy7/svjLxCPhR4S8af8Ix4V1IQ3TaR4g8 RHS9J1lNP1R9Ku7xdK1E2vwx4s8G+Nfhx8dP2otU8WeMv2rvDvhn41an4b8YeEH/AGdvgX4M+N3h 7xvpGn/DbQfA1/4L8SXmr/s8/GvW/BvijStQ0O7trOw8U634P8CXGh63p99pd60w8TT2S+KPhX4U +D9l8M7jwVJ+3N8D/iN4M/Zz8P8AgHw147+HXww039oC38ZaT4f0/U4vDfw8+M3gv4ceD/jJ8N9U 8W/DfUNRmmju9R0T4faRef8ACQXNv4E+I+oadY3Vx4auGFw31fC1pzrVJVqOHqOnh06lSpWq5bjc VisHSh7F3q5bjaeFwdf6vPHVq0PrFWWFwlSeGozpyl9YrUkoqNOUoqVSSjCNOOMy2hTxM6seeapY 3DYjFYmhzYelTo1Pq9CpXqwo4zEU/t7xl+1L8D/A/wDZx1HxXq3iAan4Nh+IkR+GngD4jfGFbHwB dI0lh4311vhP4S8ajw14T1WOO5k0bxD4iOl6TrKWGpvpV3eLpWom11NO+MvgzU/iJc6FZfE3wXea InwW0T4wQ6Zb6Fq4dPB+r63q9nb/ABJb4rNrzeArzwdf2unPb22hW+kRavZNZXHiG61ybR761toP hTxjYeLUj+HnxZ+IC/tVfAj9qq9/Z70bTvFHjj9mv4RX/wAbPhv4116O01W6i8C+O/hzonhL40eH JNW8Ba/q93qNqvizSfAcTN4nvLDwd8TdVs9Ou7zw7zHin4UftH/Gi++J8HjTwbLofxO+J/8AwTG8 P+ANW1GCxutN8Dr8YdT8ZePr3UfBi+Ikku9BstZUajaSarpNtrV7HpUN+J1uLjSfIvZtZ4GhT9ol VV6FTNaNSsqir4epKhhOIKuHeD5MM1jKUHluEp4mrGUMRGtXgqeEoTxOEqU86VWVRUVNqEa1PJ6j 5oqnUhHFZhwzQxU6yddrDclPM8wrUYU6mKoyoUYPEYtKhi8PX/QL4e/tQfBL4o+INP8ADPg7xVql xquu6PqXiHwo2veA/iH4K0nx7oGjy28ep658NfEPjXwp4e8P/EvR7JLuzu59T8A6p4jsk028s9V8 86bd293LyXhv9tn9mvxcnha88P8AjnXL7w/4z1jS/Dvh7xw/wu+Ldj8NLrxJrMwtNN8NXnxR1DwL afDvRvEs+osmjt4e1rxPp2s2+uyR6FdWMOsSR2LeHvqOt/Hrxz+yLZeGvhN8V/h8/wADPE2o+O/i jqXjz4eeKvh3p/giKx+FXizwDF8PPD2veJtMtNK+I8/iXX/EEFnLcfDHW/GHhc+HNGudT1LXRa3m iHUfI7D4afEaz/4JWfDj4fW3gDxrafELTrr4R3Nz4Ig8K67B4zsLjT/2j/C3iPVLifw1HYJrlrNZ abDda9qEslkj21jFcapcslukk40jgMEq8IVJ1lTnm2TZfFLE4fmqYXMsyzHC1szjVhSq0lQp0MJT 9nBKcXJSxjrywmKwsTCGIrzp/BGFWWAWKkpU6n+yYt0nzZfiKUpQnUq0ZeyxFSSlh5ezxCwrpQrU alZ/rVqVy9np2oXkQRpbWyurmNZASjPBBJKgcKysULKAwVlJGQGB5H5teBf2oP2gvi5afscaZ4Uv fg34I8QftDfBf4jfFHxnrHiH4beNvHWj6XqHgmbwVFa6X4Y8P6b8ZfAN7Z2d8PE90bibVfEmszRm 2g8vOZN32jqGjfGtvE2uXlx47+Gd58M5rLV1s/BVj8IPFlt8QRHLpE8NjA/xGk+Nt/4fubiPU2S5 mki+FEC3lmDp0NvaXDjUl/Mf4L2Hir4PR/8ABOjxN48+GvxktNL8Dfs0fGXwl41j8PfBT4t+PNZ8 IeJNfufho+jaP4n8N+AvBfibxHoN5qC6XqLW6appVqpFnPudfLNc2WUqE51nVdKrJ/V5UqclK9Or Lh/jWuqEozjGFWbx+DylyjTdalUrRwtJSn7Tkl1YiU4wXs1JNKupTSTU4LMuH6bqRV3KMY4avjrS nGnOEJVppR5HKP338OPit8QrD4x63+z98aP+EN1Pxg3gaL4o+APHfw+0PW/Cfhvxv4Ng1a18OeKb C+8F+IPFPjvUvCfiXwV4hv8ASre4T/hNvEen+I9H17S9Xs30m5j1HR7Tk/FHxJ+PXiL9p7xT8DPh j4n+EPgrw/4T+DPgb4l3GsePPhR4z+JWsapqfi3xb408Oz6fD/wj/wAbvhTZadYWdv4ZtbiEvbaj cSTXFwHlVPLCJ4BTXPjB+05J8dLfwr418JfDL4d/B7WPhT4NuviB4R8QfDzxD488TePfFPhbxZ4y 1e08C+NdG0Lx1o/hvwta+C/Duh2mo+JtG0M69rF7q02iWl9o9hHqt75/4t+Ac3xR/bT+Jus+IT8a PCfhaX9mL4a6D4f8e/DX4ifFj4TWh8Tp47+J0uoWUPiPwB4h8N6P4m1nQrO+03VU0HxCdftNN+1W l3caP9nvmFyU401Vy6WIpxjXll+aVsbRVOlFRr0KGcyy9+wlKnRjWrYShlmKlQnKnCWKqyhUjR5p UoKTXs809jO9KFbJoYOs5SqO2IxPD8MxSn783GniMRmmHlKMZTo0YTVNP2UW/VfhH+0LqD6P+0Fb fHzVfAnh/Uv2avHl/wCGfG/xB8O2+peGPh7rXhyfwroPjzQfE9tpHiDXvFOoeGL2Pw74msdM17w5 ceKvEstvrljNLZalPb6pY2cHpfgT9oj4RfEV9fg0LxJqOkX/AIX0KDxVrujfETwZ45+EniGw8I3K TPB4ybw78VfDXgzXZ/BkptrqFfF9rp8/hv7VaXdodUF1a3EMf5qD4LfFyX9k74yfsyQeB/GcXxN+ D/xq8G+P9U+IWnaVeSy/tTeHYPiP4f8AitN8SNB8XfEm213wn45+MHiPQdKn07xb4e8T6l4j0aw8 f6PYaRq9vZeGr7SdJsuk8V/BzUv2jNM+LB8L+Mv2wPGfxCvP2ZPib8MvDfiz9ob4P+AfgH4C0qb4 lTaNct4Fubc/AT4G+PPFGr6nfeGLKeTUtI0Txh4K8NWEd+95rmlatqulw6hvUwuEqRrVnWjGNOhS vVo05KFSMchwmLpZv9Uo0qjpUM5zOrVpwy+TwM8A6dXDU1WxXssvpqm5KtSpTXs41cfXjL2lSM1R pVc8eHWDjWqzp3eAyyUMVDFKWLhjcPWw1eLjh6dfFT+0vDf7ZX7O3ivxL4H8I6T4z12HXvidcNF8 NbfX/hf8WPCVn8RLZNH1PX5Na8C6x4q8D6Lo3i/wtFpGlT3k3i/w9qGo+FoVvNCil1hJ/Evh2LVO 1X9on4ON8HtL+Pq+MM/CXWTog03xZ/wj/ikfaT4j8T2fg3Rh/YR0QeJYftniTULTTf8ASNGi+z+b 9suvIsI5bpPgn4j/ABX074hfG3/gnzoFp8Jfin4F1Tw78VtcXX5fHnwu8TeBNG8Haq/wI+IlhL8P tF8Q+JNH0jSfG8zT2dzM+qfDC68VeCTZeG7a9k10Q6j4bOoeRaiPHulfsD+E/wBlSL4JfHfVfjH4 N8W/D7w94s07Tvg94/fwppmmeEP2hNE17UfGWlfESbQYvAXjbw3d6Zp9pe6dH4E8R+JfEMmnatFq 97oVjpGjeK77w/pDLMPUqYeC9tB1s5yvBq9fD1PaZbWx1fD5nmEJU6fJGlhqLwdSGIcqmFhCvHEu VfDV6MlzfWq0feqQjTj/AGVh8ZUpyhUVTD4yssY/qU22nUqNYOahRjSp13Xf1PkeJShL9LvEH7SH w0+Hl18ddX+IvxO8PWHhT4Max8OtL8VQ2/gLxtY33w7l+IGl6A+iW3ibXlu9esfG58Q33iDTtRtN U8KaFo2n+F9Nvk0/xCs09hfasH6n+1b8GNHsfDl1qF38SIdQ8WW+tX2heD0+A3x5ufiXdaP4dlhg 1nxHcfCq1+Gs/wAStM8J2M91aQP4t1XwpZeGpZ7yzht9Vllu7ZZfg/4//DD4ha9H/wAFCodO+Hnj PWofHPxb/YtvvCcVl4S1zUY/GOk+GF+Di+K7zw6kGnzL4h07w8umaoviG400XdtpK6ffjUntxaXA j9U+Nfg/xx4Q/a11P4v3PjL9ofwV8P8Axx8E/CXgDS/Ff7PHwm8PfGzVNI8Q+C/Ffi7XdS8N+MvC 2ofA747+KtB0fXbXxPZ6roOteGfDenaFd6jpuqWnijU4r5PD8Nzy0cLhqlDBSnVcauJpUo6ThGFO ceFcmzbllFUpznOtmOPxGChd+2m6MaH+04+UnU6nOap1pxheVBwk4e9KVaFXMqWEl7NLWn9Wwzr4 urJqpB04c0lhqFKpVf1J4h/ar+Afhqw+HGo3Pj0a3B8X9L1nWPhbD4G8L+M/iRqPj+z8PNo41tPC ukfD3w74n1bWNR0xNcsbi70ezspNXjtItWvTYm00DXZ9N5bQv23f2ZfEr+HxovxC1G9tfEfiOy8G Q6wfhx8Urbw5oPjbUdZufD9h4G8feJ7zwVb+Hvhl44u9Vthb2/gz4jan4W8TyRXmkXq6UbHW9Hub 75i+F3wevPC3xb/Ym1Tw54N+Ng8JaZYftmeMNe1b4v8AhrwraeKfDOsfFi/8LeILOfxdbfDfSNO8 E+AJfGF9fa1feGvC0mn+G9YsrG4n0XVNB0rXbHWdHsaOsfDDxmf2Wfjt4dtfh54n/t3Vv26tW8aa PoVv4S1X+19T8Nt+2J4U8QweLNN0yPT/ALZeaG3hO0m1yLXrWCSwPh22k1NLr+zYWnXang8A8Rg6 NSWISxNW9WSr0oewpPiynkDoSVTDJutSwVVY6VecaUZulOX1WlRneljKrW+rSqQ9m5/WZYOEuRyh UcsvzDGUcfywrSth5zwlGnLDwrVUliUoY6o4QlV+19d/am+BXhrxjqPgjWfGl1a6nomt6T4Y8Sa3 F4O8d33w78JeJ9dW1bR/DPjP4saf4Zuvhd4M8R6gb/TY7fQfFPjDSNWefVtHtzZifV9MjuqXiz9r L4GeDfFnjLwJqfiHxXqvjD4eLYzeOvDngf4S/F74lap4SstT0HT/ABNp+r6/bfDvwJ4pbTNAvNG1 O1uLfxDdGPQ5bhL7TV1A6npep2dp+c//AAqLxNovhr4/fAX4peIf207iP4l/Fv4rarD4F+CPwV+F XjH4c/FHwp8YfGd/rmk6rp3xo8XfADxJo/hDVF07WYbDxTcfFb43eCL7wlqmh3VzZ3WmaDF4evJ/ tf4AeCte8NftEftoatqPh7xDYaP4j1z4DQ+GPEWt6XdQReLLHw78DfD+jX0+m6zJbRWXiAaXqyXl hqc+mT3NvZ6sby2kMVwZI65auHw1HBVcVzzrTpZNPMYwpzUY4jEp5JT+qwcqElSlQqZhjPb0lLEV 70oUakcNVw9f2mzqSWMnQ5b01i8XQT2lGlh8TVhh8Te7dSnj8PBVKTdKjSjy+1oVsbSq/uYLH9tj 4dal8ep/hvbXar8MrX9nzTvjmfjA+geNP+ELubDV7y+vIb2Txm/h6DwLo/grTvCulXF7P4wv9fk0 XUvEd6/g2C/sfFXh7VNEuva/hv8AtDfCv4r65c+GfCWqeKLbxFb+H7PxbFoXjn4afE74Watq3hW+ umsYfE3hvT/ih4O8HXXirw/HeiK1vdZ8NRatp2nXF5psOoXNq+qaat1+U37OXww8Q+HtM8E6J8Z/ gb8XfFPhrx7+wDdfB/VvBNn4C8WxalqetaF8Uvif4k1z4f63rl8vh3QPhvrmo+D9YsT4XuPHfjHw HFf3c9naaFq6ap9jQ/V/7Mt98SdK+KmheCfBnjT9pX4hfs8ab8K9Tl1+b9qv4O678PvFngPxnBru njwdonhHx94t+Gnwt8YfEttV0i71y21201iy8dQ+G7Lw5p1zJ44jm1jT9Ln9DEZfgoSqUKLqSeHh mahXlVh7Op9TzXiWHtsTVhQqKLr0MBgaGBp8lKlWm1Q+sqpVoXxqVa0JTbcNZZWrcjin9YyzhmVV 4WlKp70PrWNzOWJ9piZVKE4qVGnio0MRQp/otRRRXz52BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQBw3iP4j+EvCvijwZ4L1e61VvE/j+TVh4Y0rR/C/inxJJPbaCdLTWtW1a48OaLqtn4Y8PaVN rmjW1/4k8UXGjaBa3mrabZzakt1fW0Mvc18X/tE/ALXviV8TtA8ceDfD/h2y8WaP+zn+0Z4D8P8A xQvINGg1zwd488aP8OLX4dtY6vtk8V6c62P/AAseO11rQYJz4etNT19RLaza8LfVPANH/Zl1zW/C njnQdF/Zyi+CXwv8XeOf2U1vPgFeax8LTp2pJ8PPiBZar8bPiFfWPw+8V+IPB89l4p8GTaV4d1H7 TrzeLvHlj4Hl/t/w2lxc6bb6l3YfDYevQw0pYmNCtVrYanWjUdNQoQxOeYjK3UmpzpzUMPgqMM0q Sp+2bo1ebERwOG9ji8RnWnKm+aMXUh7KvLlim6rqYfD067jFRUoL206vsaSqyoqXsKrpTr4icMGv 0ru/F3h6x8WaF4GutQ8rxT4l0LxL4l0TS/sl8/23RPCF74Z07xFe/bY7Z9Otv7OvPGPhyH7Nd3cF 3d/2j5ljBcxWd+9q/wATeK/D/g7T7XVPEmopplje674a8M2k7wXVwZ9c8X+INN8L+HdPSKzguJy+ o67q+n2QlMYt7VZ2u72a2soLi5h+O/2ovgb4v8cWLaJ8MvCdsNEtf2Tv2l/hHpFjo194d8N2mla/ 45b4LW/gHw3pNpd32mQadbXFj4P1uKxubeGLRNEi0qKK+udPWewS48q+I/7IOmaXJ4+0r4f/ALPv hLWfhtNq/wCyH4z0/wCHeiaf8NbLTvFnib4dfFPxPd/F/UrfQvFGr6F4bPjK++HN3pdjrfiDxNc6 RJ4y06QaPNreqyRz2qXhsNhKsculVxfsvrOMo0cRFqkp0sPLiCrl9WtUU6qWE5MpVLHwlUeIhKTn Vly4blYqkqkKUpRhGdRUMRPkjJtKrTw+HlQpxlyJ1VWxNeUH7tJxo0KtTWceQ/Tqs2HVbWfVr7Rk i1JbzTrLTr+4mm0bWLfSZINUl1CG2jsdeuLGLQ9UvYn0y5Oo6bpmo3eo6RFJp8+rWtlDq2lSXn5D eKP2S/i/qPjX9pLW7bwj8Qr7xZ468P8A7RdvpfjiPxR+zd4c8FeM9A+IFncQfCzwDb6lo/hOH9o3 xDdeG9PvdE0j+yPin458O+AfA2p+CYtW8JatqGmR6FpY+gPH/wCzHfyXHj7wp4E+G2iaZ8M9Z079 i7RNK8O6DP4c8O6JNo3w3/aJ8SeOPi5Yx6XBqGnNaQ2PhPWptX1HzIYJPEkuoXdvpbaxrE1zbEWD w7hgW8bS58bHLnKPuKOD+uYiFHE/WpOpz0/qVOpGvOM6dOUoRre2WF9l76dSSqYmPs5OFDE16MKi Tft6dGthIQr0oOMbwr069epTXPZLDv3pJz9l9q+Kvhz4N8a634D8ReJtH/tPWfhl4kuPF/gi8/tD VbL+xPEV1oGr+GLjUPs+n31pa6l5mh69qtj9k1eC/sU+1faUtlvILa4h5XxX8efhb4K8a2Hw+8Ra 9qdt4lvo/D0swsfB3jbXdA8Px+LdWudB8KSeNvGWg+HdT8HeAE8T6zZ3WmeHm8b694fGtXkEkGmm 5cYr5B+E37Mfjj4Y+PLDxJ8PfB3gX4X6nJpn7Xfh6XxRd6BpHiPQrDw94h+P/gfxB+zvoGp+E/Cn jbwbrOr+EdK+GWk61/wh/hPSfEOi6Z4Ct5LnT5Y/D1/fzabf9z8fvCfxy8e6P4V+HreAbvxX4ksN X+HXiXQvjV4H8TaJ4Q+EWi+LdH8W2Goa9qvxR+B/jX4k3usav4f8O2+m2+teGPC62nx5jv8AURBf Wt54O8T6Zpms2pToYeVXL6csXz4evXSrwc4Yeph6csbiMJWqqU51sPTksPhaWLvWlTdWnXw8Ipwf toqpOpGOLl7JOtQjiKFGpHmrRqLC1W6VoqNOrVw+Iq1cRLDKhzWhOeKkoubo1PuWiiivONwooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiisjV/EGgeHzpY17XNI0Q65q9n4f0UavqVlpp1 jX9RWZtP0PSxeTw/2hq98tvO1nptp517dLBMYIHET7TrGP2pzp0oLrOpVnGnSpxW8p1Kk406cFeU 5yjCKcmkzpKXSEJ1JvpGnThKpUnJ7RhThGU5ydoxhGUpNJNmvRSEhQWYhVUEsxIAAAySSeAAOSTw BXCfDf4p/DH4x+E9K8e/CL4jeA/ip4F12G4uNE8afDfxf4f8ceE9YgtNT1HRbqfSvEfhjUdU0fUI bbWdH1bSbiS0vJkh1PS9RsJGW6srmKIWvNbXk5Oe2vJ7Tn9nzW+Hn9nU5L25uSfLfllY6J9G+VPo 5WcuVPvZN23sm9kzvKKyNC8Q6B4p0yPWvDOuaP4i0ea51Czh1bQtTstX0yW70jUbvSNVtY7/AE+e 4tZLnTNWsL7S9QgWUy2Wo2d3ZXKxXNvNEnMwfFT4YXPxCj+Elt8R/AVx8VpfA8PxOi+GUHjDw9L8 Qpfhtc6w/h63+IUfguPUW8SP4HuNfjk0OHxYumnQZdYR9Mjv2vVMAFrKMFrOXPyxWspezpTrVOWK 1fs6NKpVnZPlpU51JWhCTRtGU38EeTmn9mPtKtOjT5pbL2larSpQu1zValOnG8pxT72isjQvEOge KdMj1rwzrmj+ItHmudQs4dW0LU7LV9Mlu9I1G70jVbWO/wBPnuLWS50zVrC+0vUIFlMtlqNnd2Vy sVzbzRIN4h0BNfg8KPrmjp4oudHuvENt4bbU7JdfuNAsb2z0291yDRzONRl0ez1HULCwutTjtmsr e9vrO1lnSe5hjcWsoxWsp8/LFayl7OnOtU5Vu+SjTqVZ2T5adOc5WjCTRdKLm37keTml9le0qQpU 7y2XPVqU6cLv3qk4QV5Sinr0VyGqfEHwFokniGLWvG/hDSJfCUGhXXiuLVPEujWEnhm18UXM9n4Z ufEKXd7E2iweIry1ubXQptSFtHq9zbzwae1xLFIi9fQAUUVkaz4h0Dw7FYTeINc0fQodV1jS/D2m S6zqdlpkWo6/rl3HYaLodhJezwJeaxrF/LFZaXpluZL3ULuSO2tIJpnVCbuMV8U506UI9Z1Ks406 VOK3lOpUlGnTgrynOUYxTk0mPRSk9IwhOpNvaFOnCVSpOT2jCnCMpzk7RjCMpSaSbNeiisi/8Q6B pep6Houp65o+nax4nub2z8NaTf6nZWep+IbvTdOuNX1G10OwuJ47rVrnT9Js7vVL2CwiuJbXTrW4 vZ1jtoJZVA/r79jXorI0HxBoHirSbTX/AAxrmkeI9C1ATNYa1oOpWWsaTerb3EtpcG01HT57izuR BdW89tMYZnEVxDLC+2SN1XXo32AKKjE0LTSW6yxNcRRRTSwCRTNHDO8yQSyRA70ime2uEikZQsjw TKhYxOF838c/Gr4N/DDxH8PPB3xK+LXwz+Hni74u6/J4U+E/hbxz488LeEvEfxP8UQi1M3hv4eaH r+q6fqfjXX4hfWRk0fw3a6nqKC8tS1sBcRbzeUILWVSpClTj9qpVqSUKdOC3nUqTahCEU5Tk1GKb aQPSM5PSNOE6tST0jCnShKpVqTe0YU6cZTnN2jCEZSk1FNnplFeZ+BfjV8G/ih4h+IfhH4Z/Fr4Z /ETxX8IvEEfhP4r+GPAvjzwt4u8Q/DDxVKLpovDPxD0XQNV1DUvBXiCUWN6Y9G8SW2mai4s7orbE W8uz0yhaxhJaxqU6dWnJaxnSrQjVpVIPaVOrTnCpTnFuM4SjOLcZJs6yj9qE6lKa6wqUpyp1aclv GdOpCVOpB2lCcZQklJNIooooAKKKKACiiigAooooAKKKKACiiigAr8av2sPgR+0v8Qv2wPB3inwv 8Pv2g/F3hnQPEPw58T+AfiN4S/aR0LwR+zf8NPCXh/wZ8QdP8YeFvHP7Puq/HnwvP4w+N9/8R9V0 7xT4d+KFh8A/F+oWHhPUdC0ay+LHh2LwxqHhO9/ZWiuXFYSGL+rc1WtSlhcbhcdSnh5qlUVbB1o1 6K9pyupCDqRj7RUpU51KfNRlN0qlSE+ihiJYdYmKhTqRxWExGCqwqxc4OjiqbpVb0+ZQnLkb5Pax qQhPlqxgqtOnOH86Grfsm/t42vxh/ZO8LaHpf7VV18LvCPwj8GaL+0L8Rdd/bb+NXjGDx3qHjvwZ 4ztvjTZazf6h/wAFJPB9lpvjvQviJ45vb3Too/2LfjNb6Z4P0nQr34MftG/DtvCnw++GHg36F/ZF /Y6/aX/Z7kuNP+G91qPwp8Yal+yV+wn4KvfiL+0N4p+JH7YPwli8QfCPwz450D4v/C6w+Ftt+2f8 PvE2kePNJvL7SJ9K+IGlzx+AotI1CODRtV8WquoaDp/7VUV6Pt5e1zGtyU1PMs6lndS0Wvq9VrNH Ty/CtSUqeU0qmcY2rHATlUhUdWpQxEq+ExOMw+J8/wCrR5cGpVK1R4PKKOTxlUmpyrU6VTCVKmOx PNFqrmmKeBw6xGNtGXPSpYmhGjjMPhcRQ/m98Q/szf8ABUPxF+0n4d/4SfxJ8eJ/g9r2jeLfDV5q vhT4gXer+EvDvgbxJ41+NcHiDwl8Qgf+CpPwM0LT9c8TeFvEGgP4f+JGkfsM/tS/Ev4a+HNV8GR+ BfiD4R8R+A7TQ/Bf1L+yX+yD+0j8J0l8Y/D651j4AfEDWP2Sf2F/hNdf8NUeLfiV+2L4asNU+Ddp 8XbD4ueEJPht4O/bU0LQrTxTZR6j4MfRPiJpPxCvdKhGt6pcaeniabVfF9mv7O0Vz4RLBUcTRpe8 8VjcNjZVqvv4ilPCVs3rU8NRq+644Ccs8zCNbASU8LVp16sJ0msXj/re2IgsTWw1ao5J4XAVcvhT jKXsqlKtDLITrVoSclPGL+x8BOGMusRTqYejKFSKw2DWH/nZ+Mf7In7fviDQPiN8Q9P8Yftnt8Ur R9K8KeANC+Ev7YOq6fpkngTXvGn7Uh8e3tl8H9V/a7+BHwU8SeIZ/CfjP4QQQ614v8e/D/4l+HdG 0zw/D8Hviz8LPHHhCy8U+GaXxC8K/ty+C/2b/wBmu2+JHh39pjTV+1+F/hj49+HXwf8A2ofEPg34 4eOZvFP7YfgSXRPCp+IHxB/bp+PWueH/AIq+PPglF4i0qbxFqH7cPjvTfC0Gq3Xh3Sv2iPBiz6Y3 h7+jOipw0FhsRhKt/bUsPn+EzyeGrxp1aNSnRw7weIyuNOcHShga9HEZli6dGrTr0KecZni8yr0M ZGpUwtVYiLr4WtQ56lKpPJMRk1HFU6lSOIpOpiXjKGNdZSVaWJo4ingqM506tCrUy7AYfBUa2FnC GKp/zFeM/wBlT/goz4s8baBaeP8AwB+198R/hZefCD9n/Svg/wCG9G/bc8LaTonwJ8d+GPj14w8W +On/AGwNA1P9qHQoP2ktbtf2e5/hN8PNb8RzwftSweKfil4H8W+KNPnk1LxBB8WdU+6Pj78K/wDg oRd/tG/sm+KrHxBqvxj0vwn8UdTvfGs3wZ0fx1+zR+zb4d+F2qeNfAclsnxc8L23/BWDwh478dfE bw74V0/xdKdd1/4CftlfCrxTHNpmlaf+z58NbuTxFf8Ai39jaK1pydLFYPFxcpVcFmOYZlT9rUqV oVa+ZYzE42rHExrTmq/sJ4n2GFxM74+jhKGGwzxk6dGKalTU6GJw7bUMTl+Gy6bgowdOhhsM8KnQ UIxhQ9vCVSricPTgsFWxdavjpYRYyvVrz/kt8V/s0/8ABZGP4keMr6Zv2xvGKj4p+MfE8el+EfiJ /wAI5+zz8StWHizxJJ4M8UXfi22/4OJvhD8ePAPw7sdC1OKDSfAXwa+B/wCz18LU0bUZbr4k/sf/ ABL8Q+E/h/pPhP7q8e/Bv/gpLf8A7X/xu8R/CaH4w+H/AAB4u1n4c6h4f8e/EX4xahD8NfDF3our /C77bp3wt8C6N+3z8Svh/wCIvhjAun+M77xNpur/APBPT9l34k6voFrJput+LfjBqmuarB4n/eii uejRVCll1GFSt/wmR5KFWVRuvUi55bKSxFXSdWUqeVYTCxqXjUoYGMsFhp0cK40o715/WKuYVZxg nmUZRxEFCMqUU/rMoeypVVUpx9nWxVbEpSjONTFylisRGtXnUqT/AJ69A/ZE/bK+I/hGy8N67H+3 f8Hfh/p2r634gl8HeMP+Ci3jW8+NerfFrSv2aPiToOoeNJvjd8GP2odc8VSfAXx/8cNV+Gup/D74 Of8ACztL8OaFrnhbVvEmvfBv4X+FNYl8Nr65+1v8H/8AgpL4v0L9m26fxD4x+L3w10X4s+GfEHx8 +Cv7HHi6+/Yx/aS1T4Pp8GfGGk+IfA+p/H/Vv20fBfhr4j+LW+NeofD7xSus/D7xP+zHYR+HfC/i jTYZ7+DXILC7/biit6r9tVxFRqMY4ivkWI+rQhH6lRnkWIdeEMNgpKWGoUszjHC4PNacKSjXy3L8 DluHWFwNB0J40oeyjho+0rTlhVm6hXqVqrxc/wC140FOVTGxlHGSq4KpRqYnL8Qq8cRRx2LxeY1q tfH1I4mn+MPgH9lj9tGT9lv4BfBjxH421HwF8PbXVfgzYePvhZ8P/Efjr4dftVeENEtfi5a6/wDF e68UftrfDT9qtNP8V6VqngR9W0/WNL+GXgTw345vJtRe60j4janqkGy7+T/h5+zx/wAFOdN1v9oa D4zH9rTx94A1T4hW+ueKvBvwq+NDfCrxH8ePDmn/ABa1nVbN/wBlj47eJP8Agr/8Q/EvwPu00GfR ruXwj4X+FP8AwTa8D+I/h+mqeF/EOnR6zDpXhtP6TqKiEXTqQqRqVHKGY4/Mkqs5YhVKmYQyWNTD 4n6x7V43CUKmR4fEYSljXiHh6+IxM4TssJHCU1zU1TblFRweX4KnKlKWHlQWXVsxrU8VhHhnR+oY 2v8A2lKlisVgFhqlWlhMIk4TjXniP5MrL9n79ujxr4S8GfGz4ReFP22/Hnj/AOIXgj4B3+reK4f2 r9Qm8AeJdY+Fk/7QPhHWvA/xv0/w1/wVN/YH+I2l6n4fvtT8E6nqvjH4ZD4h+ANagvdRvr/4V/F3 UCum+Hv1B/aA+Bn7aPivUtR0nxr4U+H37R2sfHDwLb/CCy+Inwa8I+GfgX4B/ZU0yw+LXhXx7YeL /HugfGr9oj4i/Erx0ttbLcaxdeL/AIMtq2v694q+GfgWC2+CvggTDxPY/sZRVUv3M6NSKTdHF5li owk5Spf8K2DngMdQVOUmqdKrhZeyVSlyYxL2svrbni8fLFRVpqth6mHk3GFXBZfgpypqEKjjleMo 5hga3PGN3PD4yjGtCjLmwaXLR+q+ww+EpYf8x/2P/g/8Y/Cnxkn1H4gfBzU/hjoPwd+Dnij4GW3j /WfEvwr1n/hpTV/EHxr1P4i23xR8Lab8NvE+va5pPhi3022uNdv4/i1onw98ZJ41+J3iiz0/wdJZ Wmo+Jdd/TiiipoxVHCYPBR1pYKGKjTlK3tJyx2ZY7N8XVqtKMZVK+PzLF1nyRhTgqip0qdOlCEI3 Jc+JxeKf8TGVMNOolpCCwmX4LK8NSpx3jTo4HL8LRXM5Tm6bqVZzqznORRRRVDCiiigAooooAKKK KACiiigAooooAKKKKAOQ+IPio+BfAXjfxuLD+1T4O8IeJfFQ0v7S1l/aR8PaNe6uLD7YlpfvafbD Z/Z/tK2N40HmeatpcFBC/wCKWh/8F0/hj8PfHXwC+FH7aHwQ8XfsxeO/2jtP+IPjDwJ4jbW9Ztfg 9oPwr+HLafb+IPiJ8UdR/a0+Hf7Ev7Q/wu02wvf+EpOoL4z/AGYNL0pPD3g3VvHmjeINe8BXemeJ bv8AdyilT5oV51JtVqMqLpxw84uMadT6vjoxxEalOUKjqrF1curOM5ToPC4PF4X2SrY+njcA6vLO hCFPmo14yrydeMozVT2ksF7CFSjUhKPs8PGjjU1TlTqVpY2EpVYrCwhV/P8Avf8Agor8ELD9nnwD +0HNf6ILX4t+IddsPg/8OT498GQfEH4vaD4a8VXdnrmpfDDTLvU7ez8ca5pnw9sL34mX+heH76+0 vTtFtZ31LxVZ+H4LjxZD+fnxB/4OMf2R/hf8Jpfjj4s/Z/8A2trn4WDX7fwbZeNfh/Z/sqfGXwxr vjb+3vA2jar4Y8NeJvgx+1d8QfDXiWPQrX4keD9cu/G+h6xf/C7V4NUPhnwj478SfEOzvPBUH9Ad eFfH79of4X/sz+GfDPj34zeNvAXwy+G2q+N9M8HeI/iP8TvHnh74b+B/BY1nR9fvNK1PW/FHiqey 0GAalrWk6d4a0+0v9T0z7bqmu2UNtdSXZgsrwg406t5v2kKub5dKhSqNRf1KcsHhK2UzqU1T9pWx 9WWJnRx0VRnhsZicJL2FbC4Srg8aOMp0qrSadHB5tiq86SvKMKOHxWMhWpU5qq3DLqVGk3h3GvWx tCliqKmsVisNXwXzf+yr/wAFHfgz+2X8D/jN8aPgj4W8fXc/wY8W/GXwRqPwt12T4e3fxN8U698G Jriw1Ofwtofw28ffEq1vdC8Wa1bvo3grUZr+C81m7wf7JgSW1+0/Efh3/gvB8CdL+HeqeM/iVpXw t8c3uj/GXWvg7qc37En7SHhf9oP4bWOt6T4A8B+Pl0zSvid+0d4N/YXi+MnxCuLHxzHFJ8Lf2WvD H7Qvii1g0rVLxzJLoXjOw8IbfwT/AOC9f7DH7QFv4i1H4ZeHPiXqfxKtPjTffs5eEfhfd3v7OGnf Fj4yeKNC1m60+9u/hRDL+0CdB8U+ANI1G80a71PxFfeLNH03w9Z+OvCGs65Fpen+JrW8b2v4E/8A BYn9kf48/Bvxf+0DFrEnwP8AhD8M/wBq7xZ+yP8AFHxt+0r4x+E/wt8PeDfG/hLRJ9Rm8QT+KdM+ IXjXwS3hvX9Vl0HQPCx1jxX4f1PWbvXrKVbGD7RpcGrFKLksMpOpL63keTYmlJKNKVWoszybCYjN aEp03CNLN6mZYfL55fVp1ZZficypOjUjPB1I1FzKDrxmnNYHMs3+sunfn+qxynM8dDLakIqqlisq jlWOxuExVC7zLC4CtCpha88VRWH+bvi3/wAHDH7JXwI0r4j3vxb+C37Q/g7WfhFN4BsPiV4Ek8X/ ALD/AIg+Ivg/WviF8T/Enwo0/R9X8FeEv2ztf12KTRNe8L3ur+I9ajtZPCdj4Uv/AA7rtp4h1CPx NoMOoe9eHv8AgrR4K+InwM/az+JPwz+FVq/j/wDZP+F2h/ELXvBPxb/aL/Zu+E/gDxHf+ItK1fUd H0LWvi6nxG8aP8ALHUJNFuf7O1n9qH4ffBbUNY0K90XxvovhnUvBGpp4gi+VPCn/AAcrfsPeK/iW PhJafC39pWLxZH8RvAHwsn1S80f4HeHPAc/iX4ifC/xH8WNF1TRvFnj747+CX1XwTF4e8LalBdeL jo9nZrcXfh/UUt38N+J9A13UP0c+DX/BQ74a/tIfsT+Gf22PgJ4B8dePdF8X6P4d1fQPgnPrnwm0 T4yzzeJfG1v4N0jwvqSr8SdU+GHhzxfrckwvtAs/E3xL0fw5Otxp6eIfFXhe0l1HUdJzTlXy7G4i lKfuxk44yhRlOGF/t3LMDnGQeyws41Z4ieGwcMViaEJTqyxmDxtPD4qKxmFjiasKXscwwuEq1Kcq yn7SrhK1oLE0cuzF4HHRlXhOksPTrS5sNXrKceXEwWLwkqWGjPDS/PX4ff8ABw3+zj448X+CPhRp vwn8b+Nviz4j+CnhT46ahD8IfGfw9v8A4Ral4W8X3+saBY2Xwz+KH7Qer/sx63rlzZ+JrLTbLUfE fxg+GvwB+HcOg6hL40h8bT+GW8O33ija+K3/AAcYfsIfCzwn8HddfQPjP468Q/GXVPDfhy38CfDK 0+EPxK8QfC3xR4y0rxXrnhTRfjRd/Dz4w+LdC8Jya/ofhYeJ9Fl8N6n43l8T+CNe0Pxz4ItfFfhW TUNU0/zz47/8F0f2Pb/xB8WP2Nv2nf2Mfifc+P7XwLe638QPgL8e9b/YWuPhDfaBL8SNZ8B6J4b+ KHjnx3+05c/Bm1vbjW9C0m51fSbi98UabJquteHvDPw8u/ib4y1zwfoniX1zwr/wWw/Zb8HfHD9l /wDYj8OfszfHn4aeKfjlD4R8PfArw7a+Bvhtpvwm8KfDUaL8O7zQL3VdR+G3jbxTo/gzRo/AvjPT NV8J+E/DOka4dE0mDQtK8fxfC651iC0sOuly169F06cZU8bm+Jo4GlQq8/1uOVZjnGZ5vlmGqyct cNkOHjlkcYvrjxFTAVM0pezqUq+Fx0yksKqkcTKblgMvw9XMHWg6MqClhMvwUcfiYQppRjjM2xUc Z7NLCU8HSrwwKWJVaOLwf1r+z3/wU8+Cv7QPxm0D4FxeBviF8KfG3iv4WaX8XfCtv8UvGH7NEd54 h8L+IP7HufDLWfgb4e/tCfEL4u6fH4q0TXLHXfDXiHxF8NtD8E6uIdZ8KQeKh8RvDPifwVo3kv7Y /wDwWs/ZF/Yo+IugeAPHn/CR/FE+IPiTonwUn1L4DeIfhN45uPAvxkv9L8Ua/rHw7+KWja/8SfBV 34M1/QdB0jw5qE+kwS674lJ8ceHY9R8OaRDqWiXWt8/+1z/wWK+Dv7GUPjrxj+0V8GfFVp8Mvhr4 8t/BOhatoniHwTe/Enx94rufiXP8Mh4z+FXgLx9dfD/w14g+GHgwXUEHxY8bW/xRs/GHw48Q+INE 0CT4d634a8SaV44vvKPiV/wcM/srfB6+8Cr8SPgb+0joOkfE7xh4S8D+A72xn/Zt8UXeral4z0DX /Fuga7eR+Fv2idX8P2HhjWPDWmaVd6faReKb/wCJmmarrtroPjz4ZeBtQl0ca7x05rEYbBYilOo6 NbHLDxr0qUnPGzlmuT1IYKiqlOcYYitgM4w2X4dRoVJ1qWNwOb0o1oYfFxxO1OlUw2JrYPFKeIxG HwtZV6fKqM4V8DQxmXZhiqUacZxq4ShmlChi6lSE6tGjUdfLalTlxOCrw6v4pf8ABeX4A/AiH4Yp 8c/2V/20PhRrPxd+M0/wS8G6Drmgfsx+JpX1+01fxx4Z1DxFrviT4a/tTeOvAPhrwlYeLfhz4x8N 3Fzrvi+w155NEvfEtr4eufAlvceLIfUm/wCCp2qfFP8AZt/Y+/aR/ZG/Zn8W/GXTf2wrnXZ/CXgL x7qvxB8L+L/Dui6Dqv8AYDy6/e/s1/A/9svwf4Yvr7WnhtD4j+KXib4W/AvwpHPFL8Tfjl4Bnkit JP0R+AXxmt/j38MtN+I8XgHx38Lbq61vxj4Z1n4e/Ex/Ac3jfwn4g8C+L9b8F69pWu3Pwv8AHXxM 8AXcseraDdzWt34W8d+JNMubGa1mW+Wd5raD2auvldKVeNaEJz/tDL69H2c/3VPLsPSpxxuBlKM6 v1meZzjOt/aFOrSWGjW5cLQ5IwkuWnJ14Up0sReKweY4as1TScsxqYmvHD4uMZJOgsrjyYWWAqRq +3q4ec8TVUpypx/GL4d/8FrvgZ8SPjNo/wAMtO+FHxE0Xw3e+JbvwP4g+Imq+NfgTrmg+APFNt4j 0jRGuPiPrvw3+Kvj/wCFvw48MWkerwW+uWfxD+LHhL4xeHvHtzoPwa1P4LR/F3xn4L8G+IP2Wtrm 2vba3vLO4gu7O7giubW6tpY57a5tp41lguLeeJnimgmidJIpY2aOSNldGZWBK3Ntb3lvcWd5bw3V pdQy211a3MUc9vc286NFPb3EEqvFNDNEzRyxSK0ciMyOpUkF8cccUaRRIkUUSLHHHGqpHHGihURE UBURFAVVUBVUAAACs4WVJQledWPsP3zaTny4ShRr88IpQTq4qjVxkORRVN4uph7SpUaHL0VLuu6l N8lGftr0H7ypfvufD+zqP95O1KpOjW9q3f2FCpBKVSvd9FFFIYUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFVobKzt57u6t7S2gub+SKW+uIYIop72WCCO1gku5kRZLmSG2i it4nmZ2jgjjiQiNFUWaKACiiigArlPBngTwP8ONDj8MfDzwb4U8B+Gobq9vovD3gzw7pHhfQ4r7U rh7zUbyPSdDs7GwS6v7uSS6vbhbcTXVxI887ySuzHq6KFo21o3FwbW7hKUJuDe/K506cnHZyhCTV 4xaHqlF6xU1USeqU4xnCM0tlOMKtSCluo1JxTtOSZRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAf/9mqVI1Jwq0q+a5fiYZc6deGY4fMVUoyjhoKvRt0a9H+0MBVk3mVP28qU5Ut MJDA1p0MfUeHhJRxuHoYrD1sPVr060aWHU6dGpVlXqUK9Sr4y/4OPP2Gfhh4o8J+Evi78M/2rfhb qHi3wEfilDe+I/ht8PNc0PSPh5B8KfDfxp1LxPq2ufDz4v8AjbTZBpHw/wDF3h3Ub/w7ok+s+MDq GraboNl4dvNa1LTbG8+5tX/4KANf+D/h38SvhT8DvFHxI+H/AI0/Zv8Ahl+1rq0k3irR/C3jvwz8 DfG2sWreKdXh8GNYa7ZeJvFvgPwTPL4sPgvR/FZ1DxbfWkvhTQLlr+azu7n6y+AXxmt/j38MtN+I 8XgHx38Lbq61vxj4Z1n4e/Ex/Ac3jfwn4g8C+L9b8F69pWu3Pwv8dfEzwBdyx6toN3Na3fhbx34k 0y5sZrWZb5Z3mtoPZq0nTqU5UYzlF1cPUc6ijySw+LiqWeqlTrckpydCVXG8P1qs8FicPUrUsjxc MPXw/wDbftctarUMRKtUw6ccLWpwopKTeJwlajictjjKmGq1IezhWcMLnWGhSx+DxkMLXzDC1KtL EPKqtHMfxT1H/gtt8FX8MeCviT4Q+Evjvxz8LfFGp3Wl3viHwh4v+GHj/UrRrDXPG+hahq/hzUfg /wCK/il8FfGPhDTpfCCahrvj2x+OVj4F8DaTP4jvPid4j8CN8PfG8Okfsvomu6J4m0mw17w3rGle INC1SBbrTNa0TULTVtJ1G1Ysq3NhqNhNcWd5AzKyrNbzSRkqwDEg1q1Ws7Kz061gsdPtLaxsraMR W1nZwRWtrbxL92OC3gRIooxk4SNFUZ4FWnFYeFOUL11iMVVniFJpTo1pxnh8MqOsYxwceelTqqTq Vqbg67qVYSqzhxqPESq+0SoSoUaawyguWFak5+0xEarbqOWIUo+1pycqUZU4uhGinOE7NFFFQaBR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVWhsrO3nu7q3tLaC5v5Ipb64 hgiinvZYII7WCS7mRFkuZIbaKK3ieZnaOCOOJCI0VRZooAKKKKACuU8GeBPA/wAONDj8MfDzwb4U 8B+Gobq9vovD3gzw7pHhfQ4r7Urh7zUbyPSdDs7GwS6v7uSS6vbhbcTXVxI887ySuzHq6KFo21o3 FwbW7hKUJuDe/K506cnHZyhCTV4xaHqlF6xU1USeqU4xnCM0tlOMKtSCluo1JxTtOSZRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBLAwQUAAYACAAAACEAbsIjXtgAAAB4AQAAEQAA AHBwdC9wcmVzUHJvcHMueG1sjI/NTsNADITvSLxD5Dvd0EqoRNn0QJQbUg/wAGbjJCvtn+xtC2/P 8ieKuNQnW6NvPNPuXr2rjsRiY9Bwu6qhomDiaMOs4flpuNlCJRnDiC4G0vBGArvu+qpNTWISChlz QfdcFaMgDWpYck6NUmIW8iirmCgUbYrsMZeTZzUynsoD79S6ru+URxvgm+dL+DhN1lAfzcGXAF8m TO4ziSw2yY9busTtvMefSF0paRw/8qFrsRGeXx4cV0d0Gjb9tr/fgPonDENd5kNQv3BZz5/suXsH AAD//wMAUEsDBBQABgAIAAAAIQCXIPj9nQEAAOcDAAARAAAAcHB0L3ZpZXdQcm9wcy54bWzEU81P wjAUv5v4PzS9y8ZUHAvDxBhPHkxA7037GE22tumrOPjrfd1ABuHAzRN9X7+P98bsuW1qtgGP2pqS j0cpZ2CkVdpUJf9cvt3lnGEQRonaGij5FpA/z29vZq7YaPj58IwADBai5OsQXJEkKNfQCBxZB4Zq K+sbESj0VaK8+CHgpk6yNJ0kjdCG7+f9NfN2tdISXq38bsCEHsRDLQKJx7V2eEBz16A5D0gw3fSJ pDmZM1F2/dVbpP2EF+EX1EsraESrG70DxWMjgQTrQb3DKjDc0Q4fJ1nKk2FtaV1Xmj5MJl0pOSWI vVhrBT1fDOWiVoPo+EQpapjPRIEtixcb08UU/aYdMKW3F9LEt59zhfW60oa1Jb8b399nnG3ja5pH ydQnj1TVN0l6xxD1dG9Gs7QxWq71O86cxZJn497SoaVP5vnB5xEkgg9cRU2nno0NgEtow1HCQM25 cTJ8yfhpOpL0Cxsap0kyfVD4x0HNFySg9QH8/0k656+8VgsnJP2RmKQrPuVpRusmT5JM/UX9NTfd Bzz/BQAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54 bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fqASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AES ujXdpAcGj3uDY0DWcd1xabRgsAoLebbfpTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR 3G25DKRb+HvTlSSB5x2J4pMG1ImewTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD/ /wMAUEsDBBQABgAIAAAAIQAfSemJhAEAAOkCAAARAAgBZG9jUHJvcHMvY29yZS54bWwgogQBKKAA AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8kktLxDAYRfeC/6FkpYtOkgqjlk4EFReiUHBE cReSzzHaPEiidf69aWZaFR8QKO13enpz0+bkXXfFG/igrFkgOiOoACOsVGa1QLfLi/IIFSFyI3ln DSzQGgI6Ybs7jXC1sB5abx34qCAUyWRCLdwCPcXoaoyDeALNwywRJg0frdc8plu/wo6LF74CXBEy xxoilzxyPAhLNxnRVinFpHSvvssCKTB0oMHEgOmM4k82gtfh1xfy5AupVVy7tKdt3K9uKTbDiX4P agL7vp/1BzlGyk/x/fXVTd5qqczQlQDEGinqqGIHrLU9+NYqE4vWQ0iJeUxlN3giBlZ44NF6dsl1 qrK13Uux96xduu5ncpwPvXc8xOt0RI8K5OmabbAG/5wMsIc3NRwuo9VxZqYHo6r1KRtIRueElnkt CanzepisI5Sy5ho3gUEWqZh6U+M4uTs4O19eoD98I5U3lL46CfV2R/8YK0KrkhyWlCzpvCbHNalS wtE4ClgO/f3nZB8AAAD//wMAUEsDBBQABgAIAAAAIQC4x437ygIAAKAHAAAQAAgBZG9jUHJvcHMv YXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxVS3PaMBC+d6b/QeNT eiACQ9IMI5ThMZkw0wSmmPQs7AU0lSVXEuTx67u2ebl121CfVruf1qtvX+z2JVVkC9ZJo3tB67IZ ENCxSaRe9YJ5dNe4CYjzQidCGQ294BVccMs/fmBTazKwXoIj6EK7XrD2PutS6uI1pMJdolmjZWls Kjwe7Yqa5VLGMDLxJgXtadhsXlN48aATSBrZwWFQeuxu/f86TUycx+eeotcMA+YsgjRTwgNn9ChG xgsVyRR42LwJ0XI4s2/GJo7ffL5mtBRZP8uUjIVHnviDjK1xZunJpHgRmZpnsFMjtWf0FIgsgcOn FtfuCib4RDdcbAE0ma3NM7nodNufGK0BsqmwYmVFtsZI2gg5HtlMyQQcb3UY3Yns0fhcw2gpsHuZ JKB31iajlTN7eBgqmTmOhr3IZrFQMETe+FIoB+j6oGD3IPKamAppHWdb391C7I0lTr5hVVwHZCEc 5Gz3gq2wUmiPrOew8lDIKnPe8jujvSNzBwmjCCiVhXiKPZVlh+PzEYvCX4GlrwjrD4N/t2+k7N2+ CzpJJL0Cd84vME91/8iVJZH4sCrF5T8mS8y6r2G8hX15pLx4eEl4yUEfU6BOAzywMRRKLqyst5mN lWDJIzzX2kewFBvlyQicXOlayAxcPkoa4xH5Cj820mIu8nzjGCBj7cHKtFEmc5f4Q2BjpTZYH9gq ekX8Ggh28EJB2iV9bDwgOIPIwCzIVgoyCAfzPkGXs8GwNoz+CoeKqDWdRIhF2Iixbh25aNEOduEh mLx0ywDr4eF58PZ58M474BV2Mfyrf4ZfvRGefaN99o3O2Teu/nRjgtuEjJ3blMkK619bQYW0iqo0 2y/t9UXq726eRWaUL4nd+Ksq2WwtLCS4vfb2o4Ld4+SzKncyXAu9gmSP+d2Qb5KncuHyVnjZxK9Y Gntdvgv2q5X/BAAA//8DAFBLAwQUAAYACAAAACEAZRbrG+wAAABdAQAAEwAIAWRvY1Byb3BzL2N1 c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACckMFuwyAQRO+V8g9o 7wRM6ja2MFFiJ+ce0twRxglSAMsQq1bVfy+W235Ab7ua1ZvZ4bsPe0ejHoLxroJsTQFpp3xr3LWC 9/MJbwGFKF0r797pCiYdYCdWT/xt8L0eotEBJYQLFdxi7EtCgrppK8M6yS4pnR+sjGkdrsR3nVG6 8ephtYuEUfpC1CNEb3H/h4OFV47xv8jWqzlduJynPsUV/Ac+oc5G01bw2eR10+Q0x+xY1Dij2QEX m+IV0y2l7MDqU7E/fgHq52MGyEmbXr8sLSXeGEvzLDJOloGTXwPByey89CK+AQAA//8DAFBLAQIt ABQABgAIAAAAIQCRtStyigIAAPkUAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10u eG1sUEsBAi0AFAAGAAgAAAAhAEe/GtATAQAAdQMAAAsAAAAAAAAAAAAAAAAAwwQAAF9yZWxzLy5y ZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAABwgAAHBwdC9zbGlk ZXMvX3JlbHMvc2xpZGU2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAA AAAAAAAAAAAABAkAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU1LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAAAQoAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU0 LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAPCqnDPYAAAAzgEAACAAAAAAAAAAAAAAAAAA/goAAHBw dC9zbGlkZXMvX3JlbHMvc2xpZGUzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADMOHgTBAAAANwEA ACAAAAAAAAAAAAAAAAAAFAwAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUyLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAAAAAAAAAAAAAAAAEw0AAHBwdC9zbGlkZXMvX3JlbHMv c2xpZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAA Eg4AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU3LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/ AAAANwEAACAAAAAAAAAAAAAAAAAADw8AAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGU4LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAAAAAAAAAAAAAAAADBAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGU5LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEAACEAAAAAAAAA AAAAAAAACREAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxNC54bWwucmVsc1BLAQItABQABgAIAAAA IQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAAAAcSAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMTMu eG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIQAAAAAAAAAAAAAAAAAFEwAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTEyLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAEv1Pey/AAAANwEA ACEAAAAAAAAAAAAAAAAAAxQAAHBwdC9zbGlkZXMvX3JlbHMvc2xpZGUxMS54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBL9T3svwAAADcBAAAhAAAAAAAAAAAAAAAAAAEVAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlMTAueG1sLnJlbHNQSwECLQAUAAYACAAAACEALfEhHIQBAAA4CwAAHwAAAAAAAAAAAAAA AAD/FQAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQItABQABgAIAAAAIQC0ChyP 7wIAALgPAAAUAAAAAAAAAAAAAAAAAMgYAABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQABgAI AAAAIQA0AvVZGwMAAMYKAAAVAAAAAAAAAAAAAAAAAOkbAABwcHQvc2xpZGVzL3NsaWRlMS54bWxQ SwECLQAUAAYACAAAACEAn2lEQmwDAADvCwAAFgAAAAAAAAAAAAAAAAA3HwAAcHB0L3NsaWRlcy9z bGlkZTEwLnhtbFBLAQItABQABgAIAAAAIQBfgK+gIwMAAAwJAAAWAAAAAAAAAAAAAAAAANciAABw cHQvc2xpZGVzL3NsaWRlMTEueG1sUEsBAi0AFAAGAAgAAAAhAM8/YcbQAgAA5wkAABYAAAAAAAAA AAAAAAAALiYAAHBwdC9zbGlkZXMvc2xpZGUxMi54bWxQSwECLQAUAAYACAAAACEAdRF1dGEDAADc CAAAFgAAAAAAAAAAAAAAAAAyKQAAcHB0L3NsaWRlcy9zbGlkZTEzLnhtbFBLAQItABQABgAIAAAA IQAgORZ8FwIAABAFAAAWAAAAAAAAAAAAAAAAAMcsAABwcHQvc2xpZGVzL3NsaWRlMTQueG1sUEsB Ai0AFAAGAAgAAAAhANSTE7ozAwAA8wgAABUAAAAAAAAAAAAAAAAAEi8AAHBwdC9zbGlkZXMvc2xp ZGU4LnhtbFBLAQItABQABgAIAAAAIQDVWZdMygMAAKQMAAAVAAAAAAAAAAAAAAAAAHgyAABwcHQv c2xpZGVzL3NsaWRlOS54bWxQSwECLQAUAAYACAAAACEAg3kxfxsHAAB+IAAAFQAAAAAAAAAAAAAA AAB1NgAAcHB0L3NsaWRlcy9zbGlkZTIueG1sUEsBAi0AFAAGAAgAAAAhAMV1A4LXAgAAXQkAABUA AAAAAAAAAAAAAAAAwz0AAHBwdC9zbGlkZXMvc2xpZGUzLnhtbFBLAQItABQABgAIAAAAIQAU77eP gAMAAM8JAAAVAAAAAAAAAAAAAAAAAM1AAABwcHQvc2xpZGVzL3NsaWRlNy54bWxQSwECLQAUAAYA CAAAACEAjMsLg8YCAACHBwAAFQAAAAAAAAAAAAAAAACARAAAcHB0L3NsaWRlcy9zbGlkZTQueG1s UEsBAi0AFAAGAAgAAAAhAD6DMG7CAgAANgcAABUAAAAAAAAAAAAAAAAAeUcAAHBwdC9zbGlkZXMv c2xpZGU1LnhtbFBLAQItABQABgAIAAAAIQCYoL/UKAMAABUJAAAVAAAAAAAAAAAAAAAAAG5KAABw cHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAA AAAAAADJTQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHNQSwEC LQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAADRTgAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDcueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAADZTwAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAADhUAAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDUueG1sLnJlbHNQSwECLQAUAAYACAAAACEAFzzt atUAAAC/AQAAKgAAAAAAAAAAAAAAAADpUQAAcHB0L25vdGVzU2xpZGVzL19yZWxzL25vdGVzU2xp ZGUxLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAABlMA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhANXRkvG+AAAANwEAAC0AAAAAAAAAAAAAAAAADlQAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMv c2xpZGVMYXlvdXQxMC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAA AAAAAAAAABdVAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAMGEnJ/EHAABeNgAAIQAAAAAAAAAAAAAAAAAgVgAAcHB0L3NsaWRlTWFz dGVycy9zbGlkZU1hc3RlcjEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAA AAAAAAAAUF4AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsB Ai0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAAWF8AAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEA ACwAAAAAAAAAAAAAAAAAYGAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhAIlAFM59BAAAdxEAACEAAAAAAAAAAAAAAAAAaGEAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbFBLAQItABQABgAIAAAAIQCiBaa5uQQAAAgSAAAh AAAAAAAAAAAAAAAAACRmAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0OC54bWxQSwECLQAU AAYACAAAACEA9Y7UmncCAACtBgAAIQAAAAAAAAAAAAAAAAAcawAAcHB0L3NsaWRlTGF5b3V0cy9z bGlkZUxheW91dDcueG1sUEsBAi0AFAAGAAgAAAAhANRhuEa9AgAA/wcAACEAAAAAAAAAAAAAAAAA 0m0AAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQAdcvXC OgUAAH0bAAAhAAAAAAAAAAAAAAAAAM5wAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54 bWxQSwECLQAUAAYACAAAACEARgOhpOEDAACuEQAAIQAAAAAAAAAAAAAAAABHdgAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhADOG1KkVBAAASA0AACEAAAAA AAAAAAAAAAAAZ3oAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbFBLAQItABQABgAI AAAAIQDy/gibLgMAANwKAAAhAAAAAAAAAAAAAAAAALt+AABwcHQvc2xpZGVMYXlvdXRzL3NsaWRl TGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEAqhoXns0DAAD0DAAAIQAAAAAAAAAAAAAAAAAoggAA cHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEueG1sUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAAAAAAAAAAAAAAAANIYAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQy LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhADS7K+tIAwAAEwsAACIAAAAAAAAAAAAAAAAAPIcAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEAVLKurZADAADz CwAAIgAAAAAAAAAAAAAAAADEigAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDExLnhtbFBL AQItABQABgAIAAAAIQCC6rT0XAIAANgFAAAfAAAAAAAAAAAAAAAAAJSOAABwcHQvbm90ZXNTbGlk ZXMvbm90ZXNTbGlkZTEueG1sUEsBAi0AFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAAAAAAAAAAAA AAAALZEAAHBwdC9zbGlkZU1hc3RlcnMvX3JlbHMvc2xpZGVNYXN0ZXIxLnhtbC5yZWxzUEsBAi0A FAAGAAgAAAAhAHSxSKNgBgAAMhsAABQAAAAAAAAAAAAAAAAAlZIAAHBwdC90aGVtZS90aGVtZTIu eG1sUEsBAi0AFAAGAAgAAAAhAGGhMNBRBgAAbSIAACEAAAAAAAAAAAAAAAAAJ5kAAHBwdC9ub3Rl c01hc3RlcnMvbm90ZXNNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQCEUtNrqAsAAGNCAAAUAAAA AAAAAAAAAAAAALefAABwcHQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQC0z1gZuwAA ACQBAAAsAAAAAAAAAAAAAAAAAJGrAABwcHQvbm90ZXNNYXN0ZXJzL19yZWxzL25vdGVzTWFzdGVy MS54bWwucmVsc1BLAQItAAoAAAAAAAAAIQCFHqISAEAAAABAAAAXAAAAAAAAAAAAAAAAAJasAABk b2NQcm9wcy90aHVtYm5haWwuanBlZ1BLAQItABQABgAIAAAAIQBuwiNe2AAAAHgBAAARAAAAAAAA AAAAAAAAAMvsAABwcHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQCXIPj9nQEAAOcDAAAR AAAAAAAAAAAAAAAAANLtAABwcHQvdmlld1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQDY/Y2PrAAA ALYAAAATAAAAAAAAAAAAAAAAAJ7vAABwcHQvdGFibGVTdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAh AB9J6YmEAQAA6QIAABEAAAAAAAAAAAAAAAAAe/AAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAG AAgAAAAhALjHjfvKAgAAoAcAABAAAAAAAAAAAAAAAAAANvMAAGRvY1Byb3BzL2FwcC54bWxQSwEC LQAUAAYACAAAACEAZRbrG+wAAABdAQAAEwAAAAAAAAAAAAAAAAA29wAAZG9jUHJvcHMvY3VzdG9t LnhtbFBLBQYAAAAARQBFAIUUAABb+QAAAAA= --=====================_1890830523==_-- From christer.holmberg@ericsson.com Tue Jul 10 12:51:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF8111E8132 for ; Tue, 10 Jul 2012 12:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snYdZsplBYNv for ; Tue, 10 Jul 2012 12:51:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C40011E812C for ; Tue, 10 Jul 2012 12:51:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-91-4ffc87e492dc Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FC.7B.07365.4E78CFF4; Tue, 10 Jul 2012 21:52:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 10 Jul 2012 21:52:04 +0200 From: Christer Holmberg To: "'Paul E. Jones'" , "'Olle E. Johansson'" , 'Paul Kyzivat' Date: Tue, 10 Jul 2012 21:52:03 +0200 Thread-Topic: [Insipid] Use case for association of session signaling and media flows Thread-Index: AQEnxsoIGcdTmWb5fTF6thkm/Fi0agGq2bnqAcX6I+8CtDlaLJg75g+wgAEOpiA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534071B990E@ESESSCMS0356.eemea.ericsson.se> References: <4FF701F7.8070202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> In-Reply-To: <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvre6T9j/+BovblCzm33/GZPFy9SFm i/MXNjBZrNhwgNWBxePv+w9MHtPWrmT1WLLkJ5NHw76j7AEsUVw2Kak5mWWpRfp2CVwZL789 Zy5YLFux4apvA+Mk8S5GTg4JAROJ+X+XMUHYYhIX7q1n62Lk4hASOMUo8W3FZShnLqPEhouL gKo4ONgELCS6/2mDNIgI1EssenueFcRmFtCUWLH4NjuIzSKgKtF2dBMjiC0sECbROXMTK0ir iEC4RO8Cf4hWP4lnGxczg9i8QOGLm/5ArdrCJHHz2CE2kASngK3ErJMXwGYyAh33/dQaJohd 4hK3nsyHOlpAYsme88wQtqjEy8f/WCHqRSXutK9nhKjXk7gxdQobhK0tsWzha6jFghInZz5h mcAoNgvJ2FlIWmYhaZmFpGUBI8sqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzACDu45bfuDsZT 50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwCjvefWehnOi0+0LLpmb I9vm8qrOezyd0fHrzzbF27YeIUv3fOmddNM1R4Bjzvwt9zP+X3ixQ8NvatrCCZapd7zN/so+ Fq1/dUtb06QiNkHe+t7TjO7tzJ9LzVcEyyVV7lXeJzXbk1+9aGXziwyl2tDMT0tTD6//Offt 7ofX21dE2NkHMdzbPkmJpTgj0VCLuag4EQBr3lEefgIAAA== Cc: "insipid@ietf.org" Subject: Re: [Insipid] Use case for association of session signaling and media 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: Tue, 10 Jul 2012 19:51:39 -0000 Hi,=20 >The mechanisms certainly are our of scope. All I was hoping for at this p= oint was to ensure that we do not make it difficult or impossible to one da= y associate media and signaling by making a poor=20 >choice in how we construct the Session-ID. But, how would you be able to determine whether the requirement has been fu= lfilled? Regards, Christer > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On=20 > Behalf Of Christer Holmberg > Sent: Monday, July 09, 2012 5:13 PM > To: 'Olle E. Johansson'; Paul Kyzivat > Cc: insipid@ietf.org > Subject: Re: [Insipid] Use case for association of session signaling=20 > and media flows >=20 >=20 > Hi, >=20 > I think there are cases where it would be useful to explicitly=20 > associate media and signalling, and if the session-id somehow can be=20 > used for that - fine. >=20 > However, isn't such mechanism outside the current charter of INSIPID? >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On=20 > Behalf Of Olle E. Johansson > Sent: 7. hein=E4kuuta 2012 11:21 > To: Paul Kyzivat > Cc: insipid@ietf.org > Subject: Re: [Insipid] Use case for association of session signaling=20 > and media flows >=20 >=20 > 6 jul 2012 kl. 17:19 skrev Paul Kyzivat: >=20 > > On 7/6/12 5:48 AM, DRAGE, Keith (Keith) wrote: > >> (As WG cochair) > >> > >> We have taken out the text: > >> > >> " * Association of session signaling and media flows, made possible > >> by including the session identifier in media-related messages > >> (e.g., RSVP or RTCP)" > >> > >> In order to keep text that has full consensus as a working group draft= . > >> > >> That however does not mean we have consensus not to include it. > >> > >> So I would like people to discuss this use case and whether there=20 > >> is > merit or not in such a use case. > >> > >> I would also note that we need to expand both this text, and the=20 > >> text > the originally surrounded it, into some more complete text about a use=20 > case, and maybe one of the ways forward in this discussion is for=20 > someone to do this. > > > > I have an open mind about this one. But I have questions about it: > > > > Is the thought that there is already a suitable field in RSVP, and=20 > > one > in RTCP, for carrying this? Or is this implying that extensions should=20 > be made to those to carry this data? > RTCP has application specific fields that can be used for this type of=20 > data, like the APP packet type. But that may be seen as misuse. There=20 > is an IANA registry for new fields. Or... Hmm. >=20 > According to RFC 3550 there should be a registry for RTCP packet types=20 > at IANA, but I can't find it. >=20 > /O >=20 > > > > If the thinking is that extensions are needed, then I think we=20 > > should > rule this out of scope. > > > > If the intent is to use existing fields, then they should be spelled > out, with whatever limitations those would imply on this work. > > > > Thanks, > > Paul > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid >=20 > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden >=20 >=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Jul 10 19:38:24 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFD821F85A2 for ; Tue, 10 Jul 2012 19:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_31=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 P5fQkIZ4hccZ for ; Tue, 10 Jul 2012 19:38:23 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7831821F85A0 for ; Tue, 10 Jul 2012 19:38:23 -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 q6B2coi1021024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 22:38:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341974331; bh=7qb8fkSyTtDLrmqSoqLFkTzFTWxH+ccS1yAdYDj2kV8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=U7q9F+Lah6+YqCbrInciaceDWDRwW6nysq5jWH+V4RGsjVEiwglw/dedkNQi3x6JQ k+eBgZApKco9JgDqoybGL8okUglM3LEZNgYqQp2hRG67qih1pnxP+7qv+kGTMwwdHm hihJU+0b8wGJqgbdKxkI74gWNI33FKWOiE9JH9Rs= From: "Paul E. Jones" To: "'Laura Liess'" References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> In-Reply-To: Date: Tue, 10 Jul 2012 22:38:56 -0400 Message-ID: <0dcc01cd5f0e$521437d0$f63ca770$@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: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAAIZ3s8FAiAEuxoBrzjzyAH42j74AfwUrrMCenXM8Zhk4HZQ Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 02:38:24 -0000 Indeed, you're right. It does cover both, but folks called for a separate requirement. What is the wishes of the WG on this? Shall I replace REQ1 with the below text? Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Laura Liess > Sent: Tuesday, July 10, 2012 8:23 AM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use > case > > Paul, > > > > > What was proposed (by you?) was this: > > > > REQ1a: It must be possible for an administrator or an external device > > which monitors the SIP-traffic to use the identifier to identify those > > dialogs, transactions and messages which were at some point in time > > components of a single end-to-end SIP session (e.g., parts of the same > call). > > [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is > in draft-ietf-insipid-session-id-reqts-00). So I think we could replace > the current text of REQ1 by the proposed text of the REQ1a and then drop > REQ1a. > > Thanks > Laura > > > > > > > > This is not presently in the draft that we just submitted to be a WG > > document since I was told to base that document on the -03 draft. I > > had that text in my pending -04 draft, but ... it is still sitting > > there :-) > > > >> > You really want to just remove that text from c)? > >> [LL] No. I don't. > >> Also in this scenario the service providers monitors and logs all > >> B2BUA traffic, incomming and outgoing. There is no log provided by > >> the customer. > >> > >> From my point of view, the text would be : > >> > >> -------------------------------------------- > >> User Agent A (A) and User Agent B (B) communicate using SIP messaging > >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service > provider. > >> For privacy reasons, the B2BUA changes the SIP headers that reveal > >> information related to the SIP users, device or domain identity. The > >> service provider uses an external device to monitor and log all SIP > >> traffic coming to and from the B2BUA. In the case of failures > >> reported by the customer or when security issue arise (e.g. theft of > >> service), the service provider has to analyze the logs from the past > >> several days or weeks and correlates those messages which were > >> messages for a single end- to-end SIP session. > >> > >> For this scenario, we must consider three particular use cases: > >> > >> a) The UAs A and B support the end-to-end Session Identifier. > >> > >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. > >> > >> b) Only the UA A supports the end-to-end Session Identifier, the UA B > >> does not. > >> > >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > >> > >> c) UA A and UA B do not support the end-to-end Session Identifier. > >> > >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > >> ----------------- > >> > >> > >> What do you think? > > > > > > Sounds OK to me. I'll put this into me -04 draft and when folks give > > me the green light, move it into the WG -01 draft. > > > > Paul > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Jul 10 20:04:37 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7551321F8555 for ; Tue, 10 Jul 2012 20:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 2GKiye9n8ATd for ; Tue, 10 Jul 2012 20:04:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDAB21F8554 for ; Tue, 10 Jul 2012 20:04: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 q6B34ujN021640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 23:04:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1341975898; bh=92f43UpSfVRJqABn07KW+zC1SNmH1Y6YuF9LdS4GPyY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=g0//+M3onTBZEjiO3NOu04EduGp1NumfTG+tUglEtRZ84KYaikkp91yAlSLcxoiK0 KfLeGUAtqGPjL88iETu0/OzA8lrZDIYafYurLSSIhvtx8TQkgmc+/Uu8Bv/+2pNHXZ liUhwtb0E2YZGump2v+9hbx7s98yHHzlhjFNpbMs= From: "Paul E. Jones" To: "'Christer Holmberg'" , "'Olle E. Johansson'" , "'Paul Kyzivat'" References: <4FF701F7.8070202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A058534071B990E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534071B990E@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 10 Jul 2012 23:05:02 -0400 Message-ID: <0de001cd5f11$f7dd7160$e7985420$@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: AQEnxsoIGcdTmWb5fTF6thkm/Fi0agGq2bnqAcX6I+8CtDlaLAIE9oNEAmOOUPuYGiP7EA== Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Use case for association of session signaling and media 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: Wed, 11 Jul 2012 03:04:37 -0000 > >The mechanisms certainly are our of scope. All I was hoping for at > >this point was to ensure that we do not make it difficult or impossible > to one day associate media and signaling by making a poor choice in how we > construct the Session-ID. > > But, how would you be able to determine whether the requirement has been > fulfilled? We probably cannot absolutely. However, if we do know of constraints placed on certain protocols, we could ensure we meet those constraints. For example, if we were to encode the Session-ID in RTCP, we might place it an SDES packet. That imposes a length limit of 255 octets. The best we can do is to try to avoid making a bad choice. I do not think we can guarantee it. Paul From laura.liess.dt@googlemail.com Wed Jul 11 00:13:44 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FBB11E80D1 for ; Wed, 11 Jul 2012 00:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKix-PpSoLnn for ; Wed, 11 Jul 2012 00:13:44 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C899811E8098 for ; Wed, 11 Jul 2012 00:13:43 -0700 (PDT) Received: by ghbg16 with SMTP id g16so919510ghb.31 for ; Wed, 11 Jul 2012 00:14:08 -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=kOdNllgqHvuMvXlLV00nHd6KmYvO3x1xW5BJqqdi3yU=; b=oGmpGBMdkcwkMWyTwId3VS2zcichgFBySBiWp5Sso7O/IJL2zxxWdWkSUJFl6pL44Q UCfjbesIj7+QRZU7Qx+IylOOkrgi/j9MRwh3MjJbyKLb14498OTtE9NhWX8zz0iGNxzp A3ThwJR+3aI5DK1zx9FL2WmjPwnmLxWxaekYPnVYm1FTwc55YQTYfPIaGX3oQ8S9oYpA y4QqURfuJhjrBPDYhIx2lSkqTJdExjCb7mcphXBxRqmtpk4TB0x5lTw/yUWkT6wNNfyv CXBo/3W/9Sn4RYst/V9wW9wvip6bQiTGTAeKNoxAb85yHbwyUmSkgmnVuC0kdIDQpjVm oC/g== MIME-Version: 1.0 Received: by 10.43.70.71 with SMTP id yf7mr24441349icb.14.1341990847746; Wed, 11 Jul 2012 00:14:07 -0700 (PDT) Received: by 10.231.200.37 with HTTP; Wed, 11 Jul 2012 00:14:07 -0700 (PDT) In-Reply-To: <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> Date: Wed, 11 Jul 2012 09:14:07 +0200 Message-ID: From: Laura Liess To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 07:13:44 -0000 Paul, After the discussion yesterday in the Webex meeting, it seems to me that separate requirements for dialogs and transactions are needed. Thanks Laura 2012/7/11 Paul E. Jones : > Indeed, you're right. It does cover both, but folks called for a separate > requirement. > > What is the wishes of the WG on this? Shall I replace REQ1 with the below > text? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Laura Liess >> Sent: Tuesday, July 10, 2012 8:23 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use >> case >> >> Paul, >> >> > >> > What was proposed (by you?) was this: >> > >> > REQ1a: It must be possible for an administrator or an external device >> > which monitors the SIP-traffic to use the identifier to identify those >> > dialogs, transactions and messages which were at some point in time >> > components of a single end-to-end SIP session (e.g., parts of the same >> call). >> >> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is >> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace >> the current text of REQ1 by the proposed text of the REQ1a and then drop >> REQ1a. >> >> Thanks >> Laura >> >> >> >> >> > >> > This is not presently in the draft that we just submitted to be a WG >> > document since I was told to base that document on the -03 draft. I >> > had that text in my pending -04 draft, but ... it is still sitting >> > there :-) >> > >> >> > You really want to just remove that text from c)? >> >> [LL] No. I don't. >> >> Also in this scenario the service providers monitors and logs all >> >> B2BUA traffic, incomming and outgoing. There is no log provided by >> >> the customer. >> >> >> >> From my point of view, the text would be : >> >> >> >> -------------------------------------------- >> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging >> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service >> provider. >> >> For privacy reasons, the B2BUA changes the SIP headers that reveal >> >> information related to the SIP users, device or domain identity. The >> >> service provider uses an external device to monitor and log all SIP >> >> traffic coming to and from the B2BUA. In the case of failures >> >> reported by the customer or when security issue arise (e.g. theft of >> >> service), the service provider has to analyze the logs from the past >> >> several days or weeks and correlates those messages which were >> >> messages for a single end- to-end SIP session. >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B >> >> does not. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> ----------------- >> >> >> >> >> >> What do you think? >> > >> > >> > Sounds OK to me. I'll put this into me -04 draft and when folks give >> > me the green light, move it into the WG -01 draft. >> > >> > Paul >> > >> > >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > From paulej@packetizer.com Wed Jul 11 05:09:17 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8621F85D2 for ; Wed, 11 Jul 2012 05:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 HrY4+1XXtnlR for ; Wed, 11 Jul 2012 05:09:16 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 98A3B21F859B for ; Wed, 11 Jul 2012 05:09:16 -0700 (PDT) Received: from dyn-157.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 q6BC9gU9004029 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 11 Jul 2012 08:09:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1342008582; bh=dF7eHF9e4J0eqYuE1aSTB40f0rvp0POLveOUdsDgIjo=; h=References:In-Reply-To:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=S/wargxz/4OrqXEEs1GnTt5zLaRkvu1xLL7MVkm7DsKK1/kZe5Vo3pRLbkI5TguxF LjbU1COlKkbysmz2kJ7D3JcuFd14qLn9KlrVMdegToV+U9vvNOCBc7cMKBnGib0S7A ZY42PM2WcY3kDb8Yl0Vflg0UXlodJsv9X+jb0qzM= References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----UQTKFUP22KW2NWV4L2FFZ507M9PADA" From: "Paul E. Jones" Date: Wed, 11 Jul 2012 08:09:40 -0400 To: Laura Liess Message-ID: <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 12:09:17 -0000 ------UQTKFUP22KW2NWV4L2FFZ507M9PADA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit What shall be the wording of REQ1a? Paul _____________________________________________ From: Laura Liess Sent: Wed Jul 11 03:14:07 EDT 2012 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case Paul, After the discussion yesterday in the Webex meeting, it seems to me that separate requirements for dialogs and transactions are needed. Thanks Laura 2012/7/11 Paul E. Jones : > Indeed, you're right. It does cover both, but folks called for a separate > requirement. > > What is the wishes of the WG on this? Shall I replace REQ1 with the below > text? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Laura Liess >> Sent: Tuesday, July 10, 2012 8:23 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use >> case >> >> Paul, >> >> > >> > What was proposed (by you?) was this: >> > >> > REQ1a: It must be possible for an administrator or an external device >> > which monitors the SIP-traffic to use the identifier to identify those >> > dialogs, transactions and messages which were at some point in time >> > components of a single end-to-end SIP session (e.g., parts of the same >> call). >> >> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is >> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace >> the current text of REQ1 by the proposed text of the REQ1a and then drop >> REQ1a. >> >> Thanks >> Laura >> >> >> >> >> > >> > This is not presently in the draft that we just submitted to be a WG >> > document since I was told to base that document on the -03 draft. I >> > had that text in my pending -04 draft, but ... it is still sitting >> > there :-) >> > >> >> > You really want to just remove that text from c)? >> >> [LL] No. I don't. >> >> Also in this scenario the service providers monitors and logs all >> >> B2BUA traffic, incomming and outgoing. There is no log provided by >> >> the customer. >> >> >> >> From my point of view, the text would be : >> >> >> >>_____________________________________________ >> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging >> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service >> provider. >> >> For privacy reasons, the B2BUA changes the SIP headers that reveal >> >> information related to the SIP users, device or domain identity. The >> >> service provider uses an external device to monitor and log all SIP >> >> traffic coming to and from the B2BUA. In the case of failures >> >> reported by the customer or when security issue arise (e.g. theft of >> >> service), the service provider has to analyze the logs from the past >> >> several days or weeks and correlates those messages which were >> >> messages for a single end- to-end SIP session. >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B >> >> does not. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> ----------------- >> >> >> >> >> >> What do you think? >> > >> > >> > Sounds OK to me. I'll put this into me -04 draft and when folks give >> > me the green light, move it into the WG -01 draft. >> > >> > Paul >> > >> > >>_____________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > ------UQTKFUP22KW2NWV4L2FFZ507M9PADA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit What shall be the wording of REQ1a?

Paul

From: Laura Liess <laura.liess.dt@googlemail.com>
Sent: Wed Jul 11 03:14:07 EDT 2012
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case

Paul,

After the discussion yesterday in the Webex meeting, it seems to me
that separate requirements for dialogs and transactions are needed.

Thanks
Laura

2012/7/11 Paul E. Jones <paulej@packetizer.com>:
> Indeed, you're right.  It does cover both, but folks called for a separate
> requirement.
>
> What is the wishes of the WG on this?  Shall I replace REQ1 with the below
> text?


>
> Paul
>
>> -----Original Message-----
>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf
>> Of Laura Liess
>> Sent: Tuesday, July 10, 2012 8:23 AM
>> To: Paul E. Jones
>> Cc: insipid@ietf.org
>> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use
>> case
>>
>> Paul,
>>
>> >
>> > What was proposed (by you?) was this:
>> >
>> > REQ1a: It must be possible for an administrator or an external device
>> > which monitors the SIP-traffic to use the identifier to identify those
>> > dialogs, transactions and messages which were at some point in time
>> > components of a single end-to-end SIP session (e.g., parts of the same
>> call).
>>
>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is
>> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace
>> the current text of REQ1 by the proposed text of the REQ1a and then drop
>> REQ1a.
>>
>> Thanks
>> Laura
>>
>>
>>
>>
>> >
>> > This is not presently in t!
 he draft
that we just submitted to be a WG
>> > document since I was told to base that document on the -03 draft.  I
>> > had that text in my pending -04 draft, but ... it is still sitting
>> > there :-)
>> >
>> >> > You really want to just remove that text from c)?
>> >> [LL]  No. I don't.
>> >> Also in this scenario the service providers monitors and logs all
>> >> B2BUA traffic, incomming and outgoing.  There is no log provided by
>> >> the customer.
>> >>
>> >> From my point of view, the text would be :
>> >>
>> >>

>> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging
>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service
>> provider.
>> >> For privacy reasons, t!
 he B2BUA
changes the SIP headers that reveal
>> >> information related to the SIP users, device or domain identity. The
>> >> service provider uses an external device to monitor and log all SIP
>> >> traffic coming to and from the B2BUA.  In the case of failures
>> >> reported by the customer or when security issue arise (e.g. theft of
>> >> service), the service provider has to analyze the logs from the past
>> >> several days or weeks and correlates those messages which were
>> >> messages for a single end- to-end SIP session.
>> >>
>> >> For this scenario, we must consider three particular use cases:
>> >>
>> >> a) The UAs  A and B support the end-to-end Session Identifier.
>> >>
>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8.
>> >>
>> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B
>> >> does not.
>> >>
>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8.
>> >>
>> >> c) UA A and UA  B do not support the end-to-end Session Identifier.
>> >>
>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8.
>> >> -----------------
>> >>
>> >>
>> >> What do you think?
>> >
>> >
>> > Sounds OK to me.  I'll put this into me -04 draft and when folks give
>> > me the green light, move it into the WG -01 draft.
>> >
>> > Paul
>> >
>> >
>>

>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
>
------UQTKFUP22KW2NWV4L2FFZ507M9PADA-- From keith.drage@alcatel-lucent.com Wed Jul 11 06:02:35 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1C021F8616 for ; Wed, 11 Jul 2012 06:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.814 X-Spam-Level: X-Spam-Status: No, score=-107.814 tagged_above=-999 required=5 tests=[AWL=-2.166, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP4hC8wsx5rG for ; Wed, 11 Jul 2012 06:02:31 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id D7ED421F856C for ; Wed, 11 Jul 2012 06:02:30 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6BCxId3001402 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 11 Jul 2012 15:02:55 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 11 Jul 2012 15:02:29 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Wed, 11 Jul 2012 15:02:28 +0200 Thread-Topic: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case Thread-Index: Ac1fXhux5QbqAg/NT3+0y9lR6uDdBgABPk7Q Message-ID: References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> In-Reply-To: <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE240A8562AFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 13:02:35 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE240A8562AFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [As individual] What I took away from the discussion yesterday was: - that REQ 1 represents the session ID requirement for= a number of transactions bound up in a dialog, whereas REQ 1A represents t= he session ID requirement for a transaction not so bound. - For each of these requirements we need to cover the = existence over time, and the existence over space. - The existence over space requirement is identical fo= r both, i.e. that UA A, UAB, and all the entities inbetween will be able to= see the same session ID, such that some other entity trying to correlate i= nformation feeds from these entities will be able to do so. - The existence over time requirement only applies to = REQ 1, i.e. that all transactions within the same dialog should share the s= ame session ID. I do not believe there is a requirement for session ID with= in the transaction, i.e. between request and response - that is dealt with = by other mechanisms. We have no requirement for correlation between two tra= nsactions that are not within a dialog. While it would be possible to draft this round the existing requirement spl= it, I suggest maybe we just do the split round the time and space division.= So the new revised requirements might look like (in place of the existing)= . REQ 1B: It must be possible for the same identifier to appear at all entiti= es participating in a SIP transaction, such that an external device that mo= nitors the SIP traffic can use that identifier to correlate the same transa= ction at each of those entities. REQ 1C: It must be possible for the same identifier to appear in all transa= ctions that form part of a SIP dialog, such that the transactions that form= part of the dialog can be correlated together. There is no requirement for= the identifier to correlate parts of a single transaction (i.e. request an= d response) as existing SIP mechanisms are assumed to do that. There is no = requirement for the identifier to correlate two transactions that do not fo= rm part of the same dialog (e.g. an OPTIONS transaction and a subsequent IN= VITE transaction, or a MESSAGE transaction and a subsequent MESSAGE transac= tion), except as expressed in other requirements. Note the "except" in REQ 1C above is to allow the transfer requirements in = REQ2. If the new REQ 1B is acceptable, then we should also consider how distinct = that is from REQ 4. Keith ________________________________ From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: 11 July 2012 13:10 To: Laura Liess Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use c= ase What shall be the wording of REQ1a? Paul ________________________________ From: Laura Liess Sent: Wed Jul 11 03:14:07 EDT 2012 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use c= ase Paul, After the discussion yesterday in the Webex meeting, it seems to me that separate requirements for dialogs and transactions are needed. Thanks Laura 2012/7/11 Paul E. Jones : > Indeed, you're right. It does cover both, but folks called for a separat= e > requirement. > > What is the wishes of the WG on this? Shall I replace REQ1 with the belo= w > text? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Beha= lf >> Of Laura Liess >> Sent: Tuesday, July 10, 2012 8:23 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" us= e >> case >> >> Paul, >> >> > >> > What was proposed (by you?) was this: >> > >> > REQ1a: It must be possible for an administrator or an external device >> > which monitors the SIP-traffic to use the identifier to identify those >> > dialogs, transactions and messages which were at some point in time >> > components of a single end-to-end SIP session (e.g., parts of the same >> call). >> >> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it = is >> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace >> the current text of REQ1 by the proposed text of the REQ1a and then drop >> REQ1a. >> >> Thanks >> Laura >> >> >> >> >> > >> > This is not presently in t! he draft that we just submitted to be a WG >> > document since I was told to base that document on the -03 draft. I >> > had that text in my pending -04 draft, but ... it is still sitting >> > there :-) >> > >> >> > You really want to just remove that text from c)? >> >> [LL] No. I don't. >> >> Also in this scenario the service providers monitors and logs all >> >> B2BUA traffic, incomming and outgoing. There is no log provided by >> >> the customer. >> >> >> >> From my point of view, the text would be : >> >> >> >> ________________________________ >> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging >> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service >> provider. >> >> For privacy reasons, t! he B2BUA changes the SIP headers that reveal >> >> information related to the SIP users, device or domain identity. The >> >> service provider uses an external device to monitor and log all SIP >> >> traffic coming to and from the B2BUA. In the case of failures >> >> reported by the customer or when security issue arise (e.g. theft of >> >> service), the service provider has to analyze the logs from the past >> >> several days or weeks and correlates those messages which were >> >> messages for a single end- to-end SIP session. >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B >> >> does not. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> ----------------- >> >> >> >> >> >> What do you think? >> > >> > >> > Sounds OK to me. I'll put this into me -04 draft and when folks give >> > me the green light, move it into the WG -01 draft. >> > >> > Paul >> > >> > >> ________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > --_000_EDC0A1AE77C57744B664A310A0B23AE240A8562AFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[As individual]

 

What I took away from the discussion yesterday was:

 

-      =             &nb= sp;   = that REQ 1 represents the session ID requirement for a number of transactions bound = up in a dialog, whereas REQ 1A represents the session ID requirement for a transaction not so bound.

-      =             &nb= sp;   = For each of these requirements we need to cover the existence over time, and the existence over space.

-      =             &nb= sp;   = The existence over space requirement is identical for both, i.e. that UA A, UAB= , and all the entities inbetween will be able to see the same session ID, suc= h that some other entity trying to correlate information feeds from these entities will be able to do so.

-      =             &nb= sp;   = The existence over time requirement only applies to REQ 1, i.e. that all transactions within the same dialog should share the same session ID. I do = not believe there is a requirement for session ID within the transaction, i.e. = between request and response – that is dealt with by other mechanisms. We hav= e no requirement for correlation between two transactions that are not within a dialog.

 

While it would be possible to draft th= is round the existing requirement split, I suggest maybe we just do the split round the time and space division. So the new revised requirements might lo= ok like (in place of the existing).

 

REQ 1B: It must be possible for the sa= me identifier to appear at all entities participating in a SIP transaction, su= ch that an external device that monitors the SIP traffic can use that identifi= er to correlate the same transaction at each of those entities.

 

REQ 1C: It must be possible for the sa= me identifier to appear in all transactions that form part of a SIP dialog, su= ch that the transactions that form part of the dialog can be correlated togeth= er. There is no requirement for the identifier to correlate parts of a single transac= tion (i.e. request and response) as existing SIP mechanisms are assumed to do th= at. There is no requirement for the identifier to correlate two transactions th= at do not form part of the same dialog (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a MESSAGE transaction and a subsequent MESSAGE transaction), except as expressed in other requirements.=

 

Note the “except” in REQ 1= C above is to allow the transfer requirements in REQ2.

 

If the new REQ 1B is acceptable, then = we should also consider how distinct that is from REQ 4.

 

Keith

 

From:= insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: 11 July 2012 13:10
To: Laura Liess
Cc: insipid@ietf.org
Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case<= span lang=3DEN-US>

 

What shall be the= wording of REQ1a?

Paul

From: Laura Li= ess <laura.liess.dt@googlemail.com>
Sent: Wed Jul 11 03:14:07 = EDT 2012
To: "Paul E. Jones"= ; <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case



P=
aul,



After the discussion yesterday in the Webex meeting, it seems to me

that separate requirements for dialogs and transactions are needed.



Thanks

Laura



2012/7/11 Paul E. Jones <paulej@packetizer.com>:

> Indeed, you're right.  It does cover both, but folks called for a=
 separate

> requirement.

>

> What is the wishes of the WG on this?  Shall I replace REQ1 with =
the below

> text?





>

> Paul

>

>> -----Original Message-----

>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] O=
n Behalf

>> Of Laura Liess

>> Sent: Tuesday, July 10, 2012 8:23 AM

>> To: Paul E. Jones

>> Cc: insipid@ietf.org

>> Subject: Re: [Insipid] Text proposal for the "SIP traffic mon=
itoring" use

>> case

>>

>> Paul,

>>

>> >

>> > What was proposed (by you?) was this:

>> >

>> > REQ1a: It must be possible for an administrator or an externa=
l device

>> > which monitors the SIP-traffic to use the identifier to ident=
ify those

>> > dialogs, transactions and messages which were at some point i=
n time

>> > components of a single end-to-end SIP session (e.g., parts of=
 the same

>> call).

>>

>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (=
as it is

>> in draft-ietf-insipid-session-id-reqts-00). So I think we could re=
place

>> the current text of REQ1 by the proposed text of the REQ1a and the=
n drop

>> REQ1a.

>>

>> Thanks

>> Laura

>>

>>

>>

>>

>> >

>> > This is not presently in t!
he draft
that we just=
 submitted to be a WG

>> > document since I was told to base that document on the -03 dr=
aft.  I

>> > had that text in my pending -04 draft, but ... it is still si=
tting

>> > there :-)

>> >

>> >> > You really want to just remove that text from c)?
>> >> [LL]  No. I don't.

>> >> Also in this scenario the service providers monitors and =
logs all

>> >> B2BUA traffic, incomming and outgoing.  There is no =
log provided by

>> >> the customer.

>> >>

>> >> From my point of view, the text would be :

>> >>

>> >>








>> >> User Agent A (A) and User Agent B (B) communicate using S=
IP messaging

>> >> with a SIP B2BUA acting as a middlebox which belongs to a=
 SIP service

>> provider.

>> >> For privacy reasons, t!
he B2BUA
changes the =
SIP headers that reveal

>> >> information related to the SIP users, device or domain id=
entity. The

>> >> service provider uses an external device to monitor and l=
og all SIP

>> >> traffic coming to and from the B2BUA.  In the case o=
f failures

>> >> reported by the customer or when security issue arise (e.=
g. theft of

>> >> service), the service provider has to analyze the logs fr=
om the past

>> >> several days or weeks and correlates those messages which=
 were

>> >> messages for a single end- to-end SIP session.

>> >>

>> >> For this scenario, we must consider three particular use =
cases:

>> >>

>> >> a) The UAs  A and B support the end-to-end Session I=
dentifier.

>> >>

>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8.

>> >>

>> >> b) Only the UA A supports the end-to-end Session Identifi=
er, the UA B

>> >> does not.

>> >>

>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8=
.

>> >>

>> >> c) UA A and UA  B do not support the end-to-end Sess=
ion Identifier.

>> >>

>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8=
.

>> >> -----------------

>> >>

>> >>

>> >> What do you think?

>> >

>> >

>> > Sounds OK to me.  I'll put this into me -04 draft and wh=
en folks give

>> > me the green light, move it into the WG -01 draft.

>> >

>> > Paul

>> >

>> >

>>








>> insipid mailing list

>> insipid@ietf.org

>> https://=
www.ietf.org/mailman/listinfo/insipid

>
--_000_EDC0A1AE77C57744B664A310A0B23AE240A8562AFRMRSSXCHMBSC3d_-- From keith.drage@alcatel-lucent.com Wed Jul 11 06:51:58 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C611711E8101 for ; Wed, 11 Jul 2012 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.034 X-Spam-Level: X-Spam-Status: No, score=-110.034 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO8k5TQkEdEC for ; Wed, 11 Jul 2012 06:51:58 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 085EB11E80FF for ; Wed, 11 Jul 2012 06:51:57 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6BDiHTI015284 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 11 Jul 2012 15:52:26 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 11 Jul 2012 15:51:59 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Wed, 11 Jul 2012 15:51:58 +0200 Thread-Topic: INSIPID solution Thread-Index: Ac1fbFcggySi3kTbRjqyrClW/hVUDg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] INSIPID solution 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, 11 Jul 2012 13:51:59 -0000 [As WG cochair] Based on the call yesterday, and the mails on the list, I am beginning to s= ee convergence of a solution around: 1) A half identity formed from the UUID of the sender. 2) A session ID formed from two half identities. 3) The two halves are always signalled. Which half is which will need to be= rigorously specified. We are not anywhere near declaring consensus on this, but now would be a go= od time to express alternative views if this is not the way forward. Regards Keith From pkyzivat@alum.mit.edu Wed Jul 11 07:50:55 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D7621F850B for ; Wed, 11 Jul 2012 07:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 L4b+djXFPlnB for ; Wed, 11 Jul 2012 07:50:54 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id E29A021F8517 for ; Wed, 11 Jul 2012 07:50:53 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Z0ak1j0050mv7h05B2rSAz; Wed, 11 Jul 2012 14:51:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Z2rN1j00g3ZTu2S3X2rN4d; Wed, 11 Jul 2012 14:51:23 +0000 Message-ID: <4FFD92EB.1000404@alum.mit.edu> Date: Wed, 11 Jul 2012 10:51:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 14:50:55 -0000 I get Keith's point. But the language isn't working for me. There are indeed two cases, one related to transactions, and the other related to dialogs. But in neither case is it about a single transaction or a single dialog, because we have B2BUAs in place. Rather, in one case we have a set of transactions spliced together by B2BUAs. In the other we have a set of dialogs spliced together by B2BUAs. Of course a dialog is itself a set of related transactions. But the grouping is different. A transaction is always between two neighboring nodes. When you insert proxies in the path there is a separate transaction on each side of the proxy, and they are correlated by dialog id. When we introduce a B2BUA the situation isn't much different, except that the dialog id isn't preserved. So in this case we want the session id to provide the correlation that the dialog id doesn't. > REQ 1B: It must be possible for the same identifier to appear at all > entities participating in a SIP transaction, such that an external > device that monitors the SIP traffic can use that identifier to > correlate the same transaction at each of those entities. So, "SIP transaction" above is wrong. > REQ 1C: It must be possible for the same identifier to appear in all > transactions that form part of a SIP dialog, such that the transactions > that form part of the dialog can be correlated together. There is no > requirement for the identifier to correlate parts of a single > transaction (i.e. request and response) as existing SIP mechanisms are > assumed to do that. There is no requirement for the identifier to > correlate two transactions that do not form part of the same dialog > (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a > MESSAGE transaction and a subsequent MESSAGE transaction), except as > expressed in other requirements. and "SIP dialog" is wrong above. We have coined the term "session" (as overloaded as it is) for the set of dialogs connected by B2BUAs. So maybe it could be used above. But we have no term proposed for the transactions connected by B2BUAs, so its really hard to write 1B. If we want to cover this case then we need terminology to describe it. Thanks, Paul On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: > [As individual] > > What I took away from the discussion yesterday was: > > -that REQ 1 represents the session ID requirement for a number of > transactions bound up in a dialog, whereas REQ 1A represents the session > ID requirement for a transaction not so bound. > > -For each of these requirements we need to cover the existence over > time, and the existence over space. > > -The existence over space requirement is identical for both, i.e. that > UA A, UAB, and all the entities inbetween will be able to see the same > session ID, such that some other entity trying to correlate information > feeds from these entities will be able to do so. > > -The existence over time requirement only applies to REQ 1, i.e. that > all transactions within the same dialog should share the same session > ID. I do not believe there is a requirement for session ID within the > transaction, i.e. between request and response – that is dealt with by > other mechanisms. We have no requirement for correlation between two > transactions that are not within a dialog. > > While it would be possible to draft this round the existing requirement > split, I suggest maybe we just do the split round the time and space > division. So the new revised requirements might look like (in place of > the existing). > > REQ 1B: It must be possible for the same identifier to appear at all > entities participating in a SIP transaction, such that an external > device that monitors the SIP traffic can use that identifier to > correlate the same transaction at each of those entities. > > REQ 1C: It must be possible for the same identifier to appear in all > transactions that form part of a SIP dialog, such that the transactions > that form part of the dialog can be correlated together. There is no > requirement for the identifier to correlate parts of a single > transaction (i.e. request and response) as existing SIP mechanisms are > assumed to do that. There is no requirement for the identifier to > correlate two transactions that do not form part of the same dialog > (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a > MESSAGE transaction and a subsequent MESSAGE transaction), except as > expressed in other requirements. > > Note the “except” in REQ 1C above is to allow the transfer requirements > in REQ2. > > If the new REQ 1B is acceptable, then we should also consider how > distinct that is from REQ 4. > > Keith > > ------------------------------------------------------------------------ > > *From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On > Behalf Of *Paul E. Jones > *Sent:* 11 July 2012 13:10 > *To:* Laura Liess > *Cc:* insipid@ietf.org > *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" > use case > > What shall be the wording of REQ1a? > > Paul > > ------------------------------------------------------------------------ > > *From:*Laura Liess > *Sent:* Wed Jul 11 03:14:07 EDT 2012 > *To:* "Paul E. Jones" > *Cc:* insipid@ietf.org > *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" > use case > > > > Paul, > > > > After the discussion yesterday in the Webex meeting, it seems to me > > that separate requirements for dialogs and transactions are needed. > > > > Thanks > > Laura > > > > 2012/7/11 Paul E. Jones: > >> Indeed, you're right. It does cover both, but folks called for a separate > >> requirement. > >> > >> What is the wishes of the WG on this? Shall I replace REQ1 with the below > >> text? > > > > > >> > >> Paul > >> > >>> -----Original Message----- > >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > >>> Of Laura Liess > >>> Sent: Tuesday,July 10, 2012 8:23 AM > >>> To: Paul E. Jones > >>> Cc: insipid@ietf.org > >>> Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring" use > >>> case > >>> > >>> Paul, > >>> > >>> > > >>> > What was proposed (by you?) was this: > >>> > > >>> > REQ1a: It must be possible for an administrator or an external device > >>> > which monitors the SIP-traffic to use the identifier to identify those > >>> > dialogs, transactions and messages which were at some point in time > >>> > components of a single end-to-end SIP session (e.g., parts of the same > >>> call). > >>> > >>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is > >>> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace > >>> the current text of REQ1 by the proposed text of the REQ1a and then drop > >>> REQ1a. > >>> > >>> Thanks > >>> Laura > >>> > >>> > >>> > >>> > >>> > > >>> > This is not presently in t! > > he draft > > that we just submitted to be a WG > >>> > document since I was told to base that document on the -03 draft. I > >>> > had that text in my pending -04 draft, but ... it is still sitting > >>> > there :-) > >>> > > >>> >> > You really want to just remove that text from c)? > >>> >> [LL] No. I don't. > >>> >> Also in this scenario the service providers monitors and logs all > >>> >> B2BUA traffic, incomming and outgoing. There is no log provided by > >>> >> the customer. > >>> >> > >>> >> From my point of view, the text would be : > >>> >> > >>> >> > > > > ------------------------------------------------------------------------ > > > > >>> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging > >>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service > >>> provider. > >>> >> For privacy reasons, t! > > he B2BUA > > changes the SIP headers that reveal > >>> >> information related to the SIP users, device or domain identity. The > >>> >> service provider uses an external device to monitor and log all SIP > >>> >> traffic coming to and from the B2BUA. In the case of failures > >>> >> reported by the customer or when security issue arise (e.g. theft of > >>> >> service), the service provider has to analyze the logs from the past > >>> >> several days or weeks and correlates those messages which were > >>> >> messages for a single end- to-end SIP session. > >>> >> > >>> >> For this scenario, we must consider three particular use cases: > >>> >> > >>> >> a) The UAs A and B support the end-to-end Session Identifier. > >>> >> > >>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. > >>> >> > >>> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B > >>> >> does not. > >>> >> > >>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > >>> >> > >>> >> c) UA A and UA B do not support the end-to-end Session Identifier. > >>> >> > >>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > >>> >> ----------------- > >>> >> > >>> >> > >>> >> What do you think? > >>> > > >>> > > >>> > Sounds OK to me. I'll put this into me -04 draft and when folks give > >>> > me the green light, move it into the WG -01 draft. > >>> > > >>> > Paul > >>> > > >>> > > >>> > > > > ------------------------------------------------------------------------ > > > > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >> > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From oej@edvina.net Wed Jul 11 07:55:00 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2E221F872A for ; Wed, 11 Jul 2012 07:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.662 X-Spam-Level: X-Spam-Status: No, score=-1.662 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 QknitNfPOdlq for ; Wed, 11 Jul 2012 07:54:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 51BA121F8767 for ; Wed, 11 Jul 2012 07:54:56 -0700 (PDT) Received: from [192.168.40.27] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 21967754A8AC; Wed, 11 Jul 2012 14:55:23 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: "Olle E. Johansson" In-Reply-To: <4FFD92EB.1000404@alum.mit.edu> Date: Wed, 11 Jul 2012 16:55:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 14:55:00 -0000 11 jul 2012 kl. 16:51 skrev Paul Kyzivat: > I get Keith's point. But the language isn't working for me. > There are indeed two cases, one related to transactions, and the other = related to dialogs. But in neither case is it about a single transaction = or a single dialog, because we have B2BUAs in place. >=20 > Rather, in one case we have a set of transactions spliced together by = B2BUAs. In the other we have a set of dialogs spliced together by = B2BUAs. Of course a dialog is itself a set of related transactions. But = the grouping is different. >=20 > A transaction is always between two neighboring nodes. When you insert = proxies in the path there is a separate transaction on each side of the = proxy, and they are correlated by dialog id. When we introduce a B2BUA = the situation isn't much different, except that the dialog id isn't = preserved. So in this case we want the session id to provide the = correlation that the dialog id doesn't. >=20 >> REQ 1B: It must be possible for the same identifier to appear at all >> entities participating in a SIP transaction, such that an external >> device that monitors the SIP traffic can use that identifier to >> correlate the same transaction at each of those entities. >=20 > So, "SIP transaction" above is wrong. >=20 >> REQ 1C: It must be possible for the same identifier to appear in all >> transactions that form part of a SIP dialog, such that the = transactions >> that form part of the dialog can be correlated together. There is no >> requirement for the identifier to correlate parts of a single >> transaction (i.e. request and response) as existing SIP mechanisms = are >> assumed to do that. There is no requirement for the identifier to >> correlate two transactions that do not form part of the same dialog >> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or = a >> MESSAGE transaction and a subsequent MESSAGE transaction), except as >> expressed in other requirements. >=20 > and "SIP dialog" is wrong above. >=20 > We have coined the term "session" (as overloaded as it is) for the set = of dialogs connected by B2BUAs. So maybe it could be used above. Oh. Sorry for arriving late to the discussion table, but isn't session = already taken by RTP?=20 >=20 > But we have no term proposed for the transactions connected by B2BUAs, = so its really hard to write 1B. If we want to cover this case then we = need terminology to describe it. >=20 Maybe "dialog-groups" and "transaction-groups" as defined by the = group-id - t-group-id and d-group-id? Just brainstorming ;-) /O > Thanks, > Paul >=20 >=20 >=20 > On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: >> [As individual] >>=20 >> What I took away from the discussion yesterday was: >>=20 >> -that REQ 1 represents the session ID requirement for a number of >> transactions bound up in a dialog, whereas REQ 1A represents the = session >> ID requirement for a transaction not so bound. >>=20 >> -For each of these requirements we need to cover the existence over >> time, and the existence over space. >>=20 >> -The existence over space requirement is identical for both, i.e. = that >> UA A, UAB, and all the entities inbetween will be able to see the = same >> session ID, such that some other entity trying to correlate = information >> feeds from these entities will be able to do so. >>=20 >> -The existence over time requirement only applies to REQ 1, i.e. that >> all transactions within the same dialog should share the same session >> ID. I do not believe there is a requirement for session ID within the >> transaction, i.e. between request and response =96 that is dealt with = by >> other mechanisms. We have no requirement for correlation between two >> transactions that are not within a dialog. >>=20 >> While it would be possible to draft this round the existing = requirement >> split, I suggest maybe we just do the split round the time and space >> division. So the new revised requirements might look like (in place = of >> the existing). >>=20 >> REQ 1B: It must be possible for the same identifier to appear at all >> entities participating in a SIP transaction, such that an external >> device that monitors the SIP traffic can use that identifier to >> correlate the same transaction at each of those entities. >>=20 >> REQ 1C: It must be possible for the same identifier to appear in all >> transactions that form part of a SIP dialog, such that the = transactions >> that form part of the dialog can be correlated together. There is no >> requirement for the identifier to correlate parts of a single >> transaction (i.e. request and response) as existing SIP mechanisms = are >> assumed to do that. There is no requirement for the identifier to >> correlate two transactions that do not form part of the same dialog >> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or = a >> MESSAGE transaction and a subsequent MESSAGE transaction), except as >> expressed in other requirements. >>=20 >> Note the =93except=94 in REQ 1C above is to allow the transfer = requirements >> in REQ2. >>=20 >> If the new REQ 1B is acceptable, then we should also consider how >> distinct that is from REQ 4. >>=20 >> Keith >>=20 >> = ------------------------------------------------------------------------ >>=20 >> *From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On >> Behalf Of *Paul E. Jones >> *Sent:* 11 July 2012 13:10 >> *To:* Laura Liess >> *Cc:* insipid@ietf.org >> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic = monitoring" >> use case >>=20 >> What shall be the wording of REQ1a? >>=20 >> Paul >>=20 >> = ------------------------------------------------------------------------ >>=20 >> *From:*Laura Liess >> *Sent:* Wed Jul 11 03:14:07 EDT 2012 >> *To:* "Paul E. Jones" >> *Cc:* insipid@ietf.org >> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic = monitoring" >> use case >>=20 >>=20 >>=20 >> Paul, >>=20 >>=20 >>=20 >> After the discussion yesterday in the Webex meeting, it seems to me >>=20 >> that separate requirements for dialogs and transactions are needed. >>=20 >>=20 >>=20 >> Thanks >>=20 >> Laura >>=20 >>=20 >>=20 >> 2012/7/11 Paul E. Jones: >>=20 >>> Indeed, you're right. It does cover both, but folks called for a = separate >>=20 >>> requirement. >>=20 >>>=20 >>=20 >>> What is the wishes of the WG on this? Shall I replace REQ1 with = the below >>=20 >>> text? >>=20 >>=20 >>=20 >>=20 >>=20 >>>=20 >>=20 >>> Paul >>=20 >>>=20 >>=20 >>>> -----Original Message----- >>=20 >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf >>=20 >>>> Of Laura Liess >>=20 >>>> Sent: Tuesday,July 10, 2012 8:23 AM >>=20 >>>> To: Paul E. Jones >>=20 >>>> Cc: insipid@ietf.org >>=20 >>>> Subject: Re: [Insipid] Text proposal for the"SIP traffic = monitoring" use >>=20 >>>> case >>=20 >>>>=20 >>=20 >>>> Paul, >>=20 >>>>=20 >>=20 >>>> > >>=20 >>>> > What was proposed (by you?) was this: >>=20 >>>> > >>=20 >>>> > REQ1a: It must be possible for an administrator or an external = device >>=20 >>>> > which monitors the SIP-traffic to use the identifier to identify = those >>=20 >>>> > dialogs, transactions and messages which were at some point in = time >>=20 >>>> > components of a single end-to-end SIP session (e.g., parts of = the same >>=20 >>>> call). >>=20 >>>>=20 >>=20 >>>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 = (as it is >>=20 >>>> in draft-ietf-insipid-session-id-reqts-00). So I think we could = replace >>=20 >>>> the current text of REQ1 by the proposed text of the REQ1a and then = drop >>=20 >>>> REQ1a. >>=20 >>>>=20 >>=20 >>>> Thanks >>=20 >>>> Laura >>=20 >>>>=20 >>=20 >>>>=20 >>=20 >>>>=20 >>=20 >>>>=20 >>=20 >>>> > >>=20 >>>> > This is not presently in t! >>=20 >> he draft >>=20 >> that we just submitted to be a WG >>=20 >>>> > document since I was told to base that document on the -03 = draft. I >>=20 >>>> > had that text in my pending -04 draft, but ... it is still = sitting >>=20 >>>> > there :-) >>=20 >>>> > >>=20 >>>> >> > You really want to just remove that text from c)? >>=20 >>>> >> [LL] No. I don't. >>=20 >>>> >> Also in this scenario the service providers monitors and logs = all >>=20 >>>> >> B2BUA traffic, incomming and outgoing. There is no log = provided by >>=20 >>>> >> the customer. >>=20 >>>> >> >>=20 >>>> >> =46rom my point of view, the text would be : >>=20 >>>> >> >>=20 >>>> >> >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >>=20 >>=20 >>=20 >>>> >> User Agent A (A) and User Agent B (B) communicate using SIP = messaging >>=20 >>>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP = service >>=20 >>>> provider. >>=20 >>>> >> For privacy reasons, t! >>=20 >> he B2BUA >>=20 >> changes the SIP headers that reveal >>=20 >>>> >> information related to the SIP users, device or domain = identity. The >>=20 >>>> >> service provider uses an external device to monitor and log all = SIP >>=20 >>>> >> traffic coming to and from the B2BUA. In the case of = failures >>=20 >>>> >> reported by the customer or when security issue arise (e.g. = theft of >>=20 >>>> >> service), the service provider has to analyze the logs from the = past >>=20 >>>> >> several days or weeks and correlates those messages which were >>=20 >>>> >> messages for a single end- to-end SIP session. >>=20 >>>> >> >>=20 >>>> >> For this scenario, we must consider three particular use cases: >>=20 >>>> >> >>=20 >>>> >> a) The UAs A and B support the end-to-end Session = Identifier. >>=20 >>>> >> >>=20 >>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >>=20 >>>> >> >>=20 >>>> >> b) Only the UA A supports the end-to-end Session Identifier, = the UA B >>=20 >>>> >> does not. >>=20 >>>> >> >>=20 >>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>=20 >>>> >> >>=20 >>>> >> c) UA A and UA B do not support the end-to-end Session = Identifier. >>=20 >>>> >> >>=20 >>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>=20 >>>> >> ----------------- >>=20 >>>> >> >>=20 >>>> >> >>=20 >>>> >> What do you think? >>=20 >>>> > >>=20 >>>> > >>=20 >>>> > Sounds OK to me. I'll put this into me -04 draft and when = folks give >>=20 >>>> > me the green light, move it into the WG -01 draft. >>=20 >>>> > >>=20 >>>> > Paul >>=20 >>>> > >>=20 >>>> > >>=20 >>>>=20 >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >>=20 >>=20 >>=20 >>>> insipid mailing list >>=20 >>>> insipid@ietf.org >>=20 >>>> https://www.ietf.org/mailman/listinfo/insipid >>=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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From pkyzivat@alum.mit.edu Wed Jul 11 08:10:10 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAE021F870F for ; Wed, 11 Jul 2012 08:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 hb9XRsON1Vb7 for ; Wed, 11 Jul 2012 08:10:09 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBAE21F8691 for ; Wed, 11 Jul 2012 08:10:09 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id YyFD1j00817dt5G533AiLp; Wed, 11 Jul 2012 15:10:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Z3Ap1j00i3ZTu2S3Z3Aplf; Wed, 11 Jul 2012 15:10:49 +0000 Message-ID: <4FFD976E.2000700@alum.mit.edu> Date: Wed, 11 Jul 2012 11:10:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 15:10:10 -0000 On 7/11/12 10:55 AM, Olle E. Johansson wrote: >> We have coined the term "session" (as overloaded as it is) for the set of dialogs connected by B2BUAs. So maybe it could be used above. > Oh. Sorry for arriving late to the discussion table, but isn't session already taken by RTP? >> >> But we have no term proposed for the transactions connected by B2BUAs, so its really hard to write 1B. If we want to cover this case then we need terminology to describe it. >> > Maybe "dialog-groups" and "transaction-groups" as defined by the group-id - t-group-id and d-group-id? > > Just brainstorming ;-) "session" is taken by lots of things. It is overloaded to the point of meaninglessness. My usual resolution to such things is to affix a modifier, such as foo-session. But frankly nothing better than foo comes to mind right now, and I don't think I can live with foo. The alternative is to come up with something that doesn't involve session. But I'm finding "group" even less helpful than "session". Another rule of thumb I use is that if you can't come up with a good term for a concept you are trying to define, then you probably haven't chosen the right concept. How about "macro-dialog" and "macro-transaction"? I'm not loving them, but they start to bring in relevant concepts. Thanks, Paul From keith.drage@alcatel-lucent.com Wed Jul 11 09:01:32 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6FB11E8091 for ; Wed, 11 Jul 2012 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.142 X-Spam-Level: X-Spam-Status: No, score=-109.142 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 BhOY9tUcfHHC for ; Wed, 11 Jul 2012 09:01:31 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 91D4311E8085 for ; Wed, 11 Jul 2012 09:01:31 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6BG1w3w008222 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Jul 2012 18:01:59 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 11 Jul 2012 18:01:58 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "insipid@ietf.org" Date: Wed, 11 Jul 2012 18:01:57 +0200 Thread-Topic: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case Thread-Index: Ac1fdLNhgzgGQVCzS4aIMV+a2dd4QwACPavA Message-ID: References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> In-Reply-To: <4FFD92EB.1000404@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 16:01:33 -0000 I am not tied to the words, they were to get the idea across. For my proposed 1B, I take the point that "transaction" is wrong. Maybe add= ing the words "(or set of concatenated transactions)" will solve that. For my proposal 1C, I would argue that "dialog" is absolutely correct here.= For 1C I am looking at a single point in space (one entity) and saying all= the transactions I see in that dialog have the same identifier. It is the combination of 1B (all the points that see the transaction) and 1= C (all the transactions at this entity that form the dialog) that give me t= he same identifier for all transactions in a dialog, concatenated across th= e complete path. Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 11 July 2012 15:51 > To: insipid@ietf.org > Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP > traffic monitoring" use case >=20 > I get Keith's point. But the language isn't working for me. > There are indeed two cases, one related to transactions, and the other > related to dialogs. But in neither case is it about a single transaction > or a single dialog, because we have B2BUAs in place. >=20 > Rather, in one case we have a set of transactions spliced together by > B2BUAs. In the other we have a set of dialogs spliced together by > B2BUAs. Of course a dialog is itself a set of related transactions. But > the grouping is different. >=20 > A transaction is always between two neighboring nodes. When you insert > proxies in the path there is a separate transaction on each side of the > proxy, and they are correlated by dialog id. When we introduce a B2BUA > the situation isn't much different, except that the dialog id isn't > preserved. So in this case we want the session id to provide the > correlation that the dialog id doesn't. >=20 > > REQ 1B: It must be possible for the same identifier to appear at all > > entities participating in a SIP transaction, such that an external > > device that monitors the SIP traffic can use that identifier to > > correlate the same transaction at each of those entities. >=20 > So, "SIP transaction" above is wrong. >=20 > > REQ 1C: It must be possible for the same identifier to appear in all > > transactions that form part of a SIP dialog, such that the transactions > > that form part of the dialog can be correlated together. There is no > > requirement for the identifier to correlate parts of a single > > transaction (i.e. request and response) as existing SIP mechanisms are > > assumed to do that. There is no requirement for the identifier to > > correlate two transactions that do not form part of the same dialog > > (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a > > MESSAGE transaction and a subsequent MESSAGE transaction), except as > > expressed in other requirements. >=20 > and "SIP dialog" is wrong above. >=20 > We have coined the term "session" (as overloaded as it is) for the set > of dialogs connected by B2BUAs. So maybe it could be used above. >=20 > But we have no term proposed for the transactions connected by B2BUAs, > so its really hard to write 1B. If we want to cover this case then we > need terminology to describe it. >=20 > Thanks, > Paul >=20 >=20 >=20 > On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: > > [As individual] > > > > What I took away from the discussion yesterday was: > > > > -that REQ 1 represents the session ID requirement for a number of > > transactions bound up in a dialog, whereas REQ 1A represents the sessio= n > > ID requirement for a transaction not so bound. > > > > -For each of these requirements we need to cover the existence over > > time, and the existence over space. > > > > -The existence over space requirement is identical for both, i.e. that > > UA A, UAB, and all the entities inbetween will be able to see the same > > session ID, such that some other entity trying to correlate information > > feeds from these entities will be able to do so. > > > > -The existence over time requirement only applies to REQ 1, i.e. that > > all transactions within the same dialog should share the same session > > ID. I do not believe there is a requirement for session ID within the > > transaction, i.e. between request and response - that is dealt with by > > other mechanisms. We have no requirement for correlation between two > > transactions that are not within a dialog. > > > > While it would be possible to draft this round the existing requirement > > split, I suggest maybe we just do the split round the time and space > > division. So the new revised requirements might look like (in place of > > the existing). > > > > REQ 1B: It must be possible for the same identifier to appear at all > > entities participating in a SIP transaction, such that an external > > device that monitors the SIP traffic can use that identifier to > > correlate the same transaction at each of those entities. > > > > REQ 1C: It must be possible for the same identifier to appear in all > > transactions that form part of a SIP dialog, such that the transactions > > that form part of the dialog can be correlated together. There is no > > requirement for the identifier to correlate parts of a single > > transaction (i.e. request and response) as existing SIP mechanisms are > > assumed to do that. There is no requirement for the identifier to > > correlate two transactions that do not form part of the same dialog > > (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a > > MESSAGE transaction and a subsequent MESSAGE transaction), except as > > expressed in other requirements. > > > > Note the "except" in REQ 1C above is to allow the transfer requirements > > in REQ2. > > > > If the new REQ 1B is acceptable, then we should also consider how > > distinct that is from REQ 4. > > > > Keith > > > > -----------------------------------------------------------------------= - > > > > *From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On > > Behalf Of *Paul E. Jones > > *Sent:* 11 July 2012 13:10 > > *To:* Laura Liess > > *Cc:* insipid@ietf.org > > *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" > > use case > > > > What shall be the wording of REQ1a? > > > > Paul > > > > -----------------------------------------------------------------------= - > > > > *From:*Laura Liess > > *Sent:* Wed Jul 11 03:14:07 EDT 2012 > > *To:* "Paul E. Jones" > > *Cc:* insipid@ietf.org > > *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" > > use case > > > > > > > > Paul, > > > > > > > > After the discussion yesterday in the Webex meeting, it seems to me > > > > that separate requirements for dialogs and transactions are needed. > > > > > > > > Thanks > > > > Laura > > > > > > > > 2012/7/11 Paul E. Jones: > > > >> Indeed, you're right. It does cover both, but folks called for a > separate > > > >> requirement. > > > >> > > > >> What is the wishes of the WG on this? Shall I replace REQ1 with th= e > below > > > >> text? > > > > > > > > > > > >> > > > >> Paul > > > >> > > > >>> -----Original Message----- > > > >>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf > > > >>> Of Laura Liess > > > >>> Sent: Tuesday,July 10, 2012 8:23 AM > > > >>> To: Paul E. Jones > > > >>> Cc: insipid@ietf.org > > > >>> Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring" > use > > > >>> case > > > >>> > > > >>> Paul, > > > >>> > > > >>> > > > > >>> > What was proposed (by you?) was this: > > > >>> > > > > >>> > REQ1a: It must be possible for an administrator or an external > device > > > >>> > which monitors the SIP-traffic to use the identifier to identify > those > > > >>> > dialogs, transactions and messages which were at some point in > time > > > >>> > components of a single end-to-end SIP session (e.g., parts of the > same > > > >>> call). > > > >>> > > > >>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as > it is > > > >>> in draft-ietf-insipid-session-id-reqts-00). So I think we could > replace > > > >>> the current text of REQ1 by the proposed text of the REQ1a and then > drop > > > >>> REQ1a. > > > >>> > > > >>> Thanks > > > >>> Laura > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > > >>> > This is not presently in t! > > > > he draft > > > > that we just submitted to be a WG > > > >>> > document since I was told to base that document on the -03 draft. > I > > > >>> > had that text in my pending -04 draft, but ... it is still sittin= g > > > >>> > there :-) > > > >>> > > > > >>> >> > You really want to just remove that text from c)? > > > >>> >> [LL] No. I don't. > > > >>> >> Also in this scenario the service providers monitors and logs al= l > > > >>> >> B2BUA traffic, incomming and outgoing. There is no log > provided by > > > >>> >> the customer. > > > >>> >> > > > >>> >> From my point of view, the text would be : > > > >>> >> > > > >>> >> > > > > > > > > -----------------------------------------------------------------------= - > > > > > > > > > >>> >> User Agent A (A) and User Agent B (B) communicate using SIP > messaging > > > >>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP > service > > > >>> provider. > > > >>> >> For privacy reasons, t! > > > > he B2BUA > > > > changes the SIP headers that reveal > > > >>> >> information related to the SIP users, device or domain identity. > The > > > >>> >> service provider uses an external device to monitor and log all > SIP > > > >>> >> traffic coming to and from the B2BUA. In the case of failures > > > >>> >> reported by the customer or when security issue arise (e.g. thef= t > of > > > >>> >> service), the service provider has to analyze the logs from the > past > > > >>> >> several days or weeks and correlates those messages which were > > > >>> >> messages for a single end- to-end SIP session. > > > >>> >> > > > >>> >> For this scenario, we must consider three particular use cases: > > > >>> >> > > > >>> >> a) The UAs A and B support the end-to-end Session Identifier. > > > >>> >> > > > >>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. > > > >>> >> > > > >>> >> b) Only the UA A supports the end-to-end Session Identifier, the > UA B > > > >>> >> does not. > > > >>> >> > > > >>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > > > >>> >> > > > >>> >> c) UA A and UA B do not support the end-to-end Session > Identifier. > > > >>> >> > > > >>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. > > > >>> >> ----------------- > > > >>> >> > > > >>> >> > > > >>> >> What do you think? > > > >>> > > > > >>> > > > > >>> > Sounds OK to me. I'll put this into me -04 draft and when folk= s > give > > > >>> > me the green light, move it into the WG -01 draft. > > > >>> > > > > >>> > 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 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Wed Jul 11 11:25:32 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A561A11E8121 for ; Wed, 11 Jul 2012 11:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.439 X-Spam-Level: X-Spam-Status: No, score=-1.439 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 QOq2OTC9WuyI for ; Wed, 11 Jul 2012 11:25:31 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 56F9D11E8116 for ; Wed, 11 Jul 2012 11:25:31 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta14.westchester.pa.mail.comcast.net with comcast id Z6Ln1j0011vXlb85E6S4vj; Wed, 11 Jul 2012 18:26:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id Z6S61j00d3ZTu2S3d6S6uo; Wed, 11 Jul 2012 18:26:07 +0000 Message-ID: <4FFDC539.2010905@alum.mit.edu> Date: Wed, 11 Jul 2012 14:26:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 18:25:32 -0000 On 7/11/12 12:01 PM, DRAGE, Keith (Keith) wrote: > I am not tied to the words, they were to get the idea across. > > For my proposed 1B, I take the point that "transaction" is wrong. Maybe adding the words "(or set of concatenated transactions)" will solve that. Maybe, if "set of concatenated transactions" is explained somewhere. > For my proposal 1C, I would argue that "dialog" is absolutely correct here. For 1C I am looking at a single point in space (one entity) and saying all the transactions I see in that dialog have the same identifier. Its true that one goal is that all the transactions in the dialog get the same ID. But its also true that all the dialogs in the same session, or "set of concatenated dialogs" get the same ID. > It is the combination of 1B (all the points that see the transaction) and 1C (all the transactions at this entity that form the dialog) that give me the same identifier for all transactions in a dialog, concatenated across the complete path. We have something like: B2Bx B2By did1 | did2 | did3 ______|_______|______ A-B-C | D-E-F | G-H-I J-K-L | M-N-O | P-Q-R In the above, A,B,...,R are transactions. Each row is a "set of concatenated transactions". "A-B-C" represents related transactions as a request moves from the UAC through proxies, ending at B2Bx. Then more transactions, B2By, etc. The columns did1, did2, did3 are dialogs with their dialog ids. The two rows represent two requests in the same set of related dialogs. So ABC,JKL all carry dialog id did1, etc. So the *desire* is that A...R all get the same session id. The distinction between the transaction case and the dialog case is really very small. Its just the degenerate case of the above where there is only one row. I think what we're trying to say, more or less, is: - all transactions with the same dialog id get the same session id - whenever a b2bua correlates a transaction on one side with a transaction on the other side then both get the same session id. Of course a transaction usually has more than one message - at least a request and a response. Ideally every *message* in every transaction would have the full session id. But that won't be met. The requests in the first message of each dialog will at best get half of the id. The responses will get the full id, except that any to the right of the last one supporting this mechanism won't get the 2nd half. Its actually hard to word the requirements so that they won't be violated for some nodes in some common cases. We'll have to decide whether to leave such requirements and be satisfied with a mechanism that doesn't meet them fully, or find a way to relax the requirements so that we can find a mechanism that fully meets them. Thanks, Paul > Keith > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 11 July 2012 15:51 >> To: insipid@ietf.org >> Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP >> traffic monitoring" use case >> >> I get Keith's point. But the language isn't working for me. >> There are indeed two cases, one related to transactions, and the other >> related to dialogs. But in neither case is it about a single transaction >> or a single dialog, because we have B2BUAs in place. >> >> Rather, in one case we have a set of transactions spliced together by >> B2BUAs. In the other we have a set of dialogs spliced together by >> B2BUAs. Of course a dialog is itself a set of related transactions. But >> the grouping is different. >> >> A transaction is always between two neighboring nodes. When you insert >> proxies in the path there is a separate transaction on each side of the >> proxy, and they are correlated by dialog id. When we introduce a B2BUA >> the situation isn't much different, except that the dialog id isn't >> preserved. So in this case we want the session id to provide the >> correlation that the dialog id doesn't. >> >>> REQ 1B: It must be possible for the same identifier to appear at all >>> entities participating in a SIP transaction, such that an external >>> device that monitors the SIP traffic can use that identifier to >>> correlate the same transaction at each of those entities. >> >> So, "SIP transaction" above is wrong. >> >>> REQ 1C: It must be possible for the same identifier to appear in all >>> transactions that form part of a SIP dialog, such that the transactions >>> that form part of the dialog can be correlated together. There is no >>> requirement for the identifier to correlate parts of a single >>> transaction (i.e. request and response) as existing SIP mechanisms are >>> assumed to do that. There is no requirement for the identifier to >>> correlate two transactions that do not form part of the same dialog >>> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>> MESSAGE transaction and a subsequent MESSAGE transaction), except as >>> expressed in other requirements. >> >> and "SIP dialog" is wrong above. >> >> We have coined the term "session" (as overloaded as it is) for the set >> of dialogs connected by B2BUAs. So maybe it could be used above. >> >> But we have no term proposed for the transactions connected by B2BUAs, >> so its really hard to write 1B. If we want to cover this case then we >> need terminology to describe it. >> >> Thanks, >> Paul >> >> >> >> On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: >>> [As individual] >>> >>> What I took away from the discussion yesterday was: >>> >>> -that REQ 1 represents the session ID requirement for a number of >>> transactions bound up in a dialog, whereas REQ 1A represents the session >>> ID requirement for a transaction not so bound. >>> >>> -For each of these requirements we need to cover the existence over >>> time, and the existence over space. >>> >>> -The existence over space requirement is identical for both, i.e. that >>> UA A, UAB, and all the entities inbetween will be able to see the same >>> session ID, such that some other entity trying to correlate information >>> feeds from these entities will be able to do so. >>> >>> -The existence over time requirement only applies to REQ 1, i.e. that >>> all transactions within the same dialog should share the same session >>> ID. I do not believe there is a requirement for session ID within the >>> transaction, i.e. between request and response - that is dealt with by >>> other mechanisms. We have no requirement for correlation between two >>> transactions that are not within a dialog. >>> >>> While it would be possible to draft this round the existing requirement >>> split, I suggest maybe we just do the split round the time and space >>> division. So the new revised requirements might look like (in place of >>> the existing). >>> >>> REQ 1B: It must be possible for the same identifier to appear at all >>> entities participating in a SIP transaction, such that an external >>> device that monitors the SIP traffic can use that identifier to >>> correlate the same transaction at each of those entities. >>> >>> REQ 1C: It must be possible for the same identifier to appear in all >>> transactions that form part of a SIP dialog, such that the transactions >>> that form part of the dialog can be correlated together. There is no >>> requirement for the identifier to correlate parts of a single >>> transaction (i.e. request and response) as existing SIP mechanisms are >>> assumed to do that. There is no requirement for the identifier to >>> correlate two transactions that do not form part of the same dialog >>> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>> MESSAGE transaction and a subsequent MESSAGE transaction), except as >>> expressed in other requirements. >>> >>> Note the "except" in REQ 1C above is to allow the transfer requirements >>> in REQ2. >>> >>> If the new REQ 1B is acceptable, then we should also consider how >>> distinct that is from REQ 4. >>> >>> Keith >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On >>> Behalf Of *Paul E. Jones >>> *Sent:* 11 July 2012 13:10 >>> *To:* Laura Liess >>> *Cc:* insipid@ietf.org >>> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" >>> use case >>> >>> What shall be the wording of REQ1a? >>> >>> Paul >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*Laura Liess >>> *Sent:* Wed Jul 11 03:14:07 EDT 2012 >>> *To:* "Paul E. Jones" >>> *Cc:* insipid@ietf.org >>> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" >>> use case >>> >>> >>> >>> Paul, >>> >>> >>> >>> After the discussion yesterday in the Webex meeting, it seems to me >>> >>> that separate requirements for dialogs and transactions are needed. >>> >>> >>> >>> Thanks >>> >>> Laura >>> >>> >>> >>> 2012/7/11 Paul E. Jones: >>> >>>> Indeed, you're right. It does cover both, but folks called for a >> separate >>> >>>> requirement. >>> >>>> >>> >>>> What is the wishes of the WG on this? Shall I replace REQ1 with the >> below >>> >>>> text? >>> >>> >>> >>> >>> >>>> >>> >>>> Paul >>> >>>> >>> >>>>> -----Original Message----- >>> >>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf >>> >>>>> Of Laura Liess >>> >>>>> Sent: Tuesday,July 10, 2012 8:23 AM >>> >>>>> To: Paul E. Jones >>> >>>>> Cc: insipid@ietf.org >>> >>>>> Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring" >> use >>> >>>>> case >>> >>>>> >>> >>>>> Paul, >>> >>>>> >>> >>>>> > >>> >>>>> > What was proposed (by you?) was this: >>> >>>>> > >>> >>>>> > REQ1a: It must be possible for an administrator or an external >> device >>> >>>>> > which monitors the SIP-traffic to use the identifier to identify >> those >>> >>>>> > dialogs, transactions and messages which were at some point in >> time >>> >>>>> > components of a single end-to-end SIP session (e.g., parts of the >> same >>> >>>>> call). >>> >>>>> >>> >>>>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as >> it is >>> >>>>> in draft-ietf-insipid-session-id-reqts-00). So I think we could >> replace >>> >>>>> the current text of REQ1 by the proposed text of the REQ1a and then >> drop >>> >>>>> REQ1a. >>> >>>>> >>> >>>>> Thanks >>> >>>>> Laura >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> > >>> >>>>> > This is not presently in t! >>> >>> he draft >>> >>> that we just submitted to be a WG >>> >>>>> > document since I was told to base that document on the -03 draft. >> I >>> >>>>> > had that text in my pending -04 draft, but ... it is still sitting >>> >>>>> > there :-) >>> >>>>> > >>> >>>>> >> > You really want to just remove that text from c)? >>> >>>>> >> [LL] No. I don't. >>> >>>>> >> Also in this scenario the service providers monitors and logs all >>> >>>>> >> B2BUA traffic, incomming and outgoing. There is no log >> provided by >>> >>>>> >> the customer. >>> >>>>> >> >>> >>>>> >> From my point of view, the text would be : >>> >>>>> >> >>> >>>>> >> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>>>> >> User Agent A (A) and User Agent B (B) communicate using SIP >> messaging >>> >>>>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP >> service >>> >>>>> provider. >>> >>>>> >> For privacy reasons, t! >>> >>> he B2BUA >>> >>> changes the SIP headers that reveal >>> >>>>> >> information related to the SIP users, device or domain identity. >> The >>> >>>>> >> service provider uses an external device to monitor and log all >> SIP >>> >>>>> >> traffic coming to and from the B2BUA. In the case of failures >>> >>>>> >> reported by the customer or when security issue arise (e.g. theft >> of >>> >>>>> >> service), the service provider has to analyze the logs from the >> past >>> >>>>> >> several days or weeks and correlates those messages which were >>> >>>>> >> messages for a single end- to-end SIP session. >>> >>>>> >> >>> >>>>> >> For this scenario, we must consider three particular use cases: >>> >>>>> >> >>> >>>>> >> a) The UAs A and B support the end-to-end Session Identifier. >>> >>>>> >> >>> >>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >>> >>>>> >> >>> >>>>> >> b) Only the UA A supports the end-to-end Session Identifier, the >> UA B >>> >>>>> >> does not. >>> >>>>> >> >>> >>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>> >>>>> >> >>> >>>>> >> c) UA A and UA B do not support the end-to-end Session >> Identifier. >>> >>>>> >> >>> >>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>> >>>>> >> ----------------- >>> >>>>> >> >>> >>>>> >> >>> >>>>> >> What do you think? >>> >>>>> > >>> >>>>> > >>> >>>>> > Sounds OK to me. I'll put this into me -04 draft and when folks >> give >>> >>>>> > me the green light, move it into the WG -01 draft. >>> >>>>> > >>> >>>>> > 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 pkyzivat@alum.mit.edu Wed Jul 11 11:51:03 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852B511E80DB for ; Wed, 11 Jul 2012 11:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 ZNVAft4I1dny for ; Wed, 11 Jul 2012 11:51:03 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id E505821F85A8 for ; Wed, 11 Jul 2012 11:51:02 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta10.westchester.pa.mail.comcast.net with comcast id Z6hE1j0010xGWP85A6rcfB; Wed, 11 Jul 2012 18:51:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Z6rN1j0103ZTu2S3Y6rNJK; Wed, 11 Jul 2012 18:51:23 +0000 Message-ID: <4FFDCB34.6070209@alum.mit.edu> Date: Wed, 11 Jul 2012 14:51:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <4FF701F7.8070202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A058534071B990E@ESESSCMS0356.eemea.ericsson.se> <0de001cd5f11$f7dd7160$e7985420$@packetizer.com> In-Reply-To: <0de001cd5f11$f7dd7160$e7985420$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org, "'Olle E. Johansson'" , 'Christer Holmberg' Subject: Re: [Insipid] Use case for association of session signaling and media 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: Wed, 11 Jul 2012 18:51:03 -0000 I suggest replacing these requirements with ones that constrain the form of the id - its encoding and length. These can say *why* these constraints are applied, but in the end we will have something that we can measure. But the constraints should be as liberal as they can be while meeting the need. Thanks, Paul On 7/10/12 11:05 PM, Paul E. Jones wrote: >>> The mechanisms certainly are our of scope. All I was hoping for at >>> this point was to ensure that we do not make it difficult or impossible >> to one day associate media and signaling by making a poor choice in how we >> construct the Session-ID. >> >> But, how would you be able to determine whether the requirement has been >> fulfilled? > > We probably cannot absolutely. However, if we do know of constraints placed > on certain protocols, we could ensure we meet those constraints. For > example, if we were to encode the Session-ID in RTCP, we might place it an > SDES packet. That imposes a length limit of 255 octets. > > The best we can do is to try to avoid making a bad choice. I do not think > we can guarantee it. > > Paul From christer.holmberg@ericsson.com Wed Jul 11 12:09:22 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B78811E8128 for ; Wed, 11 Jul 2012 12:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrfsWNwm1nlC for ; Wed, 11 Jul 2012 12:09:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6A911E811B for ; Wed, 11 Jul 2012 12:09:20 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-27-4ffdcf7ecb46 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E1.2E.03067.E7FCDFF4; Wed, 11 Jul 2012 21:09:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 11 Jul 2012 21:09:50 +0200 From: Christer Holmberg To: Paul Kyzivat , "Paul E. Jones" Date: Wed, 11 Jul 2012 21:09:11 +0200 Thread-Topic: [Insipid] Use case for association of session signaling and media flows Thread-Index: Ac1fljHCsrqHsy+zR9aTv1Sx7viWxgAAnYOU Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853407116814@ESESSCMS0356.eemea.ericsson.se> References: <4FF701F7.8070202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A058534071B990E@ESESSCMS0356.eemea.ericsson.se> <0de001cd5f11$f7dd7160$e7985420$@packetizer.com>, <4FFDCB34.6070209@alum.mit.edu> In-Reply-To: <4FFDCB34.6070209@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvrW79+b/+Bl+2c1vMv/+MyeLl6kPM FucvbGCyWLHhAKsDi8ff9x+YPKatXcnqsWTJTyaPhn1H2QNYorhsUlJzMstSi/TtErgyDv7b y1bwnbvi6afDbA2Mszi7GDk5JARMJFZf2MwOYYtJXLi3nq2LkYtDSOAUo8SfyfvYIZyFjBKf Zx9k7GLk4GATsJDo/qcNYooIBEs8bKgE6WUGMpevu80KYrMIqEo8vNPFCGILC4RJnF09mQnE FhEIl5j+YRMLhG0k0b6vH6yGFyi+5ctURohVV5kljnbPACviFNCROP1yNxuIzQh03PdTa5gg lolL3HoynwniaAGJJXvOM0PYohIvH/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSEWC0qc nPmEZQKj2CwkY2chaZmFpGUWkpYFjCyrGIVzEzNz0svN9VKLMpOLi/Pz9IpTNzECY+zglt8G Oxg33Rc7xCjNwaIkzqunut9fSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NDgr3q7M9VV6f5 X2t7mCJSfH9iHaen6EKu2E1WG89qh0y+dWNJrZVhQ1/K5XWrc+3Oe4v+2cd33tf0yjl3U6OZ bQvZAu3fq7y+ctkgda3s5jij63u+6i+ceHDBTTHdg/5XjJgqyosnOK28v/tyQxrXiZpPWw8/ /GyfrucftffBnF/zyjZZ+ysqsRRnJBpqMRcVJwIAbkBQP38CAAA= Cc: "insipid@ietf.org" , "'Olle E. Johansson'" Subject: Re: [Insipid] Use case for association of session signaling and media 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: Wed, 11 Jul 2012 19:09:22 -0000 Hi, I agree with Paul. Regards, Christer ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Wednesday, July 11, 2012 9:51 PM To: Paul E. Jones Cc: Christer Holmberg; 'Olle E. Johansson'; insipid@ietf.org Subject: Re: [Insipid] Use case for association of session signaling = and media flows I suggest replacing these requirements with ones that constrain the form of the id - its encoding and length. These can say *why* these constraints are applied, but in the end we will have something that we can measure. But the constraints should be as liberal as they can be while meeting the need. Thanks, Paul On 7/10/12 11:05 PM, Paul E. Jones wrote: >>> The mechanisms certainly are our of scope. All I was hoping for at >>> this point was to ensure that we do not make it difficult or impossible >> to one day associate media and signaling by making a poor choice in how = we >> construct the Session-ID. >> >> But, how would you be able to determine whether the requirement has been >> fulfilled? > > We probably cannot absolutely. However, if we do know of constraints pla= ced > on certain protocols, we could ensure we meet those constraints. For > example, if we were to encode the Session-ID in RTCP, we might place it a= n > SDES packet. That imposes a length limit of 255 octets. > > The best we can do is to try to avoid making a bad choice. I do not thin= k > we can guarantee it. > > Paul= From jmpolk@cisco.com Wed Jul 11 12:43:09 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7661A21F8514 for ; Wed, 11 Jul 2012 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.514 X-Spam-Level: X-Spam-Status: No, score=-110.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 odA8k++ibi7q for ; Wed, 11 Jul 2012 12:43:08 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5486721F84F3 for ; Wed, 11 Jul 2012 12:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2660; q=dns/txt; s=iport; t=1342035815; x=1343245415; h=message-id:date:to:from:subject:mime-version; bh=xD46Przv1NxgPd8Y+NIeg46UXKP8379p5iye0oPxKUs=; b=gGP/VD7BpFQMxcSp20OZnVQy5Hu/cepCNAr9/56S1A7Scy2KHJZEEb8S hjTxW8B7pLcu5waATDxWq489EB240/TAec25amiiC7sWplMVS7+1DL03i k5NtjTDXtYbzqrLUipAbM0a0uHE2/UniIksMfL2TNVCspMeiX8SVOBv6t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAP/V/U+rRDoH/2dsb2JhbABFt26BB4IgAQIWASUCVhkhKUQKK4dqnBSBKKAhkS4DiEubD4Fmgn0 X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="48555895" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 11 Jul 2012 19:43:34 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6BJhYAG029194 for ; Wed, 11 Jul 2012 19:43:34 GMT Message-Id: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2012 14:43:34 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Insipid] Session-ID construction choices 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, 11 Jul 2012 19:43:09 -0000 INSIPID From yesterday's interim call, we discussed several things, including some items already discussed on the list in the last 24 hours. I want to focus on the identifier construction, now that we have decided to communicate both parts of the Session-ID, built by both sides, on the wire once the SIP response is transmitted. Sidebar: no one has given us authors any technical reason why this is not a good idea, other than the length of the overall header-value, which many believe is outweighed by the certainty of always having the full Session-ID to analyze in every message (once the response has been transmitted). There are at least 4 ways to construct the whole Session-ID if both halves are present. Whichever way we chose in the final RFC will be unquestionably the only way to do it. Option#1 - attach a prefix (e.g., From: and To:) to each half Option#2 - group together in any order, but each half remains unchanged Option#3 - the half with the lowest value is first, with the higher value half second Option#4 - the initiator of the SIP request half key is first, the responder half key is second. The technical disadvantage for Option #1 is - there is none we are aware of, and might be the cleanest or most clear to humans and servers (i.e., processes/searches/analysis). However, once there is a call join, the From: label loses its meaning. The To: will remain correct. Option #1 does follow call transfer scenarios nicely, and is easiest analyze. The technical disadvantage for Option #2 is - loss of directionality, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. The technical disadvantage for Option #3 is - loss of directionality, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. Could lead to confusion to human analysis having values switched in order. The technical disadvantage for Option #4 is - identical to Option #1 except for tags, which could lead to loss of directionality without ever knowing it, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. We have a proposal going forward: insert the From:/To: tags from Option #1. Does anyone have a technical reason why this wouldn't work? James From jmpolk@cisco.com Wed Jul 11 13:14:17 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C2711E80E7 for ; Wed, 11 Jul 2012 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.618 X-Spam-Level: X-Spam-Status: No, score=-109.618 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 ZhCqhwd4lE2F for ; Wed, 11 Jul 2012 13:14:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7BA11E80EB for ; Wed, 11 Jul 2012 13:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=16631; q=dns/txt; s=iport; t=1342037687; x=1343247287; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=oPiYbpoUf/Ml1sBhvHQfkpD4v0aHM4bvUT7TmZOe2Qk=; b=P8f1VzCPhfL4zjuRqM4b09S1Y3mZQsM9xEvYu/YZM6mlLvohaR2lEzNP 0kUhVT5JuPxNLS7vWK1tY/qQ3OqPAnDSqmym54QX5JWBsY6mOAgvH6MrD eulBOTpdBgIe55M+uBB/wX11KRnXDc1m9qQlijSDj/GATk8RhPSkqR1jR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHfe/U+rRDoJ/2dsb2JhbAA7AQkOt2CBB4IgAQEBBAEBAQ8BJQI0FwQHBA4DBAEBAQwSCQcZDh8JCAYBCQcCIodcAwsMnTSWRg2JSgSKWmYQAYVdA4hLmw+BZoImVyA X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="48558120" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 Jul 2012 20:14:45 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6BKEikq029999; Wed, 11 Jul 2012 20:14:45 GMT Message-Id: <201207112014.q6BKEikq029999@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2012 15:14:44 -0500 To: Paul Kyzivat , From: James Polk In-Reply-To: <4FFDC539.2010905@alum.mit.edu> References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> <4FFDC539.2010905@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 20:14:17 -0000 I was there during the discussions, so I know what Keith is after, therefore I understand the meaning of what he's saying (i.e., I can read between the text he wrote to determine he's after what was agreed to yesterday). At the same time, Paul is right, that the words don't yet match what we need. Paul K. - where this is coming from, is we realized when discussing REQ#1 and (the lack of text for) 1A that we hadn't covered transactions that create dialogs (the original intent for REQ#1) and what was suggested as missing during Interim#1 for non-dialog creating transactions. There was no requirement covering the latter. From that, I like your "set of concatenated transactions" modification to Keith's 1B, but like "set of concatenated non-dialog generating transactions" better, because that's what we're talking about (covering the MESSAGE, OPTIONS, REGISTER, & PUBLISH Methods). Each of these 4 methods are individual and complete transactions that don't carry state between transactions, so the Session-ID must be the same across however many B2BUAs that concatenated series of transactions only until a final response is delivered From that, why don't we go after "set of concatenated dialog generating transactions" for Keith's 1C covering INVITE, ACK, BYE, UPDATE, REFER, SUBSCRIBE, NOTIFY, PRACK, CANCEL, & INFO Methods). When an INVITE, REFER or SUBSCRIBE creates a dialog, regardless of how many B2BUAs that transaction crosses, we want all related concatenated series of transactions to have the same Session-ID, right? isn't SIP complicated? ;-) James At 01:26 PM 7/11/2012, Paul Kyzivat wrote: >On 7/11/12 12:01 PM, DRAGE, Keith (Keith) wrote: >>I am not tied to the words, they were to get the idea across. >> >>For my proposed 1B, I take the point that "transaction" is wrong. >>Maybe adding the words "(or set of concatenated transactions)" will solve that. > >Maybe, if "set of concatenated transactions" is explained somewhere. > >>For my proposal 1C, I would argue that "dialog" is absolutely >>correct here. For 1C I am looking at a single point in space (one >>entity) and saying all the transactions I see in that dialog have >>the same identifier. > >Its true that one goal is that all the transactions in the dialog >get the same ID. But its also true that all the dialogs in the same >session, or "set of concatenated dialogs" get the same ID. > >>It is the combination of 1B (all the points that see the >>transaction) and 1C (all the transactions at this entity that form >>the dialog) that give me the same identifier for all transactions >>in a dialog, concatenated across the complete path. > >We have something like: > > B2Bx B2By > did1 | did2 | did3 > ______|_______|______ > A-B-C | D-E-F | G-H-I > J-K-L | M-N-O | P-Q-R > >In the above, A,B,...,R are transactions. >Each row is a "set of concatenated transactions". >"A-B-C" represents related transactions as a request moves from the >UAC through proxies, ending at B2Bx. Then more transactions, B2By, etc. >The columns did1, did2, did3 are dialogs with their dialog ids. > >The two rows represent two requests in the same set of related dialogs. >So ABC,JKL all carry dialog id did1, etc. > >So the *desire* is that A...R all get the same session id. > >The distinction between the transaction case and the dialog case is >really very small. Its just the degenerate case of the above where >there is only one row. > >I think what we're trying to say, more or less, is: >- all transactions with the same dialog id get the same session id >- whenever a b2bua correlates a transaction on one side with a > transaction on the other side then both get the same session id. > >Of course a transaction usually has more than one message - at least >a request and a response. Ideally every *message* in every >transaction would have the full session id. But that won't be met. >The requests in the first message of each dialog will at best get >half of the id. The responses will get the full id, except that any >to the right of the last one supporting this mechanism won't get the 2nd half. > >Its actually hard to word the requirements so that they won't be >violated for some nodes in some common cases. We'll have to decide >whether to leave such requirements and be satisfied with a mechanism >that doesn't meet them fully, or find a way to relax the >requirements so that we can find a mechanism that fully meets them. > > Thanks, > Paul > >>Keith >> >>>-----Original Message----- >>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >>>Of Paul Kyzivat >>>Sent: 11 July 2012 15:51 >>>To: insipid@ietf.org >>>Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP >>>traffic monitoring" use case >>> >>>I get Keith's point. But the language isn't working for me. >>>There are indeed two cases, one related to transactions, and the other >>>related to dialogs. But in neither case is it about a single transaction >>>or a single dialog, because we have B2BUAs in place. >>> >>>Rather, in one case we have a set of transactions spliced together by >>>B2BUAs. In the other we have a set of dialogs spliced together by >>>B2BUAs. Of course a dialog is itself a set of related transactions. But >>>the grouping is different. >>> >>>A transaction is always between two neighboring nodes. When you insert >>>proxies in the path there is a separate transaction on each side of the >>>proxy, and they are correlated by dialog id. When we introduce a B2BUA >>>the situation isn't much different, except that the dialog id isn't >>>preserved. So in this case we want the session id to provide the >>>correlation that the dialog id doesn't. >>> >>>>REQ 1B: It must be possible for the same identifier to appear at all >>>>entities participating in a SIP transaction, such that an external >>>>device that monitors the SIP traffic can use that identifier to >>>>correlate the same transaction at each of those entities. >>> >>>So, "SIP transaction" above is wrong. >>> >>>>REQ 1C: It must be possible for the same identifier to appear in all >>>>transactions that form part of a SIP dialog, such that the transactions >>>>that form part of the dialog can be correlated together. There is no >>>>requirement for the identifier to correlate parts of a single >>>>transaction (i.e. request and response) as existing SIP mechanisms are >>>>assumed to do that. There is no requirement for the identifier to >>>>correlate two transactions that do not form part of the same dialog >>>>(e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>>>MESSAGE transaction and a subsequent MESSAGE transaction), except as >>>>expressed in other requirements. >>> >>>and "SIP dialog" is wrong above. >>> >>>We have coined the term "session" (as overloaded as it is) for the set >>>of dialogs connected by B2BUAs. So maybe it could be used above. >>> >>>But we have no term proposed for the transactions connected by B2BUAs, >>>so its really hard to write 1B. If we want to cover this case then we >>>need terminology to describe it. >>> >>> Thanks, >>> Paul >>> >>> >>> >>>On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: >>>>[As individual] >>>> >>>>What I took away from the discussion yesterday was: >>>> >>>>-that REQ 1 represents the session ID requirement for a number of >>>>transactions bound up in a dialog, whereas REQ 1A represents the session >>>>ID requirement for a transaction not so bound. >>>> >>>>-For each of these requirements we need to cover the existence over >>>>time, and the existence over space. >>>> >>>>-The existence over space requirement is identical for both, i.e. that >>>>UA A, UAB, and all the entities inbetween will be able to see the same >>>>session ID, such that some other entity trying to correlate information >>>>feeds from these entities will be able to do so. >>>> >>>>-The existence over time requirement only applies to REQ 1, i.e. that >>>>all transactions within the same dialog should share the same session >>>>ID. I do not believe there is a requirement for session ID within the >>>>transaction, i.e. between request and response - that is dealt with by >>>>other mechanisms. We have no requirement for correlation between two >>>>transactions that are not within a dialog. >>>> >>>>While it would be possible to draft this round the existing requirement >>>>split, I suggest maybe we just do the split round the time and space >>>>division. So the new revised requirements might look like (in place of >>>>the existing). >>>> >>>>REQ 1B: It must be possible for the same identifier to appear at all >>>>entities participating in a SIP transaction, such that an external >>>>device that monitors the SIP traffic can use that identifier to >>>>correlate the same transaction at each of those entities. >>>> >>>>REQ 1C: It must be possible for the same identifier to appear in all >>>>transactions that form part of a SIP dialog, such that the transactions >>>>that form part of the dialog can be correlated together. There is no >>>>requirement for the identifier to correlate parts of a single >>>>transaction (i.e. request and response) as existing SIP mechanisms are >>>>assumed to do that. There is no requirement for the identifier to >>>>correlate two transactions that do not form part of the same dialog >>>>(e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>>>MESSAGE transaction and a subsequent MESSAGE transaction), except as >>>>expressed in other requirements. >>>> >>>>Note the "except" in REQ 1C above is to allow the transfer requirements >>>>in REQ2. >>>> >>>>If the new REQ 1B is acceptable, then we should also consider how >>>>distinct that is from REQ 4. >>>> >>>>Keith >>>> >>>>------------------------------------------------------------------------ >>>> >>>>*From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On >>>>Behalf Of *Paul E. Jones >>>>*Sent:* 11 July 2012 13:10 >>>>*To:* Laura Liess >>>>*Cc:* insipid@ietf.org >>>>*Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" >>>>use case >>>> >>>>What shall be the wording of REQ1a? >>>> >>>>Paul >>>> >>>>------------------------------------------------------------------------ >>>> >>>>*From:*Laura Liess >>>>*Sent:* Wed Jul 11 03:14:07 EDT 2012 >>>>*To:* "Paul E. Jones" >>>>*Cc:* insipid@ietf.org >>>>*Subject:* Re: [Insipid] Text proposal for the "SIP traffic monitoring" >>>>use case >>>> >>>> >>>> >>>>Paul, >>>> >>>> >>>> >>>>After the discussion yesterday in the Webex meeting, it seems to me >>>> >>>>that separate requirements for dialogs and transactions are needed. >>>> >>>> >>>> >>>>Thanks >>>> >>>>Laura >>>> >>>> >>>> >>>>2012/7/11 Paul E. Jones: >>>> >>>>> Indeed, you're right. It does cover both, but folks called for a >>>separate >>>> >>>>> requirement. >>>> >>>> >>>>> What is the wishes of the WG on this? Shall I replace REQ1 with the >>>below >>>> >>>>> text? >>>> >>>> >>>> >>>> >>>> >>>> >>>>> Paul >>>> >>>> >>>>>> -----Original Message----- >>>> >>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>Behalf >>>> >>>>>> Of Laura Liess >>>> >>>>>> Sent: Tuesday,July 10, 2012 8:23 AM >>>> >>>>>> To: Paul E. Jones >>>> >>>>>> Cc: insipid@ietf.org >>>> >>>>>> Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring" >>>use >>>> >>>>>> case >>>> >>>> >>>>>> Paul, >>>> >>>> >>>>>> > >>>> >>>>>> > What was proposed (by you?) was this: >>>> >>>>>> > >>>> >>>>>> > REQ1a: It must be possible for an administrator or an external >>>device >>>> >>>>>> > which monitors the SIP-traffic to use the identifier to identify >>>those >>>> >>>>>> > dialogs, transactions and messages which were at some point in >>>time >>>> >>>>>> > components of a single end-to-end SIP session (e.g., parts of the >>>same >>>> >>>>>> call). >>>> >>>> >>>>>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as >>>it is >>>> >>>>>> in draft-ietf-insipid-session-id-reqts-00). So I think we could >>>replace >>>> >>>>>> the current text of REQ1 by the proposed text of the REQ1a and then >>>drop >>>> >>>>>> REQ1a. >>>> >>>> >>>>>> Thanks >>>> >>>>>> Laura >>>> >>>> >>>> >>>> >>>> >>>>>> > >>>> >>>>>> > This is not presently in t! >>>> >>>> he draft >>>> >>>>that we just submitted to be a WG >>>> >>>>>> > document since I was told to base that document on the -03 draft. >>>I >>>> >>>>>> > had that text in my pending -04 draft, but ... it is still sitting >>>> >>>>>> > there :-) >>>> >>>>>> > >>>> >>>>>> >> > You really want to just remove that text from c)? >>>> >>>>>> >> [LL] No. I don't. >>>> >>>>>> >> Also in this scenario the service providers monitors and logs all >>>> >>>>>> >> B2BUA traffic, incomming and outgoing. There is no log >>>provided by >>>> >>>>>> >> the customer. >>>> >>>>>> >> >>>> >>>>>> >> From my point of view, the text would be : >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>>>> >> User Agent A (A) and User Agent B (B) communicate using SIP >>>messaging >>>> >>>>>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP >>>service >>>> >>>>>> provider. >>>> >>>>>> >> For privacy reasons, t! >>>> >>>> he B2BUA >>>> >>>>changes the SIP headers that reveal >>>> >>>>>> >> information related to the SIP users, device or domain identity. >>>The >>>> >>>>>> >> service provider uses an external device to monitor and log all >>>SIP >>>> >>>>>> >> traffic coming to and from the B2BUA. In the case of failures >>>> >>>>>> >> reported by the customer or when security issue arise (e.g. theft >>>of >>>> >>>>>> >> service), the service provider has to analyze the logs from the >>>past >>>> >>>>>> >> several days or weeks and correlates those messages which were >>>> >>>>>> >> messages for a single end- to-end SIP session. >>>> >>>>>> >> >>>> >>>>>> >> For this scenario, we must consider three particular use cases: >>>> >>>>>> >> >>>> >>>>>> >> a) The UAs A and B support the end-to-end Session Identifier. >>>> >>>>>> >> >>>> >>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >>>> >>>>>> >> >>>> >>>>>> >> b) Only the UA A supports the end-to-end Session Identifier, the >>>UA B >>>> >>>>>> >> does not. >>>> >>>>>> >> >>>> >>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>>> >>>>>> >> >>>> >>>>>> >> c) UA A and UA B do not support the end-to-end Session >>>Identifier. >>>> >>>>>> >> >>>> >>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>>> >>>>>> >> ----------------- >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> >> What do you think? >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > Sounds OK to me. I'll put this into me -04 draft and when folks >>>give >>>> >>>>>> > me the green light, move it into the WG -01 draft. >>>> >>>>>> > >>>> >>>>>> > 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 pkyzivat@alum.mit.edu Wed Jul 11 13:42:55 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D05C21F863D for ; Wed, 11 Jul 2012 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 RExNPDEwX388 for ; Wed, 11 Jul 2012 13:42:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7530521F863C for ; Wed, 11 Jul 2012 13:42:48 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id Yyff1j0010xGWP8538jNQq; Wed, 11 Jul 2012 20:43:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Z8j91j0093ZTu2S3Y8j9lt; Wed, 11 Jul 2012 20:43:09 +0000 Message-ID: <4FFDE567.4000802@alum.mit.edu> Date: Wed, 11 Jul 2012 16:43:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Polk References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> <4FFDC539.2010905@alum.mit.edu> <201207112014.q6BKEikq029999@mtv-core-4.cisco.com> In-Reply-To: <201207112014.q6BKEikq029999@mtv-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 20:42:55 -0000 What I realized while writing the last message (and tried to convey, perhaps unsuccessfully) is that I don't think there is any need to distinguish between dialog establishing, non-dialog establishing, and in-dialog transactions. A even non-dialog-forming transactions have callids and dialog ids. Its just that the non-dialog-forming ones are only used once, while the dialog forming ones are used for the duration of the dialog. So a non-dialog transaction is just like a dialog with just one transaction. (E.g. an OPTIONS and an INVITE that gets an immediate 4xx are treated the same with regard to dialog id and session id.) So, we don't need to treat them separately. So I was suggesting what seemed like a simpler way to look at it. Thanks, Paul On 7/11/12 4:14 PM, James Polk wrote: > I was there during the discussions, so I know what Keith is after, > therefore I understand the meaning of what he's saying (i.e., I can read > between the text he wrote to determine he's after what was agreed to > yesterday). At the same time, Paul is right, that the words don't yet > match what we need. > > Paul K. - where this is coming from, is we realized when discussing > REQ#1 and (the lack of text for) 1A that we hadn't covered transactions > that create dialogs (the original intent for REQ#1) and what was > suggested as missing during Interim#1 for non-dialog creating > transactions. There was no requirement covering the latter. > > From that, I like your "set of concatenated transactions" modification > to Keith's 1B, but like "set of concatenated non-dialog generating > transactions" better, because that's what we're talking about (covering > the MESSAGE, OPTIONS, REGISTER, & PUBLISH Methods). Each of these 4 > methods are individual and complete transactions that don't carry state > between transactions, so the Session-ID must be the same across however > many B2BUAs that concatenated series of transactions only until a final > response is delivered > > From that, why don't we go after "set of concatenated dialog generating > transactions" for Keith's 1C covering INVITE, ACK, BYE, UPDATE, REFER, > SUBSCRIBE, NOTIFY, PRACK, CANCEL, & INFO Methods). When an INVITE, REFER > or SUBSCRIBE creates a dialog, regardless of how many B2BUAs that > transaction crosses, we want all related concatenated series of > transactions to have the same Session-ID, right? > > isn't SIP complicated? > > ;-) > > James > > At 01:26 PM 7/11/2012, Paul Kyzivat wrote: >> On 7/11/12 12:01 PM, DRAGE, Keith (Keith) wrote: >>> I am not tied to the words, they were to get the idea across. >>> >>> For my proposed 1B, I take the point that "transaction" is wrong. >>> Maybe adding the words "(or set of concatenated transactions)" will >>> solve that. >> >> Maybe, if "set of concatenated transactions" is explained somewhere. >> >>> For my proposal 1C, I would argue that "dialog" is absolutely correct >>> here. For 1C I am looking at a single point in space (one entity) and >>> saying all the transactions I see in that dialog have the same >>> identifier. >> >> Its true that one goal is that all the transactions in the dialog get >> the same ID. But its also true that all the dialogs in the same >> session, or "set of concatenated dialogs" get the same ID. >> >>> It is the combination of 1B (all the points that see the transaction) >>> and 1C (all the transactions at this entity that form the dialog) >>> that give me the same identifier for all transactions in a dialog, >>> concatenated across the complete path. >> >> We have something like: >> >> B2Bx B2By >> did1 | did2 | did3 >> ______|_______|______ >> A-B-C | D-E-F | G-H-I >> J-K-L | M-N-O | P-Q-R >> >> In the above, A,B,...,R are transactions. >> Each row is a "set of concatenated transactions". >> "A-B-C" represents related transactions as a request moves from the >> UAC through proxies, ending at B2Bx. Then more transactions, B2By, etc. >> The columns did1, did2, did3 are dialogs with their dialog ids. >> >> The two rows represent two requests in the same set of related dialogs. >> So ABC,JKL all carry dialog id did1, etc. >> >> So the *desire* is that A...R all get the same session id. >> >> The distinction between the transaction case and the dialog case is >> really very small. Its just the degenerate case of the above where >> there is only one row. >> >> I think what we're trying to say, more or less, is: >> - all transactions with the same dialog id get the same session id >> - whenever a b2bua correlates a transaction on one side with a >> transaction on the other side then both get the same session id. >> >> Of course a transaction usually has more than one message - at least a >> request and a response. Ideally every *message* in every transaction >> would have the full session id. But that won't be met. The requests in >> the first message of each dialog will at best get half of the id. The >> responses will get the full id, except that any to the right of the >> last one supporting this mechanism won't get the 2nd half. >> >> Its actually hard to word the requirements so that they won't be >> violated for some nodes in some common cases. We'll have to decide >> whether to leave such requirements and be satisfied with a mechanism >> that doesn't meet them fully, or find a way to relax the requirements >> so that we can find a mechanism that fully meets them. >> >> Thanks, >> Paul >> >>> Keith >>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf >>>> Of Paul Kyzivat >>>> Sent: 11 July 2012 15:51 >>>> To: insipid@ietf.org >>>> Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP >>>> traffic monitoring" use case >>>> >>>> I get Keith's point. But the language isn't working for me. >>>> There are indeed two cases, one related to transactions, and the other >>>> related to dialogs. But in neither case is it about a single >>>> transaction >>>> or a single dialog, because we have B2BUAs in place. >>>> >>>> Rather, in one case we have a set of transactions spliced together by >>>> B2BUAs. In the other we have a set of dialogs spliced together by >>>> B2BUAs. Of course a dialog is itself a set of related transactions. But >>>> the grouping is different. >>>> >>>> A transaction is always between two neighboring nodes. When you insert >>>> proxies in the path there is a separate transaction on each side of the >>>> proxy, and they are correlated by dialog id. When we introduce a B2BUA >>>> the situation isn't much different, except that the dialog id isn't >>>> preserved. So in this case we want the session id to provide the >>>> correlation that the dialog id doesn't. >>>> >>>>> REQ 1B: It must be possible for the same identifier to appear at all >>>>> entities participating in a SIP transaction, such that an external >>>>> device that monitors the SIP traffic can use that identifier to >>>>> correlate the same transaction at each of those entities. >>>> >>>> So, "SIP transaction" above is wrong. >>>> >>>>> REQ 1C: It must be possible for the same identifier to appear in all >>>>> transactions that form part of a SIP dialog, such that the >>>>> transactions >>>>> that form part of the dialog can be correlated together. There is no >>>>> requirement for the identifier to correlate parts of a single >>>>> transaction (i.e. request and response) as existing SIP mechanisms are >>>>> assumed to do that. There is no requirement for the identifier to >>>>> correlate two transactions that do not form part of the same dialog >>>>> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>>>> MESSAGE transaction and a subsequent MESSAGE transaction), except as >>>>> expressed in other requirements. >>>> >>>> and "SIP dialog" is wrong above. >>>> >>>> We have coined the term "session" (as overloaded as it is) for the set >>>> of dialogs connected by B2BUAs. So maybe it could be used above. >>>> >>>> But we have no term proposed for the transactions connected by B2BUAs, >>>> so its really hard to write 1B. If we want to cover this case then we >>>> need terminology to describe it. >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>> >>>> On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: >>>>> [As individual] >>>>> >>>>> What I took away from the discussion yesterday was: >>>>> >>>>> -that REQ 1 represents the session ID requirement for a number of >>>>> transactions bound up in a dialog, whereas REQ 1A represents the >>>>> session >>>>> ID requirement for a transaction not so bound. >>>>> >>>>> -For each of these requirements we need to cover the existence over >>>>> time, and the existence over space. >>>>> >>>>> -The existence over space requirement is identical for both, i.e. that >>>>> UA A, UAB, and all the entities inbetween will be able to see the same >>>>> session ID, such that some other entity trying to correlate >>>>> information >>>>> feeds from these entities will be able to do so. >>>>> >>>>> -The existence over time requirement only applies to REQ 1, i.e. that >>>>> all transactions within the same dialog should share the same session >>>>> ID. I do not believe there is a requirement for session ID within the >>>>> transaction, i.e. between request and response - that is dealt with by >>>>> other mechanisms. We have no requirement for correlation between two >>>>> transactions that are not within a dialog. >>>>> >>>>> While it would be possible to draft this round the existing >>>>> requirement >>>>> split, I suggest maybe we just do the split round the time and space >>>>> division. So the new revised requirements might look like (in place of >>>>> the existing). >>>>> >>>>> REQ 1B: It must be possible for the same identifier to appear at all >>>>> entities participating in a SIP transaction, such that an external >>>>> device that monitors the SIP traffic can use that identifier to >>>>> correlate the same transaction at each of those entities. >>>>> >>>>> REQ 1C: It must be possible for the same identifier to appear in all >>>>> transactions that form part of a SIP dialog, such that the >>>>> transactions >>>>> that form part of the dialog can be correlated together. There is no >>>>> requirement for the identifier to correlate parts of a single >>>>> transaction (i.e. request and response) as existing SIP mechanisms are >>>>> assumed to do that. There is no requirement for the identifier to >>>>> correlate two transactions that do not form part of the same dialog >>>>> (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>>>> MESSAGE transaction and a subsequent MESSAGE transaction), except as >>>>> expressed in other requirements. >>>>> >>>>> Note the "except" in REQ 1C above is to allow the transfer >>>>> requirements >>>>> in REQ2. >>>>> >>>>> If the new REQ 1B is acceptable, then we should also consider how >>>>> distinct that is from REQ 4. >>>>> >>>>> Keith >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> *From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On >>>>> Behalf Of *Paul E. Jones >>>>> *Sent:* 11 July 2012 13:10 >>>>> *To:* Laura Liess >>>>> *Cc:* insipid@ietf.org >>>>> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic >>>>> monitoring" >>>>> use case >>>>> >>>>> What shall be the wording of REQ1a? >>>>> >>>>> Paul >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> *From:*Laura Liess >>>>> *Sent:* Wed Jul 11 03:14:07 EDT 2012 >>>>> *To:* "Paul E. Jones" >>>>> *Cc:* insipid@ietf.org >>>>> *Subject:* Re: [Insipid] Text proposal for the "SIP traffic >>>>> monitoring" >>>>> use case >>>>> >>>>> >>>>> >>>>> Paul, >>>>> >>>>> >>>>> >>>>> After the discussion yesterday in the Webex meeting, it seems to me >>>>> >>>>> that separate requirements for dialogs and transactions are needed. >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Laura >>>>> >>>>> >>>>> >>>>> 2012/7/11 Paul E. Jones: >>>>> >>>>>> Indeed, you're right. It does cover both, but folks called for a >>>> separate >>>>> >>>>>> requirement. >>>>> >>>>> >>>>>> What is the wishes of the WG on this? Shall I replace REQ1 with the >>>> below >>>>> >>>>>> text? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Paul >>>>> >>>>> >>>>>>> -----Original Message----- >>>>> >>>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf >>>>> >>>>>>> Of Laura Liess >>>>> >>>>>>> Sent: Tuesday,July 10, 2012 8:23 AM >>>>> >>>>>>> To: Paul E. Jones >>>>> >>>>>>> Cc: insipid@ietf.org >>>>> >>>>>>> Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring" >>>> use >>>>> >>>>>>> case >>>>> >>>>> >>>>>>> Paul, >>>>> >>>>> >>>>>>> > >>>>> >>>>>>> > What was proposed (by you?) was this: >>>>> >>>>>>> > >>>>> >>>>>>> > REQ1a: It must be possible for an administrator or an external >>>> device >>>>> >>>>>>> > which monitors the SIP-traffic to use the identifier to identify >>>> those >>>>> >>>>>>> > dialogs, transactions and messages which were at some point in >>>> time >>>>> >>>>>>> > components of a single end-to-end SIP session (e.g., parts of the >>>> same >>>>> >>>>>>> call). >>>>> >>>>> >>>>>>> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as >>>> it is >>>>> >>>>>>> in draft-ietf-insipid-session-id-reqts-00). So I think we could >>>> replace >>>>> >>>>>>> the current text of REQ1 by the proposed text of the REQ1a and then >>>> drop >>>>> >>>>>>> REQ1a. >>>>> >>>>> >>>>>>> Thanks >>>>> >>>>>>> Laura >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> > >>>>> >>>>>>> > This is not presently in t! >>>>> >>>>> he draft >>>>> >>>>> that we just submitted to be a WG >>>>> >>>>>>> > document since I was told to base that document on the -03 draft. >>>> I >>>>> >>>>>>> > had that text in my pending -04 draft, but ... it is still sitting >>>>> >>>>>>> > there :-) >>>>> >>>>>>> > >>>>> >>>>>>> >> > You really want to just remove that text from c)? >>>>> >>>>>>> >> [LL] No. I don't. >>>>> >>>>>>> >> Also in this scenario the service providers monitors and logs all >>>>> >>>>>>> >> B2BUA traffic, incomming and outgoing. There is no log >>>> provided by >>>>> >>>>>>> >> the customer. >>>>> >>>>>>> >> >>>>> >>>>>>> >> From my point of view, the text would be : >>>>> >>>>>>> >> >>>>> >>>>>>> >> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> >> User Agent A (A) and User Agent B (B) communicate using SIP >>>> messaging >>>>> >>>>>>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP >>>> service >>>>> >>>>>>> provider. >>>>> >>>>>>> >> For privacy reasons, t! >>>>> >>>>> he B2BUA >>>>> >>>>> changes the SIP headers that reveal >>>>> >>>>>>> >> information related to the SIP users, device or domain identity. >>>> The >>>>> >>>>>>> >> service provider uses an external device to monitor and log all >>>> SIP >>>>> >>>>>>> >> traffic coming to and from the B2BUA. In the case of failures >>>>> >>>>>>> >> reported by the customer or when security issue arise (e.g. theft >>>> of >>>>> >>>>>>> >> service), the service provider has to analyze the logs from the >>>> past >>>>> >>>>>>> >> several days or weeks and correlates those messages which were >>>>> >>>>>>> >> messages for a single end- to-end SIP session. >>>>> >>>>>>> >> >>>>> >>>>>>> >> For this scenario, we must consider three particular use cases: >>>>> >>>>>>> >> >>>>> >>>>>>> >> a) The UAs A and B support the end-to-end Session Identifier. >>>>> >>>>>>> >> >>>>> >>>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >>>>> >>>>>>> >> >>>>> >>>>>>> >> b) Only the UA A supports the end-to-end Session Identifier, the >>>> UA B >>>>> >>>>>>> >> does not. >>>>> >>>>>>> >> >>>>> >>>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>>>> >>>>>>> >> >>>>> >>>>>>> >> c) UA A and UA B do not support the end-to-end Session >>>> Identifier. >>>>> >>>>>>> >> >>>>> >>>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>>>> >>>>>>> >> ----------------- >>>>> >>>>>>> >> >>>>> >>>>>>> >> >>>>> >>>>>>> >> What do you think? >>>>> >>>>>>> > >>>>> >>>>>>> > >>>>> >>>>>>> > Sounds OK to me. I'll put this into me -04 draft and when folks >>>> give >>>>> >>>>>>> > me the green light, move it into the WG -01 draft. >>>>> >>>>>>> > >>>>> >>>>>>> > 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 jmpolk@cisco.com Wed Jul 11 13:48:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DC511E80F5 for ; Wed, 11 Jul 2012 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.581 X-Spam-Level: X-Spam-Status: No, score=-109.581 tagged_above=-999 required=5 tests=[AWL=-0.782, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_74=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 qBS-bpkiFC85 for ; Wed, 11 Jul 2012 13:48:55 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4F011E80BD for ; Wed, 11 Jul 2012 13:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=18694; q=dns/txt; s=iport; t=1342039767; x=1343249367; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=4tSK5rHiOO+IGRqQaGkZdFISg2uOLWyy+7hgsnsT1bE=; b=NAJfpzFnxkSsXL1LXAlKv31/Rye1M5dd9illtcQbf93GZDIpejxpgHrB rpZ1G4+Libr1gBoQ9XjB9JdjtzpGmwqXUWI6NSyyybmIdOqwI6XEC+C4a T4WlzjcccfD5w0OPprsDjiIzpfOdvd/HoyF6hDt4XxXcut71TpySL4JTR s=; X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="51591605" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 11 Jul 2012 20:49:25 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6BKnOLI016465; Wed, 11 Jul 2012 20:49:24 GMT Message-Id: <201207112049.q6BKnOLI016465@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2012 15:49:24 -0500 To: Paul Kyzivat , James Polk From: James Polk In-Reply-To: <4FFDE567.4000802@alum.mit.edu> References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <4FFD92EB.1000404@alum.mit.edu> <4FFDC539.2010905@alum.mit.edu> <201207112014.q6BKEikq029999@mtv-core-4.cisco.com> <4FFDE567.4000802@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 11 Jul 2012 20:48:57 -0000 Not having to parse out the differences between dialog establishing, non-dialog establishing, and in-dialog transactions would be far easier to write. I guess what I'm proposing is to have a single requirement cover all types of transactions (or just SIP messages) equally - i.e., they all have a Session-ID, with the in-dialog transactions using the same Session-ID as the dialog establishing message(s). Do others agree? James At 03:43 PM 7/11/2012, Paul Kyzivat wrote: >What I realized while writing the last message (and tried to convey, >perhaps unsuccessfully) is that I don't think there is any need to >distinguish between dialog establishing, non-dialog establishing, >and in-dialog transactions. > >A even non-dialog-forming transactions have callids and dialog ids. >Its just that the non-dialog-forming ones are only used once, while >the dialog forming ones are used for the duration of the dialog. So >a non-dialog transaction is just like a dialog with just one >transaction. (E.g. an OPTIONS and an INVITE that gets an immediate >4xx are treated the same with regard to dialog id and session id.) > >So, we don't need to treat them separately. So I was suggesting what >seemed like a simpler way to look at it. > > Thanks, > Paul > >On 7/11/12 4:14 PM, James Polk wrote: >>I was there during the discussions, so I know what Keith is after, >>therefore I understand the meaning of what he's saying (i.e., I can read >>between the text he wrote to determine he's after what was agreed to >>yesterday). At the same time, Paul is right, that the words don't yet >>match what we need. >> >>Paul K. - where this is coming from, is we realized when discussing >>REQ#1 and (the lack of text for) 1A that we hadn't covered transactions >>that create dialogs (the original intent for REQ#1) and what was >>suggested as missing during Interim#1 for non-dialog creating >>transactions. There was no requirement covering the latter. >> >> From that, I like your "set of concatenated transactions" modification >>to Keith's 1B, but like "set of concatenated non-dialog generating >>transactions" better, because that's what we're talking about (covering >>the MESSAGE, OPTIONS, REGISTER, & PUBLISH Methods). Each of these 4 >>methods are individual and complete transactions that don't carry state >>between transactions, so the Session-ID must be the same across however >>many B2BUAs that concatenated series of transactions only until a final >>response is delivered >> >> From that, why don't we go after "set of concatenated dialog generating >>transactions" for Keith's 1C covering INVITE, ACK, BYE, UPDATE, REFER, >>SUBSCRIBE, NOTIFY, PRACK, CANCEL, & INFO Methods). When an INVITE, REFER >>or SUBSCRIBE creates a dialog, regardless of how many B2BUAs that >>transaction crosses, we want all related concatenated series of >>transactions to have the same Session-ID, right? >> >>isn't SIP complicated? >> >>;-) >> >>James >> >>At 01:26 PM 7/11/2012, Paul Kyzivat wrote: >>>On 7/11/12 12:01 PM, DRAGE, Keith (Keith) wrote: >>>>I am not tied to the words, they were to get the idea across. >>>> >>>>For my proposed 1B, I take the point that "transaction" is wrong. >>>>Maybe adding the words "(or set of concatenated transactions)" will >>>>solve that. >>> >>>Maybe, if "set of concatenated transactions" is explained somewhere. >>> >>>>For my proposal 1C, I would argue that "dialog" is absolutely correct >>>>here. For 1C I am looking at a single point in space (one entity) and >>>>saying all the transactions I see in that dialog have the same >>>>identifier. >>> >>>Its true that one goal is that all the transactions in the dialog get >>>the same ID. But its also true that all the dialogs in the same >>>session, or "set of concatenated dialogs" get the same ID. >>> >>>>It is the combination of 1B (all the points that see the transaction) >>>>and 1C (all the transactions at this entity that form the dialog) >>>>that give me the same identifier for all transactions in a dialog, >>>>concatenated across the complete path. >>> >>>We have something like: >>> >>>B2Bx B2By >>>did1 | did2 | did3 >>>______|_______|______ >>>A-B-C | D-E-F | G-H-I >>>J-K-L | M-N-O | P-Q-R >>> >>>In the above, A,B,...,R are transactions. >>>Each row is a "set of concatenated transactions". >>>"A-B-C" represents related transactions as a request moves from the >>>UAC through proxies, ending at B2Bx. Then more transactions, B2By, etc. >>>The columns did1, did2, did3 are dialogs with their dialog ids. >>> >>>The two rows represent two requests in the same set of related dialogs. >>>So ABC,JKL all carry dialog id did1, etc. >>> >>>So the *desire* is that A...R all get the same session id. >>> >>>The distinction between the transaction case and the dialog case is >>>really very small. Its just the degenerate case of the above where >>>there is only one row. >>> >>>I think what we're trying to say, more or less, is: >>>- all transactions with the same dialog id get the same session id >>>- whenever a b2bua correlates a transaction on one side with a >>>transaction on the other side then both get the same session id. >>> >>>Of course a transaction usually has more than one message - at least a >>>request and a response. Ideally every *message* in every transaction >>>would have the full session id. But that won't be met. The requests in >>>the first message of each dialog will at best get half of the id. The >>>responses will get the full id, except that any to the right of the >>>last one supporting this mechanism won't get the 2nd half. >>> >>>Its actually hard to word the requirements so that they won't be >>>violated for some nodes in some common cases. We'll have to decide >>>whether to leave such requirements and be satisfied with a mechanism >>>that doesn't meet them fully, or find a way to relax the requirements >>>so that we can find a mechanism that fully meets them. >>> >>>Thanks, >>>Paul >>> >>>>Keith >>>> >>>>>-----Original Message----- >>>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>Behalf >>>>>Of Paul Kyzivat >>>>>Sent: 11 July 2012 15:51 >>>>>To: insipid@ietf.org >>>>>Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP >>>>>traffic monitoring" use case >>>>> >>>>>I get Keith's point. But the language isn't working for me. >>>>>There are indeed two cases, one related to transactions, and the other >>>>>related to dialogs. But in neither case is it about a single >>>>>transaction >>>>>or a single dialog, because we have B2BUAs in place. >>>>> >>>>>Rather, in one case we have a set of transactions spliced together by >>>>>B2BUAs. In the other we have a set of dialogs spliced together by >>>>>B2BUAs. Of course a dialog is itself a set of related transactions. But >>>>>the grouping is different. >>>>> >>>>>A transaction is always between two neighboring nodes. When you insert >>>>>proxies in the path there is a separate transaction on each side of the >>>>>proxy, and they are correlated by dialog id. When we introduce a B2BUA >>>>>the situation isn't much different, except that the dialog id isn't >>>>>preserved. So in this case we want the session id to provide the >>>>>correlation that the dialog id doesn't. >>>>> >>>>>>REQ 1B: It must be possible for the same identifier to appear at all >>>>>>entities participating in a SIP transaction, such that an external >>>>>>device that monitors the SIP traffic can use that identifier to >>>>>>correlate the same transaction at each of those entities. >>>>> >>>>>So, "SIP transaction" above is wrong. >>>>> >>>>>>REQ 1C: It must be possible for the same identifier to appear in all >>>>>>transactions that form part of a SIP dialog, such that the >>>>>>transactions >>>>>>that form part of the dialog can be correlated together. There is no >>>>>>requirement for the identifier to correlate parts of a single >>>>>>transaction (i.e. request and response) as existing SIP mechanisms are >>>>>>assumed to do that. There is no requirement for the identifier to >>>>>>correlate two transactions that do not form part of the same dialog >>>>>>(e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>>>>>MESSAGE transaction and a subsequent MESSAGE transaction), except as >>>>>>expressed in other requirements. >>>>> >>>>>and "SIP dialog" is wrong above. >>>>> >>>>>We have coined the term "session" (as overloaded as it is) for the set >>>>>of dialogs connected by B2BUAs. So maybe it could be used above. >>>>> >>>>>But we have no term proposed for the transactions connected by B2BUAs, >>>>>so its really hard to write 1B. If we want to cover this case then we >>>>>need terminology to describe it. >>>>> >>>>>Thanks, >>>>>Paul >>>>> >>>>> >>>>> >>>>>On 7/11/12 9:02 AM, DRAGE, Keith (Keith) wrote: >>>>>>[As individual] >>>>>> >>>>>>What I took away from the discussion yesterday was: >>>>>> >>>>>>-that REQ 1 represents the session ID requirement for a number of >>>>>>transactions bound up in a dialog, whereas REQ 1A represents the >>>>>>session >>>>>>ID requirement for a transaction not so bound. >>>>>> >>>>>>-For each of these requirements we need to cover the existence over >>>>>>time, and the existence over space. >>>>>> >>>>>>-The existence over space requirement is identical for both, i.e. that >>>>>>UA A, UAB, and all the entities inbetween will be able to see the same >>>>>>session ID, such that some other entity trying to correlate >>>>>>information >>>>>>feeds from these entities will be able to do so. >>>>>> >>>>>>-The existence over time requirement only applies to REQ 1, i.e. that >>>>>>all transactions within the same dialog should share the same session >>>>>>ID. I do not believe there is a requirement for session ID within the >>>>>>transaction, i.e. between request and response - that is dealt with by >>>>>>other mechanisms. We have no requirement for correlation between two >>>>>>transactions that are not within a dialog. >>>>>> >>>>>>While it would be possible to draft this round the existing >>>>>>requirement >>>>>>split, I suggest maybe we just do the split round the time and space >>>>>>division. So the new revised requirements might look like (in place of >>>>>>the existing). >>>>>> >>>>>>REQ 1B: It must be possible for the same identifier to appear at all >>>>>>entities participating in a SIP transaction, such that an external >>>>>>device that monitors the SIP traffic can use that identifier to >>>>>>correlate the same transaction at each of those entities. >>>>>> >>>>>>REQ 1C: It must be possible for the same identifier to appear in all >>>>>>transactions that form part of a SIP dialog, such that the >>>>>>transactions >>>>>>that form part of the dialog can be correlated together. There is no >>>>>>requirement for the identifier to correlate parts of a single >>>>>>transaction (i.e. request and response) as existing SIP mechanisms are >>>>>>assumed to do that. There is no requirement for the identifier to >>>>>>correlate two transactions that do not form part of the same dialog >>>>>>(e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a >>>>>>MESSAGE transaction and a subsequent MESSAGE transaction), except as >>>>>>expressed in other requirements. >>>>>> >>>>>>Note the "except" in REQ 1C above is to allow the transfer >>>>>>requirements >>>>>>in REQ2. >>>>>> >>>>>>If the new REQ 1B is acceptable, then we should also consider how >>>>>>distinct that is from REQ 4. >>>>>> >>>>>>Keith >>>>>> >>>>>>------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>>*From:*insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] *On >>>>>>Behalf Of *Paul E. Jones >>>>>>*Sent:* 11 July 2012 13:10 >>>>>>*To:* Laura Liess >>>>>>*Cc:* insipid@ietf.org >>>>>>*Subject:* Re: [Insipid] Text proposal for the "SIP traffic >>>>>>monitoring" >>>>>>use case >>>>>> >>>>>>What shall be the wording of REQ1a? >>>>>> >>>>>>Paul >>>>>> >>>>>>------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>>*From:*Laura Liess >>>>>>*Sent:* Wed Jul 11 03:14:07 EDT 2012 >>>>>>*To:* "Paul E. Jones" >>>>>>*Cc:* insipid@ietf.org >>>>>>*Subject:* Re: [Insipid] Text proposal for the "SIP traffic >>>>>>monitoring" >>>>>>use case >>>>>> >>>>>> >>>>>> >>>>>>Paul, >>>>>> >>>>>> >>>>>> >>>>>>After the discussion yesterday in the Webex meeting, it seems to me >>>>>> >>>>>>that separate requirements for dialogs and transactions are needed. >>>>>> >>>>>> >>>>>> >>>>>>Thanks >>>>>> >>>>>>Laura >>>>>> >>>>>> >>>>>> >>>>>>2012/7/11 Paul E. Jones: >>>>>> >>>>>>>Indeed, you're right. It does cover both, but folks called for a >>>>>separate >>>>>> >>>>>>>requirement. >>>>>> >>>>>> >>>>>>>What is the wishes of the WG on this? Shall I replace REQ1 with the >>>>>below >>>>>> >>>>>>>text? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Paul >>>>>> >>>>>> >>>>>>>>-----Original Message----- >>>>>> >>>>>>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>Behalf >>>>>> >>>>>>>>Of Laura Liess >>>>>> >>>>>>>>Sent: Tuesday,July 10, 2012 8:23 AM >>>>>> >>>>>>>>To: Paul E. Jones >>>>>> >>>>>>>>Cc: insipid@ietf.org >>>>>> >>>>>>>>Subject: Re: [Insipid] Text proposal for the"SIP traffic monitoring" >>>>>use >>>>>> >>>>>>>>case >>>>>> >>>>>> >>>>>>>>Paul, >>>>>> >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > What was proposed (by you?) was this: >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > REQ1a: It must be possible for an administrator or an external >>>>>device >>>>>> >>>>>>>> > which monitors the SIP-traffic to use the identifier to identify >>>>>those >>>>>> >>>>>>>> > dialogs, transactions and messages which were at some point in >>>>>time >>>>>> >>>>>>>> > components of a single end-to-end SIP session (e.g., parts of the >>>>>same >>>>>> >>>>>>>>call). >>>>>> >>>>>> >>>>>>>>[LL] The proposed text of the REQ1a (above) also covers the REQ1 (as >>>>>it is >>>>>> >>>>>>>>in draft-ietf-insipid-session-id-reqts-00). So I think we could >>>>>replace >>>>>> >>>>>>>>the current text of REQ1 by the proposed text of the REQ1a and then >>>>>drop >>>>>> >>>>>>>>REQ1a. >>>>>> >>>>>> >>>>>>>>Thanks >>>>>> >>>>>>>>Laura >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > This is not presently in t! >>>>>> >>>>>>he draft >>>>>> >>>>>>that we just submitted to be a WG >>>>>> >>>>>>>> > document since I was told to base that document on the -03 draft. >>>>>I >>>>>> >>>>>>>> > had that text in my pending -04 draft, but ... it is still sitting >>>>>> >>>>>>>> > there :-) >>>>>> >>>>>>>> > >>>>>> >>>>>>>> >> > You really want to just remove that text from c)? >>>>>> >>>>>>>> >> [LL] No. I don't. >>>>>> >>>>>>>> >> Also in this scenario the service providers monitors and logs all >>>>>> >>>>>>>> >> B2BUA traffic, incomming and outgoing. There is no log >>>>>provided by >>>>>> >>>>>>>> >> the customer. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> From my point of view, the text would be : >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> >>>>>> >>>>>> >>>>>> >>>>>>------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> >> User Agent A (A) and User Agent B (B) communicate using SIP >>>>>messaging >>>>>> >>>>>>>> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP >>>>>service >>>>>> >>>>>>>>provider. >>>>>> >>>>>>>> >> For privacy reasons, t! >>>>>> >>>>>>he B2BUA >>>>>> >>>>>>changes the SIP headers that reveal >>>>>> >>>>>>>> >> information related to the SIP users, device or domain identity. >>>>>The >>>>>> >>>>>>>> >> service provider uses an external device to monitor and log all >>>>>SIP >>>>>> >>>>>>>> >> traffic coming to and from the B2BUA. In the case of failures >>>>>> >>>>>>>> >> reported by the customer or when security issue arise (e.g. theft >>>>>of >>>>>> >>>>>>>> >> service), the service provider has to analyze the logs from the >>>>>past >>>>>> >>>>>>>> >> several days or weeks and correlates those messages which were >>>>>> >>>>>>>> >> messages for a single end- to-end SIP session. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> For this scenario, we must consider three particular use cases: >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> a) The UAs A and B support the end-to-end Session Identifier. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> b) Only the UA A supports the end-to-end Session Identifier, the >>>>>UA B >>>>>> >>>>>>>> >> does not. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> c) UA A and UA B do not support the end-to-end Session >>>>>Identifier. >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >>>>>> >>>>>>>> >> ----------------- >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> >>>>>> >>>>>>>> >> What do you think? >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > Sounds OK to me. I'll put this into me -04 draft and when folks >>>>>give >>>>>> >>>>>>>> > me the green light, move it into the WG -01 draft. >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > 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 pkyzivat@alum.mit.edu Wed Jul 11 14:07:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14821F85FD for ; Wed, 11 Jul 2012 14:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 qZwE5wq7Ozm2 for ; Wed, 11 Jul 2012 14:07:58 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 62A6A21F85FC for ; Wed, 11 Jul 2012 14:07:58 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id Z8AA1j0011ei1Bg5C98YuG; Wed, 11 Jul 2012 21:08:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id Z98c1j00a3ZTu2S3k98cq6; Wed, 11 Jul 2012 21:08:36 +0000 Message-ID: <4FFDEB4B.8010306@alum.mit.edu> Date: Wed, 11 Jul 2012 17:08:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> In-Reply-To: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Session-ID construction choices 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, 11 Jul 2012 21:07:59 -0000 Comment at end. On 7/11/12 3:43 PM, James Polk wrote: > INSIPID > > From yesterday's interim call, we discussed several things, including > some items already discussed on the list in the last 24 hours. I want to > focus on the identifier construction, now that we have decided to > communicate both parts of the Session-ID, built by both sides, on the > wire once the SIP response is transmitted. > > Sidebar: no one has given us authors any technical reason > why this is not a good idea, other than the length > of the overall header-value, which many believe is > outweighed by the certainty of always having the > full Session-ID to analyze in every message (once > the response has been transmitted). > > There are at least 4 ways to construct the whole Session-ID if both > halves are present. Whichever way we chose in the final RFC will be > unquestionably the only way to do it. > > Option#1 - attach a prefix (e.g., From: and To:) to each > half > > Option#2 - group together in any order, but each half > remains unchanged > > Option#3 - the half with the lowest value is first, > with the higher value half second > > Option#4 - the initiator of the SIP request half key > is first, the responder half key is second. > > The technical disadvantage for Option #1 is - there is none we are aware > of, and might be the cleanest or most clear to humans and servers (i.e., > processes/searches/analysis). However, once there is a call join, the > From: label loses its meaning. The To: will remain correct. > Option #1 does follow call transfer scenarios nicely, and is easiest > analyze. > > The technical disadvantage for Option #2 is - loss of directionality, if > that is ever an issue. The UUID/GUID halves are each unique regardless, > so searching for a specific value will not be an issue during or after > the fact. > > The technical disadvantage for Option #3 is - loss of directionality, if > that is ever an issue. The UUID/GUID halves are each unique regardless, > so searching for a specific value will not be an issue during or after > the fact. Could lead to confusion to human analysis having values > switched in order. > > The technical disadvantage for Option #4 is - identical to Option #1 > except for tags, which could lead to loss of directionality without ever > knowing it, if that is ever an issue. The UUID/GUID halves are each > unique regardless, so searching for a specific value will not be an > issue during or after the fact. > > We have a proposal going forward: insert the From:/To: tags from Option #1. > > Does anyone have a technical reason why this wouldn't work? Do you mean to assign From and To once, and then keep it fixed for the duration of the dialog? ISTM that From and To are not well defined in all cases. For instance, consider a BTBUA that sets up a session by inviting both endpoints. Which is From and which is To? IIUC, the reason for labeling this way is so that someone observing a session id in a message can tell which half corresponds to which end. Using From and To won't satisfy that unless those tags are reassigned for each request. (This is a special case of a conference focus, which you already call out as an exception.) Identifying which end is which is easy for any single transaction, but hard if you want to use the same identifiers in every message. The endpoints can easily figure this out, because they should know their half, and the half that isn't theirs is the other end's. But its not simple for middleboxes. The solution that is used for dialog ids is to use To and From, but they must be reassigned depending on the direction of the message. We could do the same for session id, but only if they are remapped based on the direction of the request. Thanks, Paul From christer.holmberg@ericsson.com Wed Jul 11 14:16:29 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0174A21F861F for ; Wed, 11 Jul 2012 14:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBxGIMS5ld-G for ; Wed, 11 Jul 2012 14:16:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7EA211E80BB for ; Wed, 11 Jul 2012 14:16:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-27-4ffded4aef19 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9F.15.07365.A4DEDFF4; Wed, 11 Jul 2012 23:16:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 11 Jul 2012 23:16:58 +0200 From: Christer Holmberg To: 'James Polk' , "insipid@ietf.org" Date: Wed, 11 Jul 2012 23:16:56 +0200 Thread-Topic: [Insipid] Session-ID construction choices Thread-Index: Ac1fnXqyI1jOfOzQQTaVojWWqS1rqwAC/+yg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> In-Reply-To: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra7X27/+BgtXyFnMv/+MyWLHmkIH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+Pm+wbWgs0yFZf+drE3MLaJdTFyckgImEh0 /L3HBmGLSVy4tx7I5uIQEjjFKPHkdCsLhLOQUeLR93OMXYwcHGwCFhLd/7RBGkQEvCS+vHzL CmKzCKhK7Hv4BmyQsICZxIuGJUwQNeYSj979ZISwjSR2T17LDmLzCoRLLJj4E6xXSMBO4uC6 brB6TgF7iWs968HijEAHfT+1BizOLCAucevJfCaIQwUkluw5zwxhi0q8fPwPql5U4k77ekaI ej2JG1OnsEHY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFM5NzMxJLzfU Sy3KTC4uzs/TK07dxAiMkINbfuvuYDx1TuQQozQHi5I4L1fSfn8hgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjFn+897dybq7lWv7joL/904K2bZUqwlHdizdGGpwblICe/Bz2ZMFT5j/yn3q TrywxqSZr7tm2zRZZ5WtHlorD+bZP9Pc89BfL4eprerVvKYQr9eq81p4khz4rG+krL66YMvF 80wOcpbrhG7eza9pkuN7uaHhcn74yp6X04UFiiWe1Zxh3lcdpMRSnJFoqMVcVJwIAJZ6orFe AgAA Subject: Re: [Insipid] Session-ID construction choices 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, 11 Jul 2012 21:16:29 -0000 Hi, I didn't call in for the interim, so maybe the following was discussed. First, if we would use the To/From tags, do we assume that the tag values a= re always passed by an SBC? If an SBC modifies the tag values in the To/Fro= m headers, and is aware that they are also present in the session id, it ma= y remove/modify the session id - which is what we want to prevent :) Second, maybe I've missed something, but if we would use the To/From tags (= and assume they are passed unchanged end-to-end), why would we need anythin= g else? Regards, Christer =20 -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of James Polk Sent: 11. hein=E4kuuta 2012 22:44 To: insipid@ietf.org Subject: [Insipid] Session-ID construction choices INSIPID From yesterday's interim call, we discussed several things, including some= items already discussed on the list in the last 24 hours. I want to focus = on the identifier construction, now that we have decided to communicate bot= h parts of the Session-ID, built by both sides, on the wire once the SIP re= sponse is transmitted. Sidebar: no one has given us authors any technical reason why this is not a good idea, other than the length of the overall header-value, which many believe is outweighed by the certainty of always having the full Session-ID to analyze in every message (once the response has been transmitted). There are at least 4 ways to construct the whole Session-ID if both halves = are present. Whichever way we chose in the final RFC will be unquestionably= the only way to do it. Option#1 - attach a prefix (e.g., From: and To:) to each half Option#2 - group together in any order, but each half remains unchanged Option#3 - the half with the lowest value is first, with the higher value half second Option#4 - the initiator of the SIP request half key is first, the responder half key is second. The technical disadvantage for Option #1 is - there is none we are aware of= , and might be the cleanest or most clear to humans and servers (i.e., proc= esses/searches/analysis). However, once there is a call join, the From: lab= el loses its meaning. The To: will remain correct. Option #1 does follow call transfer scenarios nicely, and is easiest analyz= e. The technical disadvantage for Option #2 is - loss of directionality, if th= at is ever an issue. The UUID/GUID halves are each unique regardless, so se= arching for a specific value will not be an issue during or after the fact. The technical disadvantage for Option #3 is - loss of directionality, if th= at is ever an issue. The UUID/GUID halves are each unique regardless, so se= arching for a specific value will not be an issue during or after the fact.= Could lead to confusion to human analysis having values switched in order. The technical disadvantage for Option #4 is - identical to Option #1 except= for tags, which could lead to loss of directionality without ever knowing = it, if that is ever an issue. The UUID/GUID halves are each unique regardle= ss, so searching for a specific value will not be an issue during or after = the fact. We have a proposal going forward: insert the From:/To: tags from Option #1. Does anyone have a technical reason why this wouldn't work? James _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Wed Jul 11 14:25:13 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AB611E80EC for ; Wed, 11 Jul 2012 14:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 7ngIlgdfxK9O for ; Wed, 11 Jul 2012 14:25:13 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id CD3EC11E80EA for ; Wed, 11 Jul 2012 14:25:12 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id Z3aR1j01K1swQuc539Rmzj; Wed, 11 Jul 2012 21:25:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id Z9Rf1j00Y3ZTu2S3b9RfYV; Wed, 11 Jul 2012 21:25:39 +0000 Message-ID: <4FFDEF56.2040708@alum.mit.edu> Date: Wed, 11 Jul 2012 17:25:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Insipid] Session-ID construction choices 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, 11 Jul 2012 21:25:13 -0000 On 7/11/12 5:16 PM, Christer Holmberg wrote: > > Hi, > > I didn't call in for the interim, so maybe the following was discussed. > > First, if we would use the To/From tags, do we assume that the tag values are always passed by an SBC? If an SBC modifies the tag values in the To/From headers, and is aware that they are also present in the session id, it may remove/modify the session id - which is what we want to prevent :) > > Second, maybe I've missed something, but if we would use the To/From tags (and assume they are passed unchanged end-to-end), why would we need anything else? Christer - AFAIK the proposal is not to use the tag= values on From and To headers. Rather it is to label the two halves of the session id as to which corresponds to From and which corresponds to To. Thanks, Paul > Regards, > > Christer > > > > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of James Polk > Sent: 11. heinäkuuta 2012 22:44 > To: insipid@ietf.org > Subject: [Insipid] Session-ID construction choices > > INSIPID > > From yesterday's interim call, we discussed several things, including some items already discussed on the list in the last 24 hours. I want to focus on the identifier construction, now that we have decided to communicate both parts of the Session-ID, built by both sides, on the wire once the SIP response is transmitted. > > Sidebar: no one has given us authors any technical reason > why this is not a good idea, other than the length > of the overall header-value, which many believe is > outweighed by the certainty of always having the > full Session-ID to analyze in every message (once > the response has been transmitted). > > There are at least 4 ways to construct the whole Session-ID if both halves are present. Whichever way we chose in the final RFC will be unquestionably the only way to do it. > > Option#1 - attach a prefix (e.g., From: and To:) to each > half > > Option#2 - group together in any order, but each half > remains unchanged > > Option#3 - the half with the lowest value is first, > with the higher value half second > > Option#4 - the initiator of the SIP request half key > is first, the responder half key is second. > > The technical disadvantage for Option #1 is - there is none we are aware of, and might be the cleanest or most clear to humans and servers (i.e., processes/searches/analysis). However, once there is a call join, the From: label loses its meaning. The To: will remain correct. > Option #1 does follow call transfer scenarios nicely, and is easiest analyze. > > The technical disadvantage for Option #2 is - loss of directionality, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. > > The technical disadvantage for Option #3 is - loss of directionality, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. Could lead to confusion to human analysis having values switched in order. > > The technical disadvantage for Option #4 is - identical to Option #1 except for tags, which could lead to loss of directionality without ever knowing it, if that is ever an issue. The UUID/GUID halves are each unique regardless, so searching for a specific value will not be an issue during or after the fact. > > We have a proposal going forward: insert the From:/To: tags from Option #1. > > Does anyone have a technical reason why this wouldn't work? > > James > > _______________________________________________ > 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 christer.holmberg@ericsson.com Wed Jul 11 14:29:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0AF11E80EC for ; Wed, 11 Jul 2012 14:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvegNcfOf+Fg for ; Wed, 11 Jul 2012 14:29:00 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2004A11E80EA for ; Wed, 11 Jul 2012 14:28:57 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-49-4ffdf0387933 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6D.E5.07365.830FDFF4; Wed, 11 Jul 2012 23:29:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.100]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 11 Jul 2012 23:29:28 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "insipid@ietf.org" Date: Wed, 11 Jul 2012 23:29:27 +0200 Thread-Topic: [Insipid] Session-ID construction choices Thread-Index: Ac1fq7zuNr9pVizfR4KpQ5QrbtabnAAAFotQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A058534071B991C@ESESSCMS0356.eemea.ericsson.se> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> In-Reply-To: <4FFDEF56.2040708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra7lh7/+BgsrLebff8ZksWLDAVYH Jo+/7z8weSxZ8pMpgCmKyyYlNSezLLVI3y6BK+PA242sBZcUK2ave8DYwDhXqouRk0NCwERi zt8VzBC2mMSFe+vZuhi5OIQETjFKrLmyjgXCmcso8XTrF6YuRg4ONgELie5/2iANIgLBElt+ vGcCsVkEVCU+TmwGs4UFzCReNCxhgqgxl3j07icjhG0ksXfGQ3aQMbwC4RLL9iRBjF/HKLHn xWZWkBpOAR2J5g832EFsRqCDvp9aAzaHWUBc4taT+UwQhwpILNlzHupoUYmXj/+xQtSLStxp X88IUa8ncWPqFDYIW1ti2cLXYPW8AoISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbh3MTM nPRyQ73Uoszk4uL8PL3i1E2MwAg5uOW37g7GU+dEDjFKc7AoifNyJe33FxJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cBo9O+VwkXVa5NOC+tGJu76Y/LvSc/syHTjjoC6pXkL/5oyCUpOcX+f 9qnX+2F7y7SU9lLn25+6e66ubL4UfldCpWBbbtd7Dqe02Ib5Z7TWCDYmHw5PXroxJTOI+0B7 jczKoLhTP1/nRD7y0YnbqqFnrxt8OP+1b63OzmADvgc2nyrC1578t0yJpTgj0VCLuag4EQD0 Q8HnXgIAAA== Subject: Re: [Insipid] Session-ID construction choices 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, 11 Jul 2012 21:29:01 -0000 Hi,=20 >> I didn't call in for the interim, so maybe the following was discussed. >> >> First, if we would use the To/From tags, do we assume that the tag=20 >> values are always passed by an SBC? If an SBC modifies the tag values=20 >> in the To/From headers, and is aware that they are also present in the=20 >> session id, it may remove/modify the session id - which is what we=20 >> want to prevent :) >> >> Second, maybe I've missed something, but if we would use the To/From tag= s (and assume they are passed unchanged end-to-end), why would we need anyt= hing else? > > Christer - AFAIK the proposal is not to use the tag=3D values on From and= To headers. Rather it is to label the two halves of the session id as to w= hich corresponds to From and which corresponds to To. Ok. Thanks for the clarification. Regards, Christer > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On=20 > Behalf Of James Polk > Sent: 11. hein=E4kuuta 2012 22:44 > To: insipid@ietf.org > Subject: [Insipid] Session-ID construction choices > > INSIPID > > From yesterday's interim call, we discussed several things, including s= ome items already discussed on the list in the last 24 hours. I want to foc= us on the identifier construction, now that we have decided to communicate = both parts of the Session-ID, built by both sides, on the wire once the SIP= response is transmitted. > > Sidebar: no one has given us authors any technical reason > why this is not a good idea, other than the length > of the overall header-value, which many believe is > outweighed by the certainty of always having the > full Session-ID to analyze in every message (once > the response has been transmitted). > > There are at least 4 ways to construct the whole Session-ID if both halve= s are present. Whichever way we chose in the final RFC will be unquestionab= ly the only way to do it. > > Option#1 - attach a prefix (e.g., From: and To:) to each > half > > Option#2 - group together in any order, but each half > remains unchanged > > Option#3 - the half with the lowest value is first, > with the higher value half second > > Option#4 - the initiator of the SIP request half key > is first, the responder half key is second. > > The technical disadvantage for Option #1 is - there is none we are aware = of, and might be the cleanest or most clear to humans and servers (i.e., pr= ocesses/searches/analysis). However, once there is a call join, the From: l= abel loses its meaning. The To: will remain correct. > Option #1 does follow call transfer scenarios nicely, and is easiest anal= yze. > > The technical disadvantage for Option #2 is - loss of directionality, if = that is ever an issue. The UUID/GUID halves are each unique regardless, so = searching for a specific value will not be an issue during or after the fac= t. > > The technical disadvantage for Option #3 is - loss of directionality, if = that is ever an issue. The UUID/GUID halves are each unique regardless, so = searching for a specific value will not be an issue during or after the fac= t. Could lead to confusion to human analysis having values switched in orde= r. > > The technical disadvantage for Option #4 is - identical to Option #1 exce= pt for tags, which could lead to loss of directionality without ever knowin= g it, if that is ever an issue. The UUID/GUID halves are each unique regard= less, so searching for a specific value will not be an issue during or afte= r the fact. > > We have a proposal going forward: insert the From:/To: tags from Option #= 1. > > Does anyone have a technical reason why this wouldn't work? > > James > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Wed Jul 11 15:22:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4918611E80FB for ; Wed, 11 Jul 2012 15:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.447 X-Spam-Level: X-Spam-Status: No, score=-110.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 qowvi9eZ0eWX for ; Wed, 11 Jul 2012 15:22:34 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 61A8611E8119 for ; Wed, 11 Jul 2012 15:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5534; q=dns/txt; s=iport; t=1342045386; x=1343254986; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=8NpZ07/haKDixpkXBVI3aztyiBaBTJQwCuwGbbNfXow=; b=JIp2CMIgziWgrc0HfGPyKREmHr9aLlNsWZZYy2Ytt5MGhqHFSAaXj1Mx xPL6ngkO0vwZqQiV3lvDRJtFgZT5BCpklpd6CDlGpSyr3fb02j6QlwVc4 FrKDnnyLvuYt3MGmh2WEDKBMvuS88VUtBnPUKdwx5L0jQhtBGBDmwPoA8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKn7/U+rRDoI/2dsb2JhbABFDrdjgQeCIAEBAQMBAQEBDwElAi4GEAsHBA4HAx4QGQ4wBgEJCRsHh2UFDJ1UoCEEi0CFbgOIS5sPgWaCJlc X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="48566802" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 11 Jul 2012 22:23:05 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6BMN5iP025997; Wed, 11 Jul 2012 22:23:05 GMT Message-Id: <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Jul 2012 17:23:06 -0500 To: Paul Kyzivat , From: James Polk In-Reply-To: <4FFDEB4B.8010306@alum.mit.edu> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Session-ID construction choices 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, 11 Jul 2012 22:22:36 -0000 At 04:08 PM 7/11/2012, Paul Kyzivat wrote: >Comment at end. > >On 7/11/12 3:43 PM, James Polk wrote: >>INSIPID >> >> From yesterday's interim call, we discussed several things, including >>some items already discussed on the list in the last 24 hours. I want to >>focus on the identifier construction, now that we have decided to >>communicate both parts of the Session-ID, built by both sides, on the >>wire once the SIP response is transmitted. >> >>Sidebar: no one has given us authors any technical reason >>why this is not a good idea, other than the length >>of the overall header-value, which many believe is >>outweighed by the certainty of always having the >>full Session-ID to analyze in every message (once >>the response has been transmitted). >> >>There are at least 4 ways to construct the whole Session-ID if both >>halves are present. Whichever way we chose in the final RFC will be >>unquestionably the only way to do it. >> >>Option#1 - attach a prefix (e.g., From: and To:) to each >>half >> >>Option#2 - group together in any order, but each half >>remains unchanged >> >>Option#3 - the half with the lowest value is first, >>with the higher value half second >> >>Option#4 - the initiator of the SIP request half key >>is first, the responder half key is second. >> >>The technical disadvantage for Option #1 is - there is none we are aware >>of, and might be the cleanest or most clear to humans and servers (i.e., >>processes/searches/analysis). However, once there is a call join, the >>From: label loses its meaning. The To: will remain correct. >>Option #1 does follow call transfer scenarios nicely, and is easiest >>analyze. >> >>The technical disadvantage for Option #2 is - loss of directionality, if >>that is ever an issue. The UUID/GUID halves are each unique regardless, >>so searching for a specific value will not be an issue during or after >>the fact. >> >>The technical disadvantage for Option #3 is - loss of directionality, if >>that is ever an issue. The UUID/GUID halves are each unique regardless, >>so searching for a specific value will not be an issue during or after >>the fact. Could lead to confusion to human analysis having values >>switched in order. >> >>The technical disadvantage for Option #4 is - identical to Option #1 >>except for tags, which could lead to loss of directionality without ever >>knowing it, if that is ever an issue. The UUID/GUID halves are each >>unique regardless, so searching for a specific value will not be an >>issue during or after the fact. >> >>We have a proposal going forward: insert the From:/To: tags from Option #1. >> >>Does anyone have a technical reason why this wouldn't work? > >Do you mean to assign From and To once, and then keep it fixed for >the duration of the dialog? ISTM that From and To are not well >defined in all cases. > >For instance, consider a BTBUA that sets up a session by inviting >both endpoints. Which is From and which is To? IIUC, the reason for >labeling this way is so that someone observing a session id in a >message can tell which half corresponds to which end. Using From and >To won't satisfy that unless those tags are reassigned for each request. >(This is a special case of a conference focus, which you already >call out as an exception.) The desire is to have the same half in the same position throughout the transaction or dialog (whichever it is). I believe in the case of a B2BUA initiating or originating the transaction or dialog on behalf of other endpoint UAs, the B2BUA would pick which Session-ID is the From and which is the To. IOW - we don't make it a requirement on an implementation that Alice is always inserting her half in first, and Bob in as the second half. If the B2BUA is sending an INVITE to both Alice and Bob, then that's 2 separate Session-IDs because it's two different dialogs, even if a 3rd party isn't part (i.e., listening) of the media flow. This would be a hub and 2 spokes in which the hub doesn't listen or interact with the media of the 2 UAs. We could also have text that says for this scenario, that an INVITE normally inserts the From half of the Session-ID, but that in this scenario it can insert the To: half and the invitee inserts the To half. >Identifying which end is which is easy for any single transaction, agreed >but hard if you want to use the same identifiers in every message. >The endpoints can easily figure this out, because they should know >their half, and the half that isn't theirs is the other end's. But >its not simple for middleboxes. remember that each half is a UUID or GUID, which will always be a unique value through space and time. >The solution that is used for dialog ids is to use To and From, but >they must be reassigned depending on the direction of the message. >We could do the same for session id, but only if they are remapped >based on the direction of the request. I guess I'm no getting why the halves need to switch places yet depending on whether it's in a request or response. Or are you saying that for one complete transaction they are in a certain order, but in a related transaction(s) they are possibly in the reverse order - depending on who sent the message? James > Thanks, > Paul >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Wed Jul 11 16:37:11 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F4511E80F8 for ; Wed, 11 Jul 2012 16:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.821, 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 yoODEMzrVOlv for ; Wed, 11 Jul 2012 16:37:10 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A31B711E8134 for ; Wed, 11 Jul 2012 16:37:10 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id Z2CH1j00l27AodY51Bdhad; Wed, 11 Jul 2012 23:37:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id ZBdn1j00U3ZTu2S3fBdn6j; Wed, 11 Jul 2012 23:37:48 +0000 Message-ID: <4FFE0E42.6060806@alum.mit.edu> Date: Wed, 11 Jul 2012 19:37:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Polk References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> In-Reply-To: <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 11 Jul 2012 23:37:11 -0000 On 7/11/12 6:23 PM, James Polk wrote: ... >>> Option#1 - attach a prefix (e.g., From: and To:) to each >>> half ... >>> We have a proposal going forward: insert the From:/To: tags from >>> Option #1. >>> >>> Does anyone have a technical reason why this wouldn't work? >> >> Do you mean to assign From and To once, and then keep it fixed for the >> duration of the dialog? ISTM that From and To are not well defined in >> all cases. >> >> For instance, consider a BTBUA that sets up a session by inviting both >> endpoints. Which is From and which is To? IIUC, the reason for >> labeling this way is so that someone observing a session id in a >> message can tell which half corresponds to which end. Using From and >> To won't satisfy that unless those tags are reassigned for each request. >> (This is a special case of a conference focus, which you already call >> out as an exception.) > > The desire is to have the same half in the same position throughout the > transaction or dialog (whichever it is). I believe in the case of a > B2BUA initiating or originating the transaction or dialog on behalf of > other endpoint UAs, the B2BUA would pick which Session-ID is the From > and which is the To. IOW - we don't make it a requirement on an > implementation that Alice is always inserting her half in first, and Bob > in as the second half. If the B2BUA is sending an INVITE to both Alice > and Bob, then that's 2 separate Session-IDs because it's two different > dialogs, even if a 3rd party isn't part (i.e., listening) of the media > flow. This would be a hub and 2 spokes in which the hub doesn't listen > or interact with the media of the 2 UAs. > > We could also have text that says for this scenario, that an INVITE > normally inserts the From half of the Session-ID, but that in this > scenario it can insert the To: half and the invitee inserts the To half. > > >> Identifying which end is which is easy for any single transaction, > > agreed > >> but hard if you want to use the same identifiers in every message. The >> endpoints can easily figure this out, because they should know their >> half, and the half that isn't theirs is the other end's. But its not >> simple for middleboxes. > > remember that each half is a UUID or GUID, which will always be a unique > value through space and time. > > >> The solution that is used for dialog ids is to use To and From, but >> they must be reassigned depending on the direction of the message. We >> could do the same for session id, but only if they are remapped based >> on the direction of the request. > > I guess I'm no getting why the halves need to switch places yet > depending on whether it's in a request or response. Or are you saying > that for one complete transaction they are in a certain order, but in a > related transaction(s) they are possibly in the reverse order - > depending on who sent the message? When a message is sent in the reverse direction from the dialog establishing message, the From URI and To URI are reversed, as well as the From and To tags. If the session id still has its halves tagged consistent with the from and to of the dialog establishing request, then you will get confused about which half goes with which end. There is no problem for servers that keep state and remember the values for each end. For them we don't need to tag the halves at all. There is also no problem for those who don't *care* which end is which. And there may be a lot of those. This tagging is only there for those who don't keep state yet need to know. Maybe there aren't any of those, in which case we can stop worrying about it. I guess an example that might matter is something analyzing logs, and doesn't have a complete set of logs available to it - in particular it doesn't have a log of the initial signaling that set up the session, so it can't figure out which half-id belongs to which end. Then it sees a change - it sees a message where half of the id matches prior things, but the other half doesn't - is new. From this it can perhaps infer that there was a transfer. And in that case it will want to know which end remains and which was replaced. But it can't figure that out from which half of the id changed without knowing the mapping from half to end. But I will be the first to say that this case is somewhat implausible. In practice there will be lots of stuff in the messages being analyzed that should support figuring this out. Perhaps this just isn't a good example, and there is another that is better. But I don't know a better one. Anybody else? (I think Paul J was the one who raised this concern, so maybe he has an example.) If we can't find a plausible reason why we need to do this mapping, then I propose that we just not bother. In that case I think representation #3 is attractive. It provides for the easiest comparison between id values - a single string comparison is sufficient. And its among the most compact representations. I'd recommend: session-id: SmallestHalf:BiggestHalf Or just session-id: FirstHalf before the half for the far end has been assigned. Thanks, Paul From gsalguei@cisco.com Wed Jul 11 20:11:39 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E522411E8125 for ; Wed, 11 Jul 2012 20:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 ndQTjKgX0SG9 for ; Wed, 11 Jul 2012 20:11:39 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id F3A1911E8100 for ; Wed, 11 Jul 2012 20:11:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6C3C2Cs027729 for ; Wed, 11 Jul 2012 23:12:03 -0400 (EDT) Received: from rtp-gsalguei-8718.cisco.com (rtp-gsalguei-8718.cisco.com [10.116.61.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6C3C2ST000376 for ; Wed, 11 Jul 2012 23:12:02 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2012 23:12:02 -0400 References: <20120706211533.3449.10225.idtracker@ietfa.amsl.com> To: insipid@ietf.org Message-Id: <509ADC1C-5D96-4616-B7C4-43BA544C3854@cisco.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [Insipid] Fwd: NomCom 2012-13 Call for Volunteers 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, 12 Jul 2012 03:11:40 -0000 If you meet the eligibility requirements and are interested in = contributing, please consider volunteering to NomCom.=20 Gonzalo Begin forwarded message: > From: NomCom Chair > Subject: NomCom 2012-13 Call for Volunteers > Date: July 6, 2012 5:15:33 PM EDT > To: IETF Announcement List >=20 > The IETF nominating committee process for 2012-13 has begun. The IETF > nominating committee appoints folks to fill the open slots on the > IAOC, the IAB, and the IESG. The 10 nominating committee members are > selected randomly from a pool of volunteers. The more volunteers, the > better chance we have of choosing a random yet representative cross > section of the IETF population. The details of the operation of the > nomcom can be found in RFC 3777. >=20 > To be eligible, volunteers for the nomcom need to have attended 3 of > the past 5 IETF meetings as of the time this announcement goes out. > That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you > qualify, and if you will not be seeking appointment to any of the open > positions that this nomcom will be filling, please consider > volunteering. >=20 > The list of people whose terms end with the March 2013 IETF meeting, > and thus the positions for which the nominating committee is > responsible for filling, are as follows: >=20 > IAOC: > -------- > Dave Crocker >=20 > IAB: > -------- > Alissa Cooper > Joel Halpern > David Kessens > Danny McPherson > Jon Peterson > Dave Thaler >=20 > IESG: > -------- > Russ Housley (General Area) > Pete Resnick (Applications Area) > Ralph Droms (Internet Area) > Ronald Bonica (Operations and Management Area) > Robert Sparks (Real-Time Applications and Infrastructure Area) > Adrian Farrel (Routing Area) > Stephen Farrell (Security Area) > Wesley Eddy (Transport Area) >=20 > The primary activity for this nomcom will begin in August 2012 and > should be completed in January 2013. The nomcom will be collecting > requirements from the community, as well as talking to candidates and > obtaining feedback from community members about candidates. There will > be regularly scheduled conference calls to ensure progress. Thus, > being a nomcom member does require some time commitment. >=20 > Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 > hours) August 5, 2012 as follows: >=20 > To: mlepinski.ietf@gmail.com > Subject: Nomcom 2012-13 Volunteer >=20 > Please include the following information in the body: >=20 > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > // typically what goes in the Company field > // in the IETF Registration Form > [] > // > // For confirmation if selected >=20 > Please expect an email response from me within 3 business days stating > whether or not you are qualified. If you don't receive a response, > please re-send your email with the tag "RESEND:" added to the subject > line. >=20 > If you are not yet sure you would like to volunteer, please consider > that nomcom members play a very important role in shaping the > leadership of the IETF. Ensuring the leadership of the IETF is fair > and balanced and comprised of those who can lead the IETF in the right > direction is an important responsibility that rests on the IETF > participants at large. Volunteering for the nomcom is a good way of > contributing toward that goal. >=20 > I will be publishing a more detailed timetable for nomcom activities, > as well as details of the randomness seeds to be used for the RFC 3797 > selection process, within the next couple weeks. >=20 > Thank you, > Matthew Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org >=20 From gsalguei@cisco.com Wed Jul 11 20:53:39 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A376911E80A4 for ; Wed, 11 Jul 2012 20:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 btppyh2hO3Hd for ; Wed, 11 Jul 2012 20:53:39 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9098C11E809F for ; Wed, 11 Jul 2012 20:53:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6C3sA1X001996 for ; Wed, 11 Jul 2012 23:54:10 -0400 (EDT) Received: from rtp-gsalguei-8718.cisco.com (rtp-gsalguei-8718.cisco.com [10.116.61.57]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6C3s3HL027429; Wed, 11 Jul 2012 23:54:03 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <4FFDCB34.6070209@alum.mit.edu> Date: Wed, 11 Jul 2012 23:54:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <87E3242D-6C00-476B-A276-FDFB05190041@cisco.com> References: <4FF701F7.8070202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058534071B9906@ESESSCMS0356.eemea.ericsson.se> <0c1801cd5e4e$9e442ae0$dacc80a0$@packetizer.com> <7F2072F1E0DE894DA4B517B93C6A058534071B990E@ESESSCMS0356.eemea.ericsson.se> <0de001cd5f11$f7dd7160$e7985420$@packetizer.com> <4FFDCB34.6070209@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1278) Cc: Paul Jones , insipid@ietf.org, "Olle E. Johansson" , Christer Holmberg Subject: Re: [Insipid] Use case for association of session signaling and media 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: Thu, 12 Jul 2012 03:53:39 -0000 [as individual] I completely agree. IMO the requirement is valuable and should remain = simply as a best practice to future-proof the Session-ID we're = developing. We all agree that defining the mechanisms/extensions to = handle the Session-ID in other protocols like RSVP/RTCP/H323/etc is out = of scope for this WG, but as discussed during the last interim this = requirement needs hardening to something more practically achievable. As = Paul suggests, putting our heads together and coming up with some = construction requirements/restrictions based on our collective knowledge = of those other protocols seems the best way forward. This would maintain = the original spirit of the requirement but allows it to be reworded less = nebulously. Gonzalo On Jul 11, 2012, at 2:51 PM, Paul Kyzivat wrote: > I suggest replacing these requirements with ones that constrain the = form of the id - its encoding and length. These can say *why* these = constraints are applied, but in the end we will have something that we = can measure. But the constraints should be as liberal as they can be = while meeting the need. >=20 > Thanks, > Paul >=20 > On 7/10/12 11:05 PM, Paul E. Jones wrote: >>>> The mechanisms certainly are our of scope. All I was hoping for at >>>> this point was to ensure that we do not make it difficult or = impossible >>> to one day associate media and signaling by making a poor choice in = how we >>> construct the Session-ID. >>>=20 >>> But, how would you be able to determine whether the requirement has = been >>> fulfilled? >>=20 >> We probably cannot absolutely. However, if we do know of constraints = placed >> on certain protocols, we could ensure we meet those constraints. For >> example, if we were to encode the Session-ID in RTCP, we might place = it an >> SDES packet. That imposes a length limit of 255 octets. >>=20 >> The best we can do is to try to avoid making a bad choice. I do not = think >> we can guarantee it. >>=20 >> Paul >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid >=20 From oej@edvina.net Wed Jul 11 23:14:59 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4621F870B for ; Wed, 11 Jul 2012 23:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 7nb0jm+PN8y2 for ; Wed, 11 Jul 2012 23:14:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE1521F86CF for ; Wed, 11 Jul 2012 23:14:55 -0700 (PDT) Received: from [192.168.40.89] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E7CC1754A8AC; Thu, 12 Jul 2012 06:15:26 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 12 Jul 2012 08:15:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <77811AF7-3555-402D-A1E5-E529DA1D824E@edvina.net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1278) Cc: 'James Polk' , "insipid@ietf.org" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 06:14:59 -0000 11 jul 2012 kl. 23:16 skrev Christer Holmberg: >=20 > Hi, >=20 > I didn't call in for the interim, so maybe the following was = discussed. >=20 > First, if we would use the To/=46rom tags, do we assume that the tag = values are always passed by an SBC? If an SBC modifies the tag values in = the To/=46rom headers, and is aware that they are also present in the = session id, it may remove/modify the session id - which is what we want = to prevent :) >=20 > Second, maybe I've missed something, but if we would use the To/=46rom = tags (and assume they are passed unchanged end-to-end), why would we = need anything else? Using the from/to-tags, do we reveal information that could be misused = as these are used for Invite/Replaces and other things? There are a lot = of assumptions in SIP that if you know the identifiers of the = dialog/transaction you have the right to operate on it. /O >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On = Behalf Of James Polk > Sent: 11. hein=E4kuuta 2012 22:44 > To: insipid@ietf.org > Subject: [Insipid] Session-ID construction choices >=20 > INSIPID >=20 > =46rom yesterday's interim call, we discussed several things, = including some items already discussed on the list in the last 24 hours. = I want to focus on the identifier construction, now that we have decided = to communicate both parts of the Session-ID, built by both sides, on the = wire once the SIP response is transmitted. >=20 > Sidebar: no one has given us authors any technical reason > why this is not a good idea, other than the length > of the overall header-value, which many believe is > outweighed by the certainty of always having the > full Session-ID to analyze in every message (once > the response has been transmitted). >=20 > There are at least 4 ways to construct the whole Session-ID if both = halves are present. Whichever way we chose in the final RFC will be = unquestionably the only way to do it. >=20 > Option#1 - attach a prefix (e.g., From: and To:) to each > half >=20 > Option#2 - group together in any order, but each half > remains unchanged >=20 > Option#3 - the half with the lowest value is first, > with the higher value half second >=20 > Option#4 - the initiator of the SIP request half key > is first, the responder half key is second. >=20 > The technical disadvantage for Option #1 is - there is none we are = aware of, and might be the cleanest or most clear to humans and servers = (i.e., processes/searches/analysis). However, once there is a call join, = the From: label loses its meaning. The To: will remain correct. > Option #1 does follow call transfer scenarios nicely, and is easiest = analyze. >=20 > The technical disadvantage for Option #2 is - loss of directionality, = if that is ever an issue. The UUID/GUID halves are each unique = regardless, so searching for a specific value will not be an issue = during or after the fact. >=20 > The technical disadvantage for Option #3 is - loss of directionality, = if that is ever an issue. The UUID/GUID halves are each unique = regardless, so searching for a specific value will not be an issue = during or after the fact. Could lead to confusion to human analysis = having values switched in order. >=20 > The technical disadvantage for Option #4 is - identical to Option #1 = except for tags, which could lead to loss of directionality without ever = knowing it, if that is ever an issue. The UUID/GUID halves are each = unique regardless, so searching for a specific value will not be an = issue during or after the fact. >=20 > We have a proposal going forward: insert the From:/To: tags from = Option #1. >=20 > Does anyone have a technical reason why this wouldn't work? >=20 > James >=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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden From andrew.hutton@siemens-enterprise.com Thu Jul 12 01:32:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927DE21F87AE for ; Thu, 12 Jul 2012 01:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 SBY3zMH7NUoM for ; Thu, 12 Jul 2012 01:32:19 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 306E321F87A4 for ; Thu, 12 Jul 2012 01:32:19 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id E19271EB8543; Thu, 12 Jul 2012 10:32:50 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Thu, 12 Jul 2012 10:32:50 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Session-ID construction choices Thread-Index: Ac1fnXqy9ehvD3pnOUGZnEVW5q+dFgAC/+yg///i9wD//yd2EA== Date: Thu, 12 Jul 2012 08:32:50 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> In-Reply-To: <4FFDEF56.2040708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 08:32:20 -0000 On 7/11/12 23:36 PM, Paul Kyzivat wrote: >=20 > Christer - AFAIK the proposal is not to use the tag=3D values on From and > To headers. Rather it is to label the two halves of the session id as > to > which corresponds to From and which corresponds to To. >=20 OK Yes I think this is what is being proposed but I am struggling to unders= tand how this can work in 3PCC scenarios but having said that I am not sure= how any of the proposed solutions work in 3PCC scenarios would they need a= re-negotiation of the session-id after the completion of 3PCC procedures? I think we previously agreed to include a 3PCC use case in the requirements= draft but I don't see it so I will provide some proposed text for the requ= irements.=20 Regards Andy > > > > > > > > > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of James Polk > > Sent: 11. hein=E4kuuta 2012 22:44 > > To: insipid@ietf.org > > Subject: [Insipid] Session-ID construction choices > > > > INSIPID > > > > From yesterday's interim call, we discussed several things, > including some items already discussed on the list in the last 24 > hours. I want to focus on the identifier construction, now that we have > decided to communicate both parts of the Session-ID, built by both > sides, on the wire once the SIP response is transmitted. > > > > Sidebar: no one has given us authors any technical reason > > why this is not a good idea, other than the length > > of the overall header-value, which many believe is > > outweighed by the certainty of always having the > > full Session-ID to analyze in every message (once > > the response has been transmitted). > > > > There are at least 4 ways to construct the whole Session-ID if both > halves are present. Whichever way we chose in the final RFC will be > unquestionably the only way to do it. > > > > Option#1 - attach a prefix (e.g., From: and To:) to each > > half > > > > Option#2 - group together in any order, but each half > > remains unchanged > > > > Option#3 - the half with the lowest value is first, > > with the higher value half second > > > > Option#4 - the initiator of the SIP request half key > > is first, the responder half key is second. > > > > The technical disadvantage for Option #1 is - there is none we are > aware of, and might be the cleanest or most clear to humans and servers > (i.e., processes/searches/analysis). However, once there is a call > join, the From: label loses its meaning. The To: will remain correct. > > Option #1 does follow call transfer scenarios nicely, and is easiest > analyze. > > > > The technical disadvantage for Option #2 is - loss of directionality, > if that is ever an issue. The UUID/GUID halves are each unique > regardless, so searching for a specific value will not be an issue > during or after the fact. > > > > The technical disadvantage for Option #3 is - loss of directionality, > if that is ever an issue. The UUID/GUID halves are each unique > regardless, so searching for a specific value will not be an issue > during or after the fact. Could lead to confusion to human analysis > having values switched in order. > > > > The technical disadvantage for Option #4 is - identical to Option #1 > except for tags, which could lead to loss of directionality without > ever knowing it, if that is ever an issue. The UUID/GUID halves are > each unique regardless, so searching for a specific value will not be > an issue during or after the fact. > > > > We have a proposal going forward: insert the From:/To: tags from > Option #1. > > > > Does anyone have a technical reason why this wouldn't work? > > > > James > > > > _______________________________________________ > > 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 jmpolk@cisco.com Thu Jul 12 11:25:33 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C70111E80E8 for ; Thu, 12 Jul 2012 11:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 d6H3F26lu98A for ; Thu, 12 Jul 2012 11:25:32 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4600B11E80D1 for ; Thu, 12 Jul 2012 11:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4948; q=dns/txt; s=iport; t=1342117566; x=1343327166; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=RhtYL3TnlwV31L0QgVJ4NHhbrkOYOvFBLBrKrPu586M=; b=ZwLluHKnM9YjEASGkm8n80vDp5no8vqD14VQx/M55MjJvH24yrpjjmVz g4wM5LYX5+1wZ91tHImSplXDFvRjAXrPOv9fe30Gmcf4Ng3+bRvf3cu8O ZJvUBmRHNqOzU9lZs3iuQsyg7ch1YcAqKapldjXUXeORwNoI+EcOot7Su s=; X-IronPort-AV: E=Sophos;i="4.77,575,1336348800"; d="scan'208";a="48646766" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 12 Jul 2012 18:26:06 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6CIQ5BV012434; Thu, 12 Jul 2012 18:26:05 GMT Message-Id: <201207121826.q6CIQ5BV012434@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jul 2012 13:26:06 -0500 To: "Olle E. Johansson" , Christer Holmberg From: James Polk In-Reply-To: <77811AF7-3555-402D-A1E5-E529DA1D824E@edvina.net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <77811AF7-3555-402D-A1E5-E529DA1D824E@edvina.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: 'James Polk' , "insipid@ietf.org" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 18:25:33 -0000 At 01:15 AM 7/12/2012, Olle E. Johansson wrote: >11 jul 2012 kl. 23:16 skrev Christer Holmberg: > > > > > Hi, > > > > I didn't call in for the interim, so maybe the following was discussed. > > > > First, if we would use the To/From tags, do=20 > we assume that the tag values are always passed=20 > by an SBC? If an SBC modifies the tag values in=20 > the To/From headers, and is aware that they are=20 > also present in the session id, it may=20 > remove/modify the session id - which is what we want to prevent :) > > > > Second, maybe I've missed something, but if=20 > we would use the To/From tags (and assume they=20 > are passed unchanged end-to-end), why would we need anything else? > >Using the from/to-tags, we're not using the from and to tags, period.=20 There are many reasons why not that have been said already. James >do we reveal information that could be misused=20 >as these are used for Invite/Replaces and other=20 >things? There are a lot of assumptions in SIP=20 >that if you know the identifiers of the=20 >dialog/transaction you have the right to operate on it. > >/O > > > > Regards, > > > > Christer > > > > > > > > > > -----Original Message----- > > From: insipid-bounces@ietf.org=20 > [mailto:insipid-bounces@ietf.org] On Behalf Of James Polk > > Sent: 11. hein=E4kuuta 2012 22:44 > > To: insipid@ietf.org > > Subject: [Insipid] Session-ID construction choices > > > > INSIPID > > > > From yesterday's interim call, we discussed=20 > several things, including some items already=20 > discussed on the list in the last 24 hours. I=20 > want to focus on the identifier construction,=20 > now that we have decided to communicate both=20 > parts of the Session-ID, built by both sides,=20 > on the wire once the SIP response is transmitted. > > > > Sidebar: no one has given us authors any technical reason > > why this is not a good idea, other than the length > > of the overall header-value, which many believe is > > outweighed by the certainty of always having the > > full Session-ID to analyze in every message (once > > the response has been transmitted). > > > > There are at least 4 ways to construct the=20 > whole Session-ID if both halves are present.=20 > Whichever way we chose in the final RFC will be=20 > unquestionably the only way to do it. > > > > Option#1 - attach a prefix (e.g., From: and To:) to each > > half > > > > Option#2 - group together in any order, but each half > > remains unchanged > > > > Option#3 - the half with the lowest value is first, > > with the higher value half second > > > > Option#4 - the initiator of the SIP request half key > > is first, the responder half key is second. > > > > The technical disadvantage for Option #1 is -=20 > there is none we are aware of, and might be the=20 > cleanest or most clear to humans and servers=20 > (i.e., processes/searches/analysis). However,=20 > once there is a call join, the From: label=20 > loses its meaning. The To: will remain correct. > > Option #1 does follow call transfer scenarios=20 > nicely, and is easiest analyze. > > > > The technical disadvantage for Option #2 is -=20 > loss of directionality, if that is ever an=20 > issue. The UUID/GUID halves are each unique=20 > regardless, so searching for a specific value=20 > will not be an issue during or after the fact. > > > > The technical disadvantage for Option #3 is -=20 > loss of directionality, if that is ever an=20 > issue. The UUID/GUID halves are each unique=20 > regardless, so searching for a specific value=20 > will not be an issue during or after the fact.=20 > Could lead to confusion to human analysis having values switched in order. > > > > The technical disadvantage for Option #4 is -=20 > identical to Option #1 except for tags, which=20 > could lead to loss of directionality without=20 > ever knowing it, if that is ever an issue. The=20 > UUID/GUID halves are each unique regardless, so=20 > searching for a specific value will not be an issue during or after the= fact. > > > > We have a proposal going forward: insert the From:/To: tags from Option= #1. > > > > Does anyone have a technical reason why this wouldn't work? > > > > James > > > > _______________________________________________ > > 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 > >--- >* Olle E Johansson - oej@edvina.net >* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Thu Jul 12 11:37:07 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8BA11E80F4 for ; Thu, 12 Jul 2012 11:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 BE-t1g9Woqpt for ; Thu, 12 Jul 2012 11:37:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88A11E80E9 for ; Thu, 12 Jul 2012 11:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5862; q=dns/txt; s=iport; t=1342118260; x=1343327860; h=message-id:date:to:from:subject:in-reply-to:references: mime-version:content-transfer-encoding; bh=3B9cu6sRpIwbX9s3YLO0EaMTF+7X4Kem/YeRicHSiJw=; b=Ke+2ExM6cQzxbE7ilfBXcZT7iR5TTngMPMQsBR9HshaxxaFkN7AKsqLG 08tVnAcYlfXMDtNb3LWlFa66Z7d/6UhUymPmYPBLNih7UBic8FLPR9B2a Q7rBFmIVHImHuYNzJkpIybLXeKV7SEEE4sNZVFfn2xfhg4lq+tx+xrG5x w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFwY/0+rRDoH/2dsb2JhbABFDrd+gQeCIAEBAQQBAQEPASUwBhcEBwQRBAEBAScHGQ4fCQgGAQkJGweHagydYqAcBItAhXwDiBY1mw+BZoImVw X-IronPort-AV: E=Sophos;i="4.77,575,1336348800"; d="scan'208";a="51760755" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 12 Jul 2012 18:37:40 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6CIbdTi017652; Thu, 12 Jul 2012 18:37:39 GMT Message-Id: <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jul 2012 13:37:37 -0500 To: "Hutton, Andrew" , Paul Kyzivat , "insipid@ietf.org" From: James Polk In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad .net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 18:37:07 -0000 At 03:32 AM 7/12/2012, Hutton, Andrew wrote: >On 7/11/12 23:36 PM, Paul Kyzivat wrote: > > > > > Christer - AFAIK the proposal is not to use the tag=3D values on From= and > > To headers. Rather it is to label the two halves of the session id as > > to > > which corresponds to From and which corresponds to To. > > > >OK Yes I think this is what is being proposed=20 >but I am struggling to understand how this can=20 >work in 3PCC scenarios but having said that I am=20 >not sure how any of the proposed solutions work=20 >in 3PCC scenarios would they need a=20 >re-negotiation of the session-id after the completion of 3PCC procedures? > >I think we previously agreed to include a 3PCC=20 >use case in the requirements draft but I don't=20 >see it so I will provide some proposed text for the requirements. We need a proposed use-case as well as proposed=20 requirements text. IOW, saying "3PCC" is not=20 enough for some (many?) to understand what all=20 there is to the scenario that needs to be=20 accounted for. At the same time, the use-case=20 needs to be concise (good luck, huh?). Actually, what also wouldn't be bad to have is a=20 single PPT slide explaining the 3PCC scenario as=20 you see it. This gives a visual for the WG in the=20 session. For example, I can imagine a 3PCC=20 scenario as a remote application (perhaps sitting=20 on a server) that contacts a B2BUA or a=20 conference bridge to INVITE both Alice and Bob to=20 a dialog. The conference bridge aspect we=20 already cover in the MCU requirement that we're=20 had in our slides for a while (treated as a pt2pt=20 between the MCU and Alice, and another between=20 the MCU and Bob). The application getting a B2BUA=20 to initiate a call between Alice and Bob via the=20 B2BUA not acting as a MCU is another scenario.=20 I'm not sure that is what you're after, or=20 detailed enough if it is what you're after. James >Regards >Andy > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of James Polk > > > Sent: 11. hein=E4kuuta 2012 22:44 > > > To: insipid@ietf.org > > > Subject: [Insipid] Session-ID construction choices > > > > > > INSIPID > > > > > > From yesterday's interim call, we discussed several things, > > including some items already discussed on the list in the last 24 > > hours. I want to focus on the identifier construction, now that we have > > decided to communicate both parts of the Session-ID, built by both > > sides, on the wire once the SIP response is transmitted. > > > > > > Sidebar: no one has given us authors any technical reason > > > why this is not a good idea, other than the length > > > of the overall header-value, which many believe is > > > outweighed by the certainty of always having the > > > full Session-ID to analyze in every message (once > > > the response has been transmitted). > > > > > > There are at least 4 ways to construct the whole Session-ID if both > > halves are present. Whichever way we chose in the final RFC will be > > unquestionably the only way to do it. > > > > > > Option#1 - attach a prefix (e.g., From: and To:) to each > > > half > > > > > > Option#2 - group together in any order, but each half > > > remains unchanged > > > > > > Option#3 - the half with the lowest value is first, > > > with the higher value half second > > > > > > Option#4 - the initiator of the SIP request half key > > > is first, the responder half key is second. > > > > > > The technical disadvantage for Option #1 is - there is none we are > > aware of, and might be the cleanest or most clear to humans and servers > > (i.e., processes/searches/analysis). However, once there is a call > > join, the From: label loses its meaning. The To: will remain correct. > > > Option #1 does follow call transfer scenarios nicely, and is easiest > > analyze. > > > > > > The technical disadvantage for Option #2 is - loss of directionality, > > if that is ever an issue. The UUID/GUID halves are each unique > > regardless, so searching for a specific value will not be an issue > > during or after the fact. > > > > > > The technical disadvantage for Option #3 is - loss of directionality, > > if that is ever an issue. The UUID/GUID halves are each unique > > regardless, so searching for a specific value will not be an issue > > during or after the fact. Could lead to confusion to human analysis > > having values switched in order. > > > > > > The technical disadvantage for Option #4 is - identical to Option #1 > > except for tags, which could lead to loss of directionality without > > ever knowing it, if that is ever an issue. The UUID/GUID halves are > > each unique regardless, so searching for a specific value will not be > > an issue during or after the fact. > > > > > > We have a proposal going forward: insert the From:/To: tags from > > Option #1. > > > > > > Does anyone have a technical reason why this wouldn't work? > > > > > > James > > > > > > _______________________________________________ > > > 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 pkyzivat@alum.mit.edu Thu Jul 12 11:58:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195EC21F8567 for ; Thu, 12 Jul 2012 11:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 NppYMWlARmER for ; Thu, 12 Jul 2012 11:58:19 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8217221F8566 for ; Thu, 12 Jul 2012 11:58:19 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id ZWLP1j00816LCl05EWyvHE; Thu, 12 Jul 2012 18:58:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ZWyo1j0023ZTu2S3SWyoQ4; Thu, 12 Jul 2012 18:58:48 +0000 Message-ID: <4FFF1E6C.9030101@alum.mit.edu> Date: Thu, 12 Jul 2012 14:58:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Polk References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> In-Reply-To: <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" , "Hutton, Andrew" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 18:58:20 -0000 On 7/12/12 2:37 PM, James Polk wrote: > We need a proposed use-case as well as proposed requirements text. IOW, > saying "3PCC" is not enough for some (many?) to understand what all > there is to the scenario that needs to be accounted for. At the same > time, the use-case needs to be concise (good luck, huh?). The following is from RFC 3725. There are many alternative flows there, but for this discussion it doesn't matter so this is a simple one: A Controller B |(1) INVITE no SDP | | |<------------------| | |(2) 200 offer1 | | |------------------>| | | |(3) INVITE offer1 | | |------------------>| | |(4) 200 OK answer1 | | |<------------------| | |(5) ACK | | |------------------>| |(6) ACK answer1 | | |<------------------| | |(7) RTP | | |.......................................| This establishes an e2e session between A and B with a B2BUA in the middle. Presumably we want to end up with a session id that has one half associated with A and one half associated with B. But both A and B think they are the "To" party in establishing the session. This also presents a difficulty for message (1). What half id does the controller assign for the From half in the INVITE? Thanks, Paul From andrew.hutton@siemens-enterprise.com Thu Jul 12 12:12:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63F311E810D for ; Thu, 12 Jul 2012 12:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 DOMP4Lonc9Ub for ; Thu, 12 Jul 2012 12:12:30 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7E411E808C for ; Thu, 12 Jul 2012 12:12:30 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 30AB623F05CB; Thu, 12 Jul 2012 21:13:03 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Thu, 12 Jul 2012 21:13:03 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , James Polk Thread-Topic: [Insipid] Session-ID construction choices Thread-Index: Ac1fnXqy9ehvD3pnOUGZnEVW5q+dFgAC/+yg///i9wD//yd2EIACXXhU///kYAD//9s58A== Date: Thu, 12 Jul 2012 19:13:02 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0508B7@MCHP04MSX.global-ad.net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <4FFF1E6C.9030101@alum.mit.edu> In-Reply-To: <4FFF1E6C.9030101@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 19:12:32 -0000 Hi Paul, Thanks, This it is exactly the scenario and problem I was referring to. Regards Andy > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 12 July 2012 20:59 > To: James Polk > Cc: Hutton, Andrew; insipid@ietf.org > Subject: Re: [Insipid] Session-ID construction choices >=20 > On 7/12/12 2:37 PM, James Polk wrote: >=20 > > We need a proposed use-case as well as proposed requirements text. > IOW, > > saying "3PCC" is not enough for some (many?) to understand what all > > there is to the scenario that needs to be accounted for. At the same > > time, the use-case needs to be concise (good luck, huh?). >=20 > The following is from RFC 3725. There are many alternative flows there, > but for this discussion it doesn't matter so this is a simple one: >=20 > A Controller B > |(1) INVITE no SDP | | > |<------------------| | > |(2) 200 offer1 | | > |------------------>| | > | |(3) INVITE offer1 | > | |------------------>| > | |(4) 200 OK answer1 | > | |<------------------| > | |(5) ACK | > | |------------------>| > |(6) ACK answer1 | | > |<------------------| | > |(7) RTP | | > |.......................................| >=20 > This establishes an e2e session between A and B with a B2BUA in the > middle. Presumably we want to end up with a session id that has one > half > associated with A and one half associated with B. But both A and B > think > they are the "To" party in establishing the session. >=20 > This also presents a difficulty for message (1). What half id does the > controller assign for the From half in the INVITE? >=20 > Thanks, > Paul From jmpolk@cisco.com Thu Jul 12 12:25:50 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1878711E80CD for ; Thu, 12 Jul 2012 12:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 AYKTgdXY8D7G for ; Thu, 12 Jul 2012 12:25:49 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2F12111E809B for ; Thu, 12 Jul 2012 12:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2745; q=dns/txt; s=iport; t=1342121183; x=1343330783; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=4hxyKfhJcNxYN4TyiRG12CoRuyIbYjOMv+YI4/qYVHw=; b=aawjZ7kz49H2/AZZgXPhu4FBaFlc83SBssKkoiLl+9vAeQa8ewNrzx1W fs2Uwylkhq460t6sE3gcptiTvuEkHbO/VfXk2zMV9L/MWMc8/4VioOOgl bOC2w2O2t1wRyijJdZ/nlSpVOHJiehL9gp0UsKxnH+3K+rPLdAg64IaLR 8=; X-IronPort-AV: E=Sophos;i="4.77,575,1336348800"; d="scan'208";a="51682491" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 12 Jul 2012 19:26:19 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6CJQJbs010006; Thu, 12 Jul 2012 19:26:19 GMT Message-Id: <201207121926.q6CJQJbs010006@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jul 2012 14:26:20 -0500 To: Paul Kyzivat , James Polk From: James Polk In-Reply-To: <4FFF1E6C.9030101@alum.mit.edu> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <4FFF1E6C.9030101@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" , "Hutton, Andrew" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 19:25:50 -0000 At 01:58 PM 7/12/2012, Paul Kyzivat wrote: >On 7/12/12 2:37 PM, James Polk wrote: > >>We need a proposed use-case as well as proposed requirements text. IOW, >>saying "3PCC" is not enough for some (many?) to understand what all >>there is to the scenario that needs to be accounted for. At the same >>time, the use-case needs to be concise (good luck, huh?). > >The following is from RFC 3725. There are many alternative flows >there, but for this discussion it doesn't matter so this is a simple one: > > A Controller B > |(1) INVITE no SDP | | > |<------------------| | > |(2) 200 offer1 | | > |------------------>| | > | |(3) INVITE offer1 | > | |------------------>| > | |(4) 200 OK answer1 | > | |<------------------| > | |(5) ACK | > | |------------------>| > |(6) ACK answer1 | | > |<------------------| | > |(7) RTP | | > |.......................................| > >This establishes an e2e session between A and B with a B2BUA in the >middle. Presumably we want to end up with a session id that has one >half associated with A and one half associated with B. But both A >and B think they are the "To" party in establishing the session. One way of addressing this - that Laura might not like - is to allow a null header-value with the stipulation that UA A MUST populate this header with their "half" upon receipt of a SIP request that has an unpopulated/null Session-ID header-value. This will result in the 200 OK in message 2 to have UA A's half, and the INVITE in message 3 includes that half awaiting the 200 OK in message 4 to include the other half of the Session-ID. This alternative means that the offer from A (message 2) must be received before the message 3 INVITE is sent to B. Is that acceptable? It seems to be wrt containing the offer1 SDP. A slightly different alternative to the above is to make a rule that UA A adds a Session-ID to any request it receives without a Session-ID, and add it's half of the header-value. Where a B2BUA is not involved, the ACK would contain the other half. James >This also presents a difficulty for message (1). What half id does >the controller assign for the From half in the INVITE? > > Thanks, > Paul From andrew.hutton@siemens-enterprise.com Thu Jul 12 12:46:26 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C174E21F8688 for ; Thu, 12 Jul 2012 12:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 jHG4Qe4hezxF for ; Thu, 12 Jul 2012 12:46:26 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 12EFE21F861A for ; Thu, 12 Jul 2012 12:46:25 -0700 (PDT) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 498451EB8475; Thu, 12 Jul 2012 21:46:59 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.02.0309.002; Thu, 12 Jul 2012 21:46:59 +0200 From: "Hutton, Andrew" To: James Polk , Paul Kyzivat , "insipid@ietf.org" Thread-Topic: Proposed 3PCC Use Case and Requirement. Thread-Index: AQHNYGcZDRgrVe3ZpUCDy5xVsUtkDg== Date: Thu, 12 Jul 2012 19:46:58 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF050920@MCHP04MSX.global-ad.net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> In-Reply-To: <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] Proposed 3PCC Use Case and Requirement. 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, 12 Jul 2012 19:46:26 -0000 Hi, I propose the following text as a new use case for section 3.3 of draft-iet= f-insipid-session-id-reqts 3.3 3PCC Use Case. Third party call control refers to the ability of one entity to create a ca= ll in which communication is actually between other parties. For example a = B2BUA acting as a third party controller may establish a call between two S= IP UA's using 3PCC procedures as described in section 4.1 of RFC 3725 the f= low for which is reproduced below. A Controller B |(1) INVITE no SDP | | |<------------------| | |(2) 200 offer1 | | |------------------>| | | |(3) INVITE offer1 | | |------------------>| | |(4) 200 OK answer1 | | |<------------------| | |(5) ACK | | |------------------>| |(6) ACK answer1 | | |<------------------| | |(7) RTP | | |.......................................| Such a flow must result in a single session identifier being used for the c= ommunication session between UA A and UA B. New REQ10: REQ10: It must be possible to correlate two end-to-end sessions when the se= ssions are created by a third party controller using 3PCC procedures as des= cribed in RFC 3575.=20 Regards Andy From pkyzivat@alum.mit.edu Thu Jul 12 12:49:11 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B019C11E80E9 for ; Thu, 12 Jul 2012 12:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 I68ZYLVp7IjV for ; Thu, 12 Jul 2012 12:49:11 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id C003711E80CD for ; Thu, 12 Jul 2012 12:49:10 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id ZX4a1j0021swQuc5CXpn7h; Thu, 12 Jul 2012 19:49:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id ZXpg1j0043ZTu2S3bXpgZJ; Thu, 12 Jul 2012 19:49:40 +0000 Message-ID: <4FFF2A57.9030905@alum.mit.edu> Date: Thu, 12 Jul 2012 15:49:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Polk References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <4FFF1E6C.9030101@alum.mit.edu> <201207121926.q6CJQJbs010006@mtv-core-2.cisco.com> In-Reply-To: <201207121926.q6CJQJbs010006@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "insipid@ietf.org" , "Hutton, Andrew" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 19:49:11 -0000 On 7/12/12 3:26 PM, James Polk wrote: > At 01:58 PM 7/12/2012, Paul Kyzivat wrote: >> On 7/12/12 2:37 PM, James Polk wrote: >> >>> We need a proposed use-case as well as proposed requirements text. IOW, >>> saying "3PCC" is not enough for some (many?) to understand what all >>> there is to the scenario that needs to be accounted for. At the same >>> time, the use-case needs to be concise (good luck, huh?). >> >> The following is from RFC 3725. There are many alternative flows >> there, but for this discussion it doesn't matter so this is a simple one: >> >> A Controller B >> |(1) INVITE no SDP | | >> |<------------------| | >> |(2) 200 offer1 | | >> |------------------>| | >> | |(3) INVITE offer1 | >> | |------------------>| >> | |(4) 200 OK answer1 | >> | |<------------------| >> | |(5) ACK | >> | |------------------>| >> |(6) ACK answer1 | | >> |<------------------| | >> |(7) RTP | | >> |.......................................| >> >> This establishes an e2e session between A and B with a B2BUA in the >> middle. Presumably we want to end up with a session id that has one >> half associated with A and one half associated with B. But both A and >> B think they are the "To" party in establishing the session. > > One way of addressing this - that Laura might not like - is to allow a > null header-value with the stipulation that UA A MUST populate this > header with their "half" upon receipt of a SIP request that has an > unpopulated/null Session-ID header-value. This will result in the 200 OK > in message 2 to have UA A's half, and the INVITE in message 3 includes > that half awaiting the 200 OK in message 4 to include the other half of > the Session-ID. Yes, this is analogous to the offerless invite. > This alternative means that the offer from A (message 2) must be > received before the message 3 INVITE is sent to B. Is that acceptable? > It seems to be wrt containing the offer1 SDP. There are lots of different ways to do 3pcc, but this is probably acceptable. > A slightly different alternative to the above is to make a rule that UA > A adds a Session-ID to any request it receives without a Session-ID, and > add it's half of the header-value. Where a B2BUA is not involved, the > ACK would contain the other half. That would work *if* there is no intervening B2BUA that takes responsibility for inserting the first half id. But that is a bad bet to make - there are no doubt lots of cases where that is exactly what would happen. Another way is for the controller to provide a half id (say X) for itself in (1). It then gets both halves back from A in (s). (Say X:A) Then it provides X again in (3), and gets back X:B in (4). Finally it constructs an ID (A:B) for the e2e call and sends that in (5) and (6). But this is pretty ugly. Thanks, Paul > James > > >> This also presents a difficulty for message (1). What half id does the >> controller assign for the From half in the INVITE? >> >> Thanks, >> Paul > > From andrew.hutton@siemens-enterprise.com Thu Jul 12 13:04:18 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B899D21F853B for ; Thu, 12 Jul 2012 13:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 6lsNUkIIg+LB for ; Thu, 12 Jul 2012 13:04:17 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABAF21F8548 for ; Thu, 12 Jul 2012 13:04:17 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 1EA7923F0698; Thu, 12 Jul 2012 22:04:51 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.131]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.02.0309.002; Thu, 12 Jul 2012 22:04:50 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , James Polk Thread-Topic: [Insipid] Session-ID construction choices Thread-Index: Ac1fnXqy9ehvD3pnOUGZnEVW5q+dFgAC/+yg///i9wD//yd2EIACcZnP///8rrA= Date: Thu, 12 Jul 2012 20:04:50 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF0509A1@MCHP04MSX.global-ad.net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <4FFF1E6C.9030101@alum.mit.edu> <201207121926.q6CJQJbs010006@mtv-core-2.cisco.com> <4FFF2A57.9030905@alum.mit.edu> In-Reply-To: <4FFF2A57.9030905@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid@ietf.org" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 20:04:18 -0000 See below. Regards Andy > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 12 July 2012 21:50 > To: James Polk > Cc: Hutton, Andrew; insipid@ietf.org > Subject: Re: [Insipid] Session-ID construction choices >=20 > On 7/12/12 3:26 PM, James Polk wrote: > > At 01:58 PM 7/12/2012, Paul Kyzivat wrote: > >> On 7/12/12 2:37 PM, James Polk wrote: > >> > >>> We need a proposed use-case as well as proposed requirements text. > IOW, > >>> saying "3PCC" is not enough for some (many?) to understand what all > >>> there is to the scenario that needs to be accounted for. At the > same > >>> time, the use-case needs to be concise (good luck, huh?). > >> > >> The following is from RFC 3725. There are many alternative flows > >> there, but for this discussion it doesn't matter so this is a simple > one: > >> > >> A Controller B > >> |(1) INVITE no SDP | | > >> |<------------------| | > >> |(2) 200 offer1 | | > >> |------------------>| | > >> | |(3) INVITE offer1 | > >> | |------------------>| > >> | |(4) 200 OK answer1 | > >> | |<------------------| > >> | |(5) ACK | > >> | |------------------>| > >> |(6) ACK answer1 | | > >> |<------------------| | > >> |(7) RTP | | > >> |.......................................| > >> > >> This establishes an e2e session between A and B with a B2BUA in the > >> middle. Presumably we want to end up with a session id that has one > >> half associated with A and one half associated with B. But both A > and > >> B think they are the "To" party in establishing the session. > > > > One way of addressing this - that Laura might not like - is to allow > a > > null header-value with the stipulation that UA A MUST populate this > > header with their "half" upon receipt of a SIP request that has an > > unpopulated/null Session-ID header-value. This will result in the 200 > OK > > in message 2 to have UA A's half, and the INVITE in message 3 > includes > > that half awaiting the 200 OK in message 4 to include the other half > of > > the Session-ID. >=20 > Yes, this is analogous to the offerless invite. [AndyH] - Yes I kind of like that. >=20 > > This alternative means that the offer from A (message 2) must be > > received before the message 3 INVITE is sent to B. Is that > acceptable? > > It seems to be wrt containing the offer1 SDP. >=20 > There are lots of different ways to do 3pcc, but this is probably > acceptable. [AndyH] - I think this most likely would be ok. >=20 > > A slightly different alternative to the above is to make a rule that > UA > > A adds a Session-ID to any request it receives without a Session-ID, > and > > add it's half of the header-value. Where a B2BUA is not involved, the > > ACK would contain the other half. >=20 > That would work *if* there is no intervening B2BUA that takes > responsibility for inserting the first half id. But that is a bad bet > to > make - there are no doubt lots of cases where that is exactly what > would > happen. [AndyH] - We have to assume that there could be a B2BUA/SBC between the con= troller and the UA this is very common scenario. >=20 > Another way is for the controller to provide a half id (say X) for > itself in (1). It then gets both halves back from A in (s). (Say X:A) > Then it provides X again in (3), and gets back X:B in (4). Finally it > constructs an ID (A:B) for the e2e call and sends that in (5) and (6). > But this is pretty ugly. >=20 > Thanks, > Paul >=20 > > James > > > > > >> This also presents a difficulty for message (1). What half id does > the > >> controller assign for the From half in the INVITE? > >> > >> Thanks, > >> Paul > > > > From jmpolk@cisco.com Thu Jul 12 13:11:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65F11E809C for ; Thu, 12 Jul 2012 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 MXvu7nBisj8v for ; Thu, 12 Jul 2012 13:10:56 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA011E8080 for ; Thu, 12 Jul 2012 13:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2578; q=dns/txt; s=iport; t=1342123890; x=1343333490; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=XU7TF2do0MAjXSdmJBE5dywuV35cBrq33Lfl0x/u/qs=; b=Nj8AyON/S/abC9JCKAb/nRN+rNY9TDeBgckPC8L9+foAc/FRuX5zfqL/ XRcLUrLF5jaOcodjD3d+SCRSQOrreDyz3LTsUODOaQzbsnMCpyH1XavWq aUXMZ3mHihOTnGbcOHP4ptVZRTjWdcMEev9mxIYZimdkWQ+dXSb63J++w g=; X-IronPort-AV: E=Sophos;i="4.77,576,1336348800"; d="scan'208";a="51685456" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 12 Jul 2012 20:11:30 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6CKBThA029817; Thu, 12 Jul 2012 20:11:30 GMT Message-Id: <201207122011.q6CKBThA029817@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jul 2012 14:41:52 -0500 To: "Hutton, Andrew" , Paul Kyzivat , James Polk From: James Polk In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF0508B7@MCHP04MSX.global-ad .net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <4FFF1E6C.9030101@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF0508B7@MCHP04MSX.global-ad.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 20:11:01 -0000 At 02:13 PM 7/12/2012, Hutton, Andrew wrote: >Hi Paul, > >Thanks, This it is exactly the scenario and problem I was referring to. ok, cool. This is probably the simplest case I know of. I was afraid you wanted some totally whacked out corner case, and I'm thankful you don't. ;-) Now, what do you think of my response in the other message as to potential ways forward on this topic? James >Regards >Andy > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: 12 July 2012 20:59 > > To: James Polk > > Cc: Hutton, Andrew; insipid@ietf.org > > Subject: Re: [Insipid] Session-ID construction choices > > > > On 7/12/12 2:37 PM, James Polk wrote: > > > > > We need a proposed use-case as well as proposed requirements text. > > IOW, > > > saying "3PCC" is not enough for some (many?) to understand what all > > > there is to the scenario that needs to be accounted for. At the same > > > time, the use-case needs to be concise (good luck, huh?). > > > > The following is from RFC 3725. There are many alternative flows there, > > but for this discussion it doesn't matter so this is a simple one: > > > > A Controller B > > |(1) INVITE no SDP | | > > |<------------------| | > > |(2) 200 offer1 | | > > |------------------>| | > > | |(3) INVITE offer1 | > > | |------------------>| > > | |(4) 200 OK answer1 | > > | |<------------------| > > | |(5) ACK | > > | |------------------>| > > |(6) ACK answer1 | | > > |<------------------| | > > |(7) RTP | | > > |.......................................| > > > > This establishes an e2e session between A and B with a B2BUA in the > > middle. Presumably we want to end up with a session id that has one > > half > > associated with A and one half associated with B. But both A and B > > think > > they are the "To" party in establishing the session. > > > > This also presents a difficulty for message (1). What half id does the > > controller assign for the From half in the INVITE? > > > > Thanks, > > Paul From jmpolk@cisco.com Thu Jul 12 13:28:54 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBC811E8096 for ; Thu, 12 Jul 2012 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.174 X-Spam-Level: X-Spam-Status: No, score=-110.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_38=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 7BnRUE0Atz+y for ; Thu, 12 Jul 2012 13:28:53 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7871311E8080 for ; Thu, 12 Jul 2012 13:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2874; q=dns/txt; s=iport; t=1342124967; x=1343334567; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=vPcrOcsxX1HCIkkeHnMlMOhfdumhNkP4jvEESejfRss=; b=YxJNWoeWCIVMDmSTD8DVlzL2G/2UpsYID/Jf1XtKWRL+wX/CMpIM2PKO awxgVtWC67Kuqy84/m8J4CG8hXq9KfJiCZ1RlYg6bbowrgAqCxFkEMOOg Y5yC4I/gdiv+UK438g7SSuSYM+33MEIQALUT2x3TPG1krxto3IB5IiPgx 0=; X-IronPort-AV: E=Sophos;i="4.77,576,1336348800"; d="scan'208";a="48655540" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 12 Jul 2012 20:29:27 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6CKTRJA006378; Thu, 12 Jul 2012 20:29:27 GMT Message-Id: <201207122029.q6CKTRJA006378@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jul 2012 15:29:28 -0500 To: "Hutton, Andrew" , James Polk , Paul Kyzivat , "insipid@ietf.org" From: James Polk In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF050920@MCHP04MSX.global-ad .net> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF050920@MCHP04MSX.global-ad.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Insipid] Proposed 3PCC Use Case and Requirement. 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, 12 Jul 2012 20:28:54 -0000 At 02:46 PM 7/12/2012, Hutton, Andrew wrote: >Hi, > >I propose the following text as a new use case for section 3.3 of >draft-ietf-insipid-session-id-reqts > >3.3 3PCC Use Case. > >Third party call control refers to the ability of one entity to >create a call in which communication is actually between other >parties. For example a B2BUA acting as a third party controller may >establish a call between two SIP UA's using 3PCC procedures as >described in section 4.1 of RFC 3725 the flow for which is reproduced below. > > A Controller B > |(1) INVITE no SDP | | > |<------------------| | > |(2) 200 offer1 | | > |------------------>| | > | |(3) INVITE offer1 | > | |------------------>| > | |(4) 200 OK answer1 | > | |<------------------| > | |(5) ACK | > | |------------------>| > |(6) ACK answer1 | | > |<------------------| | > |(7) RTP | | > |.......................................| > >Such a flow must result in a single session identifier being used >for the communication session between UA A and UA B. > >New REQ10: > >REQ10: It must be possible to correlate two end-to-end sessions when >the sessions are created by a third party controller using 3PCC >procedures as described in RFC 3575. For this new req10, I'm concerned about opening up the Session-ID to a MUST comply with all that's described in RFC 3725. For example, the above diagram is Figure 1 from that RFC. Whereas figures 2 and 4 from that RFC make things a fair amount more complicated wrt following the offer/answer model. If we limit our req(whatever number) to just 'must support 3PCC as described in Figure 1 of RFC 3725', then I'm far more open to it. In other words, if our solution, based on this req<#?> covers more 3PCC scenarios, great, but I'd like that not to be a must for our solution. Remember, our solution must solve each of the reqs in our reqs document - because the chairs have said they will not progress whatever solution draft forward if it doesn't address each. I don't want certain 3PCC scenarios to be what kills this effort. Just like Adam doesn't want focus based conferencing to kill it either. Is this agreeable? James >Regards >Andy >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From jmpolk@cisco.com Thu Jul 12 13:32:49 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619B311E8096 for ; Thu, 12 Jul 2012 13:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 RVAHDhqHgDaN for ; Thu, 12 Jul 2012 13:32:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id A8D7E11E8080 for ; Thu, 12 Jul 2012 13:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3593; q=dns/txt; s=iport; t=1342125203; x=1343334803; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=XcJAPjZvf6Em+xsKQxNlYzYPwxDcSgyHO/9OMkrOYQs=; b=WGSNRJy9fdsdWCKd9Ybq8JyMBnt1X7vxqPaELyZ6gJ3z2lNe1dHF+Ei2 +9wskZ/VBl+PK3vTEWK37ByjuMb4WF2MS6YZpfLlw4eeK7fdA3TRSJzbh xUq9t4uT/5ZU6mYU0aFhslaece2Wny63enaCaWf7mHTVeUD7L0asoHend o=; X-IronPort-AV: E=Sophos;i="4.77,576,1336348800"; d="scan'208";a="51768818" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 12 Jul 2012 20:33:23 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6CKXMH0031499; Thu, 12 Jul 2012 20:33:22 GMT Message-Id: <201207122033.q6CKXMH0031499@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 12 Jul 2012 15:33:23 -0500 To: Paul Kyzivat , James Polk From: James Polk In-Reply-To: <4FFF2A57.9030905@alum.mit.edu> References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A058534071B991B@ESESSCMS0356.eemea.ericsson.se> <4FFDEF56.2040708@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF05043A@MCHP04MSX.global-ad.net> <201207121837.q6CIbdTi017652@mtv-core-2.cisco.com> <4FFF1E6C.9030101@alum.mit.edu> <201207121926.q6CJQJbs010006@mtv-core-2.cisco.com> <4FFF2A57.9030905@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" , "Hutton, Andrew" Subject: Re: [Insipid] Session-ID construction choices 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, 12 Jul 2012 20:32:49 -0000 At 02:49 PM 7/12/2012, Paul Kyzivat wrote: >On 7/12/12 3:26 PM, James Polk wrote: >>At 01:58 PM 7/12/2012, Paul Kyzivat wrote: >>>On 7/12/12 2:37 PM, James Polk wrote: >>> >>>>We need a proposed use-case as well as proposed requirements text. IOW, >>>>saying "3PCC" is not enough for some (many?) to understand what all >>>>there is to the scenario that needs to be accounted for. At the same >>>>time, the use-case needs to be concise (good luck, huh?). >>> >>>The following is from RFC 3725. There are many alternative flows >>>there, but for this discussion it doesn't matter so this is a simple one: >>> >>>A Controller B >>>|(1) INVITE no SDP | | >>>|<------------------| | >>>|(2) 200 offer1 | | >>>|------------------>| | >>>| |(3) INVITE offer1 | >>>| |------------------>| >>>| |(4) 200 OK answer1 | >>>| |<------------------| >>>| |(5) ACK | >>>| |------------------>| >>>|(6) ACK answer1 | | >>>|<------------------| | >>>|(7) RTP | | >>>|.......................................| >>> >>>This establishes an e2e session between A and B with a B2BUA in the >>>middle. Presumably we want to end up with a session id that has one >>>half associated with A and one half associated with B. But both A and >>>B think they are the "To" party in establishing the session. >> >>One way of addressing this - that Laura might not like - is to allow a >>null header-value with the stipulation that UA A MUST populate this >>header with their "half" upon receipt of a SIP request that has an >>unpopulated/null Session-ID header-value. This will result in the 200 OK >>in message 2 to have UA A's half, and the INVITE in message 3 includes >>that half awaiting the 200 OK in message 4 to include the other half of >>the Session-ID. > >Yes, this is analogous to the offerless invite. > >>This alternative means that the offer from A (message 2) must be >>received before the message 3 INVITE is sent to B. Is that acceptable? >>It seems to be wrt containing the offer1 SDP. > >There are lots of different ways to do 3pcc, but this is probably acceptable. > >>A slightly different alternative to the above is to make a rule that UA >>A adds a Session-ID to any request it receives without a Session-ID, and >>add it's half of the header-value. Where a B2BUA is not involved, the >>ACK would contain the other half. > >That would work *if* there is no intervening B2BUA that takes >responsibility for inserting the first half id. But that is a bad >bet to make - there are no doubt lots of cases where that is exactly >what would happen. > >Another way is for the controller to provide a half id (say X) for >itself in (1). It then gets both halves back from A in (s). (Say X:A) >Then it provides X again in (3), and gets back X:B in (4). Finally >it constructs an ID (A:B) for the e2e call and sends that in (5) and >(6). But this is pretty ugly. that's a little convoluted, but if the results are always valid (i.e., doesn't break), I'm ok with it. Each UA will be paying attention to only its half of the id. One problem would be intermediary B2BUAs and stateful proxies tracking the full id value, and seeing the change in overall value. This would normally be the case for a call transfer, but here there's been no change - other than half the value changed. Is that acceptable? James > Thanks, > Paul > >>James >> >> >>>This also presents a difficulty for message (1). What half id does the >>>controller assign for the From half in the INVITE? >>> >>>Thanks, >>>Paul >> From gsalguei@cisco.com Fri Jul 13 12:37:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2394B11E80C7 for ; Fri, 13 Jul 2012 12:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 w0nsIPH0Yzv7 for ; Fri, 13 Jul 2012 12:37:56 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7562F11E808C for ; Fri, 13 Jul 2012 12:37:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6DJcUmO014744 for ; Fri, 13 Jul 2012 15:38:30 -0400 (EDT) Received: from dhcp-64-102-154-216.cisco.com (dhcp-64-102-154-216.cisco.com [64.102.154.216]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6DJcT3o010699; Fri, 13 Jul 2012 15:38:29 -0400 (EDT) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jul 2012 15:38:29 -0400 Message-Id: To: insipid@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: insipid-chairs@tools.ietf.org Subject: [Insipid] Agenda for INSIPID WG meeting at IETF 84 (Vancouver) 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, 13 Jul 2012 19:37:57 -0000 INSIPID WG -=20 The preliminary agenda for the INSIPID WG meeting at IETF 84 in = Vancouver is available here: http://www.ietf.org/proceedings/84/agenda/agenda-84-insipid Please send feedback or requests for speaking slots to Keith and myself. Gonzalo & Keith (as co-chairs)= From jmpolk@cisco.com Mon Jul 16 16:50:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7711E833E; Mon, 16 Jul 2012 16:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 V+0UwjmgZk95; Mon, 16 Jul 2012 16:50:34 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 91EDB11E8340; Mon, 16 Jul 2012 16:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=7643; q=dns/txt; s=iport; t=1342482679; x=1343692279; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=OVlUJkv0Y3q4WMJH9pBVX+ACT2WvEXMjiRmRuyodpPM=; b=AUJdJrs4AMu/ZjTm9qymJnmNcjuFGqgIQ/SOgInaVUzeZRrxg4ntkZF7 bdsRvf6pYRVAucelIT1afgg3n6K2hhc3ysL3fbDNe5cwYN7WaEWUk5LTQ rDpjLpsDBZopuuMbu0dWVbzElVZ+4AGIc+2GWPhRH4+WP35XHxd94UsXV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJqoBFCrRDoG/2dsb2JhbABFDrlJgQeCIAEBAQMBAQEBDwElAjEDBAcMBAcEEQQBAQEeCQcZDh8IAQgGAQkJIodlBQycCqAcBItAhkcDiEubEIFmgiZXgUE X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="scan'208";a="49537325" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2012 23:51:19 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6GNpIIp004258; Mon, 16 Jul 2012 23:51:18 GMT Message-Id: <201207162351.q6GNpIIp004258@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Jul 2012 18:51:17 -0500 To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "rai@ietf.org" From: James Polk In-Reply-To: References: <201207161935.q6GJZ03k006108@mtv-core-1.cisco.com> <5004766F.1090104@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "insipid@ietf.org" Subject: Re: [Insipid] [RAI] FW: Expert Review of 6 new SIP header fields defined by OMA CPM 1.0 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 23:50:36 -0000 I'm not sure I agree with everything you said, but could be wrong. It appears what OMA wants is to relate non-dialog transactions together, with the ability to pick back up a relationship that existed in the past, went either dormant or idle, then someone from that previous transaction(s) starts again what they call the Conversation-ID or that someone not in the previous (set of) transaction(s) joins while not changing the Conversation-ID. This to me is completely new wrt the scope of INSIPID's charter and not an issue the current requirements not articulating this as a use-case. The reason why I asked was that I could see it as a phase II approach for INSIPID after the initial work is completed (i.e., via a recharter). Of concern would be the idea of having a Session-ID from INSIPID be unique through space and time, but resurrectable. IOW, any Session-ID would be able to be active whenever an entity or actor wants to use it again. IMO this violates the "unique through space and time" aspect. I can see there being a real problem for one of the charter stated use-cases about logging and analysis. If a provider thinks it has a good handle on a communications session, from start to end (i.e., which final response is the final response for the Session-ID?). Wouldn't it be a real problem for there really to be no end (because it is resurrectable)? James (copying insipid for those who aren't on the rai list) At 06:18 PM 7/16/2012, DRAGE, Keith (Keith) wrote: >Given Adam's response that these should all be standards track as >currently defined, then if they do come in in that form, then there >does need to be a reevaluation of the scope of the current INSIPID >requirements. > >As far as I am aware it is not the scope of the INSIPID charter that >rules this out, but only the requirements currently drafted in the >working group document. > >Keith > > > -----Original Message----- > > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Paul > > Kyzivat > > Sent: 16 July 2012 21:16 > > To: rai@ietf.org > > Subject: Re: [RAI] FW: Expert Review of 6 new SIP header fields defined by > > OMA CPM 1.0 > > > > On 7/16/12 3:34 PM, James Polk wrote: > > > haven't thought this through completely, but where would the new > > > Session-ID fit into this? The Session-ID within the INSIPID WG is coming > > > down the pipe really soon, and seems to track *similarly* to how I read > > > the OMA's desired use of the Conversation-ID. > > > > I don't think it is the same. IIUC they want to use a common ID for > > multiple dialogs, and independent transactions (like MESSAGE) that > > otherwise appear to be independent but are semantically related. > > > > AFAIK that is beyond the scope of session-id. > > > > I still think they can accomplish their goals with existing mechanisms > > (and sufficiently smart B2BUAs). But obviously they don't agree. I don't > > know how this will get sorted out. > > > > Thanks, > > Paul > > > > > James > > > > > > At 01:25 PM 7/16/2012, Cristina Badulescu wrote: > > >> Content-Language: en-US > > >> Content-Type: multipart/alternative; > > >> > > >> > > boundary="_000_B802D092CAFAB344B354F0977DEB71EE558AE7C7C4EUSAACMS0703e_" > > >> > > >> Dear all, > > >> > > >> > > >> ...continuing to respond to RAI review comments below; I hope that > > >> I've collected all comments previously circulated on RAI list. > > >> > > >> > > >> Comment (email 19/03/2012 Paul Kyzivat) > > >> OMA Header Possible Alternative > > >> -------------------------- ------------------------------------- > > >> Conversation-ID Message-ID of 1st message > > >> [Cristina] OMA CPM has the concept of "Conversation" which groups > > >> together for example chat sessions, file transfers, standalone > > >> messages, subsequent disposition notifications e.g. 'delivered'. The > > >> Conversation content (messages, file tranfers, notifications, etc) is > > >> identified and stored all together, by the Conversation-ID which ties > > >> them all together. > > >> > > >> > Contribution-ID Message-ID > > >> > > >> [Cristina] Same as above, it has to apply to more than messages - as > > >> it ties together chat sessions, file transfers within a chat session. > > >> > > >> > InReplyTo-Contribution-ID In-Reply-To > > >> > > >> [Cristina] A header with the equivalent syntax to the Contribution-ID > > >> was created, for correlation and sequencing within a conversation. > > >> > > >> > Session-Replaces References(?) > > >> > > >> [Cristina] This is supposed to carry a Contribution-ID - not sure > > >> where References is defined (CPM 1.0 was Candidate Approved in 2010). > > >> > > >> > Message-Expires Expires(?) > > >> > > >> [Cristina] In OMA CPM the message might be deferred and stored in the > > >> network if the recipient is not available, for later delivery or user > > >> initiated retrieval of the stored message. So message-expires is a way > > >> for the sender to indicate the expiry time of the message itself (e.g. > > >> a too late retrieval might be useless from the message content > > >> perspective). It is not related to the "Expires" header for the SIP > > >> transaction. > > >> > > >> > Message-UID Message-ID > > >> > > >> [Cristina] This header is related to the way messages are identified > > >> in the Message Store accessible through IMAP. > > >> > > >> Comment (email 20/03/2012 - Dale Worley) > > >> ---------------------------------------------- > > >> Conversation-ID Message-ID of 1st message > > >> Contribution-ID Message-ID > > >> InReplyTo-Contribution-ID In-Reply-To > > >> Session-Replaces References(?) > > >> all have a value that is syntactically "word", as opposed to Call-Id, > > >> whose syntax is "word ['@' word]". For consistency's sake I'd like to > > >> see them all use the same syntax. Section 3.2 suggests that the > > >> datatypes of these headers has already been fixed in [OMA-CPM-SD]. > > >> > > >> [Cristina] Answer is same as in my previous email to Adam. > > >> Call-Id syntax was not used since the values of these headers should > > >> be created and used in a way unrelated to Call-Id. These ID's are > > >> expected to simply be copied over at B2BUA's so they will remain the > > >> same on an end to end basis (passing through SBCs). We wanted to avoid > > >> any cases where SBCs could alter the new headers in any way (e.g. even > > >> a blind replacement of the ['@' word]" part). > > >> > > >> Also, in CPM scenarios where a closed group chat session is revived > > >> later on by any one of the original participating UAs (i.e. > > >> re-initiating it), the same Conversation-ID of the previous group chat > > >> INVITE would have to be used. As this later UA could be in a different > > >> domain, carrying the original ['@' word]" part does not serve any > > >> purpose (but can be confusing). > > >> > > >> > > >> Regards > > >> Cristina > > >> _______________________________________________ > > >> RAI mailing list > > >> RAI@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rai > > > > > > _______________________________________________ > > > RAI mailing list > > > RAI@ietf.org > > > https://www.ietf.org/mailman/listinfo/rai > > > > > > > _______________________________________________ > > RAI mailing list > > RAI@ietf.org > > https://www.ietf.org/mailman/listinfo/rai >_______________________________________________ >RAI mailing list >RAI@ietf.org >https://www.ietf.org/mailman/listinfo/rai From keith.drage@alcatel-lucent.com Mon Jul 16 17:20:53 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09AC11E8086; Mon, 16 Jul 2012 17:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.683 X-Spam-Level: X-Spam-Status: No, score=-109.683 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF6nW4Xa0Huv; Mon, 16 Jul 2012 17:20:52 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7356B11E811A; Mon, 16 Jul 2012 17:20:51 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6H0LWVY029035 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jul 2012 02:21:33 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 17 Jul 2012 02:21:32 +0200 From: "DRAGE, Keith (Keith)" To: James Polk , Paul Kyzivat , "rai@ietf.org" Date: Tue, 17 Jul 2012 02:21:31 +0200 Thread-Topic: [RAI] FW: Expert Review of 6 new SIP header fields defined by OMA CPM 1.0 Thread-Index: Ac1jregKo9FzNER/RMKKfMkgCDh4owAA+alQ Message-ID: References: <201207161935.q6GJZ03k006108@mtv-core-1.cisco.com> <5004766F.1090104@alum.mit.edu> <201207162351.q6GNpIIp004258@mtv-core-1.cisco.com> In-Reply-To: <201207162351.q6GNpIIp004258@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "insipid@ietf.org" Subject: Re: [Insipid] [RAI] FW: Expert Review of 6 new SIP header fields defined by OMA CPM 1.0 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, 17 Jul 2012 00:20:53 -0000 We agree that the requirements currently preclude it. In the charter that only words that would preclude it are: " This group will focus on a document that will specify a SIP identifier that has the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries." There are plenty of other words that would allow it, and the quoted words a= bove are only "focus", not "concentrate entirely". But in any case, let us see if we have a proposal coming in. Keith > -----Original Message----- > From: James Polk [mailto:jmpolk@cisco.com] > Sent: 17 July 2012 00:51 > To: DRAGE, Keith (Keith); Paul Kyzivat; rai@ietf.org > Cc: insipid@ietf.org > Subject: Re: [RAI] FW: Expert Review of 6 new SIP header fields defined b= y > OMA CPM 1.0 >=20 > I'm not sure I agree with everything you said, but could be wrong. >=20 > It appears what OMA wants is to relate non-dialog transactions > together, with the ability to pick back up a relationship that > existed in the past, went either dormant or idle, then someone from > that previous transaction(s) starts again what they call the > Conversation-ID or that someone not in the previous (set of) > transaction(s) joins while not changing the Conversation-ID. >=20 > This to me is completely new wrt the scope of INSIPID's charter and > not an issue the current requirements not articulating this as a > use-case. The reason why I asked was that I could see it as a phase > II approach for INSIPID after the initial work is completed (i.e., > via a recharter). Of concern would be the idea of having a > Session-ID from INSIPID be unique through space and time, but > resurrectable. IOW, any Session-ID would be able to be active > whenever an entity or actor wants to use it again. IMO this violates > the "unique through space and time" aspect. I can see there being a > real problem for one of the charter stated use-cases about logging > and analysis. If a provider thinks it has a good handle on a > communications session, from start to end (i.e., which final response > is the final response for the Session-ID?). Wouldn't it be a real > problem for there really to be no end (because it is resurrectable)? >=20 > James >=20 > (copying insipid for those who aren't on the rai list) >=20 > At 06:18 PM 7/16/2012, DRAGE, Keith (Keith) wrote: > >Given Adam's response that these should all be standards track as > >currently defined, then if they do come in in that form, then there > >does need to be a reevaluation of the scope of the current INSIPID > >requirements. > > > >As far as I am aware it is not the scope of the INSIPID charter that > >rules this out, but only the requirements currently drafted in the > >working group document. > > > >Keith > > > > > -----Original Message----- > > > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of > Paul > > > Kyzivat > > > Sent: 16 July 2012 21:16 > > > To: rai@ietf.org > > > Subject: Re: [RAI] FW: Expert Review of 6 new SIP header fields > defined by > > > OMA CPM 1.0 > > > > > > On 7/16/12 3:34 PM, James Polk wrote: > > > > haven't thought this through completely, but where would the new > > > > Session-ID fit into this? The Session-ID within the INSIPID WG is > coming > > > > down the pipe really soon, and seems to track *similarly* to how I > read > > > > the OMA's desired use of the Conversation-ID. > > > > > > I don't think it is the same. IIUC they want to use a common ID for > > > multiple dialogs, and independent transactions (like MESSAGE) that > > > otherwise appear to be independent but are semantically related. > > > > > > AFAIK that is beyond the scope of session-id. > > > > > > I still think they can accomplish their goals with existing mechanism= s > > > (and sufficiently smart B2BUAs). But obviously they don't agree. I > don't > > > know how this will get sorted out. > > > > > > Thanks, > > > Paul > > > > > > > James > > > > > > > > At 01:25 PM 7/16/2012, Cristina Badulescu wrote: > > > >> Content-Language: en-US > > > >> Content-Type: multipart/alternative; > > > >> > > > >> > > > > boundary=3D"_000_B802D092CAFAB344B354F0977DEB71EE558AE7C7C4EUSAACMS0703e_= " > > > >> > > > >> Dear all, > > > >> > > > >> > > > >> ...continuing to respond to RAI review comments below; I hope that > > > >> I've collected all comments previously circulated on RAI list. > > > >> > > > >> > > > >> Comment (email 19/03/2012 Paul Kyzivat) > > > >> OMA Header Possible Alternative > > > >> -------------------------- ------------------------------------- > > > >> Conversation-ID Message-ID of 1st message > > > >> [Cristina] OMA CPM has the concept of "Conversation" which groups > > > >> together for example chat sessions, file transfers, standalone > > > >> messages, subsequent disposition notifications e.g. 'delivered'. > The > > > >> Conversation content (messages, file tranfers, notifications, etc) > is > > > >> identified and stored all together, by the Conversation-ID which > ties > > > >> them all together. > > > >> > > > >> > Contribution-ID Message-ID > > > >> > > > >> [Cristina] Same as above, it has to apply to more than messages - > as > > > >> it ties together chat sessions, file transfers within a chat > session. > > > >> > > > >> > InReplyTo-Contribution-ID In-Reply-To > > > >> > > > >> [Cristina] A header with the equivalent syntax to the Contribution= - > ID > > > >> was created, for correlation and sequencing within a conversation. > > > >> > > > >> > Session-Replaces References(?) > > > >> > > > >> [Cristina] This is supposed to carry a Contribution-ID - not sure > > > >> where References is defined (CPM 1.0 was Candidate Approved in > 2010). > > > >> > > > >> > Message-Expires Expires(?) > > > >> > > > >> [Cristina] In OMA CPM the message might be deferred and stored in > the > > > >> network if the recipient is not available, for later delivery or > user > > > >> initiated retrieval of the stored message. So message-expires is a > way > > > >> for the sender to indicate the expiry time of the message itself > (e.g. > > > >> a too late retrieval might be useless from the message content > > > >> perspective). It is not related to the "Expires" header for the SI= P > > > >> transaction. > > > >> > > > >> > Message-UID Message-ID > > > >> > > > >> [Cristina] This header is related to the way messages are > identified > > > >> in the Message Store accessible through IMAP. > > > >> > > > >> Comment (email 20/03/2012 - Dale Worley) > > > >> ---------------------------------------------- > > > >> Conversation-ID Message-ID of 1st message > > > >> Contribution-ID Message-ID > > > >> InReplyTo-Contribution-ID In-Reply-To > > > >> Session-Replaces References(?) > > > >> all have a value that is syntactically "word", as opposed to Call- > Id, > > > >> whose syntax is "word ['@' word]". For consistency's sake I'd like > to > > > >> see them all use the same syntax. Section 3.2 suggests that the > > > >> datatypes of these headers has already been fixed in [OMA-CPM-SD]. > > > >> > > > >> [Cristina] Answer is same as in my previous email to Adam. > > > >> Call-Id syntax was not used since the values of these headers > should > > > >> be created and used in a way unrelated to Call-Id. These ID's are > > > >> expected to simply be copied over at B2BUA's so they will remain > the > > > >> same on an end to end basis (passing through SBCs). We wanted to > avoid > > > >> any cases where SBCs could alter the new headers in any way (e.g. > even > > > >> a blind replacement of the ['@' word]" part). > > > >> > > > >> Also, in CPM scenarios where a closed group chat session is revive= d > > > >> later on by any one of the original participating UAs (i.e. > > > >> re-initiating it), the same Conversation-ID of the previous group > chat > > > >> INVITE would have to be used. As this later UA could be in a > different > > > >> domain, carrying the original ['@' word]" part does not serve any > > > >> purpose (but can be confusing). > > > >> > > > >> > > > >> Regards > > > >> Cristina > > > >> _______________________________________________ > > > >> RAI mailing list > > > >> RAI@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/rai > > > > > > > > _______________________________________________ > > > > RAI mailing list > > > > RAI@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rai > > > > > > > > > > _______________________________________________ > > > RAI mailing list > > > RAI@ietf.org > > > https://www.ietf.org/mailman/listinfo/rai > >_______________________________________________ > >RAI mailing list > >RAI@ietf.org > >https://www.ietf.org/mailman/listinfo/rai From paulej@packetizer.com Tue Jul 24 19:51:42 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589FF11E80A4 for ; Tue, 24 Jul 2012 19:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vpycn1oSdFab for ; Tue, 24 Jul 2012 19:51:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 90FD811E8097 for ; Tue, 24 Jul 2012 19:51:37 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6P2pYJq003176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 22:51:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343184695; bh=LhgXmBZMJLNWWlNfTaZr7CljbP1V7IGywZGQ76c/v4U=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=GBke+vItGORMBYbae7VOOusd7p8imXdHmy48XCnJNhUIQ3wbO12dIOPo0upj8pgli UIJx1POxrDgCfmdmfMaKf3Z4shDYALNWjXrsl+Wj+tmkQfewY5UKYFfNwJamaADNje li4ocURWNSy7/EGM5w3n0raAZZEmCb/dn7OEQ/jI= From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'James Polk'" References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> In-Reply-To: <4FFE0E42.6060806@alum.mit.edu> Date: Tue, 24 Jul 2012 22:51:36 -0400 Message-ID: <005101cd6a10$68e08ce0$3aa1a6a0$@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: AQKKeQ3ycBTDCxy0/njVbETmXsGnNQJPd8dFAk1S0scC5qHme5WDCS6g Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 25 Jul 2012 02:51:42 -0000 Paul, Following up on this thread, as I did not see an outcome. I think this message might be the last in the series on this topic. I think your proposal is along the lines of what we originally proposed. As I understand, there is a desire to always include both A and B's halves. That's fine, so long as devices understand they might change from one message to the next. So given these two abbreviated UUIDs: UUID 1: 0xaeffa652 UUID 2: 0xbe11afc8 We would have: Session-ID: 0xaeffa652be11afc8 If we agree to encode it in hex and agree on the size (a 16 octet UUID), that means this will always be a 64-byte hex string and there is no need to put a :. We could also base64 encode the 64 octet binary value, which would encode in 44 octets (shaving off 20 octets). Do we want to go for reduced size or more readable hex string? As for putting the entire Session-ID into messages, there are many situations where the Session-ID will be wrong. Let me give you just one example. Syntax: A == B means A is in a call with B A == B && A == C (A in call with B; A has a separate call with C.) && B == D (B has a separate call with D) A & B are talking. A puts B on hold. A starts talking to C. Meanwhile B puts A on hold and talks to D. A performs some action to join B and C, while at the same time B performs some action to join D and C Assuming a PBX does this magic, we might have some INVITE messages going down the wire like this: + INVITE ----> C (so C can talk to B) (Session-ID: B || C) PBX1 ---| + INVITE ----> B (so B can talk to C) (Session-ID: B || C) And we have + INVITE ----> A (so A can talk to D) (Session-ID: A || D) PBX2 ---| + INVITE ----> D (so D can talk to A) (Session-ID: A || D) Now, these messages are passing on the wire at the same time. So that message from PBX1 heading toward B is actually now heading toward D. So, what D receives is Session-ID "B || C". D thought the Session-ID was A || D. It will be confused. Perhaps PBX2 can massage the Session-ID, but it's not supposed to do that. We really don't want intermediaries to touch it. To avoid these kinds of race conditions, adding complexity to try to straighten it out, etc., I very much prefer to have only the Session-ID-UUID header that contains only the UUID of the sender of the message. If we did that, the endpoints in the above scenario would not be confused and the correct Session-ID could be noted in logs. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, July 11, 2012 7:38 PM > To: James Polk > Cc: insipid@ietf.org > Subject: Re: [Insipid] Session-ID construction choices > > On 7/11/12 6:23 PM, James Polk wrote: > ... > >>> Option#1 - attach a prefix (e.g., From: and To:) to each half > ... > >>> We have a proposal going forward: insert the From:/To: tags from > >>> Option #1. > >>> > >>> Does anyone have a technical reason why this wouldn't work? > >> > >> Do you mean to assign From and To once, and then keep it fixed for > >> the duration of the dialog? ISTM that From and To are not well > >> defined in all cases. > >> > >> For instance, consider a BTBUA that sets up a session by inviting > >> both endpoints. Which is From and which is To? IIUC, the reason for > >> labeling this way is so that someone observing a session id in a > >> message can tell which half corresponds to which end. Using From and > >> To won't satisfy that unless those tags are reassigned for each > request. > >> (This is a special case of a conference focus, which you already call > >> out as an exception.) > > > > The desire is to have the same half in the same position throughout > > the transaction or dialog (whichever it is). I believe in the case of > > a B2BUA initiating or originating the transaction or dialog on behalf > > of other endpoint UAs, the B2BUA would pick which Session-ID is the > > From and which is the To. IOW - we don't make it a requirement on an > > implementation that Alice is always inserting her half in first, and > > Bob in as the second half. If the B2BUA is sending an INVITE to both > > Alice and Bob, then that's 2 separate Session-IDs because it's two > > different dialogs, even if a 3rd party isn't part (i.e., listening) of > > the media flow. This would be a hub and 2 spokes in which the hub > > doesn't listen or interact with the media of the 2 UAs. > > > > We could also have text that says for this scenario, that an INVITE > > normally inserts the From half of the Session-ID, but that in this > > scenario it can insert the To: half and the invitee inserts the To half. > > > > > >> Identifying which end is which is easy for any single transaction, > > > > agreed > > > >> but hard if you want to use the same identifiers in every message. > >> The endpoints can easily figure this out, because they should know > >> their half, and the half that isn't theirs is the other end's. But > >> its not simple for middleboxes. > > > > remember that each half is a UUID or GUID, which will always be a > > unique value through space and time. > > > > > >> The solution that is used for dialog ids is to use To and From, but > >> they must be reassigned depending on the direction of the message. We > >> could do the same for session id, but only if they are remapped based > >> on the direction of the request. > > > > I guess I'm no getting why the halves need to switch places yet > > depending on whether it's in a request or response. Or are you saying > > that for one complete transaction they are in a certain order, but in > > a related transaction(s) they are possibly in the reverse order - > > depending on who sent the message? > > When a message is sent in the reverse direction from the dialog > establishing message, the From URI and To URI are reversed, as well as the > From and To tags. If the session id still has its halves tagged consistent > with the from and to of the dialog establishing request, then you will get > confused about which half goes with which end. > > There is no problem for servers that keep state and remember the values > for each end. For them we don't need to tag the halves at all. > > There is also no problem for those who don't *care* which end is which. > And there may be a lot of those. > > This tagging is only there for those who don't keep state yet need to > know. Maybe there aren't any of those, in which case we can stop worrying > about it. > > I guess an example that might matter is something analyzing logs, and > doesn't have a complete set of logs available to it - in particular it > doesn't have a log of the initial signaling that set up the session, so it > can't figure out which half-id belongs to which end. > > Then it sees a change - it sees a message where half of the id matches > prior things, but the other half doesn't - is new. From this it can > perhaps infer that there was a transfer. And in that case it will want to > know which end remains and which was replaced. But it can't figure that > out from which half of the id changed without knowing the mapping from > half to end. > > But I will be the first to say that this case is somewhat implausible. > In practice there will be lots of stuff in the messages being analyzed > that should support figuring this out. Perhaps this just isn't a good > example, and there is another that is better. But I don't know a better > one. Anybody else? (I think Paul J was the one who raised this concern, so > maybe he has an example.) > > If we can't find a plausible reason why we need to do this mapping, then I > propose that we just not bother. In that case I think representation > #3 is attractive. It provides for the easiest comparison between id values > - a single string comparison is sufficient. And its among the most compact > representations. I'd recommend: > > session-id: SmallestHalf:BiggestHalf > > Or just > > session-id: FirstHalf > > before the half for the far end has been assigned. > > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Tue Jul 24 19:53:20 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3963011E8097 for ; Tue, 24 Jul 2012 19:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 hwiQ+IUXO9y9 for ; Tue, 24 Jul 2012 19:53:16 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D111311E8080 for ; Tue, 24 Jul 2012 19:53:15 -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 q6P2rClu003234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 22:53:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343184793; bh=sN2X/km0uMLb+5a17n0gH7Rx1S88Z6rGxxHMQZVLeU0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=Qf7lI45zwvJ6zDAPzoXc5vmPsFhsSTRKjer4d+HTd7Ov3ggZ+JD7CFqlgzOe0AbHH lA8Fjm4VMISJD+l+O71s0BE3+gF02xfnKFDwL29KidZ9ijFm1Jm0cmt3/78wAy/nQJ A88rwZ/Ffx3Wdp/A0OKlJJFv0W2BV49NaEbiUim0= From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> In-Reply-To: Date: Tue, 24 Jul 2012 22:53:14 -0400 Message-ID: <005301cd6a10$a31cb140$e95613c0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CD69EF.1C0FCC30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAAIZ3s8FAiAEuxoBrzjzyAH42j74AfwUrrMCenXM8QIx6CmIAnTj8HYB0kR7bgJlec1emDPw3wA= Content-Language: en-us Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 25 Jul 2012 02:53:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01CD69EF.1C0FCC30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Keith, Was there any consensus on modifications to REQ1 or REQ1a? Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Wednesday, July 11, 2012 9:02 AM To: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case [As individual] What I took away from the discussion yesterday was: - that REQ 1 represents the session ID requirement for a number of transactions bound up in a dialog, whereas REQ 1A represents the session ID requirement for a transaction not so bound. - For each of these requirements we need to cover the existence over time, and the existence over space. - The existence over space requirement is identical for both, i.e. that UA A, UAB, and all the entities inbetween will be able to see the same session ID, such that some other entity trying to correlate information feeds from these entities will be able to do so. - The existence over time requirement only applies to REQ 1, i.e. that all transactions within the same dialog should share the same session ID. I do not believe there is a requirement for session ID within the transaction, i.e. between request and response - that is dealt with by other mechanisms. We have no requirement for correlation between two transactions that are not within a dialog. While it would be possible to draft this round the existing requirement split, I suggest maybe we just do the split round the time and space division. So the new revised requirements might look like (in place of the existing). REQ 1B: It must be possible for the same identifier to appear at all entities participating in a SIP transaction, such that an external device that monitors the SIP traffic can use that identifier to correlate the same transaction at each of those entities. REQ 1C: It must be possible for the same identifier to appear in all transactions that form part of a SIP dialog, such that the transactions that form part of the dialog can be correlated together. There is no requirement for the identifier to correlate parts of a single transaction (i.e. request and response) as existing SIP mechanisms are assumed to do that. There is no requirement for the identifier to correlate two transactions that do not form part of the same dialog (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a MESSAGE transaction and a subsequent MESSAGE transaction), except as expressed in other requirements. Note the "except" in REQ 1C above is to allow the transfer requirements in REQ2. If the new REQ 1B is acceptable, then we should also consider how distinct that is from REQ 4. Keith _____ From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: 11 July 2012 13:10 To: Laura Liess Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case What shall be the wording of REQ1a? Paul _____ From: Laura Liess Sent: Wed Jul 11 03:14:07 EDT 2012 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case Paul, After the discussion yesterday in the Webex meeting, it seems to me that separate requirements for dialogs and transactions are needed. Thanks Laura 2012/7/11 Paul E. Jones : > Indeed, you're right. It does cover both, but folks called for a separate > requirement. > > What is the wishes of the WG on this? Shall I replace REQ1 with the below > text? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Laura Liess >> Sent: Tuesday, July 10, 2012 8:23 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use >> case >> >> Paul, >> >> > >> > What was proposed (by you?) was this: >> > >> > REQ1a: It must be possible for an administrator or an external device >> > which monitors the SIP-traffic to use the identifier to identify those >> > dialogs, transactions and messages which were at some point in time >> > components of a single end-to-end SIP session (e.g., parts of the same >> call). >> >> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is >> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace >> the current text of REQ1 by the proposed text of the REQ1a and then drop >> REQ1a. >> >> Thanks >> Laura >> >> >> >> >> > >> > This is not presently in t! he draft that we just submitted to be a WG >> > document since I was told to base that document on the -03 draft. I >> > had that text in my pending -04 draft, but ... it is still sitting >> > there :-) >> > >> >> > You really want to just remove that text from c)? >> >> [LL] No. I don't. >> >> Also in this scenario the service providers monitors and logs all >> >> B2BUA traffic, incomming and outgoing. There is no log provided by >> >> the customer. >> >> >> >> From my point of view, the text would be : >> >> >> >> _____ >> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging >> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service >> provider. >> >> For privacy reasons, t! he B2BUA changes the SIP headers that reveal >> >> information related to the SIP users, device or domain identity. The >> >> service provider uses an external device to monitor and log all SIP >> >> traffic coming to and from the B2BUA. In the case of failures >> >> reported by the customer or when security issue arise (e.g. theft of >> >> service), the service provider has to analyze the logs from the past >> >> several days or weeks and correlates those messages which were >> >> messages for a single end- to-end SIP session. >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B >> >> does not. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> ----------------- >> >> >> >> >> >> What do you think? >> > >> > >> > Sounds OK to me. I'll put this into me -04 draft and when folks give >> > me the green light, move it into the WG -01 draft. >> > >> > Paul >> > >> > >> _____ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > ------=_NextPart_000_0054_01CD69EF.1C0FCC30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith,

 

Was there any consensus on modifications to REQ1 or = REQ1a?

 

Paul

 

From:= = insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith)
Sent: Wednesday, July 11, 2012 = 9:02 AM
To: insipid@ietf.org
Subject: Re: [Insipid] = REQ 1 / REQ 1A - was Text proposal for the "SIP traffic = monitoring" use case

 

[A= s individual]

 

Wh= at I took away from the discussion yesterday = was:

 

-           = ;  th= at REQ 1 represents the session ID requirement for a number of = transactions bound up in a dialog, whereas REQ 1A represents the session = ID requirement for a transaction not so bound.

-           = ;  Fo= r each of these requirements we need to cover the existence over time, = and the existence over space.

-           = ;  Th= e existence over space requirement is identical for both, i.e. that UA = A, UAB, and all the entities inbetween will be able to see the same = session ID, such that some other entity trying to correlate information = feeds from these entities will be able to do so.

-           = ;  Th= e existence over time requirement only applies to REQ 1, i.e. that all = transactions within the same dialog should share the same session ID. I = do not believe there is a requirement for session ID within the = transaction, i.e. between request and response – that is dealt = with by other mechanisms. We have no requirement for correlation between = two transactions that are not within a dialog.

 

Wh= ile it would be possible to draft this round the existing requirement = split, I suggest maybe we just do the split round the time and space = division. So the new revised requirements might look like (in place of = the existing).

 

RE= Q 1B: It must be possible for the same identifier to appear at all = entities participating in a SIP transaction, such that an external = device that monitors the SIP traffic can use that identifier to = correlate the same transaction at each of those = entities.

 

RE= Q 1C: It must be possible for the same identifier to appear in all = transactions that form part of a SIP dialog, such that the transactions = that form part of the dialog can be correlated together. There is no = requirement for the identifier to correlate parts of a single = transaction (i.e. request and response) as existing SIP mechanisms are = assumed to do that. There is no requirement for the identifier to = correlate two transactions that do not form part of the same dialog = (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a = MESSAGE transaction and a subsequent MESSAGE transaction), except as = expressed in other requirements.

 

No= te the “except” in REQ 1C above is to allow the transfer = requirements in REQ2.

 

If= the new REQ 1B is acceptable, then we should also consider how distinct = that is from REQ 4.

 

Ke= ith

 

From:= = insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones
Sent: 11 July 2012 13:10
To: = Laura Liess
Cc: insipid@ietf.org
Subject: Re: = [Insipid] Text proposal for the "SIP traffic monitoring" use = case

 

What shall be the = wording of REQ1a?

Paul

From:= Laura = Liess <laura.liess.dt@googlemail.com>
Sent: Wed Jul 11 = 03:14:07 EDT 2012
To: "Paul E. Jones" = <paulej@packetizer.com>
Cc: = insipid@ietf.org
Subject: Re: [Insipid] Text proposal for the = "SIP traffic monitoring" use = case

 

Paul,



After the discussion yesterday in the Webex meeting, it =
seems to me

that =
separate requirements for dialogs and transactions are =
needed.



Thanks

Laura



2012/7/11 Paul E. Jones =
<paulej@packetizer.com>:

> Indeed, you're right.  It does cover both, but =
folks called for a separate

> requirement.

>

> What is the wishes of the WG on this?  Shall I =
replace REQ1 with the below

> text?





>

> Paul

>

>> -----Original =
Message-----

>> From: insipid-bounces@ietf.org =
[mailto:insipid-bounces@ietf.org] On =
Behalf

>> =
Of Laura Liess

>> Sent: Tuesday, July 10, 2012 8:23 =
AM

>> To: =
Paul E. Jones

>> Cc: =
insipid@ietf.org

>> Subject: Re: [Insipid] Text proposal for the =
"SIP traffic monitoring" =
use

>> =
case

>>

>> Paul,

>>

>> >

>> > What was proposed (by you?) was =
this:

>> =
>

>> =
> REQ1a: It must be possible for an administrator or an external =
device

>> =
> which monitors the SIP-traffic to use the identifier to identify =
those

>> =
> dialogs, transactions and messages which were at some point in =
time

>> =
> components of a single end-to-end SIP session (e.g., parts of the =
same

>> =
call).

>>

>> [LL] The proposed text of the REQ1a (above) also =
covers the REQ1 (as it is

>> in draft-ietf-insipid-session-id-reqts-00). So I =
think we could replace

>> the current text of REQ1 by the proposed text of =
the REQ1a and then drop

>> REQ1a.

>>

>> Thanks

>> Laura

>>

>>

>>

>>

>> >

>> > This is not presently in =
t!
 he =
draft
that we just =
submitted to be a WG

>> > document since I was told to base that =
document on the -03 draft.  =
I

>> > =
had that text in my pending -04 draft, but ... it is still =
sitting

>> =
> there :-)

>> >

>> >> > You really want to just remove that =
text from c)?

>> >> [LL]  No. I =
don't.

>> =
>> Also in this scenario the service providers monitors and logs =
all

>> =
>> B2BUA traffic, incomming and outgoing.  There is no log =
provided by

>> >> the =
customer.

>> >>

>> >> From my point of view, the text would be =
:

>> =
>>

>> =
>>
 
 
 
 


>> >> User Agent A (A) and User Agent B (B) =
communicate using SIP =
messaging

>> >> with a SIP B2BUA acting as a middlebox =
which belongs to a SIP service

>> =
provider.

>> >> For privacy reasons, =
t!
 he =
B2BUA
changes the SIP =
headers that reveal

>> >> information related to the SIP users, =
device or domain identity. The

>> >> service provider uses an external device =
to monitor and log all SIP

>> >> traffic coming to and from the =
B2BUA.  In the case of =
failures

>> =
>> reported by the customer or when security issue arise (e.g. =
theft of

>> =
>> service), the service provider has to analyze the logs from the =
past

>> =
>> several days or weeks and correlates those messages which =
were

>> =
>> messages for a single end- to-end SIP =
session.

>> =
>>

>> =
>> For this scenario, we must consider three particular use =
cases:

>> =
>>

>> =
>> a) The UAs  A and B support the end-to-end Session =
Identifier.

>> >>

>> >> Derived Requirements: REQ1, REQ1a, REQ4, =
REQ5, REQ8.

>> >>

>> >> b) Only the UA A supports the end-to-end =
Session Identifier, the UA B

>> >> does =
not.

>> =
>>

>> =
>> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, =
REQ8.

>> =
>>

>> =
>> c) UA A and UA  B do not support the end-to-end Session =
Identifier.

>> >>

>> >> Derived Requirements: REQ1, REQ1a, REQ4, =
REQ5, REQ7, REQ8.

>> >> =
-----------------

>> >>

>> >>

>> >> What do you =
think?

>> =
>

>> =
>

>> =
> Sounds OK to me.  I'll put this into me -04 draft and when =
folks give

>> > me the green light, move it into the WG -01 =
draft.

>> =
>

>> =
> Paul

>> >

>> >

>> 
 
 
 
 


>> insipid mailing =
list

>> =
insipid@ietf.org

>> https://www.ietf.o=
rg/mailman/listinfo/insipid

> 
<= /html> ------=_NextPart_000_0054_01CD69EF.1C0FCC30-- From keith.drage@alcatel-lucent.com Wed Jul 25 01:59:38 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B75821F8554 for ; Wed, 25 Jul 2012 01:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.489 X-Spam-Level: X-Spam-Status: No, score=-109.489 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 mobiNwAup551 for ; Wed, 25 Jul 2012 01:59:33 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF1921F84DA for ; Wed, 25 Jul 2012 01:59:32 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6P8xJYN011589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Jul 2012 10:59:29 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 25 Jul 2012 10:59:05 +0200 From: "DRAGE, Keith (Keith)" To: "Paul E. Jones" , "insipid@ietf.org" Date: Wed, 25 Jul 2012 10:59:05 +0200 Thread-Topic: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case Thread-Index: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAAIZ3s8FAiAEuxoBrzjzyAH42j74AfwUrrMCenXM8QIx6CmIAnTj8HYB0kR7bgJlec1emDPw3wCAAEnk4A== Message-ID: References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <005301cd6a10$a31cb140$e95613c0$@packetizer.com> In-Reply-To: <005301cd6a10$a31cb140$e95613c0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE240AE8FE6FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 25 Jul 2012 08:59:38 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE240AE8FE6FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not that I saw yet - you may want to summarise where it got to and see if t= hat produces more input. Keith ________________________________ From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 25 July 2012 03:53 To: DRAGE, Keith (Keith); insipid@ietf.org Subject: RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traf= fic monitoring" use case Keith, Was there any consensus on modifications to REQ1 or REQ1a? Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: Wednesday, July 11, 2012 9:02 AM To: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traf= fic monitoring" use case [As individual] What I took away from the discussion yesterday was: - that REQ 1 represents the session ID requirement for a numb= er of transactions bound up in a dialog, whereas REQ 1A represents the sess= ion ID requirement for a transaction not so bound. - For each of these requirements we need to cover the existen= ce over time, and the existence over space. - The existence over space requirement is identical for both,= i.e. that UA A, UAB, and all the entities inbetween will be able to see th= e same session ID, such that some other entity trying to correlate informat= ion feeds from these entities will be able to do so. - The existence over time requirement only applies to REQ 1, = i.e. that all transactions within the same dialog should share the same ses= sion ID. I do not believe there is a requirement for session ID within the = transaction, i.e. between request and response - that is dealt with by othe= r mechanisms. We have no requirement for correlation between two transactio= ns that are not within a dialog. While it would be possible to draft this round the existing requirement spl= it, I suggest maybe we just do the split round the time and space division.= So the new revised requirements might look like (in place of the existing)= . REQ 1B: It must be possible for the same identifier to appear at all entiti= es participating in a SIP transaction, such that an external device that mo= nitors the SIP traffic can use that identifier to correlate the same transa= ction at each of those entities. REQ 1C: It must be possible for the same identifier to appear in all transa= ctions that form part of a SIP dialog, such that the transactions that form= part of the dialog can be correlated together. There is no requirement for= the identifier to correlate parts of a single transaction (i.e. request an= d response) as existing SIP mechanisms are assumed to do that. There is no = requirement for the identifier to correlate two transactions that do not fo= rm part of the same dialog (e.g. an OPTIONS transaction and a subsequent IN= VITE transaction, or a MESSAGE transaction and a subsequent MESSAGE transac= tion), except as expressed in other requirements. Note the "except" in REQ 1C above is to allow the transfer requirements in = REQ2. If the new REQ 1B is acceptable, then we should also consider how distinct = that is from REQ 4. Keith ________________________________ From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: 11 July 2012 13:10 To: Laura Liess Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use c= ase What shall be the wording of REQ1a? Paul ________________________________ From: Laura Liess Sent: Wed Jul 11 03:14:07 EDT 2012 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use c= ase Paul, After the discussion yesterday in the Webex meeting, it seems to me that separate requirements for dialogs and transactions are needed. Thanks Laura 2012/7/11 Paul E. Jones : > Indeed, you're right. It does cover both, but folks called for a separat= e > requirement. > > What is the wishes of the WG on this? Shall I replace REQ1 with the belo= w > text? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Beha= lf >> Of Laura Liess >> Sent: Tuesday, July 10, 2012 8:23 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" us= e >> case >> >> Paul, >> >> > >> > What was proposed (by you?) was this: >> > >> > REQ1a: It must be possible for an administrator or an external device >> > which monitors the SIP-traffic to use the identifier to identify those >> > dialogs, transactions and messages which were at some point in time >> > components of a single end-to-end SIP session (e.g., parts of the same >> call). >> >> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it = is >> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace >> the current text of REQ1 by the proposed text of the REQ1a and then drop >> REQ1a. >> >> Thanks >> Laura >> >> >> >> >> > >> > This is not presently in t! he draft that we just submitted to be a WG >> > document since I was told to base that document on the -03 draft. I >> > had that text in my pending -04 draft, but ... it is still sitting >> > there :-) >> > >> >> > You really want to just remove that text from c)? >> >> [LL] No. I don't. >> >> Also in this scenario the service providers monitors and logs all >> >> B2BUA traffic, incomming and outgoing. There is no log provided by >> >> the customer. >> >> >> >> From my point of view, the text would be : >> >> >> >> ________________________________ >> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging >> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service >> provider. >> >> For privacy reasons, t! he B2BUA changes the SIP headers that reveal >> >> information related to the SIP users, device or domain identity. The >> >> service provider uses an external device to monitor and log all SIP >> >> traffic coming to and from the B2BUA. In the case of failures >> >> reported by the customer or when security issue arise (e.g. theft of >> >> service), the service provider has to analyze the logs from the past >> >> several days or weeks and correlates those messages which were >> >> messages for a single end- to-end SIP session. >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B >> >> does not. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> ----------------- >> >> >> >> >> >> What do you think? >> > >> > >> > Sounds OK to me. I'll put this into me -04 draft and when folks give >> > me the green light, move it into the WG -01 draft. >> > >> > Paul >> > >> > >> ________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > --_000_EDC0A1AE77C57744B664A310A0B23AE240AE8FE6FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Not that I saw yet – you may wan= t to summarise where it got to and see if that produces more input.

 

Keith

 

From:= Paul E. Jones [mailto:paulej@packetizer.com]
Sent: 25 July 2012 03:53
To: DRAGE, Keith (Keith); insipid@ietf.org
Subject: RE: [Insipid] REQ 1= / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case<= /span>

 

Keith,

 

Was there any consensus on modifications to REQ1 or REQ1a?

 

Paul

 

From:= insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Wednesday, July 11, 2012= 9:02 AM
To: insipid@ietf.org
Subject: Re: [Insipid] REQ 1= / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case<= o:p>

 

[As individual]

 

What I took away from the discussion yesterday was:

 

-      =          = that REQ 1 represents the session ID requirement for a number of transactions bound = up in a dialog, whereas REQ 1A represents the session ID requirement for a transaction not so bound.

-      =          = For each of these requirements we need to cover the existence over time, and the existence over space.

-      =          = The existence over space requirement is identical for both, i.e. that UA A, UAB= , and all the entities inbetween will be able to see the same session ID, suc= h that some other entity trying to correlate information feeds from these entities will be able to do so.

-      =          = The existence over time requirement only applies to REQ 1, i.e. that all transactions within the same dialog should share the same session ID. I do = not believe there is a requirement for session ID within the transaction, i.e. between request and response – that is dealt with by other mechanisms= . We have no requirement for correlation between two transactions that are not within= a dialog.

 

While it would be possible to draft th= is round the existing requirement split, I suggest maybe we just do the split round the time and space division. So the new revised requirements might lo= ok like (in place of the existing).

 

REQ 1B: It must be possible for the sa= me identifier to appear at all entities participating in a SIP transaction, su= ch that an external device that monitors the SIP traffic can use that identifi= er to correlate the same transaction at each of those entities.

 

REQ 1C: It must be possible for the sa= me identifier to appear in all transactions that form part of a SIP dialog, su= ch that the transactions that form part of the dialog can be correlated togeth= er. There is no requirement for the identifier to correlate parts of a single transaction (i.e. request and response) as existing SIP mechanisms are assu= med to do that. There is no requirement for the identifier to correlate two transactions that do not form part of the same dialog (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a MESSAGE transaction a= nd a subsequent MESSAGE transaction), except as expressed in other requirements.=

 

Note the “except” in REQ 1= C above is to allow the transfer requirements in REQ2.

 

If the new REQ 1B is acceptable, then = we should also consider how distinct that is from REQ 4.

 

Keith

 

From:= insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: 11 July 2012 13:10
To: Laura Liess
Cc: insipid@ietf.org
Subject: Re: [Insipid] Text = proposal for the "SIP traffic monitoring" use case

 

What shall be the= wording of REQ1a?

Paul

From: Laura Li= ess <laura.liess.dt@googlemail.com>
Sent: Wed Jul 11 03:14:07 = EDT 2012
To: "Paul E. Jones"= ; <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case

 = 

Paul,
 
After the discussion yesterday in the Webex meet=
ing, it seems to me
that separate requirements for dialogs and trans=
actions are needed.
 
Thanks
Laura
 
2012/7/11 Paul E. Jones <paulej@packetizer.co=
m>:
> Indeed, you're right.  It does cover b=
oth, but folks called for a separate
> requirement.
= 
> 
> What is the wishes of the WG on this? =
 Shall I replace REQ1 with the below
> text?
 
 
> 
> Paul
> 
>> -----Original Message-----
>> From: insipid-bounces@ietf.org [mailto:=
insipid-bounces@ietf.org] On Behalf
>> Of Laura Liess=

>> Sent: Tuesday, July 10, 2012 8:23 AM
>> To: Paul E. Jones
>> Cc: insipid@ietf.org<=
/font>
>> Subject: Re: [Insipid] Text proposal fo=
r the "SIP traffic monitoring" use
= 
>> case
>> 
>> Paul,>> >> >
>> > What was proposed (by you?) was th=
is:
>> >
>> > REQ1a: It must be possible for an =
administrator or an external device
>> > which monitors the SIP-traffic to =
use the identifier to identify those
>> > dialogs, transactions and messages=
 which were at some point in time
>> > components of a single end-to-end =
SIP session (e.g., parts of the same
>> call).
>> >> [LL] The proposed text of the REQ1a (ab= ove) also covers the REQ1 (as it is
>> in draft-ietf-insipid-session-id-reqts-=
00). So I think we could replace
>> the current text of REQ1 by the propose=
d text of the REQ1a and then drop
>> REQ1a.
>> >> Thanks>> Laura>> >> >> >> >> >>> >= ; This is not presently in t!
 he draft
that we just submitted to be a WG
>> > document since I was told to base =
that document on the -03 draft.  I
>> > had that text in my pending -04 dr=
aft, but ... it is still sitting
>> > there :-)=

>> >
>> >> > You really want to just r=
emove that text from c)?
>> >> [LL]  No. I don't.
>> >> Also in this scenario the serv=
ice providers monitors and logs all
>> >> B2BUA traffic, incomming and o=
utgoing.  There is no log provided by
>> >> the customer.
>> >>
= 
>> >> From my point of view, the tex=
t would be :
>> >>
= 
>> >=
;>
 
 






 
 
 
>> >> User Agent A (A) and User Agen=
t B (B) communicate using SIP messaging
>> >> with a SIP B2BUA acting as a m=
iddlebox which belongs to a SIP service
>> provider.
>> >=
;> For privacy reasons, t!
 he B2BUA
changes the SIP headers that reveal
>> >> information related to the SIP=
 users, device or domain identity. The
>> >> service provider uses an exter=
nal device to monitor and log all SIP
>> >> traffic coming to and from the=
 B2BUA.  In the case of failures
>> >> reported by the customer or wh=
en security issue arise (e.g. theft of
>> >> service), the service provider=
 has to analyze the logs from the past
>> >> several days or weeks and corr=
elates those messages which were
>> >> messages for a single end- to-=
end SIP session.
>> >>
=

>> >> For this scenario, we must con=
sider three particular use cases:
>> >>
=

>> >> a) The UAs  A and B suppo=
rt the end-to-end Session Identifier.
>> >>
=

>> >> Derived Requirements: REQ1, RE=
Q1a, REQ4, REQ5, REQ8.
>> >>
=

>> >> b) Only the UA A supports the =
end-to-end Session Identifier, the UA B
>> >> does not.
>> >>
=

>> >> Derived Requirements: REQ1, RE=
Q1a, REQ4, REQ5, REQ7, REQ8.
>> >>
=

>> >> c) UA A and UA  B do not =
support the end-to-end Session Identifier.
>> >>
= 
>> >> Derived Requirements: REQ1, RE=
Q1a, REQ4, REQ5, REQ7, REQ8.
>> >> -----------------
>> >>
= 
>> >>
= 
>> >> What do you think?<=
/span>
>> >
>> >
>> > Sounds OK to me.  I'll put th=
is into me -04 draft and when folks give
>> > me the green light, move it into t=
he WG -01 draft.
>> >
>> > Paul
>> >
>> >
>> 
 
 






 
 
 
>> insipid mailing list<=
/font>
>> insipid@ietf.org
>> https://www.ietf.org=
/mailman/listinfo/insipid
>&nb=
sp;
--_000_EDC0A1AE77C57744B664A310A0B23AE240AE8FE6FRMRSSXCHMBSC3d_-- From paulej@packetizer.com Wed Jul 25 07:48:15 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2621F8596 for ; Wed, 25 Jul 2012 07:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 AapfuvAz7DFw for ; Wed, 25 Jul 2012 07:48:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 70A4621F852E for ; Wed, 25 Jul 2012 07:48: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 q6PEm5xv030799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jul 2012 10:48:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343227686; bh=Mgtq0ZsfwP/j2o2Nf6uFlpp6GOEv425ZMPT/7pqv3vw=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=H1oseJs3aoNvHXFqdn3lrNVgHe3KVOSmA9opoi4hsCEIm+83H43OcfJjhf2N6e5Tn UBjlzGAo+t50HwO9FGBr+irtsWE6oOqSzGWujduM71SKt5W0EsgQdOnuWZWYjzUHfQ chcxuvcqua+0Rs5uVFZAaUXSX1pWmZAK9thOSY9M= From: "Paul E. Jones" To: "'DRAGE, Keith \(Keith\)'" , References: <04e501cd5980$45f013e0$d1d03ba0$@packetizer.com> <064d01cd5a43$b97b8100$2c728300$@packetizer.com> <0c2c01cd5e51$7b525e50$71f71af0$@packetizer.com> <0dcc01cd5f0e$521437d0$f63ca770$@packetizer.com> <1ee96553-a2fb-471d-95c9-7464707ca5c4@email.android.com> <005301cd6a10$a31cb140$e95613c0$@packetizer.com> In-Reply-To: Date: Wed, 25 Jul 2012 10:48:07 -0400 Message-ID: <00a801cd6a74$81c0f6f0$8542e4d0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01CD6A52.FAB411E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD7O/c3CYUFuF4eJA6C3E7N37ZZAAIZ3s8FAiAEuxoBrzjzyAH42j74AfwUrrMCenXM8QIx6CmIAnTj8HYB0kR7bgJlec1eAwmVB9MBo7qz25gPTKbg Content-Language: en-us Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case 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, 25 Jul 2012 14:48:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01CD6A52.FAB411E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't think I can summarize it. I looked over the thread, but I didn't see convergence. I didn't see divergence, either. I think James said he knows what you're after. There was discussion on the definition of "session". I didn't see anything resembling a conclusion. Do we want to form REQ1a,b,c? There was a call to merge REQ1 and REQ1a together. So, what I have as the current proposal is a single REQ1: "It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify those dialogs, transactions and messages which were at some point in time components of a single end-to-end SIP session (e.g., parts of the same call)." Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, July 25, 2012 4:59 AM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case Not that I saw yet - you may want to summarise where it got to and see if that produces more input. Keith _____ From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: 25 July 2012 03:53 To: DRAGE, Keith (Keith); insipid@ietf.org Subject: RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case Keith, Was there any consensus on modifications to REQ1 or REQ1a? Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Wednesday, July 11, 2012 9:02 AM To: insipid@ietf.org Subject: Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP traffic monitoring" use case [As individual] What I took away from the discussion yesterday was: - that REQ 1 represents the session ID requirement for a number of transactions bound up in a dialog, whereas REQ 1A represents the session ID requirement for a transaction not so bound. - For each of these requirements we need to cover the existence over time, and the existence over space. - The existence over space requirement is identical for both, i.e. that UA A, UAB, and all the entities inbetween will be able to see the same session ID, such that some other entity trying to correlate information feeds from these entities will be able to do so. - The existence over time requirement only applies to REQ 1, i.e. that all transactions within the same dialog should share the same session ID. I do not believe there is a requirement for session ID within the transaction, i.e. between request and response - that is dealt with by other mechanisms. We have no requirement for correlation between two transactions that are not within a dialog. While it would be possible to draft this round the existing requirement split, I suggest maybe we just do the split round the time and space division. So the new revised requirements might look like (in place of the existing). REQ 1B: It must be possible for the same identifier to appear at all entities participating in a SIP transaction, such that an external device that monitors the SIP traffic can use that identifier to correlate the same transaction at each of those entities. REQ 1C: It must be possible for the same identifier to appear in all transactions that form part of a SIP dialog, such that the transactions that form part of the dialog can be correlated together. There is no requirement for the identifier to correlate parts of a single transaction (i.e. request and response) as existing SIP mechanisms are assumed to do that. There is no requirement for the identifier to correlate two transactions that do not form part of the same dialog (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a MESSAGE transaction and a subsequent MESSAGE transaction), except as expressed in other requirements. Note the "except" in REQ 1C above is to allow the transfer requirements in REQ2. If the new REQ 1B is acceptable, then we should also consider how distinct that is from REQ 4. Keith _____ From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: 11 July 2012 13:10 To: Laura Liess Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case What shall be the wording of REQ1a? Paul _____ From: Laura Liess Sent: Wed Jul 11 03:14:07 EDT 2012 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use case Paul, After the discussion yesterday in the Webex meeting, it seems to me that separate requirements for dialogs and transactions are needed. Thanks Laura 2012/7/11 Paul E. Jones : > Indeed, you're right. It does cover both, but folks called for a separate > requirement. > > What is the wishes of the WG on this? Shall I replace REQ1 with the below > text? > > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Laura Liess >> Sent: Tuesday, July 10, 2012 8:23 AM >> To: Paul E. Jones >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Text proposal for the "SIP traffic monitoring" use >> case >> >> Paul, >> >> > >> > What was proposed (by you?) was this: >> > >> > REQ1a: It must be possible for an administrator or an external device >> > which monitors the SIP-traffic to use the identifier to identify those >> > dialogs, transactions and messages which were at some point in time >> > components of a single end-to-end SIP session (e.g., parts of the same >> call). >> >> [LL] The proposed text of the REQ1a (above) also covers the REQ1 (as it is >> in draft-ietf-insipid-session-id-reqts-00). So I think we could replace >> the current text of REQ1 by the proposed text of the REQ1a and then drop >> REQ1a. >> >> Thanks >> Laura >> >> >> >> >> > >> > This is not presently in t! he draft that we just submitted to be a WG >> > document since I was told to base that document on the -03 draft. I >> > had that text in my pending -04 draft, but ... it is still sitting >> > there :-) >> > >> >> > You really want to just remove that text from c)? >> >> [LL] No. I don't. >> >> Also in this scenario the service providers monitors and logs all >> >> B2BUA traffic, incomming and outgoing. There is no log provided by >> >> the customer. >> >> >> >> From my point of view, the text would be : >> >> >> >> _____ >> >> User Agent A (A) and User Agent B (B) communicate using SIP messaging >> >> with a SIP B2BUA acting as a middlebox which belongs to a SIP service >> provider. >> >> For privacy reasons, t! he B2BUA changes the SIP headers that reveal >> >> information related to the SIP users, device or domain identity. The >> >> service provider uses an external device to monitor and log all SIP >> >> traffic coming to and from the B2BUA. In the case of failures >> >> reported by the customer or when security issue arise (e.g. theft of >> >> service), the service provider has to analyze the logs from the past >> >> several days or weeks and correlates those messages which were >> >> messages for a single end- to-end SIP session. >> >> >> >> For this scenario, we must consider three particular use cases: >> >> >> >> a) The UAs A and B support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ8. >> >> >> >> b) Only the UA A supports the end-to-end Session Identifier, the UA B >> >> does not. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> >> >> c) UA A and UA B do not support the end-to-end Session Identifier. >> >> >> >> Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, REQ8. >> >> ----------------- >> >> >> >> >> >> What do you think? >> > >> > >> > Sounds OK to me. I'll put this into me -04 draft and when folks give >> > me the green light, move it into the WG -01 draft. >> > >> > Paul >> > >> > >> _____ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > ------=_NextPart_000_00A9_01CD6A52.FAB411E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t think I can summarize it.  I looked over the = thread, but I didn’t see convergence.  I didn’t see = divergence, either.

 

I think James said he knows what you’re after.  There was = discussion on the definition of “session”.  I = didn’t see anything resembling a = conclusion.

 

Do we want to form REQ1a,b,c?  There was a call to merge REQ1 = and REQ1a together.  So, what I have as the current proposal is a = single REQ1:

 

“It must be possible for an administrator or an external device = which monitors the SIP-traffic to use the identifier to identify those = dialogs, transactions and messages which were at some point in time = components of a single end-to-end SIP session (e.g., parts of the same = call).”

 

Paul

 

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] =
Sent: Wednesday, July 25, 2012 4:59 AM
To: Paul E. = Jones; insipid@ietf.org
Subject: RE: [Insipid] REQ 1 / REQ 1A = - was Text proposal for the "SIP traffic monitoring" use = case

 

No= t that I saw yet – you may want to summarise where it got to and = see if that produces more input.

 

Ke= ith

 

From:= = Paul E. Jones [mailto:paulej@packetizer.= com]
Sent: 25 July 2012 03:53
To: DRAGE, Keith = (Keith); insipid@ietf.org
Subject: = RE: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP = traffic monitoring" use case

 

Keith,

 

Was there any consensus on modifications to REQ1 or = REQ1a?

 

Paul

 

From:= = insipid-bounces@ietf.org = [mailto:insipid-bounces= @ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: = Wednesday, July 11, 2012 9:02 AM
To: insipid@ietf.org
Subject: = Re: [Insipid] REQ 1 / REQ 1A - was Text proposal for the "SIP = traffic monitoring" use case

 

[A= s individual]

 

Wh= at I took away from the discussion yesterday = was:

 

-        = th= at REQ 1 represents the session ID requirement for a number of = transactions bound up in a dialog, whereas REQ 1A represents the session = ID requirement for a transaction not so bound.

-        = Fo= r each of these requirements we need to cover the existence over time, = and the existence over space.

-        = Th= e existence over space requirement is identical for both, i.e. that UA = A, UAB, and all the entities inbetween will be able to see the same = session ID, such that some other entity trying to correlate information = feeds from these entities will be able to do so.

-        = Th= e existence over time requirement only applies to REQ 1, i.e. that all = transactions within the same dialog should share the same session ID. I = do not believe there is a requirement for session ID within the = transaction, i.e. between request and response – that is dealt = with by other mechanisms. We have no requirement for correlation between = two transactions that are not within a dialog.

 

Wh= ile it would be possible to draft this round the existing requirement = split, I suggest maybe we just do the split round the time and space = division. So the new revised requirements might look like (in place of = the existing).

 

RE= Q 1B: It must be possible for the same identifier to appear at all = entities participating in a SIP transaction, such that an external = device that monitors the SIP traffic can use that identifier to = correlate the same transaction at each of those = entities.

 

RE= Q 1C: It must be possible for the same identifier to appear in all = transactions that form part of a SIP dialog, such that the transactions = that form part of the dialog can be correlated together. There is no = requirement for the identifier to correlate parts of a single = transaction (i.e. request and response) as existing SIP mechanisms are = assumed to do that. There is no requirement for the identifier to = correlate two transactions that do not form part of the same dialog = (e.g. an OPTIONS transaction and a subsequent INVITE transaction, or a = MESSAGE transaction and a subsequent MESSAGE transaction), except as = expressed in other requirements.

 

No= te the “except” in REQ 1C above is to allow the transfer = requirements in REQ2.

 

If= the new REQ 1B is acceptable, then we should also consider how distinct = that is from REQ 4.

 

Ke= ith

 

From:= = insipid-bounces@ietf.org = [mailto:insipid-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: 11 July = 2012 13:10
To: Laura Liess
Cc: insipid@ietf.org
Subject: = Re: [Insipid] Text proposal for the "SIP traffic monitoring" = use case

 

What shall be the = wording of REQ1a?

Paul

From:= Laura = Liess <laura.liess.dt@googlemail.c= om>
Sent: Wed Jul 11 03:14:07 EDT 2012
To: = "Paul E. Jones" <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: = Re: [Insipid] Text proposal for the "SIP traffic monitoring" = use case

 

Paul,
 
After the discussion =
yesterday in the Webex meeting, it seems to =
me
that separate requirements for dialogs and transactions are =
needed.
 
Thanks
Laura
 
2012/7/11 Paul E. =
Jones <paulej@packetizer.com>:=

> Indeed, you're right.  It does cover both, but =
folks called for a separate
> =
requirement.
> 
> What is the =
wishes of the WG on this?  Shall I replace REQ1 with the =
below
> text?
 
 
> 
> =
Paul
> 
>> -----Original =
Message-----
>> From: insipid-bounces@ietf.org [mailto:insipid-bounces=
@ietf.org] On Behalf
>> Of Laura =
Liess
>> Sent: Tuesday, July 10, 2012 8:23 =
AM
>> To: Paul E. Jones
>> Cc: insipid@ietf.org
>> =
Subject: Re: [Insipid] Text proposal for the "SIP traffic =
monitoring" use
>> =
case
>> 
>> =
Paul,
>> 
>> =
>
>> > What was proposed (by you?) was =
this:
>> >
>> > REQ1a: =
It must be possible for an administrator or an external =
device
>> > which monitors the SIP-traffic to use the =
identifier to identify those
>> > dialogs, =
transactions and messages which were at some point in =
time
>> > components of a single end-to-end SIP session =
(e.g., parts of the same
>> =
call).
>> 
>> [LL] The =
proposed text of the REQ1a (above) also covers the REQ1 (as it =
is
>> in draft-ietf-insipid-session-id-reqts-00). So I =
think we could replace
>> the current =
text of REQ1 by the proposed text of the REQ1a and then =
drop
>> REQ1a.
>> 
>> =
Thanks
>> Laura
>> 
>> 
>> 
>> 
>> =
>
>> > This =
is not presently in t!
 =
he draft
that we just submitted =
to be a WG
>> > document =
since I was told to base that document on the -03 draft.  =
I
>> > had that text in my pending -04 draft, but =
... it is still sitting
>> > there =
:-)
>> >
>> >> > =
You really want to just remove that text from =
c)?
>> >> [LL]  No. I =
don't.
>> >> Also in this scenario the service =
providers monitors and logs all
>> >> =
B2BUA traffic, incomming and outgoing.  There is no log provided =
by
>> >> the customer.
>> =
>>
>> >> From =
my point of view, the text would be :
>> =
>>
>> =
>>
 
 
 
 
 
 
 
 
 
>> >> User =
Agent A (A) and User Agent B (B) communicate using SIP =
messaging
>> >> with =
a SIP B2BUA acting as a middlebox which belongs to a SIP =
service
>> provider.
>> >> For privacy reasons, =
t!
 he =
B2BUA
changes the SIP headers that =
reveal
>> >> information related to the SIP users, =
device or domain identity. The
>> >> =
service provider uses an external device to monitor and log all =
SIP
>> >> traffic coming to and from the =
B2BUA.  In the case of failures
>> >> =
reported by the customer or when security issue arise (e.g. theft =
of
>> >> service), the service provider has to =
analyze the logs from the past
>> >> =
several days or weeks and correlates those messages which =
were
>> >> messages for a single end- to-end SIP =
session.
>> =
>>
>> >> For =
this scenario, we must consider three particular use =
cases:
>> >>
>> >> a) =
The UAs  A and B support the end-to-end Session =
Identifier.
>> =
>>
>> >> =
Derived Requirements: REQ1, REQ1a, REQ4, REQ5, =
REQ8.
>> >>
>> >> b) =
Only the UA A supports the end-to-end Session Identifier, the UA =
B
>> >> does not.
>> =
>>
>> >> =
Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, =
REQ8.
>> >>
>> >> c) =
UA A and UA  B do not support the end-to-end Session =
Identifier.
>> =
>>
>> >> =
Derived Requirements: REQ1, REQ1a, REQ4, REQ5, REQ7, =
REQ8.
>> >> =
-----------------
>> =
>>
>> =
>>
>> >> What =
do you think?
>> =
>
>> >
>> > Sounds =
OK to me.  I'll put this into me -04 draft and when folks =
give
>> > me the green light, move it into the WG -01 =
draft.
>> >
>> > =
Paul
>> >
>> =
>
>> 
 
 
 
 
 
 
 
 
 
>> insipid =
mailing list
>> insipid@ietf.org
>> https://www.ietf.o=
rg/mailman/listinfo/insipid
> 
------=_NextPart_000_00A9_01CD6A52.FAB411E0-- From pkyzivat@alum.mit.edu Thu Jul 26 08:00:01 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2D221F8550 for ; Thu, 26 Jul 2012 08:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 azIf8eJVQwwp for ; Thu, 26 Jul 2012 08:00:00 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7137421F8530 for ; Thu, 26 Jul 2012 08:00:00 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta05.westchester.pa.mail.comcast.net with comcast id f2Q01j0050vyq2s55303Zg; Thu, 26 Jul 2012 15:00:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id f3091j0063ZTu2S3R309TT; Thu, 26 Jul 2012 15:00:09 +0000 Message-ID: <50115B6F.8070803@alum.mit.edu> Date: Thu, 26 Jul 2012 10:59:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> In-Reply-To: <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 26 Jul 2012 15:00:01 -0000 On 7/24/12 10:51 PM, Paul E. Jones wrote: > Paul, > > Following up on this thread, as I did not see an outcome. I think this > message might be the last in the series on this topic. > > I think your proposal is along the lines of what we originally proposed. As > I understand, there is a desire to always include both A and B's halves. > That's fine, so long as devices understand they might change from one > message to the next. > > So given these two abbreviated UUIDs: > > UUID 1: 0xaeffa652 > UUID 2: 0xbe11afc8 > > We would have: > > Session-ID: 0xaeffa652be11afc8 > > If we agree to encode it in hex and agree on the size (a 16 octet UUID), > that means this will always be a 64-byte hex string and there is no need to > put a :. We could also base64 encode the 64 octet binary value, which would > encode in 44 octets (shaving off 20 octets). Do we want to go for reduced > size or more readable hex string? I don't have a strong feeling about hex vs. base64. But I think it would be good to have a separator (I'm not attached to ":" - that is just an example.) I realize it isn't logically necessary as long as the halves are fixed length. But its not very friendly, and I think it is worth "wasting" *1* byte on. If we go with base64, I agree that we don't need to preserve the trailing "==". > As for putting the entire Session-ID into messages, there are many > situations where the Session-ID will be wrong. Let me give you just one > example. > > Syntax: > A == B means A is in a call with B > > A == B&& A == C (A in call with B; A has a separate call with C.) > > && B == D (B has a separate call with D) > > A& B are talking. A puts B on hold. > A starts talking to C. > Meanwhile B puts A on hold and talks to D. > > A performs some action to join B and C, while at the same time > B performs some action to join D and C > > Assuming a PBX does this magic, we might have some INVITE messages going > down the wire like this: > > + INVITE ----> C (so C can talk to B) (Session-ID: B || C) > PBX1 ---| > + INVITE ----> B (so B can talk to C) (Session-ID: B || C) > > And we have > > + INVITE ----> A (so A can talk to D) (Session-ID: A || D) > PBX2 ---| > + INVITE ----> D (so D can talk to A) (Session-ID: A || D) I can't fully follow the above. My problem is that I don't know where PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to speculate much. > Now, these messages are passing on the wire at the same time. So that > message from PBX1 heading toward B is actually now heading toward D. ??? > So, what D receives is Session-ID "B || C". D thought the Session-ID was A > || D. It will be confused. Perhaps PBX2 can massage the Session-ID, but > it's not supposed to do that. We really don't want intermediaries to touch > it. Can you please map out the full topology, and a lot more of the call flow you have in mind. (Including REFERs, or some other indication of how the PBXs are being instructed what to do.) (There are a million ways this could be done.) > To avoid these kinds of race conditions, adding complexity to try to > straighten it out, etc., I very much prefer to have only the Session-ID-UUID > header that contains only the UUID of the sender of the message. If we did > that, the endpoints in the above scenario would not be confused and the > correct Session-ID could be noted in logs. I'm not ready to leap to this conclusion until I understand the cases better. Thanks, Paul K > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, July 11, 2012 7:38 PM >> To: James Polk >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Session-ID construction choices >> >> On 7/11/12 6:23 PM, James Polk wrote: >> ... >>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >> ... >>>>> We have a proposal going forward: insert the From:/To: tags from >>>>> Option #1. >>>>> >>>>> Does anyone have a technical reason why this wouldn't work? >>>> >>>> Do you mean to assign From and To once, and then keep it fixed for >>>> the duration of the dialog? ISTM that From and To are not well >>>> defined in all cases. >>>> >>>> For instance, consider a BTBUA that sets up a session by inviting >>>> both endpoints. Which is From and which is To? IIUC, the reason for >>>> labeling this way is so that someone observing a session id in a >>>> message can tell which half corresponds to which end. Using From and >>>> To won't satisfy that unless those tags are reassigned for each >> request. >>>> (This is a special case of a conference focus, which you already call >>>> out as an exception.) >>> >>> The desire is to have the same half in the same position throughout >>> the transaction or dialog (whichever it is). I believe in the case of >>> a B2BUA initiating or originating the transaction or dialog on behalf >>> of other endpoint UAs, the B2BUA would pick which Session-ID is the >>> From and which is the To. IOW - we don't make it a requirement on an >>> implementation that Alice is always inserting her half in first, and >>> Bob in as the second half. If the B2BUA is sending an INVITE to both >>> Alice and Bob, then that's 2 separate Session-IDs because it's two >>> different dialogs, even if a 3rd party isn't part (i.e., listening) of >>> the media flow. This would be a hub and 2 spokes in which the hub >>> doesn't listen or interact with the media of the 2 UAs. >>> >>> We could also have text that says for this scenario, that an INVITE >>> normally inserts the From half of the Session-ID, but that in this >>> scenario it can insert the To: half and the invitee inserts the To half. >>> >>> >>>> Identifying which end is which is easy for any single transaction, >>> >>> agreed >>> >>>> but hard if you want to use the same identifiers in every message. >>>> The endpoints can easily figure this out, because they should know >>>> their half, and the half that isn't theirs is the other end's. But >>>> its not simple for middleboxes. >>> >>> remember that each half is a UUID or GUID, which will always be a >>> unique value through space and time. >>> >>> >>>> The solution that is used for dialog ids is to use To and From, but >>>> they must be reassigned depending on the direction of the message. We >>>> could do the same for session id, but only if they are remapped based >>>> on the direction of the request. >>> >>> I guess I'm no getting why the halves need to switch places yet >>> depending on whether it's in a request or response. Or are you saying >>> that for one complete transaction they are in a certain order, but in >>> a related transaction(s) they are possibly in the reverse order - >>> depending on who sent the message? >> >> When a message is sent in the reverse direction from the dialog >> establishing message, the From URI and To URI are reversed, as well as the >> From and To tags. If the session id still has its halves tagged consistent >> with the from and to of the dialog establishing request, then you will get >> confused about which half goes with which end. >> >> There is no problem for servers that keep state and remember the values >> for each end. For them we don't need to tag the halves at all. >> >> There is also no problem for those who don't *care* which end is which. >> And there may be a lot of those. >> >> This tagging is only there for those who don't keep state yet need to >> know. Maybe there aren't any of those, in which case we can stop worrying >> about it. >> >> I guess an example that might matter is something analyzing logs, and >> doesn't have a complete set of logs available to it - in particular it >> doesn't have a log of the initial signaling that set up the session, so it >> can't figure out which half-id belongs to which end. >> >> Then it sees a change - it sees a message where half of the id matches >> prior things, but the other half doesn't - is new. From this it can >> perhaps infer that there was a transfer. And in that case it will want to >> know which end remains and which was replaced. But it can't figure that >> out from which half of the id changed without knowing the mapping from >> half to end. >> >> But I will be the first to say that this case is somewhat implausible. >> In practice there will be lots of stuff in the messages being analyzed >> that should support figuring this out. Perhaps this just isn't a good >> example, and there is another that is better. But I don't know a better >> one. Anybody else? (I think Paul J was the one who raised this concern, so >> maybe he has an example.) >> >> If we can't find a plausible reason why we need to do this mapping, then I >> propose that we just not bother. In that case I think representation >> #3 is attractive. It provides for the easiest comparison between id values >> - a single string comparison is sufficient. And its among the most compact >> representations. I'd recommend: >> >> session-id: SmallestHalf:BiggestHalf >> >> Or just >> >> session-id: FirstHalf >> >> before the half for the far end has been assigned. >> >> Thanks, >> Paul >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > From paulej@packetizer.com Thu Jul 26 08:49:41 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8168A21F86E0 for ; Thu, 26 Jul 2012 08:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 TRnHYj7p2it2 for ; Thu, 26 Jul 2012 08:49:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 361FB21F86BD for ; Thu, 26 Jul 2012 08:49:40 -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 q6QFnbIl015017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jul 2012 11:49:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343317778; bh=FCosgSShouSMlxpajzjj1908F4Y1MRh4qqF2GijH388=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=M+a6lKKt0Zsj4GsW4UKUEQPy0TUrNc9JptjIB/5mChYh06KVtSB3h4iG8QcEV7pz2 bJ09WDrsLadNtrFvG9Ytt+Mhe0pc01quMEeEo6k6u4NkJaMVHTTPgu0DlMlHxY0++8 FYjOZcY5mnn6vHkw8hhRU76BjbaNyhgq+ZMLpamk= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> <50115B6F.8070803@alum.mit.edu> In-Reply-To: <50115B6F.8070803@alum.mit.edu> Date: Thu, 26 Jul 2012 11:49:42 -0400 Message-ID: <019e01cd6b46$46319630$d294c290$@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: AQKKeQ3ycBTDCxy0/njVbETmXsGnNQJPd8dFAk1S0scC5qHmewHQrBhpAn/GlNmVYvSw8A== Content-Language: en-us Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 26 Jul 2012 15:49:41 -0000 Paul, The topology is basically this: C --- PBX0 | | | A --- PBX1 --- PBX2 --- B | | | D A is in two separate calls, one with B and one with C. B is in two separate calls, one with A and one with D. At about the same time, A transfers the A-B call to C and B transfers the A-B call to D. There does not necessarily have to be a REFER. Ideal world, but the PBX might handle this locally. Let's just assume the PBX managing these calls sends a new INVITE, perhaps doing a delayed offer exchange to get C and D talking. So, PBX2 sends an INVITE toward A, but PBX1 directs it toward C. And, PBX1 sends an INVITE toward B, but PBX2 directs it toward D. Those invite messages would have the wrong session-ID since PBX1 assumed the ID would be B || C and PBX2 assumed the ID would be A || D. Since the endpoints now involved in the call are C and D, the Session-ID should be C || D. If REFER had been used, A would send a REFER to B (referring to C) and B would send a REFER to A (referring to D) at the same time. I'm not even sure how that race condition would be handled. Perhaps both sides would reject? Or would the outcome be that B is in a call with C and A with D? Or would both cancel the transfer? Anyway, this is one of those unusual corner cases, I admit. Still, if it might happen, we should consider it. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Thursday, July 26, 2012 11:00 AM > To: Paul E. Jones > Cc: 'James Polk'; insipid@ietf.org > Subject: Re: [Insipid] Session-ID construction choices > > On 7/24/12 10:51 PM, Paul E. Jones wrote: > > Paul, > > > > Following up on this thread, as I did not see an outcome. I think > > this message might be the last in the series on this topic. > > > > I think your proposal is along the lines of what we originally > > proposed. As I understand, there is a desire to always include both A > and B's halves. > > That's fine, so long as devices understand they might change from one > > message to the next. > > > > So given these two abbreviated UUIDs: > > > > UUID 1: 0xaeffa652 > > UUID 2: 0xbe11afc8 > > > > We would have: > > > > Session-ID: 0xaeffa652be11afc8 > > > > If we agree to encode it in hex and agree on the size (a 16 octet > > UUID), that means this will always be a 64-byte hex string and there > > is no need to put a :. We could also base64 encode the 64 octet > > binary value, which would encode in 44 octets (shaving off 20 octets). > > Do we want to go for reduced size or more readable hex string? > > I don't have a strong feeling about hex vs. base64. > But I think it would be good to have a separator (I'm not attached to ":" > - that is just an example.) I realize it isn't logically necessary as long > as the halves are fixed length. But its not very friendly, and I think it > is worth "wasting" *1* byte on. > > If we go with base64, I agree that we don't need to preserve the trailing > "==". > > > As for putting the entire Session-ID into messages, there are many > > situations where the Session-ID will be wrong. Let me give you just > > one example. > > > > Syntax: > > A == B means A is in a call with B > > > > A == B&& A == C (A in call with B; A has a separate call with C.) > > > > && B == D (B has a separate call with D) > > > > A& B are talking. A puts B on hold. > > A starts talking to C. > > Meanwhile B puts A on hold and talks to D. > > > > A performs some action to join B and C, while at the same time B > > performs some action to join D and C > > > > Assuming a PBX does this magic, we might have some INVITE messages > > going down the wire like this: > > > > + INVITE ----> C (so C can talk to B) (Session-ID: B || C) > > PBX1 ---| > > + INVITE ----> B (so B can talk to C) (Session-ID: B || C) > > > > And we have > > > > + INVITE ----> A (so A can talk to D) (Session-ID: A || D) > > PBX2 ---| > > + INVITE ----> D (so D can talk to A) (Session-ID: A || D) > > I can't fully follow the above. My problem is that I don't know where > PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to > speculate much. > > > Now, these messages are passing on the wire at the same time. So that > > message from PBX1 heading toward B is actually now heading toward D. > > ??? > > > So, what D receives is Session-ID "B || C". D thought the Session-ID > > was A > > || D. It will be confused. Perhaps PBX2 can massage the Session-ID, > > || but > > it's not supposed to do that. We really don't want intermediaries to > > touch it. > > Can you please map out the full topology, and a lot more of the call flow > you have in mind. (Including REFERs, or some other indication of how the > PBXs are being instructed what to do.) (There are a million ways this > could be done.) > > > To avoid these kinds of race conditions, adding complexity to try to > > straighten it out, etc., I very much prefer to have only the > > Session-ID-UUID header that contains only the UUID of the sender of > > the message. If we did that, the endpoints in the above scenario > > would not be confused and the correct Session-ID could be noted in logs. > > I'm not ready to leap to this conclusion until I understand the cases > better. > > Thanks, > Paul K > > > Paul > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Wednesday, July 11, 2012 7:38 PM > >> To: James Polk > >> Cc: insipid@ietf.org > >> Subject: Re: [Insipid] Session-ID construction choices > >> > >> On 7/11/12 6:23 PM, James Polk wrote: > >> ... > >>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half > >> ... > >>>>> We have a proposal going forward: insert the From:/To: tags from > >>>>> Option #1. > >>>>> > >>>>> Does anyone have a technical reason why this wouldn't work? > >>>> > >>>> Do you mean to assign From and To once, and then keep it fixed for > >>>> the duration of the dialog? ISTM that From and To are not well > >>>> defined in all cases. > >>>> > >>>> For instance, consider a BTBUA that sets up a session by inviting > >>>> both endpoints. Which is From and which is To? IIUC, the reason for > >>>> labeling this way is so that someone observing a session id in a > >>>> message can tell which half corresponds to which end. Using From > >>>> and To won't satisfy that unless those tags are reassigned for each > >> request. > >>>> (This is a special case of a conference focus, which you already > >>>> call out as an exception.) > >>> > >>> The desire is to have the same half in the same position throughout > >>> the transaction or dialog (whichever it is). I believe in the case > >>> of a B2BUA initiating or originating the transaction or dialog on > >>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID > >>> is the From and which is the To. IOW - we don't make it a > >>> requirement on an implementation that Alice is always inserting her > >>> half in first, and Bob in as the second half. If the B2BUA is > >>> sending an INVITE to both Alice and Bob, then that's 2 separate > >>> Session-IDs because it's two different dialogs, even if a 3rd party > >>> isn't part (i.e., listening) of the media flow. This would be a hub > >>> and 2 spokes in which the hub doesn't listen or interact with the > media of the 2 UAs. > >>> > >>> We could also have text that says for this scenario, that an INVITE > >>> normally inserts the From half of the Session-ID, but that in this > >>> scenario it can insert the To: half and the invitee inserts the To > half. > >>> > >>> > >>>> Identifying which end is which is easy for any single transaction, > >>> > >>> agreed > >>> > >>>> but hard if you want to use the same identifiers in every message. > >>>> The endpoints can easily figure this out, because they should know > >>>> their half, and the half that isn't theirs is the other end's. But > >>>> its not simple for middleboxes. > >>> > >>> remember that each half is a UUID or GUID, which will always be a > >>> unique value through space and time. > >>> > >>> > >>>> The solution that is used for dialog ids is to use To and From, but > >>>> they must be reassigned depending on the direction of the message. > >>>> We could do the same for session id, but only if they are remapped > >>>> based on the direction of the request. > >>> > >>> I guess I'm no getting why the halves need to switch places yet > >>> depending on whether it's in a request or response. Or are you > >>> saying that for one complete transaction they are in a certain > >>> order, but in a related transaction(s) they are possibly in the > >>> reverse order - depending on who sent the message? > >> > >> When a message is sent in the reverse direction from the dialog > >> establishing message, the From URI and To URI are reversed, as well > >> as the From and To tags. If the session id still has its halves > >> tagged consistent with the from and to of the dialog establishing > >> request, then you will get confused about which half goes with which > end. > >> > >> There is no problem for servers that keep state and remember the > >> values for each end. For them we don't need to tag the halves at all. > >> > >> There is also no problem for those who don't *care* which end is which. > >> And there may be a lot of those. > >> > >> This tagging is only there for those who don't keep state yet need to > >> know. Maybe there aren't any of those, in which case we can stop > >> worrying about it. > >> > >> I guess an example that might matter is something analyzing logs, and > >> doesn't have a complete set of logs available to it - in particular > >> it doesn't have a log of the initial signaling that set up the > >> session, so it can't figure out which half-id belongs to which end. > >> > >> Then it sees a change - it sees a message where half of the id > >> matches prior things, but the other half doesn't - is new. From this > >> it can perhaps infer that there was a transfer. And in that case it > >> will want to know which end remains and which was replaced. But it > >> can't figure that out from which half of the id changed without > >> knowing the mapping from half to end. > >> > >> But I will be the first to say that this case is somewhat implausible. > >> In practice there will be lots of stuff in the messages being > >> analyzed that should support figuring this out. Perhaps this just > >> isn't a good example, and there is another that is better. But I > >> don't know a better one. Anybody else? (I think Paul J was the one > >> who raised this concern, so maybe he has an example.) > >> > >> If we can't find a plausible reason why we need to do this mapping, > >> then I propose that we just not bother. In that case I think > >> representation > >> #3 is attractive. It provides for the easiest comparison between id > >> values > >> - a single string comparison is sufficient. And its among the most > >> compact representations. I'd recommend: > >> > >> session-id: SmallestHalf:BiggestHalf > >> > >> Or just > >> > >> session-id: FirstHalf > >> > >> before the half for the far end has been assigned. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Thu Jul 26 10:09:51 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09621F8658 for ; Thu, 26 Jul 2012 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 aMUernFIl1Ll for ; Thu, 26 Jul 2012 10:09:50 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id EB04721F861E for ; Thu, 26 Jul 2012 10:09:49 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id f2Nl1j0051c6gX85959sj7; Thu, 26 Jul 2012 17:09:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id f59f1j00F3ZTu2S3j59ftN; Thu, 26 Jul 2012 17:09:39 +0000 Message-ID: <501179DC.6050807@alum.mit.edu> Date: Thu, 26 Jul 2012 13:09:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> <50115B6F.8070803@alum.mit.edu> <019e01cd6b46$46319630$d294c290$@packetizer.com> In-Reply-To: <019e01cd6b46$46319630$d294c290$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Insipid] Session-ID construction choices 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, 26 Jul 2012 17:09:51 -0000 On 7/26/12 11:49 AM, Paul E. Jones wrote: > Paul, > > > The topology is basically this: > > > C --- PBX0 > | > | > | > A --- PBX1 --- PBX2 --- B > | > | > | > D OK. That is helpful. > A is in two separate calls, one with B and one with C. > B is in two separate calls, one with A and one with D. > > At about the same time, A transfers the A-B call to C and B transfers the > A-B call to D. > > There does not necessarily have to be a REFER. Ideal world, but the PBX > might handle this locally. Let's just assume the PBX managing these calls > sends a new INVITE, perhaps doing a delayed offer exchange to get C and D > talking. The following is still too scant for me to follow. I'll fill in some questions. But basically I'd like to see a call flow for the whole thing. > So, PBX2 sends an INVITE toward A, but PBX1 directs it toward C. I suppose you mean that PBX2 is acting on B's desire to connect A to D? And its sending the request within the PBX1:PBX2 dialog of the A:PBX1:PBX2:B session. > And, PBX1 sends an INVITE toward B, but PBX2 directs it toward D. And similarly this is PBX1 acting on A's desire to connect B to C, sending the request, also within the PBX1:PBX2 dialog of the A:PBX1:PBX2:B session. > Those invite messages would have the wrong session-ID since PBX1 assumed the > ID would be B || C and PBX2 assumed the ID would be A || D. You are making a bunch of assumptions here. Why would the session id be changed this early in the process? It isn't yet known if this will work. In reality, these two INVITEs should end up failing due to glare. After the backoff the situation will be clearer. But this depends on the details of the call flow, which is why I want to see the detailed call flow before reaching specific conclusions. > Since the > endpoints now involved in the call are C and D, the Session-ID should be C > || D. > > If REFER had been used, A would send a REFER to B (referring to C) and B > would send a REFER to A (referring to D) at the same time. I'm not even > sure how that race condition would be handled. I think in many cases the transfer will be initiated via REFER (because it's one of the endpoints that knows it wants the transfer, and the REFER is the standard way to act on that.) But then the REFER would be intercepted by the PBX, which then finishes it using reINVITEs because it isn't confident that the other end supports REFER. OTOH, REFER has been around for a long time now, so it's not unreasonable to let it pass. Both scenarios are worth exploring. > Perhaps both sides would > reject? The REFER would include a Replaces param on the resulting INVITE. That would identify the specific dialog being replaced. In the presence of B2BUAs you then must make some assumptions that they will update the dialog id in the Replaces if they forward the REFER. But that still leaves a lot of variables. > Or would the outcome be that B is in a call with C and A with D? Or > would both cancel the transfer? > > Anyway, this is one of those unusual corner cases, I admit. Still, if it > might happen, we should consider it. Yes, I think so. But I see no alternative to working out the entire call flow. And there will be multiple call flows that could work. We can't consider them all, but we should explore the popular alternatives. Thanks, Paul > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Thursday, July 26, 2012 11:00 AM >> To: Paul E. Jones >> Cc: 'James Polk'; insipid@ietf.org >> Subject: Re: [Insipid] Session-ID construction choices >> >> On 7/24/12 10:51 PM, Paul E. Jones wrote: >>> Paul, >>> >>> Following up on this thread, as I did not see an outcome. I think >>> this message might be the last in the series on this topic. >>> >>> I think your proposal is along the lines of what we originally >>> proposed. As I understand, there is a desire to always include both A >> and B's halves. >>> That's fine, so long as devices understand they might change from one >>> message to the next. >>> >>> So given these two abbreviated UUIDs: >>> >>> UUID 1: 0xaeffa652 >>> UUID 2: 0xbe11afc8 >>> >>> We would have: >>> >>> Session-ID: 0xaeffa652be11afc8 >>> >>> If we agree to encode it in hex and agree on the size (a 16 octet >>> UUID), that means this will always be a 64-byte hex string and there >>> is no need to put a :. We could also base64 encode the 64 octet >>> binary value, which would encode in 44 octets (shaving off 20 octets). >>> Do we want to go for reduced size or more readable hex string? >> >> I don't have a strong feeling about hex vs. base64. >> But I think it would be good to have a separator (I'm not attached to ":" >> - that is just an example.) I realize it isn't logically necessary as long >> as the halves are fixed length. But its not very friendly, and I think it >> is worth "wasting" *1* byte on. >> >> If we go with base64, I agree that we don't need to preserve the trailing >> "==". >> >>> As for putting the entire Session-ID into messages, there are many >>> situations where the Session-ID will be wrong. Let me give you just >>> one example. >>> >>> Syntax: >>> A == B means A is in a call with B >>> >>> A == B&& A == C (A in call with B; A has a separate call with C.) >>> >>> && B == D (B has a separate call with D) >>> >>> A& B are talking. A puts B on hold. >>> A starts talking to C. >>> Meanwhile B puts A on hold and talks to D. >>> >>> A performs some action to join B and C, while at the same time B >>> performs some action to join D and C >>> >>> Assuming a PBX does this magic, we might have some INVITE messages >>> going down the wire like this: >>> >>> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>> PBX1 ---| >>> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>> >>> And we have >>> >>> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>> PBX2 ---| >>> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >> >> I can't fully follow the above. My problem is that I don't know where >> PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >> speculate much. >> >>> Now, these messages are passing on the wire at the same time. So that >>> message from PBX1 heading toward B is actually now heading toward D. >> >> ??? >> >>> So, what D receives is Session-ID "B || C". D thought the Session-ID >>> was A >>> || D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>> || but >>> it's not supposed to do that. We really don't want intermediaries to >>> touch it. >> >> Can you please map out the full topology, and a lot more of the call flow >> you have in mind. (Including REFERs, or some other indication of how the >> PBXs are being instructed what to do.) (There are a million ways this >> could be done.) >> >>> To avoid these kinds of race conditions, adding complexity to try to >>> straighten it out, etc., I very much prefer to have only the >>> Session-ID-UUID header that contains only the UUID of the sender of >>> the message. If we did that, the endpoints in the above scenario >>> would not be confused and the correct Session-ID could be noted in logs. >> >> I'm not ready to leap to this conclusion until I understand the cases >> better. >> >> Thanks, >> Paul K >> >>> Paul >>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Wednesday, July 11, 2012 7:38 PM >>>> To: James Polk >>>> Cc: insipid@ietf.org >>>> Subject: Re: [Insipid] Session-ID construction choices >>>> >>>> On 7/11/12 6:23 PM, James Polk wrote: >>>> ... >>>>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >>>> ... >>>>>>> We have a proposal going forward: insert the From:/To: tags from >>>>>>> Option #1. >>>>>>> >>>>>>> Does anyone have a technical reason why this wouldn't work? >>>>>> >>>>>> Do you mean to assign From and To once, and then keep it fixed for >>>>>> the duration of the dialog? ISTM that From and To are not well >>>>>> defined in all cases. >>>>>> >>>>>> For instance, consider a BTBUA that sets up a session by inviting >>>>>> both endpoints. Which is From and which is To? IIUC, the reason for >>>>>> labeling this way is so that someone observing a session id in a >>>>>> message can tell which half corresponds to which end. Using From >>>>>> and To won't satisfy that unless those tags are reassigned for each >>>> request. >>>>>> (This is a special case of a conference focus, which you already >>>>>> call out as an exception.) >>>>> >>>>> The desire is to have the same half in the same position throughout >>>>> the transaction or dialog (whichever it is). I believe in the case >>>>> of a B2BUA initiating or originating the transaction or dialog on >>>>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID >>>>> is the From and which is the To. IOW - we don't make it a >>>>> requirement on an implementation that Alice is always inserting her >>>>> half in first, and Bob in as the second half. If the B2BUA is >>>>> sending an INVITE to both Alice and Bob, then that's 2 separate >>>>> Session-IDs because it's two different dialogs, even if a 3rd party >>>>> isn't part (i.e., listening) of the media flow. This would be a hub >>>>> and 2 spokes in which the hub doesn't listen or interact with the >> media of the 2 UAs. >>>>> >>>>> We could also have text that says for this scenario, that an INVITE >>>>> normally inserts the From half of the Session-ID, but that in this >>>>> scenario it can insert the To: half and the invitee inserts the To >> half. >>>>> >>>>> >>>>>> Identifying which end is which is easy for any single transaction, >>>>> >>>>> agreed >>>>> >>>>>> but hard if you want to use the same identifiers in every message. >>>>>> The endpoints can easily figure this out, because they should know >>>>>> their half, and the half that isn't theirs is the other end's. But >>>>>> its not simple for middleboxes. >>>>> >>>>> remember that each half is a UUID or GUID, which will always be a >>>>> unique value through space and time. >>>>> >>>>> >>>>>> The solution that is used for dialog ids is to use To and From, but >>>>>> they must be reassigned depending on the direction of the message. >>>>>> We could do the same for session id, but only if they are remapped >>>>>> based on the direction of the request. >>>>> >>>>> I guess I'm no getting why the halves need to switch places yet >>>>> depending on whether it's in a request or response. Or are you >>>>> saying that for one complete transaction they are in a certain >>>>> order, but in a related transaction(s) they are possibly in the >>>>> reverse order - depending on who sent the message? >>>> >>>> When a message is sent in the reverse direction from the dialog >>>> establishing message, the From URI and To URI are reversed, as well >>>> as the From and To tags. If the session id still has its halves >>>> tagged consistent with the from and to of the dialog establishing >>>> request, then you will get confused about which half goes with which >> end. >>>> >>>> There is no problem for servers that keep state and remember the >>>> values for each end. For them we don't need to tag the halves at all. >>>> >>>> There is also no problem for those who don't *care* which end is which. >>>> And there may be a lot of those. >>>> >>>> This tagging is only there for those who don't keep state yet need to >>>> know. Maybe there aren't any of those, in which case we can stop >>>> worrying about it. >>>> >>>> I guess an example that might matter is something analyzing logs, and >>>> doesn't have a complete set of logs available to it - in particular >>>> it doesn't have a log of the initial signaling that set up the >>>> session, so it can't figure out which half-id belongs to which end. >>>> >>>> Then it sees a change - it sees a message where half of the id >>>> matches prior things, but the other half doesn't - is new. From this >>>> it can perhaps infer that there was a transfer. And in that case it >>>> will want to know which end remains and which was replaced. But it >>>> can't figure that out from which half of the id changed without >>>> knowing the mapping from half to end. >>>> >>>> But I will be the first to say that this case is somewhat implausible. >>>> In practice there will be lots of stuff in the messages being >>>> analyzed that should support figuring this out. Perhaps this just >>>> isn't a good example, and there is another that is better. But I >>>> don't know a better one. Anybody else? (I think Paul J was the one >>>> who raised this concern, so maybe he has an example.) >>>> >>>> If we can't find a plausible reason why we need to do this mapping, >>>> then I propose that we just not bother. In that case I think >>>> representation >>>> #3 is attractive. It provides for the easiest comparison between id >>>> values >>>> - a single string comparison is sufficient. And its among the most >>>> compact representations. I'd recommend: >>>> >>>> session-id: SmallestHalf:BiggestHalf >>>> >>>> Or just >>>> >>>> session-id: FirstHalf >>>> >>>> before the half for the far end has been assigned. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> insipid mailing list >>>> insipid@ietf.org >>>> https://www.ietf.org/mailman/listinfo/insipid >>> >>> >> >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From paulej@packetizer.com Thu Jul 26 11:42:58 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A321F8587 for ; Thu, 26 Jul 2012 11:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 mL8SpJ9JoUYM for ; Thu, 26 Jul 2012 11:42:57 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AAD2221F8585 for ; Thu, 26 Jul 2012 11:42:57 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6QIgtN2021446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jul 2012 14:42:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343328176; bh=5uj/F4KBIKW4MrwNGX6QAjiaWywUnm47r0g3zBbf39M=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DL02ealzThKxdU/14/Lk4Pny+LQZ9uuBgZ6N2l/R3ClUuVzihNj0wQd4Vc7wZxcAJ +/ptPmuKKCzlVPw2C4Mjj7zr1cVS8xJZV8YoYqsjxYwBONa2CTxz7PAAGwuT33OG4r GCw+e8I/qgXq8R+71RXfLB+Y30GinG8oFOxc3q2g= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> <50115B6F.8070803@alum.mit.edu> <019e01cd6b46$46319630$d294c290$@packetizer.com> <501179DC.6050807@alum.mit.edu> In-Reply-To: <501179DC.6050807@alum.mit.edu> Date: Thu, 26 Jul 2012 14:43:00 -0400 Message-ID: <01d301cd6b5e$7c056a80$74103f80$@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: AQKKeQ3ycBTDCxy0/njVbETmXsGnNQJPd8dFAk1S0scC5qHmewHQrBhpAn/GlNkCXD3rGQEp6KCBlUbnecA= Content-Language: en-us Subject: Re: [Insipid] Session-ID construction choices 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, 26 Jul 2012 18:42:58 -0000 Paul, > > > > The topology is basically this: > > > > > > C --- PBX0 > > | > > | > > | > > A --- PBX1 --- PBX2 --- B > > | > > | > > | > > D > > OK. That is helpful. > > > A is in two separate calls, one with B and one with C. > > B is in two separate calls, one with A and one with D. > > > > At about the same time, A transfers the A-B call to C and B transfers > > the A-B call to D. > > > > There does not necessarily have to be a REFER. Ideal world, but the > > PBX might handle this locally. Let's just assume the PBX managing > > these calls sends a new INVITE, perhaps doing a delayed offer exchange > > to get C and D talking. > > The following is still too scant for me to follow. I'll fill in some > questions. But basically I'd like to see a call flow for the whole thing. > > > So, PBX2 sends an INVITE toward A, but PBX1 directs it toward C. > > I suppose you mean that PBX2 is acting on B's desire to connect A to D? > And its sending the request within the PBX1:PBX2 dialog of the > A:PBX1:PBX2:B session. Right. PBX2 might formulate an INVITE that perhaps tries to put A on hold. It might also put D on hold at the same time, as it prepares to join these calls. > > And, PBX1 sends an INVITE toward B, but PBX2 directs it toward D. > > And similarly this is PBX1 acting on A's desire to connect B to C, sending > the request, also within the PBX1:PBX2 dialog of the A:PBX1:PBX2:B > session. Right. > > Those invite messages would have the wrong session-ID since PBX1 > > assumed the ID would be B || C and PBX2 assumed the ID would be A || D. > > You are making a bunch of assumptions here. > Why would the session id be changed this early in the process? It isn't > yet known if this will work. Let's assume the call hold is accepted. Now PBX2 wants to take the call off hold and switch the call to D. We presently have this topology: C --- PBX0 | | | PBX1 --- PBX2 | | | D So, as far as the PBXes are concerned, A and B are gone. However, the opposite PBX is unaware of that. PBX2 intends to send an INVITE to 'A' (which is gone) with D's SDP, perhaps. In any case, it wants to take 'A' and 'D' off hold and get them communicating. > In reality, these two INVITEs should end up failing due to glare. After > the backoff the situation will be clearer. Using the call hold scenario, both devices are on hold, but the transition is made as far as the PBX is concerned. So, the next INVITE that comes from PBX2 will have an INVITE contains A || D. PBX1 could forward that to C to take C off hold, but the problem is the Session-ID is wrong. This forces PBX1 to manipulate the Session-ID. > But this depends on the details of the call flow, which is why I want to > see the detailed call flow before reaching specific conclusions. You're right. Sometimes we might get into glare conditions, but I think the flow could be constructed to avoid that situation. It occurs when both PBXes switch endpoints locally and do it without the more verbose call transfer signaling. And, generally one would not want to send a REFER from PBX1 to PBX2. It gets into all of the nasty "who pays the bill" problem. > > Since the > > endpoints now involved in the call are C and D, the Session-ID should > > be C > > || D. > > > > If REFER had been used, A would send a REFER to B (referring to C) and > > B would send a REFER to A (referring to D) at the same time. I'm not > > even sure how that race condition would be handled. > > I think in many cases the transfer will be initiated via REFER (because > it's one of the endpoints that knows it wants the transfer, and the REFER > is the standard way to act on that.) But then the REFER would be > intercepted by the PBX, which then finishes it using reINVITEs because it > isn't confident that the other end supports REFER. > > OTOH, REFER has been around for a long time now, so it's not unreasonable > to let it pass. Both scenarios are worth exploring. I've not given a lot of thought to what issues we might encounter using REFER. I assume that would present less problems, as it might force one side to fail to transfer. So long as we do not allow a race condition to occur, we will not have it. I've been focused on the case where the PBX just performs a transfer locally (i.e., no REFER). > > Perhaps both sides would > > reject? > > The REFER would include a Replaces param on the resulting INVITE. That > would identify the specific dialog being replaced. > > In the presence of B2BUAs you then must make some assumptions that they > will update the dialog id in the Replaces if they forward the REFER. But > that still leaves a lot of variables. > > > Or would the outcome be that B is in a call with C and A with D? Or > > would both cancel the transfer? > > > > Anyway, this is one of those unusual corner cases, I admit. Still, if > > it might happen, we should consider it. > > Yes, I think so. But I see no alternative to working out the entire call > flow. And there will be multiple call flows that could work. We can't > consider them all, but we should explore the popular alternatives. But this gets back to my original point on this part: if an endpoint only send the sender's UUID (not the whole Session-ID), then we avoid this problem. The endpoint always knows the Session-ID is its UUID and the remote UUID. The remote UUID might change at any time and it could record this fact. Intermediaries that care can also not such changes during mid-call. Paul From paulej@packetizer.com Thu Jul 26 11:52:04 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9191421F8594 for ; Thu, 26 Jul 2012 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 JdNUUKAutLR3 for ; Thu, 26 Jul 2012 11:52:03 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8C06C21F8503 for ; Thu, 26 Jul 2012 11:51:58 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6QIpt2G021730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jul 2012 14:51:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343328716; bh=q6Pz1myKrP3htVHI8diozj1i1JTQtREthz60dDseQOA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=kZijw9ccLQaCMEGY4EG7yCvSyJnkDx2fz/+0sivIprJJM9u5D7doOSwA7T4cpy18h vJ5qRbXqcfxBo+SdBaqSWWw/dwxTLdkM881X8XeQ79gkU6WlW+hLZ3XTeFy2JpXXl0 TnSM1HcjOTrf9mrauA74JnNXxbAM1HW+xDAWC5AU= From: "Paul E. Jones" To: "'Paul Kyzivat'" , "'James Polk'" References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> In-Reply-To: <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> Date: Thu, 26 Jul 2012 14:52:01 -0400 Message-ID: <01d501cd6b5f$be3cc050$3ab640f0$@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: AQKKeQ3ycBTDCxy0/njVbETmXsGnNQJPd8dFAk1S0scC5qHmewHQrBhplXcqcvA= Content-Language: en-us Cc: insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 26 Jul 2012 18:52:04 -0000 Paul, Let me come back to just this part of the dialog. If we do decide to signal both UUIDs, perhaps rather than order them as "smaller:larger", how about we insert them as "Sender:recipient"? If we always have the sender place his UUID into the "Session-ID:" field first, then if the second value (recipient) does not match the recipient, it could ignore that. It would see that the first value is different and assume that some kind of mid-call change happened. When the receiving endpoint responds, it would send over the correct pair of values. So, while the INVITE might have D:A (as in my other example), the reply would contain C:D. The reply would be right. When logging session IDs, we should order them low/high so we can search on one value. Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf > Of Paul E. Jones > Sent: Tuesday, July 24, 2012 10:52 PM > To: 'Paul Kyzivat'; 'James Polk' > Cc: insipid@ietf.org > Subject: Re: [Insipid] Session-ID construction choices > > Paul, > > Following up on this thread, as I did not see an outcome. I think this > message might be the last in the series on this topic. > > I think your proposal is along the lines of what we originally proposed. > As I understand, there is a desire to always include both A and B's > halves. > That's fine, so long as devices understand they might change from one > message to the next. > > So given these two abbreviated UUIDs: > > UUID 1: 0xaeffa652 > UUID 2: 0xbe11afc8 > > We would have: > > Session-ID: 0xaeffa652be11afc8 From pkyzivat@alum.mit.edu Thu Jul 26 12:07:41 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E52411E8098 for ; Thu, 26 Jul 2012 12:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-0.805, 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 CE5N9Hfd9edA for ; Thu, 26 Jul 2012 12:07:40 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD321F8620 for ; Thu, 26 Jul 2012 12:07:38 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta02.westchester.pa.mail.comcast.net with comcast id eyeT1j0011HzFnQ5177hzd; Thu, 26 Jul 2012 19:07:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id f77g1j0063ZTu2S3a77gQV; Thu, 26 Jul 2012 19:07:40 +0000 Message-ID: <50119579.6080809@alum.mit.edu> Date: Thu, 26 Jul 2012 15:07:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Paul E. Jones" References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> <01d501cd6b5f$be3cc050$3ab640f0$@packetizer.com> In-Reply-To: <01d501cd6b5f$be3cc050$3ab640f0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 26 Jul 2012 19:07:41 -0000 On 7/26/12 2:52 PM, Paul E. Jones wrote: > Paul, > > Let me come back to just this part of the dialog. If we do decide to signal > both UUIDs, perhaps rather than order them as "smaller:larger", how about we > insert them as "Sender:recipient"? > > If we always have the sender place his UUID into the "Session-ID:" field > first, then if the second value (recipient) does not match the recipient, it > could ignore that. It would see that the first value is different and > assume that some kind of mid-call change happened. When the receiving > endpoint responds, it would send over the correct pair of values. So, while > the INVITE might have D:A (as in my other example), the reply would contain > C:D. The reply would be right. > > When logging session IDs, we should order them low/high so we can search on > one value. It sounds like you are trying to have your cake and eat it too. :-) By ordering the halves cannonically (e.g. smaller:larger) its easy to compare two of them for equality. But then one can't figure out which half belongs to which end. Ordering them sender:recipient makes it straightforward to figure out which half belongs to which end. But then comparisons aren't so easy. And sending sender:receiver but logging smaller:larger presents its own issues. If you are logging the messages themselves you won't want to do that. Finally, using sender:receiver means constant rearrangement. (Would you have the UAS put its own half first in responses too? Or does it just copy the header field from the request?) Either way can work. Depends on which issues people think are most important. Thanks, Paul > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf >> Of Paul E. Jones >> Sent: Tuesday, July 24, 2012 10:52 PM >> To: 'Paul Kyzivat'; 'James Polk' >> Cc: insipid@ietf.org >> Subject: Re: [Insipid] Session-ID construction choices >> >> Paul, >> >> Following up on this thread, as I did not see an outcome. I think this >> message might be the last in the series on this topic. >> >> I think your proposal is along the lines of what we originally proposed. >> As I understand, there is a desire to always include both A and B's >> halves. >> That's fine, so long as devices understand they might change from one >> message to the next. >> >> So given these two abbreviated UUIDs: >> >> UUID 1: 0xaeffa652 >> UUID 2: 0xbe11afc8 >> >> We would have: >> >> Session-ID: 0xaeffa652be11afc8 > > From paulej@packetizer.com Fri Jul 27 09:02:58 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1EE21F8704 for ; Fri, 27 Jul 2012 09:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG97iIfG5nZx for ; Fri, 27 Jul 2012 09:02:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id DE60521F8703 for ; Fri, 27 Jul 2012 09:02:57 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q6RG2npN003509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 27 Jul 2012 12:02:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1343404975; bh=Nin6Vyfm1veDJm2ymKbA3Np2tbV6eRVtEN0EhqgPXBY=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qE1yIVFwH0SoQRRC53/Q1KyPgu1zD+ng/H68XSGC3JtPRhywjac8G8veSxrMX8cdw MHqNFxtEIKeozLchfDC6tibFZqHUmBacyzg0WBs3gYKKQZWN1bV2KVrHEHlsqipZxu 3zebZRVI/P9iocaEle/VZNWBtQzULv1N80BTKRsg= From: "Paul E. Jones" To: "'Paul Kyzivat'" References: <201207111943.q6BJhYAG029194@mtv-core-2.cisco.com> <4FFDEB4B.8010306@alum.mit.edu> <201207112223.q6BMN5iP025997@mtv-core-3.cisco.com> <4FFE0E42.6060806@alum.mit.edu> <005101cd6a10$68e08ce0$3aa1a6a0$@packetizer.com> <01d501cd6b5f$be3cc050$3ab640f0$@packetizer.com> <50119579.6080809@alum.mit.edu> In-Reply-To: <50119579.6080809@alum.mit.edu> Date: Fri, 27 Jul 2012 12:02:56 -0400 Message-ID: <02d201cd6c11$4cd42db0$e67c8910$@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: AQKKeQ3ycBTDCxy0/njVbETmXsGnNQJPd8dFAk1S0scC5qHmewHQrBhpAuTeB8MCZbHthJVOLOVw Content-Language: en-us Cc: 'James Polk' , insipid@ietf.org Subject: Re: [Insipid] Session-ID construction choices 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, 27 Jul 2012 16:02:58 -0000 Paul, > On 7/26/12 2:52 PM, Paul E. Jones wrote: > > Paul, > > > > Let me come back to just this part of the dialog. If we do decide to > > signal both UUIDs, perhaps rather than order them as "smaller:larger", > > how about we insert them as "Sender:recipient"? > > > > If we always have the sender place his UUID into the "Session-ID:" > > field first, then if the second value (recipient) does not match the > > recipient, it could ignore that. It would see that the first value is > > different and assume that some kind of mid-call change happened. When > > the receiving endpoint responds, it would send over the correct pair > > of values. So, while the INVITE might have D:A (as in my other > > example), the reply would contain C:D. The reply would be right. > > > > When logging session IDs, we should order them low/high so we can > > search on one value. > > It sounds like you are trying to have your cake and eat it too. :-) What's the point of having a cake if you can't eat it? > By ordering the halves cannonically (e.g. smaller:larger) its easy to > compare two of them for equality. But then one can't figure out which half > belongs to which end. Right. > Ordering them sender:recipient makes it straightforward to figure out > which half belongs to which end. But then comparisons aren't so easy. Also right. > And sending sender:receiver but logging smaller:larger presents its own > issues. If you are logging the messages themselves you won't want to do > that. What issues? > Finally, using sender:receiver means constant rearrangement. (Would you > have the UAS put its own half first in responses too? Or does it just copy > the header field from the request?) The sender of the SIP message would place its UUID first. So, if Alice calls Bob, the Session-ID header would be: Session-ID: A (Alice does not know Bob's UUID, so it is absent.) And the 200 OK from Bob would be: Session-ID: B:A If Alice later sends a re-INVITE, then the Session-ID would be: Session-ID: A:B We could use "Session-ID-UUID" as the header to make it clear that the fields are the UUIDs, not the actual Session-ID. The Session-ID should always be ordered UUIDs, IMO. We might also want to prescribe what Alice would do if Alice received: Session-ID: B:D What happened here is some kind of transfer/join took place the message being directed toward Alice was originally targeted to Bob. Alice should log "A:B" (or the ordered pair) and send "A:B" back in any response. This allows Bob to also see that "D" is replaced with "A". It does bug me a little that messages contain A:B one way and B:A the other way. But, only a little. These are two independent halves and the procedures should be clear. > Either way can work. Depends on which issues people think are most > important. Yeah, I have no strong preference, so long as we avoid any possible confusion. I think ordering the SIP header with Sender:Receiver would address issues related to timing of messages. Paul From keith.drage@alcatel-lucent.com Mon Jul 30 11:09:09 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A3411E80D5 for ; Mon, 30 Jul 2012 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.789 X-Spam-Level: X-Spam-Status: No, score=-109.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hllKPZP7AQr6 for ; Mon, 30 Jul 2012 11:09:09 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1129211E809B for ; Mon, 30 Jul 2012 11:09:08 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6UI97So000313 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 30 Jul 2012 20:09:07 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 30 Jul 2012 20:09:07 +0200 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Mon, 30 Jul 2012 20:09:05 +0200 Thread-Topic: Need volunteers for the NomCom Thread-Index: Ac1ucczVR+Gp+86STmyxnCmhm8FSEwADIC7g Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [Insipid] FW: Need volunteers for the NomCom X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:09:10 -0000 (As WG cochair) Please take note and volunteer if you are eligible. Regards Keith -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behal= f Of NomCom Chair Sent: 30 July 2012 04:23 To: Working Group Chairs Subject: Need volunteers for the NomCom We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on=20 having a large pool of volunteers from throughout the IETF community.=20 In particular, it is valuable for the pool of volunteers to have strong=20 representation from all of the technical areas within the IETF.=20 I understand that not all IETF participants read the IETF announce list=20 frequently. Therefore, if you would be willing to inform active participant= s=20 in your working groups about this year's call for NomCom volunteers, I=20 would greatly appreciate it.=20 The NomCom 2012-2013 Call for Volunteers is open until this Sunday,=20 August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/= 49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org