From iptel-bounces@ietf.org Fri Mar 03 05:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7B2-0004tY-LW; Fri, 03 Mar 2006 05:06:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF7B1-0004mu-94 for iptel@ietf.org; Fri, 03 Mar 2006 05:06:23 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF7B0-0005hP-Ka for iptel@ietf.org; Fri, 03 Mar 2006 05:06:23 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k23A6LXw015023; Fri, 3 Mar 2006 19:06:21 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k23A6Ktr004414; Fri, 3 Mar 2006 19:06:20 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k23A6KMJ027950; Fri, 3 Mar 2006 19:06:20 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k23A6JCQ018740; Fri, 3 Mar 2006 19:06:19 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k23A6JKj018778; Fri, 3 Mar 2006 19:06:19 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf.m.ecl.ntt.co.jp [129.60.5.230]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k23A6Ja0018774; Fri, 3 Mar 2006 19:06:19 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imf.m.ecl.ntt.co.jp (8.13.4/8.13.4) with SMTP id k23A6Ibx023066; Fri, 3 Mar 2006 19:06:18 +0900 (JST) Message-Id: <200603031006.k23A6Ibx023066@imf.m.ecl.ntt.co.jp> To: iptel@ietf.org From: Mayumi Munakata Date: Fri, 03 Mar 2006 19:06:18 +0900 X-Mailer: WebMail V3.5.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Iptel] New draft on ISDN subaddress type X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Hi all, We have submitted a new draft on the ISDN subaddress type. The draft defines a new tel URI parameter that can be used along with "isub" parameter in SIP messages in order to carry the encoding type information of ISDN subaddress. When we were analyzing the usage of "isub" parameter, we realized that there was a problem when interworking ISDN subaddress between SIP and ISDN network, due to the lack of encoding type used for ISDN subaddress. This draft solves the problem. Any suggestions and comments would be appreciated. ISDN subaddress encoding type for tel URI draft-munakata-iptel-isub-type-00.txt A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-munakata-iptel-isub-type-00.txt Thanks, Mayumi Munakata _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 07 18:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGlnC-0005Ys-DT; Tue, 07 Mar 2006 18:40:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGlnB-0005Yk-0t for iptel@ietf.org; Tue, 07 Mar 2006 18:40:37 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FGlnA-0002Uw-Fx for iptel@ietf.org; Tue, 07 Mar 2006 18:40:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C64241.16AE767B" Date: Wed, 8 Mar 2006 00:44:34 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48BA@oefeg-s04.oefeg.loc> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Thread-Index: AcZCOEAGpTKGx06wSQubzpFWs7+hegAB2/nO From: "Stastny Richard" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Subject: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C64241.16AE767B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, =20 in principle I support and welcome this draft =20 A minor comment to the phone-context examples: =20 "When the "user=3Ddialstring" is used, a context parameter as defined in [RFC3966] MUST be specified." =20 Ok =20 but in your examples you use (Examples of dialstring use include) ; what a SIP Phone might emit when a user dials extension 123 sip:123@sippbx.example.com;user=3Ddialstring; phone-context=3D'AtlantaDialPlan' =20 but phone-context is defined in RFC3966 as: context =3D ";phone-context=3D" descriptor descriptor =3D domainname / global-number-digits this is because the phone-context must globally unique so you should use in your examples either phone-context=3Daltlanta.example.com or phone-context=3D+1234 (without "") regards Richard ________________________________ Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Gesendet: Di 07.03.2006 21:50 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Dialstring parameter for the Session = Initiation Protocol URI Author(s) : B. Rosen Filename : draft-rosen-iptel-dialstring-03.txt Pages : 8 Date : 2006-3-7 =20 RFC3966 explicitly states that TEL URIs may not represent a dial string. That leaves no way specify a dialstring in a standardized way. Great confusion exists with the SIP URI parameter "user=3Dphone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=3Ddialstring" to encode a dialstring as a SIP or SIPS URI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-iptel-dialstring-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". =20 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail = readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C64241.16AE767B Content-Type: text/plain; name="ATT99735.txt" Content-Transfer-Encoding: base64 Content-Description: ATT99735.txt Content-Disposition: attachment; filename="ATT99735.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C64241.16AE767B Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel ------_=_NextPart_001_01C64241.16AE767B-- From iptel-bounces@ietf.org Wed Mar 08 07:43:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGy0G-0000Bi-DY; Wed, 08 Mar 2006 07:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGy0E-0000BU-P1 for iptel@ietf.org; Wed, 08 Mar 2006 07:42:54 -0500 Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGy0D-0007yG-1l for iptel@ietf.org; Wed, 08 Mar 2006 07:42:54 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp8.clb.oleane.net with ESMTP id k28CgoWi005798 for ; Wed, 8 Mar 2006 13:42:50 +0100 Message-Id: <200603081242.k28CgoWi005798@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 8 Mar 2006 13:42:10 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZCrbe2See5JXRVTF2lDHp585p8qw== X-Spam-Score: 0.4 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: [Iptel] IMS or UMA? How to Achieve FMC? X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0920307029==" Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0920307029== Content-Type: multipart/related; boundary="----=_NextPart_000_010B_01C642B6.1A410E30" This is a multi-part message in MIME format. ------=_NextPart_000_010B_01C642B6.1A410E30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_010C_01C642B6.1A410E30" ------=_NextPart_001_010C_01C642B6.1A410E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IMS or UMA? How to Achieve FMC? At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May 19, distinguished experts and key players in the convergence field will address technical issues. Moreover, carriers like BT, Orange, Vonage (etc) will discuss their commercial experience and technological choices. Get all details at: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm ------=_NextPart_001_010C_01C642B6.1A410E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IMS or UMA?

How to Achieve FMC?

 

At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May = 19,

distinguished experts and key players in the convergence field will address technical issues. =

Moreover, carriers like BT, Orange, Vonage (etc) will discuss = their commercial experience and

    &nb= sp;  technological choices.

 

    &nb= sp; Get all details at:

    &nb= sp; http://www.upperside.fr/wirelessconvergence2006/wwconvergence= 2006intro.htm

 

 

