From gsalguei@cisco.com Thu Feb 7 13:44:15 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1521F86F5 for ; Thu, 7 Feb 2013 13:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThHL0qIMIn24 for ; Thu, 7 Feb 2013 13:44:14 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7487521F86CC for ; Thu, 7 Feb 2013 13:44:14 -0800 (PST) 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 r17LiDiu005282 for ; Thu, 7 Feb 2013 16:44:13 -0500 (EST) Received: from dhcp-64-102-154-246.cisco.com (dhcp-64-102-154-246.cisco.com [64.102.154.246]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r17LiDF5013189; Thu, 7 Feb 2013 16:44:13 -0500 (EST) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Feb 2013 16:44:13 -0500 Message-Id: To: insipid@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "insipid-chairs@tools.ietf.org" Subject: [Insipid] INSIPID Session has been scheduled for IETF 86 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.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, 07 Feb 2013 21:44:15 -0000 The INSIPID session has been scheduled for IETF86 in Orlando: =20 --------------------------------------------- insipid Session 1 (2:00:00) Wednesday, Afternoon Session II 1510-1710 Room Name: Boca 1 Length of Session(s): 2 Hours Number of Attendees: 40 --------------------------------------------- Note that this is still subject to change, as swaps are going on to = resolve conflicts. RAI area tends to be fairly stable, but changes can = always occur. Additionally, while I think the chairs have a reasonably good idea of = what we think should be on the agenda, if you have specific requests, = now would be the time to send them to the chairs. Regards Gonzalo & Keith= From jmpolk@cisco.com Sun Feb 17 21:41:16 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BA421E803C for ; Sun, 17 Feb 2013 21:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVDZRpABqN76 for ; Sun, 17 Feb 2013 21:41:12 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 056EB21F89DC for ; Sun, 17 Feb 2013 21:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10850; q=dns/txt; s=iport; t=1361166072; x=1362375672; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=dqYO0MAsmVxjPcQ5+q/yNWdDdO4cwRLB0Gswu1eJruw=; b=J4G4b/6hFtHZLCm0PgU3VzCphS+sPnt037yYN8aHsRVe7tPhaTQh1rJ2 NJ6J745mxfSdZRY1tPYkCXrextsC5T+8pbCTjYUQP7l4ff6wNUXFgvcKK 9IyRIwdXFLSLU/M6JcUR/zo4U/HO8PwTLzhP8EpYNhpODfKkJuyuhZs/p g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAEu+IVGtJV2Y/2dsb2JhbABEDr8PgQOBBBZzgh8BAQEDAQEBASQRAi4GEAcEBwQOAwQBAQEJFQkHDwoOHwkIBgESCRKHcQYMvk2NcAaBNhIGgzoDiGeCdpEviXiCSF6BSgkX X-IronPort-AV: E=Sophos;i="4.84,684,1355097600"; d="scan'208";a="178165366" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 18 Feb 2013 05:41:11 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1I5fAET017558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2013 05:41:11 GMT Message-Id: <201302180541.r1I5fAET017558@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 17 Feb 2013 23:41:10 -0600 To: Paul Kyzivat , From: James Polk In-Reply-To: <50F07742.3030601@alum.mit.edu> References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> <50F07742.3030601@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Are we ready to LC on the requirements? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 05:41:16 -0000 Paul see inline At 02:34 PM 1/11/2013, Paul Kyzivat wrote: >(Sorry that this is long. I don't know how to make it short.) > >Are we ready to LC? I don't think so. Specifically I don't think we >yet have an unambiguous definition of what is being identified. > >This version added some new text: > > In this document, the word "session" refers to a "communication > session" that may exist between two SIP user agents and that may pass > through one or more intermediary devices, including B2BUAs or SIP > proxies. A communication session consists of one of more SIP > transactions. A very simple communication session may be a single > out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a > SIP dialog, the SIP message exchange includes a dialog creating > INVITE transaction, and zero of more subsequent SIP transactions > within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the > existence of middle boxes, there may be multiple related SIP > transactions or dialogs chained together along the path from one end > of the communication session to the other. For example: > > A Middlebox B > SIP trans1 -----------------> SIP trans 2 > SIP dialog 1 <-------------- SIP dialog 2 > > Figure 1 - Communication Session through a Middlebox > > In such cases, the two SIP transactions or dialogs are part of a > single communication session. > > The term "end-to-end" in this document means the communication > session from the point of origin, passing through any number of > intermediaries, to the ultimate point of termination. It is > recognized that legacy devices may not support the "end-to-end" > session identifier, though an identifier might be created by an > intermediary when it is absent from the session signaling. > >IMO this is a big improvement. I'm glad >But it still isn't as precise as I would like. grrrr... I knew there was a catch :-) >What I find lacking in the above is: > >o parsing the above, the properties of a communication session are: > - connects *two* UAs > - optionally includes one or more intermediary devices > - one or more transactions > - one out-of-dialog transaction, > OR a dialog including the dialog establishing transaction > and some transactions within the dialog. > - middle boxes may result in chaining dialogs or transactions. > > Exactly how all these properties "plug together" fuzzy. > I'm not at all certain that all readers would reach > the same conclusion about which cases meet these criteria > and which don't. that's why we have incorporating a series of amazing color pict... oh yeah... IETF docs are still limited to B&W ASCII art. ;-) >o I'm also not certain that these criteria match all the cases > people expect, and exclude all the cases people think should > be excluded. Are we talking the WG requirements doc, or our solution doc. Any WG solution doc has to cover all the requirements, but once it does that, it's not limited to only follow what the requirements doc has it in, and that's it. If there is low hanging fruit, grab it. > - I think people expect that a conference is *not* a single > communications session. But a conference with only two > participants would seem to qualify according to all of the > above criteria. So that suggests that another criterion is > needed to exclude that case. Again = are we talking the WG requirements doc, or our solution doc. > - A topologically similar case to the conference is a > click-to-dial case where a web server makes outward INVITEs > to two UAs and connects them. I think people believe this > case *should* be a communications session. that sounds to me like 3PCC, which a vocal minority of the WG definitely want excluded, at least from the reqs doc. > - Another case is described in > http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html > and debated in the replies to that. Arguments are made for > different answers to what should get a common session id and what > should not. For this case I think we need to decide: > . do we mandate exactly how this should be treated? > . or do we leave it to the discretion of the B2BUA to decide? I've described my take on that, and I included pictures (ok, a ASCII diagram) and in a nutshell, that's a B2BUA forking into a conference two different UAs on Bob's side and what does Alice see? Does she see Bob's phone as a separate dialog from that to Bob's computer? Alice only sent one INVITE, which was suggested the B2BUA went in a spliced apart the SDP (something SIP intermediaries aren't supposed to do). In my feeble mind, the B2BUA because not only dialog stateful, but media terminating (because it needs to adjust where Alice's audio and video samples go). This is conferencing my friend, and we don't have that in our reqs doc or charter. > Either way we need to decide what the criteria are that lead > to the decision. we need to get conferencing in scope of the charter. I've tried and failed. Maybe you should now try... >o IIRC Hadriel suggested (in a meeting?) that where media > originates and terminates has something to do with this. > That doesn't work all the time (e.g. MESSAGE), but it might help > in some cases. I think he used this to justify that: > > - the Conference Bridge Transcoding Model (RFC5369 section 3.2) > is a single communications session. charter says this is out of scope, and we have no requirements to do this... > - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* > a single communications session. Charter doesn't say whether this is in or out of scope (usually that means out), plus a vocal minority want it removed from the reqs doc. > (I'm not convinced - this seems like a distinction without > a difference.) > >Fundamentally we should be able to classify all cases into: >- those that *should* be communications sessions, >- those that *shouldn't* be communication sessions, >- those we don't care about - could be either way. are we going to take another year to have this exhaustive discussion, or can we have this be a short discussion that everyone can live with? I'm for the latter. >When we are done, we should be able to apply the definition of >communication session to any case. When applied to the cases we >explicitly care about it should deliver the answer we expect. ? >The more weird cases we care about, the more complex and unintuitive >the criteria will be. I suspect that the path we are on will lead to >complex criteria. (We can have a really crisp definition of >communications session if we don't care much about which cases qualify.) > >One idea I considered is to define some new terms that build on >normal sip concepts but extend them to allow B2BUA intermediaries >where sip allows proxies. E.g. >- Transaction++ is either a sip transaction, or a series of sip > transactions linked by B2BUA intermediaries. > >- Dialog++ is either a sip dialog, or a series of sip dialogs > linked by B2BUA intermediaries. > >Then would need to define the behavior of a B2BUA intermediary. ...ok, two to five years ... and maybe we can restart the Session-ID work again... Seriously though, a B2BUA is mentioned in 3261, authored 11 years ago, hundreds of folks working on defining the protocol and its entities, and you think now we need to define an entity that is in the old of a doc is realistic in the next little while? (psst, our milestones are already two months old) James >It needs to relay transactions from one "side" to the other, >preserving certain invariants (TBD). Presumably it can also >originate certain transactions, but there must be constraints on >what it can do. There must also be some rules on how media is >handled across one of these intermediaries. > >If that was done, then a communication session could be defined as a >Transaction++ for an out-of-dialog request, or a Dialog++. > >But that makes the definition of communication session the first >priority and the cases that happen to qualify as a communication >session a consequence. It probably won't match people's intuitive >feelings about what *should* be a communication session. So it might >not satisfy people. > > Thanks, > Paul > > >On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: >> From my point of view, the draft looks good. The changes >> incorporated in this updated version directly address this open issue. >> >>Cheers, >>Charles >> >>>-----Original Message----- >>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>Behalf Of Gonzalo Salgueiro (gsalguei) >>>Sent: Thursday, January 10, 2013 12:39 PM >>>To: Paul E. Jones >>>Cc: insipid@ietf.org >>>Subject: Re: [Insipid] Are we ready to LC on the requirements? >>> >>>Thanks for submitting this, Paul. The biggest open issue in regards to the >>>requirements document was to clearly define what it is we are identifying >>>(i.e., "communication session") within the scope of this document and >>>ensure that clearly defined language is used consistently throughout the >>>document. Prior to any consensus on moving to WGLC, the chairs would >>>appreciate hearing the group's thoughts on where we are on this issue in >>>the current version. >>> >>>Cheers, >>> >>>Gonzalo & Keith >>> >>> >>> >>>On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: >>> >>>>Folks, >>>> >>>>Dialog has been extremely light on the requirements document. Do >>>people feel generally OK with it as it is now? Can we move on to the >>>solution document now or are there other changes needed in the >>>requirements document? >>>> >>>>I just posted the -04 version with changes proposed on the list over the >>>past month or so. >>>> >>>>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 paulej@packetizer.com Wed Feb 20 14:52:08 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9C521E8041 for ; Wed, 20 Feb 2013 14:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBssn8WODgAt for ; Wed, 20 Feb 2013 14:52:07 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E90F021E8037 for ; Wed, 20 Feb 2013 14:52:06 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1KMq6Wk023089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 20 Feb 2013 17:52:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361400726; bh=nV+MCeEL4oOyy7jus4kiTPN5dSOeqrouTMucRZpGxm0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=lmf1cJJtquDoRaSXQpRntHiYzltba0CX9yjnjjZB7DFVnys3zy9Mv+r1DWAQhnYBB tCEXuFkK8+ujYmvKiQ5/p/ZYqYnc85TGywPt+WJWOO9eRT73K1Bu8cN05sLBwvv3fp aiZ5GBPEEmo4XRi7Iufj2PUGK0xXQrjLhCh3DQOU= From: "Paul E. Jones" To: References: <20130220214453.9775.21588.idtracker@ietfa.amsl.com> In-Reply-To: <20130220214453.9775.21588.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 17:52:13 -0500 Message-ID: <081001ce0fbc$ecca1ce0$c65e56a0$@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: AQLJUFpUvxu3jFlwlkWktdW3tJMZvJaM1uSQ Content-Language: en-us Subject: [Insipid] FW: New Version Notification for draft-jones-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:52:08 -0000 Folks, We prepared a new version of the text. You'll note errors that say = "Error! Reference source not found." I apologize for that. Word goofed = and I didn't catch it. I'll correct that when we publish the next = revision. We tried to incorporate all of the comments received during and since = the last meeting. Please read over the draft and if there is something missing or other = issues we should address in a new version before the Monday deadline, = please let us. Paul > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, February 20, 2013 4:45 PM > To: paulej@packetizer.com > Cc: jmpolk@cisco.com; chrep@cisco.com; gsalguei@cisco.com > Subject: New Version Notification for draft-jones-insipid-session-id- > 02.txt >=20 >=20 > A new version of I-D, draft-jones-insipid-session-id-02.txt > has been successfully submitted by Paul E. Jones and posted to the = IETF > repository. >=20 > Filename: draft-jones-insipid-session-id > Revision: 02 > Title: End-to-End Session Identification in IP-Based > Multimedia Communication Networks > Creation date: 2013-02-20 > Group: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-jones- > insipid-session-id-02.txt > Status: http://datatracker.ietf.org/doc/draft-jones-insipid- > session-id > Htmlized: = http://tools.ietf.org/html/draft-jones-insipid-session- > id-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-jones-insipid- > session-id-02 >=20 > Abstract: > This document describes an end-to-end Session Identifier for use in > IP-based Multimedia Communication systems that enables endpoints, > intermediate devices, and management systems to identify a session > end-to-end, associate multiple endpoints with a given multipoint > conference, track communication sessions when they are redirected, > and associate one or more media flows with a given communication > session. >=20 >=20 >=20 >=20 > The IETF Secretariat From jmpolk@cisco.com Thu Feb 21 15:14:12 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5780A21E803D for ; Thu, 21 Feb 2013 15:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzVO6Pn5OyXS for ; Thu, 21 Feb 2013 15:14:11 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6979121E8039 for ; Thu, 21 Feb 2013 15:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3792; q=dns/txt; s=iport; t=1361488451; x=1362698051; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=vuBt48dntBIsAcQN6yBn1SLrJp52PlX8BxP3G7aGO2U=; b=fePtOHXfBAdCr01ko0LNUJzHIjFH9NdBLYpHrRXyBVmIYq8Cybda7Uju ICeSuSbnSWS12POIQP4HjBIuqYJLswo0zqgNS/A5mxpicQSiMrnpPR/kX /9hIvmedHqAb8yUH8/WfaPk6opnhSnNYwOe6jAvuBgFzhs83Der5F9W9R o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcGAFaoJlGtJV2c/2dsb2JhbAA7CgGDd7VTh0eBBhZzgh8BAQEEAQEBNQIuBgkOBAcEEQQBAQEJFQkHDwoOHwgBCAYTCYgJBwW/IY1DgUASBoJZYQOIaY5qj0GBUoFU X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179830504" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 21 Feb 2013 23:14:11 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1LNEAvD021438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Feb 2013 23:14:10 GMT Message-Id: <201302212314.r1LNEAvD021438@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Feb 2013 17:14:10 -0600 To: From: James Polk In-Reply-To: <081001ce0fbc$ecca1ce0$c65e56a0$@packetizer.com> References: <20130220214453.9775.21588.idtracker@ietfa.amsl.com> <081001ce0fbc$ecca1ce0$c65e56a0$@packetizer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] FW: New Version Notification for draft-jones-insipid-session-id-02.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:14:12 -0000 INSIPID Here are the changes we've made from the -01 to -02 versions of this draft: - we changed the ABNF, including the "remote=" parameter which is always the UUID of the remote endpoint. - clarified where appropriate when a call flow starts the a communications session already exchanging RTP packets, that it was set-up with the call flow in s9.1 whcih established the Session-ID for the communications session. - clarified what purpose the reINVITEs have in each call flow that have reINVITEs. - just for Mary (just kidding), we included the flows necessary to allow Cascading Conference Bridges by using the RFC 4579 defined Contact header parameter "isfocus" to identify a communications session between MCUs meant to exchange the same UUID that a single MCU would provide. - changed in s10 (Compatibility with Previous versions) v0 and v1 to "old" and "new", because we don't have a version field in the Session-ID that would make this appropriate. - Added a comment in the Security Cons section that this spec (or the Session-ID itself) MUST NOT be used for billing, but the authors failed to capture from Atlanta why that is a problem. Any help here (from someone that has any memories of why this was desired - speak up please!) - we made minor corrections to nits Comments and questions are welcome James At 04:52 PM 2/20/2013, Paul E. Jones wrote: >Folks, > >We prepared a new version of the text. You'll note errors that say >"Error! Reference source not found." I apologize for that. Word >goofed and I didn't catch it. I'll correct that when we publish the >next revision. > >We tried to incorporate all of the comments received during and >since the last meeting. > >Please read over the draft and if there is something missing or >other issues we should address in a new version before the Monday >deadline, please let us. > >Paul > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, February 20, 2013 4:45 PM > > To: paulej@packetizer.com > > Cc: jmpolk@cisco.com; chrep@cisco.com; gsalguei@cisco.com > > Subject: New Version Notification for draft-jones-insipid-session-id- > > 02.txt > > > > > > A new version of I-D, draft-jones-insipid-session-id-02.txt > > has been successfully submitted by Paul E. Jones and posted to the IETF > > repository. > > > > Filename: draft-jones-insipid-session-id > > Revision: 02 > > Title: End-to-End Session Identification in IP-Based > > Multimedia Communication Networks > > Creation date: 2013-02-20 > > Group: Individual Submission > > Number of pages: 19 > > URL: http://www.ietf.org/internet-drafts/draft-jones- > > insipid-session-id-02.txt > > Status: http://datatracker.ietf.org/doc/draft-jones-insipid- > > session-id > > Htmlized: http://tools.ietf.org/html/draft-jones-insipid-session- > > id-02 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-jones-insipid- > > session-id-02 > > > > Abstract: > > This document describes an end-to-end Session Identifier for use in > > IP-based Multimedia Communication systems that enables endpoints, > > intermediate devices, and management systems to identify a session > > end-to-end, associate multiple endpoints with a given multipoint > > conference, track communication sessions when they are redirected, > > and associate one or more media flows with a given communication > > session. > > > > > > > > > > The IETF Secretariat > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From paulej@packetizer.com Thu Feb 21 18:51:28 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4510021F89C0 for ; Thu, 21 Feb 2013 18:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psVI3cguOGZF for ; Thu, 21 Feb 2013 18:51:27 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1346721F89B9 for ; Thu, 21 Feb 2013 18:51:26 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1M2pNYk008269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 21:51:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361501485; bh=TyLMkTacAgv5D6VrMYMcQo4TELsNfRvYYGLF2taZWeU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dtqsoeEgL2WrGeC9r2hqNG5xxXwEgFCSn9YpZvhQ0UieBcWSiEmSIzkf62DGOuzH9 /nSoh4Yk4Zrg6msls7j/oIn3t7eKggYzkv7cZb8xS7Mm2yqoWSRpNvf/VmURSQu/86 kLWvTs8tw6dEmSecS5KURYrl2PEtC4QZeZsth6NQ= From: "Paul E. Jones" To: "'Paul Kyzivat'" , References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> <50F07742.3030601@alum.mit.edu> In-Reply-To: <50F07742.3030601@alum.mit.edu> Date: Thu, 21 Feb 2013 21:51:33 -0500 Message-ID: <0a0e01ce10a7$875a0690$960e13b0$@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: AQHTUbyWWA5m3crBY/au5zDaSqMbPQHgf0hnAhmddX0CpBjqo5hFuJ2g Content-Language: en-us Subject: Re: [Insipid] Are we ready to LC on the requirements? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:51:28 -0000 Paul, I read your message, but was left unsure of exactly how we could improve the definition over what we have already. If there is something concrete that you can propose that would help lend to clarity of the text, I'm definitely willing to put it in. I would like to move the requirements along and the submission deadline is Monday. Do you have text you would like to add before the deadline? Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, January 11, 2013 3:34 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Are we ready to LC on the requirements? > > (Sorry that this is long. I don't know how to make it short.) > > Are we ready to LC? I don't think so. Specifically I don't think we yet > have an unambiguous definition of what is being identified. > > This version added some new text: > > In this document, the word "session" refers to a "communication > session" that may exist between two SIP user agents and that may > pass > through one or more intermediary devices, including B2BUAs or SIP > proxies. A communication session consists of one of more SIP > transactions. A very simple communication session may be a single > out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a > SIP dialog, the SIP message exchange includes a dialog creating > INVITE transaction, and zero of more subsequent SIP transactions > within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the > existence of middle boxes, there may be multiple related SIP > transactions or dialogs chained together along the path from one end > of the communication session to the other. For example: > > A Middlebox B > SIP trans1 -----------------> SIP trans 2 > SIP dialog 1 <-------------- SIP dialog 2 > > Figure 1 - Communication Session through a Middlebox > > In such cases, the two SIP transactions or dialogs are part of a > single communication session. > > The term "end-to-end" in this document means the communication > session from the point of origin, passing through any number of > intermediaries, to the ultimate point of termination. It is > recognized that legacy devices may not support the "end-to-end" > session identifier, though an identifier might be created by an > intermediary when it is absent from the session signaling. > > IMO this is a big improvement. But it still isn't as precise as I would > like. What I find lacking in the above is: > > o parsing the above, the properties of a communication session are: > - connects *two* UAs > - optionally includes one or more intermediary devices > - one or more transactions > - one out-of-dialog transaction, > OR a dialog including the dialog establishing transaction > and some transactions within the dialog. > - middle boxes may result in chaining dialogs or transactions. > > Exactly how all these properties "plug together" fuzzy. > I'm not at all certain that all readers would reach > the same conclusion about which cases meet these criteria > and which don't. > > o I'm also not certain that these criteria match all the cases > people expect, and exclude all the cases people think should > be excluded. > > - I think people expect that a conference is *not* a single > communications session. But a conference with only two > participants would seem to qualify according to all of the > above criteria. So that suggests that another criterion is > needed to exclude that case. > > - A topologically similar case to the conference is a > click-to-dial case where a web server makes outward INVITEs > to two UAs and connects them. I think people believe this > case *should* be a communications session. > > - Another case is described in > http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html > and debated in the replies to that. Arguments are made for > different answers to what should get a common session id and what > should not. For this case I think we need to decide: > . do we mandate exactly how this should be treated? > . or do we leave it to the discretion of the B2BUA to decide? > > Either way we need to decide what the criteria are that lead > to the decision. > > o IIRC Hadriel suggested (in a meeting?) that where media > originates and terminates has something to do with this. > That doesn't work all the time (e.g. MESSAGE), but it might help > in some cases. I think he used this to justify that: > > - the Conference Bridge Transcoding Model (RFC5369 section 3.2) > is a single communications session. > > - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* > a single communications session. > > (I'm not convinced - this seems like a distinction without > a difference.) > > Fundamentally we should be able to classify all cases into: > - those that *should* be communications sessions, > - those that *shouldn't* be communication sessions, > - those we don't care about - could be either way. > > When we are done, we should be able to apply the definition of > communication session to any case. When applied to the cases we > explicitly care about it should deliver the answer we expect. > > The more weird cases we care about, the more complex and unintuitive the > criteria will be. I suspect that the path we are on will lead to complex > criteria. (We can have a really crisp definition of communications > session if we don't care much about which cases qualify.) > > One idea I considered is to define some new terms that build on normal > sip concepts but extend them to allow B2BUA intermediaries where sip > allows proxies. E.g. > - Transaction++ is either a sip transaction, or a series of sip > transactions linked by B2BUA intermediaries. > > - Dialog++ is either a sip dialog, or a series of sip dialogs > linked by B2BUA intermediaries. > > Then would need to define the behavior of a B2BUA intermediary. It needs > to relay transactions from one "side" to the other, preserving certain > invariants (TBD). Presumably it can also originate certain transactions, > but there must be constraints on what it can do. There must also be some > rules on how media is handled across one of these intermediaries. > > If that was done, then a communication session could be defined as a > Transaction++ for an out-of-dialog request, or a Dialog++. > > But that makes the definition of communication session the first > priority and the cases that happen to qualify as a communication session > a consequence. It probably won't match people's intuitive feelings about > what *should* be a communication session. So it might not satisfy people. > > Thanks, > Paul > > > On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: > >>From my point of view, the draft looks good. The changes incorporated > in this updated version directly address this open issue. > > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > >> Behalf Of Gonzalo Salgueiro (gsalguei) > >> Sent: Thursday, January 10, 2013 12:39 PM > >> To: Paul E. Jones > >> Cc: insipid@ietf.org > >> Subject: Re: [Insipid] Are we ready to LC on the requirements? > >> > >> Thanks for submitting this, Paul. The biggest open issue in regards > >> to the requirements document was to clearly define what it is we are > >> identifying (i.e., "communication session") within the scope of this > >> document and ensure that clearly defined language is used > >> consistently throughout the document. Prior to any consensus on > >> moving to WGLC, the chairs would appreciate hearing the group's > >> thoughts on where we are on this issue in the current version. > >> > >> Cheers, > >> > >> Gonzalo & Keith > >> > >> > >> > >> On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: > >> > >>> Folks, > >>> > >>> Dialog has been extremely light on the requirements document. Do > >> people feel generally OK with it as it is now? Can we move on to the > >> solution document now or are there other changes needed in the > >> requirements document? > >>> > >>> I just posted the -04 version with changes proposed on the list over > >>> the > >> past month or so. > >>> > >>> 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 Sat Feb 23 17:01:12 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA94221F8F09 for ; Sat, 23 Feb 2013 17:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JMWMl9VxtAR for ; Sat, 23 Feb 2013 17:01:01 -0800 (PST) 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 E08C321F8EFB for ; Sat, 23 Feb 2013 17:00:59 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta02.westchester.pa.mail.comcast.net with comcast id 40aM1l00317dt5G5110zDN; Sun, 24 Feb 2013 01:00:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([125.122.241.79]) by omta13.westchester.pa.mail.comcast.net with comcast id 40ym1l00N1jVNfx3Z0yp9W; Sun, 24 Feb 2013 00:58:57 +0000 Message-ID: <512965C1.2090204@alum.mit.edu> Date: Sat, 23 Feb 2013 19:58:41 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Paul E. Jones" References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> <50F07742.3030601@alum.mit.edu> <0a0e01ce10a7$875a0690$960e13b0$@packetizer.com> In-Reply-To: <0a0e01ce10a7$875a0690$960e13b0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361667659; bh=Ma7L8Kqhzk3NPcUCvV2Aj75VrvbUEGcJ9tPuK/OmPWk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BB556X0+h4uFt1XusCb41Cv6EgywZa9mi4prG/Bp+Anjv1FiubP3xfVUgIVIylc5K +apx1KfytO2ed5uQ3VghfmKOMjW4fXJf8ZyO9eDF0ZGOdcv7t5pZ1uHHAU/3fFuRVJ I3nXIsKHamSMlr1H2KihK5ytZ96wqdFpxtDCfPXmqV8eZoPVpnB7xNmRDT4wlwqmqK 1Lzz77tNajifU3jHu16+mhbAvpH4pBc1trdw5vawAB0SqmAJy+No/m8Xq0ANlH7a0Z 1b/1JyLy674L3l4Lc1Lgq8IGN9h3xKSAyLyvpTNIQBotUzKvln/xr7TMzvMaeffFXB QDdYdCqiE6vCA== Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 01:01:12 -0000 On 2/21/13 9:51 PM, Paul E. Jones wrote: > Paul, > > I read your message, but was left unsure of exactly how we could improve the > definition over what we have already. > > If there is something concrete that you can propose that would help lend to > clarity of the text, I'm definitely willing to put it in. I would like to > move the requirements along and the submission deadline is Monday. Do you > have text you would like to add before the deadline? I'm traveling on business and have limited internet access, and limited time, so I probably can't. In any case, ISTM that the problem isn't that we don't have the right words. Rather, we still don't have clear *concepts* that distinguish what should be covered from what should not. We have some use cases, but lack basic principles that can be applied to any case to determine if it should be a communication session or not. It still seems to be more in the realm of "I know one when I see it." If we had the principles, then it would probably be straightforward to come up with words. I don't yet see a suitable general principle here that fits the use cases and seems to make sense. Thanks, Paul > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, January 11, 2013 3:34 PM >> To: insipid@ietf.org >> Subject: Re: [Insipid] Are we ready to LC on the requirements? >> >> (Sorry that this is long. I don't know how to make it short.) >> >> Are we ready to LC? I don't think so. Specifically I don't think we yet >> have an unambiguous definition of what is being identified. >> >> This version added some new text: >> >> In this document, the word "session" refers to a "communication >> session" that may exist between two SIP user agents and that may >> pass >> through one or more intermediary devices, including B2BUAs or SIP >> proxies. A communication session consists of one of more SIP >> transactions. A very simple communication session may be a single >> out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a >> SIP dialog, the SIP message exchange includes a dialog creating >> INVITE transaction, and zero of more subsequent SIP transactions >> within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the >> existence of middle boxes, there may be multiple related SIP >> transactions or dialogs chained together along the path from one end >> of the communication session to the other. For example: >> >> A Middlebox B >> SIP trans1 -----------------> SIP trans 2 >> SIP dialog 1 <-------------- SIP dialog 2 >> >> Figure 1 - Communication Session through a Middlebox >> >> In such cases, the two SIP transactions or dialogs are part of a >> single communication session. >> >> The term "end-to-end" in this document means the communication >> session from the point of origin, passing through any number of >> intermediaries, to the ultimate point of termination. It is >> recognized that legacy devices may not support the "end-to-end" >> session identifier, though an identifier might be created by an >> intermediary when it is absent from the session signaling. >> >> IMO this is a big improvement. But it still isn't as precise as I would >> like. What I find lacking in the above is: >> >> o parsing the above, the properties of a communication session are: >> - connects *two* UAs >> - optionally includes one or more intermediary devices >> - one or more transactions >> - one out-of-dialog transaction, >> OR a dialog including the dialog establishing transaction >> and some transactions within the dialog. >> - middle boxes may result in chaining dialogs or transactions. >> >> Exactly how all these properties "plug together" fuzzy. >> I'm not at all certain that all readers would reach >> the same conclusion about which cases meet these criteria >> and which don't. >> >> o I'm also not certain that these criteria match all the cases >> people expect, and exclude all the cases people think should >> be excluded. >> >> - I think people expect that a conference is *not* a single >> communications session. But a conference with only two >> participants would seem to qualify according to all of the >> above criteria. So that suggests that another criterion is >> needed to exclude that case. >> >> - A topologically similar case to the conference is a >> click-to-dial case where a web server makes outward INVITEs >> to two UAs and connects them. I think people believe this >> case *should* be a communications session. >> >> - Another case is described in >> http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html >> and debated in the replies to that. Arguments are made for >> different answers to what should get a common session id and what >> should not. For this case I think we need to decide: >> . do we mandate exactly how this should be treated? >> . or do we leave it to the discretion of the B2BUA to decide? >> >> Either way we need to decide what the criteria are that lead >> to the decision. >> >> o IIRC Hadriel suggested (in a meeting?) that where media >> originates and terminates has something to do with this. >> That doesn't work all the time (e.g. MESSAGE), but it might help >> in some cases. I think he used this to justify that: >> >> - the Conference Bridge Transcoding Model (RFC5369 section 3.2) >> is a single communications session. >> >> - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* >> a single communications session. >> >> (I'm not convinced - this seems like a distinction without >> a difference.) >> >> Fundamentally we should be able to classify all cases into: >> - those that *should* be communications sessions, >> - those that *shouldn't* be communication sessions, >> - those we don't care about - could be either way. >> >> When we are done, we should be able to apply the definition of >> communication session to any case. When applied to the cases we >> explicitly care about it should deliver the answer we expect. >> >> The more weird cases we care about, the more complex and unintuitive the >> criteria will be. I suspect that the path we are on will lead to complex >> criteria. (We can have a really crisp definition of communications >> session if we don't care much about which cases qualify.) >> >> One idea I considered is to define some new terms that build on normal >> sip concepts but extend them to allow B2BUA intermediaries where sip >> allows proxies. E.g. >> - Transaction++ is either a sip transaction, or a series of sip >> transactions linked by B2BUA intermediaries. >> >> - Dialog++ is either a sip dialog, or a series of sip dialogs >> linked by B2BUA intermediaries. >> >> Then would need to define the behavior of a B2BUA intermediary. It needs >> to relay transactions from one "side" to the other, preserving certain >> invariants (TBD). Presumably it can also originate certain transactions, >> but there must be constraints on what it can do. There must also be some >> rules on how media is handled across one of these intermediaries. >> >> If that was done, then a communication session could be defined as a >> Transaction++ for an out-of-dialog request, or a Dialog++. >> >> But that makes the definition of communication session the first >> priority and the cases that happen to qualify as a communication session >> a consequence. It probably won't match people's intuitive feelings about >> what *should* be a communication session. So it might not satisfy people. >> >> Thanks, >> Paul >> >> >> On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: >>> >From my point of view, the draft looks good. The changes incorporated >> in this updated version directly address this open issue. >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Gonzalo Salgueiro (gsalguei) >>>> Sent: Thursday, January 10, 2013 12:39 PM >>>> To: Paul E. Jones >>>> Cc: insipid@ietf.org >>>> Subject: Re: [Insipid] Are we ready to LC on the requirements? >>>> >>>> Thanks for submitting this, Paul. The biggest open issue in regards >>>> to the requirements document was to clearly define what it is we are >>>> identifying (i.e., "communication session") within the scope of this >>>> document and ensure that clearly defined language is used >>>> consistently throughout the document. Prior to any consensus on >>>> moving to WGLC, the chairs would appreciate hearing the group's >>>> thoughts on where we are on this issue in the current version. >>>> >>>> Cheers, >>>> >>>> Gonzalo & Keith >>>> >>>> >>>> >>>> On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: >>>> >>>>> Folks, >>>>> >>>>> Dialog has been extremely light on the requirements document. Do >>>> people feel generally OK with it as it is now? Can we move on to the >>>> solution document now or are there other changes needed in the >>>> requirements document? >>>>> >>>>> I just posted the -04 version with changes proposed on the list over >>>>> the >>>> past month or so. >>>>> >>>>> 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 paulej@packetizer.com Sat Feb 23 21:34:05 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A8A21F898A for ; Sat, 23 Feb 2013 21:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqlArLU8bCIt for ; Sat, 23 Feb 2013 21:34:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2087E21F8983 for ; Sat, 23 Feb 2013 21:34:03 -0800 (PST) Received: from dyn-170.arid.us (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1O5Y1gJ018742 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 24 Feb 2013 00:34:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361684042; bh=/LIx8hNTd0+vxXa3K99yijsYbXld2gfBo59uGsF6A20=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=nnwIVSW7ERrBcp06MeUu7uSKnuh6QGQmec+TA6ji3c2ER6bNNYPv1ITQ4oYkBbZl2 xNHPGO/q7trUUIzSmTZrhYMqGD7XoONceo3d30mgNdbC5vK2nA+EeLAtVxf/+tfBo9 bdDkeVaAIN6S1Qe1f+U6zXMDy0IKYfVWb85TrmwU= User-Agent: Kaiten Mail In-Reply-To: <512965C1.2090204@alum.mit.edu> References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> <50F07742.3030601@alum.mit.edu> <0a0e01ce10a7$875a0690$960e13b0$@packetizer.com> <512965C1.2090204@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----LHC5BNPBKPXD9PFEYC61UBNU66AEOB" From: "Paul E. Jones" Date: Sun, 24 Feb 2013 00:33:58 -0500 To: Paul Kyzivat Message-ID: <55fa36b1-465e-40e0-b875-90fb48f3fc13@email.android.com> Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 05:34:05 -0000 ------LHC5BNPBKPXD9PFEYC61UBNU66AEOB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Paul, So what concept is vague? In terms of an H.323 device, I would consider two terminals with users at each end to be a communication session. I would consider a terminal and an MCU to have a communication session. The collection of communication sessions on an MCU to which one or more terrminals are a party is a conference. And I would like to relate all those sessions by the UUID the MCU uses in each of those sessions. That value could even be the Conference ID in H.323. There are gateway devices that connect to the PSTN that I would count as equal to a terminal. But, there are gateway devices that bridge IP networks (SBCs) that should just pass the UUIDs through. The difference between the two really is whether it bridges an IPMC device to another or to something else. There are call flows like the one you highlighted in the threads where voice comes from one terminal and video from another. That's an MCU, really. The session ID exists between Alice and MCU (or PBX). The other devices Bob uses might share the UUID of the MCU/PBX, but those are distinct communication sessions like the typical MCU case. Yeah, such topologies do make it hard to do debugging and the number of UUIDs makes it a pain, too, but at least there is consistency in the assignments. So, it is doable. So, how can we make progress here? Paul -------- Original Message -------- From: Paul Kyzivat Sent: Sat Feb 23 19:58:41 EST 2013 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? On 2/21/13 9:51 PM, Paul E. Jones wrote: > Paul, > > I read your message, but was left unsure of exactly how we could improve the > definition over what we have already. > > If there is something concrete that you can propose that would help lend to > clarity of the text, I'm definitely willing to put it in. I would like to > move the requirements along and the submission deadline is Monday. Do you > have text you would like to add before the deadline? I'm traveling on business and have limited internet access, and limited time, so I probably can't. In any case, ISTM that the problem isn't that we don't have the right words. Rather, we still don't have clear *concepts* that distinguish what should be covered from what should not. We have some use cases, but lack basic principles that can be applied to any case to determine if it should be a communication session or not. It still seems to be more in the realm of "I know one when I see it." If we had the principles, then it would probably be straightforward to come up with words. I don't yet see a suitable general principle here that fits the use cases and seems to make sense. Thanks, Paul > Paul > >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Friday, January 11, 2013 3:34 PM >> To: insipid@ietf.org >> Subject: Re: [Insipid] Are we ready to LC on the requirements? >> >> (Sorry that this is long. I don't know how to make it short.) >> >> Are we ready to LC? I don't think so. Specifically I don't think we yet >> have an unambiguous definition of what is being identified. >> >> This version added some new text: >> >> In this document, the word "session" refers to a "communication >> session" that may exist between two SIP user agents and that may >> pass >> through one or more intermediary devices, including B2BUAs or SIP >> proxies. A communication session consists of one of more SIP >> transactions. A very simple communication session may be a single >> out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a >> SIP dialog, the SIP message exchange includes a dialog creating >> INVITE transaction, and zero of more subsequent SIP transactions >> within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the >> existence of middle boxes, there may be multiple related SIP >> transactions or dialogs chained together along the path from one end >> of the communication session to the other. For example: >> >> A Middlebox B >> SIP trans1 -----------------> SIP trans 2 >> SIP dialog 1 <-------------- SIP dialog 2 >> >> Figure 1 - Communication Session through a Middlebox >> >> In such cases, the two SIP transactions or dialogs are part of a >> single communication session. >> >> The term "end-to-end" in this document means the communication >> session from the point of origin, passing through any number of >> intermediaries, to the ultimate point of termination. It is >> recognized that legacy devices may not support the "end-to-end" >> session identifier, though an identifier might be created by an >> intermediary when it is absent from the session signaling. >> >> IMO this is a big improvement. But it still isn't as precise as I would >> like. What I find lacking in the above is: >> >> o parsing the above, the properties of a communication session are: >> - connects *two* UAs >> - optionally includes one or more intermediary devices >> - one or more transactions >> - one out-of-dialog transaction, >> OR a dialog including the dialog establishing transaction >> and some transactions within the dialog. >> - middle boxes may result in chaining dialogs or transactions. >> >> Exactly how all these properties "plug together" fuzzy. >> I'm not at all certain that all readers would reach >> the same conclusion about which cases meet these criteria >> and which don't. >> >> o I'm also not certain that these criteria match all the cases >> people expect, and exclude all the cases people think should >> be excluded. >> >> - I think people expect that a conference is *not* a single >> communications session. But a conference with only two >> participants would seem to qualify according to all of the >> above criteria. So that suggests that another criterion is >> needed to exclude that case. >> >> - A topologically similar case to the conference is a >> click-to-dial case where a web server makes outward INVITEs >> to two UAs and connects them. I think people believe this >> case *should* be a communications session. >> >> - Another case is described in >> http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html >> and debated in the replies to that. Arguments are made for >> different answers to what should get a common session id and what >> should not. For this case I think we need to decide: >> . do we mandate exactly how this should be treated? >> . or do we leave it to the discretion of the B2BUA to decide? >> >> Either way we need to decide what the criteria are that lead >> to the decision. >> >> o IIRC Hadriel suggested (in a meeting?) that where media >> originates and terminates has something to do with this. >> That doesn't work all the time (e.g. MESSAGE), but it might help >> in some cases. I think he used this to justify that: >> >> - the Conference Bridge Transcoding Model (RFC5369 section 3.2) >> is a single communications session. >> >> - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* >> a single communications session. >> >> (I'm not convinced - this seems like a distinction without >> a difference.) >> >> Fundamentally we should be able to classify all cases into: >> - those that *should* be communications sessions, >> - those that *shouldn't* be communication sessions, >> - those we don't care about - could be either way. >> >> When we are done, we should be able to apply the definition of >> communication session to any case. When applied to the cases we >> explicitly care about it should deliver the answer we expect. >> >> The more weird cases we care about, the more complex and unintuitive the >> criteria will be. I suspect that the path we are on will lead to complex >> criteria. (We can have a really crisp definition of communications >> session if we don't care much about which cases qualify.) >> >> One idea I considered is to define some new terms that build on normal >> sip concepts but extend them to allow B2BUA intermediaries where sip >> allows proxies. E.g. >> - Transaction++ is either a sip transaction, or a series of sip >> transactions linked by B2BUA intermediaries. >> >> - Dialog++ is either a sip dialog, or a series of sip dialogs >> linked by B2BUA intermediaries. >> >> Then would need to define the behavior of a B2BUA intermediary. It needs >> to relay transactions from one "side" to the other, preserving certain >> invariants (TBD). Presumably it can also originate certain transactions, >> but there must be constraints on what it can do. There must also be some >> rules on how media is handled across one of these intermediaries. >> >> If that was done, then a communication session could be defined as a >> Transaction++ for an out-of-dialog request, or a Dialog++. >> >> But that makes the definition of communication session the first >> priority and the cases that happen to qualify as a communication session >> a consequence. It probably won't match people's intuitive feelings about >> what *should* be a communication session. So it might not satisfy people. >> >> Thanks, >> Paul >> >> >> On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: >>> >From my point of view, the draft looks good. The changes incorporated >> in this updated version directly address this open issue. >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>> Behalf Of Gonzalo Salgueiro (gsalguei) >>>> Sent: Thursday, January 10, 2013 12:39 PM >>>> To: Paul E. Jones >>>> Cc: insipid@ietf.org >>>> Subject: Re: [Insipid] Are we ready to LC on the requirements? >>>> >>>> Thanks for submitting this, Paul. The biggest open issue in regards >>>> to the requirements document was to clearly define what it is we are >>>> identifying (i.e., "communication session") within the scope of this >>>> document and ensure that clearly defined language is used >>>> consistently throughout the document. Prior to any consensus on >>>> moving to WGLC, the chairs would appreciate hearing the group's >>>> thoughts on where we are on this issue in the current version. >>>> >>>> Cheers, >>>> >>>> Gonzalo & Keith >>>> >>>> >>>> >>>> On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: >>>> >>>>> Folks, >>>>> >>>>> Dialog has been extremely light on the requirements document. Do >>>> people feel generally OK with it as it is now? Can we move on to the >>>> solution document now or are there other changes needed in the >>>> requirements document? >>>>> >>>>> I just posted the -04 version with changes proposed on the list over >>>>> the >>>> past month or so. >>>>> >>>>> 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 ------LHC5BNPBKPXD9PFEYC61UBNU66AEOB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Paul,

So what concept is vague?

In terms of an H.323 device, I would consider two terminals with users at each end to be a communication session. I would consider a terminal and an MCU to have a communication session.

The collection of communication sessions on an MCU to which one or more terrminals are a party is a conference. And I would like to relate all those sessions by the UUID the MCU uses in each of those sessions. That value could even be the Conference ID in H.323.

There are gateway devices that connect to the PSTN that I would count as equal to a terminal. But, there are gateway devices that bridge IP networks (SBCs) that should just pass the UUIDs through. The difference between the two really is whether it bridges an IPMC device to another or to something else.

There are call flows like the one you highlighted in the threads where voice comes from one terminal and video from another. That's an MCU, really. The session ID exists between Alice and MCU (or PBX). The other devices Bob uses might share the UUID of the MCU/PBX, but those are distinct communication sessions like the typical MCU case. Yeah, such topologies do make it hard to do debugging and the number of UUIDs makes it a pain, too, but at least there is consistency in the assignments. So, it is doable.

So, how can we make progress here?

Paul



From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Sent: Sat Feb 23 19:58:41 EST 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: Re: [Insipid] Are we ready to LC on the requirements?

On 2/21/13 9:51 PM, Paul E. Jones wrote:
Paul,

I read your message, but was left unsure of exactly how we could improve the
definition over what we have already.

If there is something concrete that you can propose that would help lend to
clarity of the text, I'm definitely willing to put it in.  I would like to
move the requirements along and the submission deadline is Monday.  Do you
have text you would like to add before the deadline?

I'm traveling on business and have limited internet access, and limited 
time, so I probably can't.

In any case, ISTM that the problem isn't that we don't have the right 
words. Rather, we still don't have clear *concepts* that distinguish 
!
 what
should be covered from what should not. We have some use cases, but 
lack basic principles that can be applied to any case to determine if it 
should be a communication session or not. It still seems to be more in 
the realm of "I know one when I see it."

If we had the principles, then it would probably be straightforward to 
come up with words.

I don't yet see a suitable general principle here that fits the use 
cases and seems to make sense.

 Thanks,
 Paul

Paul

-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: Friday, January 11, 2013 3:34 PM
To: insipid@ietf.org
Subject: Re: [Insipid] Are we ready to LC on the requirements?

(Sorry that this is long. I don't know how to make it short.)

Are we ready to LC? I don't think so. Specifically I don't think we yet
have an unambiguous definition of what is being identified.

This version added some new text:

In this document, the word "session" refers to a "communication
session" that may exist between two SIP user agents and that may
pass
through one or more intermediary devices, including B2BUAs or SIP
proxies. A communication session consists of one of more SIP
transactions. A very simple communication session may be a single
out-of-dialog SIP transaction (e.g., MESSAGE/200).  In the case of a
SIP dialog, the SIP message exchange includes a dialog creating
INVITE transaction, and zero of more subsequent SIP transactions
within the same dialog (e.g., ACK, re-INVITE, BYE).  Due to the
existenc!
 e of
middle boxes, there may be multiple related SIP
transactions or dialogs chained together along the path from one end
of the communication session to the other. For example:

A               Middlebox               B
SIP trans1 -----------------> SIP trans 2
SIP dialog 1 <-------------- SIP dialog 2

Figure 1 - Communication Session through a Middlebox

In such cases, the two SIP transactions or dialogs are part of a
single communication session.

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

IMO this is a big improvement. But it still isn't as prec!
 ise as I
would
like. What I find lacking in the above is:

o  parsing the above, the properties of a communication session are:
- connects *two* UAs
- optionally includes one or more intermediary devices
- one or more transactions
- one out-of-dialog transaction,
OR a dialog including the dialog establishing transaction
and some transactions within the dialog.
- middle boxes may result in chaining dialogs or transactions.

Exactly how all these properties "plug together" fuzzy.
I'm not at all certain that all readers would reach
the same conclusion about which cases meet these criteria
and which don't.

o  I'm also not certain that these criteria match all the cases
people expect, and exclude all the cases people think should
be excluded.

- I think people expect that a conference is *not* a single
communications session. But a conference with only two
participants would!
  seem to
qualify according to all of the
above criteria. So that suggests that another criterion is
needed to exclude that case.

- A topologically similar case to the conference is a
click-to-dial case where a web server makes outward INVITEs
to two UAs and connects them. I think people believe this
case *should* be a communications session.

- Another case is described in
http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html
and debated in the replies to that. Arguments are made for
different answers to what should get a common session id and what
should not. For this case I think we need to decide:
. do we mandate exactly how this should be treated?
. or do we leave it to the discretion of the B2BUA to decide?

Either way we need to decide what the criteria are that lead
to the decision.

o!
   IIRC
Hadriel suggested (in a meeting?) that where media
originates and terminates has something to do with this.
That doesn't work all the time (e.g. MESSAGE), but it might help
in some cases. I think he used this to justify that:

- the Conference Bridge Transcoding Model (RFC5369 section 3.2)
is a single communications session.

- the 3PCC Transcoding Model (RFC5369 section 3.1) is *not*
a single communications session.

(I'm not convinced - this seems like a distinction without
a difference.)

Fundamentally we should be able to classify all cases into:
- those that *should* be communications sessions,
- those that *shouldn't* be communication sessions,
- those we don't care about - could be either way.

When we are done, we should be able to apply the definition of
communication session to any case. When applied to the cases we
explicitly care about it should deliver the an!
 swer we
expect.

The more weird cases we care about, the more complex and unintuitive the
criteria will be. I suspect that the path we are on will lead to complex
criteria. (We can have a really crisp definition of communications
session if we don't care much about which cases qualify.)

One idea I considered is to define some new terms that build on normal
sip concepts but extend them to allow B2BUA intermediaries where sip
allows proxies. E.g.
- Transaction++ is either a sip transaction, or a series of sip
transactions linked by B2BUA intermediaries.

- Dialog++ is either a sip dialog, or a series of sip dialogs
linked by B2BUA intermediaries.

Then would need to define the behavior of a B2BUA intermediary. It needs
to relay transactions from one "side" to the other, preserving certain
invariants (TBD). Presumably it can also originate certain transactions,
but there must be constraints !
 on what
it can do. There must also be some
rules on how media is handled across one of these intermediaries.

If that was done, then a communication session could be defined as a
Transaction++ for an out-of-dialog request, or a Dialog++.

But that makes the definition of communication session the first
priority and the cases that happen to qualify as a communication session
a consequence. It probably won't match people's intuitive feelings about
what *should* be a communication session. So it might not satisfy people.

 Thanks,
 Paul


On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote:
From my point of view, the draft looks good. The changes incorporated
in this updated version directly address this open issue.

Cheers,
Charles

-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Thursday, January 10, 2013 12:39 PM
To: Paul E. Jones
Cc: insipid@ietf.org
Subject: Re: [Insipid] Are we ready to LC on the requirements?

Thanks for submitting this, Paul.  The biggest open issue in regards
to the requirements document was to clearly define what it is we are
identifying (i.e., "communication session") within the scope of this
document and ensure that clearly defined language is used
consistently through!
 out the
document.  Prior to any consensus on
moving to WGLC, the chairs would appreciate hearing the group's
thoughts on where we are on this issue in the current version.

Cheers,

Gonzalo & Keith



On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote:

Folks,

Dialog has been extremely light on the requirements document.  Do
people feel generally OK with it as it is now?  Can we move on to the
solution document now or are there other changes needed in the
requirements document?

I just posted the -04 version with changes proposed on the list over
the
past month or so.

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
------LHC5BNPBKPXD9PFEYC61UBNU66AEOB-- From pkyzivat@alum.mit.edu Sat Feb 23 22:46:15 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1167E21F8FE0 for ; Sat, 23 Feb 2013 22:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyp6ApuWdq4p for ; Sat, 23 Feb 2013 22:46:14 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BE65421F8FD9 for ; Sat, 23 Feb 2013 22:46:12 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id 46bM1l0050EZKEL536mCKa; Sun, 24 Feb 2013 06:46:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([125.122.241.79]) by omta01.westchester.pa.mail.comcast.net with comcast id 46jy1l00Z1jVNfx3M6k1py; Sun, 24 Feb 2013 06:44:10 +0000 Message-ID: <5129B6AD.6010306@alum.mit.edu> Date: Sun, 24 Feb 2013 01:43:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Paul E. Jones" References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> <50F07742.3030601@alum.mit.edu> <0a0e01ce10a7$875a0690$960e13b0$@packetizer.com> <512965C1.2090204@alum.mit.edu> <55fa36b1-465e-40e0-b875-90fb48f3fc13@email.android.com> In-Reply-To: <55fa36b1-465e-40e0-b875-90fb48f3fc13@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361688372; bh=dCfEiTENwKVhmr5uURNBTtp2WBk/20JImS+8gg0X4nw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jX344k48MlUEEKRB/MzKMc477d1HhcsMncO3nnA9PIi4PMwEDFTM+7molUSENMgxy PxJXyfEGKbokf5OC/GESGz3Bh5mjio4adje40qeAfEos8AOD22wd8OOATYGjfw8F6i uaUNUol8EpKfAIOJ7WYUgUVbNkFMIH5B5T+MNxhLYorMRmtJtCwC/f2+qcQa8a1ERk bAnm5NzXQYzdL/jZKo4sopyBrXVOT4mQ0UOgqNWnPXX9T44ER1GDGaJUuOM0JwYqR3 Ta6Qbu/d2M0EjnX+m1citc0zQhqHHVfqohR+DjK7yazASxDLVtS4GsngTyT5cXL++s ypeO45Z+3EDEw== Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 06:46:15 -0000 On 2/24/13 12:33 AM, Paul E. Jones wrote: > Paul, > > So what concept is vague? > > In terms of an H.323 device, I would consider two terminals with users > at each end to be a communication session. I would consider a terminal > and an MCU to have a communication session. > > The collection of communication sessions on an MCU to which one or more > terrminals are a party is a conference. And I would like to relate all > those sessions by the UUID the MCU uses in each of those sessions. That > value could even be the Conference ID in H.323. > > There are gateway devices that connect to the PSTN that I would count as > equal to a terminal. But, there are gateway devices that bridge IP > networks (SBCs) that should just pass the UUIDs through. The difference > between the two really is whether it bridges an IPMC device to another > or to something else. > > There are call flows like the one you highlighted in the threads where > voice comes from one terminal and video from another. That's an MCU, > really. The session ID exists between Alice and MCU (or PBX). The other > devices Bob uses might share the UUID of the MCU/PBX, but those are > distinct communication sessions like the typical MCU case. Yeah, such > topologies do make it hard to do debugging and the number of UUIDs makes > it a pain, too, but at least there is consistency in the assignments. > So, it is doable. > > So, how can we make progress here? We write some rules that any device that terminates more than one dialog can use to decide when one dialog should share a session-id with another dialog. The rules should get the "right" answer for all the use cases, and should be specific enough so that when applied to any device, no matter how weird, most reasonable people would agree with the answer. That way we can have a way of judging conformance to this specification. I realize this bridges the gap between what the requirements are responsible for and what the mechanism is responsible for. But the mechanism is about marking communications sessions, not defining them. OR I suppose the requirements could kick the can down the road, simply say that the mechanism must work for the specified use cases and itself must specify the algorithm for making the decision in other cases. But that just puts it off. Thanks, Paul K > Paul > > > > ------------------------------------------------------------------------ > *From:* Paul Kyzivat > *Sent:* Sat Feb 23 19:58:41 EST 2013 > *To:* "Paul E. Jones" > *Cc:* insipid@ietf.org > *Subject:* Re: [Insipid] Are we ready to LC on the requirements? > > On 2/21/13 9:51 PM, Paul E. Jones wrote: > > Paul, > > I read your message, but was left unsure of exactly how we could > improve the > definition over what we have already. > > If there is something concrete that you can propose that would help > lend to > clarity of the text, I'm definitely willing to put it in. I would > like to > move the requirements along and the submission deadline is Monday. > Do you > have text you would like to add before the deadline? > > > I'm traveling on business and have limited internet access, and limited > time, so I probably can't. > > In any case, ISTM that the problem isn't that we don't have the right > words. Rather, we still don't have clear *concepts* that distinguish > ! > what > should be covered from what should not. We have some use cases, but > lack basic principles that can be applied to any case to determine if it > should be a communication session or not. It still seems to be more in > the realm of "I know one when I see it." > > If we had the principles, then it would probably be straightforward to > come up with words. > > I don't yet see a suitable general principle here that fits the use > cases and seems to make sense. > > Thanks, > Paul > > Paul > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, January 11, 2013 3:34 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Are we ready to LC on the requirements? > > (Sorry that this is long. I don't know how to make it short.) > > Are we ready to LC? I don't think so. Specifically I don't think > we yet > have an unambiguous definition of what is being identified. > > This version added some new text: > > In this document, the word "session" refers to a "communication > session" that may exist between two SIP user agents and that may > pass > through one or more intermediary devices, including B2BUAs or SIP > proxies. A communication session consists of one of more SIP > transactions. A very simple communication session may be a single > out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a > SIP dialog, the SIP message exchange includes a dialog creating > INVITE transaction, and zero of more subsequent SIP transactions > within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the > existenc! e of middle boxes, there may be multiple related SIP > transactions or dialogs chained together along the path from one end > of the communication session to the other. For example: > > A Middlebox B > SIP trans1 -----------------> SIP trans 2 > SIP dialog 1 <-------------- SIP dialog 2 > > Figure 1 - Communication Session through a Middlebox > > In such cases, the two SIP transactions or dialogs are part of a > single communication session. > > The term "end-to-end" in this document means the communication > session from the point of origin, passing through any number of > intermediaries, to the ultimate point of termination. It is > recognized that legacy devices may not support the "end-to-end" > session identifier, though an identifier might be created by an > intermediary when it is absent from the session signaling. > > IMO this is a big improvement. But it still isn't as prec! ise > as I would > like. What I find lacking in the above is: > > o parsing the above, the properties of a communication session are: > - connects *two* UAs > - optionally includes one or more intermediary devices > - one or more transactions > - one out-of-dialog transaction, > OR a dialog including the dialog establishing transaction > and some transactions within the dialog. > - middle boxes may result in chaining dialogs or transactions. > > Exactly how all these properties "plug together" fuzzy. > I'm not at all certain that all readers would reach > the same conclusion about which cases meet these criteria > and which don't. > > o I'm also not certain that these criteria match all the cases > people expect, and exclude all the cases people think should > be excluded. > > - I think people expect that a conference is *not* a single > communications session. But a conference with only two > participants would! seem to qualify according to all of the > above criteria. So that suggests that another criterion is > needed to exclude that case. > > - A topologically similar case to the conference is a > click-to-dial case where a web server makes outward INVITEs > to two UAs and connects them. I think people believe this > case *should* be a communications session. > > - Another case is described in > http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html > and debated in the replies to that. Arguments are made for > different answers to what should get a common session id and what > should not. For this case I think we need to decide: > . do we mandate exactly how this should be treated? > . or do we leave it to the discretion of the B2BUA to decide? > > Either way we need to decide what the criteria are that lead > to the decision. > > o! IIRC Hadriel suggested (in a meeting?) that where media > originates and terminates has something to do with this. > That doesn't work all the time (e.g. MESSAGE), but it might help > in some cases. I think he used this to justify that: > > - the Conference Bridge Transcoding Model (RFC5369 section 3.2) > is a single communications session. > > - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* > a single communications session. > > (I'm not convinced - this seems like a distinction without > a difference.) > > Fundamentally we should be able to classify all cases into: > - those that *should* be communications sessions, > - those that *shouldn't* be communication sessions, > - those we don't care about - could be either way. > > When we are done, we should be able to apply the definition of > communication session to any case. When applied to the cases we > explicitly care about it should deliver the an! swer we expect. > > The more weird cases we care about, the more complex and > unintuitive the > criteria will be. I suspect that the path we are on will lead to > complex > criteria. (We can have a really crisp definition of communications > session if we don't care much about which cases qualify.) > > One idea I considered is to define some new terms that build on > normal > sip concepts but extend them to allow B2BUA intermediaries where sip > allows proxies. E.g. > - Transaction++ is either a sip transaction, or a series of sip > transactions linked by B2BUA intermediaries. > > - Dialog++ is either a sip dialog, or a series of sip dialogs > linked by B2BUA intermediaries. > > Then would need to define the behavior of a B2BUA intermediary. > It needs > to relay transactions from one "side" to the other, preserving > certain > invariants (TBD). Presumably it can also originate certain > transactions, > but there must be constraints ! on what it can do. There must > also be some > rules on how media is handled across one of these intermediaries. > > If that was done, then a communication session could be defined as a > Transaction++ for an out-of-dialog request, or a Dialog++. > > But that makes the definition of communication session the first > priority and the cases that happen to qualify as a communication > session > a consequence. It probably won't match people's intuitive > feelings about > what *should* be a communication session. So it might not > satisfy people. > > Thanks, > Paul > > > On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: > > From my point of view, the draft looks good. The > changes incorporated > > in this updated version directly address this open issue. > > Cheers, > Charles > > -----Original Message----- > From: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] On > Behalf Of Gonzalo Salgueiro (gsalguei) > Sent: Thursday, January 10, 2013 12:39 PM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Are we ready to LC on the > requirements? > > Thanks for submitting this, Paul. The biggest open issue > in regards > to the requirements document was to clearly define what > it is we are > identifying (i.e., "communication session") within the > scope of this > document and ensure that clearly defined language is used > consistently through! out the document. Prior to any > consensus on > moving to WGLC, the chairs would appreciate hearing the > group's > thoughts on where we are on this issue in the current > version. > > Cheers, > > Gonzalo & Keith > > > > On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: > > Folks, > > Dialog has been extremely light on the requirements > document. Do > > people feel generally OK with it as it is now? Can we > move on to the > solution document now or are there other changes needed > in the > requirements document? > > I just posted the -04 version with changes proposed > on the list over > the > > past month or so. > > 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 paulej@packetizer.com Sun Feb 24 06:38:42 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C69C21F8F95 for ; Sun, 24 Feb 2013 06:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-1.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_BACKHAIR_46=1, OBFUSCATING_COMMENT=0.973] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhatpXCUMc+7 for ; Sun, 24 Feb 2013 06:38:40 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 385F621F8F9F for ; Sun, 24 Feb 2013 06:38:37 -0800 (PST) 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 r1OEcZC8012250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 24 Feb 2013 09:38:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361716716; bh=IliC5s1RJbD2HPxQRn9KHL9Djd791yennIau//XkZqU=; h=In-Reply-To:References:MIME-Version:Content-Type:Subject:From: Date:To:CC:Message-ID; b=OpcUB1mUDJ1k3Wgv2x1PuR6MQGqo0PYjQFgHYWDYI86aBA5J+viXFWOQ43brsNA64 Q1NZdgP9/+AzlgNChJwuCL03B579u0r/NQD6XTECDqWdCuT8F3MtRJgZTk0Z9c61iC Cjl2lvE2zonfhg+6TgX+CiGbhnM1kMdl/bISkEzc= User-Agent: K-9 Mail for Android In-Reply-To: <5129B6AD.6010306@alum.mit.edu> References: <055801cdeed9$8b441060$a1cc3120$@packetizer.com> <5F864ABC-E17F-44C9-8CDE-D6C5A32BF214@cisco.com> <92B7E61ADAC1BB4F941F943788C0882804728936@xmb-aln-x08.cisco.com> <50F07742.3030601@alum.mit.edu> <0a0e01ce10a7$875a0690$960e13b0$@packetizer.com> <512965C1.2090204@alum.mit.edu> <55fa36b1-465e-40e0-b875-90fb48f3fc13@email.android.com> <5129B6AD.6010306@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----DSS2SP7FKTBEA4RP9835A5CUN59P61" From: "Paul E. Jones" Date: Sun, 24 Feb 2013 09:38:32 -0500 To: Paul Kyzivat Message-ID: Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 14:38:42 -0000 ------DSS2SP7FKTBEA4RP9835A5CUN59P61 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Paul, That still begs the question of "what language do we need to add or change to make this clear?" In my mind, I know exactly what an endpoint needs to do and what an SBC needs to do. But, I'll not say it does not need more charity for those that do not have it clear in their minds. But, perhaps being too close to the work, I'm having trouble seeing where it is vague. Can you suggest text? Paul -------- Original Message -------- From: Paul Kyzivat Sent: Sun Feb 24 01:43:57 EST 2013 To: "Paul E. Jones" Cc: insipid@ietf.org Subject: Re: [Insipid] Are we ready to LC on the requirements? On 2/24/13 12:33 AM, Paul E. Jones wrote: > Paul, > > So what concept is vague? > > In terms of an H.323 device, I would consider two terminals with users > at each end to be a communication session. I would consider a terminal > and an MCU to have a communication session. > > The collection of communication sessions on an MCU to which one or more > terrminals are a party is a conference. And I would like to relate all > those sessions by the UUID the MCU uses in each of those sessions. That > value could even be the Conference ID in H.323. > > There are gateway devices that connect to the PSTN that I would count as > equal to a terminal. But, there are gateway devices that bridge IP > networks (SBCs) that should just pass the UUIDs through. The difference > between the two really is whether it bridges an IPMC device to another > or to something else. > > There are call flows like the one you highlighted in the threads where > voice comes from one terminal and video from another. That's an MCU, > really. The session ID exists between Alice and MCU (or PBX). The other > devices Bob uses might share the UUID of the MCU/PBX, but those are > distinct communication sessions like the typical MCU case. Yeah, such > topologies do make it hard to do debugging and the number of UUIDs makes > it a pain, too, but at least there is consistency in the assignments. > So, it is doable. > > So, how can we make progress here? We write some rules that any device that terminates more than one dialog can use to decide when one dialog should share a session-id with another dialog. The rules should get the "right" answer for all the use cases, and should be specific enough so that when applied to any device, no matter how weird, most reasonable people would agree with the answer. That way we can have a way of judging conformance to this specification. I realize this bridges the gap between what the requirements are responsible for and what the mechanism is responsible for. But the mechanism is about marking communications sessions, not defining them. OR I suppose the requirements could kick the can down the road, simply say that the mechanism must work for the specified use cases and itself must specify the algorithm for making the decision in other cases. But that just puts it off. Thanks, Paul K > Paul > > > > ------------------------------------------------------------------------ > *From:* Paul Kyzivat > *Sent:* Sat Feb 23 19:58:41 EST 2013 > *To:* "Paul E. Jones" > *Cc:* insipid@ietf.org > *Subject:* Re: [Insipid] Are we ready to LC on the requirements? > > On 2/21/13 9:51 PM, Paul E. Jones wrote: > > Paul, > > I read your message, but was left unsure of exactly how we could > improve the > definition over what we have already. > > If there is something concrete that you can propose that would help > lend to > clarity of the text, I'm definitely willing to put it in. I would > like to > move the requirements along and the submission deadline is Monday. > Do you > have text you would like to add before the deadline? > > > I'm traveling on business and have limited internet access, and limited > time, so I probably can't. > > In any case, ISTM that the problem isn't that we don't have the right > words. Rather, we still don't have clear *concepts* that distinguish > ! > what > should be covered from what should not. We have some use cases, but > lack basic principles that can be applied to any case to determine if it > should be a communication session or not. It still seems to be more in > the realm of "I know one when I see it." > > If we had the principles, then it would probably be straightforward to > come up with words. > > I don't yet see a suitable general principle here that fits the use > cases and seems to make sense. > > Thanks, > Paul > > Paul > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, January 11, 2013 3:34 PM > To: insipid@ietf.org > Subject: Re: [Insipid] Are we ready to LC on the requirements? > > (Sorry that this is long. I don't know how to make it short.) > > Are we ready to LC? I don't think so. Specifically I don't think > we yet > have an unambiguous definition of what is being identified. > > This version added some new text: > > In this document, the word "session" refers to a "communication > session" that may exist between two SIP user agents and that may > pass > through one or more intermediary devices, including B2BUAs or SIP > proxies. A communication session consists of one of more SIP > transactions. A very simple communication session may be a single > out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a > SIP dialog, the SIP message exchange includes a dialog creating > INVITE transaction, and zero of more subsequent SIP transactions > within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the > existenc! e of middle boxes, there may be multiple related SIP > transactions or dialogs chained together along the path from one end > of the communication session to the other. For example: > > A Middlebox B > SIP trans1 -----------------> SIP trans 2 > SIP dialog 1 <-------------- SIP dialog 2 > > Figure 1 - Communication Session through a Middlebox > > In such cases, the two SIP transactions or dialogs are part of a > single communication session. > > The term "end-to-end" in this document means the communication > session from the point of origin, passing through any number of > intermediaries, to the ultimate point of termination. It is > recognized that legacy devices may not support the "end-to-end" > session identifier, though an identifier might be created by an > intermediary when it is absent from the session signaling. > > IMO this is a big improvement. But it still isn't as prec! ise > as I would > like. What I find lacking in the above is: > > o parsing the above, the properties of a communication session are: > - connects *two* UAs > - optionally includes one or more intermediary devices > - one or more transactions > - one out-of-dialog transaction, > OR a dialog including the dialog establishing transaction > and some transactions within the dialog. > - middle boxes may result in chaining dialogs or transactions. > > Exactly how all these properties "plug together" fuzzy. > I'm not at all certain that all readers would reach > the same conclusion about which cases meet these criteria > and which don't. > > o I'm also not certain that these criteria match all the cases > people expect, and exclude all the cases people think should > be excluded. > > - I think people expect that a conference is *not* a single > communications session. But a conference with only two > participants would! seem to qualify according to all of the > above criteria. So that suggests that another criterion is > needed to exclude that case. > > - A topologically similar case to the conference is a > click-to-dial case where a web server makes outward INVITEs > to two UAs and connects them. I think people believe this > case *should* be a communications session. > > - Another case is described in > http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html > and debated in the replies to that. Arguments are made for > different answers to what should get a common session id and what > should not. For this case I think we need to decide: > . do we mandate exactly how this should be treated? > . or do we leave it to the discretion of the B2BUA to decide? > > Either way we need to decide what the criteria are that lead > to the decision. > > o! IIRC Hadriel suggested (in a meeting?) that where media > originates and terminates has something to do with this. > That doesn't work all the time (e.g. MESSAGE), but it might help > in some cases. I think he used this to justify that: > > - the Conference Bridge Transcoding Model (RFC5369 section 3.2) > is a single communications session. > > - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not* > a single communications session. > > (I'm not convinced - this seems like a distinction without > a difference.) > > Fundamentally we should be able to classify all cases into: > - those that *should* be communications sessions, > - those that *shouldn't* be communication sessions, > - those we don't care about - could be either way. > > When we are done, we should be able to apply the definition of > communication session to any case. When applied to the cases we > explicitly care about it should deliver the an! swer we expect. > > The more weird cases we care about, the more complex and > unintuitive the > criteria will be. I suspect that the path we are on will lead to > complex > criteria. (We can have a really crisp definition of communications > session if we don't care much about which cases qualify.) > > One idea I considered is to define some new terms that build on > normal > sip concepts but extend them to allow B2BUA intermediaries where sip > allows proxies. E.g. > - Transaction++ is either a sip transaction, or a series of sip > transactions linked by B2BUA intermediaries. > > - Dialog++ is either a sip dialog, or a series of sip dialogs > linked by B2BUA intermediaries. > > Then would need to define the behavior of a B2BUA intermediary. > It needs > to relay transactions from one "side" to the other, preserving > certain > invariants (TBD). Presumably it can also originate certain > transactions, > but there must be constraints ! on what it can do. There must > also be some > rules on how media is handled across one of these intermediaries. > > If that was done, then a communication session could be defined as a > Transaction++ for an out-of-dialog request, or a Dialog++. > > But that makes the definition of communication session the first > priority and the cases that happen to qualify as a communication > session > a consequence. It probably won't match people's intuitive > feelings about > what *should* be a communication session. So it might not > satisfy people. > > Thanks, > Paul > > > On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote: > > From my point of view, the draft looks good. The > changes incorporated > > in this updated version directly address this open issue. > > Cheers, > Charles > > -----Original Message----- > From: insipid-bounces@ietf.org > [mailto:insipid-bounces@ietf.org] On > Behalf Of Gonzalo Salgueiro (gsalguei) > Sent: Thursday, January 10, 2013 12:39 PM > To: Paul E. Jones > Cc: insipid@ietf.org > Subject: Re: [Insipid] Are we ready to LC on the > requirements? > > Thanks for submitting this, Paul. The biggest open issue > in regards > to the requirements document was to clearly define what > it is we are > identifying (i.e., "communication session") within the > scope of this > document and ensure that clearly defined language is used > consistently through! out the document. Prior to any > consensus on > moving to WGLC, the chairs would appreciate hearing the > group's > thoughts on where we are on this issue in the current > version. > > Cheers, > > Gonzalo & Keith > > > > On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote: > > Folks, > > Dialog has been extremely light on the requirements > document. Do > > people feel generally OK with it as it is now? Can we > move on to the > solution document now or are there other changes needed > in the > requirements document? > > I just posted the -04 version with changes proposed > on the list over > the > > past month or so. > > 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 > ------DSS2SP7FKTBEA4RP9835A5CUN59P61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Paul,

That still begs the question of "what language do we need to add or change to make this clear?" In my mind, I know exactly what an endpoint needs to do and what an SBC needs to do. But, I'll not say it does not need more charity for those that do not have it clear in their minds.

But, perhaps being too close to the work, I'm having trouble seeing where it is vague. Can you suggest text?

Paul

From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Sent: Sun Feb 24 01:43:57 EST 2013
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: insipid@ietf.org
Subject: Re: [Insipid] Are we ready to LC on the requirements?

On 2/24/13 12:33 AM, Paul E. Jones wrote:
Paul,

So what concept is vague?

In terms of an H.323 device, I would consider two terminals with users
at each end to be a communication session. I would consider a terminal
and an MCU to have a communication session.

The collection of communication sessions on an MCU to which one or more
terrminals are a party is a conference. And I would like to relate all
those sessions by the UUID the MCU uses in each of those sessions. That
value could even be the Conference ID in H.323.

There are gateway devices that connect to the PSTN that I would count as
equal to a terminal. But, there are gateway devices that bridge IP
networks (SBCs) that shoul!
 d just
pass the UUIDs through. The difference
between the two really is whether it bridges an IPMC device to another
or to something else.

There are call flows like the one you highlighted in the threads where
voice comes from one terminal and video from another. That's an MCU,
really. The session ID exists between Alice and MCU (or PBX). The other
devices Bob uses might share the UUID of the MCU/PBX, but those are
distinct communication sessions like the typical MCU case. Yeah, such
topologies do make it hard to do debugging and the number of UUIDs makes
it a pain, too, but at least there is consistency in the assignments.
So, it is doable.

So, how can we make progress here?

We write some rules that any device that terminates more than one dialog 
can use to decide when one dialog should share a session-id with another 
dialog. The rules should get the "right" answer for all the use case!
 s, 
and should be specific enough so that when applied to any device, no 
matter how weird, most reasonable people would agree with the answer. 
That way we can have a way of judging conformance to this specification.

I realize this bridges the gap between what the requirements are 
responsible for and what the mechanism is responsible for. But the 
mechanism is about marking communications sessions, not defining them.

OR I suppose the requirements could kick the can down the road, simply 
say that the mechanism must work for the specified use cases and itself 
must specify the algorithm for making the decision in other cases. But 
that just puts it off.

 Thanks,
 Paul K

Paul




*From:* Paul Kyzivat <pkyzivat@alum.mit.edu>
*Sent:* Sat F!
 eb 23
19:58:41 EST 2013
*To:* "Paul E. Jones" <paulej@packetizer.com>
*Cc:* insipid@ietf.org
*Subject:* Re: [Insipid] Are we ready to LC on the requirements?

On 2/21/13 9:51 PM, Paul E. Jones wrote:

Paul,

I read your message, but was left unsure of exactly how we could
improve the
definition over what we have already.

If there is something concrete that you can propose that would help
lend to
clarity of the text, I'm definitely willing to put it in. I would
like to
move the requirements along and the submission deadline is Monday.
Do you
have text you would like to add before the deadline?


I'm traveling on business and have limited internet access, and limited
time, so I probably can't.

In any case, ISTM that the problem isn't that we don't have the right
words. Rather, we still don't have clear *concepts* that distinguish
!
whatshould be covered from what should not. We have some use cases, but
lack basic principles that can be applied to any case to determine if it
should be a communication session or not. It still seems to be more in
the realm of "I know one when I see it."

If we had the principles, then it would probably be straightforward to
come up with words.

I don't yet see a suitable general principle here that fits the use
cases and seems to make sense.

Thanks,
Paul

Paul

-----Original Message-----
From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: Friday, January 11, 2013 3:34 PM
To: insipid@ietf.org
Subject: Re: [Insipid] Are we ready to LC on the requirements?

(Sorry that this is long. I don't know how to make it short.)

Are we ready to LC? I don't think so. Specifically I don't think
we yet
have an
unambiguous definition of what is being identified.

This version added some new text:

In this document, the word "session" refers to a "communication
session" that may exist between two SIP user agents and that may
pass
through one or more intermediary devices, including B2BUAs or SIP
proxies. A communication session consists of one of more SIP
transactions. A very simple communication session may be a single
out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a
SIP dialog, the SIP message exchange includes a dialog creating
INVITE transaction, and zero of more subsequent SIP transactions
within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the
existenc! e of middle boxes, there may be multiple related SIP
transactions or dialogs chained together along the path from one end
of the communication session to the other. For example:

A Middlebox B
SIP trans1
-----------------> SIP trans 2
SIP dialog 1 <-------------- SIP dialog 2

Figure 1 - Communication Session through a Middlebox

In such cases, the two SIP transactions or dialogs are part of a
single communication session.

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

IMO this is a big improvement. But it still isn't as prec! ise
as I would
like. What I find lacking in the above is:

o parsing the above, the properties of a communication session are:
- connects *two* UAs
- optionally includes one or more intermediary devices
- one or more
transactions
- one out-of-dialog transaction,
OR a dialog including the dialog establishing transaction
and some transactions within the dialog.
- middle boxes may result in chaining dialogs or transactions.

Exactly how all these properties "plug together" fuzzy.
I'm not at all certain that all readers would reach
the same conclusion about which cases meet these criteria
and which don't.

o I'm also not certain that these criteria match all the cases
people expect, and exclude all the cases people think should
be excluded.

- I think people expect that a conference is *not* a single
communications session. But a conference with only two
participants would! seem to qualify according to all of the
above criteria. So that suggests that another criterion is
needed to exclude that case.

- A topologically similar case to the conference is a
click-to-dial case where a web!
  server
makes outward INVITEs
to two UAs and connects them. I think people believe this
case *should* be a communications session.

- Another case is described in
http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html
and debated in the replies to that. Arguments are made for
different answers to what should get a common session id and what
should not. For this case I think we need to decide:
. do we mandate exactly how this should be treated?
. or do we leave it to the discretion of the B2BUA to decide?

Either way we need to decide what the criteria are that lead
to the decision.

o! IIRC Hadriel suggested (in a meeting?) that where media
originates and terminates has something to do with this.
That doesn't work all the time (e.g. MESSAGE), but it might help
in some cases. I think he used this to just!
 ify
that:

- the Conference Bridge Transcoding Model (RFC5369 section 3.2)
is a single communications session.

- the 3PCC Transcoding Model (RFC5369 section 3.1) is *not*
a single communications session.

(I'm not convinced - this seems like a distinction without
a difference.)

Fundamentally we should be able to classify all cases into:
- those that *should* be communications sessions,
- those that *shouldn't* be communication sessions,
- those we don't care about - could be either way.

When we are done, we should be able to apply the definition of
communication session to any case. When applied to the cases we
explicitly care about it should deliver the an! swer we expect.

The more weird cases we care about, the more complex and
unintuitive the
criteria will be. I suspect that the path we are on will lead to
complex
criteria. (We can have a really crisp de!
 finition
of communications
session if we don't care much about which cases qualify.)

One idea I considered is to define some new terms that build on
normal
sip concepts but extend them to allow B2BUA intermediaries where sip
allows proxies. E.g.
- Transaction++ is either a sip transaction, or a series of sip
transactions linked by B2BUA intermediaries.

- Dialog++ is either a sip dialog, or a series of sip dialogs
linked by B2BUA intermediaries.

Then would need to define the behavior of a B2BUA intermediary.
It needs
to relay transactions from one "side" to the other, preserving
certain
invariants (TBD). Presumably it can also originate certain
transactions,
but there must be constraints ! on what it can do. There must
also be some
rules on how media is handled across one of these intermediaries.

If that was done, then a communication session could be defined as a
Transaction++ for an out-of-dialog request, or a Dialog++.

But that makes the definition of communication session the first
priority and the cases that happen to qualify as a communication
session
a consequence. It probably won't match people's intuitive
feelings about
what *should* be a communication session. So it might not
satisfy people.

Thanks,
Paul


On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote:

From my point of view, the draft looks good. The
changes incorporated

in this updated version directly address this open issue.

Cheers,
Charles

-----Original Message-----
From: insipid-bounces@ietf.org
[mailto:insipid-bounces@ietf.org] On
Behalf Of Gonzalo Salgueiro (gsalguei)
Sent: Thursday, January 10, 2013 12:39 PM
To: Paul E. Jones
Cc: insipid@ietf.org
Subject: Re: [Insipid] Are we ready to LC on the
requirements?

Thanks for submitting this, Paul. The biggest open issue
in regards
to the requirements document was to clearly define what
it is we are
identifying (i.e., "communication session") within the
scope of this
document and ensure that clearly defined language is used
consistently through! out the document. Prior to any
consensus on
moving to WGLC, the chairs would appreciate hearing the
group's
thoughts on where we are on this issue in the current
version.

Cheers,

Gonzalo & Keith



On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote:

Folks,

Dialog has been extremely light on the requirements
document. Do

people feel generally OK with it as it is now? Can we
move on to the
solution document now or are there other changes needed
in the
requirements document?

I just posted the -04 versi!
 on with
changes proposed
on the list over
the

past month or so.

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


------DSS2SP7FKTBEA4RP9835A5CUN59P61-- From keith.drage@alcatel-lucent.com Tue Feb 26 18:43:44 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849F421F8648 for ; Tue, 26 Feb 2013 18:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.271 X-Spam-Level: X-Spam-Status: No, score=-109.271 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iE42ZcADjQfU for ; Tue, 26 Feb 2013 18:43:44 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9C42421F8542 for ; Tue, 26 Feb 2013 18:43:34 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1R2hXim001817 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Feb 2013 03:43:33 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 27 Feb 2013 03:43:33 +0100 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Wed, 27 Feb 2013 03:43:31 +0100 Thread-Topic: Call for working group adoption of identifier solution draft Thread-Index: Ac4UlDroba7PV9ffSRu5+JxUGGPxMA== 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] Call for working group adoption of identifier 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, 27 Feb 2013 02:43:44 -0000 (As working group cochair) This is a call for the adoption of the text of the draft http://www.ietf.org/id/draft-jones-insipid-session-id-02.txt=20 as a working group draft to meet the milestone Specification of the new identifier sent to the IESG (PS) Please respond as to whether the draft is acceptable or not. You may also r= espond that certain parts are acceptable, or that parts are not acceptable = (please be specific). This is currently the only text we have on the table to meet the milestone = and there seems to be some measure of convergence on this text at the Atlan= ta meeting. We will make a decision based on the responses received by Tuesday 12th Mar= ch (i.e. Tuesday of the IETF meeting week). Regards Keith From gsalguei@cisco.com Tue Feb 26 19:05:44 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB321F8678 for ; Tue, 26 Feb 2013 19:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAnfdAtHF5L1 for ; Tue, 26 Feb 2013 19:05:43 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 925BA21F8659 for ; Tue, 26 Feb 2013 19:05:43 -0800 (PST) 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 r1R35gZ1008734 for ; Tue, 26 Feb 2013 22:05:43 -0500 (EST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1R35cmv009582; Tue, 26 Feb 2013 22:05:39 -0500 (EST) From: Gonzalo Salgueiro Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Feb 2013 22:05:38 -0500 Message-Id: <9C16CDDE-D22F-444E-80F3-1CC90DE1435C@cisco.com> To: "insipid@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "insipid-chairs@tools.ietf.org" Subject: [Insipid] Draft Agenda for INSIPID meeting at IETF86 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.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, 27 Feb 2013 03:05:44 -0000 A draft agenda for the INSIPID WG meeting at IETF 86 in Orlando is = available here: http://www.ietf.org/proceedings/86/agenda/agenda-86-insipid Feel free to bash and send feedback to the chairs = (insipid-chairs@ietf.org). Gonzalo & Keith (as co-chairs) From Internet-Drafts@ietf.org Wed Feb 27 09:00:43 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660F021F84A4; Wed, 27 Feb 2013 09:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irh1uImBdu+o; Wed, 27 Feb 2013 09:00:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA79521F8810; Wed, 27 Feb 2013 09:00:39 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40p1 Message-ID: <20130227170039.10545.59430.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2013 09:00:39 -0800 Cc: insipid@ietf.org Subject: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts-05.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:00:43 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. 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) : P. Jones, et al Filename : draft-ietf-insipid-session-id-reqts Pages : 12 Date : Feb. 27, 2013 This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-insipid-session-id-reqts-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-insipid-session-id-reqts"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-02-27090039.I-D@ietf.org> --NextPart-- From paulej@packetizer.com Wed Feb 27 10:33:37 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A948221F8901 for ; Wed, 27 Feb 2013 10:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvtSy3bIf+F9 for ; Wed, 27 Feb 2013 10:33:36 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 58AAA21F88CF for ; Wed, 27 Feb 2013 10:33:36 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r1RIXZ6T016090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Feb 2013 13:33:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1361990015; bh=5YVP8vUL/b0LkZjEEQtoVcjHHm7CPeLZxzQ8rY2SU0E=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=B1qcKUo4Uqn8gSoCa8sZpDIPSxhlTz55Q35TBSyZFfs3s/ZKZxkVRjbNTnUBfr4M7 yUYQpZUPLKTsnhhRpSQHMrH79x0Ujqrp1TtLMj17YKttH2VuatPMlFNIjowevib/6H zEpcvhiEZerLrOv/G4Xb0V+yDzU/U1mXROocUzjw= From: "Paul E. Jones" To: References: <20130227170039.10545.59430.idtracker@ietfa.amsl.com> In-Reply-To: <20130227170039.10545.59430.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2013 13:33:42 -0500 Message-ID: <011a01ce1518$f874b6c0$e95e2440$@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: AQHTNaPCYRNE2vMuarKSFaL5KFbNDZiDxZ+A Content-Language: en-us Subject: Re: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts-05.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:33:37 -0000 Folks, This is a slightly modified draft that makes an attempt to clarify further what a Communication Session is. We put the changes into the document in response to some of Paul K's comments. This may or may not be the approach we want to take, but of course welcome comments. Specifically, we added this text to Section 3: To be clear, the following are examples of acceptable communication sessions: o A call directly between two user agents o A call between two user agents with one or more SBCs in the signaling path o A call between two user agents that was initiated using third- party call control (3PCC) o A call between two user agents (e.g., Alice and Carol) that results from a different communication session (e.g., Alice and Bob) wherein one of those user agents (Alice) is transferred to another user agent (Carol) using REFER or re-INVITE The following are not considered communication sessions: o A call between any two user agents wherein two or more user agents are engaged in a conference call via a conference focus o Each call between the user agent and the conference focus would be a communication session o Each communication session is a distinct communication session o A call between three user agents (e.g., Alice, Bob, and Carol) wherein the first user agent (Alice) ad hoc conferences the other two user agents (Bob and Carol) o The call between Alice and Bob would be one communication session o The call between Alice and Carol would be a different communication session Paul > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, February 27, 2013 12:01 PM > To: i-d-announce@ietf.org > Cc: insipid@ietf.org > Subject: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts-05.txt > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > 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) : P. Jones, et al > Filename : draft-ietf-insipid-session-id-reqts > Pages : 12 > Date : Feb. 27, 2013 > > This document specifies the requirements for an end-to-end session > identifier in IP-based multimedia communication networks. This > identifier would enable endpoints, intermediate devices, and > management and monitoring systems to identify a session end-to-end > across multiple SIP devices, hops, and administrative domains. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-insipid-session-id-reqts- > 05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From keith.drage@alcatel-lucent.com Wed Feb 27 10:50:18 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4CD21F8A52 for ; Wed, 27 Feb 2013 10:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.27 X-Spam-Level: X-Spam-Status: No, score=-109.27 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPC42pZbaEmF for ; Wed, 27 Feb 2013 10:50:18 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id A469721F8A48 for ; Wed, 27 Feb 2013 10:50:17 -0800 (PST) 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 r1RIo20D007576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 27 Feb 2013 19:50:14 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 27 Feb 2013 19:50:14 +0100 From: "DRAGE, Keith (Keith)" To: "insipid@ietf.org" Date: Wed, 27 Feb 2013 19:47:50 +0100 Thread-Topic: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts-05.txt Thread-Index: AQHTNaPCYRNE2vMuarKSFaL5KFbNDZiDxZ+AgAAEJcA= Message-ID: References: <20130227170039.10545.59430.idtracker@ietfa.amsl.com> <011a01ce1518$f874b6c0$e95e2440$@packetizer.com> In-Reply-To: <011a01ce1518$f874b6c0$e95e2440$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts-05.txt X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:50:18 -0000 (As WG cochair) We had some significant comments on the terminology definitions raised in A= tlanta, i.e. that the requirements document needed to define certain concep= ts, and that it had done this. I would like to ask the working group, and in particular those who commente= d in Atlanta, as to whether the current version addresses those comments or= whether more work is required.=20 Robert and Gonzalo in particular. Suggestions for improvements will always be welcome. Regards Keith > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behal= f > Of Paul E. Jones > Sent: 27 February 2013 18:34 > To: insipid@ietf.org > Subject: Re: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts- > 05.txt >=20 > Folks, >=20 > This is a slightly modified draft that makes an attempt to clarify furthe= r > what a Communication Session is. We put the changes into the document in > response to some of Paul K's comments. This may or may not be the > approach > we want to take, but of course welcome comments. >=20 > Specifically, we added this text to Section 3: >=20 > To be clear, the following are > examples of acceptable communication sessions: >=20 > o A call directly between two user agents >=20 > o A call between two user agents with one or more SBCs in the > signaling path >=20 > o A call between two user agents that was initiated using third- > party call control (3PCC) >=20 > o A call between two user agents (e.g., Alice and Carol) that > results from a different communication session (e.g., Alice and > Bob) wherein one of those user agents (Alice) is transferred to > another user agent (Carol) using REFER or re-INVITE >=20 > The following are not considered communication sessions: >=20 > o A call between any two user agents wherein two or more user > agents are engaged in a conference call via a conference focus >=20 > o Each call between the user agent and the conference focus > would be a communication session >=20 > o Each communication session is a distinct communication > session >=20 > o A call between three user agents (e.g., Alice, Bob, and Carol) > wherein the first user agent (Alice) ad hoc conferences the > other two user agents (Bob and Carol) >=20 > o The call between Alice and Bob would be one communication > session >=20 > o The call between Alice and Carol would be a different > communication session >=20 > Paul >=20 > > -----Original Message----- > > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > > Behalf Of Internet-Drafts@ietf.org > > Sent: Wednesday, February 27, 2013 12:01 PM > > To: i-d-announce@ietf.org > > Cc: insipid@ietf.org > > Subject: [Insipid] I-D ACTION:draft-ietf-insipid-session-id-reqts-05.tx= t > > > > A new Internet-Draft is available from the on-line Internet-Drafts > > directories. > > 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) : P. Jones, et al > > Filename : draft-ietf-insipid-session-id-reqts > > Pages : 12 > > Date : Feb. 27, 2013 > > > > This document specifies the requirements for an end-to-end session > > identifier in IP-based multimedia communication networks. This > > identifier would enable endpoints, intermediate devices, and > > management and monitoring systems to identify a session end-to-end > > across multiple SIP devices, hops, and administrative domains. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-insipid-session-id-reqts= - > > 05.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid