From paulej@packetizer.com Sun Dec 2 14:08:49 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F19F21F88C4 for ; Sun, 2 Dec 2012 14:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+ymV8QQnzrL for ; Sun, 2 Dec 2012 14:08:48 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F2B6421F88BF for ; Sun, 2 Dec 2012 14:08:47 -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 qB2M8kG8004491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 2 Dec 2012 17:08:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1354486127; bh=opdD08FFp3K/zsm5K7hHcYnrUh9SZyPEtNvqFBQmNxg=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ZLYpF96qPN2+L0fztoQeCQux1eyw+z568eCH5gMzoE5RsU1l0UOlJ82GI19Eke17T TCk0NpdIDkNRWZp+Lp3hFF3xFZbsW0oZ3sFtrcpbLidc6KaCbXjyzuiXjaNbqLAqsB fbbpJapc4jtQK7/3XxP0XYsbdaq87DgGELqg+ozc= From: "Paul E. Jones" To: References: <00cb01cdc818$93b3b210$bb1b1630$@packetizer.com> In-Reply-To: <00cb01cdc818$93b3b210$bb1b1630$@packetizer.com> Date: Sun, 2 Dec 2012 17:08:45 -0500 Message-ID: <07fc01cdd0d9$99291720$cb7b4560$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07FD_01CDD0AF.B053D270" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIFmswRwJsUgQ8TVwmpYt3k1EUZCZeWfX3w Content-Language: en-us Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 22:08:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07FD_01CDD0AF.B053D270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, Any comments on this revised requirements document? Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, November 21, 2012 1:47 PM To: insipid@ietf.org Subject: [Insipid] draft-ietf-insipid-session-id-reqts-03 Folks, I've posted a new -03 version of the requirements draft. Please note that I did not change the wording related to "communication session", yet. However, what was changed is: . Removed sections marked as "DELETED" . Re-numbered all requirements so they are consecutive . Minor editorial changes . Changes to REQ8 and corresponding section 3.6 that removes language related to RTCP with language relating to syntax; please be sure to look at that text . Removed last sentence from REQ2 . Wording change on REQ3 . At the AD's request, I moved some authors to a new "Contributors" section Comments welcome, though note it is a holiday here in the US Thursday and Friday, so I apologize if my responses are slow. Paul ------=_NextPart_000_07FD_01CDD0AF.B053D270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Any comments on this = revised requirements document?

 

Paul

 

From:= = insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones
Sent: Wednesday, November 21, 2012 1:47 = PM
To: insipid@ietf.org
Subject: [Insipid] = draft-ietf-insipid-session-id-reqts-03

<= p class=3DMsoNormal> 

Folks,

 

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

·         = Removed sections marked as = “DELETED”

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

·         = Minor editorial changes

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

·         = Removed last sentence from = REQ2

·         = Wording change on REQ3

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

 

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

 

Paul

 