------=_NextPart_001_010C_01C642B6.1A410E30-- ------=_NextPart_000_010B_01C642B6.1A410E30 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAArAJUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDzYFiT 1pPJmbpmvdvDfhrw9rnha2vRpdv5s0OGZR0fGD+teUXKxWV3PbSKN8MhTH0OKR9RhFTxMpQk7cpz 7WkjDqadHpsrHoa+gNB8GaQNCszd6fE87RhnZhzk815Z4uiXQPEt3YrGERW3xjH8J6UWJw8sJVqu Ddrfic5Ho7nrXs/wjt/s3hmeLv8AaCf0FQfDzw9Yan4YTUNQtEledyULDoo4FYera1Z2fli0vbvT bf8AtVoEWyAw+NoO7PbOaaObH1sNKEqdGL06nsApa4jWPidpuia7caLJY31xdQoCogj3+YcZ4xTb X4q6HN4autbkiuIRayiKS3ZcuXPQD8qDwjuaK89PxatbcQTahod/Z2s7AJO+1hz7A1VfXL8/GiGy S/lOntZ+b5Ib5Mbc5xQB6ZRXnw+LFtcSXB03Q7+9gt2KvOm0DjqcGrM/xU0KHwtHr+y4aOSYwCHb 84cDJB/CgDuKQjNcCnxSUPD9p8OalBHMQFcBX6+wNW9e+JFjo2uLo0On3V7eMgcxxYXAIz39qAOx JA61k3XibRLKcxXWpW8TrwVLdKx9H8eR63ey6c+kX1jOsZcGVQU4H94dKy/h/o2m6nZ311e2kdxK 1yw3OM8ZpnXQo05U5VKl7Lt5nb2epWN/CZrO6jmjXqUbgVRk8WaBFKYn1W3D5xjdXEWqjTNS8WWt oPLiS3LIqnAHNQ6Je6Jb+HUin0Ce8co3nTpDnBOehpHasvhq9WtNrX1Vz1K3uIrqES28iyxt0ZTk GisHwOmnR+H1/sqeWWBnJ/fH5kPpRQeXWgqdRwXTuct8F9U8/Sb3THYlraXegPo3/wBeuc8SeHHn +L8enxgiK9mSc+m3qf1Bql8KtU/s7xrDCxxHeoYiP9rqK9mm0KGbxTb64xHmwW7QhcepzmkddWTp VW+6IdZ8RW+iatpGnOo/4mEpiH+yAOP1wK86+N+kMLzTtUiU5mzbvjueorH+KevPN48j8h+NL2hc H+MHcf6V6vfafbeNPDenSlhsLxXKn6EEigwSdPll3GxBfCnw+UkBTZWOT/vbf8a8esdPl1nw1pTC 7tYZBqzyMJ5QhfO3OM9a9D+MmqfYvCcVijYe9mC4H90cmvNtOv47HRNDSTT7a783UmAM65Kcp0oG o/unLuzukNlpvxhvdbvNW0+G2EHlYaYb1bA4xUvjW28M+KdBk03QdW0yG/nuFlCrIB5z+hx3rz7W n0yL4raw2raXPqVv5rfuLc4bOBg1v+HpvBlz4hsYLfwXqdtM8y7JpHO2Ns8E0zmIrfwve62iabY6 DpQuLVwtzMb9pduOCSmeO9dgfBmqf8LKh1fy4xp6WX2curcg7NvSsTwp4hNnd+Lbq20yzgntpAoa NcbyXIBb19a7aK613TWjvdSvbe5sPKL3DCPYY+M8etBtCg5R5rnntp8Odc0Z7u3/AOEdttXWSQtF cG9aLAPqoNah8Aa0ngJtNGm6W93Jdmdrfc21Vxxhs/ersl8a2Cwyyz29zDsjEqq6cuhOAR+YqRPF 9i0yxSQ3ELmRIysiYI3fdP0oH9Wqv7J5fdfDvxLdJDHZaEmlSK4JuF1Fn4+lb/i7wXrV9rFreLpF nqiR26Ru4nMMrMBgkt35zXXTeNNOjkeKOKeZ0dlIVeoX7zD2FLJ4005WXZFcSo0aymRIyQqt0J9K AeHrWvynEeFfA3iKy8YxanJajS9ORCJLcXhmEmQR/UflWrpEfiXwk13ZwaN9sgkmMiOHA4JroofG enSzRp5c6pKzLHMU+R9oySD+FNj8b6Y0buY51RYmlQlf9Yo6kUHTRjWpqUXTunuY2i+HNVu11y91 K3W2m1KLYke7JWotNufE+i6GNG/4R8zbFZBKsgwQc8/rXQp4y0/yZ3mjuIWhRZBG6fM6t0wKV/GF nHb7pba5imMvlrA8eGY4zxmg3davJtSp3u1p8tLa9iPwPo1zoehGG+2rNLIZCoP3c9qK1dK1W21m 0+0Wu4hWKOrDBVh1BooPNrSnOo5T0bPmWyvJNP1KC8i+/BKJBj2PSvU/+F4wEcaFMTj/AJ6jrXlA UGXGOOtTW6KzYIyKR7Tw0az94h1Ce41LULm9lX57iRpG/E9K7/wj8UH8PeH4NKudNkumgJCSLIB8 ueB+FcWQBkUwDjNBs8DTaSZ0njXxOfGl9bT/AGdraK3QqELbsknOa2PC/gZvE+hWE0N8tt/Z980u Cmd/3Tj26VxkYww+lexfCb/kWZ/+vg/yFNE4/D06OF91dSXS/h/Jp3xAvPFDX6SLc7v3GzkZx3/C u02DsB+VHrSj7pPeg+cOE0T4b/2bJrv2jUfOj1Y5ARMGM7sg+5rRbwjdXhVNS1iW4ijjMcaIgXqM ZPr0rqe496XqKDWFecFZM5M+C5biOQXmpNLJ5KwRsIwAiggj8eKs33hJL2W8kN0yPcxRopA5Qp0I roxzQKC/rVXucm3ghUgtPIvAJoI2jZ5Yg4k3HJbB75rR07w8unX0l155m32ywFSoHTPPHrmtvotN kOEOKBSxVWSs2eeWmi30t/aWJguo7O3nkJWRAFjUg9GHXrWvH4IItZbVr1fK8po49sKqwB7k9663 Az0oA5+lM1njaj20ObvfCEd7I8hu3Qm3jhQqv3SpyDTLrwlc3sayXmpma6SUSIzRjYvGMba6juKM dBQZLE1O5n6Nph0qxMDzeczOXLBAoyewA7UVoUUjGUuZ3e5//9k= ------=_NextPart_000_010B_01C642B6.1A410E30-- --===============0920307029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0920307029==-- From iptel-bounces@ietf.org Wed Mar 08 11:34:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1ca-0005QH-Pg; Wed, 08 Mar 2006 11:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH1cZ-0005O4-JW for iptel@ietf.org; Wed, 08 Mar 2006 11:34:43 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH1UJ-0007Hf-Bh for iptel@ietf.org; Wed, 08 Mar 2006 11:26:11 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2006 08:26:11 -0800 X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="1783079523:sNHT40760938" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k28GPx81017462; Wed, 8 Mar 2006 08:26:10 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 11:26:08 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 11:26:08 -0500 Message-ID: <440F05A0.4040305@cisco.com> Date: Wed, 08 Mar 2006 11:26:08 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@ietf.org Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt References: <32755D354E6B65498C3BD9FD496C7D462C48BA@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C48BA@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 16:26:08.0561 (UTC) FILETIME=[0162AA10:01C642CD] X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I agree with Richard that I support the concept of this draft, but have a few nits. I have a different spin on the one Richard pointed out: All the parameters defined in 3966 are part of the phone number. When the definitions in 3966 are applied to sip with the user=phone uri parameter, the parameters defined in 3966 all go before the "@" sign. The user=dialstring is just a variant on this, so I expect the phone-context parameter ought to go before the "@" sign in that case too. For example: ; what a SIP Phone might emit when a user dials extension 123 sip:123;phone-context=altlanta.example.com@sippbx.example.com;user=dialstring Next, this draft permits the dialled digits A-F, but it doesn't permit * and #. 3966 does permit * and # as well as E and F - apparently they are synonymous. (When used in conjunction with sip uris, the # has to be escaped as %23.) We are slightly in limbo here, because 3261 references 2805 rather than 3966. Need to deal with that somehow. I think it would be helpful to introduce in this draft a formal syntax for the user part. The following is a suggested start at a syntax. This could just be for user=dialstring, but this might be a convenient place to revise 3261 so it references 3966 for user=phone as well. The following is a start at the changes. I've included some stuff from 3261 and 3966 for reference that probably don't need to be included in the draft. ;;; UNCHANGED RULES FROM 3261: ;SIP-URI = "sip:" [ userinfo ] hostport ; uri-parameters [ headers ] ;SIPS-URI = "sips:" [ userinfo ] hostport ; uri-parameters [ headers ] ;user = 1*( unreserved / escaped / user-unreserved ) ;user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" ; ;uri-parameters = *( ";" uri-parameter) ; ;uri-parameter = transport-param / user-param / method-param ; / ttl-param / maddr-param / lr-param ; / other-param ;;; UNCHANGED RULES FROM 3966 ; local-number = local-number-digits *par context *par ; local-number-digits = ; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex ; phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] ; visual-separator = "-" / "." / "(" / ")" ;;; REVISED RULES FROM 3261 userinfo = ( user / telephone-subscriber / dial-string ) [ ":" password ] "@" user-param = "user=" ( "phone" / "ip" / "dialstring" / other-user) The BNF for 'telephone-subscriber', 'par', and 'context' can be found in RFC 3966 [?]. Note, however, that any characters allowed there that are not allowed in the 'user' part of the SIP URI MUST be escaped. ;;; NEW RULES dial-string = dial-string-number *par context *par dial-string-number = 1* ( [ "X" ] 1*dial-string-segment ) dial-string-segment = ( * "P" ) dial-string-digit dial-string-digit = HEXDIG / "*" / "#" This needs to be accompanied by text explaining that the dial-string syntax applies when the user=dialstring parameter is present. Thanks, Paul Stastny Richard wrote: > Brian, > > in principle I support and welcome this draft > > A minor comment to the phone-context examples: > > "When the "user=dialstring" is used, a context parameter as defined in > [RFC3966] MUST be specified." > > Ok > > but in your examples you use > (Examples of dialstring use include) > ; what a SIP Phone might emit when a user dials extension 123 > sip:123@sippbx.example.com;user=dialstring; > phone-context='AtlantaDialPlan' > > but phone-context is defined in RFC3966 as: > context = ";phone-context=" descriptor > descriptor = domainname / global-number-digits > > this is because the phone-context must globally unique > > so you should use in your examples either > > phone-context=altlanta.example.com > > or > > phone-context=+1234 > > (without "") > > regards > > Richard > > > ________________________________ > > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Di 07.03.2006 21:50 > An: i-d-announce@ietf.org > Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Dialstring parameter for the Session Initiation Protocol URI > Author(s) : B. Rosen > Filename : draft-rosen-iptel-dialstring-03.txt > Pages : 8 > Date : 2006-3-7 > > RFC3966 explicitly states that TEL URIs may not represent a dial > string. That leaves no way specify a dialstring in a standardized > way. Great confusion exists with the SIP URI parameter "user=phone", > and specifically, if it can represent a dial string. This memo > creates a new value for the user parameter "dialstring", so that one > may specify "user=dialstring" to encode a dialstring as a SIP or SIPS > URI. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-rosen-iptel-dialstring-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > ------------------------------------------------------------------------ > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 14:33:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH4PO-0002u4-Vg; Wed, 08 Mar 2006 14:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH4PN-0002tz-VX for iptel@ietf.org; Wed, 08 Mar 2006 14:33:17 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH4PN-0005DF-GY for iptel@ietf.org; Wed, 08 Mar 2006 14:33:17 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FH4PE-0001di-W5; Wed, 08 Mar 2006 13:33:09 -0600 From: "Brian Rosen" To: "'Paul Kyzivat'" , Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Wed, 8 Mar 2006 14:33:03 -0500 Message-ID: <175301c642e7$20555660$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZCzjb+OC/HG+TlTbGsHc1fcyWZBQAF5pxg In-Reply-To: <440F05A0.4040305@cisco.com> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: 'Stastny Richard' X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I think what you propose for the phone number parameters are too ugly, and unnecessary. What I did with the current language is define a new parameter as defined in 3966. This makes the user parameter and the phone-context parameter the same type of parameter. The user= doesn't go before the "@", and neither should the phone-context. I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in this draft for the dialstring is a good idea. I can add the escaped * and #. And Richard, of course you are correct; sloppy editing on my part, and I'll fix the examples. Brian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, March 08, 2006 11:26 AM To: iptel@ietf.org Cc: Stastny Richard Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt I agree with Richard that I support the concept of this draft, but have a few nits. I have a different spin on the one Richard pointed out: All the parameters defined in 3966 are part of the phone number. When the definitions in 3966 are applied to sip with the user=phone uri parameter, the parameters defined in 3966 all go before the "@" sign. The user=dialstring is just a variant on this, so I expect the phone-context parameter ought to go before the "@" sign in that case too. For example: ; what a SIP Phone might emit when a user dials extension 123 sip:123;phone-context=altlanta.example.com@sippbx.example.com;user=dialstrin g Next, this draft permits the dialled digits A-F, but it doesn't permit * and #. 3966 does permit * and # as well as E and F - apparently they are synonymous. (When used in conjunction with sip uris, the # has to be escaped as %23.) We are slightly in limbo here, because 3261 references 2805 rather than 3966. Need to deal with that somehow. I think it would be helpful to introduce in this draft a formal syntax for the user part. The following is a suggested start at a syntax. This could just be for user=dialstring, but this might be a convenient place to revise 3261 so it references 3966 for user=phone as well. The following is a start at the changes. I've included some stuff from 3261 and 3966 for reference that probably don't need to be included in the draft. ;;; UNCHANGED RULES FROM 3261: ;SIP-URI = "sip:" [ userinfo ] hostport ; uri-parameters [ headers ] ;SIPS-URI = "sips:" [ userinfo ] hostport ; uri-parameters [ headers ] ;user = 1*( unreserved / escaped / user-unreserved ) ;user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" ; ;uri-parameters = *( ";" uri-parameter) ; ;uri-parameter = transport-param / user-param / method-param ; / ttl-param / maddr-param / lr-param ; / other-param ;;; UNCHANGED RULES FROM 3966 ; local-number = local-number-digits *par context *par ; local-number-digits = ; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex ; phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] ; visual-separator = "-" / "." / "(" / ")" ;;; REVISED RULES FROM 3261 userinfo = ( user / telephone-subscriber / dial-string ) [ ":" password ] "@" user-param = "user=" ( "phone" / "ip" / "dialstring" / other-user) The BNF for 'telephone-subscriber', 'par', and 'context' can be found in RFC 3966 [?]. Note, however, that any characters allowed there that are not allowed in the 'user' part of the SIP URI MUST be escaped. ;;; NEW RULES dial-string = dial-string-number *par context *par dial-string-number = 1* ( [ "X" ] 1*dial-string-segment ) dial-string-segment = ( * "P" ) dial-string-digit dial-string-digit = HEXDIG / "*" / "#" This needs to be accompanied by text explaining that the dial-string syntax applies when the user=dialstring parameter is present. Thanks, Paul Stastny Richard wrote: > Brian, > > in principle I support and welcome this draft > > A minor comment to the phone-context examples: > > "When the "user=dialstring" is used, a context parameter as defined in > [RFC3966] MUST be specified." > > Ok > > but in your examples you use > (Examples of dialstring use include) > ; what a SIP Phone might emit when a user dials extension 123 > sip:123@sippbx.example.com;user=dialstring; > phone-context='AtlantaDialPlan' > > but phone-context is defined in RFC3966 as: > context = ";phone-context=" descriptor > descriptor = domainname / global-number-digits > > this is because the phone-context must globally unique > > so you should use in your examples either > > phone-context=altlanta.example.com > > or > > phone-context=+1234 > > (without "") > > regards > > Richard > > > ________________________________ > > Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Gesendet: Di 07.03.2006 21:50 > An: i-d-announce@ietf.org > Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Dialstring parameter for the Session Initiation Protocol URI > Author(s) : B. Rosen > Filename : draft-rosen-iptel-dialstring-03.txt > Pages : 8 > Date : 2006-3-7 > > RFC3966 explicitly states that TEL URIs may not represent a dial > string. That leaves no way specify a dialstring in a standardized > way. Great confusion exists with the SIP URI parameter "user=phone", > and specifically, if it can represent a dial string. This memo > creates a new value for the user parameter "dialstring", so that one > may specify "user=dialstring" to encode a dialstring as a SIP or SIPS > URI. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-rosen-iptel-dialstring-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > ------------------------------------------------------------------------ > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 15:44:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5Wd-0002DT-6t; Wed, 08 Mar 2006 15:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5Wc-0002DO-VO for iptel@ietf.org; Wed, 08 Mar 2006 15:44:50 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5Wc-00086U-Ef for iptel@ietf.org; Wed, 08 Mar 2006 15:44:50 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2006 12:44:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,176,1139212800"; d="scan'208"; a="23233031:sNHT28010684" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k28KimWc013619; Wed, 8 Mar 2006 15:44:49 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 15:44:48 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 15:44:48 -0500 Message-ID: <440F4240.2000705@cisco.com> Date: Wed, 08 Mar 2006 15:44:48 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt References: <175301c642e7$20555660$640fa8c0@cis.neustar.com> In-Reply-To: <175301c642e7$20555660$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 20:44:48.0527 (UTC) FILETIME=[240189F0:01C642F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: iptel@ietf.org, 'Stastny Richard' X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Brian Rosen wrote: > I think what you propose for the phone number parameters are too ugly, and > unnecessary. What I did with the current language is define a new parameter > as defined in 3966. This makes the user parameter and the phone-context > parameter the same type of parameter. The user= doesn't go before the "@", > and neither should the phone-context. It was my feeling that this is pretty similar to user=phone, so I was expecting the representation to be similar as well. I find it pretty surprising to reuse the phone-context parameter but in an entirely different namespace. Even more so if the values for the parameter have a differing meaning. (If that is to be done it might be better to change the name.) Are you proposing that a phone-context *URI parameter* be valid for user=phone as well? I would prefer this to deviate as little as possible from the sip form of the tel uri. > I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in this > draft for the dialstring is a good idea. > > I can add the escaped * and #. Only # *needs* to be escaped if it is used. Paul > And Richard, of course you are correct; sloppy editing on my part, and I'll > fix the examples. > > Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 11:26 AM > To: iptel@ietf.org > Cc: Stastny Richard > Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > I agree with Richard that I support the concept of this draft, but have > a few nits. I have a different spin on the one Richard pointed out: > > All the parameters defined in 3966 are part of the phone number. When > the definitions in 3966 are applied to sip with the user=phone uri > parameter, the parameters defined in 3966 all go before the "@" sign. > The user=dialstring is just a variant on this, so I expect the > phone-context parameter ought to go before the "@" sign in that case > too. For example: > > ; what a SIP Phone might emit when a user dials extension 123 > sip:123;phone-context=altlanta.example.com@sippbx.example.com;user=dialstrin > g > > Next, this draft permits the dialled digits A-F, but it doesn't permit * > and #. 3966 does permit * and # as well as E and F - apparently they are > synonymous. (When used in conjunction with sip uris, the # has to be > escaped as %23.) > > We are slightly in limbo here, because 3261 references 2805 rather than > 3966. Need to deal with that somehow. I think it would be helpful to > introduce in this draft a formal syntax for the user part. The following > is a suggested start at a syntax. This could just be for > user=dialstring, but this might be a convenient place to revise 3261 so > it references 3966 for user=phone as well. The following is a start at > the changes. I've included some stuff from 3261 and 3966 for reference > that probably don't need to be included in the draft. > > ;;; UNCHANGED RULES FROM 3261: > ;SIP-URI = "sip:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;SIPS-URI = "sips:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;user = 1*( unreserved / escaped / user-unreserved ) > ;user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" > ; > ;uri-parameters = *( ";" uri-parameter) > ; > ;uri-parameter = transport-param / user-param / method-param > ; / ttl-param / maddr-param / lr-param > > ; / other-param > > ;;; UNCHANGED RULES FROM 3966 > ; local-number = local-number-digits *par context *par > ; local-number-digits = > ; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex > ; phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] > ; visual-separator = "-" / "." / "(" / ")" > > > ;;; REVISED RULES FROM 3261 > userinfo = ( user / telephone-subscriber / dial-string ) > [ ":" password ] "@" > user-param = "user=" > ( "phone" / "ip" / "dialstring" / other-user) > > The BNF for 'telephone-subscriber', 'par', and 'context' can be > found in RFC 3966 [?]. Note, however, that any characters allowed > there that are not allowed in the 'user' part of the SIP URI MUST > be escaped. > > > > ;;; NEW RULES > dial-string = dial-string-number *par context *par > dial-string-number = 1* ( [ "X" ] 1*dial-string-segment ) > dial-string-segment = ( * "P" ) dial-string-digit > dial-string-digit = HEXDIG / "*" / "#" > > > This needs to be accompanied by text explaining that the dial-string > syntax applies when the user=dialstring parameter is present. > > Thanks, > Paul > > Stastny Richard wrote: > >>Brian, >> >>in principle I support and welcome this draft >> >>A minor comment to the phone-context examples: >> >>"When the "user=dialstring" is used, a context parameter as defined in >> [RFC3966] MUST be specified." >> >>Ok >> >>but in your examples you use >>(Examples of dialstring use include) >> ; what a SIP Phone might emit when a user dials extension 123 >> sip:123@sippbx.example.com;user=dialstring; >> phone-context='AtlantaDialPlan' >> >>but phone-context is defined in RFC3966 as: >>context = ";phone-context=" descriptor >>descriptor = domainname / global-number-digits >> >>this is because the phone-context must globally unique >> >>so you should use in your examples either >> >>phone-context=altlanta.example.com >> >>or >> >>phone-context=+1234 >> >>(without "") >> >>regards >> >>Richard >> >> >>________________________________ >> >>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Gesendet: Di 07.03.2006 21:50 >>An: i-d-announce@ietf.org >>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> >> Title : Dialstring parameter for the Session Initiation > > Protocol URI > >> Author(s) : B. Rosen >> Filename : draft-rosen-iptel-dialstring-03.txt >> Pages : 8 >> Date : 2006-3-7 >> >>RFC3966 explicitly states that TEL URIs may not represent a dial >>string. That leaves no way specify a dialstring in a standardized >>way. Great confusion exists with the SIP URI parameter "user=phone", >>and specifically, if it can represent a dial string. This memo >>creates a new value for the user parameter "dialstring", so that one >>may specify "user=dialstring" to encode a dialstring as a SIP or SIPS >>URI. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of the > > message. > >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-rosen-iptel-dialstring-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 16:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Cw-00083s-0s; Wed, 08 Mar 2006 16:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Cv-000818-8O for iptel@ietf.org; Wed, 08 Mar 2006 16:28:33 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FH6Cu-0007lD-8X for iptel@ietf.org; Wed, 08 Mar 2006 16:28:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Wed, 8 Mar 2006 22:32:31 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48C1@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Thread-Index: AcZC8bVhHHWRlPZpRgygCxKPg8P+rQABSCLn From: "Stastny Richard" To: "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Brian, Paul, =20 My first answer was too fast (and incomplete) =20 a dialstring is NOT a tel URI, it is something different so draft-rosen-iptel-dialstring should not reference RFC 3966 it should define separately how to include a dialstring into a sip, sips = URI with the sip parameter user=3Ddialstring similar user=3Dphone defines how to include a tel URI in a sip URI and it needs to define the whole syntax in the way Paul proposed =20 of course it should copy the syntax of RFC 3966 as far as possible, including the phone-context =20 sip:123;phone-context=3Datl.example.com@sippbx.example.com;user=3Ddialstr= ing =20 cheers Richard =20 ________________________________ Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] Gesendet: Mi 08.03.2006 21:44 An: br@brianrosen.net Cc: iptel@ietf.org; Stastny Richard Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Brian Rosen wrote: > I think what you propose for the phone number parameters are too ugly, = and > unnecessary. What I did with the current language is define a new = parameter > as defined in 3966. This makes the user parameter and the = phone-context > parameter the same type of parameter. The user=3D doesn't go before = the "@", > and neither should the phone-context. It was my feeling that this is pretty similar to user=3Dphone, so I was expecting the representation to be similar as well. I find it pretty surprising to reuse the phone-context parameter but in an entirely different namespace. Even more so if the values for the parameter have a differing meaning. (If that is to be done it might be better to change the name.) Are you proposing that a phone-context *URI parameter* be valid for user=3Dphone as well? I would prefer this to deviate as little as possible from the sip form of the tel uri. > I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in = this > draft for the dialstring is a good idea. > > I can add the escaped * and #.=20 Only # *needs* to be escaped if it is used. Paul > And Richard, of course you are correct; sloppy editing on my part, and = I'll > fix the examples. > > Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 11:26 AM > To: iptel@ietf.org > Cc: Stastny Richard > Subject: Re: [Iptel] Re: I-D = ACTION:draft-rosen-iptel-dialstring-03.txt > > I agree with Richard that I support the concept of this draft, but = have > a few nits. I have a different spin on the one Richard pointed out: > > All the parameters defined in 3966 are part of the phone number. When > the definitions in 3966 are applied to sip with the user=3Dphone uri > parameter, the parameters defined in 3966 all go before the "@" sign. > The user=3Ddialstring is just a variant on this, so I expect the > phone-context parameter ought to go before the "@" sign in that case > too. For example: > > ; what a SIP Phone might emit when a user dials extension 123 > = sip:123;phone-context=3Daltlanta.example.com@sippbx.example.com;user=3Ddi= alstrin > g > > Next, this draft permits the dialled digits A-F, but it doesn't permit = * > and #. 3966 does permit * and # as well as E and F - apparently they = are > synonymous. (When used in conjunction with sip uris, the # has to be > escaped as %23.) > > We are slightly in limbo here, because 3261 references 2805 rather = than > 3966. Need to deal with that somehow. I think it would be helpful to > introduce in this draft a formal syntax for the user part. The = following > is a suggested start at a syntax. This could just be for > user=3Ddialstring, but this might be a convenient place to revise 3261 = so > it references 3966 for user=3Dphone as well. The following is a start = at > the changes. I've included some stuff from 3261 and 3966 for reference > that probably don't need to be included in the draft. > > ;;; UNCHANGED RULES FROM 3261: > ;SIP-URI =3D "sip:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;SIPS-URI =3D "sips:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;user =3D 1*( unreserved / escaped / user-unreserved ) > ;user-unreserved =3D "&" / "=3D" / "+" / "$" / "," / ";" / "?" / "/" > ; > ;uri-parameters =3D *( ";" uri-parameter) > ; > ;uri-parameter =3D transport-param / user-param / method-param > ; / ttl-param / maddr-param / lr-param > > ; / other-param > > ;;; UNCHANGED RULES FROM 3966 > ; local-number =3D local-number-digits *par context *par > ; local-number-digits =3D > ; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex > ; phonedigit-hex =3D HEXDIG / "*" / "#" / [ visual-separator ] > ; visual-separator =3D "-" / "." / "(" / ")" > > > ;;; REVISED RULES FROM 3261 > userinfo =3D ( user / telephone-subscriber / dial-string ) > [ ":" password ] "@" > user-param =3D "user=3D" > ( "phone" / "ip" / "dialstring" / other-user) > > The BNF for 'telephone-subscriber', 'par', and 'context' can be > found in RFC 3966 [?]. Note, however, that any characters allowed > there that are not allowed in the 'user' part of the SIP URI MUST > be escaped. > > > > ;;; NEW RULES > dial-string =3D dial-string-number *par context *par > dial-string-number =3D 1* ( [ "X" ] 1*dial-string-segment ) > dial-string-segment =3D ( * "P" ) dial-string-digit > dial-string-digit =3D HEXDIG / "*" / "#" > > > This needs to be accompanied by text explaining that the dial-string > syntax applies when the user=3Ddialstring parameter is present. > > Thanks, > Paul > > Stastny Richard wrote: > >>Brian, >> >>in principle I support and welcome this draft >> >>A minor comment to the phone-context examples: >> >>"When the "user=3Ddialstring" is used, a context parameter as defined = in >> [RFC3966] MUST be specified." >> >>Ok >> >>but in your examples you use >>(Examples of dialstring use include) >> ; what a SIP Phone might emit when a user dials extension 123 >> sip:123@sippbx.example.com;user=3Ddialstring; >> phone-context=3D'AtlantaDialPlan' >> >>but phone-context is defined in RFC3966 as: >>context =3D ";phone-context=3D" descriptor >>descriptor =3D domainname / global-number-digits >> >>this is because the phone-context must globally unique >> >>so you should use in your examples either >> >>phone-context=3Daltlanta.example.com >> >>or >> >>phone-context=3D+1234 >> >>(without "") >> >>regards >> >>Richard >> >> >>________________________________ >> >>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Gesendet: Di 07.03.2006 21:50 >>An: i-d-announce@ietf.org >>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> >> Title : Dialstring parameter for the Session = Initiation > > Protocol URI > >> Author(s) : B. Rosen >> Filename : draft-rosen-iptel-dialstring-03.txt >> Pages : 8 >> Date : 2006-3-7 >> =20 >>RFC3966 explicitly states that TEL URIs may not represent a dial >>string. That leaves no way specify a dialstring in a standardized >>way. Great confusion exists with the SIP URI parameter = "user=3Dphone", >>and specifically, if it can represent a dial string. This memo >>creates a new value for the user parameter "dialstring", so that one >>may specify "user=3Ddialstring" to encode a dialstring as a SIP or = SIPS >>URI. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt= >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of = the > > message. > >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-rosen-iptel-dialstring-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >> =20 >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" = or >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been = split >> up into multiple messages), so check your local documentation = on >> how to manipulate these messages. >> =20 >> =20 >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 16:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Di-0008SB-0y; Wed, 08 Mar 2006 16:29:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6Dg-0008S1-VF for iptel@ietf.org; Wed, 08 Mar 2006 16:29:20 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6Dg-0007oe-BG for iptel@ietf.org; Wed, 08 Mar 2006 16:29:20 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2006 13:29:21 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="260560326:sNHT36034648" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k28LSe7l004791; Wed, 8 Mar 2006 13:29:14 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 16:29:06 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 16:29:06 -0500 Message-ID: <440F4CA2.3020901@cisco.com> Date: Wed, 08 Mar 2006 16:29:06 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt References: <32755D354E6B65498C3BD9FD496C7D462C48C0@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C48C0@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Mar 2006 21:29:06.0510 (UTC) FILETIME=[54498EE0:01C642F7] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Stastny Richard wrote: > Paul, > > I see your problem > > What about leaving phone-context with RFC 3966? > > sip:123;phone-context=atlanta.example.com@sippbx.example.com;user=dialstring That is what I proposed. Brian didn't like it. Paul > Richard > > ________________________________ > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Mi 08.03.2006 21:44 > An: br@brianrosen.net > Cc: iptel@ietf.org; Stastny Richard > Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > > > > > Brian Rosen wrote: > >>I think what you propose for the phone number parameters are too ugly, and >>unnecessary. What I did with the current language is define a new parameter >>as defined in 3966. This makes the user parameter and the phone-context >>parameter the same type of parameter. The user= doesn't go before the "@", >>and neither should the phone-context. > > > It was my feeling that this is pretty similar to user=phone, so I was > expecting the representation to be similar as well. I find it pretty > surprising to reuse the phone-context parameter but in an entirely > different namespace. Even more so if the values for the parameter have a > differing meaning. (If that is to be done it might be better to change > the name.) > > Are you proposing that a phone-context *URI parameter* be valid for > user=phone as well? > > I would prefer this to deviate as little as possible from the sip form > of the tel uri. > > >>I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in this >>draft for the dialstring is a good idea. >> >>I can add the escaped * and #. > > > Only # *needs* to be escaped if it is used. > > Paul > > >>And Richard, of course you are correct; sloppy editing on my part, and I'll >>fix the examples. >> >>Brian >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, March 08, 2006 11:26 AM >>To: iptel@ietf.org >>Cc: Stastny Richard >>Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >> >>I agree with Richard that I support the concept of this draft, but have >>a few nits. I have a different spin on the one Richard pointed out: >> >>All the parameters defined in 3966 are part of the phone number. When >>the definitions in 3966 are applied to sip with the user=phone uri >>parameter, the parameters defined in 3966 all go before the "@" sign. >>The user=dialstring is just a variant on this, so I expect the >>phone-context parameter ought to go before the "@" sign in that case >>too. For example: >> >>; what a SIP Phone might emit when a user dials extension 123 >>sip:123;phone-context=altlanta.example.com@sippbx.example.com;user=dialstrin >>g >> >>Next, this draft permits the dialled digits A-F, but it doesn't permit * >>and #. 3966 does permit * and # as well as E and F - apparently they are >>synonymous. (When used in conjunction with sip uris, the # has to be >>escaped as %23.) >> >>We are slightly in limbo here, because 3261 references 2805 rather than >>3966. Need to deal with that somehow. I think it would be helpful to >>introduce in this draft a formal syntax for the user part. The following >>is a suggested start at a syntax. This could just be for >>user=dialstring, but this might be a convenient place to revise 3261 so >>it references 3966 for user=phone as well. The following is a start at >>the changes. I've included some stuff from 3261 and 3966 for reference >>that probably don't need to be included in the draft. >> >>;;; UNCHANGED RULES FROM 3261: >>;SIP-URI = "sip:" [ userinfo ] hostport >>; uri-parameters [ headers ] >>;SIPS-URI = "sips:" [ userinfo ] hostport >>; uri-parameters [ headers ] >>;user = 1*( unreserved / escaped / user-unreserved ) >>;user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" >>; >>;uri-parameters = *( ";" uri-parameter) >>; >>;uri-parameter = transport-param / user-param / method-param >>; / ttl-param / maddr-param / lr-param >> >>; / other-param >> >>;;; UNCHANGED RULES FROM 3966 >>; local-number = local-number-digits *par context *par >>; local-number-digits = >>; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex >>; phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] >>; visual-separator = "-" / "." / "(" / ")" >> >> >>;;; REVISED RULES FROM 3261 >>userinfo = ( user / telephone-subscriber / dial-string ) >> [ ":" password ] "@" >>user-param = "user=" >> ( "phone" / "ip" / "dialstring" / other-user) >> >> The BNF for 'telephone-subscriber', 'par', and 'context' can be >> found in RFC 3966 [?]. Note, however, that any characters allowed >> there that are not allowed in the 'user' part of the SIP URI MUST >> be escaped. >> >> >> >>;;; NEW RULES >>dial-string = dial-string-number *par context *par >>dial-string-number = 1* ( [ "X" ] 1*dial-string-segment ) >>dial-string-segment = ( * "P" ) dial-string-digit >>dial-string-digit = HEXDIG / "*" / "#" >> >> >>This needs to be accompanied by text explaining that the dial-string >>syntax applies when the user=dialstring parameter is present. >> >> Thanks, >> Paul >> >>Stastny Richard wrote: >> >> >>>Brian, >>> >>>in principle I support and welcome this draft >>> >>>A minor comment to the phone-context examples: >>> >>>"When the "user=dialstring" is used, a context parameter as defined in >>> [RFC3966] MUST be specified." >>> >>>Ok >>> >>>but in your examples you use >>>(Examples of dialstring use include) >>> ; what a SIP Phone might emit when a user dials extension 123 >>> sip:123@sippbx.example.com;user=dialstring; >>> phone-context='AtlantaDialPlan' >>> >>>but phone-context is defined in RFC3966 as: >>>context = ";phone-context=" descriptor >>>descriptor = domainname / global-number-digits >>> >>>this is because the phone-context must globally unique >>> >>>so you should use in your examples either >>> >>>phone-context=altlanta.example.com >>> >>>or >>> >>>phone-context=+1234 >>> >>>(without "") >>> >>>regards >>> >>>Richard >>> >>> >>>________________________________ >>> >>>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>Gesendet: Di 07.03.2006 21:50 >>>An: i-d-announce@ietf.org >>>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >>> >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> >>> Title : Dialstring parameter for the Session Initiation >> >>Protocol URI >> >> >>> Author(s) : B. Rosen >>> Filename : draft-rosen-iptel-dialstring-03.txt >>> Pages : 8 >>> Date : 2006-3-7 >>> >>>RFC3966 explicitly states that TEL URIs may not represent a dial >>>string. That leaves no way specify a dialstring in a standardized >>>way. Great confusion exists with the SIP URI parameter "user=phone", >>>and specifically, if it can represent a dial string. This memo >>>creates a new value for the user parameter "dialstring", so that one >>>may specify "user=dialstring" to encode a dialstring as a SIP or SIPS >>>URI. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt >>> >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of the >> >>message. >> >> >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the >> >>username >> >> >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-rosen-iptel-dialstring-03.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant mail >> >>readers >> >> >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www1.ietf.org/mailman/listinfo/i-d-announce >>> >>> >>>------------------------------------------------------------------------ >>> >>>_______________________________________________ >>>Iptel mailing list >>>Iptel@ietf.org >>>https://www1.ietf.org/mailman/listinfo/iptel >> >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel >> > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 16:36:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6KD-0002bC-A0; Wed, 08 Mar 2006 16:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5vy-000598-PI for iptel@ietf.org; Wed, 08 Mar 2006 16:11:03 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FH5vw-0005on-Qy for iptel@ietf.org; Wed, 08 Mar 2006 16:11:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Wed, 8 Mar 2006 22:12:20 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48C0@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Thread-Index: AcZC8bVhHHWRlPZpRgygCxKPg8P+rQAA0cqb From: "Stastny Richard" To: "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Paul, I see your problem =20 What about leaving phone-context with RFC 3966? =20 sip:123;phone-context=3Datlanta.example.com@sippbx.example.com;user=3Ddia= lstring =20 Richard ________________________________ Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] Gesendet: Mi 08.03.2006 21:44 An: br@brianrosen.net Cc: iptel@ietf.org; Stastny Richard Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Brian Rosen wrote: > I think what you propose for the phone number parameters are too ugly, = and > unnecessary. What I did with the current language is define a new = parameter > as defined in 3966. This makes the user parameter and the = phone-context > parameter the same type of parameter. The user=3D doesn't go before = the "@", > and neither should the phone-context. It was my feeling that this is pretty similar to user=3Dphone, so I was expecting the representation to be similar as well. I find it pretty surprising to reuse the phone-context parameter but in an entirely different namespace. Even more so if the values for the parameter have a differing meaning. (If that is to be done it might be better to change the name.) Are you proposing that a phone-context *URI parameter* be valid for user=3Dphone as well? I would prefer this to deviate as little as possible from the sip form of the tel uri. > I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in = this > draft for the dialstring is a good idea. > > I can add the escaped * and #.=20 Only # *needs* to be escaped if it is used. Paul > And Richard, of course you are correct; sloppy editing on my part, and = I'll > fix the examples. > > Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 11:26 AM > To: iptel@ietf.org > Cc: Stastny Richard > Subject: Re: [Iptel] Re: I-D = ACTION:draft-rosen-iptel-dialstring-03.txt > > I agree with Richard that I support the concept of this draft, but = have > a few nits. I have a different spin on the one Richard pointed out: > > All the parameters defined in 3966 are part of the phone number. When > the definitions in 3966 are applied to sip with the user=3Dphone uri > parameter, the parameters defined in 3966 all go before the "@" sign. > The user=3Ddialstring is just a variant on this, so I expect the > phone-context parameter ought to go before the "@" sign in that case > too. For example: > > ; what a SIP Phone might emit when a user dials extension 123 > = sip:123;phone-context=3Daltlanta.example.com@sippbx.example.com;user=3Ddi= alstrin > g > > Next, this draft permits the dialled digits A-F, but it doesn't permit = * > and #. 3966 does permit * and # as well as E and F - apparently they = are > synonymous. (When used in conjunction with sip uris, the # has to be > escaped as %23.) > > We are slightly in limbo here, because 3261 references 2805 rather = than > 3966. Need to deal with that somehow. I think it would be helpful to > introduce in this draft a formal syntax for the user part. The = following > is a suggested start at a syntax. This could just be for > user=3Ddialstring, but this might be a convenient place to revise 3261 = so > it references 3966 for user=3Dphone as well. The following is a start = at > the changes. I've included some stuff from 3261 and 3966 for reference > that probably don't need to be included in the draft. > > ;;; UNCHANGED RULES FROM 3261: > ;SIP-URI =3D "sip:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;SIPS-URI =3D "sips:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;user =3D 1*( unreserved / escaped / user-unreserved ) > ;user-unreserved =3D "&" / "=3D" / "+" / "$" / "," / ";" / "?" / "/" > ; > ;uri-parameters =3D *( ";" uri-parameter) > ; > ;uri-parameter =3D transport-param / user-param / method-param > ; / ttl-param / maddr-param / lr-param > > ; / other-param > > ;;; UNCHANGED RULES FROM 3966 > ; local-number =3D local-number-digits *par context *par > ; local-number-digits =3D > ; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex > ; phonedigit-hex =3D HEXDIG / "*" / "#" / [ visual-separator ] > ; visual-separator =3D "-" / "." / "(" / ")" > > > ;;; REVISED RULES FROM 3261 > userinfo =3D ( user / telephone-subscriber / dial-string ) > [ ":" password ] "@" > user-param =3D "user=3D" > ( "phone" / "ip" / "dialstring" / other-user) > > The BNF for 'telephone-subscriber', 'par', and 'context' can be > found in RFC 3966 [?]. Note, however, that any characters allowed > there that are not allowed in the 'user' part of the SIP URI MUST > be escaped. > > > > ;;; NEW RULES > dial-string =3D dial-string-number *par context *par > dial-string-number =3D 1* ( [ "X" ] 1*dial-string-segment ) > dial-string-segment =3D ( * "P" ) dial-string-digit > dial-string-digit =3D HEXDIG / "*" / "#" > > > This needs to be accompanied by text explaining that the dial-string > syntax applies when the user=3Ddialstring parameter is present. > > Thanks, > Paul > > Stastny Richard wrote: > >>Brian, >> >>in principle I support and welcome this draft >> >>A minor comment to the phone-context examples: >> >>"When the "user=3Ddialstring" is used, a context parameter as defined = in >> [RFC3966] MUST be specified." >> >>Ok >> >>but in your examples you use >>(Examples of dialstring use include) >> ; what a SIP Phone might emit when a user dials extension 123 >> sip:123@sippbx.example.com;user=3Ddialstring; >> phone-context=3D'AtlantaDialPlan' >> >>but phone-context is defined in RFC3966 as: >>context =3D ";phone-context=3D" descriptor >>descriptor =3D domainname / global-number-digits >> >>this is because the phone-context must globally unique >> >>so you should use in your examples either >> >>phone-context=3Daltlanta.example.com >> >>or >> >>phone-context=3D+1234 >> >>(without "") >> >>regards >> >>Richard >> >> >>________________________________ >> >>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Gesendet: Di 07.03.2006 21:50 >>An: i-d-announce@ietf.org >>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> >> Title : Dialstring parameter for the Session = Initiation > > Protocol URI > >> Author(s) : B. Rosen >> Filename : draft-rosen-iptel-dialstring-03.txt >> Pages : 8 >> Date : 2006-3-7 >> =20 >>RFC3966 explicitly states that TEL URIs may not represent a dial >>string. That leaves no way specify a dialstring in a standardized >>way. Great confusion exists with the SIP URI parameter = "user=3Dphone", >>and specifically, if it can represent a dial string. This memo >>creates a new value for the user parameter "dialstring", so that one >>may specify "user=3Ddialstring" to encode a dialstring as a SIP or = SIPS >>URI. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.txt= >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of = the > > message. > >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-rosen-iptel-dialstring-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >> =20 >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" = or >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been = split >> up into multiple messages), so check your local documentation = on >> how to manipulate these messages. >> =20 >> =20 >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >>-----------------------------------------------------------------------= - >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 21:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAw5-00056L-Bp; Wed, 08 Mar 2006 21:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHAw3-000565-GU for iptel@ietf.org; Wed, 08 Mar 2006 21:31:27 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHAw1-0006v9-1J for iptel@ietf.org; Wed, 08 Mar 2006 21:31:27 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k292VKBW024952; Thu, 9 Mar 2006 02:31:21 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 21:31:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Wed, 8 Mar 2006 21:31:18 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED00809B6FB@stntexch01.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Thread-Index: AcZC8bVhHHWRlPZpRgygCxKPg8P+rQABSCLnAAn+0HA= From: "Yu, James" To: "Stastny Richard" , "Paul Kyzivat" , X-OriginalArrivalTime: 09 Mar 2006 02:31:20.0314 (UTC) FILETIME=[8CE075A0:01C64321] X-Spam-Score: 0.0 (/) X-Scan-Signature: e95407604bef3289cd27cb4f3b3a35b4 Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I'd like to discuss the scenario involving IP Multimedia Subsystem (IMS). When an IMS user originates a call to an international number (e.g., +1-703-622-1234), the IMS application/device uses a tel URI (tel:+1-703-622-1234) in the R-URI of the SIP INVITE. If the user dials a local/national number with or without the local dialing plan, what would the IMS application/device put in the R-URI? I'd guess that it would be a tel URI but with the "dial-string" indication. So I think that we need to indicate "dial-string" in the tel URI. If that is the case, we probably don't need anything in the sip URI. "user=3Dphone" in the sip URI would indicate that the user = part contains the tel URI information that may include the "dial-string" indication. Roaming mobile users' outbound calls are handled by the visited networks and they can easily determine if the callers/roamers dial local/national numbers with or without dialing prefixes. IMS creates a challenge because the outbound calls are analyzed and handled by the roamers' home IMS providers. So even if the dialed string can be passed in a tel URI to the home IMS provider, the home IMS provider would need to understand the dialing prefixes of the countries where the IMS users are currently roaming to convert the dialed string to a global/local phone number. But this is an issue for the IMS to solve. James -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, March 08, 2006 4:33 PM To: Paul Kyzivat; br@brianrosen.net Cc: iptel@ietf.org Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Brian, Paul, =20 My first answer was too fast (and incomplete) =20 a dialstring is NOT a tel URI, it is something different so draft-rosen-iptel-dialstring should not reference RFC 3966 it should define separately how to include a dialstring into a sip, sips URI with the sip parameter user=3Ddialstring similar user=3Dphone defines how to include a tel URI in a sip URI and it needs to define the whole syntax in the way Paul proposed =20 of course it should copy the syntax of RFC 3966 as far as possible, including the phone-context =20 sip:123;phone-context=3Datl.example.com@sippbx.example.com;user=3Ddialstr= ing =20 cheers Richard =20 ________________________________ Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] Gesendet: Mi 08.03.2006 21:44 An: br@brianrosen.net Cc: iptel@ietf.org; Stastny Richard Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Brian Rosen wrote: > I think what you propose for the phone number parameters are too ugly, and > unnecessary. What I did with the current language is define a new parameter > as defined in 3966. This makes the user parameter and the phone-context > parameter the same type of parameter. The user=3D doesn't go before = the "@", > and neither should the phone-context. It was my feeling that this is pretty similar to user=3Dphone, so I was expecting the representation to be similar as well. I find it pretty surprising to reuse the phone-context parameter but in an entirely different namespace. Even more so if the values for the parameter have a differing meaning. (If that is to be done it might be better to change the name.) Are you proposing that a phone-context *URI parameter* be valid for user=3Dphone as well? I would prefer this to deviate as little as possible from the sip form of the tel uri. > I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in this > draft for the dialstring is a good idea. > > I can add the escaped * and #.=20 Only # *needs* to be escaped if it is used. Paul > And Richard, of course you are correct; sloppy editing on my part, and I'll > fix the examples. > > Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, March 08, 2006 11:26 AM > To: iptel@ietf.org > Cc: Stastny Richard > Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > I agree with Richard that I support the concept of this draft, but have > a few nits. I have a different spin on the one Richard pointed out: > > All the parameters defined in 3966 are part of the phone number. When > the definitions in 3966 are applied to sip with the user=3Dphone uri > parameter, the parameters defined in 3966 all go before the "@" sign. > The user=3Ddialstring is just a variant on this, so I expect the > phone-context parameter ought to go before the "@" sign in that case > too. For example: > > ; what a SIP Phone might emit when a user dials extension 123 > sip:123;phone-context=3Daltlanta.example.com@sippbx.example.com;user=3Ddi= als trin > g > > Next, this draft permits the dialled digits A-F, but it doesn't permit * > and #. 3966 does permit * and # as well as E and F - apparently they are > synonymous. (When used in conjunction with sip uris, the # has to be > escaped as %23.) > > We are slightly in limbo here, because 3261 references 2805 rather than > 3966. Need to deal with that somehow. I think it would be helpful to > introduce in this draft a formal syntax for the user part. The following > is a suggested start at a syntax. This could just be for > user=3Ddialstring, but this might be a convenient place to revise 3261 so > it references 3966 for user=3Dphone as well. The following is a start = at > the changes. I've included some stuff from 3261 and 3966 for reference > that probably don't need to be included in the draft. > > ;;; UNCHANGED RULES FROM 3261: > ;SIP-URI =3D "sip:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;SIPS-URI =3D "sips:" [ userinfo ] hostport > ; uri-parameters [ headers ] > ;user =3D 1*( unreserved / escaped / user-unreserved ) > ;user-unreserved =3D "&" / "=3D" / "+" / "$" / "," / ";" / "?" / "/" > ; > ;uri-parameters =3D *( ";" uri-parameter) > ; > ;uri-parameter =3D transport-param / user-param / method-param > ; / ttl-param / maddr-param / lr-param > > ; / other-param > > ;;; UNCHANGED RULES FROM 3966 > ; local-number =3D local-number-digits *par context *par > ; local-number-digits =3D > ; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex > ; phonedigit-hex =3D HEXDIG / "*" / "#" / [ visual-separator ] > ; visual-separator =3D "-" / "." / "(" / ")" > > > ;;; REVISED RULES FROM 3261 > userinfo =3D ( user / telephone-subscriber / dial-string ) > [ ":" password ] "@" > user-param =3D "user=3D" > ( "phone" / "ip" / "dialstring" / other-user) > > The BNF for 'telephone-subscriber', 'par', and 'context' can be > found in RFC 3966 [?]. Note, however, that any characters allowed > there that are not allowed in the 'user' part of the SIP URI MUST > be escaped. > > > > ;;; NEW RULES > dial-string =3D dial-string-number *par context *par > dial-string-number =3D 1* ( [ "X" ] 1*dial-string-segment ) > dial-string-segment =3D ( * "P" ) dial-string-digit > dial-string-digit =3D HEXDIG / "*" / "#" > > > This needs to be accompanied by text explaining that the dial-string > syntax applies when the user=3Ddialstring parameter is present. > > Thanks, > Paul > > Stastny Richard wrote: > >>Brian, >> >>in principle I support and welcome this draft >> >>A minor comment to the phone-context examples: >> >>"When the "user=3Ddialstring" is used, a context parameter as defined = in >> [RFC3966] MUST be specified." >> >>Ok >> >>but in your examples you use >>(Examples of dialstring use include) >> ; what a SIP Phone might emit when a user dials extension 123 >> sip:123@sippbx.example.com;user=3Ddialstring; >> phone-context=3D'AtlantaDialPlan' >> >>but phone-context is defined in RFC3966 as: >>context =3D ";phone-context=3D" descriptor >>descriptor =3D domainname / global-number-digits >> >>this is because the phone-context must globally unique >> >>so you should use in your examples either >> >>phone-context=3Daltlanta.example.com >> >>or >> >>phone-context=3D+1234 >> >>(without "") >> >>regards >> >>Richard >> >> >>________________________________ >> >>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>Gesendet: Di 07.03.2006 21:50 >>An: i-d-announce@ietf.org >>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> >> Title : Dialstring parameter for the Session Initiation > > Protocol URI > >> Author(s) : B. Rosen >> Filename : draft-rosen-iptel-dialstring-03.txt >> Pages : 8 >> Date : 2006-3-7 >> =20 >>RFC3966 explicitly states that TEL URIs may not represent a dial >>string. That leaves no way specify a dialstring in a standardized >>way. Great confusion exists with the SIP URI parameter = "user=3Dphone", >>and specifically, if it can represent a dial string. This memo >>creates a new value for the user parameter "dialstring", so that one >>may specify "user=3Ddialstring" to encode a dialstring as a SIP or = SIPS >>URI. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.tx t >> >>To remove yourself from the I-D Announcement list, send a message to >>i-d-announce-request@ietf.org with the word unsubscribe in the body of the > > message. > >>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>to change your subscription settings. >> >> >>Internet-Drafts are also available by anonymous FTP. Login with the > > username > >>"anonymous" and a password of your e-mail address. After logging in, >>type "cd internet-drafts" and then >> "get draft-rosen-iptel-dialstring-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >> =20 >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail > > readers > >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> =20 >> =20 >>Below is the data which will enable a MIME compliant mail reader >>implementation to automatically retrieve the ASCII version of the >>Internet-Draft. >> >> >> >> >>---------------------------------------------------------------------- -- >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> >>---------------------------------------------------------------------- -- >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 22:27:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBoT-0003RF-0l; Wed, 08 Mar 2006 22:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHBoS-0003Ns-AW for iptel@ietf.org; Wed, 08 Mar 2006 22:27:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHBoR-0000cH-IN for iptel@ietf.org; Wed, 08 Mar 2006 22:27:40 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 08 Mar 2006 19:27:41 -0800 X-IronPort-AV: i="4.02,177,1139212800"; d="scan'208"; a="260656615:sNHT38490238" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k293RbYg014187; Wed, 8 Mar 2006 19:27:38 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 22:27:37 -0500 Received: from [10.86.243.71] ([10.86.243.71]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Mar 2006 22:27:36 -0500 Message-ID: <440FA0A8.20307@cisco.com> Date: Wed, 08 Mar 2006 22:27:36 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on References: <165FCC93A820D240A62F98E028CEFED00809B6FB@stntexch01.cis.neustar.com> In-Reply-To: <165FCC93A820D240A62F98E028CEFED00809B6FB@stntexch01.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 03:27:36.0951 (UTC) FILETIME=[69826070:01C64329] X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Yu, James wrote: > I'd like to discuss the scenario involving IP Multimedia Subsystem > (IMS). > > When an IMS user originates a call to an international number (e.g., > +1-703-622-1234), the IMS application/device uses a tel URI > (tel:+1-703-622-1234) in the R-URI of the SIP INVITE. > > If the user dials a local/national number with or without the local > dialing plan, I don't know how to parse the above. AFAIK it is normally impossible to "dial" a dialing plan. Presumably the dialing plan must be implicit. Thew question is only what entity is responsible for making the dial plan explicit by including it in the uri. As long as the URI formats require that local numbers and dialstrings contain a context, it is necessary for the UA to insert the context. IMO that is just fine - the UA *ought* to know the context. > what would the IMS application/device put in the R-URI? The obvious thing is to put the e.164 number corresponding to the dial string. If you know the context it is no big deal to turn the number into an e.164 number too. The time I have found when that isn't the solution is when the dial string conveys extra information that needs to be processed in the network - such as a star-code, or a leading zero to request operator services. While there are many ways to handle those things, passing the dialstring seems to be a useful way. > I'd guess that it would be a tel URI but with the "dial-string" > indication. Well, you are the author of the tel uri, so I'm not going to try to tell you anything about it. I didn't know it had a way to carry a dial string, or a dial-string-indicator. One of the reasons that user=dialstring was proposed (quite some time ago) was because tel couldn't do it. > So I think that we need to indicate "dial-string" in the > tel URI. If that is the case, we probably don't need anything in the > sip URI. "user=phone" in the sip URI would indicate that the user part > contains the tel URI information that may include the "dial-string" > indication. If that existed, it would be fine with me. But we have been going down this other path for some time. > Roaming mobile users' outbound calls are handled by the visited networks > and they can easily determine if the callers/roamers dial local/national > numbers with or without dialing prefixes. IMS creates a challenge > because the outbound calls are analyzed and handled by the roamers' home > IMS providers. So even if the dialed string can be passed in a tel URI > to the home IMS provider, the home IMS provider would need to understand > the dialing prefixes of the countries where the IMS users are currently > roaming to convert the dialed string to a global/local phone number. You think it is desirable that a roaming user dial using the dialling conventions of the location he has roamed to, rather than his home location? (I consider that to be grossly user-unfriendly.) Paul > But this is an issue for the IMS to solve. > > James > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 08, 2006 4:33 PM > To: Paul Kyzivat; br@brianrosen.net > Cc: iptel@ietf.org > Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > add-on > > Brian, Paul, > > My first answer was too fast (and incomplete) > > a dialstring is NOT a tel URI, it is something different > so draft-rosen-iptel-dialstring should not reference RFC 3966 > it should define separately how to include a dialstring into a sip, sips > URI > > with the sip parameter user=dialstring similar user=phone defines > how to include a tel URI in a sip URI > and it needs to define the whole syntax in the way Paul proposed > > of course it should copy the syntax of RFC 3966 as far as possible, > including the phone-context > > sip:123;phone-context=atl.example.com@sippbx.example.com;user=dialstring > > cheers > > Richard > > > ________________________________ > > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Mi 08.03.2006 21:44 > An: br@brianrosen.net > Cc: iptel@ietf.org; Stastny Richard > Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > > > > > Brian Rosen wrote: > >>I think what you propose for the phone number parameters are too ugly, > > and > >>unnecessary. What I did with the current language is define a new > > parameter > >>as defined in 3966. This makes the user parameter and the > > phone-context > >>parameter the same type of parameter. The user= doesn't go before the > > "@", > >>and neither should the phone-context. > > > It was my feeling that this is pretty similar to user=phone, so I was > expecting the representation to be similar as well. I find it pretty > surprising to reuse the phone-context parameter but in an entirely > different namespace. Even more so if the values for the parameter have a > differing meaning. (If that is to be done it might be better to change > the name.) > > Are you proposing that a phone-context *URI parameter* be valid for > user=phone as well? > > I would prefer this to deviate as little as possible from the sip form > of the tel uri. > > >>I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in > > this > >>draft for the dialstring is a good idea. >> >>I can add the escaped * and #. > > > Only # *needs* to be escaped if it is used. > > Paul > > >>And Richard, of course you are correct; sloppy editing on my part, and > > I'll > >>fix the examples. >> >>Brian >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, March 08, 2006 11:26 AM >>To: iptel@ietf.org >>Cc: Stastny Richard >>Subject: Re: [Iptel] Re: I-D > > ACTION:draft-rosen-iptel-dialstring-03.txt > >>I agree with Richard that I support the concept of this draft, but > > have > >>a few nits. I have a different spin on the one Richard pointed out: >> >>All the parameters defined in 3966 are part of the phone number. When >>the definitions in 3966 are applied to sip with the user=phone uri >>parameter, the parameters defined in 3966 all go before the "@" sign. >>The user=dialstring is just a variant on this, so I expect the >>phone-context parameter ought to go before the "@" sign in that case >>too. For example: >> >>; what a SIP Phone might emit when a user dials extension 123 >> > > sip:123;phone-context=altlanta.example.com@sippbx.example.com;user=dials > trin > >>g >> >>Next, this draft permits the dialled digits A-F, but it doesn't permit > > * > >>and #. 3966 does permit * and # as well as E and F - apparently they > > are > >>synonymous. (When used in conjunction with sip uris, the # has to be >>escaped as %23.) >> >>We are slightly in limbo here, because 3261 references 2805 rather > > than > >>3966. Need to deal with that somehow. I think it would be helpful to >>introduce in this draft a formal syntax for the user part. The > > following > >>is a suggested start at a syntax. This could just be for >>user=dialstring, but this might be a convenient place to revise 3261 > > so > >>it references 3966 for user=phone as well. The following is a start at >>the changes. I've included some stuff from 3261 and 3966 for reference >>that probably don't need to be included in the draft. >> >>;;; UNCHANGED RULES FROM 3261: >>;SIP-URI = "sip:" [ userinfo ] hostport >>; uri-parameters [ headers ] >>;SIPS-URI = "sips:" [ userinfo ] hostport >>; uri-parameters [ headers ] >>;user = 1*( unreserved / escaped / user-unreserved ) >>;user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/" >>; >>;uri-parameters = *( ";" uri-parameter) >>; >>;uri-parameter = transport-param / user-param / method-param >>; / ttl-param / maddr-param / lr-param >> >>; / other-param >> >>;;; UNCHANGED RULES FROM 3966 >>; local-number = local-number-digits *par context *par >>; local-number-digits = >>; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex >>; phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] >>; visual-separator = "-" / "." / "(" / ")" >> >> >>;;; REVISED RULES FROM 3261 >>userinfo = ( user / telephone-subscriber / dial-string ) >> [ ":" password ] "@" >>user-param = "user=" >> ( "phone" / "ip" / "dialstring" / other-user) >> >> The BNF for 'telephone-subscriber', 'par', and 'context' can be >> found in RFC 3966 [?]. Note, however, that any characters allowed >> there that are not allowed in the 'user' part of the SIP URI MUST >> be escaped. >> >> >> >>;;; NEW RULES >>dial-string = dial-string-number *par context *par >>dial-string-number = 1* ( [ "X" ] 1*dial-string-segment ) >>dial-string-segment = ( * "P" ) dial-string-digit >>dial-string-digit = HEXDIG / "*" / "#" >> >> >>This needs to be accompanied by text explaining that the dial-string >>syntax applies when the user=dialstring parameter is present. >> >> Thanks, >> Paul >> >>Stastny Richard wrote: >> >> >>>Brian, >>> >>>in principle I support and welcome this draft >>> >>>A minor comment to the phone-context examples: >>> >>>"When the "user=dialstring" is used, a context parameter as defined in >>> [RFC3966] MUST be specified." >>> >>>Ok >>> >>>but in your examples you use >>>(Examples of dialstring use include) >>> ; what a SIP Phone might emit when a user dials extension 123 >>> sip:123@sippbx.example.com;user=dialstring; >>> phone-context='AtlantaDialPlan' >>> >>>but phone-context is defined in RFC3966 as: >>>context = ";phone-context=" descriptor >>>descriptor = domainname / global-number-digits >>> >>>this is because the phone-context must globally unique >>> >>>so you should use in your examples either >>> >>>phone-context=altlanta.example.com >>> >>>or >>> >>>phone-context=+1234 >>> >>>(without "") >>> >>>regards >>> >>>Richard >>> >>> >>>________________________________ >>> >>>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>Gesendet: Di 07.03.2006 21:50 >>>An: i-d-announce@ietf.org >>>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >>> >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> >>> Title : Dialstring parameter for the Session > > Initiation > >>Protocol URI >> >> >>> Author(s) : B. Rosen >>> Filename : draft-rosen-iptel-dialstring-03.txt >>> Pages : 8 >>> Date : 2006-3-7 >>> >>>RFC3966 explicitly states that TEL URIs may not represent a dial >>>string. That leaves no way specify a dialstring in a standardized >>>way. Great confusion exists with the SIP URI parameter "user=phone", >>>and specifically, if it can represent a dial string. This memo >>>creates a new value for the user parameter "dialstring", so that one >>>may specify "user=dialstring" to encode a dialstring as a SIP or SIPS >>>URI. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.tx > > t > >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the > >>message. >> >> >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the >> >>username >> >> >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-rosen-iptel-dialstring-03.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" > > or > >>> a MIME-compliant mail reader. Different MIME-compliant mail >> >>readers >> >> >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been > > split > >>> up into multiple messages), so check your local documentation > > on > >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>> >>> >>>---------------------------------------------------------------------- > > -- > >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www1.ietf.org/mailman/listinfo/i-d-announce >>> >>> >>>---------------------------------------------------------------------- > > -- > >>>_______________________________________________ >>>Iptel mailing list >>>Iptel@ietf.org >>>https://www1.ietf.org/mailman/listinfo/iptel >> >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel >> > > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 22:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHC2K-00022W-3Q; Wed, 08 Mar 2006 22:42:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHC2I-0001xr-Ok for iptel@ietf.org; Wed, 08 Mar 2006 22:41:58 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHC2I-0000sJ-EQ for iptel@ietf.org; Wed, 08 Mar 2006 22:41:58 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k293fh1o028384 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 8 Mar 2006 22:41:44 -0500 (EST) In-Reply-To: <440FA0A8.20307@cisco.com> References: <165FCC93A820D240A62F98E028CEFED00809B6FB@stntexch01.cis.neustar.com> <440FA0A8.20307@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45353DBF-FB45-4D40-B7BD-0E48F03CA21D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Wed, 8 Mar 2006 22:41:41 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: iptel@ietf.org, Stastny Richard , "Yu, James" X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Jumping in probably without having digested the whole message trail: RFC 3966 (tel) is specifically *not* suited for dial strings; this was discussed repeatedly during the development of the draft. It says, for example, that dial strings are not directly represented (page 13). Or A SIP UA can use a dial plan to translate dial strings into SIP or "tel" URIs. The dial plan can be manually configured or, preferably, downloaded as part of a device configuration mechanism. (At this time, there is no standardized mechanism for this.) The phone-context parameter was meant to represent local numbers that don't have a real E.164 identifier representation, but they are not dial strings. RFC 3966 also puts a SHOULD NOT warning on the use of local numbers. The RFC also points out other differences, such as the inclusion of post-dial digits for controlling IVRs, which would be wholly inappropriate in an identifier, i.e., a tel URI. Needless to say, the dial strings in the draft-rosen draft also have things like pause and break, which can't be represented in RFC 3966. I hope we don't have to re-visit this whole discussion from about three years ago. Henning (author of RFC 3966) On Mar 8, 2006, at 10:27 PM, Paul Kyzivat wrote: > > > Yu, James wrote: >> I'd like to discuss the scenario involving IP Multimedia Subsystem >> (IMS). >> When an IMS user originates a call to an international number (e.g., >> +1-703-622-1234), the IMS application/device uses a tel URI >> (tel:+1-703-622-1234) in the R-URI of the SIP INVITE. >> If the user dials a local/national number with or without the local >> dialing plan, > > I don't know how to parse the above. AFAIK it is normally > impossible to "dial" a dialing plan. Presumably the dialing plan > must be implicit. Thew question is only what entity is responsible > for making the dial plan explicit by including it in the uri. As > long as the URI formats require that local numbers and dialstrings > contain a context, it is necessary for the UA to insert the > context. IMO that is just fine - the UA *ought* to know the context. > >> what would the IMS application/device put in the R-URI? > > The obvious thing is to put the e.164 number corresponding to the > dial string. If you know the context it is no big deal to turn the > number into an e.164 number too. > > The time I have found when that isn't the solution is when the dial > string conveys extra information that needs to be processed in the > network - such as a star-code, or a leading zero to request > operator services. While there are many ways to handle those > things, passing the dialstring seems to be a useful way. > >> I'd guess that it would be a tel URI but with the "dial-string" >> indication. > > Well, you are the author of the tel uri, so I'm not going to try to > tell you anything about it. I didn't know it had a way to carry a > dial string, or a dial-string-indicator. > > One of the reasons that user=dialstring was proposed (quite some > time ago) was because tel couldn't do it. > >> So I think that we need to indicate "dial-string" in the >> tel URI. If that is the case, we probably don't need anything in the >> sip URI. "user=phone" in the sip URI would indicate that the user >> part >> contains the tel URI information that may include the "dial-string" >> indication. > > If that existed, it would be fine with me. But we have been going > down this other path for some time. > >> Roaming mobile users' outbound calls are handled by the visited >> networks >> and they can easily determine if the callers/roamers dial local/ >> national >> numbers with or without dialing prefixes. IMS creates a challenge >> because the outbound calls are analyzed and handled by the >> roamers' home >> IMS providers. So even if the dialed string can be passed in a >> tel URI >> to the home IMS provider, the home IMS provider would need to >> understand >> the dialing prefixes of the countries where the IMS users are >> currently >> roaming to convert the dialed string to a global/local phone number. > > You think it is desirable that a roaming user dial using the > dialling conventions of the location he has roamed to, rather than > his home location? (I consider that to be grossly user-unfriendly.) > > Paul > >> But this is an issue for the IMS to solve. >> James _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 22:58:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCHr-00045M-0M; Wed, 08 Mar 2006 22:58:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCHo-0003tp-Tt for iptel@ietf.org; Wed, 08 Mar 2006 22:58:00 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHCHo-0001Au-Bz for iptel@ietf.org; Wed, 08 Mar 2006 22:58:00 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k293vuBW029278; Thu, 9 Mar 2006 03:57:56 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 22:57:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Wed, 8 Mar 2006 22:57:49 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED00809B70F@stntexch01.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Thread-Index: AcZDKWvv6f1XPNQVRXSVhByoQ3mrNwAANOSA From: "Yu, James" To: "Paul Kyzivat" X-OriginalArrivalTime: 09 Mar 2006 03:57:55.0521 (UTC) FILETIME=[A5762310:01C6432D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7c7a0f28a102b9cb6317697abf1cf76 Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I probably should have used "dialing prefix" instead of "dialing plan" to avoid the confusion. One way to avoid the problem is for the IMS providers to inform their IMS users to always dial "+TN". But that would not be "user-friendly". I'm based in US and my experience in London is that I could dial a London number with a prefix of "0" to reach that number. I can certainly use +TN format but that requires dialing a few more digits. Since the roaming mobile network process the call, it could figure out that my dialed string/number contains a dialing prefix of "0". What I'm trying to indicate is that many mobile users are familiar with the dialing prefixes of the countries they frequently roam into. So the IMS providers may want to allow their IMS users to do things they are used to do (e.g., dial numbers with dialing prefixes in the roaming countries). I don't know if the IMS application/handset is smart enough to know the country where the IMS user is roaming and knows all the dialing prefixes in that country to be able to convert a dialed string containing the dialing prefix to a phone number or adding a country code to a dialed national number without a dialing prefix. If it is not done by the IMS application/handset, the dialed string must be passed to the home IMS provider in a tel URI instead of sip URI. The tel URI currently does not have a way to pass the "dial string" indication and I think this I-D probably is one to address it. Although this I-D addresses the sip URI aspect, I'm throwing in a scenario to show that tel URI probably is a better place to pass that indication. How that indication is carried in the tel URI is to be addressed by this I-D. Phone-Context certainly is a candidate place to carry that indication (e.g., need to add "dialstring" as a new option). James -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, March 08, 2006 10:28 PM To: Yu, James Cc: Stastny Richard; br@brianrosen.net; iptel@ietf.org Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Yu, James wrote: > I'd like to discuss the scenario involving IP Multimedia Subsystem > (IMS). >=20 > When an IMS user originates a call to an international number (e.g., > +1-703-622-1234), the IMS application/device uses a tel URI > (tel:+1-703-622-1234) in the R-URI of the SIP INVITE. >=20 > If the user dials a local/national number with or without the local > dialing plan, I don't know how to parse the above. AFAIK it is normally impossible to=20 "dial" a dialing plan. Presumably the dialing plan must be implicit.=20 Thew question is only what entity is responsible for making the dial=20 plan explicit by including it in the uri. As long as the URI formats=20 require that local numbers and dialstrings contain a context, it is=20 necessary for the UA to insert the context. IMO that is just fine - the=20 UA *ought* to know the context. > what would the IMS application/device put in the R-URI? The obvious thing is to put the e.164 number corresponding to the dial=20 string. If you know the context it is no big deal to turn the number=20 into an e.164 number too. The time I have found when that isn't the solution is when the dial=20 string conveys extra information that needs to be processed in the=20 network - such as a star-code, or a leading zero to request operator=20 services. While there are many ways to handle those things, passing the=20 dialstring seems to be a useful way. > I'd guess that it would be a tel URI but with the "dial-string" > indication.=20 Well, you are the author of the tel uri, so I'm not going to try to tell you anything about it. I didn't know it had a way to carry a dial=20 string, or a dial-string-indicator. One of the reasons that user=3Ddialstring was proposed (quite some time=20 ago) was because tel couldn't do it. > So I think that we need to indicate "dial-string" in the > tel URI. If that is the case, we probably don't need anything in the > sip URI. "user=3Dphone" in the sip URI would indicate that the user part > contains the tel URI information that may include the "dial-string" > indication. If that existed, it would be fine with me. But we have been going down=20 this other path for some time. > Roaming mobile users' outbound calls are handled by the visited networks > and they can easily determine if the callers/roamers dial local/national > numbers with or without dialing prefixes. IMS creates a challenge > because the outbound calls are analyzed and handled by the roamers' home > IMS providers. So even if the dialed string can be passed in a tel URI > to the home IMS provider, the home IMS provider would need to understand > the dialing prefixes of the countries where the IMS users are currently > roaming to convert the dialed string to a global/local phone number. You think it is desirable that a roaming user dial using the dialling=20 conventions of the location he has roamed to, rather than his home=20 location? (I consider that to be grossly user-unfriendly.) Paul > But this is an issue for the IMS to solve. >=20 > James >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, March 08, 2006 4:33 PM > To: Paul Kyzivat; br@brianrosen.net > Cc: iptel@ietf.org > Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > add-on >=20 > Brian, Paul, > =20 > My first answer was too fast (and incomplete) > =20 > a dialstring is NOT a tel URI, it is something different > so draft-rosen-iptel-dialstring should not reference RFC 3966 > it should define separately how to include a dialstring into a sip, sips > URI >=20 > with the sip parameter user=3Ddialstring similar user=3Dphone defines > how to include a tel URI in a sip URI > and it needs to define the whole syntax in the way Paul proposed > =20 > of course it should copy the syntax of RFC 3966 as far as possible, > including the phone-context > =20 > sip:123;phone-context=3Datl.example.com@sippbx.example.com;user=3Ddialstr= ing > =20 > cheers >=20 > Richard > =20 >=20 > ________________________________ >=20 > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Mi 08.03.2006 21:44 > An: br@brianrosen.net > Cc: iptel@ietf.org; Stastny Richard > Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >=20 >=20 >=20 >=20 >=20 > Brian Rosen wrote: >=20 >>I think what you propose for the phone number parameters are too ugly, >=20 > and >=20 >>unnecessary. What I did with the current language is define a new >=20 > parameter >=20 >>as defined in 3966. This makes the user parameter and the >=20 > phone-context >=20 >>parameter the same type of parameter. The user=3D doesn't go before = the >=20 > "@", >=20 >>and neither should the phone-context. >=20 >=20 > It was my feeling that this is pretty similar to user=3Dphone, so I = was > expecting the representation to be similar as well. I find it pretty > surprising to reuse the phone-context parameter but in an entirely > different namespace. Even more so if the values for the parameter have a > differing meaning. (If that is to be done it might be better to change > the name.) >=20 > Are you proposing that a phone-context *URI parameter* be valid for > user=3Dphone as well? >=20 > I would prefer this to deviate as little as possible from the sip form > of the tel uri. >=20 >=20 >>I do think fixing 3261's ABNF is a good idea. Having a formal ABNF in >=20 > this >=20 >>draft for the dialstring is a good idea. >> >>I can add the escaped * and #.=20 >=20 >=20 > Only # *needs* to be escaped if it is used. >=20 > Paul >=20 >=20 >>And Richard, of course you are correct; sloppy editing on my part, and >=20 > I'll >=20 >>fix the examples. >> >>Brian >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, March 08, 2006 11:26 AM >>To: iptel@ietf.org >>Cc: Stastny Richard >>Subject: Re: [Iptel] Re: I-D >=20 > ACTION:draft-rosen-iptel-dialstring-03.txt >=20 >>I agree with Richard that I support the concept of this draft, but >=20 > have >=20 >>a few nits. I have a different spin on the one Richard pointed out: >> >>All the parameters defined in 3966 are part of the phone number. When >>the definitions in 3966 are applied to sip with the user=3Dphone uri >>parameter, the parameters defined in 3966 all go before the "@" sign. >>The user=3Ddialstring is just a variant on this, so I expect the >>phone-context parameter ought to go before the "@" sign in that case >>too. For example: >> >>; what a SIP Phone might emit when a user dials extension 123 >> >=20 > sip:123;phone-context=3Daltlanta.example.com@sippbx.example.com;user=3Ddi= als > trin >=20 >>g >> >>Next, this draft permits the dialled digits A-F, but it doesn't permit >=20 > * >=20 >>and #. 3966 does permit * and # as well as E and F - apparently they >=20 > are >=20 >>synonymous. (When used in conjunction with sip uris, the # has to be >>escaped as %23.) >> >>We are slightly in limbo here, because 3261 references 2805 rather >=20 > than >=20 >>3966. Need to deal with that somehow. I think it would be helpful to >>introduce in this draft a formal syntax for the user part. The >=20 > following >=20 >>is a suggested start at a syntax. This could just be for >>user=3Ddialstring, but this might be a convenient place to revise 3261 >=20 > so >=20 >>it references 3966 for user=3Dphone as well. The following is a start = at >>the changes. I've included some stuff from 3261 and 3966 for reference >>that probably don't need to be included in the draft. >> >>;;; UNCHANGED RULES FROM 3261: >>;SIP-URI =3D "sip:" [ userinfo ] hostport >>; uri-parameters [ headers ] >>;SIPS-URI =3D "sips:" [ userinfo ] hostport >>; uri-parameters [ headers ] >>;user =3D 1*( unreserved / escaped / user-unreserved ) >>;user-unreserved =3D "&" / "=3D" / "+" / "$" / "," / ";" / "?" / "/" >>; >>;uri-parameters =3D *( ";" uri-parameter) >>; >>;uri-parameter =3D transport-param / user-param / method-param >>; / ttl-param / maddr-param / lr-param >> >>; / other-param >> >>;;; UNCHANGED RULES FROM 3966 >>; local-number =3D local-number-digits *par context *par >>; local-number-digits =3D >>; *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex >>; phonedigit-hex =3D HEXDIG / "*" / "#" / [ visual-separator ] >>; visual-separator =3D "-" / "." / "(" / ")" >> >> >>;;; REVISED RULES FROM 3261 >>userinfo =3D ( user / telephone-subscriber / dial-string ) >> [ ":" password ] "@" >>user-param =3D "user=3D" >> ( "phone" / "ip" / "dialstring" / other-user) >> >> The BNF for 'telephone-subscriber', 'par', and 'context' can be >> found in RFC 3966 [?]. Note, however, that any characters allowed >> there that are not allowed in the 'user' part of the SIP URI MUST >> be escaped. >> >> >> >>;;; NEW RULES >>dial-string =3D dial-string-number *par context *par >>dial-string-number =3D 1* ( [ "X" ] 1*dial-string-segment ) >>dial-string-segment =3D ( * "P" ) dial-string-digit >>dial-string-digit =3D HEXDIG / "*" / "#" >> >> >>This needs to be accompanied by text explaining that the dial-string >>syntax applies when the user=3Ddialstring parameter is present. >> >> Thanks, >> Paul >> >>Stastny Richard wrote: >> >> >>>Brian, >>> >>>in principle I support and welcome this draft >>> >>>A minor comment to the phone-context examples: >>> >>>"When the "user=3Ddialstring" is used, a context parameter as defined in >>> [RFC3966] MUST be specified." >>> >>>Ok >>> >>>but in your examples you use >>>(Examples of dialstring use include) >>> ; what a SIP Phone might emit when a user dials extension 123 >>> sip:123@sippbx.example.com;user=3Ddialstring; >>> phone-context=3D'AtlantaDialPlan' >>> >>>but phone-context is defined in RFC3966 as: >>>context =3D ";phone-context=3D" descriptor >>>descriptor =3D domainname / global-number-digits >>> >>>this is because the phone-context must globally unique >>> >>>so you should use in your examples either >>> >>>phone-context=3Daltlanta.example.com >>> >>>or >>> >>>phone-context=3D+1234 >>> >>>(without "") >>> >>>regards >>> >>>Richard >>> >>> >>>________________________________ >>> >>>Von: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >>>Gesendet: Di 07.03.2006 21:50 >>>An: i-d-announce@ietf.org >>>Betreff: I-D ACTION:draft-rosen-iptel-dialstring-03.txt >>> >>> >>> >>>A New Internet-Draft is available from the on-line Internet-Drafts >> >>directories. >> >> >>> Title : Dialstring parameter for the Session >=20 > Initiation >=20 >>Protocol URI >> >> >>> Author(s) : B. Rosen >>> Filename : draft-rosen-iptel-dialstring-03.txt >>> Pages : 8 >>> Date : 2006-3-7 >>> =20 >>>RFC3966 explicitly states that TEL URIs may not represent a dial >>>string. That leaves no way specify a dialstring in a standardized >>>way. Great confusion exists with the SIP URI parameter = "user=3Dphone", >>>and specifically, if it can represent a dial string. This memo >>>creates a new value for the user parameter "dialstring", so that one >>>may specify "user=3Ddialstring" to encode a dialstring as a SIP or = SIPS >>>URI. >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-rosen-iptel-dialstring-03.t x >=20 > t >=20 >>>To remove yourself from the I-D Announcement list, send a message to >>>i-d-announce-request@ietf.org with the word unsubscribe in the body of >=20 > the >=20 >>message. >> >> >>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>to change your subscription settings. >>> >>> >>>Internet-Drafts are also available by anonymous FTP. Login with the >> >>username >> >> >>>"anonymous" and a password of your e-mail address. After logging in, >>>type "cd internet-drafts" and then >>> "get draft-rosen-iptel-dialstring-03.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html >>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-rosen-iptel-dialstring-03.txt". >>> =20 >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" >=20 > or >=20 >>> a MIME-compliant mail reader. Different MIME-compliant mail >> >>readers >> >> >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been >=20 > split >=20 >>> up into multiple messages), so check your local documentation >=20 > on >=20 >>> how to manipulate these messages. >>> =20 >>> =20 >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>> >>> >>>--------------------------------------------------------------------- - >=20 > -- >=20 >>>_______________________________________________ >>>I-D-Announce mailing list >>>I-D-Announce@ietf.org >>>https://www1.ietf.org/mailman/listinfo/i-d-announce >>> >>> >>>--------------------------------------------------------------------- - >=20 > -- >=20 >>>_______________________________________________ >>>Iptel mailing list >>>Iptel@ietf.org >>>https://www1.ietf.org/mailman/listinfo/iptel >> >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel >> >=20 >=20 >=20 >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 08 23:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCig-0001Vu-4R; Wed, 08 Mar 2006 23:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHCiP-0001TB-RW for iptel@ietf.org; Wed, 08 Mar 2006 23:25:29 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHCiP-0002Es-Hn for iptel@ietf.org; Wed, 08 Mar 2006 23:25:29 -0500 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k294PNBW030981; Thu, 9 Mar 2006 04:25:23 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Mar 2006 23:25:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Wed, 8 Mar 2006 23:25:21 -0500 Message-ID: <165FCC93A820D240A62F98E028CEFED00809B71B@stntexch01.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Thread-Index: AcZDK2wx3jIalHPaQ3CW4O1UMqQvcQAAmP4w From: "Yu, James" To: "Henning Schulzrinne" , "Paul Kyzivat" X-OriginalArrivalTime: 09 Mar 2006 04:25:22.0815 (UTC) FILETIME=[7B5340F0:01C64331] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I sent a response to Paul before seeing this message. I did not know about the past discussions on this. IMS is complicate because it may involve "roaming" (not "fixed") and require the home IMS provider to process the dialed digits/number. I do see a need to pass the dialed string (any number that does not have a leading "+") to the home IMS provider because it may not be feasible/desirable for the IMS application/handset to convert the dialed string to a phone number. It is fine with me if tel URI is not a good place to carry it. =20 If the IMS application/handset needs to use sip URI to pass the dialed string to the home IMS provider, it needs to put the home S-CSCF's domain name or a generic IMS provider domain name in the host part of the sip URI. This puts a requirement on the home S-CSCF to verify if the sip URI carries a "dialstring" indication so that it will convert the dialed string to a phone number and then terminate the call versus in the case when the caller tries to set up a call to a sip URI belonging to another IMS user served by the same IMS provider. James -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, March 08, 2006 10:42 PM To: Paul Kyzivat Cc: Yu, James; iptel@ietf.org; Stastny Richard Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Jumping in probably without having digested the whole message trail: RFC 3966 (tel) is specifically *not* suited for dial strings; this =20 was discussed repeatedly during the development of the draft. It =20 says, for example, that dial strings are not directly represented =20 (page 13). Or A SIP UA can use a dial plan to translate dial strings into SIP or "tel" URIs. The dial plan can be manually configured or, =20 preferably, downloaded as part of a device configuration mechanism. (At this time, there is no standardized mechanism for this.) The phone-context parameter was meant to represent local numbers that =20 don't have a real E.164 identifier representation, but they are not =20 dial strings. RFC 3966 also puts a SHOULD NOT warning on the use of =20 local numbers. The RFC also points out other differences, such as the =20 inclusion of post-dial digits for controlling IVRs, which would be =20 wholly inappropriate in an identifier, i.e., a tel URI. Needless to say, the dial strings in the draft-rosen draft also have =20 things like pause and break, which can't be represented in RFC 3966. I hope we don't have to re-visit this whole discussion from about =20 three years ago. Henning (author of RFC 3966) On Mar 8, 2006, at 10:27 PM, Paul Kyzivat wrote: > > > Yu, James wrote: >> I'd like to discuss the scenario involving IP Multimedia Subsystem >> (IMS). >> When an IMS user originates a call to an international number (e.g., >> +1-703-622-1234), the IMS application/device uses a tel URI >> (tel:+1-703-622-1234) in the R-URI of the SIP INVITE. >> If the user dials a local/national number with or without the local >> dialing plan, > > I don't know how to parse the above. AFAIK it is normally =20 > impossible to "dial" a dialing plan. Presumably the dialing plan =20 > must be implicit. Thew question is only what entity is responsible =20 > for making the dial plan explicit by including it in the uri. As =20 > long as the URI formats require that local numbers and dialstrings =20 > contain a context, it is necessary for the UA to insert the =20 > context. IMO that is just fine - the UA *ought* to know the context. > >> what would the IMS application/device put in the R-URI? > > The obvious thing is to put the e.164 number corresponding to the =20 > dial string. If you know the context it is no big deal to turn the =20 > number into an e.164 number too. > > The time I have found when that isn't the solution is when the dial =20 > string conveys extra information that needs to be processed in the =20 > network - such as a star-code, or a leading zero to request =20 > operator services. While there are many ways to handle those =20 > things, passing the dialstring seems to be a useful way. > >> I'd guess that it would be a tel URI but with the "dial-string" >> indication. > > Well, you are the author of the tel uri, so I'm not going to try to =20 > tell you anything about it. I didn't know it had a way to carry a =20 > dial string, or a dial-string-indicator. > > One of the reasons that user=3Ddialstring was proposed (quite some =20 > time ago) was because tel couldn't do it. > >> So I think that we need to indicate "dial-string" in the >> tel URI. If that is the case, we probably don't need anything in the >> sip URI. "user=3Dphone" in the sip URI would indicate that the user = >> part >> contains the tel URI information that may include the "dial-string" >> indication. > > If that existed, it would be fine with me. But we have been going =20 > down this other path for some time. > >> Roaming mobile users' outbound calls are handled by the visited =20 >> networks >> and they can easily determine if the callers/roamers dial local/=20 >> national >> numbers with or without dialing prefixes. IMS creates a challenge >> because the outbound calls are analyzed and handled by the =20 >> roamers' home >> IMS providers. So even if the dialed string can be passed in a =20 >> tel URI >> to the home IMS provider, the home IMS provider would need to =20 >> understand >> the dialing prefixes of the countries where the IMS users are =20 >> currently >> roaming to convert the dialed string to a global/local phone number. > > You think it is desirable that a roaming user dial using the =20 > dialling conventions of the location he has roamed to, rather than =20 > his home location? (I consider that to be grossly user-unfriendly.) > > Paul > >> But this is an issue for the IMS to solve. >> James _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 09 04:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHHQE-00042b-Vh; Thu, 09 Mar 2006 04:27:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHHQD-0003wZ-I4 for iptel@ietf.org; Thu, 09 Mar 2006 04:27:01 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHHQC-0002ac-Ps for iptel@ietf.org; Thu, 09 Mar 2006 04:27:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Thu, 9 Mar 2006 10:30:52 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E24@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Thread-Index: AcZDK2wx3jIalHPaQ3CW4O1UMqQvcQAAmP4wAAqwLhA= From: "Stastny Richard" To: "Yu, James" , "Henning Schulzrinne" , "Paul Kyzivat" X-Spam-Score: 0.5 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org As Henning said, the tel URI defined in RFC 3966 does not allow dialstrings Period I fully agree with Henning NOT to re-open this discussion (I still can remember ;-) OTOH, as long as (stupid) terminals are out there capable of only entering digits and forwarding these digits to the next hop, we need the possibility to enter dialstrings We also cannot assume that particularly the stupid terminals in question will be able to translate dialstrings to Tel URIs. Most terminals are even so stupid that they are not able to provide a tel URI, they normally provide: sip:1234@homeproxy.example.com;user=3Dphone (not even the user=3Dphone is provided in some cases) This was the reason why I proposed to include the dialstring (as done anyway in the most cases) in the sip URI, but to clarify the issue in the following way: -if user=3Dphone is used as SIP parm, the digits are a tel URI as defined in RFC 3966 -if user=3Ddialstring is used, it is a dialstring (with all funny characters allowed) as defined in draft-rosen-iptel-dialstring. Now to the phone-context (or dialplan-context?) Since the dialplan used may be an agreement between home network and the terminal (user profile), it is always required (the homeproxy.com in the sip URI alone is not sufficient, we need this in addition. I am also considering here the problem from ECRIT with visited and home emergency numbers. The context could be used to provide information if home or visited country emergency numbers are dialled. This is also necessary for IMS: In IMS the P-CSCF is NEVER analyzing the request URI,=20 it is always the home S-CSCF. Question: how does the home S-CSCF of the caller learn the local emergency numbers? regards Richard > -----Original Message----- > From: Yu, James [mailto:james.yu@neustar.biz] > Sent: Thursday, March 09, 2006 5:25 AM > To: Henning Schulzrinne; Paul Kyzivat > Cc: iptel@ietf.org; Stastny Richard > Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > add-on >=20 > I sent a response to Paul before seeing this message. I did not know > about the past discussions on this. >=20 > IMS is complicate because it may involve "roaming" (not "fixed") and > require the home IMS provider to process the dialed digits/number. I > do see a need to pass the dialed string (any number that does not have a > leading "+") to the home IMS provider because it may not be > feasible/desirable for the IMS application/handset to convert the dialed > string to a phone number. It is fine with me if tel URI is not a good > place to carry it. >=20 > If the IMS application/handset needs to use sip URI to pass the dialed > string to the home IMS provider, it needs to put the home S-CSCF's > domain name or a generic IMS provider domain name in the host part of > the sip URI. This puts a requirement on the home S-CSCF to verify if > the sip URI carries a "dialstring" indication so that it will convert > the dialed string to a phone number and then terminate the call versus > in the case when the caller tries to set up a call to a sip URI > belonging to another IMS user served by the same IMS provider. >=20 > James > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, March 08, 2006 10:42 PM > To: Paul Kyzivat > Cc: Yu, James; iptel@ietf.org; Stastny Richard > Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > add-on >=20 > Jumping in probably without having digested the whole message trail: >=20 > RFC 3966 (tel) is specifically *not* suited for dial strings; this > was discussed repeatedly during the development of the draft. It > says, for example, that dial strings are not directly represented > (page 13). Or >=20 > A SIP UA can use a dial plan to translate dial strings into SIP or > "tel" URIs. The dial plan can be manually configured or, > preferably, > downloaded as part of a device configuration mechanism. (At this > time, there is no standardized mechanism for this.) >=20 >=20 > The phone-context parameter was meant to represent local numbers that > don't have a real E.164 identifier representation, but they are not > dial strings. RFC 3966 also puts a SHOULD NOT warning on the use of > local numbers. The RFC also points out other differences, such as the > inclusion of post-dial digits for controlling IVRs, which would be > wholly inappropriate in an identifier, i.e., a tel URI. >=20 > Needless to say, the dial strings in the draft-rosen draft also have > things like pause and break, which can't be represented in RFC 3966. >=20 > I hope we don't have to re-visit this whole discussion from about > three years ago. >=20 > Henning > (author of RFC 3966) >=20 >=20 >=20 > On Mar 8, 2006, at 10:27 PM, Paul Kyzivat wrote: >=20 > > > > > > Yu, James wrote: > >> I'd like to discuss the scenario involving IP Multimedia Subsystem > >> (IMS). > >> When an IMS user originates a call to an international number (e.g., > >> +1-703-622-1234), the IMS application/device uses a tel URI > >> (tel:+1-703-622-1234) in the R-URI of the SIP INVITE. > >> If the user dials a local/national number with or without the local > >> dialing plan, > > > > I don't know how to parse the above. AFAIK it is normally > > impossible to "dial" a dialing plan. Presumably the dialing plan > > must be implicit. Thew question is only what entity is responsible > > for making the dial plan explicit by including it in the uri. As > > long as the URI formats require that local numbers and dialstrings > > contain a context, it is necessary for the UA to insert the > > context. IMO that is just fine - the UA *ought* to know the context. > > > >> what would the IMS application/device put in the R-URI? > > > > The obvious thing is to put the e.164 number corresponding to the > > dial string. If you know the context it is no big deal to turn the > > number into an e.164 number too. > > > > The time I have found when that isn't the solution is when the dial > > string conveys extra information that needs to be processed in the > > network - such as a star-code, or a leading zero to request > > operator services. While there are many ways to handle those > > things, passing the dialstring seems to be a useful way. > > > >> I'd guess that it would be a tel URI but with the "dial-string" > >> indication. > > > > Well, you are the author of the tel uri, so I'm not going to try to > > tell you anything about it. I didn't know it had a way to carry a > > dial string, or a dial-string-indicator. > > > > One of the reasons that user=3Ddialstring was proposed (quite some > > time ago) was because tel couldn't do it. > > > >> So I think that we need to indicate "dial-string" in the > >> tel URI. If that is the case, we probably don't need anything in the > >> sip URI. "user=3Dphone" in the sip URI would indicate that the = user > >> part > >> contains the tel URI information that may include the "dial-string" > >> indication. > > > > If that existed, it would be fine with me. But we have been going > > down this other path for some time. > > > >> Roaming mobile users' outbound calls are handled by the visited > >> networks > >> and they can easily determine if the callers/roamers dial local/ > >> national > >> numbers with or without dialing prefixes. IMS creates a challenge > >> because the outbound calls are analyzed and handled by the > >> roamers' home > >> IMS providers. So even if the dialed string can be passed in a > >> tel URI > >> to the home IMS provider, the home IMS provider would need to > >> understand > >> the dialing prefixes of the countries where the IMS users are > >> currently > >> roaming to convert the dialed string to a global/local phone number. > > > > You think it is desirable that a roaming user dial using the > > dialling conventions of the location he has roamed to, rather than > > his home location? (I consider that to be grossly user-unfriendly.) > > > > Paul > > > >> But this is an issue for the IMS to solve. > >> James _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 09 10:12:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMo5-0000Xj-Ry; Thu, 09 Mar 2006 10:12:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHMo4-0000Xe-LG for iptel@ietf.org; Thu, 09 Mar 2006 10:12:00 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHMo3-0005Al-Ej for iptel@ietf.org; Thu, 09 Mar 2006 10:12:00 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k29FBsR0003866; Thu, 9 Mar 2006 10:11:59 -0500 (EST) From: "Brett Tate" To: "'Stastny Richard'" Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt add-on Date: Thu, 9 Mar 2006 10:12:59 -0500 Message-ID: <001501c6438b$f413c7d0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <32755D354E6B65498C3BD9FD496C7D463C4E24@oefeg-s04.oefeg.loc> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org > Most terminals are even so stupid that they are > not able to provide a tel URI, they normally > provide: sip:1234@homeproxy.example.com;user=3Dphone Unfortunately or fortunately depending on ones opinion, the above is = valid per rfc2806 and not valid per rfc3966. Because "1234" is not "global", = a phone-context is now required per rfc3966. This rfc3966 requirement was one of the reasons leading to the need for = the iptel-dialstring document. > (not even the user=3Dphone is provided in some cases) Per rfc3966, it is now considered invalid if user=3Dphone is provided = for your example (see above). And as more devices start enforcing this rfc3966 requirement, it breaks interoperability with devices which implemented rfc2806 and have not implemented (or been upgraded to) the rfc3966 requirement. And I agree with others that it isn't worth re-debating the rfc3966 phone-context requirement; everyone just gets to enjoy the results of = the decision. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 09 11:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNr2-0001XR-6K; Thu, 09 Mar 2006 11:19:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHNr0-0001S5-I6 for iptel@ietf.org; Thu, 09 Mar 2006 11:19:06 -0500 Received: from bdsoft10.vwh.net ([130.94.149.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHNqz-0007Ed-Bw for iptel@ietf.org; Thu, 09 Mar 2006 11:19:06 -0500 Received: from brett1 (corp.broadsoft.com [67.88.7.2]) (authenticated bits=0) by bdsoft10.vwh.net (8.13.1/8.12.11) with ESMTP id k29GJ1uK009950 for ; Thu, 9 Mar 2006 11:19:04 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Thu, 9 Mar 2006 11:20:05 -0500 Message-ID: <001801c64395$53ce87b0$2c28a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <440F4CA2.3020901@cisco.com> Importance: Normal X-PMX-IsInternal: True X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org > > What about leaving phone-context with RFC 3966? > >=20 > > sip:123;phone-context=3Datlanta.example.com@sippbx.example.com;user=3Ddia= lstring > > > > That is what I proposed. Brian didn't like it. I'm actually surprised that the draft didn't completely follow rfc3966 = and relax the phone-context rule. Or totally disregard rfc3966 (including = the phone-context type requirements) and allow the receiver to determine the context. If I understand correctly, the draft currently disregards rfc3966 but = still requires a context to be sent. =20 I agree that indicating context can be helpful; but why put the same = rfc3966 phone-context requirement on the dialstring draft? =20 Relaxing the rule is helpful for interactions between device and = outbound proxy so they don't have to uselessly configure and pass such a context = when not needed. If the group thinks a context is really needed for dialstring, would something like "phone-context=3Doutbound.invalid." or "phone-context=3Dunknown.invalid." be acceptable as a default context? = Thus outbound devices which allow it can use it; and others can handle it as = they would when the phone-context is unknown. I would suggest such a default context for rfc3966 usage (within "tel:" = and when user=3Dphone); however I'm sure some would consider it a violation = of the rfc3966 phone-context rule. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 09 11:46:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOHg-00089o-EE; Thu, 09 Mar 2006 11:46:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHOHe-00089j-TE for iptel@ietf.org; Thu, 09 Mar 2006 11:46:38 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHOHe-000868-Jd for iptel@ietf.org; Thu, 09 Mar 2006 11:46:38 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Mar 2006 11:46:38 -0500 X-IronPort-AV: i="4.02,179,1139202000"; d="scan'208"; a="83809694:sNHT31041704" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k29GkYVW017094; Thu, 9 Mar 2006 11:46:38 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 11:46:34 -0500 Received: from [161.44.79.183] ([161.44.79.183]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 11:46:33 -0500 Message-ID: <44105BE9.9040008@cisco.com> Date: Thu, 09 Mar 2006 11:46:33 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brett Tate Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt References: <001801c64395$53ce87b0$2c28a8c0@brett1> In-Reply-To: <001801c64395$53ce87b0$2c28a8c0@brett1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2006 16:46:33.0938 (UTC) FILETIME=[062E1B20:01C64399] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Brett, The problem with omitting the context from the URI is that it makes the URI itself dependent on the context in which it is used. That means it must be detected and translated into some context independent form while the original context is still known. Of course it is tempting to say "oh the edge proxy will fix everything up". But its pretty easy for something to slip past. It isn't just the R-URI that might need translating. Some examples where that is not the case: - the Refer-To uri in a REFER message - perhaps the address of a colleague referenced in a presence document - an XCAP message containing forwarding address URL. So if a URI that depends on implicit context slips by the element that understands that context, and gets used in some other context, then at best it will fail, and at worst it will succeed by assuming the wrong context and reach the wrong party. If the context is explicit in the URI, at worst it may fail if handed to someone that doesn't understand the context. At best it will be routed to an element that does understand the context and can do the needed translation. Paul Brett Tate wrote: >>>What about leaving phone-context with RFC 3966? >>> >>> > > sip:123;phone-context=atlanta.example.com@sippbx.example.com;user=dialstring > >>That is what I proposed. Brian didn't like it. > > > I'm actually surprised that the draft didn't completely follow rfc3966 and > relax the phone-context rule. Or totally disregard rfc3966 (including the > phone-context type requirements) and allow the receiver to determine the > context. > > If I understand correctly, the draft currently disregards rfc3966 but still > requires a context to be sent. > > I agree that indicating context can be helpful; but why put the same rfc3966 > phone-context requirement on the dialstring draft? > > Relaxing the rule is helpful for interactions between device and outbound > proxy so they don't have to uselessly configure and pass such a context when > not needed. > > If the group thinks a context is really needed for dialstring, would > something like "phone-context=outbound.invalid." or > "phone-context=unknown.invalid." be acceptable as a default context? Thus > outbound devices which allow it can use it; and others can handle it as they > would when the phone-context is unknown. > > I would suggest such a default context for rfc3966 usage (within "tel:" and > when user=phone); however I'm sure some would consider it a violation of the > rfc3966 phone-context rule. > > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Mon Mar 20 05:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHxc-00026U-Ie; Mon, 20 Mar 2006 05:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLHxb-00026K-R6 for iptel@ietf.org; Mon, 20 Mar 2006 05:50:03 -0500 Received: from smtp11.clb.oleane.net ([213.56.31.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLHxb-00052X-1f for iptel@ietf.org; Mon, 20 Mar 2006 05:50:03 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp11.clb.oleane.net with ESMTP id k2KAngp7019799 for ; Mon, 20 Mar 2006 11:49:57 +0100 Message-Id: <200603201049.k2KAngp7019799@smtp11.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 20 Mar 2006 11:49:09 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZMC+p/Ghib1FZoTFONmmJu+ZoYCg== X-Spam-Score: 0.3 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Subject: [Iptel] Wireless WiFi Convergence 2006 Conference & Exhibition - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0584737612==" Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============0584737612== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C64C14.4EAB1690" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C64C14.4EAB1690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 1st Edition of the Wireless WiFi Convergence 2006 Conference & Exhibition will stand in Paris next May 16 - 19, 2006 Only 2 weeks left to take advantage of our Early Bird Offer! Register before the 31st of March 2006 and benefit from a 10% discount on the registration fees. To register, please go to: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006registratio n.htm ------=_NextPart_000_0015_01C64C14.4EAB1690 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 1st = Edition of the Wireless WiFi Convergence 2006 Conference & = Exhibition

