From internet-drafts@ietf.org Mon Jul 11 13:19:06 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C52C11E81E9; Mon, 11 Jul 2011 13:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 rx9RrmsHLvcH; Mon, 11 Jul 2011 13:19:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1141311E818F; Mon, 11 Jul 2011 13:19:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711201905.12512.75164.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 13:19:05 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-03.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:19:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Work= ing Group of the IETF. Title : Problem Statement and Requirements for Transporting User= to User Call Control Information in SIP Author(s) : Alan Johnston Laura Liess Filename : draft-ietf-cuss-sip-uui-reqs-03.txt Pages : 11 Date : 2011-07-11 This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-03.txt From internet-drafts@ietf.org Mon Jul 11 13:19:20 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6393911E81F3; Mon, 11 Jul 2011 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 KZzFB9x74HzU; Mon, 11 Jul 2011 13:19:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45EE11E81E5; Mon, 11 Jul 2011 13:19:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711201919.12530.1732.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 13:19:19 -0700 Cc: cuss@ietf.org Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-01.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:19:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Call Control UUI Service for SIP Work= ing Group of the IETF. Title : A Mechanism for Transporting User to User Call Control I= nformation in SIP Author(s) : Alan Johnston James Rafferty Filename : draft-ietf-cuss-sip-uui-01.txt Pages : 12 Date : 2011-07-11 There is a need for applications using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. This data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI, along with an extension mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-01.txt From john.elwell@siemens-enterprise.com Tue Jul 12 00:13:40 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD15321F8BD9 for ; Tue, 12 Jul 2011 00:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 tJ3Bt-D-AJU9 for ; Tue, 12 Jul 2011 00:13:38 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id E551B21F8B60 for ; Tue, 12 Jul 2011 00:13:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-12.tower-174.messagelabs.com!1310454815!24451139!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 17574 invoked from network); 12 Jul 2011 07:13:35 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-12.tower-174.messagelabs.com with SMTP; 12 Jul 2011 07:13:35 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 3F3F223F03ED for ; Tue, 12 Jul 2011 09:13:35 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 12 Jul 2011 09:13:35 +0200 From: "Elwell, John" To: "cuss@ietf.org" Date: Tue, 12 Jul 2011 09:13:32 +0200 Thread-Topic: sip-uui-reqs-03 Thread-Index: AcxAYzUpGFfxdHDdTBqsCJvnw0WXUQ== 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 Subject: [cuss] sip-uui-reqs-03 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 07:13:40 -0000 This addresses my review comments on -02. Nits: " REQ-8: The mechanism will allow a UAC to require that a UAS understands the call control UUI mechanism have a request routed based on this information." Change "have" to "and have". "As such, is important " Change to "As such, it is important". John = From dworley@avaya.com Tue Jul 12 11:58:54 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8E21F8EE1 for ; Tue, 12 Jul 2011 11:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 ff8gVXfDYRV2 for ; Tue, 12 Jul 2011 11:58:54 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A9AF021F8E5E for ; Tue, 12 Jul 2011 11:58:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoHAHKYHE6HCzI1/2dsb2JhbABTpzJwB6tRg3UCm0GFW18El3iLSw X-IronPort-AV: E=Sophos;i="4.65,522,1304308800"; d="scan'208";a="256217681" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jul 2011 14:58:52 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jul 2011 14:51:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 12 Jul 2011 14:58:50 -0400 From: "Worley, Dale R (Dale)" To: "cuss@ietf.org" Date: Tue, 12 Jul 2011 14:58:08 -0400 Thread-Topic: Comments on draft-ietf-cuss-sip-uui-reqs-03 Thread-Index: AQHMQMW80Wh0bmNEdUixW7lyQvG1LA== 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 Subject: [cuss] Comments on draft-ietf-cuss-sip-uui-reqs-03 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:58:54 -0000 The introduction discusses "the application" as being associated with both the UAS and UAC. I would describe it as "the applications", with one "application" associated with the UAS and one "application" associated with the UAC. This is largely a matter of terminology, but the choice carries a philosophical bias, as calling both bits of code one application is a mindset which assumes tight administrative coordination between them, whereas calling each one an application seperately suggests they are administratively decoupled. Given the expectation of a "protocol discriminator" (REQ-11), both approaches may already be covered by the draft. The message flow in section 2.4 is not quite correct, as it has a NOTIFY from Originator to Referrer reporting a 100 Trying that was received from Terminator, before Originator sends its INVITE to Terminator. The correct version is: Originator Referrer Terminator | | | | REFER (UUI) F1 | | |<-------------------| | | 202 Accepted F2 | | |------------------->| | | INVITE (UUI) F5 | | |---------------------------------------->| | 100 Trying | |<----------------------------------------| | NOTIFY (100 Trying) F3 | |------------------->| | | 200 OK F4 | | |<-------------------| | | 200 OK F6 | |<----------------------------------------| | ACK F7 | |---------------------------------------->| | NOTIFY (200 OK) F8 | | |------------------->| | | 200 OK F9 | | |<-------------------| | Or we could omit the 100 and the NOTIFY of 100 for brevicy, as they are not interesting in this situation. Do we expect to support UUI in failure responses? Those are not listed in REQ-1, but they might be useful in interworking or even pure-SIP applications. REQ-5 says that the mechanism will not require dereferencing a URI, though it might be informative to state that a particular sending application might use the UUI to carry a URI, which the receiving application would dereference. REQ-6 says that UUI can be used for DSS1 information elements, QSIG information elements, or ISUP parameters. Does the UUI mechanism automatically tag which of these cases obtains? Would that be needed in fairly open-network gateway-to-gateway interworking situations? Or does the protocol discriminator ensure that these issues don't cause practical problems? And is there the intention to define within the solution the details of these interworking cases? Another architectural question is whether there is an expectation that the sender and receiver will always be tightly coordinated, part of a "walled garden", or whether we expect "public" resources to use the mechanism. Dale From dworley@avaya.com Tue Jul 12 12:37:34 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE79A21F8D64 for ; Tue, 12 Jul 2011 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.983 X-Spam-Level: X-Spam-Status: No, score=-102.983 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1, 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 86YK9IMMNksA for ; Tue, 12 Jul 2011 12:37:33 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9823B21F8D63 for ; Tue, 12 Jul 2011 12:37:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoHAIahHE7GmAcF/2dsb2JhbABTpzJwB6tcg3UCm0CFW18El3iLSw X-IronPort-AV: E=Sophos;i="4.65,522,1304308800"; d="scan'208";a="290292564" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jul 2011 15:37:32 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jul 2011 15:35:58 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 12 Jul 2011 15:37:31 -0400 From: "Worley, Dale R (Dale)" To: "cuss@ietf.org" Date: Tue, 12 Jul 2011 15:36:49 -0400 Thread-Topic: Comments on draft-ietf-cuss-sip-uui-01 Thread-Index: AQHMQMskxgsD0NK6BU+GrpUtKtgplg== 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 Subject: [cuss] Comments on draft-ietf-cuss-sip-uui-01 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:37:34 -0000 In regard to the BNF: "|" is used where the official operator is "/". Although I don't think anyone will be confused. In a number of rules, a literal "=3D" is used where SIP BNF typically uses EQUAL (which permits SWS before the "=3D"). E.g., cont-param =3D "content=3D" token as opposed to=20 cont-param =3D "content" EQUAL token The header is named "User-to-User". I would expect "UUI", which is briefer and seems to be the term that is used throughout the telephony field. The relationship between "content" and "app" seems to be vaguely specified. As far as I can tell, the primary categorization is on "app" and then within the app value, it is categorized by "content". OTOH, the text always describes the "content" value before describing the "app" value, which suggests primacy of "content". The semantics of "content" is not clear. (The only thing that is certain is that "content" cannot be a media type, as "/" is not permitted in tokens.) How multiple User-to-User headers are to be handled is not clear. The syntax does not allow a COMMA-separated list of values, so RFC 3261 section 7.3.1 says that multiple headers are not permitted. But section 4.1 of the draft explicitly allows multiple values *if* they have different "app" values; presumably values with the same "app" value and different "content" values remain forbidden. All of this seems to be risky, in case a proxy assumes that section 7.3.1 forbids new headers which do not obey the COMMA rule, and thus it blindly combines User-to-User: 0123456789abcdef User-to-User: abcdef0123456789 into User-to-User: 0123456789abcdef, abcdef0123456789 which is syntactically invalid. The lack of clarity of which User-to-User values may be combined leads to lack of clarity regarding how a proxy acts on a 3xx response whose Contact value contains "?User-to-User=3D...". Currently, there are two alternatives for how headers are processed in this situation: If the header may appear only once in a request, the included header completely replaces any existing header of that name. If the header may appear multiple times, the included header is added to the series of headers of that name. (For the latter to succeed requires that any two header values that are individually valid can be validly both present in a request.) The complexity of the combining rules for User-to-User requires the rules to be explicitly stated. Is the "actual" content, the underlying semantics of the value space, of the User-to-User header assumed to be a sequence of octets? Or is that only if encoding=3Dhex? The details of "hex" are not specified. AFAICT the only detail is what case A-F may be in. Dale From enrico.marocco@telecomitalia.it Wed Jul 13 02:03:47 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D8121F85AE for ; Wed, 13 Jul 2011 02:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 DHRS2ALPQvyc for ; Wed, 13 Jul 2011 02:03:47 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 775DC21F85AC for ; Wed, 13 Jul 2011 02:03:46 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 11:03:42 +0200 Received: from MacLab.local (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 13 Jul 2011 11:03:41 +0200 Message-ID: <4E1D5F6C.8080500@telecomitalia.it> Date: Wed, 13 Jul 2011 11:03:40 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "cuss@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060504090302050607060407" Subject: [cuss] Draft agenda for IETF 81 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 09:03:47 -0000 --------------ms060504090302050607060407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, as you may have noticed, the cuss WG session has been scheduled on Wed, July 27, 13:00-15:00 (usual warning: IETF agenda is subject to change till the very last minute!). The primary goals for this meeting are to discuss any residual post-WGLC comments and finalize the requirements document, and move forward the mechanism specification. A draft agenda is available at: http://www.ietf.org/proceedings/81/agenda/cuss.html Please let the chairs know if you have any comments. Enrico and Vijay --------------ms060504090302050607060407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM7jCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGsjCCBZqgAwIBAgIDAZXQMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTAwOTAyMjE0NjQ5 WhcNMTEwOTA0MDczNDM2WjCBnTEgMB4GA1UEDRMXMjUxNDUwLTVBOWo3QUhXTXgzNkVHa2Qx HjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRDb20gRnJl ZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCVq5Ial9/2 azyFbgXY2+yMbEwHjhOWlXcwa7sdnRZ6BUXjusppAmshM1SPz+IZYfLdqancntuhkG/YKR4T Mg0SzWz3bDtCQjga0FSBQ5v2Up8kT/Q0F4/hkYrsTaKfL+WA2cjQtn8+K0fD3t/1tcuTuIHw fesN6w1VDn4HhFj3WGSXok9Zxk7609/Z4ZBqr3trmQ5Dl6pwb8pO1kE/ggH7qCx537ybIByS dxzcPNzbryGJiCfy4iXaws0xsl4xEQXDJFixLjgJm+AOTXb37AAgwKq+v9t3qIH6AHAbPBO6 I/qpoQ/zYMs1s9CoKkNDa9DsJlgyZdPH/vyFvCi/dDJ7AgMBAAGjggMIMIIDBDAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFCTMmq/In1ufC0+wdpHdBvezAYWcMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCoGA1UdEQQjMCGBH2Vucmljby5tYXJvY2NvQHRlbGVjb21pdGFsaWEuaXQwggFCBgNV HSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20g THRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGlj eSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNV HR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADWaaCjv4EfYGz4rrds8wLUpSPTi1tnO3hIm /Hg0SHqDRWRv3AG/OjUKYj+UKKAzhhEoYYrYCxhQfO3uEAC4Mez+DWDsBymKHsRkpf/0efoh mDe60HN81V6jB7hSB+FHaJ5QCBhJ/yasltL7HMl92dpRHYlnKXoXAiIoZUY54eYh09Gyk8su xgaiAwWtn4NnTqnQTjYOOly+WOZ/M6AlmkTErzjliIyAJOIceWzByJs6iIvLXzqpdoZ1+BzE TvoyaVidF13Xc8opUGSqYTyaVKwumrA5eUOZrLzdunkT8JuWgAx81syHYjSeD4ae+EoMFRJ8 gVm6vGPNETTSbFjGM38xggPQMIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUg Q2xpZW50IENBAgMBldAwCQYFKw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTEwNzEzMDkwMzQwWjAjBgkqhkiG9w0BCQQxFgQUqNuunvg3 M6XNJBfK8iPAKgWZcpswXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n MTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQIDAZXQMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMBldAwDQYJKoZIhvcNAQEBBQAEggEANAGoFFid8REmLh5N26F8xSQp aGIvmvl2asn4iNgH/2KRQbmDdUDkuC4NFHtEMT6hgoj9BKlioBANk4/AZ7/CjllV64uRSTnm ryNVTWJMJteJkOviHFtezY26P3kN6+Ja8ekGsxCpGfPQPyapSL8gCvJ5PrXdC6x/iGrqzH31 KxbddBAqHw/tRwte+FC5cmlbfwvidvjMmSJDCB9SLyEBOG/GdLm3VWVfKp/Rkzsq6WSHaZOT yQ3Wxo68sPtDqKOhrE3DuUQr7xZI/N/z/OK3+oTDzh5DRpjI5eNc0YfCooeX5x7smgHWqYc3 YCSiQ5drFVeaD55O2LbHXSU9xfhlQAAAAAAAAA== --------------ms060504090302050607060407-- From alan.b.johnston@gmail.com Wed Jul 20 08:21:10 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DEF21F84D3 for ; Wed, 20 Jul 2011 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 ArrLC9xPnL0Q for ; Wed, 20 Jul 2011 08:21:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75D21F856A for ; Wed, 20 Jul 2011 08:21:03 -0700 (PDT) Received: by gyd5 with SMTP id 5so167834gyd.31 for ; Wed, 20 Jul 2011 08:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mRXWgrZrdL7u1rsgtQgmQbKy6oaABgwn0M+YfvYtu0Y=; b=dMEkNTFsJRyuUIl4N95758E3ykgVMOsXi67LUmr1hC4BoDDV8uJVuXBW3PKbAHwjbc HpIcjiXGsjQl+XOHwdrZdFjSai3Qqo8UPQubWw+Bmih6pvW4Gx7pbUxY1TMcGC2XSLhn 6v+M6Jb6JsG4eFzNPcBcllbL5HfdeWHnVPKmc= MIME-Version: 1.0 Received: by 10.150.136.3 with SMTP id j3mr8090850ybd.282.1311175262141; Wed, 20 Jul 2011 08:21:02 -0700 (PDT) Received: by 10.151.106.1 with HTTP; Wed, 20 Jul 2011 08:21:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Jul 2011 10:21:02 -0500 Message-ID: From: Alan Johnston To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] Comments on draft-ietf-cuss-sip-uui-reqs-03 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:21:10 -0000 Dale, Thanks for your comments on the draft. See my replies below. - Alan - On Tue, Jul 12, 2011 at 1:58 PM, Worley, Dale R (Dale) wrote: > The introduction discusses "the application" as being associated with > both the UAS and UAC. =A0I would describe it as "the applications", with > one "application" associated with the UAS and one "application" > associated with the UAC. =A0This is largely a matter of terminology, but > the choice carries a philosophical bias, as calling both bits of code > one application is a mindset which assumes tight administrative > coordination between them, whereas calling each one an application > seperately suggests they are administratively decoupled. > > Given the expectation of a "protocol discriminator" (REQ-11), both > approaches may already be covered by the draft. I think we need to support both cases. In some cases, there might be very loose coordination between the software on the pair of UAs. In other cases, I suspect there will be very tight coupling. But I'd be interested in other's opinions on this. > > The message flow in section 2.4 is not quite correct, as it has a > NOTIFY from Originator to Referrer reporting a 100 Trying that was > received from Terminator, before Originator sends its INVITE to > Terminator. =A0The correct version is: > > =A0 =A0 =A0 =A0 =A0 =A0 =A0Originator =A0 =A0 =A0 =A0 =A0 Referrer =A0 = =A0 =A0 =A0 =A0 =A0 Terminator > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0REFER (UUI) F1 =A0 =A0| =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-------------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0202 Accepted F2 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0INVITE (UUI) F5 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------------------------= ---->| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0100 Trying =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-----------------------------------= -----| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | NOTIFY (100 Trying) F3 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 200 OK F4 =A0| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-------------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0200 OK F6 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-----------------------------------= -----| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0ACK F7 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------------------------= ---->| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | NOTIFY (200 OK) F8 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------->| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0200 OK F9 =A0 | =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<-------------------| =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| > > Or we could omit the 100 and the NOTIFY of 100 for brevicy, as they > are not interesting in this situation. I'll fix it. > > Do we expect to support UUI in failure responses? =A0Those are not > listed in REQ-1, but they might be useful in interworking or even > pure-SIP applications. The problem with failure responses is that they are hop-by-hop rather than end-to-end. I don't think we could guarantee delivery of UUI in a 4xx, 5xx, or 6xx response. Does anyone have any thoughts on use cases for this? > > REQ-5 says that the mechanism will not require dereferencing a URI, > though it might be informative to state that a particular sending > application might use the UUI to carry a URI, which the receiving > application would dereference. I don't think this would be an appropriate use of this mechanism. For a URI, you would use the Call-Info header field instead of the UUI mechanism. > > REQ-6 says that UUI can be used for DSS1 information elements, QSIG > information elements, or ISUP parameters. =A0Does the UUI mechanism > automatically tag which of these cases obtains? =A0Would that be needed > in fairly open-network gateway-to-gateway interworking situations? =A0Or > does the protocol discriminator ensure that these issues don't cause > practical problems? I don't believe there are any issues on the SIP side - the PSTN gateway will know what PSTN protocol is used on the other side and will map accordingly. > > And is there the intention to define within the solution the details > of these interworking cases? We are chartered to specify an ISDN interworking usage, so yes. > > Another architectural question is whether there is an expectation that > the sender and receiver will always be tightly coordinated, part of a > "walled garden", or whether we expect "public" resources to use the > mechanism. We should be able to support both approaches, but the current uses are within a trust domain. As such, this should be the primary use case, in my opinion. > > Dale > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From dworley@avaya.com Wed Jul 20 12:13:27 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8579521F86E5 for ; Wed, 20 Jul 2011 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.294 X-Spam-Level: X-Spam-Status: No, score=-103.294 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 AqrSDasuUKG0 for ; Wed, 20 Jul 2011 12:13:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2D21F86E0 for ; Wed, 20 Jul 2011 12:13:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFAL0nJ07GmAcF/2dsb2JhbABTm3iLb3eIfKNWAptQhV5fBJgThEOHEQ X-IronPort-AV: E=Sophos;i="4.67,236,1309752000"; d="scan'208";a="291917953" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Jul 2011 15:13:26 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Jul 2011 15:11:26 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 20 Jul 2011 15:13:25 -0400 From: "Worley, Dale R (Dale)" To: Alan Johnston Date: Wed, 20 Jul 2011 15:13:26 -0400 Thread-Topic: [cuss] Comments on draft-ietf-cuss-sip-uui-reqs-03 Thread-Index: AcxG8KjMghk5AZZjSoiYS9JnDW9w8QAH3pQ/ Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cuss@ietf.org" Subject: Re: [cuss] Comments on draft-ietf-cuss-sip-uui-reqs-03 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 19:13:27 -0000 > From: Alan Johnston [alan.b.johnston@gmail.com] >=20 > > On Tue, Jul 12, 2011 at 1:58 PM, Worley, Dale R (Dale) wrote: > > > > Do we expect to support UUI in failure responses? Those are not > > listed in REQ-1, but they might be useful in interworking or even > > pure-SIP applications. >=20 > The problem with failure responses is that they are hop-by-hop rather > than end-to-end. I don't think we could guarantee delivery of UUI in > a 4xx, 5xx, or 6xx response. Does anyone have any thoughts on use > cases for this? An interesting point. In the pure-SIP world, there is no guarantee that any particular failure response makes it back to the UAC. OTOH, in PSTN-like situations where there is no forking, one can expect the sole failure response to get back to the UAC. The important question, I think, is whether in PSTN usage the callee can send UUI back to the caller when failing a call. Interworking with that feature could be important and difficult to implement, so we need to know if it is a requirement. > > REQ-5 says that the mechanism will not require dereferencing a URI, > > though it might be informative to state that a particular sending > > application might use the UUI to carry a URI, which the receiving > > application would dereference. >=20 > I don't think this would be an appropriate use of this mechanism. For > a URI, you would use the Call-Info header field instead of the UUI > mechanism. Good point, although you can never tell what the application might send in the UUI. > > REQ-6 says that UUI can be used for DSS1 information elements, QSIG > > information elements, or ISUP parameters. Does the UUI mechanism > > automatically tag which of these cases obtains? Would that be needed > > in fairly open-network gateway-to-gateway interworking situations? Or > > does the protocol discriminator ensure that these issues don't cause > > practical problems? >=20 > I don't believe there are any issues on the SIP side - the PSTN > gateway will know what PSTN protocol is used on the other side and > will map accordingly. [...] > > Another architectural question is whether there is an expectation that > > the sender and receiver will always be tightly coordinated, part of a > > "walled garden", or whether we expect "public" resources to use the > > mechanism. >=20 > We should be able to support both approaches, but the current uses are > within a trust domain. As such, this should be the primary use case, > in my opinion. As long as both ends are within a coordinated domain, then there is no need to worry about tagging DSS1 vs. QSIG vs. ISUP parameters. Dale