From Internet-Drafts@ietf.org Mon Feb 7 07:15:02 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F263A6E15; Mon, 7 Feb 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsFf+YrQ765k; Mon, 7 Feb 2011 07:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999893A6D7D; Mon, 7 Feb 2011 07:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207151501.1133.51830.idtracker@localhost> Date: Mon, 07 Feb 2011 07:15:01 -0800 Cc: cuss@ietf.org Subject: [cuss] I-D Action:draft-ietf-cuss-sip-uui-00.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF. Title : A Mechanism for Transporting User to User Call Control Information in SIP Author(s) : A. Johnston, et al. Filename : draft-ietf-cuss-sip-uui-00.txt Pages : 12 Date : 2011-02-07 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-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-cuss-sip-uui-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-07070614.I-D@ietf.org> --NextPart-- From alan.b.johnston@gmail.com Mon Feb 7 07:19:06 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66BB3A6E07 for ; Mon, 7 Feb 2011 07:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3C0nEJDids6 for ; Mon, 7 Feb 2011 07:19:05 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8C86B3A6E13 for ; Mon, 7 Feb 2011 07:19:05 -0800 (PST) Received: by bwz12 with SMTP id 12so5588731bwz.31 for ; Mon, 07 Feb 2011 07:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=vRKkS8HH3z/ZbQAxSv09vyLQxxMCvSaUHzxs4UyWHU0=; b=Ezym0x49qYUyROn8cIbMhMD3nnkBvLbDo0YcfHAe/j55vaGVCzdmgAzp+772Kd56uw dF1Vr/Kvz24hBa0AVS/s7SJS0Wujd+xx5p1lHoA7P4ZEpOxv32jmXqM3YlwtIRtHwpOJ Xu0yGlAt/NsVyFiH+ZTLtJCuSBuRYOV4ZB/2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=bgYkzDikrue2EbUMBCYlmABhr5avIlBKUNgRJ0LY1WiL6kZpcFKVdJlYrKKTxCTvYV jmMyXjFOg77blE+P6Gve8cLHbeA5w8I+ZTEC0b2hB8W3PIktKJyViZSyA3wrn4BWQmJx eB4jY8mPqEUKGvgAFKr2/KTe6q5StSJ6HSOI4= MIME-Version: 1.0 Received: by 10.204.99.77 with SMTP id t13mr15412368bkn.164.1297091948110; Mon, 07 Feb 2011 07:19:08 -0800 (PST) Received: by 10.204.81.91 with HTTP; Mon, 7 Feb 2011 07:19:08 -0800 (PST) In-Reply-To: <20110207151501.1133.51830.idtracker@localhost> References: <20110207151501.1133.51830.idtracker@localhost> Date: Mon, 7 Feb 2011 09:19:08 -0600 Message-ID: From: Alan Johnston To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cuss] I-D Action:draft-ietf-cuss-sip-uui-00.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 15:19:06 -0000 All, This version is similar to the last draft, but I have moved all the discussion about other mechanisms and INFO to an Appendix. I did this mainly just for archiving. Unless someone objects, I will remove it from the next version. I also have three open issues that I will start separate threads on the lis= t. As always, comments are most welcome. - Alan - On Mon, Feb 7, 2011 at 9:15 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Call Control UUI Service for SIP Working= Group of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Mechanism for Transporting U= ser to User Call Control Information in SIP > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : A. Johnston, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-cuss-sip-uui-00.txt > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-07 > > There is a need for applications using SIP to exchange User to User > Information (UUI) data during session establishment. =A0This > 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. =A0This data is opaque to SIP and > its function is unrelated to any basic SIP function. =A0This 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-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > > From alan.b.johnston@gmail.com Mon Feb 7 07:21:20 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF3B3A6E07 for ; Mon, 7 Feb 2011 07:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsHPFrnH9cNm for ; Mon, 7 Feb 2011 07:21:19 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 3A5E93A6D7D for ; Mon, 7 Feb 2011 07:21:19 -0800 (PST) Received: by eyd10 with SMTP id 10so2556421eyd.31 for ; Mon, 07 Feb 2011 07:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2oHvPoTMaFAi5ex90QzY76xDuI/cpg56Sx1omA1ngIw=; b=TM639EB7j9SrXkPNmzJnNVZ9IQ8fE/4kEc51UYpFQVQ6+j/lXRPSNQu3GRsvQV84dq HA7R6fA5hq95C1fS/ZHFvkSumkcgKTM9paEwTf0MIQlin7EkZQawiFDUCDvS02872CpB Da2vDqZPkfU2XaZCEk3lJVotd5D3iF9nAakLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=o56T7+S5HzUXc5MyFFNp9mgQuDfCc6bs+IWNn5V+rK1ct9LSBtJKIcX/kgu0/wUJbO aiJSdiSCpQNZJ/nlbFlUgQRWKXMiuXWevtIQa4et6rF/ZvfcS9ckn+qjV8t+WKeROCdd F6ccbvZVgDBIFuo66qur5e7Zx7hoIdKy5As88= MIME-Version: 1.0 Received: by 10.204.72.137 with SMTP id m9mr1119665bkj.191.1297092079944; Mon, 07 Feb 2011 07:21:19 -0800 (PST) Received: by 10.204.81.91 with HTTP; Mon, 7 Feb 2011 07:21:19 -0800 (PST) Date: Mon, 7 Feb 2011 09:21:19 -0600 Message-ID: From: Alan Johnston To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [cuss] Open Issue: REQ-12 and History-Info X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 15:21:20 -0000 Currently, there is no mechanism defined to meet REQ-12 on identifying the inserter of UUI. Is there interest in defining this? Is the History-Info approach outlined in the draft a reasonable approach, or are there others? - Alan - From alan.b.johnston@gmail.com Mon Feb 7 07:24:32 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671503A6D03 for ; Mon, 7 Feb 2011 07:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFdnj42Pctsy for ; Mon, 7 Feb 2011 07:24:31 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 686BF3A6D6E for ; Mon, 7 Feb 2011 07:24:31 -0800 (PST) Received: by bwz12 with SMTP id 12so5594312bwz.31 for ; Mon, 07 Feb 2011 07:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=CLPiPvt+irEixnkATi2XJ9NasmtmqgcljmAYOvwcbS0=; b=B7eH/GHHrvWkjKMt58OYDfOBshOuWTNwf7DmSaQq8bB2fd+PLgcIzMzEbOeQ2qk83k Xam4cxmQfyBK0leMsuVvB8OGMbZW2UuXxnWHsNkiaetEdF8S49WUOIhL4O9cODl7iI1L T0hJxShUFyooq4Ukg4FkYM3jVOwfhzfqseD4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=d6CnLbPPdJ2FNcYspxjamDSPxPUFnAEwUm/PqJ4YwkNiD0bNMX/qNVkjij7SzRLup2 LzHZU5INbgft6PFhaQ06bxmuVNxbqmkHFb1h84koq+hNcb5F5hjsctY3m9TmsqpYUrrZ WAfgS5XyED53EQU2UQLWM/jMZ1eivkgz93zM8= MIME-Version: 1.0 Received: by 10.204.72.137 with SMTP id m9mr1125675bkj.191.1297092274970; Mon, 07 Feb 2011 07:24:34 -0800 (PST) Received: by 10.204.81.91 with HTTP; Mon, 7 Feb 2011 07:24:34 -0800 (PST) Date: Mon, 7 Feb 2011 09:24:34 -0600 Message-ID: From: Alan Johnston To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [cuss] Open Issue: REQ-13 and Integrity Protection X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 15:24:32 -0000 Currently, the mechanism does not define a way to meet REQ-13 on integrity protection of UUI. One approach is to use S/MIME, although S/MIME is not deployed, and this introduces another body. Another approach would be to define an SDP attribute so that RFC 4474 could be used. However, RFC 4474 is not deployed either. Are there other approaches? Do either of these approaches make sense given real deployments? - Alan - From alan.b.johnston@gmail.com Mon Feb 7 07:26:11 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7E03A6E12 for ; Mon, 7 Feb 2011 07:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFonX2ZHrTvx for ; Mon, 7 Feb 2011 07:26:10 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 8627B3A6E05 for ; Mon, 7 Feb 2011 07:26:10 -0800 (PST) Received: by bwz12 with SMTP id 12so5595919bwz.31 for ; Mon, 07 Feb 2011 07:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=zZz+KVqw1TY30YZYDCqQtFYqv7sidXaRec5UISd3db8=; b=GokKczr+ZPqTC0zS7qIH0Rw1rbn7xo2b0jH68kfbgT8xZoQ0IwktU7dOGqF0YtvCCm UgEV4H1EADZx2jdmIirNAmQRu7sOglXvN7SbzswRiP305byLIc5ukit7UIUlGwcI9cDG HeySykpV+/GpXLIYk3Yodz6mXIM+6JlcQnQzs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=to9NyJVJwYgoNCqR0TUZiaPeWy4NHUS772PJsQPq+obCOyOzcngkx+HOLWHfsK+U5i FCGma/KKv7WAPbdP4PdJ5gwsAQOGMWwzns5+XnrSQfzkkh1Rx6TrnTGo1Sku/OHFCCo+ xAMxYhyNNdv5D87JqZwOozoaZU/VTON86fO9E= MIME-Version: 1.0 Received: by 10.204.76.65 with SMTP id b1mr8428148bkk.29.1297092373680; Mon, 07 Feb 2011 07:26:13 -0800 (PST) Received: by 10.204.81.91 with HTTP; Mon, 7 Feb 2011 07:26:13 -0800 (PST) Date: Mon, 7 Feb 2011 09:26:13 -0600 Message-ID: From: Alan Johnston To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 15:26:11 -0000 I think there is an issue around encoding format. For interworking with the ISDN, there are two potential encodings: the one used in ISDN and the one used to encapsulate the ISDN in the SIP header field. Which doe we need to convey? Just the SIP one, or both? Do we need to define IA5 transport? - Alan - From keith.drage@alcatel-lucent.com Mon Feb 7 07:27:30 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C0FD3A68C6 for ; Mon, 7 Feb 2011 07:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4FHEGxDbrEK for ; Mon, 7 Feb 2011 07:27:29 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 456143A6D90 for ; Mon, 7 Feb 2011 07:27:28 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p17FOuhQ006225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 7 Feb 2011 16:27:31 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 7 Feb 2011 16:27:04 +0100 From: "DRAGE, Keith (Keith)" To: Alan Johnston , "cuss@ietf.org" Date: Mon, 7 Feb 2011 16:27:02 +0100 Thread-Topic: [cuss] Open Issue: REQ-12 and History-Info Thread-Index: AcvG2rM953lGsHJ9SYqCetsT+Y3dQgAAHujQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [cuss] Open Issue: REQ-12 and History-Info X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 15:27:30 -0000 The only way out of not defining this is to allow only one inserter of the = UUI, which would be a change back in the requirements. As soon as there are multiple UUI inserted by different parties then we nee= d a may of identifying who the inserter was. I do favour the default of an untagged UUI always being inserted by the ori= ginal calling user. Something built on History-Info does seem the simplest way of otherwise sol= ving this problem, as it already contains the forwarding index. Regards Keith=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > Behalf Of Alan Johnston > Sent: 07 February 2011 15:21 > To: cuss@ietf.org > Subject: [cuss] Open Issue: REQ-12 and History-Info >=20 > Currently, there is no mechanism defined to meet REQ-12 on=20 > identifying the inserter of UUI. >=20 > Is there interest in defining this? >=20 > Is the History-Info approach outlined in the draft a=20 > reasonable approach, or are there others? >=20 > - Alan - > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From pkyzivat@cisco.com Mon Feb 7 14:09:21 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00AC3A6E5B for ; Mon, 7 Feb 2011 14:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dne26rRMiINL for ; Mon, 7 Feb 2011 14:09:21 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E5D6F3A6D96 for ; Mon, 7 Feb 2011 14:09:20 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEFAA78T01AZnwN/2dsb2JhbACXCI4cc55LmxeFWgSEeoZtgy4 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2011 22:09:25 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p17M9PWw007773 for ; Mon, 7 Feb 2011 22:09:25 GMT Message-ID: <4D506D95.1090704@cisco.com> Date: Mon, 07 Feb 2011 17:09:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: cuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 07 Feb 2011 22:09:22 -0000 On 2/7/2011 10:26 AM, Alan Johnston wrote: > I think there is an issue around encoding format. For interworking > with the ISDN, there are two potential encodings: the one used in ISDN > and the one used to encapsulate the ISDN in the SIP header field. > > Which doe we need to convey? Just the SIP one, or both? Do we need > to define IA5 transport? Well, this is an interesting mess! I'm not myself a user of this stuff. But its my impression that in many cases the users of this info are indeed passing *text*, and at best find it inconvenient to have to encode/decode it to hex. This is independent of whether the stuff is passing through ISDN or not. I don't know if the ISDN formats are well defined wrt whether they are encoded in IA5 or something else. If they are, then conversion between a sip encoding and an ISDN encoding could be done by the GW. If they are not, then its more problematic. I've suggested before that instead of defining isdn-interwork as a single purpose, that there be a separate purpose defined for each valid value of the discriminator byte in the ISDN UUI data. If that were done, then it would be much more reasonable to expect a GW to convert between sip encodings and ISDN encodings. Thanks, Paul From R.Jesske@telekom.de Tue Feb 8 06:36:37 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2013A63D3 for ; Tue, 8 Feb 2011 06:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CrtyGCi0B+W for ; Tue, 8 Feb 2011 06:36:36 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8C93D3A6403 for ; Tue, 8 Feb 2011 06:36:35 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 08 Feb 2011 15:36:37 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.189]) by he110890 ([10.134.92.131]) with mapi; Tue, 8 Feb 2011 15:36:37 +0100 From: To: , Date: Tue, 8 Feb 2011 15:36:35 +0100 Thread-Topic: [cuss] Open Issue: Encoding format Thread-Index: AcvG23SM3IL3xlHRSDWTavcg73IsyAAvoQnA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC01@HE111648.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 14:36:37 -0000 Hi Alan, If you are using the ISDN encoding then you have more complex interworking = procedures with SS7. You have then to put together the encoding which is the Protocol discrimina= tor within DSS1 and the UUI information itself. So I would support the encapsulation of the ISDN header. This would fit for= direct SIP-DSS1 and SIP - SS7 interworking. I don't see the need for defining a IA5 transport format. A pure hex encodi= ng, I think, is sufficient. Or have I overseen something? Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > Auftrag von Alan Johnston > Gesendet: Montag, 7. Februar 2011 16:26 > An: cuss@ietf.org > Betreff: [cuss] Open Issue: Encoding format > > I think there is an issue around encoding format. For interworking > with the ISDN, there are two potential encodings: the one used in ISDN > and the one used to encapsulate the ISDN in the SIP header field. > > Which doe we need to convey? Just the SIP one, or both? Do we need > to define IA5 transport? > > - Alan - > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From R.Jesske@telekom.de Tue Feb 8 06:54:08 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366203A67B8 for ; Tue, 8 Feb 2011 06:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqhXjPb-b1hp for ; Tue, 8 Feb 2011 06:54:07 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id F1AEF3A67AE for ; Tue, 8 Feb 2011 06:54:06 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 08 Feb 2011 15:54:12 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.189]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 8 Feb 2011 15:54:12 +0100 From: To: , Date: Tue, 8 Feb 2011 15:54:10 +0100 Thread-Topic: [cuss] Open Issue: Encoding format Thread-Index: AcvHE7EMloFjdBOFSLiuKkr+vn3UAgAiiBJg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> References: <4D506D95.1090704@cisco.com> In-Reply-To: <4D506D95.1090704@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 14:54:08 -0000 > > I've suggested before that instead of defining isdn-interwork as a > single purpose, that there be a separate purpose defined for > each valid > value of the discriminator byte in the ISDN UUI data. If that > were done, > then it would be much more reasonable to expect a GW to > convert between > sip encodings and ISDN encodings. Hi Paul, I try to understand where you are coming from. looking in Q.931 I see the following protocol discriminator values: 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) 0 0 0 0 0 0 0 1 OSI high layer protocols 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) 0 0 0 0 0 0 1 1 Reserved for system management convergence function 0 0 0 0 0 1 0 0 IA5 characters (Note 4) 0 0 0 0 0 1 0 1 X.208 and X.209 coded user information (Note 5) 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call control messages 0 0 0 1 0 0 0 0 Reserved for other network layer or layer 3 protoco= ls, including Recommendation through X.25 [5] (Note 3) 0 0 1 1 1 1 1 1 0 1 0 0 0 0 0 0 through National use 0 1 0 0 1 1 1 1 0 1 0 1 0 0 0 0 Reserved for other network layer or layer 3 protoco= ls, including Recommendation through X.25 (Note 3) 1 1 1 1 1 1 1 0 So this is the indication how the User Information is coded itself. So my question is, what is then understand as a SIP encoding? Regards Roland > > Thanks, > Paul > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Tue Feb 8 07:44:00 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97023A67F1 for ; Tue, 8 Feb 2011 07:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0tVSGdmzUNp for ; Tue, 8 Feb 2011 07:44:00 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id B09733A67F0 for ; Tue, 8 Feb 2011 07:43:59 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p18Fhxps010911 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Feb 2011 16:43:59 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 8 Feb 2011 16:43:59 +0100 From: "DRAGE, Keith (Keith)" To: "R.Jesske@telekom.de" , "pkyzivat@cisco.com" , "cuss@ietf.org" Date: Tue, 8 Feb 2011 16:43:57 +0100 Thread-Topic: [cuss] Open Issue: Encoding format Thread-Index: AcvHE7EMloFjdBOFSLiuKkr+vn3UAgAiiBJgAAIlv9A= Message-ID: References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 08 Feb 2011 15:44:00 -0000 The ISDN coding could be IA5 or binary, as determined possibly by the proto= col discriminator. Moreover in the ISDN, the protocol discriminator could j= ust be a lie. Noone checks it from one end to the other, and it has no impa= ct on the way the network provides the service. So as far as interworking with the ISDN is concerned, I believe it is best = to treat it as always binary. In any case, I do not believe it is appropriate at the interworking gateway= s to start delving into the protocol discriminator values to work out the b= est coding mapping. Therefore I believe the best coding mapping for the ISDN application is alw= ays map to a binary coding within the header field. What that tranfer codin= g is could be optimised so one size fits all as we discussed previously on = the list. Regards Keith > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > Behalf Of R.Jesske@telekom.de > Sent: 08 February 2011 14:54 > To: pkyzivat@cisco.com; cuss@ietf.org > Subject: Re: [cuss] Open Issue: Encoding format >=20 >=20 > > > > I've suggested before that instead of defining isdn-interwork as a=20 > > single purpose, that there be a separate purpose defined for each=20 > > valid value of the discriminator byte in the ISDN UUI data. If that=20 > > were done, then it would be much more reasonable to expect a GW to=20 > > convert between sip encodings and ISDN encodings. >=20 > Hi Paul, > I try to understand where you are coming from. >=20 > looking in Q.931 I see the following protocol discriminator values: >=20 >=20 > 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) > 0 0 0 0 0 0 0 1 OSI high layer protocols > 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) > 0 0 0 0 0 0 1 1 Reserved for system management=20 > convergence function > 0 0 0 0 0 1 0 0 IA5 characters (Note 4) > 0 0 0 0 0 1 0 1 X.208 and X.209 coded user=20 > information (Note 5) > 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption > 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call control messages >=20 > 0 0 0 1 0 0 0 0 Reserved for other network layer or=20 > layer 3 protocols, including Recommendation > through X.25 [5] (Note 3) > 0 0 1 1 1 1 1 1 >=20 > 0 1 0 0 0 0 0 0 > through National use > 0 1 0 0 1 1 1 1 >=20 > 0 1 0 1 0 0 0 0 Reserved for other network layer or=20 > layer 3 protocols, including Recommendation > through X.25 (Note 3) > 1 1 1 1 1 1 1 0 >=20 > So this is the indication how the User Information is coded itself. >=20 > So my question is, what is then understand as a SIP encoding? >=20 > Regards >=20 > Roland >=20 > > > > Thanks, > > Paul > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From pkyzivat@cisco.com Wed Feb 9 06:24:56 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E403A69C2 for ; Wed, 9 Feb 2011 06:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69lCsw7HzWfx for ; Wed, 9 Feb 2011 06:24:55 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 877903A69CF for ; Wed, 9 Feb 2011 06:24:55 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0GACIyUk1AZnwN/2dsb2JhbACXKI4cc6B2mw2FXASEf4ZxgzI Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2011 14:25:05 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p19EP4dp008606; Wed, 9 Feb 2011 14:25:04 GMT Message-ID: <4D52A3C0.9010508@cisco.com> Date: Wed, 09 Feb 2011 09:25:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cuss@ietf.org Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 14:24:56 -0000 On 2/8/2011 9:54 AM, R.Jesske@telekom.de wrote: > >> >> I've suggested before that instead of defining isdn-interwork as a >> single purpose, that there be a separate purpose defined for >> each valid >> value of the discriminator byte in the ISDN UUI data. If that >> were done, >> then it would be much more reasonable to expect a GW to >> convert between >> sip encodings and ISDN encodings. > > Hi Paul, > I try to understand where you are coming from. > > looking in Q.931 I see the following protocol discriminator values: > > > 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) > 0 0 0 0 0 0 0 1 OSI high layer protocols > 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) > 0 0 0 0 0 0 1 1 Reserved for system management convergence function > 0 0 0 0 0 1 0 0 IA5 characters (Note 4) > 0 0 0 0 0 1 0 1 X.208 and X.209 coded user information (Note 5) > 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption > 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call control messages > > 0 0 0 1 0 0 0 0 Reserved for other network layer or layer 3 protocols, including Recommendation > through X.25 [5] (Note 3) > 0 0 1 1 1 1 1 1 > > 0 1 0 0 0 0 0 0 > through National use > 0 1 0 0 1 1 1 1 > > 0 1 0 1 0 0 0 0 Reserved for other network layer or layer 3 protocols, including Recommendation > through X.25 (Note 3) > 1 1 1 1 1 1 1 0 > > So this is the indication how the User Information is coded itself. > > So my question is, what is then understand as a SIP encoding? Roland, My thought is that *each* of the above be defined as a distinct purpose value for sip uui. Then the corresponding value carried in sip would encode all the bytes *except* the discriminator byte (which would be encoded as the purpose). An ISDN GW would then take the sip uui encoding of the value plus the purpose code and construct a corresponding Q.931 encoding. The mapping from the sip encoding of the value to the Q.931 encoding could be defined on a per-purpose basis. But more likely the mappings would be common but validation could be specific. In sip we could then have, e.g., UTF8 and hex encodings. When going from sip to Q.931, the hex encoding would be straightforward, but might need to be checked that the values were consistent with the protocol discriminator. When going from Q.931 to sip, the encoding could be chosen based on both the discriminator/purpose value and the actual content. Even if nothing useful is defined about many of the discriminator values, separating them from the rest of the value has the benefit that when the value is representable as text in sip, but the discriminator is not, we would not be forced to encode the entire thing in hex. Thanks, Paul From pkyzivat@cisco.com Wed Feb 9 06:35:41 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A37A3A69F2 for ; Wed, 9 Feb 2011 06:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chy3teuPGxvt for ; Wed, 9 Feb 2011 06:35:40 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EBDDE3A69F1 for ; Wed, 9 Feb 2011 06:35:39 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKU1Uk1AZnwM/2dsb2JhbAClRHOhBZsNhVwEhH+GcYMy Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2011 14:35:31 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19EZV2v007060; Wed, 9 Feb 2011 14:35:31 GMT Message-ID: <4D52A633.5030403@cisco.com> Date: Wed, 09 Feb 2011 09:35:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 14:35:41 -0000 I just replied to Roland on this. But I'll say a little more: One way to handle the conversion from Q.931 to sip would be "if it can be represented as a sip quoted string, without escapes, then represent it that way, else represent it as hex." And the converse conversion could be "convert a sip quoted string to Q.931 byte for byte, and convert hex to Q.931 in the obvious way, two hex characters per byte." It could be done this way on the entire Q.931 value, including the discriminator byte. But that might be less than satisfactory if the actual data is text, but the chosen discriminator is not a nice quoted string value. If the discriminator is separated out, as the purpose value, then it won't muck up an all-text value. Thanks, Paul On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: > The ISDN coding could be IA5 or binary, as determined possibly by the protocol discriminator. Moreover in the ISDN, the protocol discriminator could just be a lie. Noone checks it from one end to the other, and it has no impact on the way the network provides the service. > > So as far as interworking with the ISDN is concerned, I believe it is best to treat it as always binary. > > In any case, I do not believe it is appropriate at the interworking gateways to start delving into the protocol discriminator values to work out the best coding mapping. > > Therefore I believe the best coding mapping for the ISDN application is always map to a binary coding within the header field. What that tranfer coding is could be optimised so one size fits all as we discussed previously on the list. > > Regards > > Keith > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >> Behalf Of R.Jesske@telekom.de >> Sent: 08 February 2011 14:54 >> To: pkyzivat@cisco.com; cuss@ietf.org >> Subject: Re: [cuss] Open Issue: Encoding format >> >> >>> >>> I've suggested before that instead of defining isdn-interwork as a >>> single purpose, that there be a separate purpose defined for each >>> valid value of the discriminator byte in the ISDN UUI data. If that >>> were done, then it would be much more reasonable to expect a GW to >>> convert between sip encodings and ISDN encodings. >> >> Hi Paul, >> I try to understand where you are coming from. >> >> looking in Q.931 I see the following protocol discriminator values: >> >> >> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >> 0 0 0 0 0 0 0 1 OSI high layer protocols >> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >> 0 0 0 0 0 0 1 1 Reserved for system management >> convergence function >> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >> information (Note 5) >> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption >> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call control messages >> >> 0 0 0 1 0 0 0 0 Reserved for other network layer or >> layer 3 protocols, including Recommendation >> through X.25 [5] (Note 3) >> 0 0 1 1 1 1 1 1 >> >> 0 1 0 0 0 0 0 0 >> through National use >> 0 1 0 0 1 1 1 1 >> >> 0 1 0 1 0 0 0 0 Reserved for other network layer or >> layer 3 protocols, including Recommendation >> through X.25 (Note 3) >> 1 1 1 1 1 1 1 0 >> >> So this is the indication how the User Information is coded itself. >> >> So my question is, what is then understand as a SIP encoding? >> >> Regards >> >> Roland >> >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> From alan.b.johnston@gmail.com Wed Feb 9 06:48:33 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394893A69E3 for ; Wed, 9 Feb 2011 06:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8+wfJAVhEOM for ; Wed, 9 Feb 2011 06:48:32 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 258503A6405 for ; Wed, 9 Feb 2011 06:48:32 -0800 (PST) Received: by gyd12 with SMTP id 12so109852gyd.31 for ; Wed, 09 Feb 2011 06:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=h2JZEe3bJ6rNkBP80aAteL0cy13TlMHSpIpHFNNrEJg=; b=B3tb49ALjIer2DsRVkO1JqYYcqxdJgfgvrEk4YAQkKzXqcHjZSKig101d9lXLiCjq2 c6MceSIoIcbE6SlU4SHxsvCot53MuIRybo/6sMe5h56GPfj1bd/KoFdYGkZrV5iwT5ba 52uMLCyaMCocGnSvy0Ufnj6inwJIxYfSfwdvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=Lu3n3HY2BYNCoS9/wdELcUbrwhv3Jxi+C+upjn//XPEgsX6hM/ZbZ2Cx2wlZgGO0wT Ob4qhy+3xbibAsyzBZdvKceGlNeva36kTpWxmiNt1OGt8/cLjqVQiiPbvmjI+TwqhumR F71OegcoI/tHXDa8W58Sk7zfUdwHv1/4J7KHg= Received: by 10.90.74.14 with SMTP id w14mr1480110aga.34.1297262920993; Wed, 09 Feb 2011 06:48:40 -0800 (PST) Received: from [10.9.211.99] ([166.205.15.106]) by mx.google.com with ESMTPS id g31sm204404yhd.26.2011.02.09.06.48.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 06:48:39 -0800 (PST) References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> In-Reply-To: <4D52A633.5030403@cisco.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Alan Johnston Date: Wed, 9 Feb 2011 07:48:33 -0700 To: Paul Kyzivat Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 14:48:33 -0000 I agree completely with Keith. Gateways have no business delving into the UU= I or the protocol discriminator. This will only create mistakes and errors.=20= My opinion is that for ISDN interworking, the encoding is the transfer encod= ing chosen by the Gateway with the ISDN encoding being assumed to be binary.= =20 - Alan - On Feb 9, 2011, at 7:35 AM, Paul Kyzivat wrote: > I just replied to Roland on this. But I'll say a little more: >=20 > One way to handle the conversion from Q.931 to sip would be "if it can be r= epresented as a sip quoted string, without escapes, then represent it that w= ay, else represent it as hex." And the converse conversion could be "convert= a sip quoted string to Q.931 byte for byte, and convert hex to Q.931 in the= obvious way, two hex characters per byte." >=20 > It could be done this way on the entire Q.931 value, including the discrim= inator byte. But that might be less than satisfactory if the actual data is t= ext, but the chosen discriminator is not a nice quoted string value. If the d= iscriminator is separated out, as the purpose value, then it won't muck up a= n all-text value. >=20 > Thanks, > Paul >=20 > On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: >> The ISDN coding could be IA5 or binary, as determined possibly by the pro= tocol discriminator. Moreover in the ISDN, the protocol discriminator could j= ust be a lie. Noone checks it from one end to the other, and it has no impac= t on the way the network provides the service. >>=20 >> So as far as interworking with the ISDN is concerned, I believe it is bes= t to treat it as always binary. >>=20 >> In any case, I do not believe it is appropriate at the interworking gatew= ays to start delving into the protocol discriminator values to work out the b= est coding mapping. >>=20 >> Therefore I believe the best coding mapping for the ISDN application is a= lways map to a binary coding within the header field. What that tranfer codi= ng is could be optimised so one size fits all as we discussed previously on t= he list. >>=20 >> Regards >>=20 >> Keith >>=20 >>> -----Original Message----- >>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>> Behalf Of R.Jesske@telekom.de >>> Sent: 08 February 2011 14:54 >>> To: pkyzivat@cisco.com; cuss@ietf.org >>> Subject: Re: [cuss] Open Issue: Encoding format >>>=20 >>>=20 >>>>=20 >>>> I've suggested before that instead of defining isdn-interwork as a >>>> single purpose, that there be a separate purpose defined for each >>>> valid value of the discriminator byte in the ISDN UUI data. If that >>>> were done, then it would be much more reasonable to expect a GW to >>>> convert between sip encodings and ISDN encodings. >>>=20 >>> Hi Paul, >>> I try to understand where you are coming from. >>>=20 >>> looking in Q.931 I see the following protocol discriminator values: >>>=20 >>>=20 >>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >>> 0 0 0 0 0 0 0 1 OSI high layer protocols >>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >>> 0 0 0 0 0 0 1 1 Reserved for system management >>> convergence function >>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >>> information (Note 5) >>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption >>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call control messages >>>=20 >>> 0 0 0 1 0 0 0 0 Reserved for other network layer or >>> layer 3 protocols, including Recommendation >>> through X.25 [5] (Note 3) >>> 0 0 1 1 1 1 1 1 >>>=20 >>> 0 1 0 0 0 0 0 0 >>> through National use >>> 0 1 0 0 1 1 1 1 >>>=20 >>> 0 1 0 1 0 0 0 0 Reserved for other network layer or >>> layer 3 protocols, including Recommendation >>> through X.25 (Note 3) >>> 1 1 1 1 1 1 1 0 >>>=20 >>> So this is the indication how the User Information is coded itself. >>>=20 >>> So my question is, what is then understand as a SIP encoding? >>>=20 >>> Regards >>>=20 >>> Roland >>>=20 >>>>=20 >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> cuss mailing list >>>> cuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cuss >>>>=20 >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>>=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From pkyzivat@cisco.com Wed Feb 9 07:49:25 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14DD63A67AF for ; Wed, 9 Feb 2011 07:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0R2RpXiO0IG for ; Wed, 9 Feb 2011 07:49:24 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 961B83A67A7 for ; Wed, 9 Feb 2011 07:49:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAxGUk1AZnwM/2dsb2JhbAClRHOhMJsYhVwEhH+GcYMy Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2011 15:49:33 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p19FnWCG003028; Wed, 9 Feb 2011 15:49:32 GMT Message-ID: <4D52B78C.4030708@cisco.com> Date: Wed, 09 Feb 2011 10:49:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alan Johnston References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> In-Reply-To: <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 15:49:25 -0000 On 2/9/2011 9:48 AM, Alan Johnston wrote: > I agree completely with Keith. Gateways have no business delving into the UUI or the protocol discriminator. This will only create mistakes and errors. It will lead to mistakes or errors if there is discretion or lack of clarity regarding the mapping. As long as the mapping is well defined, all should be fine. Perhaps I am mistaken, but it certainly appears to me that the descriminator byte in the Q.931 format serves much the same purpose that the "purpose" parameter is intended to serve in the proposed sip uui header. It seems very natural to me that we make this correlation. I guess the counter-argument to that is *if* the prevailing use of UUI in ISDN entirely ignores the intent of the discriminator byte, and simply uses the entire string, including the discriminator byte, as a single data value. I don't know if that might be the case, or not. (I hope not, since it is a gross abuse of the Q.931 spec.) > My opinion is that for ISDN interworking, the encoding is the transfer encoding chosen by the Gateway with the ISDN encoding being assumed to be binary. I have some feedback from developers that they do not appreciate being forced to convert text data to/from hex for this purpose. It certainly it won't be well appreciated by those looking at call traces. While its perhaps unavoidable when the actual data is binary, it is avoidable when the data is itself text. Thanks, Paul > - Alan - > > > > On Feb 9, 2011, at 7:35 AM, Paul Kyzivat wrote: > >> I just replied to Roland on this. But I'll say a little more: >> >> One way to handle the conversion from Q.931 to sip would be "if it can be represented as a sip quoted string, without escapes, then represent it that way, else represent it as hex." And the converse conversion could be "convert a sip quoted string to Q.931 byte for byte, and convert hex to Q.931 in the obvious way, two hex characters per byte." >> >> It could be done this way on the entire Q.931 value, including the discriminator byte. But that might be less than satisfactory if the actual data is text, but the chosen discriminator is not a nice quoted string value. If the discriminator is separated out, as the purpose value, then it won't muck up an all-text value. >> >> Thanks, >> Paul >> >> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: >>> The ISDN coding could be IA5 or binary, as determined possibly by the protocol discriminator. Moreover in the ISDN, the protocol discriminator could just be a lie. Noone checks it from one end to the other, and it has no impact on the way the network provides the service. >>> >>> So as far as interworking with the ISDN is concerned, I believe it is best to treat it as always binary. >>> >>> In any case, I do not believe it is appropriate at the interworking gateways to start delving into the protocol discriminator values to work out the best coding mapping. >>> >>> Therefore I believe the best coding mapping for the ISDN application is always map to a binary coding within the header field. What that tranfer coding is could be optimised so one size fits all as we discussed previously on the list. >>> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>>> Behalf Of R.Jesske@telekom.de >>>> Sent: 08 February 2011 14:54 >>>> To: pkyzivat@cisco.com; cuss@ietf.org >>>> Subject: Re: [cuss] Open Issue: Encoding format >>>> >>>> >>>>> >>>>> I've suggested before that instead of defining isdn-interwork as a >>>>> single purpose, that there be a separate purpose defined for each >>>>> valid value of the discriminator byte in the ISDN UUI data. If that >>>>> were done, then it would be much more reasonable to expect a GW to >>>>> convert between sip encodings and ISDN encodings. >>>> >>>> Hi Paul, >>>> I try to understand where you are coming from. >>>> >>>> looking in Q.931 I see the following protocol discriminator values: >>>> >>>> >>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >>>> 0 0 0 0 0 0 0 1 OSI high layer protocols >>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >>>> 0 0 0 0 0 0 1 1 Reserved for system management >>>> convergence function >>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >>>> information (Note 5) >>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption >>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call control messages >>>> >>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or >>>> layer 3 protocols, including Recommendation >>>> through X.25 [5] (Note 3) >>>> 0 0 1 1 1 1 1 1 >>>> >>>> 0 1 0 0 0 0 0 0 >>>> through National use >>>> 0 1 0 0 1 1 1 1 >>>> >>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or >>>> layer 3 protocols, including Recommendation >>>> through X.25 (Note 3) >>>> 1 1 1 1 1 1 1 0 >>>> >>>> So this is the indication how the User Information is coded itself. >>>> >>>> So my question is, what is then understand as a SIP encoding? >>>> >>>> Regards >>>> >>>> Roland >>>> >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> cuss mailing list >>>>> cuss@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>> >>>> _______________________________________________ >>>> cuss mailing list >>>> cuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cuss >>>> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss > From keith.drage@alcatel-lucent.com Wed Feb 9 15:46:10 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD133A672E for ; Wed, 9 Feb 2011 15:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41+TpJV3oIeX for ; Wed, 9 Feb 2011 15:46:09 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 8B4E03A65A6 for ; Wed, 9 Feb 2011 15:46:07 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p19NkEPn023427 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Feb 2011 00:46:14 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 10 Feb 2011 00:46:05 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Alan Johnston Date: Thu, 10 Feb 2011 00:46:04 +0100 Thread-Topic: [cuss] Open Issue: Encoding format Thread-Index: AcvIcPpyM3KN3cBPSjyRlFoso2HHZwANQmcQ Message-ID: References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> In-Reply-To: <4D52B78C.4030708@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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, 09 Feb 2011 23:46:10 -0000 Essentially we have two levels of capability identification defined because= the ISDN protocol discriminator is not apparently flexible enough to do th= is in a non-ISDN environment.=20 The point I was making earlier is that the protocol discriminator in the IS= DN is and end to end label. The ISDN transports something that is binary. T= he network is not responsible for determining whether it is as described by= the protocol discriminator. So the only entities responsible for the usefu= lness, or not, are the two end users. As I regard any gateways between the = SIP environment and the ISDN as being part of the network, be that enterpri= se or public, I don't see why that should end up having any determination b= ased on the protocol discriminator value. ISDN will always have to be assum= ed to be binary. I do have an impression however that much of the use is IA5. I would not fr= om my perspective have a problem if we encoded the binary as for example % = escaped characters or some similar encoding. I suspect this would be compac= t for the majority of ISDN users. But I am not a user of such information, = I work for a company that needs to transport it. Regards Keith=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 09 February 2011 15:50 > To: Alan Johnston > Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org > Subject: Re: [cuss] Open Issue: Encoding format >=20 >=20 >=20 > On 2/9/2011 9:48 AM, Alan Johnston wrote: > > I agree completely with Keith. Gateways have no business=20 > delving into the UUI or the protocol discriminator. This will=20 > only create mistakes and errors. >=20 > It will lead to mistakes or errors if there is discretion or=20 > lack of clarity regarding the mapping. As long as the mapping=20 > is well defined, all should be fine. >=20 > Perhaps I am mistaken, but it certainly appears to me that=20 > the descriminator byte in the Q.931 format serves much the=20 > same purpose that the "purpose" parameter is intended to=20 > serve in the proposed sip uui header. It seems very natural=20 > to me that we make this correlation. >=20 > I guess the counter-argument to that is *if* the prevailing=20 > use of UUI in ISDN entirely ignores the intent of the=20 > discriminator byte, and simply uses the entire string,=20 > including the discriminator byte, as a single data value. I=20 > don't know if that might be the case, or not. (I hope not,=20 > since it is a gross abuse of the Q.931 spec.) >=20 > > My opinion is that for ISDN interworking, the encoding is=20 > the transfer encoding chosen by the Gateway with the ISDN=20 > encoding being assumed to be binary. >=20 > I have some feedback from developers that they do not=20 > appreciate being forced to convert text data to/from hex for=20 > this purpose. It certainly it won't be well appreciated by=20 > those looking at call traces. While its perhaps unavoidable=20 > when the actual data is binary, it is avoidable when the data=20 > is itself text. >=20 > Thanks, > Paul >=20 > > - Alan - > > > > > > > > On Feb 9, 2011, at 7:35 AM, Paul Kyzivat wrote: > > > >> I just replied to Roland on this. But I'll say a little more: > >> > >> One way to handle the conversion from Q.931 to sip would=20 > be "if it can be represented as a sip quoted string, without=20 > escapes, then represent it that way, else represent it as=20 > hex." And the converse conversion could be "convert a sip=20 > quoted string to Q.931 byte for byte, and convert hex to=20 > Q.931 in the obvious way, two hex characters per byte." > >> > >> It could be done this way on the entire Q.931 value,=20 > including the discriminator byte. But that might be less than=20 > satisfactory if the actual data is text, but the chosen=20 > discriminator is not a nice quoted string value. If the=20 > discriminator is separated out, as the purpose value, then it=20 > won't muck up an all-text value. > >> > >> Thanks, > >> Paul > >> > >> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: > >>> The ISDN coding could be IA5 or binary, as determined=20 > possibly by the protocol discriminator. Moreover in the ISDN,=20 > the protocol discriminator could just be a lie. Noone checks=20 > it from one end to the other, and it has no impact on the way=20 > the network provides the service. > >>> > >>> So as far as interworking with the ISDN is concerned, I=20 > believe it is best to treat it as always binary. > >>> > >>> In any case, I do not believe it is appropriate at the=20 > interworking gateways to start delving into the protocol=20 > discriminator values to work out the best coding mapping. > >>> > >>> Therefore I believe the best coding mapping for the ISDN=20 > application is always map to a binary coding within the=20 > header field. What that tranfer coding is could be optimised=20 > so one size fits all as we discussed previously on the list. > >>> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > >>>> Behalf Of R.Jesske@telekom.de > >>>> Sent: 08 February 2011 14:54 > >>>> To: pkyzivat@cisco.com; cuss@ietf.org > >>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>> > >>>> > >>>>> > >>>>> I've suggested before that instead of defining=20 > isdn-interwork as a=20 > >>>>> single purpose, that there be a separate purpose=20 > defined for each=20 > >>>>> valid value of the discriminator byte in the ISDN UUI data. If=20 > >>>>> that were done, then it would be much more reasonable=20 > to expect a=20 > >>>>> GW to convert between sip encodings and ISDN encodings. > >>>> > >>>> Hi Paul, > >>>> I try to understand where you are coming from. > >>>> > >>>> looking in Q.931 I see the following protocol=20 > discriminator values: > >>>> > >>>> > >>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) > >>>> 0 0 0 0 0 0 0 1 OSI high layer protocols > >>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) > >>>> 0 0 0 0 0 0 1 1 Reserved for system management > >>>> convergence function > >>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) > >>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user > >>>> information (Note 5) > >>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption > >>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call=20 > control messages > >>>> > >>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or > >>>> layer 3 protocols, including Recommendation > >>>> through X.25 [5] (Note 3) > >>>> 0 0 1 1 1 1 1 1 > >>>> > >>>> 0 1 0 0 0 0 0 0 > >>>> through National use > >>>> 0 1 0 0 1 1 1 1 > >>>> > >>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or > >>>> layer 3 protocols, including Recommendation > >>>> through X.25 (Note 3) > >>>> 1 1 1 1 1 1 1 0 > >>>> > >>>> So this is the indication how the User Information is=20 > coded itself. > >>>> > >>>> So my question is, what is then understand as a SIP encoding? > >>>> > >>>> Regards > >>>> > >>>> Roland > >>>> > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> _______________________________________________ > >>>>> cuss mailing list > >>>>> cuss@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>> > >>>> _______________________________________________ > >>>> cuss mailing list > >>>> cuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cuss > >>>> > >> _______________________________________________ > >> cuss mailing list > >> cuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/cuss > > > = From pkyzivat@cisco.com Wed Feb 9 19:05:25 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598F03A6806 for ; Wed, 9 Feb 2011 19:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSreaCWaXrxr for ; Wed, 9 Feb 2011 19:05:23 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A909D3A680C for ; Wed, 9 Feb 2011 19:05:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAETkUk1AZnwN/2dsb2JhbAClanOfaZsrhVwEhH+GcYMy X-IronPort-AV: E=Sophos;i="4.60,449,1291593600"; d="scan'208";a="213903604" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2011 03:05:34 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1A35YS4015524; Thu, 10 Feb 2011 03:05:34 GMT Message-ID: <4D5355FE.3030206@cisco.com> Date: Wed, 09 Feb 2011 22:05:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 10 Feb 2011 03:05:25 -0000 First, I just realized that I had "purpose=" and "content=" mixed up in my mind. (And I may still not fully understand the distinction in detail.) Where I have been suggesting multiple purpose values, I think I should have been recommending different "content=" values. On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: > Essentially we have two levels of capability identification defined because the ISDN protocol discriminator is not apparently flexible enough to do this in a non-ISDN environment. > > The point I was making earlier is that the protocol discriminator in the ISDN is and end to end label. The ISDN transports something that is binary. The network is not responsible for determining whether it is as described by the protocol discriminator. So the only entities responsible for the usefulness, or not, are the two end users. As I regard any gateways between the SIP environment and the ISDN as being part of the network, be that enterprise or public, I don't see why that should end up having any determination based on the protocol discriminator value. ISDN will always have to be assumed to be binary. > > I do have an impression however that much of the use is IA5. I would not from my perspective have a problem if we encoded the binary as for example % escaped characters or some similar encoding. I suspect this would be compact for the majority of ISDN users. But I am not a user of such information, I work for a company that needs to transport it. That may work out in many cases, but for seriously binary data it could be quite unpleasant. For the ease of those that wish to restrict themselves to text and don't want to deal with the hex encoding, it would be good if the conversion from Q.931 to sip used the quoted string encoding when that didn't require any escaping, and otherwise use hex. (While it would be possible to define some middle ground, I think it would likely just be annoying.) But the discriminator byte then might well force many usages to hex. I still fail to understand how having separate purposes that map onto specific discriminator values would cause any problem in mapping to/from Q.931. Fundamentally this comes down to how *sip* users of this will perceive it. It doesn't matter at all for Q.931 users, since they will see what they have always seen. And if you have a Q.931-aware *application* that has been ported to sip, *something* will still have to convert between the sip representation and the Q.931 format the application expects, just as a GW will have to do. As a SIP user, I think I would prefer to say: User-to-User: "name=foo,age=33";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5 than: User-to-User: 046E616D653D666F6F2C6167653D3333;encoding=hex;purpose=isdn-interwork;content=isdn or even: User-to-User: "\04name=foo,age=33";encoding=text;purpose=isdn-interwork;content=isdn-uui At the other extreme, I would also prefer to have User-to-User: 0000006500000020;encoding=hex;purpose=isdn-interwork;content=isdn-ia5 than: User-to-User: "\00\00\00A\00\00\00 ";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5 or: User-to-User: "\04\00\00\00A\00\00\00 ";encoding=text;purpose=isdn-interwork;content=isdn-uui Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 09 February 2011 15:50 >> To: Alan Johnston >> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org >> Subject: Re: [cuss] Open Issue: Encoding format >> >> >> >> On 2/9/2011 9:48 AM, Alan Johnston wrote: >>> I agree completely with Keith. Gateways have no business >> delving into the UUI or the protocol discriminator. This will >> only create mistakes and errors. >> >> It will lead to mistakes or errors if there is discretion or >> lack of clarity regarding the mapping. As long as the mapping >> is well defined, all should be fine. >> >> Perhaps I am mistaken, but it certainly appears to me that >> the descriminator byte in the Q.931 format serves much the >> same purpose that the "purpose" parameter is intended to >> serve in the proposed sip uui header. It seems very natural >> to me that we make this correlation. >> >> I guess the counter-argument to that is *if* the prevailing >> use of UUI in ISDN entirely ignores the intent of the >> discriminator byte, and simply uses the entire string, >> including the discriminator byte, as a single data value. I >> don't know if that might be the case, or not. (I hope not, >> since it is a gross abuse of the Q.931 spec.) >> >>> My opinion is that for ISDN interworking, the encoding is >> the transfer encoding chosen by the Gateway with the ISDN >> encoding being assumed to be binary. >> >> I have some feedback from developers that they do not >> appreciate being forced to convert text data to/from hex for >> this purpose. It certainly it won't be well appreciated by >> those looking at call traces. While its perhaps unavoidable >> when the actual data is binary, it is avoidable when the data >> is itself text. >> >> Thanks, >> Paul >> >>> - Alan - >>> >>> >>> >>> On Feb 9, 2011, at 7:35 AM, Paul Kyzivat wrote: >>> >>>> I just replied to Roland on this. But I'll say a little more: >>>> >>>> One way to handle the conversion from Q.931 to sip would >> be "if it can be represented as a sip quoted string, without >> escapes, then represent it that way, else represent it as >> hex." And the converse conversion could be "convert a sip >> quoted string to Q.931 byte for byte, and convert hex to >> Q.931 in the obvious way, two hex characters per byte." >>>> >>>> It could be done this way on the entire Q.931 value, >> including the discriminator byte. But that might be less than >> satisfactory if the actual data is text, but the chosen >> discriminator is not a nice quoted string value. If the >> discriminator is separated out, as the purpose value, then it >> won't muck up an all-text value. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: >>>>> The ISDN coding could be IA5 or binary, as determined >> possibly by the protocol discriminator. Moreover in the ISDN, >> the protocol discriminator could just be a lie. Noone checks >> it from one end to the other, and it has no impact on the way >> the network provides the service. >>>>> >>>>> So as far as interworking with the ISDN is concerned, I >> believe it is best to treat it as always binary. >>>>> >>>>> In any case, I do not believe it is appropriate at the >> interworking gateways to start delving into the protocol >> discriminator values to work out the best coding mapping. >>>>> >>>>> Therefore I believe the best coding mapping for the ISDN >> application is always map to a binary coding within the >> header field. What that tranfer coding is could be optimised >> so one size fits all as we discussed previously on the list. >>>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>>>>> Behalf Of R.Jesske@telekom.de >>>>>> Sent: 08 February 2011 14:54 >>>>>> To: pkyzivat@cisco.com; cuss@ietf.org >>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>> >>>>>> >>>>>>> >>>>>>> I've suggested before that instead of defining >> isdn-interwork as a >>>>>>> single purpose, that there be a separate purpose >> defined for each >>>>>>> valid value of the discriminator byte in the ISDN UUI data. If >>>>>>> that were done, then it would be much more reasonable >> to expect a >>>>>>> GW to convert between sip encodings and ISDN encodings. >>>>>> >>>>>> Hi Paul, >>>>>> I try to understand where you are coming from. >>>>>> >>>>>> looking in Q.931 I see the following protocol >> discriminator values: >>>>>> >>>>>> >>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols >>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >>>>>> 0 0 0 0 0 0 1 1 Reserved for system management >>>>>> convergence function >>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >>>>>> information (Note 5) >>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption >>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call >> control messages >>>>>> >>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or >>>>>> layer 3 protocols, including Recommendation >>>>>> through X.25 [5] (Note 3) >>>>>> 0 0 1 1 1 1 1 1 >>>>>> >>>>>> 0 1 0 0 0 0 0 0 >>>>>> through National use >>>>>> 0 1 0 0 1 1 1 1 >>>>>> >>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or >>>>>> layer 3 protocols, including Recommendation >>>>>> through X.25 (Note 3) >>>>>> 1 1 1 1 1 1 1 0 >>>>>> >>>>>> So this is the indication how the User Information is >> coded itself. >>>>>> >>>>>> So my question is, what is then understand as a SIP encoding? >>>>>> >>>>>> Regards >>>>>> >>>>>> Roland >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> cuss mailing list >>>>>>> cuss@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>> >>>>>> _______________________________________________ >>>>>> cuss mailing list >>>>>> cuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>> >>>> _______________________________________________ >>>> cuss mailing list >>>> cuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cuss >>> >> From john.elwell@siemens-enterprise.com Thu Feb 10 00:50:37 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7E93A6933 for ; Thu, 10 Feb 2011 00:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBeCWfa0PrYq for ; Thu, 10 Feb 2011 00:50:35 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id AEA273A69B7 for ; Thu, 10 Feb 2011 00:50:33 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3345668; Thu, 10 Feb 2011 09:50:44 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 9BE4A1EB82AB; Thu, 10 Feb 2011 09:50:44 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 10 Feb 2011 09:50:44 +0100 From: "Elwell, John" To: Paul Kyzivat , "DRAGE, Keith (Keith)" Date: Thu, 10 Feb 2011 09:50:43 +0100 Thread-Topic: [cuss] Open Issue: Encoding format Thread-Index: AcvIz2dgMi2xb+5KR7OgLrDUHEYgYwALy7tw Message-ID: References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> <4D5355FE.3030206@cisco.com> In-Reply-To: <4D5355FE.3030206@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 10 Feb 2011 08:50:37 -0000 I think we would be going down a rat hole if we required any sort of conver= sion at ISDN gateways. End-to-end transparent transport would seem to match= best the intended purpose of the ISDN service and its use in practice. If we want a separate text format for use between SIP UAs when ISDN is not = involved, that might make sense. However, an ISDN gateway would not pass th= is on, so one would need to avoid using this format if expecting to interop= erate with ISDN. If we do perform any conversion at ISDN gateways, we must at least ensure i= t is symmetrical, in the sense of what is received from ISDN at UA A gets s= ent in exactly the same form to ISDN at UA B. Performing no conversion is t= he simplest way of achieving this. John > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 10 February 2011 03:06 > To: DRAGE, Keith (Keith) > Cc: R.Jesske@telekom.de; cuss@ietf.org > Subject: Re: [cuss] Open Issue: Encoding format >=20 > First, I just realized that I had "purpose=3D" and "content=3D"=20 > mixed up in=20 > my mind. (And I may still not fully understand the distinction in=20 > detail.) Where I have been suggesting multiple purpose=20 > values, I think I=20 > should have been recommending different "content=3D" values. >=20 > On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: > > Essentially we have two levels of capability identification=20 > defined because the ISDN protocol discriminator is not=20 > apparently flexible enough to do this in a non-ISDN environment. > > > > The point I was making earlier is that the protocol=20 > discriminator in the ISDN is and end to end label. The ISDN=20 > transports something that is binary. The network is not=20 > responsible for determining whether it is as described by the=20 > protocol discriminator. So the only entities responsible for=20 > the usefulness, or not, are the two end users. As I regard=20 > any gateways between the SIP environment and the ISDN as=20 > being part of the network, be that enterprise or public, I=20 > don't see why that should end up having any determination=20 > based on the protocol discriminator value. ISDN will always=20 > have to be assumed to be binary. > > > > I do have an impression however that much of the use is=20 > IA5. I would not from my perspective have a problem if we=20 > encoded the binary as for example % escaped characters or=20 > some similar encoding. I suspect this would be compact for=20 > the majority of ISDN users. But I am not a user of such=20 > information, I work for a company that needs to transport it. >=20 > That may work out in many cases, but for seriously binary=20 > data it could=20 > be quite unpleasant. >=20 > For the ease of those that wish to restrict themselves to=20 > text and don't=20 > want to deal with the hex encoding, it would be good if the=20 > conversion=20 > from Q.931 to sip used the quoted string encoding when that didn't=20 > require any escaping, and otherwise use hex. >=20 > (While it would be possible to define some middle ground, I think it=20 > would likely just be annoying.) >=20 > But the discriminator byte then might well force many usages to hex. >=20 > I still fail to understand how having separate purposes that map onto=20 > specific discriminator values would cause any problem in=20 > mapping to/from=20 > Q.931. >=20 > Fundamentally this comes down to how *sip* users of this will=20 > perceive=20 > it. It doesn't matter at all for Q.931 users, since they will=20 > see what=20 > they have always seen. And if you have a Q.931-aware=20 > *application* that=20 > has been ported to sip, *something* will still have to=20 > convert between=20 > the sip representation and the Q.931 format the application expects,=20 > just as a GW will have to do. >=20 > As a SIP user, I think I would prefer to say: >=20 > User-to-User:=20 > "name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Disdn-interwork;content > =3Disdn-uui-ia5 >=20 > than: >=20 > User-to-User:=20 > 046E616D653D666F6F2C6167653D3333;encoding=3Dhex;purpose=3Disdn-int > erwork;content=3Disdn >=20 > or even: >=20 > User-to-User:=20 > "\04name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Disdn-interwork;cont > ent=3Disdn-uui >=20 > At the other extreme, I would also prefer to have >=20 > User-to-User:=20 > 0000006500000020;encoding=3Dhex;purpose=3Disdn-interwork;content=3Disdn-i= a5 >=20 > than: >=20 > User-to-User: "\00\00\00A\00\00\00=20 > ";encoding=3Dtext;purpose=3Disdn-interwork;content=3Disdn-uui-ia5 >=20 > or: >=20 > User-to-User: "\04\00\00\00A\00\00\00=20 > ";encoding=3Dtext;purpose=3Disdn-interwork;content=3Disdn-uui >=20 > Thanks, > Paul >=20 >=20 > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: 09 February 2011 15:50 > >> To: Alan Johnston > >> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org > >> Subject: Re: [cuss] Open Issue: Encoding format > >> > >> > >> > >> On 2/9/2011 9:48 AM, Alan Johnston wrote: > >>> I agree completely with Keith. Gateways have no business > >> delving into the UUI or the protocol discriminator. This will > >> only create mistakes and errors. > >> > >> It will lead to mistakes or errors if there is discretion or > >> lack of clarity regarding the mapping. As long as the mapping > >> is well defined, all should be fine. > >> > >> Perhaps I am mistaken, but it certainly appears to me that > >> the descriminator byte in the Q.931 format serves much the > >> same purpose that the "purpose" parameter is intended to > >> serve in the proposed sip uui header. It seems very natural > >> to me that we make this correlation. > >> > >> I guess the counter-argument to that is *if* the prevailing > >> use of UUI in ISDN entirely ignores the intent of the > >> discriminator byte, and simply uses the entire string, > >> including the discriminator byte, as a single data value. I > >> don't know if that might be the case, or not. (I hope not, > >> since it is a gross abuse of the Q.931 spec.) > >> > >>> My opinion is that for ISDN interworking, the encoding is > >> the transfer encoding chosen by the Gateway with the ISDN > >> encoding being assumed to be binary. > >> > >> I have some feedback from developers that they do not > >> appreciate being forced to convert text data to/from hex for > >> this purpose. It certainly it won't be well appreciated by > >> those looking at call traces. While its perhaps unavoidable > >> when the actual data is binary, it is avoidable when the data > >> is itself text. > >> > >> Thanks, > >> Paul > >> > >>> - Alan - > >>> > >>> > >>> > >>> On Feb 9, 2011, at 7:35 AM, Paul=20 > Kyzivat wrote: > >>> > >>>> I just replied to Roland on this. But I'll say a little more: > >>>> > >>>> One way to handle the conversion from Q.931 to sip would > >> be "if it can be represented as a sip quoted string, without > >> escapes, then represent it that way, else represent it as > >> hex." And the converse conversion could be "convert a sip > >> quoted string to Q.931 byte for byte, and convert hex to > >> Q.931 in the obvious way, two hex characters per byte." > >>>> > >>>> It could be done this way on the entire Q.931 value, > >> including the discriminator byte. But that might be less than > >> satisfactory if the actual data is text, but the chosen > >> discriminator is not a nice quoted string value. If the > >> discriminator is separated out, as the purpose value, then it > >> won't muck up an all-text value. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: > >>>>> The ISDN coding could be IA5 or binary, as determined > >> possibly by the protocol discriminator. Moreover in the ISDN, > >> the protocol discriminator could just be a lie. Noone checks > >> it from one end to the other, and it has no impact on the way > >> the network provides the service. > >>>>> > >>>>> So as far as interworking with the ISDN is concerned, I > >> believe it is best to treat it as always binary. > >>>>> > >>>>> In any case, I do not believe it is appropriate at the > >> interworking gateways to start delving into the protocol > >> discriminator values to work out the best coding mapping. > >>>>> > >>>>> Therefore I believe the best coding mapping for the ISDN > >> application is always map to a binary coding within the > >> header field. What that tranfer coding is could be optimised > >> so one size fits all as we discussed previously on the list. > >>>>> > >>>>> Regards > >>>>> > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On > >>>>>> Behalf Of R.Jesske@telekom.de > >>>>>> Sent: 08 February 2011 14:54 > >>>>>> To: pkyzivat@cisco.com; cuss@ietf.org > >>>>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> I've suggested before that instead of defining > >> isdn-interwork as a > >>>>>>> single purpose, that there be a separate purpose > >> defined for each > >>>>>>> valid value of the discriminator byte in the ISDN UUI data. If > >>>>>>> that were done, then it would be much more reasonable > >> to expect a > >>>>>>> GW to convert between sip encodings and ISDN encodings. > >>>>>> > >>>>>> Hi Paul, > >>>>>> I try to understand where you are coming from. > >>>>>> > >>>>>> looking in Q.931 I see the following protocol > >> discriminator values: > >>>>>> > >>>>>> > >>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) > >>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols > >>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) > >>>>>> 0 0 0 0 0 0 1 1 Reserved for system management > >>>>>> convergence function > >>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) > >>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user > >>>>>> information (Note 5) > >>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption > >>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call > >> control messages > >>>>>> > >>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or > >>>>>> layer 3 protocols, including Recommendation > >>>>>> through X.25 [5] (Note 3) > >>>>>> 0 0 1 1 1 1 1 1 > >>>>>> > >>>>>> 0 1 0 0 0 0 0 0 > >>>>>> through National use > >>>>>> 0 1 0 0 1 1 1 1 > >>>>>> > >>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or > >>>>>> layer 3 protocols, including Recommendation > >>>>>> through X.25 (Note 3) > >>>>>> 1 1 1 1 1 1 1 0 > >>>>>> > >>>>>> So this is the indication how the User Information is > >> coded itself. > >>>>>> > >>>>>> So my question is, what is then understand as a SIP encoding? > >>>>>> > >>>>>> Regards > >>>>>> > >>>>>> Roland > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> _______________________________________________ > >>>>>>> cuss mailing list > >>>>>>> cuss@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> cuss mailing list > >>>>>> cuss@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>> > >>>> _______________________________________________ > >>>> cuss mailing list > >>>> cuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cuss > >>> > >> > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From pkyzivat@cisco.com Thu Feb 10 08:33:29 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B713A67A2 for ; Thu, 10 Feb 2011 08:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd-DWgUY7eXo for ; Thu, 10 Feb 2011 08:33:26 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9000F3A659A for ; Thu, 10 Feb 2011 08:33:25 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACCiU01AZnwN/2dsb2JhbAClaXOeeZtDhVwEhQGGeIMy X-IronPort-AV: E=Sophos;i="4.60,451,1291593600"; d="scan'208";a="213892136" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2011 16:33:37 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1AGXbUt015625; Thu, 10 Feb 2011 16:33:37 GMT Message-ID: <4D541361.2070506@cisco.com> Date: Thu, 10 Feb 2011 11:33:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Elwell, John" References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> <4D5355FE.3030206@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 10 Feb 2011 16:33:30 -0000 On 2/10/2011 3:50 AM, Elwell, John wrote: > I think we would be going down a rat hole if we required any sort of conversion at ISDN gateways. End-to-end transparent transport would seem to match best the intended purpose of the ISDN service and its use in practice. The proposed hex format *already* requires a conversion by ISDN gateways. Arguably, a quoted string representation would require *less* effort by a gateway, as long as the chars are converted 1:1. The "advantage" of hex, if its the *only* encoding, is that it is done identically for every character. But its not especially friendly for applications or for reading message dumps. > If we want a separate text format for use between SIP UAs when ISDN is not involved, that might make sense. However, an ISDN gateway would not pass this on, so one would need to avoid using this format if expecting to interoperate with ISDN. Yes, we could say that hex is the *only* format when the content is isdn-uui. Then the question is: when would anything else ever be used? I'm having trouble envisioning a path to use of any content other than isdn-uui or a purpose other than isdn-interwork. That is part of my difficulty in discriminating between content and purpose. AFAIK the purpose of UUI is *never* "isdn-interwork". It is something like: "pass info from IVR to call center". Accomplishing that may or may not require isdn-interworking. That depends on the equipment deployed, and the IVR sending the UUI might not know. > If we do perform any conversion at ISDN gateways, we must at least ensure it is symmetrical, in the sense of what is received from ISDN at UA A gets sent in exactly the same form to ISDN at UA B. Performing no conversion is the simplest way of achieving this. I don't think it needs to be symmetrical. There should be a single well defined sip representation for each ISDN uui value. A GW should always produce that value when converting from ISDN to sip. And a GW should of course also accept that representation and convert it consistently when going from SIP to ISDN. But there could be alternative sip representations that the GW is also capable of converting to ISDN. For instance, we could go with quoted strings as the sip representation. In that case, the preferred representation would be to convert each ISDN byte to corresponding quoted character when that is allowed, and to use \nn only when necessary. But converting the other way would presumably permit other characters to be represented using the \nn form. I am about to give up on this. I don't care *that much*. I was hoping to get something that seems reasonable as a native sip facility, that also happens to interwork with ISDN. It seems we are on a path that results in all the limitations and ugliness of the Q.931 mechanism with another piled on layer of ugliness and inconvenience to wedge it into SIP. Apparently everybody else thinks that is fine. Thanks, Paul > John > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 10 February 2011 03:06 >> To: DRAGE, Keith (Keith) >> Cc: R.Jesske@telekom.de; cuss@ietf.org >> Subject: Re: [cuss] Open Issue: Encoding format >> >> First, I just realized that I had "purpose=" and "content=" >> mixed up in >> my mind. (And I may still not fully understand the distinction in >> detail.) Where I have been suggesting multiple purpose >> values, I think I >> should have been recommending different "content=" values. >> >> On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: >>> Essentially we have two levels of capability identification >> defined because the ISDN protocol discriminator is not >> apparently flexible enough to do this in a non-ISDN environment. >>> >>> The point I was making earlier is that the protocol >> discriminator in the ISDN is and end to end label. The ISDN >> transports something that is binary. The network is not >> responsible for determining whether it is as described by the >> protocol discriminator. So the only entities responsible for >> the usefulness, or not, are the two end users. As I regard >> any gateways between the SIP environment and the ISDN as >> being part of the network, be that enterprise or public, I >> don't see why that should end up having any determination >> based on the protocol discriminator value. ISDN will always >> have to be assumed to be binary. >>> >>> I do have an impression however that much of the use is >> IA5. I would not from my perspective have a problem if we >> encoded the binary as for example % escaped characters or >> some similar encoding. I suspect this would be compact for >> the majority of ISDN users. But I am not a user of such >> information, I work for a company that needs to transport it. >> >> That may work out in many cases, but for seriously binary >> data it could >> be quite unpleasant. >> >> For the ease of those that wish to restrict themselves to >> text and don't >> want to deal with the hex encoding, it would be good if the >> conversion >> from Q.931 to sip used the quoted string encoding when that didn't >> require any escaping, and otherwise use hex. >> >> (While it would be possible to define some middle ground, I think it >> would likely just be annoying.) >> >> But the discriminator byte then might well force many usages to hex. >> >> I still fail to understand how having separate purposes that map onto >> specific discriminator values would cause any problem in >> mapping to/from >> Q.931. >> >> Fundamentally this comes down to how *sip* users of this will >> perceive >> it. It doesn't matter at all for Q.931 users, since they will >> see what >> they have always seen. And if you have a Q.931-aware >> *application* that >> has been ported to sip, *something* will still have to >> convert between >> the sip representation and the Q.931 format the application expects, >> just as a GW will have to do. >> >> As a SIP user, I think I would prefer to say: >> >> User-to-User: >> "name=foo,age=33";encoding=text;purpose=isdn-interwork;content >> =isdn-uui-ia5 >> >> than: >> >> User-to-User: >> 046E616D653D666F6F2C6167653D3333;encoding=hex;purpose=isdn-int >> erwork;content=isdn >> >> or even: >> >> User-to-User: >> "\04name=foo,age=33";encoding=text;purpose=isdn-interwork;cont >> ent=isdn-uui >> >> At the other extreme, I would also prefer to have >> >> User-to-User: >> 0000006500000020;encoding=hex;purpose=isdn-interwork;content=isdn-ia5 >> >> than: >> >> User-to-User: "\00\00\00A\00\00\00 >> ";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5 >> >> or: >> >> User-to-User: "\04\00\00\00A\00\00\00 >> ";encoding=text;purpose=isdn-interwork;content=isdn-uui >> >> Thanks, >> Paul >> >> >>> Regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: 09 February 2011 15:50 >>>> To: Alan Johnston >>>> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org >>>> Subject: Re: [cuss] Open Issue: Encoding format >>>> >>>> >>>> >>>> On 2/9/2011 9:48 AM, Alan Johnston wrote: >>>>> I agree completely with Keith. Gateways have no business >>>> delving into the UUI or the protocol discriminator. This will >>>> only create mistakes and errors. >>>> >>>> It will lead to mistakes or errors if there is discretion or >>>> lack of clarity regarding the mapping. As long as the mapping >>>> is well defined, all should be fine. >>>> >>>> Perhaps I am mistaken, but it certainly appears to me that >>>> the descriminator byte in the Q.931 format serves much the >>>> same purpose that the "purpose" parameter is intended to >>>> serve in the proposed sip uui header. It seems very natural >>>> to me that we make this correlation. >>>> >>>> I guess the counter-argument to that is *if* the prevailing >>>> use of UUI in ISDN entirely ignores the intent of the >>>> discriminator byte, and simply uses the entire string, >>>> including the discriminator byte, as a single data value. I >>>> don't know if that might be the case, or not. (I hope not, >>>> since it is a gross abuse of the Q.931 spec.) >>>> >>>>> My opinion is that for ISDN interworking, the encoding is >>>> the transfer encoding chosen by the Gateway with the ISDN >>>> encoding being assumed to be binary. >>>> >>>> I have some feedback from developers that they do not >>>> appreciate being forced to convert text data to/from hex for >>>> this purpose. It certainly it won't be well appreciated by >>>> those looking at call traces. While its perhaps unavoidable >>>> when the actual data is binary, it is avoidable when the data >>>> is itself text. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> - Alan - >>>>> >>>>> >>>>> >>>>> On Feb 9, 2011, at 7:35 AM, Paul >> Kyzivat wrote: >>>>> >>>>>> I just replied to Roland on this. But I'll say a little more: >>>>>> >>>>>> One way to handle the conversion from Q.931 to sip would >>>> be "if it can be represented as a sip quoted string, without >>>> escapes, then represent it that way, else represent it as >>>> hex." And the converse conversion could be "convert a sip >>>> quoted string to Q.931 byte for byte, and convert hex to >>>> Q.931 in the obvious way, two hex characters per byte." >>>>>> >>>>>> It could be done this way on the entire Q.931 value, >>>> including the discriminator byte. But that might be less than >>>> satisfactory if the actual data is text, but the chosen >>>> discriminator is not a nice quoted string value. If the >>>> discriminator is separated out, as the purpose value, then it >>>> won't muck up an all-text value. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: >>>>>>> The ISDN coding could be IA5 or binary, as determined >>>> possibly by the protocol discriminator. Moreover in the ISDN, >>>> the protocol discriminator could just be a lie. Noone checks >>>> it from one end to the other, and it has no impact on the way >>>> the network provides the service. >>>>>>> >>>>>>> So as far as interworking with the ISDN is concerned, I >>>> believe it is best to treat it as always binary. >>>>>>> >>>>>>> In any case, I do not believe it is appropriate at the >>>> interworking gateways to start delving into the protocol >>>> discriminator values to work out the best coding mapping. >>>>>>> >>>>>>> Therefore I believe the best coding mapping for the ISDN >>>> application is always map to a binary coding within the >>>> header field. What that tranfer coding is could be optimised >>>> so one size fits all as we discussed previously on the list. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>>>>>>> Behalf Of R.Jesske@telekom.de >>>>>>>> Sent: 08 February 2011 14:54 >>>>>>>> To: pkyzivat@cisco.com; cuss@ietf.org >>>>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I've suggested before that instead of defining >>>> isdn-interwork as a >>>>>>>>> single purpose, that there be a separate purpose >>>> defined for each >>>>>>>>> valid value of the discriminator byte in the ISDN UUI data. If >>>>>>>>> that were done, then it would be much more reasonable >>>> to expect a >>>>>>>>> GW to convert between sip encodings and ISDN encodings. >>>>>>>> >>>>>>>> Hi Paul, >>>>>>>> I try to understand where you are coming from. >>>>>>>> >>>>>>>> looking in Q.931 I see the following protocol >>>> discriminator values: >>>>>>>> >>>>>>>> >>>>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >>>>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols >>>>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >>>>>>>> 0 0 0 0 0 0 1 1 Reserved for system management >>>>>>>> convergence function >>>>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >>>>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >>>>>>>> information (Note 5) >>>>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] rate adaption >>>>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call >>>> control messages >>>>>>>> >>>>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or >>>>>>>> layer 3 protocols, including Recommendation >>>>>>>> through X.25 [5] (Note 3) >>>>>>>> 0 0 1 1 1 1 1 1 >>>>>>>> >>>>>>>> 0 1 0 0 0 0 0 0 >>>>>>>> through National use >>>>>>>> 0 1 0 0 1 1 1 1 >>>>>>>> >>>>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or >>>>>>>> layer 3 protocols, including Recommendation >>>>>>>> through X.25 (Note 3) >>>>>>>> 1 1 1 1 1 1 1 0 >>>>>>>> >>>>>>>> So this is the indication how the User Information is >>>> coded itself. >>>>>>>> >>>>>>>> So my question is, what is then understand as a SIP encoding? >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Roland >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> _______________________________________________ >>>>>>>>> cuss mailing list >>>>>>>>> cuss@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cuss mailing list >>>>>>>> cuss@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>> >>>>>> _______________________________________________ >>>>>> cuss mailing list >>>>>> cuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>> >>>> >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> From R.Jesske@telekom.de Fri Feb 11 05:47:24 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C7E3A6964 for ; Fri, 11 Feb 2011 05:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubCfYyRQnHLu for ; Fri, 11 Feb 2011 05:47:22 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id EBC2E3A6817 for ; Fri, 11 Feb 2011 05:47:21 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 11 Feb 2011 14:47:31 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.189]) by he110890 ([10.134.92.131]) with mapi; Fri, 11 Feb 2011 14:47:30 +0100 From: To: , Date: Fri, 11 Feb 2011 14:47:29 +0100 Thread-Topic: [cuss] Open Issue: Encoding format Thread-Index: AcvJQFGemKZTxVDTTDuVllmWNTbiNAAsQ7mQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0100893150@HE111648.emea1.cds.t-internal.com> References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> <4D5355FE.3030206@cisco.com> <4D541361.2070506@cisco.com> In-Reply-To: <4D541361.2070506@cisco.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: L.Liess@telekom.de, cuss@ietf.org Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Feb 2011 13:47:24 -0000 Paul, > I am about to give up on this. I don't care *that much*. I > was hoping to > get something that seems reasonable as a native sip facility, > that also > happens to interwork with ISDN. It seems we are on a path > that results > in all the limitations and ugliness of the Q.931 mechanism > with another > piled on layer of ugliness and inconvenience to wedge it into SIP. > Apparently everybody else thinks that is fine. Do I understand you correct that you would like also to see something like = that: User-to-User: "name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Dsip;content =3Dsip-uui-ia5 So this would make the SIP UUI interworkable. And in parallel we would have also the ISDN-UUI as an hex coded string whic= h can then be passed between ISDN applications. Where we are looking on. I don't know what people are thinking on that. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Donnerstag, 10. Februar 2011 17:34 > An: Elwell, John > Cc: DRAGE, Keith (Keith); Jesske, Roland; cuss@ietf.org > Betreff: Re: [cuss] Open Issue: Encoding format > > > > On 2/10/2011 3:50 AM, Elwell, John wrote: > > I think we would be going down a rat hole if we required > any sort of conversion at ISDN gateways. End-to-end > transparent transport would seem to match best the intended > purpose of the ISDN service and its use in practice. > > The proposed hex format *already* requires a conversion by ISDN > gateways. Arguably, a quoted string representation would > require *less* > effort by a gateway, as long as the chars are converted 1:1. > > The "advantage" of hex, if its the *only* encoding, is that > it is done > identically for every character. But its not especially friendly for > applications or for reading message dumps. > > > If we want a separate text format for use between SIP UAs > when ISDN is not involved, that might make sense. However, an > ISDN gateway would not pass this on, so one would need to > avoid using this format if expecting to interoperate with ISDN. > > Yes, we could say that hex is the *only* format when the content is > isdn-uui. Then the question is: when would anything else ever > be used? > I'm having trouble envisioning a path to use of any content > other than > isdn-uui or a purpose other than isdn-interwork. > > That is part of my difficulty in discriminating between content and > purpose. AFAIK the purpose of UUI is *never* "isdn-interwork". It is > something like: "pass info from IVR to call center". > Accomplishing that > may or may not require isdn-interworking. That depends on the > equipment > deployed, and the IVR sending the UUI might not know. > > > If we do perform any conversion at ISDN gateways, we must > at least ensure it is symmetrical, in the sense of what is > received from ISDN at UA A gets sent in exactly the same form > to ISDN at UA B. Performing no conversion is the simplest way > of achieving this. > > I don't think it needs to be symmetrical. There should be a > single well > defined sip representation for each ISDN uui value. A GW > should always > produce that value when converting from ISDN to sip. And a GW > should of > course also accept that representation and convert it > consistently when > going from SIP to ISDN. But there could be alternative sip > representations that the GW is also capable of converting to ISDN. > > For instance, we could go with quoted strings as the sip > representation. > In that case, the preferred representation would be to > convert each ISDN > byte to corresponding quoted character when that is allowed, > and to use > \nn only when necessary. But converting the other way would > presumably > permit other characters to be represented using the \nn form. > > > > I am about to give up on this. I don't care *that much*. I > was hoping to > get something that seems reasonable as a native sip facility, > that also > happens to interwork with ISDN. It seems we are on a path > that results > in all the limitations and ugliness of the Q.931 mechanism > with another > piled on layer of ugliness and inconvenience to wedge it into SIP. > Apparently everybody else thinks that is fine. > > > > Thanks, > Paul > > > John > > > >> -----Original Message----- > >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: 10 February 2011 03:06 > >> To: DRAGE, Keith (Keith) > >> Cc: R.Jesske@telekom.de; cuss@ietf.org > >> Subject: Re: [cuss] Open Issue: Encoding format > >> > >> First, I just realized that I had "purpose=3D" and "content=3D" > >> mixed up in > >> my mind. (And I may still not fully understand the distinction in > >> detail.) Where I have been suggesting multiple purpose > >> values, I think I > >> should have been recommending different "content=3D" values. > >> > >> On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: > >>> Essentially we have two levels of capability identification > >> defined because the ISDN protocol discriminator is not > >> apparently flexible enough to do this in a non-ISDN environment. > >>> > >>> The point I was making earlier is that the protocol > >> discriminator in the ISDN is and end to end label. The ISDN > >> transports something that is binary. The network is not > >> responsible for determining whether it is as described by the > >> protocol discriminator. So the only entities responsible for > >> the usefulness, or not, are the two end users. As I regard > >> any gateways between the SIP environment and the ISDN as > >> being part of the network, be that enterprise or public, I > >> don't see why that should end up having any determination > >> based on the protocol discriminator value. ISDN will always > >> have to be assumed to be binary. > >>> > >>> I do have an impression however that much of the use is > >> IA5. I would not from my perspective have a problem if we > >> encoded the binary as for example % escaped characters or > >> some similar encoding. I suspect this would be compact for > >> the majority of ISDN users. But I am not a user of such > >> information, I work for a company that needs to transport it. > >> > >> That may work out in many cases, but for seriously binary > >> data it could > >> be quite unpleasant. > >> > >> For the ease of those that wish to restrict themselves to > >> text and don't > >> want to deal with the hex encoding, it would be good if the > >> conversion > >> from Q.931 to sip used the quoted string encoding when that didn't > >> require any escaping, and otherwise use hex. > >> > >> (While it would be possible to define some middle ground, > I think it > >> would likely just be annoying.) > >> > >> But the discriminator byte then might well force many > usages to hex. > >> > >> I still fail to understand how having separate purposes > that map onto > >> specific discriminator values would cause any problem in > >> mapping to/from > >> Q.931. > >> > >> Fundamentally this comes down to how *sip* users of this will > >> perceive > >> it. It doesn't matter at all for Q.931 users, since they will > >> see what > >> they have always seen. And if you have a Q.931-aware > >> *application* that > >> has been ported to sip, *something* will still have to > >> convert between > >> the sip representation and the Q.931 format the > application expects, > >> just as a GW will have to do. > >> > >> As a SIP user, I think I would prefer to say: > >> > >> User-to-User: > >> "name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Disdn-interwork;content > >> =3Disdn-uui-ia5 > >> > >> than: > >> > >> User-to-User: > >> 046E616D653D666F6F2C6167653D3333;encoding=3Dhex;purpose=3Disdn-int > >> erwork;content=3Disdn > >> > >> or even: > >> > >> User-to-User: > >> "\04name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Disdn-interwork;cont > >> ent=3Disdn-uui > >> > >> At the other extreme, I would also prefer to have > >> > >> User-to-User: > >> > 0000006500000020;encoding=3Dhex;purpose=3Disdn-interwork;content=3Disdn-i= a5 > >> > >> than: > >> > >> User-to-User: "\00\00\00A\00\00\00 > >> ";encoding=3Dtext;purpose=3Disdn-interwork;content=3Disdn-uui-ia5 > >> > >> or: > >> > >> User-to-User: "\04\00\00\00A\00\00\00 > >> ";encoding=3Dtext;purpose=3Disdn-interwork;content=3Disdn-uui > >> > >> Thanks, > >> Paul > >> > >> > >>> Regards > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: 09 February 2011 15:50 > >>>> To: Alan Johnston > >>>> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org > >>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>> > >>>> > >>>> > >>>> On 2/9/2011 9:48 AM, Alan Johnston wrote: > >>>>> I agree completely with Keith. Gateways have no business > >>>> delving into the UUI or the protocol discriminator. This will > >>>> only create mistakes and errors. > >>>> > >>>> It will lead to mistakes or errors if there is discretion or > >>>> lack of clarity regarding the mapping. As long as the mapping > >>>> is well defined, all should be fine. > >>>> > >>>> Perhaps I am mistaken, but it certainly appears to me that > >>>> the descriminator byte in the Q.931 format serves much the > >>>> same purpose that the "purpose" parameter is intended to > >>>> serve in the proposed sip uui header. It seems very natural > >>>> to me that we make this correlation. > >>>> > >>>> I guess the counter-argument to that is *if* the prevailing > >>>> use of UUI in ISDN entirely ignores the intent of the > >>>> discriminator byte, and simply uses the entire string, > >>>> including the discriminator byte, as a single data value. I > >>>> don't know if that might be the case, or not. (I hope not, > >>>> since it is a gross abuse of the Q.931 spec.) > >>>> > >>>>> My opinion is that for ISDN interworking, the encoding is > >>>> the transfer encoding chosen by the Gateway with the ISDN > >>>> encoding being assumed to be binary. > >>>> > >>>> I have some feedback from developers that they do not > >>>> appreciate being forced to convert text data to/from hex for > >>>> this purpose. It certainly it won't be well appreciated by > >>>> those looking at call traces. While its perhaps unavoidable > >>>> when the actual data is binary, it is avoidable when the data > >>>> is itself text. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> - Alan - > >>>>> > >>>>> > >>>>> > >>>>> On Feb 9, 2011, at 7:35 AM, Paul > >> Kyzivat wrote: > >>>>> > >>>>>> I just replied to Roland on this. But I'll say a little more: > >>>>>> > >>>>>> One way to handle the conversion from Q.931 to sip would > >>>> be "if it can be represented as a sip quoted string, without > >>>> escapes, then represent it that way, else represent it as > >>>> hex." And the converse conversion could be "convert a sip > >>>> quoted string to Q.931 byte for byte, and convert hex to > >>>> Q.931 in the obvious way, two hex characters per byte." > >>>>>> > >>>>>> It could be done this way on the entire Q.931 value, > >>>> including the discriminator byte. But that might be less than > >>>> satisfactory if the actual data is text, but the chosen > >>>> discriminator is not a nice quoted string value. If the > >>>> discriminator is separated out, as the purpose value, then it > >>>> won't muck up an all-text value. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: > >>>>>>> The ISDN coding could be IA5 or binary, as determined > >>>> possibly by the protocol discriminator. Moreover in the ISDN, > >>>> the protocol discriminator could just be a lie. Noone checks > >>>> it from one end to the other, and it has no impact on the way > >>>> the network provides the service. > >>>>>>> > >>>>>>> So as far as interworking with the ISDN is concerned, I > >>>> believe it is best to treat it as always binary. > >>>>>>> > >>>>>>> In any case, I do not believe it is appropriate at the > >>>> interworking gateways to start delving into the protocol > >>>> discriminator values to work out the best coding mapping. > >>>>>>> > >>>>>>> Therefore I believe the best coding mapping for the ISDN > >>>> application is always map to a binary coding within the > >>>> header field. What that tranfer coding is could be optimised > >>>> so one size fits all as we discussed previously on the list. > >>>>>>> > >>>>>>> Regards > >>>>>>> > >>>>>>> Keith > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On > >>>>>>>> Behalf Of R.Jesske@telekom.de > >>>>>>>> Sent: 08 February 2011 14:54 > >>>>>>>> To: pkyzivat@cisco.com; cuss@ietf.org > >>>>>>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> I've suggested before that instead of defining > >>>> isdn-interwork as a > >>>>>>>>> single purpose, that there be a separate purpose > >>>> defined for each > >>>>>>>>> valid value of the discriminator byte in the ISDN > UUI data. If > >>>>>>>>> that were done, then it would be much more reasonable > >>>> to expect a > >>>>>>>>> GW to convert between sip encodings and ISDN encodings. > >>>>>>>> > >>>>>>>> Hi Paul, > >>>>>>>> I try to understand where you are coming from. > >>>>>>>> > >>>>>>>> looking in Q.931 I see the following protocol > >>>> discriminator values: > >>>>>>>> > >>>>>>>> > >>>>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) > >>>>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols > >>>>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) > >>>>>>>> 0 0 0 0 0 0 1 1 Reserved for system management > >>>>>>>> convergence function > >>>>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) > >>>>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user > >>>>>>>> information (Note 5) > >>>>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] > rate adaption > >>>>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call > >>>> control messages > >>>>>>>> > >>>>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or > >>>>>>>> layer 3 protocols, including Recommendation > >>>>>>>> through X.25 [5] (Note 3) > >>>>>>>> 0 0 1 1 1 1 1 1 > >>>>>>>> > >>>>>>>> 0 1 0 0 0 0 0 0 > >>>>>>>> through National use > >>>>>>>> 0 1 0 0 1 1 1 1 > >>>>>>>> > >>>>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or > >>>>>>>> layer 3 protocols, including Recommendation > >>>>>>>> through X.25 (Note 3) > >>>>>>>> 1 1 1 1 1 1 1 0 > >>>>>>>> > >>>>>>>> So this is the indication how the User Information is > >>>> coded itself. > >>>>>>>> > >>>>>>>> So my question is, what is then understand as a SIP encoding? > >>>>>>>> > >>>>>>>> Regards > >>>>>>>> > >>>>>>>> Roland > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> Paul > >>>>>>>>> _______________________________________________ > >>>>>>>>> cuss mailing list > >>>>>>>>> cuss@ietf.org > >>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> cuss mailing list > >>>>>>>> cuss@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>>>> > >>>>>> _______________________________________________ > >>>>>> cuss mailing list > >>>>>> cuss@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>> > >>>> > >> _______________________________________________ > >> cuss mailing list > >> cuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/cuss > >> > From pkyzivat@cisco.com Fri Feb 11 06:14:57 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86B943A6A5D for ; Fri, 11 Feb 2011 06:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgZFG+VDH2hj for ; Fri, 11 Feb 2011 06:14:55 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 287A03A69AB for ; Fri, 11 Feb 2011 06:14:55 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMjSVE1AZnwM/2dsb2JhbACldHOfQZs4hV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="214268224" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Feb 2011 14:15:09 +0000 Received: from [10.86.251.15] (bxb-vpn3-783.cisco.com [10.86.251.15]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BEF8aM010016; Fri, 11 Feb 2011 14:15:08 GMT Message-ID: <4D55446C.4090504@cisco.com> Date: Fri, 11 Feb 2011 09:15:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> <4D5355FE.3030206@cisco.com> <4D541361.2070506@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0100893150@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0100893150@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: L.Liess@telekom.de, cuss@ietf.org Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Feb 2011 14:14:57 -0000 On 2/11/2011 8:47 AM, R.Jesske@telekom.de wrote: > > Paul, > >> I am about to give up on this. I don't care *that much*. I >> was hoping to >> get something that seems reasonable as a native sip facility, >> that also >> happens to interwork with ISDN. It seems we are on a path >> that results >> in all the limitations and ugliness of the Q.931 mechanism >> with another >> piled on layer of ugliness and inconvenience to wedge it into SIP. >> Apparently everybody else thinks that is fine. > > Do I understand you correct that you would like also to see something like that: > > User-to-User: > "name=foo,age=33";encoding=text;purpose=sip;content > =sip-uui-ia5 > > So this would make the SIP UUI interworkable. > And in parallel we would have also the ISDN-UUI as an hex coded string which can then be passed between ISDN applications. Where we are looking on. I don't really understand the purpose parameter, and when you would use two different values in the same message. If you had purpose=sip and it goes to an ISDN GW, is it ignored? If it has a purpose *other* than isdn-interwork and it arrives at a UA other than an ISDN GW, is it ignored? It seems unreasonable to expect the sending application to know whether the message will be going to an ISDN GW in order to decide what to put into the UUI header. ISTM that the header should be useful in a natural way between two sip devices, and that if they suitably constrain their usage it should also work between two sip devices that are separated by an ISDN hop, or between one sip device and one ISDN device. That says to me that if only purpose=isdn-interwork makes it through an ISDN GW, then that is what any application that *might* interwork with ISDN will use, regardless of whether there is an actual use of ISDN. It seems unreasonable to me that a device that wants to use UUI would encode its UUI information one way for ISDN and a different way for sip-sip communication, in the same message. *Perhaps* it might do so in the same sense as multipart/alternative - where the multiple encodings are of the "same" information but with differing fidelity. E.g. a short form that fits the constraints of ISDN, and a longer form that that does not. In that case a recipient would use the "best" form it is capable of using. But the it wouldn't be a matter of text vs. hex. Thanks, Paul > I don't know what people are thinking on that. > > > Best Regards > > Roland > > >> -----Ursprüngliche Nachricht----- >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Gesendet: Donnerstag, 10. Februar 2011 17:34 >> An: Elwell, John >> Cc: DRAGE, Keith (Keith); Jesske, Roland; cuss@ietf.org >> Betreff: Re: [cuss] Open Issue: Encoding format >> >> >> >> On 2/10/2011 3:50 AM, Elwell, John wrote: >>> I think we would be going down a rat hole if we required >> any sort of conversion at ISDN gateways. End-to-end >> transparent transport would seem to match best the intended >> purpose of the ISDN service and its use in practice. >> >> The proposed hex format *already* requires a conversion by ISDN >> gateways. Arguably, a quoted string representation would >> require *less* >> effort by a gateway, as long as the chars are converted 1:1. >> >> The "advantage" of hex, if its the *only* encoding, is that >> it is done >> identically for every character. But its not especially friendly for >> applications or for reading message dumps. >> >>> If we want a separate text format for use between SIP UAs >> when ISDN is not involved, that might make sense. However, an >> ISDN gateway would not pass this on, so one would need to >> avoid using this format if expecting to interoperate with ISDN. >> >> Yes, we could say that hex is the *only* format when the content is >> isdn-uui. Then the question is: when would anything else ever >> be used? >> I'm having trouble envisioning a path to use of any content >> other than >> isdn-uui or a purpose other than isdn-interwork. >> >> That is part of my difficulty in discriminating between content and >> purpose. AFAIK the purpose of UUI is *never* "isdn-interwork". It is >> something like: "pass info from IVR to call center". >> Accomplishing that >> may or may not require isdn-interworking. That depends on the >> equipment >> deployed, and the IVR sending the UUI might not know. >> >>> If we do perform any conversion at ISDN gateways, we must >> at least ensure it is symmetrical, in the sense of what is >> received from ISDN at UA A gets sent in exactly the same form >> to ISDN at UA B. Performing no conversion is the simplest way >> of achieving this. >> >> I don't think it needs to be symmetrical. There should be a >> single well >> defined sip representation for each ISDN uui value. A GW >> should always >> produce that value when converting from ISDN to sip. And a GW >> should of >> course also accept that representation and convert it >> consistently when >> going from SIP to ISDN. But there could be alternative sip >> representations that the GW is also capable of converting to ISDN. >> >> For instance, we could go with quoted strings as the sip >> representation. >> In that case, the preferred representation would be to >> convert each ISDN >> byte to corresponding quoted character when that is allowed, >> and to use >> \nn only when necessary. But converting the other way would >> presumably >> permit other characters to be represented using the \nn form. >> >> >> >> I am about to give up on this. I don't care *that much*. I >> was hoping to >> get something that seems reasonable as a native sip facility, >> that also >> happens to interwork with ISDN. It seems we are on a path >> that results >> in all the limitations and ugliness of the Q.931 mechanism >> with another >> piled on layer of ugliness and inconvenience to wedge it into SIP. >> Apparently everybody else thinks that is fine. >> >> >> >> Thanks, >> Paul >> >>> John >>> >>>> -----Original Message----- >>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: 10 February 2011 03:06 >>>> To: DRAGE, Keith (Keith) >>>> Cc: R.Jesske@telekom.de; cuss@ietf.org >>>> Subject: Re: [cuss] Open Issue: Encoding format >>>> >>>> First, I just realized that I had "purpose=" and "content=" >>>> mixed up in >>>> my mind. (And I may still not fully understand the distinction in >>>> detail.) Where I have been suggesting multiple purpose >>>> values, I think I >>>> should have been recommending different "content=" values. >>>> >>>> On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: >>>>> Essentially we have two levels of capability identification >>>> defined because the ISDN protocol discriminator is not >>>> apparently flexible enough to do this in a non-ISDN environment. >>>>> >>>>> The point I was making earlier is that the protocol >>>> discriminator in the ISDN is and end to end label. The ISDN >>>> transports something that is binary. The network is not >>>> responsible for determining whether it is as described by the >>>> protocol discriminator. So the only entities responsible for >>>> the usefulness, or not, are the two end users. As I regard >>>> any gateways between the SIP environment and the ISDN as >>>> being part of the network, be that enterprise or public, I >>>> don't see why that should end up having any determination >>>> based on the protocol discriminator value. ISDN will always >>>> have to be assumed to be binary. >>>>> >>>>> I do have an impression however that much of the use is >>>> IA5. I would not from my perspective have a problem if we >>>> encoded the binary as for example % escaped characters or >>>> some similar encoding. I suspect this would be compact for >>>> the majority of ISDN users. But I am not a user of such >>>> information, I work for a company that needs to transport it. >>>> >>>> That may work out in many cases, but for seriously binary >>>> data it could >>>> be quite unpleasant. >>>> >>>> For the ease of those that wish to restrict themselves to >>>> text and don't >>>> want to deal with the hex encoding, it would be good if the >>>> conversion >>>> from Q.931 to sip used the quoted string encoding when that didn't >>>> require any escaping, and otherwise use hex. >>>> >>>> (While it would be possible to define some middle ground, >> I think it >>>> would likely just be annoying.) >>>> >>>> But the discriminator byte then might well force many >> usages to hex. >>>> >>>> I still fail to understand how having separate purposes >> that map onto >>>> specific discriminator values would cause any problem in >>>> mapping to/from >>>> Q.931. >>>> >>>> Fundamentally this comes down to how *sip* users of this will >>>> perceive >>>> it. It doesn't matter at all for Q.931 users, since they will >>>> see what >>>> they have always seen. And if you have a Q.931-aware >>>> *application* that >>>> has been ported to sip, *something* will still have to >>>> convert between >>>> the sip representation and the Q.931 format the >> application expects, >>>> just as a GW will have to do. >>>> >>>> As a SIP user, I think I would prefer to say: >>>> >>>> User-to-User: >>>> "name=foo,age=33";encoding=text;purpose=isdn-interwork;content >>>> =isdn-uui-ia5 >>>> >>>> than: >>>> >>>> User-to-User: >>>> 046E616D653D666F6F2C6167653D3333;encoding=hex;purpose=isdn-int >>>> erwork;content=isdn >>>> >>>> or even: >>>> >>>> User-to-User: >>>> "\04name=foo,age=33";encoding=text;purpose=isdn-interwork;cont >>>> ent=isdn-uui >>>> >>>> At the other extreme, I would also prefer to have >>>> >>>> User-to-User: >>>> >> 0000006500000020;encoding=hex;purpose=isdn-interwork;content=isdn-ia5 >>>> >>>> than: >>>> >>>> User-to-User: "\00\00\00A\00\00\00 >>>> ";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5 >>>> >>>> or: >>>> >>>> User-to-User: "\04\00\00\00A\00\00\00 >>>> ";encoding=text;purpose=isdn-interwork;content=isdn-uui >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>>> Regards >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>> Sent: 09 February 2011 15:50 >>>>>> To: Alan Johnston >>>>>> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org >>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>> >>>>>> >>>>>> >>>>>> On 2/9/2011 9:48 AM, Alan Johnston wrote: >>>>>>> I agree completely with Keith. Gateways have no business >>>>>> delving into the UUI or the protocol discriminator. This will >>>>>> only create mistakes and errors. >>>>>> >>>>>> It will lead to mistakes or errors if there is discretion or >>>>>> lack of clarity regarding the mapping. As long as the mapping >>>>>> is well defined, all should be fine. >>>>>> >>>>>> Perhaps I am mistaken, but it certainly appears to me that >>>>>> the descriminator byte in the Q.931 format serves much the >>>>>> same purpose that the "purpose" parameter is intended to >>>>>> serve in the proposed sip uui header. It seems very natural >>>>>> to me that we make this correlation. >>>>>> >>>>>> I guess the counter-argument to that is *if* the prevailing >>>>>> use of UUI in ISDN entirely ignores the intent of the >>>>>> discriminator byte, and simply uses the entire string, >>>>>> including the discriminator byte, as a single data value. I >>>>>> don't know if that might be the case, or not. (I hope not, >>>>>> since it is a gross abuse of the Q.931 spec.) >>>>>> >>>>>>> My opinion is that for ISDN interworking, the encoding is >>>>>> the transfer encoding chosen by the Gateway with the ISDN >>>>>> encoding being assumed to be binary. >>>>>> >>>>>> I have some feedback from developers that they do not >>>>>> appreciate being forced to convert text data to/from hex for >>>>>> this purpose. It certainly it won't be well appreciated by >>>>>> those looking at call traces. While its perhaps unavoidable >>>>>> when the actual data is binary, it is avoidable when the data >>>>>> is itself text. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> - Alan - >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Feb 9, 2011, at 7:35 AM, Paul >>>> Kyzivat wrote: >>>>>>> >>>>>>>> I just replied to Roland on this. But I'll say a little more: >>>>>>>> >>>>>>>> One way to handle the conversion from Q.931 to sip would >>>>>> be "if it can be represented as a sip quoted string, without >>>>>> escapes, then represent it that way, else represent it as >>>>>> hex." And the converse conversion could be "convert a sip >>>>>> quoted string to Q.931 byte for byte, and convert hex to >>>>>> Q.931 in the obvious way, two hex characters per byte." >>>>>>>> >>>>>>>> It could be done this way on the entire Q.931 value, >>>>>> including the discriminator byte. But that might be less than >>>>>> satisfactory if the actual data is text, but the chosen >>>>>> discriminator is not a nice quoted string value. If the >>>>>> discriminator is separated out, as the purpose value, then it >>>>>> won't muck up an all-text value. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: >>>>>>>>> The ISDN coding could be IA5 or binary, as determined >>>>>> possibly by the protocol discriminator. Moreover in the ISDN, >>>>>> the protocol discriminator could just be a lie. Noone checks >>>>>> it from one end to the other, and it has no impact on the way >>>>>> the network provides the service. >>>>>>>>> >>>>>>>>> So as far as interworking with the ISDN is concerned, I >>>>>> believe it is best to treat it as always binary. >>>>>>>>> >>>>>>>>> In any case, I do not believe it is appropriate at the >>>>>> interworking gateways to start delving into the protocol >>>>>> discriminator values to work out the best coding mapping. >>>>>>>>> >>>>>>>>> Therefore I believe the best coding mapping for the ISDN >>>>>> application is always map to a binary coding within the >>>>>> header field. What that tranfer coding is could be optimised >>>>>> so one size fits all as we discussed previously on the list. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Keith >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>>>>>>>>> Behalf Of R.Jesske@telekom.de >>>>>>>>>> Sent: 08 February 2011 14:54 >>>>>>>>>> To: pkyzivat@cisco.com; cuss@ietf.org >>>>>>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've suggested before that instead of defining >>>>>> isdn-interwork as a >>>>>>>>>>> single purpose, that there be a separate purpose >>>>>> defined for each >>>>>>>>>>> valid value of the discriminator byte in the ISDN >> UUI data. If >>>>>>>>>>> that were done, then it would be much more reasonable >>>>>> to expect a >>>>>>>>>>> GW to convert between sip encodings and ISDN encodings. >>>>>>>>>> >>>>>>>>>> Hi Paul, >>>>>>>>>> I try to understand where you are coming from. >>>>>>>>>> >>>>>>>>>> looking in Q.931 I see the following protocol >>>>>> discriminator values: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >>>>>>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols >>>>>>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >>>>>>>>>> 0 0 0 0 0 0 1 1 Reserved for system management >>>>>>>>>> convergence function >>>>>>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >>>>>>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >>>>>>>>>> information (Note 5) >>>>>>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] >> rate adaption >>>>>>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call >>>>>> control messages >>>>>>>>>> >>>>>>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or >>>>>>>>>> layer 3 protocols, including Recommendation >>>>>>>>>> through X.25 [5] (Note 3) >>>>>>>>>> 0 0 1 1 1 1 1 1 >>>>>>>>>> >>>>>>>>>> 0 1 0 0 0 0 0 0 >>>>>>>>>> through National use >>>>>>>>>> 0 1 0 0 1 1 1 1 >>>>>>>>>> >>>>>>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or >>>>>>>>>> layer 3 protocols, including Recommendation >>>>>>>>>> through X.25 (Note 3) >>>>>>>>>> 1 1 1 1 1 1 1 0 >>>>>>>>>> >>>>>>>>>> So this is the indication how the User Information is >>>>>> coded itself. >>>>>>>>>> >>>>>>>>>> So my question is, what is then understand as a SIP encoding? >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Roland >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Paul >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> cuss mailing list >>>>>>>>>>> cuss@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> cuss mailing list >>>>>>>>>> cuss@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> cuss mailing list >>>>>>>> cuss@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>> >>>>>> >>>> _______________________________________________ >>>> cuss mailing list >>>> cuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cuss >>>> >> > From keith.drage@alcatel-lucent.com Fri Feb 11 08:13:38 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B683A68C0 for ; Fri, 11 Feb 2011 08:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_73=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdR7Yz3eSzX8 for ; Fri, 11 Feb 2011 08:13:36 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 681803A6959 for ; Fri, 11 Feb 2011 08:13:36 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1BGDdFt011252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Feb 2011 17:13:47 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 11 Feb 2011 17:13:41 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "R.Jesske@telekom.de" Date: Fri, 11 Feb 2011 17:13:40 +0100 Thread-Topic: AW: [cuss] Open Issue: Encoding format Thread-Index: AcvJ9ivQDlzoMkRORHqmGBiOCPu94AADudDg Message-ID: References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> <4D5355FE.3030206@cisco.com> <4D541361.2070506@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0100893150@HE111648.emea1.cds.t-internal.com> <4D55446C.4090504@cisco.com> In-Reply-To: <4D55446C.4090504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "L.Liess@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Feb 2011 16:13:38 -0000 > It seems unreasonable to expect the sending application to > know whether the message will be going to an ISDN GW in order > to decide what to put into the UUI header. > But that is the essence of what we have already agreed. Go to my isdn draft= and see the list of constraints. On things like restrictions on length, et= c we have already agreed that the sender has to know the ISDN limits and no= t exceed them, otherwise all the UUI will be lost. That expectation is expressed in different words: The sender purposefully r= estricts themselves to the limitations of the ISDN application in order tha= t if interworking occurs with the ISDN, the interworking with the UUI can a= lso occur. That restriction is identified by signalling the use of the ISDN= application. Regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 11 February 2011 14:15 > To: R.Jesske@telekom.de > Cc: john.elwell@siemens-enterprise.com; DRAGE, Keith (Keith); > cuss@ietf.org; L.Liess@telekom.de > Subject: Re: AW: [cuss] Open Issue: Encoding format > > > > On 2/11/2011 8:47 AM, R.Jesske@telekom.de wrote: > > > > Paul, > > > >> I am about to give up on this. I don't care *that much*. I > was hoping > >> to get something that seems reasonable as a native sip > facility, that > >> also happens to interwork with ISDN. It seems we are on a > path that > >> results in all the limitations and ugliness of the Q.931 mechanism > >> with another piled on layer of ugliness and inconvenience > to wedge it > >> into SIP. > >> Apparently everybody else thinks that is fine. > > > > Do I understand you correct that you would like also to see > something like that: > > > > User-to-User: > > "name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Dsip;content > > =3Dsip-uui-ia5 > > > > So this would make the SIP UUI interworkable. > > And in parallel we would have also the ISDN-UUI as an hex > coded string which can then be passed between ISDN > applications. Where we are looking on. > > I don't really understand the purpose parameter, and when you > would use two different values in the same message. If you > had purpose=3Dsip and it goes to an ISDN GW, is it ignored? If > it has a purpose *other* than isdn-interwork and it arrives > at a UA other than an ISDN GW, is it ignored? > > It seems unreasonable to expect the sending application to > know whether the message will be going to an ISDN GW in order > to decide what to put into the UUI header. > > ISTM that the header should be useful in a natural way > between two sip devices, and that if they suitably constrain > their usage it should also work between two sip devices that > are separated by an ISDN hop, or between one sip device and > one ISDN device. That says to me that if only > purpose=3Disdn-interwork makes it through an ISDN GW, then that > is what any application that *might* interwork with ISDN will > use, regardless of whether there is an actual use of ISDN. > > It seems unreasonable to me that a device that wants to use > UUI would encode its UUI information one way for ISDN and a > different way for sip-sip communication, in the same message. > > *Perhaps* it might do so in the same sense as > multipart/alternative - where the multiple encodings are of > the "same" information but with differing fidelity. E.g. a > short form that fits the constraints of ISDN, and a longer > form that that does not. In that case a recipient would use > the "best" form it is capable of using. But the it wouldn't > be a matter of text vs. hex. > > Thanks, > Paul > > > I don't know what people are thinking on that. > > > > > > Best Regards > > > > Roland > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Gesendet: Donnerstag, 10. Februar 2011 17:34 > >> An: Elwell, John > >> Cc: DRAGE, Keith (Keith); Jesske, Roland; cuss@ietf.org > >> Betreff: Re: [cuss] Open Issue: Encoding format > >> > >> > >> > >> On 2/10/2011 3:50 AM, Elwell, John wrote: > >>> I think we would be going down a rat hole if we required > >> any sort of conversion at ISDN gateways. End-to-end transparent > >> transport would seem to match best the intended purpose of > the ISDN > >> service and its use in practice. > >> > >> The proposed hex format *already* requires a conversion by ISDN > >> gateways. Arguably, a quoted string representation would require > >> *less* effort by a gateway, as long as the chars are converted 1:1. > >> > >> The "advantage" of hex, if its the *only* encoding, is that it is > >> done identically for every character. But its not > especially friendly > >> for applications or for reading message dumps. > >> > >>> If we want a separate text format for use between SIP UAs > >> when ISDN is not involved, that might make sense. However, an ISDN > >> gateway would not pass this on, so one would need to avoid > using this > >> format if expecting to interoperate with ISDN. > >> > >> Yes, we could say that hex is the *only* format when the > content is > >> isdn-uui. Then the question is: when would anything else ever be > >> used? > >> I'm having trouble envisioning a path to use of any content other > >> than isdn-uui or a purpose other than isdn-interwork. > >> > >> That is part of my difficulty in discriminating between > content and > >> purpose. AFAIK the purpose of UUI is *never* > "isdn-interwork". It is > >> something like: "pass info from IVR to call center". > >> Accomplishing that > >> may or may not require isdn-interworking. That depends on the > >> equipment deployed, and the IVR sending the UUI might not know. > >> > >>> If we do perform any conversion at ISDN gateways, we must > >> at least ensure it is symmetrical, in the sense of what is > received > >> from ISDN at UA A gets sent in exactly the same form to > ISDN at UA B. > >> Performing no conversion is the simplest way of achieving this. > >> > >> I don't think it needs to be symmetrical. There should be a single > >> well defined sip representation for each ISDN uui value. A > GW should > >> always produce that value when converting from ISDN to > sip. And a GW > >> should of course also accept that representation and convert it > >> consistently when going from SIP to ISDN. But there could be > >> alternative sip representations that the GW is also capable of > >> converting to ISDN. > >> > >> For instance, we could go with quoted strings as the sip > >> representation. > >> In that case, the preferred representation would be to > convert each > >> ISDN byte to corresponding quoted character when that is > allowed, and > >> to use \nn only when necessary. But converting the other way would > >> presumably permit other characters to be represented using the \nn > >> form. > >> > >> > >> > >> I am about to give up on this. I don't care *that much*. I > was hoping > >> to get something that seems reasonable as a native sip > facility, that > >> also happens to interwork with ISDN. It seems we are on a > path that > >> results in all the limitations and ugliness of the Q.931 mechanism > >> with another piled on layer of ugliness and inconvenience > to wedge it > >> into SIP. > >> Apparently everybody else thinks that is fine. > >> > >> > >> > >> Thanks, > >> Paul > >> > >>> John > >>> > >>>> -----Original Message----- > >>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: 10 February 2011 03:06 > >>>> To: DRAGE, Keith (Keith) > >>>> Cc: R.Jesske@telekom.de; cuss@ietf.org > >>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>> > >>>> First, I just realized that I had "purpose=3D" and "content=3D" > >>>> mixed up in > >>>> my mind. (And I may still not fully understand the distinction in > >>>> detail.) Where I have been suggesting multiple purpose values, I > >>>> think I should have been recommending different > "content=3D" values. > >>>> > >>>> On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: > >>>>> Essentially we have two levels of capability identification > >>>> defined because the ISDN protocol discriminator is not > apparently > >>>> flexible enough to do this in a non-ISDN environment. > >>>>> > >>>>> The point I was making earlier is that the protocol > >>>> discriminator in the ISDN is and end to end label. The ISDN > >>>> transports something that is binary. The network is not > responsible > >>>> for determining whether it is as described by the protocol > >>>> discriminator. So the only entities responsible for the > usefulness, > >>>> or not, are the two end users. As I regard any gateways > between the > >>>> SIP environment and the ISDN as being part of the > network, be that > >>>> enterprise or public, I don't see why that should end up > having any > >>>> determination based on the protocol discriminator value. > ISDN will > >>>> always have to be assumed to be binary. > >>>>> > >>>>> I do have an impression however that much of the use is > >>>> IA5. I would not from my perspective have a problem if > we encoded > >>>> the binary as for example % escaped characters or some similar > >>>> encoding. I suspect this would be compact for the > majority of ISDN > >>>> users. But I am not a user of such information, I work for a > >>>> company that needs to transport it. > >>>> > >>>> That may work out in many cases, but for seriously > binary data it > >>>> could be quite unpleasant. > >>>> > >>>> For the ease of those that wish to restrict themselves > to text and > >>>> don't want to deal with the hex encoding, it would be > good if the > >>>> conversion from Q.931 to sip used the quoted string > encoding when > >>>> that didn't require any escaping, and otherwise use hex. > >>>> > >>>> (While it would be possible to define some middle ground, > >> I think it > >>>> would likely just be annoying.) > >>>> > >>>> But the discriminator byte then might well force many > >> usages to hex. > >>>> > >>>> I still fail to understand how having separate purposes > >> that map onto > >>>> specific discriminator values would cause any problem in mapping > >>>> to/from Q.931. > >>>> > >>>> Fundamentally this comes down to how *sip* users of this will > >>>> perceive it. It doesn't matter at all for Q.931 users, > since they > >>>> will see what they have always seen. And if you have a > Q.931-aware > >>>> *application* that > >>>> has been ported to sip, *something* will still have to convert > >>>> between the sip representation and the Q.931 format the > >> application expects, > >>>> just as a GW will have to do. > >>>> > >>>> As a SIP user, I think I would prefer to say: > >>>> > >>>> User-to-User: > >>>> "name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Disdn-interwork;conte= nt > >>>> =3Disdn-uui-ia5 > >>>> > >>>> than: > >>>> > >>>> User-to-User: > >>>> 046E616D653D666F6F2C6167653D3333;encoding=3Dhex;purpose=3Disdn-int > >>>> erwork;content=3Disdn > >>>> > >>>> or even: > >>>> > >>>> User-to-User: > >>>> "\04name=3Dfoo,age=3D33";encoding=3Dtext;purpose=3Disdn-interwork;co= nt > >>>> ent=3Disdn-uui > >>>> > >>>> At the other extreme, I would also prefer to have > >>>> > >>>> User-to-User: > >>>> > >> > 0000006500000020;encoding=3Dhex;purpose=3Disdn-interwork;content=3Disdn-i= a5 > >>>> > >>>> than: > >>>> > >>>> User-to-User: "\00\00\00A\00\00\00 > >>>> ";encoding=3Dtext;purpose=3Disdn-interwork;content=3Disdn-uui-ia5 > >>>> > >>>> or: > >>>> > >>>> User-to-User: "\04\00\00\00A\00\00\00 > >>>> ";encoding=3Dtext;purpose=3Disdn-interwork;content=3Disdn-uui > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> > >>>>> Regards > >>>>> > >>>>> Keith > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>>> Sent: 09 February 2011 15:50 > >>>>>> To: Alan Johnston > >>>>>> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org > >>>>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 2/9/2011 9:48 AM, Alan Johnston wrote: > >>>>>>> I agree completely with Keith. Gateways have no business > >>>>>> delving into the UUI or the protocol discriminator. This will > >>>>>> only create mistakes and errors. > >>>>>> > >>>>>> It will lead to mistakes or errors if there is > discretion or lack > >>>>>> of clarity regarding the mapping. As long as the > mapping is well > >>>>>> defined, all should be fine. > >>>>>> > >>>>>> Perhaps I am mistaken, but it certainly appears to me that the > >>>>>> descriminator byte in the Q.931 format serves much the same > >>>>>> purpose that the "purpose" parameter is intended to > serve in the > >>>>>> proposed sip uui header. It seems very natural to me > that we make > >>>>>> this correlation. > >>>>>> > >>>>>> I guess the counter-argument to that is *if* the > prevailing use > >>>>>> of UUI in ISDN entirely ignores the intent of the > discriminator > >>>>>> byte, and simply uses the entire string, including the > >>>>>> discriminator byte, as a single data value. I don't > know if that > >>>>>> might be the case, or not. (I hope not, since it is a > gross abuse > >>>>>> of the Q.931 spec.) > >>>>>> > >>>>>>> My opinion is that for ISDN interworking, the encoding is > >>>>>> the transfer encoding chosen by the Gateway with the ISDN > >>>>>> encoding being assumed to be binary. > >>>>>> > >>>>>> I have some feedback from developers that they do not > appreciate > >>>>>> being forced to convert text data to/from hex for this > purpose. > >>>>>> It certainly it won't be well appreciated by those looking at > >>>>>> call traces. While its perhaps unavoidable when the > actual data > >>>>>> is binary, it is avoidable when the data is itself text. > >>>>>> > >>>>>> Thanks, > >>>>>> Paul > >>>>>> > >>>>>>> - Alan - > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Feb 9, 2011, at 7:35 AM, Paul > >>>> Kyzivat wrote: > >>>>>>> > >>>>>>>> I just replied to Roland on this. But I'll say a little more: > >>>>>>>> > >>>>>>>> One way to handle the conversion from Q.931 to sip would > >>>>>> be "if it can be represented as a sip quoted string, without > >>>>>> escapes, then represent it that way, else represent it > as hex." > >>>>>> And the converse conversion could be "convert a sip > quoted string > >>>>>> to Q.931 byte for byte, and convert hex to > >>>>>> Q.931 in the obvious way, two hex characters per byte." > >>>>>>>> > >>>>>>>> It could be done this way on the entire Q.931 value, > >>>>>> including the discriminator byte. But that might be less than > >>>>>> satisfactory if the actual data is text, but the chosen > >>>>>> discriminator is not a nice quoted string value. If the > >>>>>> discriminator is separated out, as the purpose value, then it > >>>>>> won't muck up an all-text value. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Paul > >>>>>>>> > >>>>>>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: > >>>>>>>>> The ISDN coding could be IA5 or binary, as determined > >>>>>> possibly by the protocol discriminator. Moreover in > the ISDN, the > >>>>>> protocol discriminator could just be a lie. Noone > checks it from > >>>>>> one end to the other, and it has no impact on the way > the network > >>>>>> provides the service. > >>>>>>>>> > >>>>>>>>> So as far as interworking with the ISDN is concerned, I > >>>>>> believe it is best to treat it as always binary. > >>>>>>>>> > >>>>>>>>> In any case, I do not believe it is appropriate at the > >>>>>> interworking gateways to start delving into the protocol > >>>>>> discriminator values to work out the best coding mapping. > >>>>>>>>> > >>>>>>>>> Therefore I believe the best coding mapping for the ISDN > >>>>>> application is always map to a binary coding within the header > >>>>>> field. What that tranfer coding is could be optimised > so one size > >>>>>> fits all as we discussed previously on the list. > >>>>>>>>> > >>>>>>>>> Regards > >>>>>>>>> > >>>>>>>>> Keith > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: cuss-bounces@ietf.org > [mailto:cuss-bounces@ietf.org] On > >>>>>>>>>> Behalf Of R.Jesske@telekom.de > >>>>>>>>>> Sent: 08 February 2011 14:54 > >>>>>>>>>> To: pkyzivat@cisco.com; cuss@ietf.org > >>>>>>>>>> Subject: Re: [cuss] Open Issue: Encoding format > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I've suggested before that instead of defining > >>>>>> isdn-interwork as a > >>>>>>>>>>> single purpose, that there be a separate purpose > >>>>>> defined for each > >>>>>>>>>>> valid value of the discriminator byte in the ISDN > >> UUI data. If > >>>>>>>>>>> that were done, then it would be much more reasonable > >>>>>> to expect a > >>>>>>>>>>> GW to convert between sip encodings and ISDN encodings. > >>>>>>>>>> > >>>>>>>>>> Hi Paul, > >>>>>>>>>> I try to understand where you are coming from. > >>>>>>>>>> > >>>>>>>>>> looking in Q.931 I see the following protocol > >>>>>> discriminator values: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) > >>>>>>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols > >>>>>>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) > >>>>>>>>>> 0 0 0 0 0 0 1 1 Reserved for system management > >>>>>>>>>> convergence function > >>>>>>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) > >>>>>>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user > >>>>>>>>>> information (Note 5) > >>>>>>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] > >> rate adaption > >>>>>>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call > >>>>>> control messages > >>>>>>>>>> > >>>>>>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or > >>>>>>>>>> layer 3 protocols, including Recommendation > >>>>>>>>>> through X.25 [5] (Note 3) > >>>>>>>>>> 0 0 1 1 1 1 1 1 > >>>>>>>>>> > >>>>>>>>>> 0 1 0 0 0 0 0 0 > >>>>>>>>>> through National use > >>>>>>>>>> 0 1 0 0 1 1 1 1 > >>>>>>>>>> > >>>>>>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or > >>>>>>>>>> layer 3 protocols, including Recommendation > >>>>>>>>>> through X.25 (Note 3) > >>>>>>>>>> 1 1 1 1 1 1 1 0 > >>>>>>>>>> > >>>>>>>>>> So this is the indication how the User Information is > >>>>>> coded itself. > >>>>>>>>>> > >>>>>>>>>> So my question is, what is then understand as a > SIP encoding? > >>>>>>>>>> > >>>>>>>>>> Regards > >>>>>>>>>> > >>>>>>>>>> Roland > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Paul > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> cuss mailing list > >>>>>>>>>>> cuss@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> cuss mailing list > >>>>>>>>>> cuss@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> cuss mailing list > >>>>>>>> cuss@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/cuss > >>>>>>> > >>>>>> > >>>> _______________________________________________ > >>>> cuss mailing list > >>>> cuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cuss > >>>> > >> > > > From pkyzivat@cisco.com Fri Feb 11 12:05:33 2011 Return-Path: X-Original-To: cuss@core3.amsl.com Delivered-To: cuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114BD3A698A for ; Fri, 11 Feb 2011 12:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq-uaXTzmI1d for ; Fri, 11 Feb 2011 12:05:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ABC973A6925 for ; Fri, 11 Feb 2011 12:05:28 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP8kVU1AZnwM/2dsb2JhbACldXOfUZsvhV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,457,1291593600"; d="scan'208";a="214647940" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2011 20:05:43 +0000 Received: from [10.86.251.15] (bxb-vpn3-783.cisco.com [10.86.251.15]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BK5hKE010399; Fri, 11 Feb 2011 20:05:43 GMT Message-ID: <4D559696.90901@cisco.com> Date: Fri, 11 Feb 2011 15:05:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4D506D95.1090704@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D010058EC68@HE111648.emea1.cds.t-internal.com> <4D52A633.5030403@cisco.com> <603B765F-414F-4979-9FDE-88C27D69CCEA@gmail.com> <4D52B78C.4030708@cisco.com> <4D5355FE.3030206@cisco.com> <4D541361.2070506@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D0100893150@HE111648.emea1.cds.t-internal.com> <4D55446C.4090504@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "L.Liess@telekom.de" , "R.Jesske@telekom.de" , "cuss@ietf.org" Subject: Re: [cuss] Open Issue: Encoding format X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 11 Feb 2011 20:05:33 -0000 On 2/11/2011 11:13 AM, DRAGE, Keith (Keith) wrote: >> It seems unreasonable to expect the sending application to >> know whether the message will be going to an ISDN GW in order >> to decide what to put into the UUI header. >> > > But that is the essence of what we have already agreed. Go to my isdn draft and see the list of constraints. On things like restrictions on length, etc we have already agreed that the sender has to know the ISDN limits and not exceed them, otherwise all the UUI will be lost. > > That expectation is expressed in different words: The sender purposefully restricts themselves to the limitations of the ISDN application in order that if interworking occurs with the ISDN, the interworking with the UUI can also occur. That restriction is identified by signalling the use of the ISDN application. There is a big difference between "accepting the limitations of ISDN" and "knowing this is going to ISDN". This is especially the case if "purpose=isdn-interwork" really means it should only be processed by an ISDN GW and some other purpose is to be used in all other cases. I'd really like to understand the thinking about how the purpose parameter is intended to be used. Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 11 February 2011 14:15 >> To: R.Jesske@telekom.de >> Cc: john.elwell@siemens-enterprise.com; DRAGE, Keith (Keith); >> cuss@ietf.org; L.Liess@telekom.de >> Subject: Re: AW: [cuss] Open Issue: Encoding format >> >> >> >> On 2/11/2011 8:47 AM, R.Jesske@telekom.de wrote: >>> >>> Paul, >>> >>>> I am about to give up on this. I don't care *that much*. I >> was hoping >>>> to get something that seems reasonable as a native sip >> facility, that >>>> also happens to interwork with ISDN. It seems we are on a >> path that >>>> results in all the limitations and ugliness of the Q.931 mechanism >>>> with another piled on layer of ugliness and inconvenience >> to wedge it >>>> into SIP. >>>> Apparently everybody else thinks that is fine. >>> >>> Do I understand you correct that you would like also to see >> something like that: >>> >>> User-to-User: >>> "name=foo,age=33";encoding=text;purpose=sip;content >>> =sip-uui-ia5 >>> >>> So this would make the SIP UUI interworkable. >>> And in parallel we would have also the ISDN-UUI as an hex >> coded string which can then be passed between ISDN >> applications. Where we are looking on. >> >> I don't really understand the purpose parameter, and when you >> would use two different values in the same message. If you >> had purpose=sip and it goes to an ISDN GW, is it ignored? If >> it has a purpose *other* than isdn-interwork and it arrives >> at a UA other than an ISDN GW, is it ignored? >> >> It seems unreasonable to expect the sending application to >> know whether the message will be going to an ISDN GW in order >> to decide what to put into the UUI header. >> >> ISTM that the header should be useful in a natural way >> between two sip devices, and that if they suitably constrain >> their usage it should also work between two sip devices that >> are separated by an ISDN hop, or between one sip device and >> one ISDN device. That says to me that if only >> purpose=isdn-interwork makes it through an ISDN GW, then that >> is what any application that *might* interwork with ISDN will >> use, regardless of whether there is an actual use of ISDN. >> >> It seems unreasonable to me that a device that wants to use >> UUI would encode its UUI information one way for ISDN and a >> different way for sip-sip communication, in the same message. >> >> *Perhaps* it might do so in the same sense as >> multipart/alternative - where the multiple encodings are of >> the "same" information but with differing fidelity. E.g. a >> short form that fits the constraints of ISDN, and a longer >> form that that does not. In that case a recipient would use >> the "best" form it is capable of using. But the it wouldn't >> be a matter of text vs. hex. >> >> Thanks, >> Paul >> >>> I don't know what people are thinking on that. >>> >>> >>> Best Regards >>> >>> Roland >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Gesendet: Donnerstag, 10. Februar 2011 17:34 >>>> An: Elwell, John >>>> Cc: DRAGE, Keith (Keith); Jesske, Roland; cuss@ietf.org >>>> Betreff: Re: [cuss] Open Issue: Encoding format >>>> >>>> >>>> >>>> On 2/10/2011 3:50 AM, Elwell, John wrote: >>>>> I think we would be going down a rat hole if we required >>>> any sort of conversion at ISDN gateways. End-to-end transparent >>>> transport would seem to match best the intended purpose of >> the ISDN >>>> service and its use in practice. >>>> >>>> The proposed hex format *already* requires a conversion by ISDN >>>> gateways. Arguably, a quoted string representation would require >>>> *less* effort by a gateway, as long as the chars are converted 1:1. >>>> >>>> The "advantage" of hex, if its the *only* encoding, is that it is >>>> done identically for every character. But its not >> especially friendly >>>> for applications or for reading message dumps. >>>> >>>>> If we want a separate text format for use between SIP UAs >>>> when ISDN is not involved, that might make sense. However, an ISDN >>>> gateway would not pass this on, so one would need to avoid >> using this >>>> format if expecting to interoperate with ISDN. >>>> >>>> Yes, we could say that hex is the *only* format when the >> content is >>>> isdn-uui. Then the question is: when would anything else ever be >>>> used? >>>> I'm having trouble envisioning a path to use of any content other >>>> than isdn-uui or a purpose other than isdn-interwork. >>>> >>>> That is part of my difficulty in discriminating between >> content and >>>> purpose. AFAIK the purpose of UUI is *never* >> "isdn-interwork". It is >>>> something like: "pass info from IVR to call center". >>>> Accomplishing that >>>> may or may not require isdn-interworking. That depends on the >>>> equipment deployed, and the IVR sending the UUI might not know. >>>> >>>>> If we do perform any conversion at ISDN gateways, we must >>>> at least ensure it is symmetrical, in the sense of what is >> received >>>> from ISDN at UA A gets sent in exactly the same form to >> ISDN at UA B. >>>> Performing no conversion is the simplest way of achieving this. >>>> >>>> I don't think it needs to be symmetrical. There should be a single >>>> well defined sip representation for each ISDN uui value. A >> GW should >>>> always produce that value when converting from ISDN to >> sip. And a GW >>>> should of course also accept that representation and convert it >>>> consistently when going from SIP to ISDN. But there could be >>>> alternative sip representations that the GW is also capable of >>>> converting to ISDN. >>>> >>>> For instance, we could go with quoted strings as the sip >>>> representation. >>>> In that case, the preferred representation would be to >> convert each >>>> ISDN byte to corresponding quoted character when that is >> allowed, and >>>> to use \nn only when necessary. But converting the other way would >>>> presumably permit other characters to be represented using the \nn >>>> form. >>>> >>>> >>>> >>>> I am about to give up on this. I don't care *that much*. I >> was hoping >>>> to get something that seems reasonable as a native sip >> facility, that >>>> also happens to interwork with ISDN. It seems we are on a >> path that >>>> results in all the limitations and ugliness of the Q.931 mechanism >>>> with another piled on layer of ugliness and inconvenience >> to wedge it >>>> into SIP. >>>> Apparently everybody else thinks that is fine. >>>> >>>> >>>> >>>> Thanks, >>>> Paul >>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >>>>>> Behalf Of Paul Kyzivat >>>>>> Sent: 10 February 2011 03:06 >>>>>> To: DRAGE, Keith (Keith) >>>>>> Cc: R.Jesske@telekom.de; cuss@ietf.org >>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>> >>>>>> First, I just realized that I had "purpose=" and "content=" >>>>>> mixed up in >>>>>> my mind. (And I may still not fully understand the distinction in >>>>>> detail.) Where I have been suggesting multiple purpose values, I >>>>>> think I should have been recommending different >> "content=" values. >>>>>> >>>>>> On 2/9/2011 6:46 PM, DRAGE, Keith (Keith) wrote: >>>>>>> Essentially we have two levels of capability identification >>>>>> defined because the ISDN protocol discriminator is not >> apparently >>>>>> flexible enough to do this in a non-ISDN environment. >>>>>>> >>>>>>> The point I was making earlier is that the protocol >>>>>> discriminator in the ISDN is and end to end label. The ISDN >>>>>> transports something that is binary. The network is not >> responsible >>>>>> for determining whether it is as described by the protocol >>>>>> discriminator. So the only entities responsible for the >> usefulness, >>>>>> or not, are the two end users. As I regard any gateways >> between the >>>>>> SIP environment and the ISDN as being part of the >> network, be that >>>>>> enterprise or public, I don't see why that should end up >> having any >>>>>> determination based on the protocol discriminator value. >> ISDN will >>>>>> always have to be assumed to be binary. >>>>>>> >>>>>>> I do have an impression however that much of the use is >>>>>> IA5. I would not from my perspective have a problem if >> we encoded >>>>>> the binary as for example % escaped characters or some similar >>>>>> encoding. I suspect this would be compact for the >> majority of ISDN >>>>>> users. But I am not a user of such information, I work for a >>>>>> company that needs to transport it. >>>>>> >>>>>> That may work out in many cases, but for seriously >> binary data it >>>>>> could be quite unpleasant. >>>>>> >>>>>> For the ease of those that wish to restrict themselves >> to text and >>>>>> don't want to deal with the hex encoding, it would be >> good if the >>>>>> conversion from Q.931 to sip used the quoted string >> encoding when >>>>>> that didn't require any escaping, and otherwise use hex. >>>>>> >>>>>> (While it would be possible to define some middle ground, >>>> I think it >>>>>> would likely just be annoying.) >>>>>> >>>>>> But the discriminator byte then might well force many >>>> usages to hex. >>>>>> >>>>>> I still fail to understand how having separate purposes >>>> that map onto >>>>>> specific discriminator values would cause any problem in mapping >>>>>> to/from Q.931. >>>>>> >>>>>> Fundamentally this comes down to how *sip* users of this will >>>>>> perceive it. It doesn't matter at all for Q.931 users, >> since they >>>>>> will see what they have always seen. And if you have a >> Q.931-aware >>>>>> *application* that >>>>>> has been ported to sip, *something* will still have to convert >>>>>> between the sip representation and the Q.931 format the >>>> application expects, >>>>>> just as a GW will have to do. >>>>>> >>>>>> As a SIP user, I think I would prefer to say: >>>>>> >>>>>> User-to-User: >>>>>> "name=foo,age=33";encoding=text;purpose=isdn-interwork;content >>>>>> =isdn-uui-ia5 >>>>>> >>>>>> than: >>>>>> >>>>>> User-to-User: >>>>>> 046E616D653D666F6F2C6167653D3333;encoding=hex;purpose=isdn-int >>>>>> erwork;content=isdn >>>>>> >>>>>> or even: >>>>>> >>>>>> User-to-User: >>>>>> "\04name=foo,age=33";encoding=text;purpose=isdn-interwork;cont >>>>>> ent=isdn-uui >>>>>> >>>>>> At the other extreme, I would also prefer to have >>>>>> >>>>>> User-to-User: >>>>>> >>>> >> 0000006500000020;encoding=hex;purpose=isdn-interwork;content=isdn-ia5 >>>>>> >>>>>> than: >>>>>> >>>>>> User-to-User: "\00\00\00A\00\00\00 >>>>>> ";encoding=text;purpose=isdn-interwork;content=isdn-uui-ia5 >>>>>> >>>>>> or: >>>>>> >>>>>> User-to-User: "\04\00\00\00A\00\00\00 >>>>>> ";encoding=text;purpose=isdn-interwork;content=isdn-uui >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Keith >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>>>>> Sent: 09 February 2011 15:50 >>>>>>>> To: Alan Johnston >>>>>>>> Cc: DRAGE, Keith (Keith); R.Jesske@telekom.de; cuss@ietf.org >>>>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2/9/2011 9:48 AM, Alan Johnston wrote: >>>>>>>>> I agree completely with Keith. Gateways have no business >>>>>>>> delving into the UUI or the protocol discriminator. This will >>>>>>>> only create mistakes and errors. >>>>>>>> >>>>>>>> It will lead to mistakes or errors if there is >> discretion or lack >>>>>>>> of clarity regarding the mapping. As long as the >> mapping is well >>>>>>>> defined, all should be fine. >>>>>>>> >>>>>>>> Perhaps I am mistaken, but it certainly appears to me that the >>>>>>>> descriminator byte in the Q.931 format serves much the same >>>>>>>> purpose that the "purpose" parameter is intended to >> serve in the >>>>>>>> proposed sip uui header. It seems very natural to me >> that we make >>>>>>>> this correlation. >>>>>>>> >>>>>>>> I guess the counter-argument to that is *if* the >> prevailing use >>>>>>>> of UUI in ISDN entirely ignores the intent of the >> discriminator >>>>>>>> byte, and simply uses the entire string, including the >>>>>>>> discriminator byte, as a single data value. I don't >> know if that >>>>>>>> might be the case, or not. (I hope not, since it is a >> gross abuse >>>>>>>> of the Q.931 spec.) >>>>>>>> >>>>>>>>> My opinion is that for ISDN interworking, the encoding is >>>>>>>> the transfer encoding chosen by the Gateway with the ISDN >>>>>>>> encoding being assumed to be binary. >>>>>>>> >>>>>>>> I have some feedback from developers that they do not >> appreciate >>>>>>>> being forced to convert text data to/from hex for this >> purpose. >>>>>>>> It certainly it won't be well appreciated by those looking at >>>>>>>> call traces. While its perhaps unavoidable when the >> actual data >>>>>>>> is binary, it is avoidable when the data is itself text. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>> >>>>>>>>> - Alan - >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 9, 2011, at 7:35 AM, Paul >>>>>> Kyzivat wrote: >>>>>>>>> >>>>>>>>>> I just replied to Roland on this. But I'll say a little more: >>>>>>>>>> >>>>>>>>>> One way to handle the conversion from Q.931 to sip would >>>>>>>> be "if it can be represented as a sip quoted string, without >>>>>>>> escapes, then represent it that way, else represent it >> as hex." >>>>>>>> And the converse conversion could be "convert a sip >> quoted string >>>>>>>> to Q.931 byte for byte, and convert hex to >>>>>>>> Q.931 in the obvious way, two hex characters per byte." >>>>>>>>>> >>>>>>>>>> It could be done this way on the entire Q.931 value, >>>>>>>> including the discriminator byte. But that might be less than >>>>>>>> satisfactory if the actual data is text, but the chosen >>>>>>>> discriminator is not a nice quoted string value. If the >>>>>>>> discriminator is separated out, as the purpose value, then it >>>>>>>> won't muck up an all-text value. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Paul >>>>>>>>>> >>>>>>>>>> On 2/8/2011 10:43 AM, DRAGE, Keith (Keith) wrote: >>>>>>>>>>> The ISDN coding could be IA5 or binary, as determined >>>>>>>> possibly by the protocol discriminator. Moreover in >> the ISDN, the >>>>>>>> protocol discriminator could just be a lie. Noone >> checks it from >>>>>>>> one end to the other, and it has no impact on the way >> the network >>>>>>>> provides the service. >>>>>>>>>>> >>>>>>>>>>> So as far as interworking with the ISDN is concerned, I >>>>>>>> believe it is best to treat it as always binary. >>>>>>>>>>> >>>>>>>>>>> In any case, I do not believe it is appropriate at the >>>>>>>> interworking gateways to start delving into the protocol >>>>>>>> discriminator values to work out the best coding mapping. >>>>>>>>>>> >>>>>>>>>>> Therefore I believe the best coding mapping for the ISDN >>>>>>>> application is always map to a binary coding within the header >>>>>>>> field. What that tranfer coding is could be optimised >> so one size >>>>>>>> fits all as we discussed previously on the list. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> >>>>>>>>>>> Keith >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: cuss-bounces@ietf.org >> [mailto:cuss-bounces@ietf.org] On >>>>>>>>>>>> Behalf Of R.Jesske@telekom.de >>>>>>>>>>>> Sent: 08 February 2011 14:54 >>>>>>>>>>>> To: pkyzivat@cisco.com; cuss@ietf.org >>>>>>>>>>>> Subject: Re: [cuss] Open Issue: Encoding format >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I've suggested before that instead of defining >>>>>>>> isdn-interwork as a >>>>>>>>>>>>> single purpose, that there be a separate purpose >>>>>>>> defined for each >>>>>>>>>>>>> valid value of the discriminator byte in the ISDN >>>> UUI data. If >>>>>>>>>>>>> that were done, then it would be much more reasonable >>>>>>>> to expect a >>>>>>>>>>>>> GW to convert between sip encodings and ISDN encodings. >>>>>>>>>>>> >>>>>>>>>>>> Hi Paul, >>>>>>>>>>>> I try to understand where you are coming from. >>>>>>>>>>>> >>>>>>>>>>>> looking in Q.931 I see the following protocol >>>>>>>> discriminator values: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 0 0 0 0 0 0 0 0 User-specific protocol (Note 1) >>>>>>>>>>>> 0 0 0 0 0 0 0 1 OSI high layer protocols >>>>>>>>>>>> 0 0 0 0 0 0 1 0 Recommendation X.244 [44] (Note 2) >>>>>>>>>>>> 0 0 0 0 0 0 1 1 Reserved for system management >>>>>>>>>>>> convergence function >>>>>>>>>>>> 0 0 0 0 0 1 0 0 IA5 characters (Note 4) >>>>>>>>>>>> 0 0 0 0 0 1 0 1 X.208 and X.209 coded user >>>>>>>>>>>> information (Note 5) >>>>>>>>>>>> 0 0 0 0 0 1 1 1 Recommendation V.120 [9] >>>> rate adaption >>>>>>>>>>>> 0 0 0 0 1 0 0 0 Q.931/I.451 user-network call >>>>>>>> control messages >>>>>>>>>>>> >>>>>>>>>>>> 0 0 0 1 0 0 0 0 Reserved for other network layer or >>>>>>>>>>>> layer 3 protocols, including Recommendation >>>>>>>>>>>> through X.25 [5] (Note 3) >>>>>>>>>>>> 0 0 1 1 1 1 1 1 >>>>>>>>>>>> >>>>>>>>>>>> 0 1 0 0 0 0 0 0 >>>>>>>>>>>> through National use >>>>>>>>>>>> 0 1 0 0 1 1 1 1 >>>>>>>>>>>> >>>>>>>>>>>> 0 1 0 1 0 0 0 0 Reserved for other network layer or >>>>>>>>>>>> layer 3 protocols, including Recommendation >>>>>>>>>>>> through X.25 (Note 3) >>>>>>>>>>>> 1 1 1 1 1 1 1 0 >>>>>>>>>>>> >>>>>>>>>>>> So this is the indication how the User Information is >>>>>>>> coded itself. >>>>>>>>>>>> >>>>>>>>>>>> So my question is, what is then understand as a >> SIP encoding? >>>>>>>>>>>> >>>>>>>>>>>> Regards >>>>>>>>>>>> >>>>>>>>>>>> Roland >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Paul >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> cuss mailing list >>>>>>>>>>>>> cuss@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> cuss mailing list >>>>>>>>>>>> cuss@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> cuss mailing list >>>>>>>>>> cuss@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> cuss mailing list >>>>>> cuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cuss >>>>>> >>>> >>> >> >