=

will stand in Paris next May 16 - 19, 2006

=

 

=

Only 2 weeks left to take advantage of our = Early Bird Offer! =

Register before the 31st of March = 2006 and benefit from a 10% discount on the registration fees. 

 

To register, please go = to:

http://www.upperside.fr/wirelessconvergence2006/wwconv= ergence2006registration.htm

 

------=_NextPart_000_0015_01C64C14.4EAB1690-- --===============0584737612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============0584737612==-- From iptel-bounces@ietf.org Tue Mar 21 16:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLo40-0006q2-7D; Tue, 21 Mar 2006 16:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLo3z-0006nX-FB for iptel@ietf.org; Tue, 21 Mar 2006 16:06:47 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLo3v-0002c6-50 for iptel@ietf.org; Tue, 21 Mar 2006 16:06:47 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2LL6ej15471 for ; Tue, 21 Mar 2006 16:06:40 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Tue, 21 Mar 2006 15:06:33 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF07E25FFD@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Thread-Index: AcZDmSGCAV1fOK5YTH2FnD8lmV63ZgJkXzKQ From: "Francois Audet" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org I guess I'll be the dissenter here... I really do not see why we need this draft. I think it will do much more harm than good. It will dissuade people from implementing "real" tel uris. I have not seen any convincing evidence that using "pauses" in dialling is something=20 SIP should do. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 21 16:59:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLose-00081A-Rd; Tue, 21 Mar 2006 16:59:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLosd-0007yX-ON for iptel@ietf.org; Tue, 21 Mar 2006 16:59:07 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLosc-0005PZ-Gd for iptel@ietf.org; Tue, 21 Mar 2006 16:59:07 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FLosT-0000wK-OF; Tue, 21 Mar 2006 15:58:58 -0600 From: "Brian Rosen" To: "'Francois Audet'" , Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Tue, 21 Mar 2006 16:59:04 -0500 Message-ID: <015a01c64d32$ad4ff5c0$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZDmSGCAV1fOK5YTH2FnD8lmV63ZgJkXzKQAAHSETA= In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07E25FFD@zrc2hxm0.corp.nortel.com> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org It deals with reality. Phones don't (always) do dial plan interpretation. We have no way to know if it's been done. The problem isn't a tel uri, the problem is sip:nnn@domain;user=phone. It's NOT a phone number, it's a dial string. The only way to implement real tel uri's is to force all phones to do all dial plan interpretation. That just isn't going to happen in my lifetime I think. I don't care about the pauses; I could lose them. They are also reality, however. It's what the phone has in a speed dial to get to, for example, an existing voicemail system. You can say forklift upgrade to a SIP based VM, but that's not reality. Brian -----Original Message----- From: Francois Audet [mailto:audet@nortel.com] Sent: Tuesday, March 21, 2006 4:07 PM To: iptel@ietf.org Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt I guess I'll be the dissenter here... I really do not see why we need this draft. I think it will do much more harm than good. It will dissuade people from implementing "real" tel uris. I have not seen any convincing evidence that using "pauses" in dialling is something SIP should do. _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 21 17:54:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpjr-0003nJ-J7; Tue, 21 Mar 2006 17:54:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpjp-0003en-UK for iptel@ietf.org; Tue, 21 Mar 2006 17:54:05 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpjp-0008B3-K2 for iptel@ietf.org; Tue, 21 Mar 2006 17:54:05 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2006 14:53:20 -0800 X-IronPort-AV: i="4.03,116,1141632000"; d="scan'208"; a="1787023327:sNHT8272813816" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2LMrJw1008858; Tue, 21 Mar 2006 14:53:19 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 14:53:18 -0800 Received: from [10.89.20.37] ([10.89.20.37]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Mar 2006 14:53:15 -0800 Message-ID: <442083DB.9090202@cisco.com> Date: Tue, 21 Mar 2006 17:53:15 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt References: <015a01c64d32$ad4ff5c0$73818182@cis.neustar.com> In-Reply-To: <015a01c64d32$ad4ff5c0$73818182@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2006 22:53:16.0584 (UTC) FILETIME=[3DBC7280:01C64D3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: iptel@ietf.org, 'Francois Audet' X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Brian Rosen wrote: > It deals with reality. Phones don't (always) do dial plan interpretation. > We have no way to know if it's been done. The problem isn't a tel uri, the > problem is sip:nnn@domain;user=phone. It's NOT a phone number, it's a dial > string. I think Brian and I agree on the issues here, but I want to pick on the description. In the case of both a tel uri or sip:nnn@domain;user=phone, it is *supposed* to be a phone number. Neither of these is supposed to contain a dial string. The problem is that both of these are known to be used, improperly, to contain dial strings. > The only way to implement real tel uri's is to force all phones to > do all dial plan interpretation. That just isn't going to happen in my > lifetime I think. Well, its hard for me to guess on your health issues, but I think there is a pretty good chance that all voip phones will do this in *my* lifetime. I do agree that they don't all do it today, and we probably need to accomodate that. In my experience a more severe problem is cases when the dialstring contains both the target address *and* some special function (e.g. star code) that needs to be taken into account along with the target address. While there are many ways to deal with this if you have good dial plan processing in the phone, it still seems that there is often a desire to leave both of these things encoded in the URI. This requires a way to represent dial strings. Paul > I don't care about the pauses; I could lose them. They are also reality, > however. It's what the phone has in a speed dial to get to, for example, an > existing voicemail system. You can say forklift upgrade to a SIP based VM, > but that's not reality. > > Brian > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, March 21, 2006 4:07 PM > To: iptel@ietf.org > Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt > > I guess I'll be the dissenter here... > > I really do not see why we need this draft. I think it will do much more > harm than good. > > It will dissuade people from implementing "real" tel uris. > > I have not seen any convincing evidence that using "pauses" in dialling > is something > SIP should do. > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Tue Mar 21 18:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqZN-0004oN-LC; Tue, 21 Mar 2006 18:47:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqZM-0004oI-Fx for iptel@ietf.org; Tue, 21 Mar 2006 18:47:20 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLqZK-0001iq-VR for iptel@ietf.org; Tue, 21 Mar 2006 18:47:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Wed, 22 Mar 2006 00:51:18 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C490C@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Thread-Index: AcZNOu91x77XS94RRqWTS2D8BnvIBgABl5ot From: "Stastny Richard" To: "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: iptel@ietf.org, Francois Audet X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org >While there are many ways to deal with this if you have good dial plan >processing in the phone, it still seems that there is often a desire to >leave both of these things encoded in the URI. This requires a way to >represent dial strings. I doubt that there will be ever a good dial plan processing in a phone and it is also not necessary, if you have a defined destinction if a=20 string of numbers is a phone number or a dialstring So I fully agree that there is required a way to reresent dial-strings and also a way to distingush if a sip:nnn@domain is a phone numer i.e an imbedded tel:URI or a dialstring. sip:nnn@domain;user=3Dphone sip:nnn@domain;user=3Ddialstring Richard ________________________________ Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] Gesendet: Di 21.03.2006 23:53 An: br@brianrosen.net Cc: iptel@ietf.org; 'Francois Audet' Betreff: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Brian Rosen wrote: > It deals with reality. Phones don't (always) do dial plan = interpretation. > We have no way to know if it's been done. The problem isn't a tel = uri, the > problem is sip:nnn@domain;user=3Dphone. It's NOT a phone number, it's = a dial > string. I think Brian and I agree on the issues here, but I want to pick on the description. In the case of both a tel uri or = sip:nnn@domain;user=3Dphone, it is *supposed* to be a phone number. Neither of these is supposed to contain a dial string. The problem is that both of these are known to be used, improperly, to contain dial strings. > The only way to implement real tel uri's is to force all phones to > do all dial plan interpretation. That just isn't going to happen in = my > lifetime I think. Well, its hard for me to guess on your health issues, but I think there is a pretty good chance that all voip phones will do this in *my* lifetime. I do agree that they don't all do it today, and we probably need to accomodate that. In my experience a more severe problem is cases when the dialstring contains both the target address *and* some special function (e.g. star code) that needs to be taken into account along with the target address. While there are many ways to deal with this if you have good dial plan processing in the phone, it still seems that there is often a desire to leave both of these things encoded in the URI. This requires a way to represent dial strings. Paul > I don't care about the pauses; I could lose them. They are also = reality, > however. It's what the phone has in a speed dial to get to, for = example, an > existing voicemail system. You can say forklift upgrade to a SIP = based VM, > but that's not reality. > > Brian > > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, March 21, 2006 4:07 PM > To: iptel@ietf.org > Subject: RE: [Iptel] Re: I-D = ACTION:draft-rosen-iptel-dialstring-03.txt > > I guess I'll be the dissenter here... > > I really do not see why we need this draft. I think it will do much = more > harm than good. > > It will dissuade people from implementing "real" tel uris. > > I have not seen any convincing evidence that using "pauses" in = dialling > is something > SIP should do. > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > > > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 22 15:43:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAAl-0005ud-Bq; Wed, 22 Mar 2006 15:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAAj-0005tv-C0 for iptel@ietf.org; Wed, 22 Mar 2006 15:43:13 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAAh-0001CF-Vq for iptel@ietf.org; Wed, 22 Mar 2006 15:43:13 -0500 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2MKS3X19558; Wed, 22 Mar 2006 15:28:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Date: Wed, 22 Mar 2006 14:28:01 -0600 Message-ID: <1ECE0EB50388174790F9694F77522CCF07EF8EB1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt Thread-Index: AcZNOu91x77XS94RRqWTS2D8BnvIBgABl5otACstydA= From: "Francois Audet" To: "Stastny Richard" , "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: iptel@ietf.org X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org You can use: sip:DIALDIGITS;phone-context=3DdialledDigits.example.com@example.com;user= =3D phone There is absolutely no difference between user=3Dphone and = user=3Ddialdigits if since they both need a phone-context that makes the user part globally unique. When we went through this a wile ago, the rationale that was given for the "dial digits" was the pauses. Adding a new way to do exactly the same thing just means more interop problems. This is further complicated by the fact we tabled this for 2 years. I'd favor instead that we describe (in that draft) how to use = user=3Dphone with a=20 phone-context that essentially means "the network dialling plan in location x"=20 or whatever, without defining a new URI parameter. And drop the "pauses". > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Tuesday, March 21, 2006 15:51 > To: Paul Kyzivat; br@brianrosen.net > Cc: iptel@ietf.org; Audet, Francois [SC100:3055:EXCH] > Subject: Re: [Iptel] Re: I-D=20 > ACTION:draft-rosen-iptel-dialstring-03.txt >=20 >=20 > >While there are many ways to deal with this if you have good=20 > dial plan=20 > >processing in the phone, it still seems that there is often=20 > a desire to=20 > >leave both of these things encoded in the URI. This requires=20 > a way to=20 > >represent dial strings. >=20 > I doubt that there will be ever a good dial plan processing=20 > in a phone and it is also not necessary, if you have a=20 > defined destinction if a=20 > string of numbers is a phone number or a dialstring >=20 > So I fully agree that there is required a way to reresent=20 > dial-strings and also a way to distingush if a sip:nnn@domain=20 > is a phone numer i.e an imbedded tel:URI or a dialstring. >=20 > sip:nnn@domain;user=3Dphone > sip:nnn@domain;user=3Ddialstring >=20 > Richard >=20 >=20 > ________________________________ >=20 > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Gesendet: Di 21.03.2006 23:53 > An: br@brianrosen.net > Cc: iptel@ietf.org; 'Francois Audet' > Betreff: Re: [Iptel] Re: I-D=20 > ACTION:draft-rosen-iptel-dialstring-03.txt >=20 >=20 >=20 >=20 >=20 > Brian Rosen wrote: > > It deals with reality. Phones don't (always) do dial plan=20 > > interpretation. We have no way to know if it's been done. =20 > The problem=20 > > isn't a tel uri, the problem is sip:nnn@domain;user=3Dphone. =20 > It's NOT a=20 > > phone number, it's a dial string. >=20 > I think Brian and I agree on the issues here, but I want to=20 > pick on the description. In the case of both a tel uri or=20 > sip:nnn@domain;user=3Dphone, it is *supposed* to be a phone=20 > number. Neither of these is supposed to contain a dial=20 > string. The problem is that both of these are known to be=20 > used, improperly, to contain dial strings. >=20 > > The only way to implement real tel uri's is to force all=20 > phones to do=20 > > all dial plan interpretation. That just isn't going to=20 > happen in my=20 > > lifetime I think. >=20 > Well, its hard for me to guess on your health issues, but I=20 > think there is a pretty good chance that all voip phones will=20 > do this in *my* lifetime. I do agree that they don't all do=20 > it today, and we probably need to accomodate that. >=20 > In my experience a more severe problem is cases when the=20 > dialstring contains both the target address *and* some=20 > special function (e.g. star > code) that needs to be taken into account along with the=20 > target address. While there are many ways to deal with this=20 > if you have good dial plan processing in the phone, it still=20 > seems that there is often a desire to leave both of these=20 > things encoded in the URI. This requires a way to represent=20 > dial strings. >=20 > Paul >=20 > > I don't care about the pauses; I could lose them. They are also=20 > > reality, however. It's what the phone has in a speed dial=20 > to get to,=20 > > for example, an existing voicemail system. You can say forklift=20 > > upgrade to a SIP based VM, but that's not reality. > > > > Brian > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, March 21, 2006 4:07 PM > > To: iptel@ietf.org > > Subject: RE: [Iptel] Re: I-D=20 > > ACTION:draft-rosen-iptel-dialstring-03.txt > > > > I guess I'll be the dissenter here... > > > > I really do not see why we need this draft. I think it will do much=20 > > more harm than good. > > > > It will dissuade people from implementing "real" tel uris. > > > > I have not seen any convincing evidence that using "pauses" in=20 > > dialling is something SIP should do. > > > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www1.ietf.org/mailman/listinfo/iptel > > > > > > _______________________________________________ > > Iptel mailing list > > Iptel@ietf.org > > https://www1.ietf.org/mailman/listinfo/iptel > > >=20 > _______________________________________________ > Iptel mailing list > Iptel@ietf.org > https://www1.ietf.org/mailman/listinfo/iptel >=20 >=20 >=20 >=20 _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 22 16:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAVc-0000Ud-AH; Wed, 22 Mar 2006 16:04:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAVb-0000UT-1I for iptel@ietf.org; Wed, 22 Mar 2006 16:04:47 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAVZ-0002eZ-Ec for iptel@ietf.org; Wed, 22 Mar 2006 16:04:47 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2006 13:04:45 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="317034231:sNHT35133284" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2ML4i7V003370; Wed, 22 Mar 2006 13:04:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 13:04:44 -0800 Received: from [10.89.20.101] ([10.89.20.101]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 13:04:43 -0800 Message-ID: <4421BBEA.1070102@cisco.com> Date: Wed, 22 Mar 2006 16:04:42 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Iptel] Re: I-D ACTION:draft-rosen-iptel-dialstring-03.txt References: <1ECE0EB50388174790F9694F77522CCF07EF8EB1@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF07EF8EB1@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Mar 2006 21:04:43.0838 (UTC) FILETIME=[3E4005E0:01C64DF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: iptel@ietf.org, Stastny Richard X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org Francois Audet wrote: > You can use: > > sip:DIALDIGITS;phone-context=dialledDigits.example.com@example.com;user= > phone > > There is absolutely no difference between user=phone and user=dialdigits > if > since they both need a phone-context that makes the user part globally > unique. > > When we went through this a wile ago, the rationale that was given for > the > "dial digits" was the pauses. I was one of the people that didn't see the need for user=dialstring. I lost that battle. I think another rationale was that the same context can then be used for local numbers and dialstrings. (If you think that is important.) It doesn't matter much, which is why I didn't lose much sleep over this. In the end, either way provides a mechanism for conveying a dial string in a URI and being able to distinguish it from a phone number. > Adding a new way to do exactly the same thing just means more interop > problems. > This is further complicated by the fact we tabled this for 2 years. > > I'd favor instead that we describe (in that draft) how to use user=phone > with a > phone-context that essentially means "the network dialling plan in > location x" > or whatever, without defining a new URI parameter. And drop the > "pauses". I thought it was decided, not tabled. While I started out on the other side, and would have been happy to have it end up that way, at this point it just want to move on rather than reopen the debate. Paul >>-----Original Message----- >>From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >>Sent: Tuesday, March 21, 2006 15:51 >>To: Paul Kyzivat; br@brianrosen.net >>Cc: iptel@ietf.org; Audet, Francois [SC100:3055:EXCH] >>Subject: Re: [Iptel] Re: I-D >>ACTION:draft-rosen-iptel-dialstring-03.txt >> >> >> >>>While there are many ways to deal with this if you have good >> >>dial plan >> >>>processing in the phone, it still seems that there is often >> >>a desire to >> >>>leave both of these things encoded in the URI. This requires >> >>a way to >> >>>represent dial strings. >> >>I doubt that there will be ever a good dial plan processing >>in a phone and it is also not necessary, if you have a >>defined destinction if a >>string of numbers is a phone number or a dialstring >> >>So I fully agree that there is required a way to reresent >>dial-strings and also a way to distingush if a sip:nnn@domain >>is a phone numer i.e an imbedded tel:URI or a dialstring. >> >>sip:nnn@domain;user=phone >>sip:nnn@domain;user=dialstring >> >>Richard >> >> >>________________________________ >> >>Von: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Gesendet: Di 21.03.2006 23:53 >>An: br@brianrosen.net >>Cc: iptel@ietf.org; 'Francois Audet' >>Betreff: Re: [Iptel] Re: I-D >>ACTION:draft-rosen-iptel-dialstring-03.txt >> >> >> >> >> >>Brian Rosen wrote: >> >>>It deals with reality. Phones don't (always) do dial plan >>>interpretation. We have no way to know if it's been done. >> >>The problem >> >>>isn't a tel uri, the problem is sip:nnn@domain;user=phone. >> >>It's NOT a >> >>>phone number, it's a dial string. >> >>I think Brian and I agree on the issues here, but I want to >>pick on the description. In the case of both a tel uri or >>sip:nnn@domain;user=phone, it is *supposed* to be a phone >>number. Neither of these is supposed to contain a dial >>string. The problem is that both of these are known to be >>used, improperly, to contain dial strings. >> >> >>>The only way to implement real tel uri's is to force all >> >>phones to do >> >>>all dial plan interpretation. That just isn't going to >> >>happen in my >> >>>lifetime I think. >> >>Well, its hard for me to guess on your health issues, but I >>think there is a pretty good chance that all voip phones will >>do this in *my* lifetime. I do agree that they don't all do >>it today, and we probably need to accomodate that. >> >>In my experience a more severe problem is cases when the >>dialstring contains both the target address *and* some >>special function (e.g. star >>code) that needs to be taken into account along with the >>target address. While there are many ways to deal with this >>if you have good dial plan processing in the phone, it still >>seems that there is often a desire to leave both of these >>things encoded in the URI. This requires a way to represent >>dial strings. >> >> Paul >> >> >>>I don't care about the pauses; I could lose them. They are also >>>reality, however. It's what the phone has in a speed dial >> >>to get to, >> >>>for example, an existing voicemail system. You can say forklift >>>upgrade to a SIP based VM, but that's not reality. >>> >>>Brian >>> >>>-----Original Message----- >>>From: Francois Audet [mailto:audet@nortel.com] >>>Sent: Tuesday, March 21, 2006 4:07 PM >>>To: iptel@ietf.org >>>Subject: RE: [Iptel] Re: I-D >>>ACTION:draft-rosen-iptel-dialstring-03.txt >>> >>>I guess I'll be the dissenter here... >>> >>>I really do not see why we need this draft. I think it will do much >>>more harm than good. >>> >>>It will dissuade people from implementing "real" tel uris. >>> >>>I have not seen any convincing evidence that using "pauses" in >>>dialling is something SIP should do. >>> >>>_______________________________________________ >>>Iptel mailing list >>>Iptel@ietf.org >>>https://www1.ietf.org/mailman/listinfo/iptel >>> >>> >>>_______________________________________________ >>>Iptel mailing list >>>Iptel@ietf.org >>>https://www1.ietf.org/mailman/listinfo/iptel >>> >> >>_______________________________________________ >>Iptel mailing list >>Iptel@ietf.org >>https://www1.ietf.org/mailman/listinfo/iptel >> >> >> >> > > _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Wed Mar 29 18:12:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjqC-0003wY-Bi; Wed, 29 Mar 2006 18:12:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOjpz-0003a6-NA for iptel@ietf.org; Wed, 29 Mar 2006 18:12:27 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOjpy-0005f3-Fa for iptel@ietf.org; Wed, 29 Mar 2006 18:12:27 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 29 Mar 2006 18:12:27 -0500 X-IronPort-AV: i="4.03,145,1141621200"; d="scan'208"; a="85293063:sNHT29883460" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2TNCQWc004127 for ; Wed, 29 Mar 2006 18:12:26 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 18:12:26 -0500 Received: from [192.168.1.101] ([10.86.240.92]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 18:12:25 -0500 Message-ID: <442B1459.7000506@cisco.com> Date: Wed, 29 Mar 2006 18:12:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: list iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Mar 2006 23:12:25.0820 (UTC) FILETIME=[3E09F1C0:01C65386] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Iptel] Some iptel changes and status update X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iptel-bounces@ietf.org As I think most folks know, Cullen is now our Area Director, and thus is going to be stepping down as WG chair. That leaves just me as the chair, with the aim of finally closing this group (which I've been saying for a while now). Cullen will be the AD overseeing iptel. Here is our status on our various documents: tgrep: We issued a working group last call for tgrep on Feb 15, which ended March 1. To my knowledge there were no comments. As such, I'll now be doing the writeup for this and sending to IESG. tel-np: Token is with the AD; I have just reminded him of such ;) trunk-group: I owe a writeup on this in order to request IESG consideration; working on that now. enumdi: We had some AD feedback which needs to be worked; I'm sorting through that to see what we need to do next tel-uri registry: I have the token to review the latest draft and make sure it addresses the comments made. If so, do a writeup. Let me know if this seems wrong to anyone. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel From iptel-bounces@ietf.org Thu Mar 30 03:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOslu-0002rf-SG; Thu, 30 Mar 2006 03:44:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOslu-0002r4-6y for iptel@ietf.org; Thu, 30 Mar 2006 03:44:50 -0500 Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOsls-0008O8-R1 for iptel@ietf.org; Thu, 30 Mar 2006 03:44:50 -0500 Received: from Pavillonquatre ([194.3.133.88]) by smtp13.clb.oleane.net with ESMTP id k2U8ifr0027563 for ; Thu, 30 Mar 2006 10:44:47 +0200 Message-Id: <200603300844.k2U8ifr0027563@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Thu, 30 Mar 2006 10:43:56 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZT1hSD5oMAkYLXRhiCmIXR2VgxTA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [Iptel] Wireless/WiFi Convergence Conference - 16 to 19 May 2006 - Paris - France X-BeenThere: iptel@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Telephony List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1850834712==" Errors-To: iptel-bounces@ietf.org This is a multi-part message in MIME format. --===============1850834712== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0260_01C653E6.D85D3B50" This is a multi-part message in MIME format. ------=_NextPart_000_0260_01C653E6.D85D3B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Wireless/WiFi Convergence Conference - 16 to 19 May 2006 - Paris - France Last days to benefit from the Early Bird Offer! Register before Monday the 3rd of April and save 10 % on the Registration Fees. For more info and to register, please visit: http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006terms.htm ------=_NextPart_000_0260_01C653E6.D85D3B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wireless/Wi= Fi Convergence Conference - 16 to 19 May 2006 - Paris - France

 =

Last days = to benefit from the Early Bird Offer!

 =

Register before Monday the 3rd of April and save = 10 % on the Registration Fees.

For more info and to register, please = visit:

http://www.upperside.fr/wirelessconvergence2006/wwconvergence= 2006terms.htm

 

------=_NextPart_000_0260_01C653E6.D85D3B50-- --===============1850834712== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Iptel mailing list Iptel@ietf.org https://www1.ietf.org/mailman/listinfo/iptel --===============1850834712==--