------=_NextPart_000_07FD_01CDD0AF.B053D270-- From ietf-ipr@ietf.org Thu Dec 6 09:20:36 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25CF21F87F3; Thu, 6 Dec 2012 09:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 QRCljnkXmGXJ; Thu, 6 Dec 2012 09:20:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DCA21F87D2; Thu, 6 Dec 2012 09:20:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: paulej@packetizer.com, gsalguei@cisco.com, jmpolk@cisco.com, laura.liess.dt@gmail.com, hkaplan@acmepacket.com X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121206172036.16095.26296.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 09:20:36 -0800 X-Mailman-Approved-At: Thu, 06 Dec 2012 09:30:45 -0800 Cc: keith.drage@alcatel-lucent.com, gsalguei@cisco.com, gonzalo.camarillo@ericsson.com, insipid@ietf.org, ipr-announce@ietf.org, rjsparks@nostrum.com Subject: [Insipid] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-insipid-session-id-reqts-03 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:20:37 -0000 Dear Paul Jones, Gonzalo Salgueiro, James M. Polk, Laura Liess, Hadriel Kap= lan: An IPR disclosure that pertains to your Internet-Draft entitled "Requireme= nts for an End-to-End Session Identification in IP-Based Multimedia Communicati= on Networks" (draft-ietf-insipid-session-id-reqts) was submitted to the IETF Secretariat on 2012-12-06 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1925/). The = title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-insipid-session-id-reqts-03.""); The IETF Secretariat From eckelcu@cisco.com Mon Dec 17 12:48:44 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70421F8773 for ; Mon, 17 Dec 2012 12:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DlkDw7-X0gtW for ; Mon, 17 Dec 2012 12:48:43 -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 ACCCB21F850D for ; Mon, 17 Dec 2012 12:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4671; q=dns/txt; s=iport; t=1355777323; x=1356986923; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xeCAw2SLIHhhdojFr25w4vU6jnPmPGuc8Kqq5GR1WEM=; b=VK/p+twUCI+xm4+Uj4f0KjbYqHSNw/2W1hWa/a7oQUs2bHt3MlQXa0DN 1vncGSSSXV5GsxVRnexYiZVa/IqZCif7Qz5n/5QFtSbPt0j2zGFHbhUt9 uBDBnVOTlGLmjoFd8CgCpoIBFEjGFlg802aP+8WIOP090hsG/ItxnbuVG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACSEz1CtJXG8/2dsb2JhbAA7CgG+JhZzgh4BAQEEJxNLBAIBCBEEAQELFAkHMhQJCAEBBAESCIgKAQy6GIxdEYNRYQOXJo8sgnOCIg X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208";a="153909803" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 17 Dec 2012 20:48:43 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBHKmh3P018197 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 20:48:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 14:48:42 -0600 From: "Charles Eckel (eckelcu)" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: Communication Session Thread-Index: Ac3HsSorT1HX9tYVQyqDerYvSCdnSAU5e81w Date: Mon, 17 Dec 2012 20:48:42 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046ED09F@xmb-aln-x08.cisco.com> References: <002601cdc7b4$3b494270$b1dbc750$@packetizer.com> In-Reply-To: <002601cdc7b4$3b494270$b1dbc750$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Communication Session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:48:44 -0000 Hi Paul, How about we keep the name communication-session , but expand on the defini= tion to incorporate my proposal? For example: In this document, the word "session" refers to a "communication session" th= at may exist between two SIP user agents and that may pass through one or m= ore intermediary devices, including B2BUAs or SIP Proxies. A communication = session consists of one of more SIP transactions. A very simple communicati= on 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 c= reating INVITE transaction, and zero of more subsequent SIP transactions w= ithin the same dialog (e.g. ACK, re-INVITE, BYE). Due to the existence of m= iddle boxes, there may be multiple related SIP transactions or dialogs chai= ned together along the path from one end of the communication session to th= e other. For example: A -------middlebox--------B SIP trans1 -----> SIP trans 2 SIP dialog 1 ---> SIP dialog 2 In such cases, the two SIP transactions or dialogs are part of a single com= munication session. Cheers, Charles > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, November 20, 2012 10:49 PM > To: insipid@ietf.org > Cc: Charles Eckel (eckelcu) > Subject: Communication Session >=20 > Folks, >=20 >=20 >=20 > I said I will publish a new revision of the requirements document. I hav= e a > list of things on my list, but I may have neglected a few items. If you = can > think of an important change you wanted made to the requirements draft, > let me know. >=20 >=20 >=20 > One thing that was discussed and for which I don't have an answer is that= of > "communication session" vs. something else. The requirements document > currently says: >=20 >=20 >=20 > In this document, the word "session" refers to a "communication session" > that may exist between two SIP user agents or that might pass through one > or more intermediary devices, including B2BUAs or SIP Proxies. >=20 >=20 >=20 > The term "end-to-end" in this document means the communication session > from the point of origin, passing through any number of intermediaries, t= o > the ultimate point of termination. It is recognized that legacy devices m= ay > not support the "end-to-end" session identifier, though an identifier mig= ht > be created by an intermediary when it is absent from the session signalin= g. >=20 >=20 >=20 > There was a desire for changes in terminology. Specifically what, though= ? > Please look at the terminology in the current draft and let's discuss wha= t > changes to make: >=20 > http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02 >=20 >=20 >=20 > I'm not so confident that we'll have a quick answer, so what I might do i= s go > ahead and publish an -03 with what other changes I believe folks wanted > (and any I get between now and tomorrow evening). Don't take that > publication as ignoring this point. We can work on revising the terminol= ogy > even after the next version. >=20 >=20 >=20 > Charles Eckel proposed (on Nov. 3) to replace the words "communication > session" with "SIP message exchange". Paul Kyzivat seemed to think that > might work, but I didn't see others comment. Looking at the proposal, I'= m > having trouble seeing how I'd use the term in these sentences: >=20 > * "The identifier is intended to represents an end-to-end > communication session from the originating device to the terminating > device" >=20 > * "if a PBX joins or merges two communication sessions together l= ocally, > the end-to-end properties of currently-defined identifiers are lost" >=20 > * "we need the ability to identify each communication session thr= ough a > single SIP header-value regardless of which type of SIP servers" >=20 > * "A communication session might originate in an H.323 endpoint a= nd > pass through a Session Border Controller before ultimately reaching a > terminating SIP user agent" >=20 > * Etc. >=20 >=20 >=20 > The sentence with H.323 mentioned is a bit tricky and extends the term to > non-SIP signaling. Still, we do want to cover that case and the intent > certainly was that a "communication session" is one that s >=20 >=20 >=20 > Personally, I like the term "communication session", but perhaps we just > need to modify it along the lines of what Charles suggested? Can folks o= ffer > a good replacement definition to put in Section 2? >=20 >=20 >=20 > Paul >=20 >=20 From eckelcu@cisco.com Mon Dec 17 13:18:53 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B536621F8711 for ; Mon, 17 Dec 2012 13:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.529 X-Spam-Level: X-Spam-Status: No, score=-10.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5NsVlNKTlyY for ; Mon, 17 Dec 2012 13:18:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B421F86FC for ; Mon, 17 Dec 2012 13:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15609; q=dns/txt; s=iport; t=1355779132; x=1356988732; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=A29JekdwjWK0YK/R9h26/oYwc6wkh4MS4fIWYRY8C3k=; b=EBOPIxdCun4UGenehueu3uPJ1RVNvMLBArgjghWL6ws/0/J0q+Uh4RAW HbtuvLIzpAziOM8MJYdXPF3cPKChqXbzZ9NJDgNuFiuchR8WXKjz0tTEd nmQy/pDp862jVmFIq+XjNw7TdOVgKl/szL/ou+ZHCV7Ni2lWFUps6p/MO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFOLz1CtJV2c/2dsb2JhbABFgkm7XhZzgh4BAQEELVwCAQgRBAEBCx0HMhQJCAEBBAESCBOHdwG6LYxdg2JhA6ZSgnOCIg X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208,217";a="153920398" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 17 Dec 2012 21:18:51 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBHLIphw030797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 21:18:51 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 15:18:51 -0600 From: "Charles Eckel (eckelcu)" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-reqts-03 Thread-Index: Ac3IF8bpueH+iTehRLCeLtn7ExVWiwI9BxGAAuNPtdA= Date: Mon, 17 Dec 2012 21:18:50 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EE0ED@xmb-aln-x08.cisco.com> References: <00cb01cdc818$93b3b210$bb1b1630$@packetizer.com> <07fc01cdd0d9$99291720$cb7b4560$@packetizer.com> In-Reply-To: <07fc01cdd0d9$99291720$cb7b4560$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: multipart/alternative; boundary="_000_92B7E61ADAC1BB4F941F943788C08828046EE0EDxmbalnx08ciscoc_" MIME-Version: 1.0 Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:18:53 -0000 --_000_92B7E61ADAC1BB4F941F943788C08828046EE0EDxmbalnx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Section 3.4 s/one side at a time, through until completion /one side at a time, until c= ompletion Section 3.7 s/ in section 4.1 of RFC 3725 the flow for which/in section 4.1 of RFC 3725= , the flow for which And add a cross reference to RFC 3725. Section 4, REQ2 has an extra " ." at the end. REQ3 seems problematic to me. It reads: The solution must require that the identifier pass unchanged through SIP B2BUAs or other intermediaries. I believe we discussed some scenarios in which a B2BUA might actually add s= omething to a session-id on behalf of an entity that did not add one itself= . That seems to conflict with this requirement. Either I recall the convers= ions at IETF 85 incorrectly, or we need to change this requirement. Ah, I j= ust read REQ5, so REQ3 needs to change or be combined with REQ5. Cheers, Charles From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul E. Jones Sent: Sunday, December 02, 2012 2:09 PM To: insipid@ietf.org Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 Folks, Any comments on this revised requirements document? Paul From: insipid-bounces@ietf.org [mailto:ins= ipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, November 21, 2012 1:47 PM To: insipid@ietf.org Subject: [Insipid] draft-ietf-insipid-session-id-reqts-03 Folks, I've posted a new -03 version of the requirements draft. Please note that = I did not change the wording related to "communication session", yet. Howe= ver, what was changed is: * Removed sections marked as "DELETED" * Re-numbered all requirements so they are consecutive * Minor editorial changes * Changes to REQ8 and corresponding section 3.6 that removes langua= ge related to RTCP with language relating to syntax; please be sure to look= at that text * Removed last sentence from REQ2 * Wording change on REQ3 * At the AD's request, I moved some authors to a new "Contributors"= section Comments welcome, though note it is a holiday here in the US Thursday and F= riday, so I apologize if my responses are slow. Paul --_000_92B7E61ADAC1BB4F941F943788C08828046EE0EDxmbalnx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

Section 3.4=

s/one side at a time, = through until completion /one side at a time, until completion

 

Section 3.7=

s/ in section 4.1 of RFC 3725 the flow for which/in section 4.1 of RFC 3725, t= he flow for which

And add a cross refere= nce to RFC 3725.

 

Section 4,<= /span>

REQ2 has an extra R= 20; .” at the end.

REQ3 seems problematic= to me. It reads:

   The solut= ion must require that the identifier pass unchanged

   through S= IP B2BUAs or other intermediaries.

I believe we discussed= some scenarios in which a B2BUA might actually add something to a session-= id on behalf of an entity that did not add one itself. That seems to confli= ct with this requirement. Either I recall the conversions at IETF 85 incorrectly, or we need to change this requirem= ent. Ah, I just read REQ5, so REQ3 needs to change or be combined with REQ5= .

 

Cheers,

Charles

 

From: insipid-= bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Sunday, December 02, 2012 2:09 PM
To: insipid@ietf.org
Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03

 

Folks,

 

Any comments on this r= evised requirements document?

 

Paul=

 

From: insipid-bounces@ietf.org [<= a href=3D"mailto:insipid-bounces@ietf.org">mailto:insipid-bounces@ietf.org<= /a>] On Behalf Of Paul E. Jones
Sent: Wednesday, November 21, 2012 1:47 PM
To: insipid@ietf.org
Subject: [Insipid] draft-ietf-insipid-session-id-reqts-03=

 

Folks,

 

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

·         Removed sections marked as “DELETED= 221;

·         Re-numbered all requirements so they are con= secutive

·         Minor editorial changes

·         Changes to REQ8 and corresponding section 3.= 6 that removes language related to RTCP with language relating to syntax; p= lease be sure to look at that text

·         Removed last sentence from REQ2

·         Wording change on REQ3

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

 

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

 

Paul

 

--_000_92B7E61ADAC1BB4F941F943788C08828046EE0EDxmbalnx08ciscoc_-- From paulej@packetizer.com Mon Dec 17 19:41:31 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8940821E8041 for ; Mon, 17 Dec 2012 19:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNuz3of1-iXv for ; Mon, 17 Dec 2012 19:41:30 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8D121E8055 for ; Mon, 17 Dec 2012 19:41:30 -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 qBI3fRAu028998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 22:41:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355802087; bh=Vgl2mSqggr5r/9d/I9eSAMgLy8nkqaosnXjw7dhvgb0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RZFAJimmqy70K86ZMtjTDNOu6dHKx+VzoRTqdgdAn3m7asniyZWhj35OY2/P/krtk kLNAdCb2EeAGO96Yus+m7qff1638KEROdgh/7apjsTaljgEOXHqh/+nNWTJkhgNWbV oOVXTR+XT4oxapaNL44mEjYT9ZB24BWwUWYh/p88= From: "Paul E. Jones" To: "'Charles Eckel \(eckelcu\)'" , References: <002601cdc7b4$3b494270$b1dbc750$@packetizer.com> <92B7E61ADAC1BB4F941F943788C08828046ED09F@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046ED09F@xmb-aln-x08.cisco.com> Date: Mon, 17 Dec 2012 22:41:30 -0500 Message-ID: <002f01cddcd1$91540290$b3fc07b0$@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: AQGc0PBHXDmpbr26zyWZe+A2hg2ROgLJ7qXTmGmxiTA= Content-Language: en-us Subject: Re: [Insipid] Communication Session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:41:31 -0000 Charles, This sounds great to me. Do others like this? What about the following paragraph? The term "end-to-end" in this document means the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It is recognized that legacy devices may not support the "end-to-end" session identifier, though an identifier might be created by an intermediary when it is absent from the session signaling. Paul > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: Monday, December 17, 2012 3:49 PM > To: Paul E. Jones; insipid@ietf.org > Subject: RE: Communication Session > > Hi Paul, > > How about we keep the name communication-session , but expand on the > definition to incorporate my proposal? For example: > > 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 > > In such cases, the two SIP transactions or dialogs are part of a single > communication session. > > Cheers, > Charles > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > Sent: Tuesday, November 20, 2012 10:49 PM > > To: insipid@ietf.org > > Cc: Charles Eckel (eckelcu) > > Subject: Communication Session > > > > Folks, > > > > > > > > I said I will publish a new revision of the requirements document. I > > have a list of things on my list, but I may have neglected a few > > items. If you can think of an important change you wanted made to the > > requirements draft, let me know. > > > > > > > > One thing that was discussed and for which I don't have an answer is > > that of "communication session" vs. something else. The requirements > > document currently says: > > > > > > > > In this document, the word "session" refers to a "communication > session" > > that may exist between two SIP user agents or that might pass through > > one or more intermediary devices, including B2BUAs or SIP Proxies. > > > > > > > > The term "end-to-end" in this document means the communication session > > from the point of origin, passing through any number of > > intermediaries, to the ultimate point of termination. It is recognized > > that legacy devices may not support the "end-to-end" session > > identifier, though an identifier might be created by an intermediary > when it is absent from the session signaling. > > > > > > > > There was a desire for changes in terminology. Specifically what, > though? > > Please look at the terminology in the current draft and let's discuss > > what changes to make: > > > > http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02 > > > > > > > > I'm not so confident that we'll have a quick answer, so what I might > > do is go ahead and publish an -03 with what other changes I believe > > folks wanted (and any I get between now and tomorrow evening). Don't > > take that publication as ignoring this point. We can work on revising > > the terminology even after the next version. > > > > > > > > Charles Eckel proposed (on Nov. 3) to replace the words "communication > > session" with "SIP message exchange". Paul Kyzivat seemed to think > > that might work, but I didn't see others comment. Looking at the > > proposal, I'm having trouble seeing how I'd use the term in these > sentences: > > > > * "The identifier is intended to represents an end-to-end > > communication session from the originating device to the terminating > > device" > > > > * "if a PBX joins or merges two communication sessions > together locally, > > the end-to-end properties of currently-defined identifiers are lost" > > > > * "we need the ability to identify each communication session > through a > > single SIP header-value regardless of which type of SIP servers" > > > > * "A communication session might originate in an H.323 > endpoint and > > pass through a Session Border Controller before ultimately reaching a > > terminating SIP user agent" > > > > * Etc. > > > > > > > > The sentence with H.323 mentioned is a bit tricky and extends the term > > to non-SIP signaling. Still, we do want to cover that case and the > > intent certainly was that a "communication session" is one that s > > > > > > > > Personally, I like the term "communication session", but perhaps we > > just need to modify it along the lines of what Charles suggested? Can > > folks offer a good replacement definition to put in Section 2? > > > > > > > > Paul > > > > From paulej@packetizer.com Mon Dec 17 19:46:57 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B704821E8040 for ; Mon, 17 Dec 2012 19:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dIE09igSZyW for ; Mon, 17 Dec 2012 19:46:55 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB9921E8039 for ; Mon, 17 Dec 2012 19:46:55 -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 qBI3krep029227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 22:46:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1355802414; bh=Uf1c0WUzghKpnEYgi+6AZUZLWKNd4jUPO1SY04Mrc4M=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=PvrsDdNJI7pnJcQzhvrC41HlrK/M7TZAiWia835rOmpKcHN/N5R27maBWSYhDT96D zUQCaJ4+VYMAQpnI/KMXxnSRz9BnjdFdsL1G5rcULqO3QKUEUZmug1rLmo9HrfhZuw HGiKgCaDLwZOsIAi76QUyAVQtyCMHKAkyP4jdVdI= From: "Paul E. Jones" To: "'Charles Eckel \(eckelcu\)'" , References: <00cb01cdc818$93b3b210$bb1b1630$@packetizer.com> <07fc01cdd0d9$99291720$cb7b4560$@packetizer.com> <92B7E61ADAC1BB4F941F943788C08828046EE0ED@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828046EE0ED@xmb-aln-x08.cisco.com> Date: Mon, 17 Dec 2012 22:46:56 -0500 Message-ID: <003101cddcd2$53d519d0$fb7f4d70$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CDDCA8.6B007160" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIFmswRwJsUgQ8TVwmpYt3k1EUZCQF8cnVBAVpvlDCXl7eKYA== Content-Language: en-us Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 03:46:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0032_01CDDCA8.6B007160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Charles, Thanks for reviewing the text! For REQ3, how about this: The solution must require that the identifier, if present, pass unchanged through SIP B2BUAs or other intermediaries. REQ3 and REQ5 are focused on two requirements, so I'd like to keep them separate if possible. Paul From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: Monday, December 17, 2012 4:19 PM To: Paul E. Jones; insipid@ietf.org Subject: RE: [Insipid] draft-ietf-insipid-session-id-reqts-03 Hi Paul, Section 3.4 s/one side at a time, through until completion /one side at a time, until completion Section 3.7 s/ in section 4.1 of RFC 3725 the flow for which/in section 4.1 of RFC 3725, the flow for which And add a cross reference to RFC 3725. Section 4, REQ2 has an extra " ." at the end. REQ3 seems problematic to me. It reads: The solution must require that the identifier pass unchanged through SIP B2BUAs or other intermediaries. I believe we discussed some scenarios in which a B2BUA might actually add something to a session-id on behalf of an entity that did not add one itself. That seems to conflict with this requirement. Either I recall the conversions at IETF 85 incorrectly, or we need to change this requirement. Ah, I just read REQ5, so REQ3 needs to change or be combined with REQ5. Cheers, Charles From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Sunday, December 02, 2012 2:09 PM To: insipid@ietf.org Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 Folks, Any comments on this revised requirements document? Paul From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, November 21, 2012 1:47 PM To: insipid@ietf.org Subject: [Insipid] draft-ietf-insipid-session-id-reqts-03 Folks, I've posted a new -03 version of the requirements draft. Please note that I did not change the wording related to "communication session", yet. However, what was changed is: . Removed sections marked as "DELETED" . Re-numbered all requirements so they are consecutive . Minor editorial changes . Changes to REQ8 and corresponding section 3.6 that removes language related to RTCP with language relating to syntax; please be sure to look at that text . Removed last sentence from REQ2 . Wording change on REQ3 . At the AD's request, I moved some authors to a new "Contributors" section Comments welcome, though note it is a holiday here in the US Thursday and Friday, so I apologize if my responses are slow. Paul ------=_NextPart_000_0032_01CDDCA8.6B007160 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Charles,

 

Thanks for reviewing the = text!

 

For REQ3, how about = this:

 

The solution must = require that the identifier, if present, pass unchanged through = SIP B2BUAs or other intermediaries.

 

REQ3 and REQ5 are = focused on two requirements, so I’d like to keep them separate if = possible.

 

Paul

 

From:= = Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: = Monday, December 17, 2012 4:19 PM
To: Paul E. Jones; = insipid@ietf.org
Subject: RE: [Insipid] = draft-ietf-insipid-session-id-reqts-03

<= p class=3DMsoNormal> 

Hi Paul,

 

Section = 3.4

s/one side at a time, through until completion = /one side at a time, until completion

 

Section = 3.7

s/ in = section 4.1 of RFC 3725 the flow for which/in section 4.1 of RFC 3725, = the flow for which

And add a cross reference to RFC = 3725.

 

Section = 4,

REQ2 has an extra “ .” at the = end.

REQ3 seems problematic to me. It = reads:

   The solution must require that the = identifier pass unchanged

   through SIP = B2BUAs or other intermediaries.

I believe we discussed = some scenarios in which a B2BUA might actually add something to a = session-id on behalf of an entity that did not add one itself. That = seems to conflict with this requirement. Either I recall the conversions = at IETF 85 incorrectly, or we need to change this requirement. Ah, I = just read REQ5, so REQ3 needs to change or be combined with = REQ5.

 

Cheers,

Charles

 

<= p class=3DMsoNormal> 

Folks,

 

Any comments on this = revised requirements document?

 

Paul

 

<= p class=3DMsoNormal> 

Folks,

 

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

·         = Removed sections marked as = “DELETED”

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

·         = Minor editorial changes

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

·         = Removed last sentence from = REQ2

·         = Wording change on REQ3

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

 

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

 

Paul

 

------=_NextPart_000_0032_01CDDCA8.6B007160-- From eckelcu@cisco.com Tue Dec 18 08:36:42 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C021F8A78 for ; Tue, 18 Dec 2012 08:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 fmUrRtDSSqjx for ; Tue, 18 Dec 2012 08:36:41 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0518921F8A5D for ; Tue, 18 Dec 2012 08:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6092; q=dns/txt; s=iport; t=1355848601; x=1357058201; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rVFI04ZWAdZ/4u0RoNTyCCS/El/gV/Xobw9WQ6c0/xU=; b=Vv+wnbK7pnVkBKzxa8NSb0cZ5Z2JcyIP2MylbUQbUMpACtxbeyf1ilUL u/uxXlSjtXoUCIISf2y1DpvoMHbQBZc/yjXLSPJhlrA0bRoOe3C4CvxgX QATFNAA3U2gKvckO6Vb7F1OzlfMGNAuYmHRuqN2H8Vu1uJlj+kVuOq8m6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEea0FCtJXG8/2dsb2JhbAA7CgG+KBZzgh4BAQEEJxNLBAIBCBEEAQELFAkHMhQJCAEBBAESCIgKAQyoHJBAjEkRg1FhA5cmjyyCc4Ii X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208";a="154243610" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 18 Dec 2012 16:36:40 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBIGaeab015486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 16:36:40 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 10:36:40 -0600 From: "Charles Eckel (eckelcu)" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: Communication Session Thread-Index: Ac3HsSorT1HX9tYVQyqDerYvSCdnSAU5e81wABswhQAADmjOIA== Date: Tue, 18 Dec 2012 16:36:39 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EE458@xmb-aln-x08.cisco.com> References: <002601cdc7b4$3b494270$b1dbc750$@packetizer.com> <92B7E61ADAC1BB4F941F943788C08828046ED09F@xmb-aln-x08.cisco.com> <002f01cddcd1$91540290$b3fc07b0$@packetizer.com> In-Reply-To: <002f01cddcd1$91540290$b3fc07b0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] Communication Session X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:36:42 -0000 Hi Paul, Your definition for end-to-end looks okay to me. Cheers, Charles > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Monday, December 17, 2012 7:42 PM > To: Charles Eckel (eckelcu); insipid@ietf.org > Subject: RE: Communication Session >=20 > Charles, >=20 > This sounds great to me. Do others like this? >=20 > What about the following paragraph? >=20 > 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 n= ot > support the "end-to-end" session identifier, though an identifier might b= e > created by an intermediary when it is absent from the session signaling. >=20 > Paul >=20 > > -----Original Message----- > > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > > Sent: Monday, December 17, 2012 3:49 PM > > To: Paul E. Jones; insipid@ietf.org > > Subject: RE: Communication Session > > > > Hi Paul, > > > > How about we keep the name communication-session , but expand on the > > definition to incorporate my proposal? For example: > > > > 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 b= e > > 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 > > > > In such cases, the two SIP transactions or dialogs are part of a single > > communication session. > > > > Cheers, > > Charles > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@packetizer.com] > > > Sent: Tuesday, November 20, 2012 10:49 PM > > > To: insipid@ietf.org > > > Cc: Charles Eckel (eckelcu) > > > Subject: Communication Session > > > > > > Folks, > > > > > > > > > > > > I said I will publish a new revision of the requirements document. I > > > have a list of things on my list, but I may have neglected a few > > > items. If you can think of an important change you wanted made to th= e > > > requirements draft, let me know. > > > > > > > > > > > > One thing that was discussed and for which I don't have an answer is > > > that of "communication session" vs. something else. The requirements > > > document currently says: > > > > > > > > > > > > In this document, the word "session" refers to a "communication > > session" > > > that may exist between two SIP user agents or that might pass through > > > one or more intermediary devices, including B2BUAs or SIP Proxies. > > > > > > > > > > > > The term "end-to-end" in this document means the communication > session > > > from the point of origin, passing through any number of > > > intermediaries, to the ultimate point of termination. It is recognize= d > > > that legacy devices may not support the "end-to-end" session > > > identifier, though an identifier might be created by an intermediary > > when it is absent from the session signaling. > > > > > > > > > > > > There was a desire for changes in terminology. Specifically what, > > though? > > > Please look at the terminology in the current draft and let's discuss > > > what changes to make: > > > > > > http://tools.ietf.org/html/draft-ietf-insipid-session-id-reqts-02 > > > > > > > > > > > > I'm not so confident that we'll have a quick answer, so what I might > > > do is go ahead and publish an -03 with what other changes I believe > > > folks wanted (and any I get between now and tomorrow evening). Don't > > > take that publication as ignoring this point. We can work on revisin= g > > > the terminology even after the next version. > > > > > > > > > > > > Charles Eckel proposed (on Nov. 3) to replace the words "communicatio= n > > > session" with "SIP message exchange". Paul Kyzivat seemed to think > > > that might work, but I didn't see others comment. Looking at the > > > proposal, I'm having trouble seeing how I'd use the term in these > > sentences: > > > > > > * "The identifier is intended to represents an end-to-end > > > communication session from the originating device to the terminating > > > device" > > > > > > * "if a PBX joins or merges two communication sessions > > together locally, > > > the end-to-end properties of currently-defined identifiers are lost" > > > > > > * "we need the ability to identify each communication session > > through a > > > single SIP header-value regardless of which type of SIP servers" > > > > > > * "A communication session might originate in an H.323 > > endpoint and > > > pass through a Session Border Controller before ultimately reaching a > > > terminating SIP user agent" > > > > > > * Etc. > > > > > > > > > > > > The sentence with H.323 mentioned is a bit tricky and extends the ter= m > > > to non-SIP signaling. Still, we do want to cover that case and the > > > intent certainly was that a "communication session" is one that s > > > > > > > > > > > > Personally, I like the term "communication session", but perhaps we > > > just need to modify it along the lines of what Charles suggested? Ca= n > > > folks offer a good replacement definition to put in Section 2? > > > > > > > > > > > > Paul > > > > > > >=20 From eckelcu@cisco.com Tue Dec 18 08:37:54 2012 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A5F21F8A94 for ; Tue, 18 Dec 2012 08:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 hIZuOg1RGPWg for ; Tue, 18 Dec 2012 08:37:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C44C521F8A70 for ; Tue, 18 Dec 2012 08:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3541; q=dns/txt; s=iport; t=1355848664; x=1357058264; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5De0lZSTCDwroVZlUfSv/i1EhAPZSS2TIcGoBsB5apA=; b=U75exymB4Ry8GIGIuRT9olSc0/0i17UuFX7HtFPfoQRyKFCNmi625Rc0 4EvFRlv6kd0Q6rhSMC6+4xV5o7hyAh80c6MCq793kFLnwoOZPz3feVMJs mu8FZLws/+2f8h1jUXAL53A0+RHwYJdyp0suLmXkOatMGYhDwtVS75rD7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPOa0FCtJXHA/2dsb2JhbABFvikWc4IeAQEBBDpLBAIBCBEEAQELFAkHMhQJCAEBBAESCBOHdwGoJpBAjEmDYmEDplKCc4Ii X-IronPort-AV: E=Sophos;i="4.84,309,1355097600"; d="scan'208";a="154243761" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 18 Dec 2012 16:37:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBIGbhuU019827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 16:37:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.169]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 10:37:43 -0600 From: "Charles Eckel (eckelcu)" To: "Paul E. Jones" , "insipid@ietf.org" Thread-Topic: [Insipid] draft-ietf-insipid-session-id-reqts-03 Thread-Index: Ac3IF8bpueH+iTehRLCeLtn7ExVWiwI9BxGAAuNPtdAAGt7wAAAOVcHQ Date: Tue, 18 Dec 2012 16:37:42 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828046EE469@xmb-aln-x08.cisco.com> References: <00cb01cdc818$93b3b210$bb1b1630$@packetizer.com> <07fc01cdd0d9$99291720$cb7b4560$@packetizer.com> <92B7E61ADAC1BB4F941F943788C08828046EE0ED@xmb-aln-x08.cisco.com> <003101cddcd2$53d519d0$fb7f4d70$@packetizer.com> In-Reply-To: <003101cddcd2$53d519d0$fb7f4d70$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 16:37:54 -0000 Works for me. Thanks, Charles > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Monday, December 17, 2012 7:47 PM > To: Charles Eckel (eckelcu); insipid@ietf.org > Subject: RE: [Insipid] draft-ietf-insipid-session-id-reqts-03 >=20 > Charles, >=20 >=20 >=20 > Thanks for reviewing the text! >=20 >=20 >=20 > For REQ3, how about this: >=20 >=20 >=20 > The solution must require that the identifier, if present, pass unchanged > through SIP B2BUAs or other intermediaries. >=20 >=20 >=20 > REQ3 and REQ5 are focused on two requirements, so I'd like to keep them > separate if possible. >=20 >=20 >=20 > Paul >=20 >=20 >=20 > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: Monday, December 17, 2012 4:19 PM > To: Paul E. Jones; insipid@ietf.org > Subject: RE: [Insipid] draft-ietf-insipid-session-id-reqts-03 >=20 >=20 >=20 > Hi Paul, >=20 >=20 >=20 > Section 3.4 >=20 > s/one side at a time, through until completion /one side at a time, until > completion >=20 >=20 >=20 > Section 3.7 >=20 > s/ in section 4.1 of RFC 3725 the flow for which/in section 4.1 of RFC 37= 25, > the flow for which >=20 > And add a cross reference to RFC 3725. >=20 >=20 >=20 > Section 4, >=20 > REQ2 has an extra " ." at the end. >=20 > REQ3 seems problematic to me. It reads: >=20 > The solution must require that the identifier pass unchanged >=20 > through SIP B2BUAs or other intermediaries. >=20 > I believe we discussed some scenarios in which a B2BUA might actually add > something to a session-id on behalf of an entity that did not add one its= elf. > That seems to conflict with this requirement. Either I recall the convers= ions > at IETF 85 incorrectly, or we need to change this requirement. Ah, I just= read > REQ5, so REQ3 needs to change or be combined with REQ5. >=20 >=20 >=20 > Cheers, >=20 > Charles >=20 >=20 >=20 > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Sunday, December 02, 2012 2:09 PM > To: insipid@ietf.org > Subject: Re: [Insipid] draft-ietf-insipid-session-id-reqts-03 >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > Any comments on this revised requirements document? >=20 >=20 >=20 > Paul >=20 >=20 >=20 > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On > Behalf Of Paul E. Jones > Sent: Wednesday, November 21, 2012 1:47 PM > To: insipid@ietf.org > Subject: [Insipid] draft-ietf-insipid-session-id-reqts-03 >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > I've posted a new -03 version of the requirements draft. Please note tha= t I > did not change the wording related to "communication session", yet. > However, what was changed is: >=20 > * Removed sections marked as "DELETED" >=20 > * Re-numbered all requirements so they are consecutive >=20 > * Minor editorial changes >=20 > * Changes to REQ8 and corresponding section 3.6 that removes lang= uage > related to RTCP with language relating to syntax; please be sure to look = at > that text >=20 > * Removed last sentence from REQ2 >=20 > * Wording change on REQ3 >=20 > * At the AD's request, I moved some authors to a new "Contributor= s" > section >=20 >=20 >=20 > Comments welcome, though note it is a holiday here in the US Thursday and > Friday, so I apologize if my responses are slow. >=20 >=20 >=20 > Paul >=20 >=20