From extest-admin@lists.bell-labs.com Wed May 1 05:02:28 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10178 for ; Wed, 1 May 2002 05:02:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4192UN22799 for ; Wed, 1 May 2002 05:02:30 -0400 Date: Wed, 1 May 2002 05:02:30 -0400 Message-Id: <200205010902.g4192UN22799@share.research.bell-labs.com> Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, iptel-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com nexaew http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Thu May 2 02:38:57 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23661 for ; Thu, 2 May 2002 02:38:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g426cFN10417; Thu, 2 May 2002 02:38:15 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g426bnN10404 for ; Thu, 2 May 2002 02:37:49 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g426dVQ3023135 for ; Thu, 2 May 2002 02:39:31 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 8E1CC4439E; Thu, 2 May 2002 02:37:43 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 4E6F84439D for ; Thu, 2 May 2002 02:37:43 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g426bfo72278 for ; Thu, 2 May 2002 02:37:41 -0400 (EDT) Received: from wiprom2mx1.wipro.com ([203.197.164.41]) by dusty; Thu May 2 02:32:57 EDT 2002 Received: from m2vwall2.wipro.com ([164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g426bRZ19479 for ; Thu, 2 May 2002 12:07:27 +0530 (IST) Received: from M1186K110116 ([192.168.40.100]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GVH12901.I3A for ; Thu, 2 May 2002 12:07:21 +0530 From: "Nagarajan.D" To: Message-ID: <000801c1f1a4$48fd60a0$6428a8c0@M1186K110116> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-ccf38ef6-5d8d-11d6-af80-0080c8048dde" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <000201c1ef6d$e4b20430$6428a8c0@M1186K110116> Subject: [IPTEL] Doubt in CPL Scripts Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 2 May 2002 12:10:44 +0530 This is a multi-part message in MIME format. ------=_NextPartTM-000-ccf38ef6-5d8d-11d6-af80-0080c8048dde Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C1F1D2.62B59CA0" ------=_NextPart_000_0009_01C1F1D2.62B59CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am trying to understand the CPL scripts where I have the following doubt: I am having a CPL Server and the SIP Server as two different components. Where all calls from the SIP Server is forwarded to the CPL Server to check for any specific action required and returns an action back to SIP Server to proceed with. Doubt no 1: When there is a call between 2 users A and B. A's script says to start the call logging feature( where the details of the calls of A are logged to a file ) And then B's script says to reject all the calls from A. In such a case; which one of the following will be the return action sent from CPL Server to SIP Server 1. Start call logging feature for call A 2. Reject action ; for calls coming from A to B 3. both 1 and 2. In some situations there will be only one action; and in some more than one action is it right ? Or do we need to have priorities for the actions of A and B and choose one among them. If somebody has done some implementations handling such scenarios can you please guide me. Doubt no 2: And in some cases, the actions could result in recursions, The RFC 2824 in section 9.2 says " in some cases, forwarding can be recursive; a CPL Server must be careful to prevent forwarding loops." If somebody has done some implementations handling such scenarios can you please guide me. Doubt no 3: Sip Server works on specified set of timers, when a call is been sent to the CPL Server for action; may be it has to handle many scripts at a time and respond back. But it may disturb the SIP timers; How are we going to handle such situations. Are there any specific timer implementations for CPL Server required ? Are there are any implementations available to look into these issues. Thanks, Naga ******************************************* *** D. Nagarajan *** *** Wipro Technologies *** *** 271, Sri Ganesh Complex *** *** Madivala, Bangalore 560068, India *** *** Tel : 0091-80-5539134/139 ext 1161 *** ******************************************* *** The woods are lovely, dark and deep. *** *** But I have promises to keep, *** *** And miles to go before I sleep, *** *** And miles to go before I sleep. *** ******************************************* ------=_NextPart_000_0009_01C1F1D2.62B59CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I am trying to understand the CPL scripts where I = have the=20 following doubt:

I am having a CPL Server and the SIP Server as = two=20 different components.
Where all calls from the SIP Server is = forwarded to the=20 CPL Server to check for any specific action required and returns an = action back=20 to SIP Server to proceed with.

Doubt no=20 1:

When there is a call between 2 users A and B.
A's = script=20 says to start the call logging feature( where the details of the calls = of A=20 are logged to a file )
And then B's script says to reject all the = calls=20 from A.

In such a case; which one of the following will be the = return=20 action sent from CPL Server to SIP Server

1. Start call logging = feature=20 for call A
2. Reject action ; for calls coming from A to B
3. = both 1 and=20 2.

In some situations there will be only one action; and in = some more=20 than one action is it right ?
Or do we need to have priorities for = the=20 actions of A and B and choose one among them.
If somebody has done = some=20 implementations handling such scenarios can you please guide = me.

Doubt no 2:

And in some cases, the actions could result in = recursions, The=20 RFC 2824 in section 9.2 says " in some cases, forwarding can be = recursive;=20
a CPL Server must be careful to prevent forwarding loops." =20 If somebody has done some implementations = handling such=20 scenarios can you please guide me.


Doubt no 3:

Sip Server works on specified set of timers, = when a call=20 is been sent to the CPL Server for action; may be it has to handle = many=20 scripts at a time and respond back.
But it may disturb the SIP = timers; How=20 are we going to handle such situations. Are there any specific timer=20 implementations for CPL Server required ?

 
Are there are any implementations available to = look into=20 these issues.
 
Thanks,
Naga
*******************************************
*** D.=20 = Nagarajan          &nbs= p;            = ;            =             &= nbsp;           &n= bsp; =20 ***
*** Wipro=20 = Technologies          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p; =20 ***
*** 271, Sri Ganesh=20 = Complex           =             &= nbsp;           &n= bsp;    =20  ***
*** Madivala, Bangalore 560068,=20 = India           &n= bsp;           =20 ***
*** Tel : 0091-80-5539134/139 ext=20 = 1161           &nb= sp;           &nbs= p;=20 ***
*******************************************
*** The woods = are=20 lovely, dark and=20 = deep.           &n= bsp;     =20 *** 
*** But I have promises to=20 = keep,           &n= bsp;           &nb= sp;        =20  ***
*** And miles to go before I=20 = sleep,           &= nbsp;           &n= bsp;    =20 ***
*** And miles to go before I=20 = sleep.           &= nbsp;           &n= bsp;    =20 ***  
*******************************************=20
------=_NextPart_000_0009_01C1F1D2.62B59CA0-- ------=_NextPartTM-000-ccf38ef6-5d8d-11d6-af80-0080c8048dde Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit **************************Disclaimer************************************ Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited. ******************************************************************** ------=_NextPartTM-000-ccf38ef6-5d8d-11d6-af80-0080c8048dde-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 2 14:47:11 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25547 for ; Thu, 2 May 2002 14:47:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g42IkLN14143; Thu, 2 May 2002 14:46:21 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g42IjpN14130 for ; Thu, 2 May 2002 14:45:51 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g42IjpXt031239 for ; Thu, 2 May 2002 14:45:51 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 2BE324439E; Thu, 2 May 2002 14:45:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id D695D4439D for ; Thu, 2 May 2002 14:45:45 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g42Ijio31949 for ; Thu, 2 May 2002 14:45:44 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu May 2 14:41:07 EDT 2002 Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA08526; Thu, 2 May 2002 14:45:41 -0400 (EDT) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g42Ije6X028023; Thu, 2 May 2002 14:45:40 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g42Ijepo028020; Thu, 2 May 2002 14:45:40 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15569.35156.246976.869034@grandcentral.cs.columbia.edu> To: "Nagarajan.D" Cc: Subject: Re: [IPTEL] Doubt in CPL Scripts In-Reply-To: <000801c1f1a4$48fd60a0$6428a8c0@M1186K110116> References: <000201c1ef6d$e4b20430$6428a8c0@M1186K110116> <000801c1f1a4$48fd60a0$6428a8c0@M1186K110116> X-Mailer: VM 6.98 under Emacs 20.7.1 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 2 May 2002 14:45:40 -0400 Content-Transfer-Encoding: 7bit On Thursday, May 2 2002, "Nagarajan.D" wrote to "" saying: > I am trying to understand the CPL scripts where I have the following > doubt: > > I am having a CPL Server and the SIP Server as two different components. > Where all calls from the SIP Server is forwarded to the CPL Server to > check for any specific action required and returns an action back to SIP > Server to proceed with. > > Doubt no 1: > > When there is a call between 2 users A and B. > A's script says to start the call logging feature( where the details of > the calls of A are logged to a file ) > And then B's script says to reject all the calls from A. > > In such a case; which one of the following will be the return action > sent from CPL Server to SIP Server > > 1. Start call logging feature for call A > 2. Reject action ; for calls coming from A to B > 3. both 1 and 2. > > In some situations there will be only one action; and in some more than > one action is it right ? > Or do we need to have priorities for the actions of A and B and choose > one among them. > If somebody has done some implementations handling such scenarios can > you please guide me. This is a fairly classic feature interaction issue. The CPL Framework and Requirements RFC (RFC 2824) has some discussion of this. Basically, you treat multiple scripts as though they were taking place on multiple servers. That is, if the call is from A to B, first you execute A's script, and trigger any actions it specifies. Then, if A's script told you to attempt to contact B, you trigger B's script. If B's script rejected the call from A, it's handled exactly the same as if A's script was placed to some external destination which returned a SIP 600 (say) error response. > Doubt no 2: > > And in some cases, the actions could result in recursions, The RFC 2824 > in section 9.2 says " in some cases, forwarding can be recursive; > a CPL Server must be careful to prevent forwarding loops." If somebody > has done some implementations handling such scenarios can you please > guide me. What guidance are you looking for? I'm pretty sure the standard SIP mechanisms for handling forwarding loops should be sufficient. > Doubt no 3: > > Sip Server works on specified set of timers, when a call is been sent to > the CPL Server for action; may be it has to handle many scripts at a > time and respond back. > But it may disturb the SIP timers; How are we going to handle such > situations. Are there any specific timer implementations for CPL Server > required ? The lookup and proxy timeouts are additional timers. They shouldn't disrupt SIP timers, though; they should take place on another level... -jonathan _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 8 05:55:57 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29681 for ; Wed, 8 May 2002 05:55:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g489t8N22211; Wed, 8 May 2002 05:55:08 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g489sHN22192 for ; Wed, 8 May 2002 05:54:17 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g489sHEF075505 for ; Wed, 8 May 2002 05:54:17 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 968A74439E; Wed, 8 May 2002 05:54:12 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 62C954439D for ; Wed, 8 May 2002 05:54:12 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g489sAk65995 for ; Wed, 8 May 2002 05:54:11 -0400 (EDT) Received: from inser.loniis.spb.su ([213.182.177.254]) by dusty; Wed May 8 05:49:10 EDT 2002 Received: from Ycfe ([195.201.37.179]) by inser.loniis.spb.su (8.11.1/8.11.1) with SMTP id g48A1Bl06983 for ; Wed, 8 May 2002 14:01:15 +0400 (MSD) (envelope-from stank@inser.loniis.spb.su) Message-Id: <200205081001.g48A1Bl06983@inser.loniis.spb.su> From: taylor To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="L474li1b43h4439Rl321R8Tno6b1B" Subject: [IPTEL] 2.1 Language Support Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 8 May 2002 14:01:15 +0400 (MSD) This is a multi-part message in MIME format... --L474li1b43h4439Rl321R8Tno6b1B Content-Type: multipart/alternative; boundary="----------=_1020851651-65996-0" MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) This is a multi-part message in MIME format... ------------=_1020851651-65996-0 Content-Type: text/html; Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =0D =0D as the name of the column in the result set.=0D ------------=_1020851651-65996-0 Content-Type: text/plain Content-Disposition: inline MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Content-Transfer-Encoding: 7bit This Email contained an attachment named Ngr.exe. This had a virus W32/Klez.dam. The attachment has been dropped. ------------=_1020851651-65996-0-- --L474li1b43h4439Rl321R8Tno6b1B-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 8 06:35:00 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00070 for ; Wed, 8 May 2002 06:35:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g48AZ4N22738; Wed, 8 May 2002 06:35:04 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g48AYMN22719 for ; Wed, 8 May 2002 06:34:22 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g48AZoUL081973 for ; Wed, 8 May 2002 06:35:50 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 236D64439E; Wed, 8 May 2002 06:34:17 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id F21274439D for ; Wed, 8 May 2002 06:34:16 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g48AYFk68267 for ; Wed, 8 May 2002 06:34:15 -0400 (EDT) Received: from mail2.infineon.com ([192.35.17.230]) by dusty; Wed May 8 06:29:33 EDT 2002 X-Envelope-Sender-Is: Garry.Stansfield@infineon.com (at relayer mail2.infineon.com) Received: from mchb0b2w.muc.infineon.com ([172.31.102.54]) by mail2.infineon.com (8.11.1/8.11.1) with ESMTP id g48AY7S25914; Wed, 8 May 2002 12:34:07 +0200 (MET DST) Received: by mchb0b2w.muc.infineon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 12:34:06 +0200 Message-ID: From: Garry.Stansfield@infineon.com To: taylor@nortelnetworks.com Cc: iptel@lists.bell-labs.com Subject: RE: [IPTEL] 2.1 Language Support MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 8 May 2002 12:33:27 +0200 Please be advised. -----Original Message----- From: taylor [mailto:taylor@nortelnetworks.com] Sent: 08 May 2002 11:01 To: iptel@lists.bell-labs.com Subject: [IPTEL] 2.1 Language Support This Email contained an attachment named Ngr.exe. This had a virus W32/Klez.dam. The attachment has been dropped. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 8 08:39:16 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03317 for ; Wed, 8 May 2002 08:39:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g48Cd2N23672; Wed, 8 May 2002 08:39:03 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g48CcpN23659 for ; Wed, 8 May 2002 08:38:51 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g48CeJUL082759 for ; Wed, 8 May 2002 08:40:19 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 5C99E4439E; Wed, 8 May 2002 08:38:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 364C24439D for ; Wed, 8 May 2002 08:38:46 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g48Ccio42716 for ; Wed, 8 May 2002 08:38:44 -0400 (EDT) Received: from zcars04e.ca.nortel.com ([47.129.242.56]) by dusty; Wed May 8 08:34:02 EDT 2002 Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g48CcdK19875; Wed, 8 May 2002 08:38:39 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 08:38:44 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A43B@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: iptel@lists.bell-labs.com Cc: "'stank@inser.loniis.spb.su'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F68C.E60700BC" Subject: [IPTEL] Virus was 2.1 Language Support Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 8 May 2002 08:39:01 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F68C.E60700BC Content-Type: text/plain; charset="iso-8859-1" Actually that note wasn't from me -- the Klez virus changes From lines. When I look in the headers, it appears the message actually came from stank@inser.loniis.spb.su. Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) ------_=_NextPart_001_01C1F68C.E60700BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Virus was 2.1 Language Support

Actually that note wasn't from me -- the Klez virus = changes From lines.  When I look in the headers, it appears the = message actually came from stank@inser.loniis.spb.su.

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

------_=_NextPart_001_01C1F68C.E60700BC-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri May 10 22:08:39 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29996 for ; Fri, 10 May 2002 22:08:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4B247N09320; Fri, 10 May 2002 22:04:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4B23PN09301 for ; Fri, 10 May 2002 22:03:25 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4B24kUL009057 for ; Fri, 10 May 2002 22:04:47 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id C43D54439E; Fri, 10 May 2002 22:03:19 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 8B0FE4439D for ; Fri, 10 May 2002 22:03:19 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4B23Eo79025 for ; Fri, 10 May 2002 22:03:18 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Fri May 10 21:58:18 EDT 2002 Received: from [193.118.205.14] (HELO [158.152.16.98]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090050; Sat, 11 May 2002 03:03:06 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: To: iptel@lists.bell-labs.com From: Lawrence Conroy Cc: sob@harvard.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPTEL] tel: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 1 Jan 1904 06:11:22 +0000 Hi folks, A question: at Minneapolis, I understood that an update to RFC2806 might be covered in IPTEL. I, for one, am interested in this and wonder - is this the right place to develop work on this? IMHO, at least there will need to be a template for IANA registration for parameters. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri May 10 22:23:23 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00621 for ; Fri, 10 May 2002 22:23:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4B2I2N09498; Fri, 10 May 2002 22:18:02 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4B2HpN09485 for ; Fri, 10 May 2002 22:17:51 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4B2JDUL009177 for ; Fri, 10 May 2002 22:19:13 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 57FD54439E; Fri, 10 May 2002 22:17:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2FD1F4439D for ; Fri, 10 May 2002 22:17:46 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4B2Hik12086 for ; Fri, 10 May 2002 22:17:45 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Fri May 10 22:13:03 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA22096; Fri, 10 May 2002 22:17:41 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-38-202.mad.east.verizon.net [138.89.38.202]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4B2Hb2i021698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 10 May 2002 22:17:39 -0400 (EDT) Message-ID: <3CDC7F69.5000400@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Conroy Cc: iptel@lists.bell-labs.com, sob@harvard.edu Subject: Re: [IPTEL] tel: References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 10 May 2002 22:18:17 -0400 Content-Transfer-Encoding: 7bit I'm (over)due to push out a revised version, hopefully this weekend. Lawrence Conroy wrote: > Hi folks, > A question: at Minneapolis, I understood that an update to RFC2806 > might be covered in IPTEL. > I, for one, am interested in this and wonder - is this the right > place to develop work on this? IMHO, at least there will need to be a > template for IANA registration for parameters. > > all the best, > Lawrence _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri May 10 22:28:14 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00840 for ; Fri, 10 May 2002 22:28:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4B2S4N09683; Fri, 10 May 2002 22:28:04 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4B2RDN09670 for ; Fri, 10 May 2002 22:27:13 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4B2SZUL009347 for ; Fri, 10 May 2002 22:28:35 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id DC6D64439E; Fri, 10 May 2002 22:27:07 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id B59404439D for ; Fri, 10 May 2002 22:27:07 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4B2R6o80510 for ; Fri, 10 May 2002 22:27:06 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Fri May 10 22:22:24 EDT 2002 Received: from [193.118.205.14] (HELO [158.152.16.98]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090052; Sat, 11 May 2002 03:27:23 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3CDC7F69.5000400@cs.columbia.edu> References: <3CDC7F69.5000400@cs.columbia.edu> To: iptel@lists.bell-labs.com From: Lawrence Conroy Subject: Re: [IPTEL] tel: Cc: Henning Schulzrinne Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 11 May 2002 03:26:56 +0100 At 10:18 pm -0400 10/5/02, Henning Schulzrinne wrote: >I'm (over)due to push out a revised version, hopefully this weekend. To which I reply, Ace! Many Thanks, Henning. As I think that this will be used for some trials this year, was getting a little twitchy. I await with enthusiasm. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun May 12 15:43:20 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26570 for ; Sun, 12 May 2002 15:43:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4CJaGN25806; Sun, 12 May 2002 15:36:16 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4CJZDN25793 for ; Sun, 12 May 2002 15:35:13 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4CJZDEF012369 for ; Sun, 12 May 2002 15:35:13 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 148B34439E; Sun, 12 May 2002 15:35:08 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id DFDFF4439D for ; Sun, 12 May 2002 15:35:07 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4CJZ6o55061 for ; Sun, 12 May 2002 15:35:06 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Sun May 12 15:30:21 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA03173; Sun, 12 May 2002 15:34:58 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4CJYv2i026600 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 12 May 2002 15:34:58 -0400 (EDT) Message-ID: <3CDEC3D3.6090000@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <172.4849421.29b55396@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 12 May 2002 15:34:43 -0400 Content-Transfer-Encoding: 7bit Sorry for the delay in responding to these comments. I've updated the draft and will submit it shortly. Until it appears in the archives, you can find it at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-03.txt and http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-03.ps (with changebars for non-trivial changes). Mpierce1@aol.com wrote: > 2. In the 7th paragraph (beginning "The approach pursued...") Extensions of a > PBX can be specified if they are a part of the global number (i.e., when DID > is used). Propose that the words "when direct inward dialing is not used" be > added after "PBX". Added. > > 5.1.2 Maybe it would be helpful to emphasize that, while the uri format does > not support alphabetic characters, it is expected that the user agent would > support entry of such characters by the user and translation based on some > standard. > > The mapping of alphabetic characters to numeric digits is in fact > standardized in E.161 as well as in American National Standard T1.703-1995 > (R1999). However, it is still a good idea to not use this mapping as a basis > for the uri. It is suggested that this final sentence be: "The URI format > does not support this since the mapping of alphabetic characters to nurmeric > digits is not completely uniform internationally, although there are > standards addressing this mapping." Noted. > > It is unclear why the second paragraph states that "F is currently not used." > and "These do not designate the fourth column of the DTMF tone matrix." The > term "Terminal number" is not the usual one used. These statements lead to > confusion. In fact, ISUP defines the additional six values as "code 11, code > 12, ST, and 3 spares", not A-F. It uses the "1111" or "F" value. As shown in > the ABNF, the digits of the global-number are limited to 0-9. While the > digits of the local-number are shown as HEXDIGIT, it is unknown where this > would be used for a tel:uri. It is suggested that this paragraph be reworded > to: "Since called and calling party numbers are encoded in BCD in ISUP, this > allows for six additional values per digit, sometimes represented as the HEX > characters A through F. However, in accordance with E.164, they may not be > included in global numbers. Their use in local numbers is not defined, but is > not prohibited." Added your wording and cleaned up the BNF. Lawrence, please indicate whether restriction to local digits is acceptable and if not, how this related to E.164. > > 5.1.3 In the first paragraph, the phrase "if the client is properly > configured" should be deleted. International numbers themselves are > unambiguous. It is unrelated to the "configuration" of "the client". Gone. > > In the second paragraph, it is unclear why the second sentence states that > "some numbers may work from several networks but not from the whole world; > these SHOULD be written in international form". Since it follows the first > sentence, it is presumed to be referring to "local numbers". It is impossible > to write a local number (which does not work everywhere) in "international > form". Cut-and-paste... Gone. > > 7.3 3rd paragraph: It is unknown why "/" is mentioned here as a possible > character separator. In fact, in E.123, the "/" means something else. This > mention here may confuse people. The whole paragraph seems to be more confusing than helpful, so I ditched it. > > 7.4 While this section is interesting, it has nothing to do with the subject > of the document and should be deleted. It might confuse someone into thinking > that it has some impact on the uri. Same remnant of the old draft. History. > > 7.5 To avoid confusion, the number 00123456789 in the example should not be > referred to as a "local phone number". This sentence should say: "Tel URIs > should, in general, not contain the local dialing prefixes such as the "00" > in 00123456789..." > > It might also be helpful here to mention that, according to E.164, the "+" in > the writing of the international number actually means that an international > prefix is required ("00" in this example). Rephrased. > > 8. The last example in this section should show a valid E.164 number with a > valid US area code, even though the number/letters displayed may contain > extraneous characters to spell a word, as is the common practice (at least in > the US). I would expect that an implementation might discard a uri that it > knows to be incorrect, such as one beginning with +1 that is not followed by > exactly 10 digits. (Not required to do this, but it might.) The example > should be: > > a href="tel:+17034383785">1-703-IETF-RULZ-OK > (Of course, the above needs the angle brackets at the beginning and end. Does > anyone know how to get AOL to stop turning my examples of html into hidden > HTML tags?) I changed the reference. > > References: FED-STD-1037C should be replaced by ANSI T1.523-2001, > Telecommunications Glossary, which replaced it. > > Mike Pierce > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 15 08:55:41 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01000 for ; Wed, 15 May 2002 08:55:40 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4FCeBN11561; Wed, 15 May 2002 08:40:11 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4F9j4N10770 for ; Wed, 15 May 2002 05:45:04 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4F9kAUL053974 for ; Wed, 15 May 2002 05:46:15 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 9B7BD4439E; Wed, 15 May 2002 05:44:38 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 588114439D for ; Wed, 15 May 2002 05:44:38 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4F9iRk27385 for ; Wed, 15 May 2002 05:44:31 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Wed May 15 05:39:40 EDT 2002 Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090096; Wed, 15 May 2002 10:44:47 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: To: hgs@cs.columbia.edu From: Lawrence Conroy Cc: iptel@lists.bell-labs.com, Mpierce1@aol.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPTEL] 2806bis comments Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 May 2002 10:44:22 +0100 Hi Henning, Mike, Folks, In answer to the earlier question on HEXDIG in local numbers: Yes, it's fine by me; (our parse engine allows this only in local numbers :). It's a challenge to gain corroboration this week, but my understanding is that routing numbers that include HEX digits are never flagged as International (E.164) numbers, so "local only" is the correct approach. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 15 08:56:41 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01104 for ; Wed, 15 May 2002 08:56:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4FCovN11701; Wed, 15 May 2002 08:50:57 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4F9m0N10781 for ; Wed, 15 May 2002 05:48:00 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4F9n2UL053990 for ; Wed, 15 May 2002 05:49:12 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 26A7D4439E; Wed, 15 May 2002 05:47:15 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id EFF534439D for ; Wed, 15 May 2002 05:47:14 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4F9lDo96278 for ; Wed, 15 May 2002 05:47:13 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Wed May 15 05:42:26 EDT 2002 Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090097; Wed, 15 May 2002 10:47:35 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: To: hgs@cs.columbia.edu From: Lawrence Conroy Cc: iptel@lists.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPTEL] 2806bis-3 comments Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 May 2002 10:47:10 +0100 Hi Henning, Folks, Re. ABNF on lines 198 to 204. A minor point, but one that would be convenient for the future: I would like a slight expansion to the ABNF (but one with no syntactic change to the URI). When discussing the elements that make up a uri-value, it is useful to be able to name that portion consisting of the "raw" number-part (for lack of a better term), as well as separating out the other parameters from the core one(s). thus: telephone-uri = "tel:" subscriber *other < subscriber = global-number / local-number | global-number = global-number-part [isdn-subaddress] < > global-number-part = "+" 1*globaldigit << local-number = local-number-part < [isdn-subaddress] | 1*(context) | > local-number-part = 1*localdigit << Where a trailing | denotes unchanged line, < denotes a changed line, << indicates an added line, and > denotes a line has been removed. The goal here is to allow a named non-terminal to define just the "number part" of the 'tel:' URI, and to define the overall telephone-uri as being in three parts, so meaning that a 'subscriber' does not include the 'other' parameter(s). The isdn-subaddress and context attributes are bound closely to the rest of the 'subscriber', whilst the 'other' parameters may or may not be so closely bound. This will allow the ABNF for subscriber, global-number-part and local-number-part to be re-used in other documents without requiring other-parameters to be included. With the benefit of hindsight, it would have been useful for the PINT RFC (and saved me personally a great deal of discussion when debugging the first parser we produced for this :). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 15 19:29:58 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25291 for ; Wed, 15 May 2002 19:29:57 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4FNTBN15484; Wed, 15 May 2002 19:29:11 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4FNSAN15464 for ; Wed, 15 May 2002 19:28:10 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4FNTKUL062683 for ; Wed, 15 May 2002 19:29:20 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 194374439E; Wed, 15 May 2002 19:28:05 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id E5BEE4439D for ; Wed, 15 May 2002 19:28:04 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4FNS2k91794 for ; Wed, 15 May 2002 19:28:03 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed May 15 19:23:12 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA25356 for ; Wed, 15 May 2002 19:27:51 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4FNRm2i013492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 May 2002 19:27:50 -0400 (EDT) Message-ID: <3CE2EEE3.3070105@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Conroy Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] 2806bis-3 comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 May 2002 19:27:31 -0400 Content-Transfer-Encoding: 7bit Thank you. Your comments will be incorporated into -04. Lawrence Conroy wrote: > Hi Henning, Folks, > > Re. ABNF on lines 198 to 204. > > A minor point, but one that would be convenient for the future: > I would like a slight expansion to the ABNF (but one with no syntactic > change to the URI). > > When discussing the elements that make up a uri-value, it is useful to > be able to name that portion consisting of the "raw" number-part (for > lack of a better term), as well as separating out the other parameters > from the core one(s). > > thus: > telephone-uri = "tel:" subscriber *other < > subscriber = global-number / local-number | > global-number = global-number-part [isdn-subaddress] < > >> > global-number-part = "+" 1*globaldigit << > local-number = local-number-part < > [isdn-subaddress] | > 1*(context) | > >> > local-number-part = 1*localdigit << > > Where a trailing | denotes unchanged line, < denotes a changed line, << > indicates an added line, and > denotes a line has been removed. > > The goal here is to allow a named non-terminal to define just the > "number part" of the 'tel:' URI, and to define the overall telephone-uri > as being in three parts, so meaning that a 'subscriber' does not include > the 'other' parameter(s). The isdn-subaddress and context attributes > are bound closely to the rest of the 'subscriber', whilst the 'other' > parameters may or may not be so closely bound. > > This will allow the ABNF for subscriber, global-number-part and > local-number-part to be re-used in other documents without requiring > other-parameters to be included. With the benefit of hindsight, it would > have been useful for the PINT RFC (and saved me personally a great deal > of discussion when debugging the first parser we produced for this :). > > all the best, > Lawrence _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 15 19:41:00 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25464 for ; Wed, 15 May 2002 19:40:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4FNefN15669; Wed, 15 May 2002 19:40:41 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4FNSIN15471 for ; Wed, 15 May 2002 19:28:18 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4FNSIEF047692 for ; Wed, 15 May 2002 19:28:18 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id DB99B4439E; Wed, 15 May 2002 19:28:12 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id B14A04439D for ; Wed, 15 May 2002 19:28:12 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4FNSBk91829 for ; Wed, 15 May 2002 19:28:11 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed May 15 19:23:24 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA25385; Wed, 15 May 2002 19:28:06 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4FNS42i013499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 15 May 2002 19:28:05 -0400 (EDT) Message-ID: <3CE2EEF3.9090808@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 15 May 2002 19:27:47 -0400 Content-Transfer-Encoding: 7bit Yu, James wrote: > Henning, > > Don't know whether anyone has caught this: > > In Section 4 related to "phone-context=": change "domain" to "domainname" > or vice versa on the next line. Fixed in the upcoming -04. (http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-04.txt) > > Also [11] should be > [11] J. Yu, "Extensions to the "tel" and "fax" URLs to Support Number > Portability and Freephone Service," Internet Draft, Internet Engineering > Task Force, March 1, 2002. Work in progress. Fixed. > > Apparently, that I-D's title needs to be changed (e.g., removing "fax" URL). > A revision will be submitted to reflect the changes based on RFC2806bis. > > James _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 20 08:26:40 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10763 for ; Mon, 20 May 2002 08:26:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4KCQEN22952; Mon, 20 May 2002 08:26:14 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4KCPvN22939 for ; Mon, 20 May 2002 08:25:57 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4KCQvUL004865 for ; Mon, 20 May 2002 08:26:57 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 447B54439E; Mon, 20 May 2002 08:25:52 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 19B824439D for ; Mon, 20 May 2002 08:25:52 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4KCPoo67333 for ; Mon, 20 May 2002 08:25:50 -0400 (EDT) Received: from plmler1.mail.eds.com ([199.228.142.71]) by dusty; Mon May 20 08:21:01 EDT 2002 Received: from plmlir3.mail.eds.com (plmlir3-2.mail.eds.com [199.228.143.134]) by plmler1.mail.eds.com (8.11.6/8.11.6) with ESMTP id g4KCPmi22483 for ; Mon, 20 May 2002 07:25:48 -0500 Received: from plmlir3.mail.eds.com (localhost [127.0.0.1]) by plmlir3.mail.eds.com (8.11.6/8.11.6) with ESMTP id g4KCPk615860 for ; Mon, 20 May 2002 07:25:46 -0500 (CDT) Received: from usplm002.exch.eds.com (USPLM002.txpln.us.eds.com [198.132.135.7]) by plmlir3.mail.eds.com (8.11.6/8.11.6) with ESMTP id g4KCPj915851 for ; Mon, 20 May 2002 07:25:45 -0500 (CDT) Received: by USPLM002.txpln.us.eds.com with Internet Mail Service (5.5.2655.51) id ; Mon, 20 May 2002 08:25:49 -0400 Message-ID: <2BE915A69EF4D2119A0800805FF5E0500FC0AE23@BRSPM201> From: "Crizza, Roberto" To: iptel@lists.bell-labs.com Subject: [IPTEL] CPL Doubts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.51) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 May 2002 08:24:57 -0400 Team I was comparing the CPL with the VoIP solution that we are installing in our client, I tryed get the answer to my doubt but I could not see, could someone help me ? Does CPL packts go inside the H.323 and SIP protocol specification ? The CPL will set up the connection between terminator A and B and the voice packts will go over the RTP protocol ? Thanks Roberto Crizza - CCDA EDS Brazil - CI - Telecomunicacoes Phone.: 55 11 3471-4536 (8-893- ) Fax.: 55 11 3471-4557 (8-893- ) Cell.: 55 11 9531-9695 email.: roberto.crizza@eds.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 20 09:22:57 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14174 for ; Mon, 20 May 2002 09:22:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4KDN9N23541; Mon, 20 May 2002 09:23:09 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4KDMgN23528 for ; Mon, 20 May 2002 09:22:42 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4KDNgUL005397 for ; Mon, 20 May 2002 09:23:42 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 772CF4439E; Mon, 20 May 2002 09:22:37 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 4C5E34439D for ; Mon, 20 May 2002 09:22:37 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4KDMZo71537 for ; Mon, 20 May 2002 09:22:36 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by dusty; Mon May 20 09:17:46 EDT 2002 Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4KDO1YH015346; Mon, 20 May 2002 09:24:02 -0400 (EDT) Message-ID: <3CE8F896.8B10252D@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Crizza, Roberto" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL Doubts References: <2BE915A69EF4D2119A0800805FF5E0500FC0AE23@BRSPM201> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 May 2002 09:22:30 -0400 Content-Transfer-Encoding: 7bit "Crizza, Roberto" wrote: > > Team > > I was comparing the CPL with the VoIP solution that we are installing in > our > client, I tryed get the answer to my doubt but I could not see, could > someone help me ? > > Does CPL packts go inside the H.323 and SIP protocol specification ? No. A SIP or H.323 call setup request will arrive at a proxy or gatekeeper. The proxy or gatekeeper then processes the call based on the CPL script. The CPL script is obtained by the proxy or gatekeeper through some means outside the scope of the specification. Some implementations allow phones to upload their scripts when the phones register, for example. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 20 14:08:24 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26259 for ; Mon, 20 May 2002 14:08:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4KI6DN25672; Mon, 20 May 2002 14:06:13 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4KI5IN25656 for ; Mon, 20 May 2002 14:05:18 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4KI6IUL011642 for ; Mon, 20 May 2002 14:06:18 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 682824439E; Mon, 20 May 2002 14:05:13 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 39D344439D for ; Mon, 20 May 2002 14:05:13 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4KI5Bo09357 for ; Mon, 20 May 2002 14:05:12 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by dusty; Mon May 20 14:00:22 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4KI4UEU019487; Mon, 20 May 2002 11:04:31 -0700 (PDT) Received: from cisco.com (sjc-vpn2-6.cisco.com [10.21.112.6]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA01455; Mon, 20 May 2002 11:04:26 -0700 (PDT) Message-ID: <3CE93AAA.DA562F82@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "Yu, James" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CE2EEF3.9090808@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 May 2002 14:04:26 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Yu, James wrote: > > Henning, > > > > Don't know whether anyone has caught this: > > > > In Section 4 related to "phone-context=": change "domain" to "domainname" > > or vice versa on the next line. > > Fixed in the upcoming -04. > (http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-04.txt) > The "*other" part of the global-number and local-number productions seem to have been replaced with "*param" in "telephone-uri", however Section 5.3 still talks about "". Question regarding naming of the "other" parameters: Is the "m-" a prefix that can be added to any extension parameter, or must an extension parameter be defined and registered with an "m-" prefix from the start ? Nit comments: ========== Section 5.1.2: "as as" => "as" Section 5.3: "in the BNF" = "in the ABNF" Section 6: "human- readable" => "human-readable" Section 7.2: `Telephone" => "Telephone" (first double-qoute formatting) Thanks Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 20 22:43:24 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01833 for ; Mon, 20 May 2002 22:43:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4L2hBN28615; Mon, 20 May 2002 22:43:11 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4L2gkN28602 for ; Mon, 20 May 2002 22:42:46 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4L2hjUL017004 for ; Mon, 20 May 2002 22:43:45 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 2E0414439E; Mon, 20 May 2002 22:42:41 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 026494439D for ; Mon, 20 May 2002 22:42:40 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4L2gdk79020 for ; Mon, 20 May 2002 22:42:39 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon May 20 22:37:50 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA21313; Mon, 20 May 2002 22:42:29 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-39-64.mad.east.verizon.net [138.89.39.64]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4L2gO2i015682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 May 2002 22:42:27 -0400 (EDT) Message-ID: <3CE9B449.8000001@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Yu, James" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CE2EEF3.9090808@cs.columbia.edu> <3CE93AAA.DA562F82@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 May 2002 22:43:21 -0400 Content-Transfer-Encoding: 7bit > The "*other" part of the global-number and local-number productions seem to have > been replaced with "*param" in "telephone-uri", however Section 5.3 still talks > about "". Oops; fixed. > > Question regarding naming of the "other" parameters: Is the "m-" a prefix that > can be added to any extension parameter, or must an extension parameter be defined > and registered with an "m-" prefix from the start ? My intent was to register it with the m- prefix from the start. I think it would complicate parsers if they had to worry about the same parameter having two names. Can you envision that the same parameter sometimes will be required, sometimes be optional? To me, that type of parameter probably assumes too much about knowing the receiver. > > > Nit comments: > ========== > Section 5.1.2: "as as" => "as" > > Section 5.3: "in the BNF" = "in the ABNF" > > Section 6: "human- readable" => "human-readable" > > Section 7.2: `Telephone" => "Telephone" (first double-qoute formatting) > Thanks! Henning _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon May 20 23:12:54 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03152 for ; Mon, 20 May 2002 23:12:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4L3D2N28974; Mon, 20 May 2002 23:13:02 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4L3CcN28961 for ; Mon, 20 May 2002 23:12:38 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4L3DbUL017309 for ; Mon, 20 May 2002 23:13:37 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 2C4774439E; Mon, 20 May 2002 23:12:30 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 04DF54439D for ; Mon, 20 May 2002 23:12:29 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4L3CSo46896 for ; Mon, 20 May 2002 23:12:28 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon May 20 23:07:39 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA22949; Mon, 20 May 2002 23:12:25 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-39-64.mad.east.verizon.net [138.89.39.64]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4L3CK2i016739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 20 May 2002 23:12:23 -0400 (EDT) Message-ID: <3CE9BB4E.1060707@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 20 May 2002 23:13:18 -0400 Content-Transfer-Encoding: 7bit > > Is there a reason why "context" is put inside ()? No, but it doesn't matter, since the () are just grouping. I removed the (). > Also, the syntax allows > more than one "context" parameter. Is it possible to have more than one > "context" in real situation? If yes (e.g., two domain names plus one > prefix), which one is to be used? Suggest to add some discussions about the > allowed situation where more than one contexts occur. This was supposed to be an "OR", i.e., the number applies in all such contexts. However, come to think of it, that's probably a bad idea. I don't think URIs typically have multiple parameters with the same name. Some parsers are likely to not take this gracefully. For the OR case, the pickings are slim, however: - + is taken - comma and semicolon are not allowed (without escaping) - / doesn't fit well and would be confusing - . doesn't work for domain names - : is one possibility, as in tel:1234;phone-context=example.com:+12345 Other suggestions welcome. > > I've the "global routing number" parameter that begin with the country code > followed by hex digits. Is it possible for you to describe "country code" > part of the global-number-part so that I can use it in my I-D. I hate to > see that the "extensions" defines something in more details. The first one > to three digits of the global-number-part identify the country code. Done. Can the country code contain hex digits? Is there the possibility that country codes need more than three digits? Does East Timor have its own country code? _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 05:30:03 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00261 for ; Tue, 21 May 2002 05:30:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4L9U7N31348; Tue, 21 May 2002 05:30:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4L9TON31326 for ; Tue, 21 May 2002 05:29:24 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4L9ULUL019924 for ; Tue, 21 May 2002 05:30:21 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 95A794439E; Tue, 21 May 2002 05:29:18 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 61E3D4439D for ; Tue, 21 May 2002 05:29:18 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4L9THk98190 for ; Tue, 21 May 2002 05:29:17 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Tue May 21 05:24:23 EDT 2002 Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090161; Tue, 21 May 2002 10:29:12 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3CE9BB4E.1060707@cs.columbia.edu> References: <3CE9BB4E.1060707@cs.columbia.edu> To: Henning Schulzrinne , "Yu, James" From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 10:28:57 +0100 At 11:13 pm -0400 20/5/02, Henning Schulzrinne wrote: in response to James' comments - > Also, the syntax allows >>more than one "context" parameter. Is it possible to have more than one >>"context" in real situation? If yes (e.g., two domain names plus one >>prefix), which one is to be used? Suggest to add some discussions about the >>allowed situation where more than one contexts occur. > >This was supposed to be an "OR", i.e., the number applies in all >such contexts. However, come to think of it, that's probably a bad >idea. I don't think URIs typically have multiple parameters with the >same name. Some parsers are likely to not take this gracefully. For >the OR case, the pickings are slim, however: > >- + is taken >- comma and semicolon are not allowed (without escaping) >- / doesn't fit well and would be confusing >- . doesn't work for domain names >- : is one possibility, as in > >tel:1234;phone-context=example.com:+12345 > >Other suggestions welcome. Actually, I can think of a number of situations in which an identifier can be used for different objects. The context is a qualifier on the applicability of the URI. It's not really more than one parameter - The single parameter 'phone-context' can have more than one value. This can happen due to introduction of relief codes, or the Vienna case, where there are two codes to dial Vienna (within Austria). Thus a Viennese phone could have two values for its phone context (01 and the old code - can't remember what this is, off hand). As an aside, the old code is not valid outside Austria, so writing this in International form is strange. [Also, for example, the tel: number might be associated with voice telephony or fax or mms or... I understand that one can use SIP as a "Service Resolution Service" and am still thinking on whether or not such explicit service idents are ever needed, but these could indeed have more than one value to the hypothetical parameter 'service' - I suspect that these would be 'hints' rather than mandatory] This, BTW, is why I originally asked the dumb question on comma separated list values. The conclusion of that is that there will be a set of params, each with one value. The alternative (there is one parameter with multiple values) needs to be syntactically valid, but may be more compact. Any ideas on value separators - is the above an exhaustive list? >> >>I've the "global routing number" parameter that begin with the country code >>followed by hex digits. Is it possible for you to describe "country code" >>part of the global-number-part so that I can use it in my I-D. I hate to >>see that the "extensions" defines something in more details. The first one >>to three digits of the global-number-part identify the country code. > >Done. Can the country code contain hex digits? Is there the >possibility that country codes need more than three digits? Does >East Timor have its own country code? Hmm...should be in E.164, IMHO. Will look. BTW, James, the conclusion we had was that a RN is not in International format so that a local number is OK when using HEXDIG. I can't think of a situation where one needs a "pseudo-E.164" number with HEXDIG in the country/service code. Was this your intention? atb, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 07:55:13 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05783 for ; Tue, 21 May 2002 07:55:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LBo3N32207; Tue, 21 May 2002 07:50:03 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LBnIN32182 for ; Tue, 21 May 2002 07:49:18 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LBoGUL020758 for ; Tue, 21 May 2002 07:50:16 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 5FBFF4439E; Tue, 21 May 2002 07:49:13 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 36D6D4439D for ; Tue, 21 May 2002 07:49:13 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LBnBk04948 for ; Tue, 21 May 2002 07:49:12 -0400 (EDT) Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Tue May 21 07:44:23 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4LBmcHs014178; Tue, 21 May 2002 04:48:38 -0700 (PDT) Received: from cisco.com (sjc-vpn1-834.cisco.com [10.21.99.66]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA19129; Tue, 21 May 2002 04:48:35 -0700 (PDT) Message-ID: <3CEA3414.CBA695DF@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "Yu, James" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CE2EEF3.9090808@cs.columbia.edu> <3CE93AAA.DA562F82@cisco.com> <3CE9B449.8000001@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 07:48:36 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > > Question regarding naming of the "other" parameters: Is the "m-" a prefix that > > can be added to any extension parameter, or must an extension parameter be defined > > and registered with an "m-" prefix from the start ? > > My intent was to register it with the m- prefix from the start. I think > it would complicate parsers if they had to worry about the same > parameter having two names. Can you envision that the same parameter > sometimes will be required, sometimes be optional? To me, that type of > parameter probably assumes too much about knowing the receiver. > You can probably argue both ways on that, but I don't feel strongly about it. It leads to the next question though, which is really for James: Will the yu-tel-url parameters be prefixed with "m-" ? Thanks Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 08:16:55 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06591 for ; Tue, 21 May 2002 08:16:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LCH8N32424; Tue, 21 May 2002 08:17:08 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LCGqN32411 for ; Tue, 21 May 2002 08:16:52 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LCHnUL020926 for ; Tue, 21 May 2002 08:17:49 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id DD03D4439E; Tue, 21 May 2002 08:16:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id B419E4439D for ; Tue, 21 May 2002 08:16:46 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LCGjo71328 for ; Tue, 21 May 2002 08:16:45 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 21 08:11:55 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA03779; Tue, 21 May 2002 08:16:39 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-39-64.mad.east.verizon.net [138.89.39.64]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LCGb2i005243 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 May 2002 08:16:38 -0400 (EDT) Message-ID: <3CEA3ADD.1010005@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Yu, James" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CE2EEF3.9090808@cs.columbia.edu> <3CE93AAA.DA562F82@cisco.com> <3CE9B449.8000001@cs.columbia.edu> <3CEA3414.CBA695DF@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 08:17:33 -0400 Content-Transfer-Encoding: 7bit > You can probably argue both ways on that, but I don't feel strongly about it. It leads > to the next question though, which is really for James: Will the yu-tel-url parameters > be prefixed with "m-" ? I actually changed from o- to m- because of James' draft. He claimed that all "his" parameters were optional and he didn't want to change his parameter names. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 08:30:19 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06969 for ; Tue, 21 May 2002 08:30:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LCS2N32636; Tue, 21 May 2002 08:28:02 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LCRLN32595 for ; Tue, 21 May 2002 08:27:21 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LCSIUL021173 for ; Tue, 21 May 2002 08:28:18 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id A76734439E; Tue, 21 May 2002 08:27:15 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 7BC7A4439D for ; Tue, 21 May 2002 08:27:15 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LCREo72225 for ; Tue, 21 May 2002 08:27:14 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 21 08:22:16 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA04246; Tue, 21 May 2002 08:26:51 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-39-64.mad.east.verizon.net [138.89.39.64]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LCQn2i005554 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 May 2002 08:26:50 -0400 (EDT) Message-ID: <3CEA3D41.4020001@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Conroy Cc: "Yu, James" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CE9BB4E.1060707@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 08:27:45 -0400 Content-Transfer-Encoding: 7bit > Actually, I can think of a number of situations in which an identifier > can be used for different objects. > > The context is a qualifier on the applicability of the URI. It's not > really more than one parameter - The single parameter 'phone-context' can > have more than one value. This can happen due to introduction of relief > codes, > or the Vienna case, where there are two codes to dial Vienna (within > Austria). > Thus a Viennese phone could have two values for its phone context (01 > and the > > Any ideas on value separators - is the above an exhaustive list? I agree that multiple contexts are useful. The choice of separators is Systematically, from RFC 2396 delims = "<" | ">" | "#" | "%" | <"> are out, as are unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" The best set to draw from is reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," as they are meant for delineation. For tel URLs, ";", "+", "=" are taken. I was wrong about the comma - it's a legitimate separator. I suspect I got confused by the difficulty that this sometimes causes in Contact and To/From SIP headers, requiring <> enclosure. From the set, "&" or "," seem the most semantically meaningful. May as well use the comma. > BTW, James, the conclusion we had was that a RN is not in International > format > so that a local number is OK when using HEXDIG. I can't think of a > situation > where one needs a "pseudo-E.164" number with HEXDIG in the > country/service code. > Was this your intention? > > atb, > Lawrence _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 08:43:47 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07815 for ; Tue, 21 May 2002 08:43:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LCi2N00449; Tue, 21 May 2002 08:44:02 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LChWN00436 for ; Tue, 21 May 2002 08:43:32 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LCiUUL021493 for ; Tue, 21 May 2002 08:44:30 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 33B224439E; Tue, 21 May 2002 08:43:27 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0B6314439D for ; Tue, 21 May 2002 08:43:27 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LChPo73484 for ; Tue, 21 May 2002 08:43:25 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by dusty; Tue May 21 08:38:37 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4LCgpEU018543; Tue, 21 May 2002 05:42:51 -0700 (PDT) Received: from cisco.com (sjc-vpn1-834.cisco.com [10.21.99.66]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA29194; Tue, 21 May 2002 05:42:50 -0700 (PDT) Message-ID: <3CEA40CA.C1B2C78C@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: "Yu, James" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CE2EEF3.9090808@cs.columbia.edu> <3CE93AAA.DA562F82@cisco.com> <3CE9B449.8000001@cs.columbia.edu> <3CEA3414.CBA695DF@cisco.com> <3CEA3ADD.1010005@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 08:42:50 -0400 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > You can probably argue both ways on that, but I don't feel strongly about it. It leads > > to the next question though, which is really for James: Will the yu-tel-url parameters > > be prefixed with "m-" ? > > I actually changed from o- to m- because of James' draft. He claimed > that all "his" parameters were optional and he didn't want to change his > parameter names. I must be missing something then. How can a CIC code and a routing number be optional ? Are you saying you can just ignore carrier selection and route ported numbers to the old exchange ? -- Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 11:06:47 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13770 for ; Tue, 21 May 2002 11:06:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LEx9N01595; Tue, 21 May 2002 10:59:09 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LEwFN01582 for ; Tue, 21 May 2002 10:58:15 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LEwFEF000459 for ; Tue, 21 May 2002 10:58:15 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id C4B764439E; Tue, 21 May 2002 10:58:09 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 999F84439D for ; Tue, 21 May 2002 10:58:09 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LEw8o86466 for ; Tue, 21 May 2002 10:58:08 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 21 10:53:18 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17452; Tue, 21 May 2002 10:58:01 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LEw02i011062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 May 2002 10:58:01 -0400 (EDT) Message-ID: <3CEA6062.70304@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" Cc: "'Flemming Andreasen'" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 10:57:38 -0400 Content-Transfer-Encoding: 7bit > - A node does not understand "m-rn" or "m-cic" and stops processing the SIP > INVITE message > > - A node does not understand "rn" or "cic" and routes based on the phone > number > > The choice is the latter. This is because when the call arrives at a PSTN > gateway or another SIP proxy server, that gateway/server may understand "rn" > or "cic" or may be able to do another NP/800 database dip. > > I suggest that 2806bis discuss whether a node drops or keeps "unknown" > optional parameters when it receives the INVITE message and needs to send > another INVITE message out. It seems better to keep the unknown optional > parameters in the message because the next node may be able to handle it. > 2806bis is not SIP-specific, so it would not be appropriate to discuss transformations of URLs there. Generally, the normal URL rules in SIP apply. > Can the country code contain hex digits? Is there the possibility > that country codes need more than three digits? Does East Timor have its > own country code? > > [JY] > According to E.164, country codes (CCs) can be assigned > > - For geographical areas - CCs are one to three digits long. > > - For global services - CCs are always three digits long. > > - For shared international networks - CCs are always three digits long. > > In all three cases the CCs do not contain digits A thru F. > > The global routing number I have in mind will always start with "+CC" where > the CC does not contain digits A thru F and the digits after CC may contain > hex digits. So a global routing number, rn=+1-202-533-1234, would be the > same as a local routing number, rn=202-533-1234;phone-context=+1. > > May be we can use "number-context" instead of "phone-context" so that it can > be used for the phone number and routing number. I thought somebody already complained when I had accidentally changed the label to "context". If a change is acceptable, I'd rather go for the shorter "context". In the end, I don't think the name much matters, as long as the description is clear. > > James _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 11:17:59 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14387 for ; Tue, 21 May 2002 11:17:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LFI8N01849; Tue, 21 May 2002 11:18:08 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LFHJN01836 for ; Tue, 21 May 2002 11:17:19 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LFIGUL023646 for ; Tue, 21 May 2002 11:18:16 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id EC2C84439E; Tue, 21 May 2002 11:17:14 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id C08CE4439D for ; Tue, 21 May 2002 11:17:13 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LFHCo88481 for ; Tue, 21 May 2002 11:17:12 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by dusty; Tue May 21 11:11:59 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4LFG0EU017072; Tue, 21 May 2002 08:16:03 -0700 (PDT) Received: from cisco.com (sjc-vpn1-834.cisco.com [10.21.99.66]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA01943; Tue, 21 May 2002 08:15:59 -0700 (PDT) Message-ID: <3CEA64AD.79FBCB01@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yu, James" Cc: Henning Schulzrinne , iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 11:15:57 -0400 Content-Transfer-Encoding: 7bit "Yu, James" wrote: > -------- Flemming Andreasen -------- > I must be missing something then. How can a CIC code and a routing number be > optional ? Are > you saying you can just ignore carrier selection and route ported numbers to > the old > exchange ? > > [JY] > Comparing the following two: > > - A node does not understand "m-rn" or "m-cic" and stops processing the SIP > INVITE message > > - A node does not understand "rn" or "cic" and routes based on the phone > number > > The choice is the latter. This is because when the call arrives at a PSTN > gateway or another SIP proxy server, that gateway/server may understand "rn" > or "cic" or may be able to do another NP/800 database dip. > But what if the the call never arrives at a PSTN gateway or SIP server that understand these extensions ? > The "cic" case may be more complicated. If the tel URL has an 800 number > and a "cic" and the node does not understand "cic," it will route based on > the 800 number. Such a node is not likely to launch 800 database queries. > It is more likely configured to route the call to another node that can > handle the 800 calls. But again, what if the the call does not arrive at such a node ? You seem to be arguing on the precise of assuming that if entity A does not support these parameters, then probably some other entity B will, and hence everyting will work OK. I don't find this convincing. Take another example where I as a consumer actually dial a particular carrier selection code as part of my call, but by default, all my calls are handled by another carrier. I don't see how you will route this call correctly without a guarantee that at least one entity in the forwarding path understands the extension (not to mention the fact that routing can be rather inefficient if preceeding hops routed the call incorrectly because they didn't understand the extensions). In other words, I don't see how these parameters can be optional. If you are concerned about lack of implementation support, then perhaps the best way to address that is by including the extensions in 2806bis, since they do seem to be a prerequisite for a generally useful tel-URI. Thanks Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 11:21:04 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14589 for ; Tue, 21 May 2002 11:21:03 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LF62N01720; Tue, 21 May 2002 11:06:02 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LF3AN01636 for ; Tue, 21 May 2002 11:03:10 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LF3AEF000494 for ; Tue, 21 May 2002 11:03:10 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 0D62A4439E; Tue, 21 May 2002 11:03:05 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id D66BB4439D for ; Tue, 21 May 2002 11:03:04 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LF33k22302 for ; Tue, 21 May 2002 11:03:03 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 21 10:58:14 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA21030 for ; Tue, 21 May 2002 11:02:59 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LF2w2i011262 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 21 May 2002 11:02:59 -0400 (EDT) Message-ID: <3CEA618D.9080105@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPTEL] RFC2806bis 04 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 11:02:37 -0400 Content-Transfer-Encoding: 7bit I integrated all the changes discussed in the last few days. I will be submitting 04 shortly, but please take a last quick look at http://www.cs.columbia.edu/sip/drafts/draft-antti-rfc2806bis-04.txt to make sure your comments are reflected. Thanks. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 11:42:54 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15192 for ; Tue, 21 May 2002 11:42:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LFh7N02512; Tue, 21 May 2002 11:43:07 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LFgVN02492 for ; Tue, 21 May 2002 11:42:31 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LFhSUL024335 for ; Tue, 21 May 2002 11:43:28 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 227054439E; Tue, 21 May 2002 11:42:26 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id EA6404439D for ; Tue, 21 May 2002 11:42:25 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LFgOk27369 for ; Tue, 21 May 2002 11:42:24 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 21 11:37:33 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA24240; Tue, 21 May 2002 11:42:16 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LFgF2i013177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 May 2002 11:42:15 -0400 (EDT) Message-ID: <3CEA6AC1.6010508@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mpierce1@aol.com Cc: lwc@roke.co.uk, james.yu@neustar.biz, iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <25.27d91be9.2a1bc2f5@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 11:41:53 -0400 Content-Transfer-Encoding: 7bit Your note would argue for not encoding the details of the format (country code) in the tel URL BNF, particularly since there's no real delimiter between country code and remainder of the message. In other words, entities that just parse the URL (as opposed to dialing a number) don't care which of the first N digits are a country code. Prefix matching for the context is done by string matching, too. Generally, I think encoding semantics in a syntax description is a bad idea. > Current E.164 calls for decimal, not hex, but I know there have been > suggestions to change that. In addition, I believe there is now > discussion about providing some 4-digit "country codes" by using the > unused 3-digit codes of 28x, 83x and 89x to support the continued > fractioning of countries. The important point is that, whatever SIP > does, it must be able to gracefully handle later changes to the > worldwide (and local) numbering plans. That means that these things can > not be burned into end devices. (Remember, the number was recently > expanded from 12 to 15 digits.) > > Mike Pierce _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 11:43:07 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15205 for ; Tue, 21 May 2002 11:43:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LFa2N02316; Tue, 21 May 2002 11:36:02 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LFZiN02303 for ; Tue, 21 May 2002 11:35:44 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LFafUL024172 for ; Tue, 21 May 2002 11:36:41 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id E967B4439E; Tue, 21 May 2002 11:35:39 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id C0FB74439D for ; Tue, 21 May 2002 11:35:38 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LFZbo91239 for ; Tue, 21 May 2002 11:35:37 -0400 (EDT) Received: from imo-m08.mx.aol.com ([64.12.136.163]) by dusty; Tue May 21 11:30:37 EDT 2002 Received: from Mpierce1@aol.com by imo-m08.mx.aol.com (mail_out_v32.5.) id 3.25.27d91be9 (3876); Tue, 21 May 2002 11:34:14 -0400 (EDT) From: Mpierce1@aol.com Message-ID: <25.27d91be9.2a1bc2f5@aol.com> Subject: Re: [IPTEL] Comments on RFC2806bis To: lwc@roke.co.uk, hgs@cs.columbia.edu, james.yu@neustar.biz Cc: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_25.27d91be9.2a1bc2f5_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 11:34:13 EDT --part1_25.27d91be9.2a1bc2f5_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/21/02 7:27:18 AM Eastern Daylight Time, lwc@roke.co.uk writes: (In response to an earlier from Henning) > >Done. Can the country code contain hex digits? Is there the > >possibility that country codes need more than three digits? Does > >East Timor have its own country code? > > Hmm...should be in E.164, IMHO. Will look. > Current E.164 calls for decimal, not hex, but I know there have been suggestions to change that. In addition, I believe there is now discussion about providing some 4-digit "country codes" by using the unused 3-digit codes of 28x, 83x and 89x to support the continued fractioning of countries. The important point is that, whatever SIP does, it must be able to gracefully handle later changes to the worldwide (and local) numbering plans. That means that these things can not be burned into end devices. (Remember, the number was recently expanded from 12 to 15 digits.) Mike Pierce --part1_25.27d91be9.2a1bc2f5_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/21/02 7:27:18 AM Eastern Daylight Time, lwc@roke.co.uk writes:
(In response to an earlier from Henning)

>Done. Can the country code contain hex digits? Is there the
>possibility that country codes need more than three digits? Does
>East Timor have its own country code?

Hmm...should be in E.164, IMHO. Will look.


Current E.164 calls for decimal, not hex, but I know there have been suggestions to change that. In addition, I believe there is now discussion about providing some 4-digit "country codes" by using the unused 3-digit codes of 28x, 83x and 89x to support the continued fractioning of countries. The important point is that, whatever SIP does, it must be able to gracefully handle later changes to the worldwide (and local) numbering plans. That means that these things can not be burned into end devices. (Remember, the number was recently expanded from 12 to 15 digits.)

Mike Pierce
--part1_25.27d91be9.2a1bc2f5_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 13:07:18 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19709 for ; Tue, 21 May 2002 13:07:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LH7AN03543; Tue, 21 May 2002 13:07:10 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LH6oN03530 for ; Tue, 21 May 2002 13:06:50 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LH6oEF002241 for ; Tue, 21 May 2002 13:06:50 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 25D2F4439E; Tue, 21 May 2002 13:06:45 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id F20874439D for ; Tue, 21 May 2002 13:06:44 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LH6ho01821 for ; Tue, 21 May 2002 13:06:43 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Tue May 21 13:01:50 EDT 2002 Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090168; Tue, 21 May 2002 18:06:44 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3CEA64AD.79FBCB01@cisco.com> References: <3CEA64AD.79FBCB01@cisco.com> To: Flemming Andreasen From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, hgs@cs.columbia.edu, james.yu@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 18:06:32 +0100 Flemming wrote: > >Take another example where I as a consumer actually dial a particular carrier >selection code as part of my call, but by default, all my calls are handled by >another carrier. I don't see how you will route this call correctly without a >guarantee that at least one entity in the forwarding path understands the >extension (not to mention the fact that routing can be rather inefficient if >preceeding hops routed the call incorrectly because they didn't understand the >extensions). > >In other words, I don't see how these parameters can be optional. If you are >concerned about lack of implementation support, then perhaps the best way to >address that is by including the extensions in 2806bis, since they >do seem to be >a prerequisite for a generally useful tel-URI. > To which I reply: It can be used in SIP, but it can also be used in a static form (e.g. DNS NAPTR content). In the latter case, it may be in the public ENUM space, or it might be stored within a Service provider's private space. I do not believe that a rn or cic parameter is a prerequisite for all these cases - Indeed, for the static (DNS) cases one may or may not need this parameterisation at all. I agree with James that it cannot be mandatory (i.e. "use this or fail"). For example, looking at the SIP case, a recipient of a SIP dialog may or may not have a trust relationship with the sender of this information. If they do not then they are at liberty to do another dip themselves. Thus a mandatory "do or die" is not appropriate, IMHO. My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand this parameter. Then again, when I outcall with this kind of URI there WILL be some external outbound proxy and/or gateway in line, and whilst understanding this parameter by *that* box may be required (for regulatory reasons ?), I'd be really unhappy if my home box were to be declared non-standard because it cannot understand nor act on a cic value but instead passes it downstream. For both these reasons, I belive that this is a stand-alone extension, and is NOT a core part of RFC2806bis. Note that we lost the 'tsp=' parameter as well in the bis process; that would also be a stand-alone extension. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 13:15:47 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20141 for ; Tue, 21 May 2002 13:15:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LHG2N03678; Tue, 21 May 2002 13:16:02 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LHFQN03665 for ; Tue, 21 May 2002 13:15:26 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LHGNUL025806 for ; Tue, 21 May 2002 13:16:23 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 5D2634439E; Tue, 21 May 2002 13:15:21 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 325B44439D for ; Tue, 21 May 2002 13:15:21 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LHFIo02682 for ; Tue, 21 May 2002 13:15:19 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue May 21 13:10:24 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA08531; Tue, 21 May 2002 13:15:10 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LHF92i017983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 21 May 2002 13:15:09 -0400 (EDT) Message-ID: <3CEA8087.6050109@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yu, James" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 13:14:47 -0400 Content-Transfer-Encoding: 7bit I've changed things so that all digit strings can contain hex digits. This seems simplest and least likely to cause future problems. In general, I don't think syntactic checking of phone numbers buys much, given that most syntactically legal random numbers are probably not valid. Yu, James wrote: > I agree that it is better to use hex digits also for global-number so that > there is no need to modify the RFC if E.164 is changed. Allowing hex > digits does not mean all numbers are valid. Even if we only allow decimal > digits for country codes, those country code values, if not yet assigned by > ITU-T, are invalid. Suggest to use hex digits and let the node decide > whether a number/prefix is valid or not for routing. > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 15:11:39 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25201 for ; Tue, 21 May 2002 15:11:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LJBUN04639; Tue, 21 May 2002 15:11:30 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LJAhN04626 for ; Tue, 21 May 2002 15:10:43 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LJBeUL027692 for ; Tue, 21 May 2002 15:11:40 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 56DF14439E; Tue, 21 May 2002 15:10:38 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2885B4439D for ; Tue, 21 May 2002 15:10:38 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LJAak50252 for ; Tue, 21 May 2002 15:10:36 -0400 (EDT) Received: from plmler2.mail.eds.com ([199.228.142.72]) by dusty; Tue May 21 15:05:44 EDT 2002 Received: from plmlir3.mail.eds.com (plmlir3-2.mail.eds.com [199.228.143.134]) by plmler2.mail.eds.com (8.11.6/8.11.6) with ESMTP id g4LJAXU16404 for ; Tue, 21 May 2002 14:10:33 -0500 Received: from plmlir3.mail.eds.com (localhost [127.0.0.1]) by plmlir3.mail.eds.com (8.11.6/8.11.6) with ESMTP id g4LJAVB19000 for ; Tue, 21 May 2002 14:10:32 -0500 (CDT) Received: from usplm001.exch.eds.com (USPLM001.txpln.us.eds.com [198.132.135.6]) by plmlir3.mail.eds.com (8.11.6/8.11.6) with ESMTP id g4LJAP018616 for ; Tue, 21 May 2002 14:10:26 -0500 (CDT) Received: by USPLM001.txpln.us.eds.com with Internet Mail Service (5.5.2655.51) id ; Tue, 21 May 2002 14:10:00 -0500 Message-ID: <2BE915A69EF4D2119A0800805FF5E0500FC8C88C@BRSPM201> From: "Crizza, Roberto" To: iptel@lists.bell-labs.com Subject: RE: [IPTEL] Comments on RFC2806bis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.51) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 14:09:34 -0500 I agree Here we dial the carrier selection, if we don't handle these numbers they will not routing to right path. Roberto Crizza - CCDA EDS Brazil - CI - Telecomunicacoes I. Solutions - DowNet Project Phone.: 55 11 3471-4536 (8-893- ) Fax.: 55 11 3471-4557 (8-893- ) Cell.: 55 11 9531-9695 email.: roberto.crizza@eds.com Flemming wrote: > >Take another example where I as a consumer actually dial a particular carrier >selection code as part of my call, but by default, all my calls are handled by >another carrier. I don't see how you will route this call correctly without a >guarantee that at least one entity in the forwarding path understands the >extension (not to mention the fact that routing can be rather inefficient if >preceeding hops routed the call incorrectly because they didn't understand the >extensions). > >In other words, I don't see how these parameters can be optional. If you are >concerned about lack of implementation support, then perhaps the best way to >address that is by including the extensions in 2806bis, since they >do seem to be >a prerequisite for a generally useful tel-URI. > To which I reply: It can be used in SIP, but it can also be used in a static form (e.g. DNS NAPTR content). In the latter case, it may be in the public ENUM space, or it might be stored within a Service provider's private space. I do not believe that a rn or cic parameter is a prerequisite for all these cases - Indeed, for the static (DNS) cases one may or may not need this parameterisation at all. I agree with James that it cannot be mandatory (i.e. "use this or fail"). For example, looking at the SIP case, a recipient of a SIP dialog may or may not have a trust relationship with the sender of this information. If they do not then they are at liberty to do another dip themselves. Thus a mandatory "do or die" is not appropriate, IMHO. My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand this parameter. Then again, when I outcall with this kind of URI there WILL be some external outbound proxy and/or gateway in line, and whilst understanding this parameter by *that* box may be required (for regulatory reasons ?), I'd be really unhappy if my home box were to be declared non-standard because it cannot understand nor act on a cic value but instead passes it downstream. For both these reasons, I belive that this is a stand-alone extension, and is NOT a core part of RFC2806bis. Note that we lost the 'tsp=' parameter as well in the bis process; that would also be a stand-alone extension. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 15:59:59 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27081 for ; Tue, 21 May 2002 15:59:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LJs9N05196; Tue, 21 May 2002 15:54:09 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LJr1N05183 for ; Tue, 21 May 2002 15:53:01 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LJr1EF004325 for ; Tue, 21 May 2002 15:53:01 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id C19F54439E; Tue, 21 May 2002 15:52:55 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 9E2284439D for ; Tue, 21 May 2002 15:52:55 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4LJqsk54874 for ; Tue, 21 May 2002 15:52:54 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by dusty; Tue May 21 15:48:00 EDT 2002 Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4LJqcdl010088; Tue, 21 May 2002 15:52:41 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAW38831; Tue, 21 May 2002 15:47:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lawrence Conroy From: Michael Hammer Subject: Re: [IPTEL] Comments on RFC2806bis Cc: Henning Schulzrinne , "Yu, James" , iptel@lists.bell-labs.com In-Reply-To: References: <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 15:52:07 -0400 It would not be a good idea to use a local dial plan in an international number format as suggested for Vienna. I assume that E. Timor as a newly created country might not have one now, but would likely get one quickly. Finally a random number, if the first few digits matched a dial plan could be routed. Excess digits could be ignored. But random hex digits might have a harder time. Mike At 10:28 AM 5/21/2002 +0100, Lawrence Conroy wrote: >At 11:13 pm -0400 20/5/02, Henning Schulzrinne wrote: >in response to James' comments - >> Also, the syntax allows >>>more than one "context" parameter. Is it possible to have more than one >>>"context" in real situation? If yes (e.g., two domain names plus one >>>prefix), which one is to be used? Suggest to add some discussions about the >>>allowed situation where more than one contexts occur. >> >>This was supposed to be an "OR", i.e., the number applies in all such >>contexts. However, come to think of it, that's probably a bad idea. I >>don't think URIs typically have multiple parameters with the same name. >>Some parsers are likely to not take this gracefully. For the OR case, the >>pickings are slim, however: >> >>- + is taken >>- comma and semicolon are not allowed (without escaping) >>- / doesn't fit well and would be confusing >>- . doesn't work for domain names >>- : is one possibility, as in >> >>tel:1234;phone-context=example.com:+12345 >> >>Other suggestions welcome. > >Actually, I can think of a number of situations in which an identifier >can be used for different objects. > >The context is a qualifier on the applicability of the URI. It's not >really more than one parameter - The single parameter 'phone-context' can >have more than one value. This can happen due to introduction of relief codes, >or the Vienna case, where there are two codes to dial Vienna (within Austria). >Thus a Viennese phone could have two values for its phone context (01 and the >old code - can't remember what this is, off hand). As an aside, the old code >is not valid outside Austria, so writing this in International form is >strange. > >[Also, for example, the tel: number might be associated with voice telephony >or fax or mms or... I understand that one can use SIP as a "Service Resolution >Service" and am still thinking on whether or not such explicit service idents >are ever needed, but these could indeed have more than one value to the >hypothetical >parameter 'service' - I suspect that these would be 'hints' rather than >mandatory] > >This, BTW, is why I originally asked the dumb question on comma separated list >values. The conclusion of that is that there will be a set of params, each >with >one value. The alternative (there is one parameter with multiple values) needs >to be syntactically valid, but may be more compact. > >Any ideas on value separators - is the above an exhaustive list? > >>> >>>I've the "global routing number" parameter that begin with the country code >>>followed by hex digits. Is it possible for you to describe "country code" >>>part of the global-number-part so that I can use it in my I-D. I hate to >>>see that the "extensions" defines something in more details. The first one >>>to three digits of the global-number-part identify the country code. >> >>Done. Can the country code contain hex digits? Is there the possibility >>that country codes need more than three digits? Does East Timor have its >>own country code? > >Hmm...should be in E.164, IMHO. Will look. > >BTW, James, the conclusion we had was that a RN is not in International format >so that a local number is OK when using HEXDIG. I can't think of a situation >where one needs a "pseudo-E.164" number with HEXDIG in the country/service >code. >Was this your intention? > >atb, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 21:15:14 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09009 for ; Tue, 21 May 2002 21:15:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4M1F9N07083; Tue, 21 May 2002 21:15:09 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4M1EJN07064 for ; Tue, 21 May 2002 21:14:19 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4M1FFUL031407 for ; Tue, 21 May 2002 21:15:15 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id AA7E94439E; Tue, 21 May 2002 21:14:13 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 819424439D for ; Tue, 21 May 2002 21:14:13 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4M1ECk78518 for ; Tue, 21 May 2002 21:14:12 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by dusty; Tue May 21 21:09:18 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4M1DruF010109; Tue, 21 May 2002 18:13:53 -0700 (PDT) Received: from cisco.com (sjc-vpn1-834.cisco.com [10.21.99.66]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA14376; Tue, 21 May 2002 18:14:01 -0700 (PDT) Message-ID: <3CEAF0D9.8234AF8E@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yu, James" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 21:14:02 -0400 Content-Transfer-Encoding: 7bit "Yu, James" wrote: > > > > > > > But what if the call never arrives at a PSTN gateway or > > SIP server that > > understand these extensions ? > > > > [JY] The node at least has the phone number for routing decision. If it > does not know how to route based on a phone number, the call then fails. > But it does, the call will continue. OK - I'll buy that for the "rn" parameter. > > > > > But again, what if the call does not arrive at such a > > node ? You seem to be > > arguing on the precise of assuming that if entity A does not > > support these > > parameters, then probably some other entity B will, and hence > > everyting will > > work OK. I don't find this convincing. > > [JY] Same as above, the call will fail if the next node does not even know > how to route based on the phone number. At least the call has a higher > chance to survive if we allow it to continue with the downstream node. The > call will never be set up if any node in the call path will drop the call > because it does not understand "rn" or "cic." > Maybe so, but as far as I can tell, it gets routed incorrectly here. Let's say I dial 1010321+0 to reach an alternate IXC operator. 2806bis explains, that I shall not put the dial-string in the tel-URI, but rather the telephone number, which in this case is "0". The CIC is "0321", so my tel-URI becomes something like "tel:0;cic=+10321". Now, if nobody understands the CIC parameter, the call ends up at the presubscribed IXC operator, and not the alternate operator. That doesn't seem right. > > > > > Take another example where I as a consumer actually dial a > > particular carrier > > selection code as part of my call, but by default, all my > > calls are handled by > > another carrier. I don't see how you will route this call > > correctly without a > > guarantee that at least one entity in the forwarding path > > understands the > > extension (not to mention the fact that routing can be rather > > inefficient if > > preceeding hops routed the call incorrectly because they > > didn't understand the > > extensions). > > If a caller (SIP UA) can put in the "cic" to specify the carrier to use and > if the outbound SIP proxy server (assume that it is operated by a service > provider) does not understand the "cic," I don't see how that service > provider can support this type of "dialing." > That is my point. If what you are trying to do is support telephone numbers, then you need to support carrier selection, and hence it cannot be optional. > > I can see that when "cic" is not popularly supported by many nodes, it is > likely that "cic" (if received in the response to the database query) may be > mapped to a host associated with that "cic" so that "cic" is not carried in > the tel or sip URL. Or the carriers can set their routing tables so that > the next node understands "cic." That sounds like fixing the sympton, not the problem IMO. If this is what you envision, then the limitations and pitfalls shold be pointed out clearly. As it stands now, the CIC parameter is useless as far as I can tell (since you can't depend on it), and we should rather simply require mapping such a selection to an appropriate domain name and then use SIP-URIs instead of tel-URIs. Am I missing something here ? -- Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 21:23:58 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09278 for ; Tue, 21 May 2002 21:23:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4M1O4N07183; Tue, 21 May 2002 21:24:04 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4M1NDN07170 for ; Tue, 21 May 2002 21:23:13 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4M1O9UL031533 for ; Tue, 21 May 2002 21:24:09 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id CC5084439E; Tue, 21 May 2002 21:23:07 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id A36764439D for ; Tue, 21 May 2002 21:23:07 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4M1N6k79121 for ; Tue, 21 May 2002 21:23:06 -0400 (EDT) Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by dusty; Tue May 21 21:18:13 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4M1MBuF013619; Tue, 21 May 2002 18:22:12 -0700 (PDT) Received: from cisco.com (sjc-vpn1-834.cisco.com [10.21.99.66]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA22272; Tue, 21 May 2002 18:22:19 -0700 (PDT) Message-ID: <3CEAF2CC.36E46E47@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Conroy Cc: iptel@lists.bell-labs.com, hgs@cs.columbia.edu, james.yu@neustar.biz Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CEA64AD.79FBCB01@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 21 May 2002 21:22:20 -0400 Content-Transfer-Encoding: 7bit Lawrence Conroy wrote: > Flemming wrote: > > > >Take another example where I as a consumer actually dial a particular carrier > >selection code as part of my call, but by default, all my calls are handled by > >another carrier. I don't see how you will route this call correctly without a > >guarantee that at least one entity in the forwarding path understands the > >extension (not to mention the fact that routing can be rather inefficient if > >preceeding hops routed the call incorrectly because they didn't understand the > >extensions). > > > >In other words, I don't see how these parameters can be optional. If you are > >concerned about lack of implementation support, then perhaps the best way to > >address that is by including the extensions in 2806bis, since they > >do seem to be > >a prerequisite for a generally useful tel-URI. > > > To which I reply: > It can be used in SIP, but it can also be used in a static form > (e.g. DNS NAPTR > content). In the latter case, it may be in the public ENUM space, or it might > be stored within a Service provider's private space. > > I do not believe that a rn or cic parameter is a prerequisite for all these > cases - Indeed, for the static (DNS) cases one may or may not need this > parameterisation at all. > Right, but I was talking about a *generally useful tel-URI*, not a SIP-URI, or some private database scheme. In that case, all you have is the tel-URI and the information it contains. If part of that information is the CIC and the call is supposed to be routed based on the CIC, but it doesn't, then something is wrong. > > I agree with James that it cannot be mandatory (i.e. "use this or fail"). > For example, looking at the SIP case, a recipient of a SIP dialog may or > may not have a trust relationship with the sender of this information. > If they do not then they are at liberty to do another dip themselves. I agree (and don't think I said anything to the contrary). > > Thus a mandatory "do or die" is not appropriate, IMHO. > > My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand > this parameter. Then again, when I outcall with this kind of URI there > WILL be some external outbound proxy and/or gateway in line, and whilst > understanding this parameter by *that* box may be required (for regulatory > reasons ?), I'd be really unhappy if my home box were to be declared > non-standard because it cannot understand nor act on a cic value but > instead passes it downstream. > I appreciate that problem and share your concern, however the current solution doesn't seem to work as far as I can tell. You need to have at least one entity in the forwarding path understand this parameter and route accordingly based on it. -- Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue May 21 22:33:44 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12506 for ; Tue, 21 May 2002 22:33:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4M2Q4N07915; Tue, 21 May 2002 22:26:06 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4M2PDN07902 for ; Tue, 21 May 2002 22:25:13 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4M2Q9UL032276 for ; Tue, 21 May 2002 22:26:09 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 9F0434439E; Tue, 21 May 2002 22:25:07 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 70AD24439D for ; Tue, 21 May 2002 22:25:07 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4M2P5o48054 for ; Tue, 21 May 2002 22:25:05 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Tue May 21 22:20:09 EDT 2002 Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090172; Wed, 22 May 2002 03:25:01 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3CEAF2CC.36E46E47@cisco.com> References: <3CEA64AD.79FBCB01@cisco.com> <3CEAF2CC.36E46E47@cisco.com> To: Flemming Andreasen From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, hgs@cs.columbia.edu, james.yu@neustar.biz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 03:24:47 +0100 At 9:22 pm -0400 21/5/02, Flemming Andreasen wrote: >Lawrence Conroy wrote: > > > I do not believe that a rn or cic parameter is a prerequisite for all these >> cases - Indeed, for the static (DNS) cases one may or may not need this > > parameterisation at all. >> >Right, but I was talking about a *generally useful tel-URI*, not a >SIP-URI, or some >private database scheme. In that case, all you have is the tel-URI and the >information it contains. If part of that information is the CIC and >the call is >supposed to be routed based on the CIC, but it doesn't, then >something is wrong. > > >> > > I agree with James that it cannot be mandatory (i.e. "use this or fail"). > > For example, looking at the SIP case, a recipient of a SIP dialog may or > > may not have a trust relationship with the sender of this information. > > If they do not then they are at liberty to do another dip themselves. > >I agree (and don't think I said anything to the contrary). To which I reply: great - I wondered when you seemed to suggest rolling it into the tel: URI. > > > My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand >> this parameter. Then again, when I outcall with this kind of URI there >> WILL be some external outbound proxy and/or gateway in line, and whilst >> understanding this parameter by *that* box may be required (for regulatory >> reasons ?), I'd be really unhappy if my home box were to be declared >> non-standard because it cannot understand nor act on a cic value but >> instead passes it downstream. >> > >I appreciate that problem and share your concern, however the current solution >doesn't seem to work as far as I can tell. You need to have at least >one entity in >the forwarding path understand this parameter and route accordingly >based on it. > To which I reply: absolutely. Are you suggesting that even if an intermediary doesn't understand the parameter, it should not expunge it? I'm fine with that. alternatively, If I'm making a call and asserting a carrier selection, AND this carrier selection has any meaning, then perforce I have to be passing my SIP call via an entity that can act on it; specifying WCOM for use when I'm calling the next desk may well not make sense. Specifying WCOM for use when I call around the world might, and if I have a public service provider using SIP then they may be forced to pass this off to WCOM (and, by definition, have an interconnect with WCOM). I suspect that this means that *their* system will have to include something that understands and acts on the carrier selection request. Thus it MAY be mandatory for one of their entities *FOR REGULATORY REASONS*, but it isn't mandatory for the call to work, and isn't mandatory on ALL entities in their system. [This is a non-IETF topic, IMHO, but I suspect that any public service provider who uses SIP intermediaries may be covered by the same regulations as TSPs are at present - even if said public service provider is Microsoft. It will be interesting to see how this influences available choices for interconnect carriers :] atb, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 12:37:33 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17182 for ; Wed, 22 May 2002 12:37:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MGaJN12493; Wed, 22 May 2002 12:36:19 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MGZAN12480 for ; Wed, 22 May 2002 12:35:10 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MGZAEF013441 for ; Wed, 22 May 2002 12:35:10 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 1CB1C4439E; Wed, 22 May 2002 12:35:05 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id EB3684439D for ; Wed, 22 May 2002 12:35:04 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MGZ1o02038 for ; Wed, 22 May 2002 12:35:03 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Wed May 22 12:30:08 EDT 2002 Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090180; Wed, 22 May 2002 17:34:52 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> References: <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> To: Michael Hammer From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 17:34:10 +0100 At 3:52 pm -0400 21/5/02, Michael Hammer wrote: >It would not be a good idea to use a local dial plan in an >international number format as suggested for Vienna. > >In response to my earlier posting >> >>The context is a qualifier on the applicability of the URI. It's not >>really more than one parameter - The single parameter 'phone-context' can >>have more than one value. This can happen due to introduction of >>relief codes, >>or the Vienna case, where there are two codes to dial Vienna >>(within Austria). >>Thus a Viennese phone could have two values for its phone context (01 and the >>old code - can't remember what this is, off hand). As an aside, the old code >>is not valid outside Austria, so writing this in International form >>is strange. To which I respond: Hi Mike, folks, (This may be where we get to counting the number of Angels on a pinhead :) Strictly, the old code is blocked at the International Gateway Exchange. Thus it can be written as a valid E.164 number; it is just blocked from International origination. Both versions are unambiguous, it's just that one is not routable from some origination points. +43-22-123456 - is this an E.164 number? +43-1-123456 - is this an E.164 number? If these are dialled from within Austria, they should terminate at the same 'phone. If you try to dial the first variant outside Austria, it's blocked. Thus I can imagine this kind of URI: but...the fully routable one would be: Thus, I'm not sure I understand the concern. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 14:12:20 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22853 for ; Wed, 22 May 2002 14:12:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MI87N13197; Wed, 22 May 2002 14:08:07 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MI7WN13184 for ; Wed, 22 May 2002 14:07:32 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MI8RUL040577 for ; Wed, 22 May 2002 14:08:27 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 5C1344439E; Wed, 22 May 2002 14:07:27 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 306EB4439D for ; Wed, 22 May 2002 14:07:27 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MI7Oo11541 for ; Wed, 22 May 2002 14:07:25 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Wed May 22 14:02:33 EDT 2002 Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090182; Wed, 22 May 2002 19:07:26 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <3CEA6062.70304@cs.columbia.edu> References: <3CEA6062.70304@cs.columbia.edu> To: Henning Schulzrinne From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, Franz.Egger@icn.siemens.de, jBuller@unispherenetworks.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 19:07:11 +0100 At 10:57 am -0400 21/5/02, Henning Schulzrinne wrote: > >I thought somebody already complained when I had accidentally >changed the label to "context". If a change is acceptable, I'd >rather go for the shorter "context". In the end, I don't think the >name much matters, as long as the description is clear. To which I reply: Hi Henning, folks, first, sorry for the delay; takes a time to contact people. Speaking as the person who complained (loudly) at the change from "phone-context", I've checked in-house. We have two implementations with this - one for PINT and one for SIP. I've checked with the respective developers and sales people, and they agreed that they can handle a name change with no problem (I thought so, but had to check :). Hence, as the URI is getting long, if people want to change from 'phone-context' to, for example, 'context' then that's fine by us. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 14:38:09 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24424 for ; Wed, 22 May 2002 14:38:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MIcGN13572; Wed, 22 May 2002 14:38:16 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MIb5N13558 for ; Wed, 22 May 2002 14:37:05 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MIc0UL041214 for ; Wed, 22 May 2002 14:38:00 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 0FD234439E; Wed, 22 May 2002 14:37:00 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id D033C4439D for ; Wed, 22 May 2002 14:36:59 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MIawo15203 for ; Wed, 22 May 2002 14:36:58 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed May 22 14:32:06 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA06813; Wed, 22 May 2002 14:36:50 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4MIan2i017656 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 May 2002 14:36:50 -0400 (EDT) Message-ID: <3CEBE52A.8030706@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Cc: Lawrence Conroy , Franz.Egger@icn.siemens.de, jBuller@unispherenetworks.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <3CEA6062.70304@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 14:36:26 -0400 Content-Transfer-Encoding: 7bit Last call to rest of group: Please let me know immediately if the parameter name change to 'context' causes you grief. > We have two implementations with this - one for PINT and one > for SIP. I've checked with the respective developers and sales > people, and they agreed that they can handle a name change with > no problem (I thought so, but had to check :). > > Hence, as the URI is getting long, if people want to change > from 'phone-context' to, for example, 'context' then that's > fine by us. > > all the best, > Lawrence _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 14:42:05 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24582 for ; Wed, 22 May 2002 14:42:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MIg6N13645; Wed, 22 May 2002 14:42:06 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MIf5N13625 for ; Wed, 22 May 2002 14:41:05 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MIg0UL041276 for ; Wed, 22 May 2002 14:42:00 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id F33C64439E; Wed, 22 May 2002 14:41:00 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id C55A14439D for ; Wed, 22 May 2002 14:40:59 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MIewk51814 for ; Wed, 22 May 2002 14:40:58 -0400 (EDT) Received: from imo-r09.mx.aol.com ([152.163.225.105]) by dusty; Wed May 22 14:36:05 EDT 2002 Received: from Mpierce1@aol.com by imo-r09.mx.aol.com (mail_out_v32.5.) id 3.191.767c924 (3944); Wed, 22 May 2002 14:40:39 -0400 (EDT) From: Mpierce1@aol.com Message-ID: <191.767c924.2a1d4026@aol.com> Subject: Re: [IPTEL] Comments on RFC2806bis To: lwc@roke.co.uk, mhammer@cisco.com Cc: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_191.767c924.2a1d4026_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 14:40:38 EDT --part1_191.767c924.2a1d4026_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 1:06:10 PM Eastern Daylight Time, lwc@roke.co.uk writes: > Strictly, the old code is blocked at the International Gateway Exchange. > Thus it can be written as a valid E.164 number; it is just blocked from > International origination. Both versions are unambiguous, it's just that > one is not routable from some origination points. > > +43-22-123456 - is this an E.164 number? > +43-1-123456 - is this an E.164 number? > If these are dialled from within Austria, they should terminate at the same > 'phone. If you try to dial the first variant outside Austria, it's blocked. > I haven't been to Vienna lately, but am confused by this example. If the same phone can be reached by two different numbers, is this because they are in the middle of a change in dialing plan? If the two numbers are represented as shown above, then that explicitly means that both can be dialed from anywhere. Why would the "22" variant be blocked? Mike --part1_191.767c924.2a1d4026_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/22/02 1:06:10 PM Eastern Daylight Time, lwc@roke.co.uk writes:


Strictly, the old code is blocked at the International Gateway Exchange.
Thus it can be written as a valid E.164 number; it is just blocked from
International origination. Both versions are unambiguous, it's just that
one is not routable from some origination points.

+43-22-123456 - is this an E.164 number?
+43-1-123456 - is this an E.164 number?
If these are dialled from within Austria, they should terminate at the same
'phone. If you try to dial the first variant outside Austria, it's blocked.


I haven't been to Vienna lately, but am confused by this example. If the same phone can be reached by two different numbers, is this because they are in the middle of a change in dialing plan? If the two numbers are represented as shown above, then that explicitly means that both can be dialed from anywhere. Why would the "22" variant be blocked?

Mike
--part1_191.767c924.2a1d4026_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 15:28:06 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26874 for ; Wed, 22 May 2002 15:28:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MJS7N14371; Wed, 22 May 2002 15:28:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MJRdN14358 for ; Wed, 22 May 2002 15:27:39 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MJSYUL042204 for ; Wed, 22 May 2002 15:28:34 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id F26F54439E; Wed, 22 May 2002 15:27:34 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id CA0374439D for ; Wed, 22 May 2002 15:27:33 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MJRWk56678 for ; Wed, 22 May 2002 15:27:32 -0400 (EDT) Received: from broadsoft.com ([198.104.184.110]) by dusty; Wed May 22 15:22:35 EDT 2002 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id g4MJREF78269; Wed, 22 May 2002 15:27:15 -0400 (EDT) Reply-To: From: "Brett Tate" To: , Subject: RE: [IPTEL] Comments on RFC2806bis Message-ID: <000901c201c6$cd703330$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3CEBE52A.8030706@cs.columbia.edu> Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 15:28:06 -0400 Content-Transfer-Encoding: 7bit > Last call to rest of group: Please let me > know immediately if the parameter name > change to 'context' causes you grief. The name change would cause grief for BroadSoft because we have products deployed within networks which send, receive, and use phone-context. An attempt to rename or introduce a short-form of the parameter would complicate interoperability. Also rfc2806 allowed a much greater non-escaped character-set for the phone-context value. Reducing this character-set within rfc2806bis will potentially also cause some grief. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 15:59:14 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28335 for ; Wed, 22 May 2002 15:59:14 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MJv7N14797; Wed, 22 May 2002 15:57:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MJuXN14784 for ; Wed, 22 May 2002 15:56:33 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MJvSUL042746 for ; Wed, 22 May 2002 15:57:28 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 875F04439E; Wed, 22 May 2002 15:56:28 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 5B74C4439D for ; Wed, 22 May 2002 15:56:28 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MJuRk59918 for ; Wed, 22 May 2002 15:56:27 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed May 22 15:51:35 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA12923; Wed, 22 May 2002 15:56:20 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4MJuJ2i021923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 22 May 2002 15:56:20 -0400 (EDT) Message-ID: <3CEBF7CC.5090900@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: brett@broadsoft.com Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <000901c201c6$cd703330$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 15:55:56 -0400 Content-Transfer-Encoding: 7bit > The name change would cause grief for > BroadSoft because we have products deployed > within networks which send, receive, and > use phone-context. An attempt to rename > or introduce a short-form of the parameter > would complicate interoperability. Sounds like a definitive answer. It stays "phone-context". > > Also rfc2806 allowed a much greater > non-escaped character-set for the > phone-context value. Reducing this > character-set within rfc2806bis will > potentially also cause some grief. The previous definition was not interoperable, so I'm not inclined to change this. This is not a character-set issue but defining in a meaningful way what phone-context means and minimizing the damage caused by local phone URIs that escape their intended scope. I believe there was group consensus on that, but as usual in the IETF, this is subject to re-discussion at any point :-) _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 16:56:31 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00064 for ; Wed, 22 May 2002 16:56:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MKu9N15351; Wed, 22 May 2002 16:56:09 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MKt5N15338 for ; Wed, 22 May 2002 16:55:05 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MKu0UL043543 for ; Wed, 22 May 2002 16:56:00 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 628E64439E; Wed, 22 May 2002 16:55:00 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 376274439D for ; Wed, 22 May 2002 16:55:00 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MKswk65243 for ; Wed, 22 May 2002 16:54:59 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Wed May 22 16:50:07 EDT 2002 Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090183; Wed, 22 May 2002 21:55:01 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <3CEBF7CC.5090900@cs.columbia.edu> References: <000901c201c6$cd703330$2b01a8c0@broadsoft.com> <3CEBF7CC.5090900@cs.columbia.edu> To: Henning Schulzrinne , brett@broadsoft.com From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 21:54:42 +0100 At 3:55 pm -0400 22/5/02, Henning Schulzrinne wrote: >>The name change would cause grief for BroadSoft because we have >>products deployed within networks which send, receive, and >>use phone-context. An attempt to rename or introduce a short-form >>of the parameter would complicate interoperability. > >Sounds like a definitive answer. It stays "phone-context". This saves each of my guys at least 30 seconds quality time, so fair enough. I am, however, surprised if Brett means that a comma-separated list form will cause grief. Anyone dealing with tel: URIs will almost certainly have to deal with other parameters (mandatory or otherwise :). > it is. >> >>Also rfc2806 allowed a much greater non-escaped character-set for >>the phone-context value. Reducing this character-set within >>rfc2806bis will >>potentially also cause some grief. > >The previous definition was not interoperable, so I'm not inclined >to change this. This is not a character-set issue but defining in a >meaningful way what phone-context means and minimizing the damage >caused by local phone URIs that escape their intended scope. I >believe there was group consensus on that, but as usual in the IETF, >this is subject to re-discussion at any point :-) > I also will be VERY unhappy if the old Reverse Hungarian is retained. I understand 2806bis phone-context to a pure sub-set of the 2806 list of hex ranges. It's also clear in intent, exactly as Henning says. Testing therefore should not be a problem - your installed base is capable of handling this "narrowed" set adequately. Brett - are your machine generating private context values, or the local-prefix Morse code allowed in 2806? I'm Puzzled. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 18:40:05 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05727 for ; Wed, 22 May 2002 18:40:04 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MMeGN16250; Wed, 22 May 2002 18:40:16 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MMdRN16228 for ; Wed, 22 May 2002 18:39:27 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MMdREF017455 for ; Wed, 22 May 2002 18:39:27 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 4B1A94439E; Wed, 22 May 2002 18:39:22 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 217C14439D for ; Wed, 22 May 2002 18:39:22 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MMdKo39875 for ; Wed, 22 May 2002 18:39:20 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by dusty; Wed May 22 18:34:29 EDT 2002 Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4MMdOnQ013789; Wed, 22 May 2002 18:39:27 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAW49660; Wed, 22 May 2002 18:33:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lawrence Conroy From: Michael Hammer Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com In-Reply-To: References: <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 22 May 2002 18:38:49 -0400 At 05:34 PM 5/22/2002 +0100, Lawrence Conroy wrote: >At 3:52 pm -0400 21/5/02, Michael Hammer wrote: >>It would not be a good idea to use a local dial plan in an international >>number format as suggested for Vienna. >> >>In response to my earlier posting >>> >>>The context is a qualifier on the applicability of the URI. It's not >>>really more than one parameter - The single parameter 'phone-context' can >>>have more than one value. This can happen due to introduction of relief >>>codes, >>>or the Vienna case, where there are two codes to dial Vienna (within >>>Austria). >>>Thus a Viennese phone could have two values for its phone context (01 >>>and the >>>old code - can't remember what this is, off hand). As an aside, the old code >>>is not valid outside Austria, so writing this in International form is >>>strange. > >To which I respond: >Hi Mike, folks, > >(This may be where we get to counting the number of Angels on a pinhead :) > >Strictly, the old code is blocked at the International Gateway Exchange. >Thus it can be written as a valid E.164 number; it is just blocked from >International origination. Both versions are unambiguous, it's just that >one is not routable from some origination points. > >+43-22-123456 - is this an E.164 number? >+43-1-123456 - is this an E.164 number? >If these are dialled from within Austria, they should terminate at the same >'phone. If you try to dial the first variant outside Austria, it's blocked. I don't understand how you can call the number international if it is blocked when dialed outside Austria. Isn't that an oxymoron of some type? Mike >Thus I can imagine this kind of URI: > > > >but...the fully routable one would be: > > > >Thus, I'm not sure I understand the concern. > >all the best, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 22 19:07:52 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06848 for ; Wed, 22 May 2002 19:07:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MN87N16574; Wed, 22 May 2002 19:08:07 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MN7JN16561 for ; Wed, 22 May 2002 19:07:19 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MN8DUL045056 for ; Wed, 22 May 2002 19:08:13 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 386084439E; Wed, 22 May 2002 19:07:14 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 14E444439D for ; Wed, 22 May 2002 19:07:14 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4MN7Ck76094 for ; Wed, 22 May 2002 19:07:12 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Wed May 22 19:02:21 EDT 2002 Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090185; Thu, 23 May 2002 00:07:15 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> References: <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> To: Michael Hammer From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, Richard Stastny Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 00:07:03 +0100 At 6:38 pm -0400 22/5/02, Michael Hammer wrote: >At 05:34 PM 5/22/2002 +0100, Lawrence Conroy wrote: >>At 3:52 pm -0400 21/5/02, Michael Hammer wrote: >>>It would not be a good idea to use a local dial plan in an >>>international number format as suggested for Vienna. >>> >>>In response to my earlier posting >>>> >>>>The context is a qualifier on the applicability of the URI. It's not >>>>really more than one parameter - The single parameter 'phone-context' can >>>>have more than one value. This can happen due to introduction of >>>>relief codes, >>>>or the Vienna case, where there are two codes to dial Vienna >>>>(within Austria). >>>>Thus a Viennese phone could have two values for its phone context >>>>(01 and the >>>>old code - can't remember what this is, off hand). As an aside, >>>>the old code >>>>is not valid outside Austria, so writing this in International >>>>form is strange. >> >>To which I respond: >>Hi Mike, folks, >> >>(This may be where we get to counting the number of Angels on a pinhead :) >> >>Strictly, the old code is blocked at the International Gateway Exchange. >>Thus it can be written as a valid E.164 number; it is just blocked from >>International origination. Both versions are unambiguous, it's just that >>one is not routable from some origination points. >> >>+43-22-123456 - is this an E.164 number? >>+43-1-123456 - is this an E.164 number? >>If these are dialled from within Austria, they should terminate at the same >>'phone. If you try to dial the first variant outside Austria, it's blocked. > >I don't understand how you can call the number international if it >is blocked when dialed outside Austria. Isn't that an oxymoron of >some type? Nope. There are numbers that can be called between several networks and within a Group of Countries but are not universally available. Try phoning North Korea. An E.164 number is globally unique, not necessarily globally routable. => It's a strange one if 'tis an Oxymoron. >>Thus, I'm not sure I understand the concern. I still don't. atb, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 10:04:09 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10925 for ; Thu, 23 May 2002 10:04:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NE48N21464; Thu, 23 May 2002 10:04:08 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NE3fN21451 for ; Thu, 23 May 2002 10:03:41 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NE4YUL050859 for ; Thu, 23 May 2002 10:04:34 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 2968A4439E; Thu, 23 May 2002 10:03:36 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 0193A4439D for ; Thu, 23 May 2002 10:03:35 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NE3Yo89697 for ; Thu, 23 May 2002 10:03:34 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by dusty; Thu May 23 09:58:29 EDT 2002 Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NE3929018038; Thu, 23 May 2002 10:03:20 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAW53274; Thu, 23 May 2002 09:57:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20020523100023.00b1e308@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lawrence Conroy From: Michael Hammer Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, Richard Stastny In-Reply-To: References: <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 10:02:35 -0400 So what happens if someone dials this "international" number from a location outside of Austria and it gets routed through SIP to a GW within Austria, is that considered originated inside Austria and therefore allowed, or is it considered dialed outside Austria and therefore blocked? Mike At 12:07 AM 5/23/2002 +0100, Lawrence Conroy wrote: >At 6:38 pm -0400 22/5/02, Michael Hammer wrote: >>At 05:34 PM 5/22/2002 +0100, Lawrence Conroy wrote: >>>At 3:52 pm -0400 21/5/02, Michael Hammer wrote: >>>>It would not be a good idea to use a local dial plan in an >>>>international number format as suggested for Vienna. >>>> >>>>In response to my earlier posting >>>>> >>>>>The context is a qualifier on the applicability of the URI. It's not >>>>>really more than one parameter - The single parameter 'phone-context' can >>>>>have more than one value. This can happen due to introduction of >>>>>relief codes, >>>>>or the Vienna case, where there are two codes to dial Vienna (within >>>>>Austria). >>>>>Thus a Viennese phone could have two values for its phone context (01 >>>>>and the >>>>>old code - can't remember what this is, off hand). As an aside, the >>>>>old code >>>>>is not valid outside Austria, so writing this in International form is >>>>>strange. >>> >>>To which I respond: >>>Hi Mike, folks, >>> >>>(This may be where we get to counting the number of Angels on a pinhead :) >>> >>>Strictly, the old code is blocked at the International Gateway Exchange. >>>Thus it can be written as a valid E.164 number; it is just blocked from >>>International origination. Both versions are unambiguous, it's just that >>>one is not routable from some origination points. >>> >>>+43-22-123456 - is this an E.164 number? >>>+43-1-123456 - is this an E.164 number? >>>If these are dialled from within Austria, they should terminate at the same >>>'phone. If you try to dial the first variant outside Austria, it's blocked. >> >>I don't understand how you can call the number international if it is >>blocked when dialed outside Austria. Isn't that an oxymoron of some type? > >Nope. >There are numbers that can be called between several networks and within a >Group of Countries but are not universally available. Try phoning North Korea. >An E.164 number is globally unique, not necessarily globally routable. >=> It's a strange one if 'tis an Oxymoron. > >>>Thus, I'm not sure I understand the concern. >I still don't. > >atb, > Lawrence > > >-- >lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 10:11:56 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11286 for ; Thu, 23 May 2002 10:11:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NEC2N21574; Thu, 23 May 2002 10:12:02 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NE5IN21478 for ; Thu, 23 May 2002 10:05:18 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NE6BUL050894 for ; Thu, 23 May 2002 10:06:11 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 85B744439E; Thu, 23 May 2002 10:05:13 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 5E6974439D for ; Thu, 23 May 2002 10:05:13 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NE5Ck25854 for ; Thu, 23 May 2002 10:05:12 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by dusty; Thu May 23 10:00:16 EDT 2002 Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NE5JnI018288; Thu, 23 May 2002 10:05:19 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAW53304; Thu, 23 May 2002 09:59:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20020523100326.00b17d80@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lawrence Conroy From: Michael Hammer Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, Richard Stastny In-Reply-To: References: <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 10:04:49 -0400 p.s. If it is not dial-able outside of Austria, what is the point in pre-fixing it with 43? Wouldn't it be more accurate to leave that off and mark it as a national call? Mike At 12:07 AM 5/23/2002 +0100, Lawrence Conroy wrote: >At 6:38 pm -0400 22/5/02, Michael Hammer wrote: >>At 05:34 PM 5/22/2002 +0100, Lawrence Conroy wrote: >>>At 3:52 pm -0400 21/5/02, Michael Hammer wrote: >>>>It would not be a good idea to use a local dial plan in an >>>>international number format as suggested for Vienna. >>>> >>>>In response to my earlier posting >>>>> >>>>>The context is a qualifier on the applicability of the URI. It's not >>>>>really more than one parameter - The single parameter 'phone-context' can >>>>>have more than one value. This can happen due to introduction of >>>>>relief codes, >>>>>or the Vienna case, where there are two codes to dial Vienna (within >>>>>Austria). >>>>>Thus a Viennese phone could have two values for its phone context (01 >>>>>and the >>>>>old code - can't remember what this is, off hand). As an aside, the >>>>>old code >>>>>is not valid outside Austria, so writing this in International form is >>>>>strange. >>> >>>To which I respond: >>>Hi Mike, folks, >>> >>>(This may be where we get to counting the number of Angels on a pinhead :) >>> >>>Strictly, the old code is blocked at the International Gateway Exchange. >>>Thus it can be written as a valid E.164 number; it is just blocked from >>>International origination. Both versions are unambiguous, it's just that >>>one is not routable from some origination points. >>> >>>+43-22-123456 - is this an E.164 number? >>>+43-1-123456 - is this an E.164 number? >>>If these are dialled from within Austria, they should terminate at the same >>>'phone. If you try to dial the first variant outside Austria, it's blocked. >> >>I don't understand how you can call the number international if it is >>blocked when dialed outside Austria. Isn't that an oxymoron of some type? > >Nope. >There are numbers that can be called between several networks and within a >Group of Countries but are not universally available. Try phoning North Korea. >An E.164 number is globally unique, not necessarily globally routable. >=> It's a strange one if 'tis an Oxymoron. > >>>Thus, I'm not sure I understand the concern. >I still don't. > >atb, > Lawrence > > >-- >lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 10:43:53 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12751 for ; Thu, 23 May 2002 10:43:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NEi3N22020; Thu, 23 May 2002 10:44:03 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NEhpN22007 for ; Thu, 23 May 2002 10:43:51 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NEiiUL051650 for ; Thu, 23 May 2002 10:44:44 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 118DB4439E; Thu, 23 May 2002 10:43:46 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id DD6334439D for ; Thu, 23 May 2002 10:43:45 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NEhio94760 for ; Thu, 23 May 2002 10:43:44 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Thu May 23 10:37:48 EDT 2002 Received: from [193.118.192.111] (HELO [193.118.205.13]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090188; Thu, 23 May 2002 15:42:19 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20020523100023.00b1e308@cia.cisco.com> References: <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <3CE9BB4E.1060707@cs.columbia.edu> <3CE9BB4E.1060707@cs.columbia.edu> <4.3.2.7.2.20020521154815.00b30e80@cia.cisco.com> <4.3.2.7.2.20020522183521.00b7b480@cia.cisco.com> <4.3.2.7.2.20020523100023.00b1e308@cia.cisco.com> To: Michael Hammer From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, Richard Stastny Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 15:42:02 +0100 At 10:02 am -0400 23/5/02, Michael Hammer wrote: >So what happens if someone dials this "international" number from a >location outside of Austria and it gets routed through SIP to a GW >within Austria, is that considered originated inside Austria and >therefore allowed, or is it considered dialed outside Austria and >therefore blocked? > >Mike > To which I reply: Good morning Mike, folks, The essential question is whether or not there is a route to the destination from your origination point. The destination address may be unique (as in an E.164 number), without a route through to it from your place. Answering your question as asked - it's allowed, IMHO. However, whether the call is delivered depends on whether or not the Destination network Gateway Exchange through which your "far end" SIP MGW connects allows routing to the number it has received or not. It probably does. This is a specific case; we should really generalise. However, for your entertainment... Austria (as does Germany) uses a flexible numbering plan. The current ITU recommendation on maximum NSN length means that, if someone tries to dial (using the old code) a Vienna number that is connected via a PBX from another Country (or an interconnect that uses a DN within the ISUP message that is in International Format), the number could exceed the maximum size allowed for a DN (15 digits, I seem to remember). Remember that Austria has a 2 digit country code, the old code for Vienna was 222 (another 3 digits), so that leaves a maximum of 10 digits for the complete local number, including any extension. To avoid this truncation risk, the choice was to change the area code for Vienna to 1. However, everyone in Austria is used to dialling 0222 to get Vienna, thus the two codes run in parallel. The only problem is that, if the International Gateway exchange gets a number with area code 222, that number may have been truncated. To avoid trying to place the call using an incomplete number, it's blocked. The 15 digit limit is not a problem within Austria (as International Register length is not an issue), so it passes. Thus, your question should be - can the destination number I've dialled be delivered to the far end gateway without truncation, and if so, is that far end MGW connected so that it can avoid using (International) ISUP messages when placing the call onwards to the destination end point. This may also address your subsequent question - the reason to have this as an E.164 number is that it won't change in the future as maximum register size increases; the only thing that will change is whether or not a call origination has gone via an ISUP interconnect that might have truncated it. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 12:56:38 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17937 for ; Thu, 23 May 2002 12:56:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NGuJN23153; Thu, 23 May 2002 12:56:19 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NGtPN23140 for ; Thu, 23 May 2002 12:55:25 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NGuHUL053340 for ; Thu, 23 May 2002 12:56:17 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id EED724439E; Thu, 23 May 2002 12:55:20 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id BDCB34439D for ; Thu, 23 May 2002 12:55:19 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NGtHo08879 for ; Thu, 23 May 2002 12:55:17 -0400 (EDT) Received: from imo-d01.mx.aol.com ([205.188.157.33]) by dusty; Thu May 23 12:50:25 EDT 2002 Received: from Mpierce1@aol.com by imo-d01.mx.aol.com (mail_out_v32.5.) id c.174.8b2f8c9 (3942); Thu, 23 May 2002 12:54:33 -0400 (EDT) From: Mpierce1@aol.com Message-ID: <174.8b2f8c9.2a1e78c9@aol.com> Subject: Re: [IPTEL] Comments on RFC2806bis To: mhammer@cisco.com, lwc@roke.co.uk Cc: iptel@lists.bell-labs.com, richard.stastny@oefeg.at MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_174.8b2f8c9.2a1e78c9_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 12:54:33 EDT --part1_174.8b2f8c9.2a1e78c9_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/23/02 10:32:30 AM Eastern Daylight Time, mhammer@cisco.com writes: > So what happens if someone dials this "international" number from a > location outside of Austria and it gets routed through SIP to a GW within > Austria, is that considered originated inside Austria and therefore > allowed, or is it considered dialed outside Austria and therefore blocked? > > Mike > > > At 12:07 AM 5/23/2002 +0100, Lawrence Conroy wrote: > >At 6:38 pm -0400 22/5/02, Michael Hammer wrote: > >>At 05:34 PM 5/22/2002 +0100, Lawrence Conroy wrote: > >>>At 3:52 pm -0400 21/5/02, Michael Hammer wrote: > >>>>>> > Austria). > >>>>>Thus a Viennese phone could have two values for its phone context (01 > and the > >>>>>old code - can't remember what this is, off hand). As an aside, the > old code > >>>>>is not valid outside Austria, so writing this in International form is > strange. > >>> > >>>To which I respond: > >>>Hi Mike, folks, > >>> > >>>(This may be where we get to counting the number of Angels on a pinhead > :) > >>> > >>>Strictly, the old code is blocked at the International Gateway Exchange. > >>>Thus it can be written as a valid E.164 number; it is just blocked from > >>>International origination. Both versions are unambiguous, it's just that > >>>one is not routable from some origination points. > >>> > >>>+43-22-123456 - is this an E.164 number? > >>>+43-1-123456 - is this an E.164 number? > >>>If these are dialled from within Austria, they should terminate at the > same > >>>'phone. If you try to dial the first variant outside Austria, it's > blocked. > >> > >>I don't understand how you can call the number international if it is > >>blocked when dialed outside Austria. Isn't that an oxymoron of some type? > > > Etc, etc, etc. I hope I can put this issue to bed once and for all. There seems to be this strange story going around about how 43-22 should be blocked from outside Austria while 43-1 is allowed and both forms designate the same phone if dialed inside Austria. This is false! Please check the web site www.sauerhof.at which is one of the hotels in the famous resort town near Vienna of Baden bei Wien. It clearly shows that their telephone number is +43 2252 412510. I have found others of this form. The "22" following the country code for Austria is not invalid or to be blocked by anyone. It is the first part of a perfectly good 4-digit city code. If there is some other local dialing plan in Vienna or Austria that uses "22" for some other purpose, it can not appear in a conflicting position in the dialing string and can not be confused with being a part of the international or national number. On the other hand, if such a code is used in the local dialing plan for some special purpose, SIP must figure out a way to handle it. But don't treat it as a part of the subscribers number. Mike Pierce --part1_174.8b2f8c9.2a1e78c9_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/23/02 10:32:30 AM Eastern Daylight Time, mhammer@cisco.com writes:


So what happens if someone dials this "international" number from a
location outside of Austria and it gets routed through SIP to a GW within
Austria, is that considered originated inside Austria and therefore
allowed, or is it considered dialed outside Austria and therefore blocked?

Mike


At 12:07 AM 5/23/2002 +0100, Lawrence Conroy wrote:
>At 6:38 pm -0400 22/5/02, Michael Hammer wrote:
>>At 05:34 PM 5/22/2002 +0100, Lawrence Conroy wrote:
>>>At 3:52 pm -0400 21/5/02, Michael Hammer wrote:

<snip>

>>>>>or the Vienna case, where there are two codes to dial Vienna (within
Austria).
>>>>>Thus a Viennese phone could have two values for its phone context (01 and the
>>>>>old code - can't remember what this is, off hand). As an aside, the old code
>>>>>is not valid outside Austria, so writing this in International form is strange.
>>>
>>>To which I respond:
>>>Hi Mike, folks,
>>>
>>>(This may be where we get to counting the number of Angels on a pinhead :)
>>>
>>>Strictly, the old code is blocked at the International Gateway Exchange.
>>>Thus it can be written as a valid E.164 number; it is just blocked from
>>>International origination. Both versions are unambiguous, it's just that
>>>one is not routable from some origination points.
>>>
>>>+43-22-123456 - is this an E.164 number?
>>>+43-1-123456 - is this an E.164 number?
>>>If these are dialled from within Austria, they should terminate at the same
>>>'phone. If you try to dial the first variant outside Austria, it's blocked.
>>
>>I don't understand how you can call the number international if it is
>>blocked when dialed outside Austria.  Isn't that an oxymoron of some type?
>


Etc, etc, etc.

I hope I can put this issue to bed once and for all. There seems to be this strange story going around about how 43-22 should be blocked from outside Austria while 43-1 is allowed and both forms designate the same phone if dialed inside Austria. This is false!

Please check the web site www.sauerhof.at which is one of the hotels in the famous resort town near Vienna of Baden bei Wien. It clearly shows that their telephone number is +43 2252 412510. I have found others of this form.

The "22" following the country code for Austria is not invalid or to be blocked by anyone. It is the first part of a perfectly good 4-digit city code.

If there is some other local dialing plan in Vienna or Austria that uses "22" for some other purpose, it can not appear in a conflicting position in the dialing string and can not be confused with being a part of the international or national number.

On the other hand, if such a code is used in the local dialing plan for some special purpose, SIP must figure out a way to handle it. But don't treat it as a part of the subscribers number.

Mike Pierce

--part1_174.8b2f8c9.2a1e78c9_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 13:04:52 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18285 for ; Thu, 23 May 2002 13:04:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NH54N23267; Thu, 23 May 2002 13:05:04 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NH4qN23245 for ; Thu, 23 May 2002 13:04:52 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NH5jUL053481 for ; Thu, 23 May 2002 13:05:45 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 6CF364439E; Thu, 23 May 2002 13:04:47 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 43B474439D for ; Thu, 23 May 2002 13:04:47 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NH4jo09714 for ; Thu, 23 May 2002 13:04:46 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Thu May 23 12:59:50 EDT 2002 Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090195; Thu, 23 May 2002 18:04:42 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <174.8b2f8c9.2a1e78c9@aol.com> References: <174.8b2f8c9.2a1e78c9@aol.com> To: Mpierce1@aol.com From: Lawrence Conroy Subject: Re: [IPTEL] Comments on RFC2806bis Cc: iptel@lists.bell-labs.com, richard.stastny@oefeg.at Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 18:04:31 +0100 At 12:54 pm -0400 23/5/02, Mpierce1@aol.com wrote: > >I hope I can put this issue to bed once and for all. There seems to >be this strange story going around about how 43-22 should be blocked >from outside Austria while 43-1 is allowed and both forms designate >the same phone if dialed inside Austria. This is false! > >Please check the web site www.sauerhof.at which is one of the hotels >in the famous resort town near Vienna of Baden bei Wien. It clearly >shows that their telephone number is +43 2252 412510. I have found >others of this form. > >The "22" following the country code for Austria is not invalid or to >be blocked by anyone. It is the first part of a perfectly good >4-digit city code. > >If there is some other local dialing plan in Vienna or Austria that >uses "22" for some other purpose, it can not appear in a conflicting >position in the dialing string and can not be confused with being a >part of the international or national number. > >On the other hand, if such a code is used in the local dialing plan >for some special purpose, SIP must figure out a way to handle it. >But don't treat it as a part of the subscribers number. To which I reply:: OK, I admit it - I mistyped the code - the old code is 222, not 22. Sorry about that. For the rest, see Richard earlier Stastny's post (it's much shorter than mine). atb, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 13:59:10 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20479 for ; Thu, 23 May 2002 13:59:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NHv8N24026; Thu, 23 May 2002 13:57:09 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NHuKN24013 for ; Thu, 23 May 2002 13:56:20 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NHvCUL054552 for ; Thu, 23 May 2002 13:57:12 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id B83794439E; Thu, 23 May 2002 13:56:14 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 8D7F14439D for ; Thu, 23 May 2002 13:56:14 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NHuDk52693 for ; Thu, 23 May 2002 13:56:13 -0400 (EDT) Received: from broadsoft.com ([198.104.184.110]) by dusty; Thu May 23 13:51:20 EDT 2002 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id g4NHu8C14973; Thu, 23 May 2002 13:56:08 -0400 (EDT) Reply-To: From: "Brett Tate" To: Cc: Subject: RE: [IPTEL] Comments on RFC2806bis Message-ID: <000f01c20283$4046fa80$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 13:57:04 -0400 Content-Transfer-Encoding: 7bit > >Sounds like a definitive answer. > >It stays "phone-context". > > This saves each of my guys at least > 30 seconds quality time, so fair enough. > > I am, however, surprised if Brett > means that a comma-separated list form > will cause grief. Commas are no problem, and coding is no problem. It would be a deployment and interoperability inconvenience resulting from some devices supporting rfc2806, others only supporting rfc2806bis. > Anyone dealing with > tel: URIs will almost certainly have > to deal with other parameters > (mandatory or otherwise :). Agreed. Just as an FYI, rfc2806 section 2.5.11 mentions to reject the request if any parameters were unknown. For example if cic was present and you do not know what cic means, the message MUST be rejected. > Brett - are your machine generating > private context values, or the > local-prefix Morse code allowed in 2806? > I'm Puzzled. The rfc2806bis definition of phone-context replaced the private-prefix with domainname. Both have effectively the same meaning within telephone-subscriber; however domainname reduces the character-set of what can be considered a valid value within phone-context. rfc2806bis also imposes a domainname format upon rfc2806's private-prefix. The rfc2806bis example of phone-context=cs.columbia.edu isn't valid in rfc2806 because it started with a 'c'. I agree that the new phone-context definition is better since it forces structure for potential use with DNS, and it provides an explicit solution to avoid accidental duplicate private-prefix names. We can reformat our rfc2806 usage of private prefixes to accommodate the rfc2806bis format. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 14:25:35 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21797 for ; Thu, 23 May 2002 14:25:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NIJBN24285; Thu, 23 May 2002 14:19:11 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NIIFN24259 for ; Thu, 23 May 2002 14:18:15 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NIJ7UL054880 for ; Thu, 23 May 2002 14:19:07 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 174FC4439E; Thu, 23 May 2002 14:18:10 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id A76E64439D for ; Thu, 23 May 2002 14:18:09 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NII7k55170 for ; Thu, 23 May 2002 14:18:08 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu May 23 14:12:56 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA23734; Thu, 23 May 2002 14:17:33 -0400 (EDT) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4NIHW2i008506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 May 2002 14:17:33 -0400 (EDT) Message-ID: <3CED3226.8070305@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: brett@broadsoft.com Cc: lwc@roke.co.uk, iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: <000f01c20283$4046fa80$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 14:17:10 -0400 Content-Transfer-Encoding: 7bit > Commas are no problem, and coding is > no problem. It would be a deployment > and interoperability inconvenience resulting > from some devices supporting rfc2806, > others only supporting rfc2806bis. You haven't identified what these "inconveniences" would be. I think there's general agreement that allowing random character string in context is a potentially large interoperability problem, so we have to pick our poison. > Agreed. Just as an FYI, rfc2806 section > 2.5.11 mentions to reject the request > if any parameters were unknown. For > example if cic was present and you do > not know what cic means, the message > MUST be rejected. We want to arrive at a more nuanced version, I think. Thus, the distinction between the two parameter types. > > The rfc2806bis definition of phone-context > replaced the private-prefix with domainname. > Both have effectively the same meaning within > telephone-subscriber; however domainname > reduces the character-set of what can be > considered a valid value within phone-context. As noted, any other random strings are likely to collide and thus create interoperability issues. > > rfc2806bis also imposes a domainname > format upon rfc2806's private-prefix. > > The rfc2806bis example of > phone-context=cs.columbia.edu > isn't valid in rfc2806 > because it started with a 'c'. > > I agree that the new phone-context > definition is better since it forces > structure for potential use with DNS, and it > provides an explicit solution to avoid > accidental duplicate private-prefix names. > > We can reformat our rfc2806 usage of > private prefixes to accommodate the > rfc2806bis format. Glad to hear that. There having been no other notes on this topic, can we declare it closed? _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 15:00:21 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23128 for ; Thu, 23 May 2002 15:00:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NJ0BN24916; Thu, 23 May 2002 15:00:11 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NIxgN24894 for ; Thu, 23 May 2002 14:59:42 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NJ0ZUL055837 for ; Thu, 23 May 2002 15:00:35 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id A2E3D4439E; Thu, 23 May 2002 14:59:37 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 782224439D for ; Thu, 23 May 2002 14:59:37 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NIxZo28668 for ; Thu, 23 May 2002 14:59:36 -0400 (EDT) Received: from broadsoft.com ([198.104.184.110]) by dusty; Thu May 23 14:54:39 EDT 2002 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id g4NIxQl22298; Thu, 23 May 2002 14:59:26 -0400 (EDT) Reply-To: From: "Brett Tate" To: , Subject: RE: [IPTEL] Comments on RFC2806bis Message-ID: <001201c2028c$179edf40$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3CED3226.8070305@cs.columbia.edu> Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 15:00:22 -0400 Content-Transfer-Encoding: 7bit > > Commas are no problem, and coding is > > no problem. It would be a deployment > > and interoperability inconvenience resulting > > from some devices supporting rfc2806, > > others only supporting rfc2806bis. > > You haven't identified what these > "inconveniences" would be. I think > there's general agreement that allowing > random character string in > context is a potentially large > interoperability problem, so we have to > pick our poison. My above comment was in response to the slam about the 30 second development effort to rename "phone-context" to be "context". It was not regarding the valid contents of phone-context. > > I agree that the new phone-context > > definition is better since it forces > > structure for potential use with DNS, and it > > provides an explicit solution to avoid > > accidental duplicate private-prefix names. > > > > We can reformat our rfc2806 usage of > > private prefixes to accommodate the > > rfc2806bis format. > > Glad to hear that. There having been > no other notes on this topic, can > we declare it closed? Yes, assuming your prior email is still correct that "phone-context" shall not be renamed to be "context". _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 15:43:51 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24186 for ; Thu, 23 May 2002 15:43:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NJi3N25513; Thu, 23 May 2002 15:44:03 -0400 Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NJhaN25500 for ; Thu, 23 May 2002 15:43:36 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NJhZEF026964 for ; Thu, 23 May 2002 15:43:35 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 8ED8D4439E; Thu, 23 May 2002 15:43:30 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 62EF04439D for ; Thu, 23 May 2002 15:43:30 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NJhSo33392 for ; Thu, 23 May 2002 15:43:28 -0400 (EDT) Received: from imo-d09.mx.aol.com ([205.188.157.41]) by dusty; Thu May 23 15:38:36 EDT 2002 Received: from Mpierce1@aol.com by imo-d09.mx.aol.com (mail_out_v32.5.) id 3.c5.23429fb6 (4264); Thu, 23 May 2002 15:43:15 -0400 (EDT) From: Mpierce1@aol.com Message-ID: Subject: Re: [IPTEL] Comments on RFC2806bis To: lwc@roke.co.uk Cc: iptel@lists.bell-labs.com, richard.stastny@oefeg.at MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_c5.23429fb6.2a1ea052_boundary" X-Mailer: AOL 6.0 for Windows US sub 10524 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 15:43:14 EDT --part1_c5.23429fb6.2a1ea052_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/23/02 1:04:55 PM Eastern Daylight Time, lwc@roke.co.uk writes: > > OK, I admit it - I mistyped the code - the old code is 222, not 22. > Sorry about that. > Yes, the 222 helps to clarify the issue - one of changing a numbering plan which we do a lot. So there is a period of time in which either number may be dialed and the call gets through. I still don't see the point of saying that it is allowed inside the country and blocked from outside. The period for allowing both to be routed should be the same for all originating points. On the other hand, concerning the issue of too many numbers (more than 15 now). I suspect that the reason that Vienna changed from 222 to 1 was to avoid the previous limit of 12, not the new 15 digit limit. I'm sure that no number would be assigned in Vienna which exceeds that limit (7 using the 222 city code) until after the allowable dual dialing period. After that, the 222 should no longer be used to route even within Austria due to the probable limit on the length of the digit string. Mike --part1_c5.23429fb6.2a1ea052_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 5/23/02 1:04:55 PM Eastern Daylight Time, lwc@roke.co.uk writes:



OK, I admit it - I mistyped the code - the old code is 222, not 22.
Sorry about that.


Yes, the 222 helps to clarify the issue - one of changing a numbering plan which we do a lot. So there is a period of time in which either number may be dialed and the call gets through. I still don't see the point of saying that it is allowed inside the country and blocked from outside. The period for allowing both to be routed should be the same for all originating points.

On the other hand, concerning the issue of too many numbers (more than 15 now). I suspect that the reason that Vienna changed from 222 to 1 was to avoid the previous limit of 12, not the new 15 digit limit. I'm sure that no number would be assigned in Vienna which exceeds that limit (7 using the 222 city code) until after the allowable dual dialing period. After that, the 222 should no longer be used to route even within Austria due to the probable limit on the length of the digit string.

Mike
--part1_c5.23429fb6.2a1ea052_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu May 23 18:13:29 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29138 for ; Thu, 23 May 2002 18:13:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NMD6N26672; Thu, 23 May 2002 18:13:06 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NMCAN26651 for ; Thu, 23 May 2002 18:12:10 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NMD2UL058211 for ; Thu, 23 May 2002 18:13:02 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 75FFE4439E; Thu, 23 May 2002 18:12:05 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 4ACA74439D for ; Thu, 23 May 2002 18:12:05 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4NMC3o47949 for ; Thu, 23 May 2002 18:12:03 -0400 (EDT) Received: from zsc3s004.us.nortel.com ([47.81.138.65]) by dusty; Thu May 23 18:07:12 EDT 2002 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NMCDu15369 for ; Thu, 23 May 2002 15:12:13 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 15:11:49 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D202AF8B65@zsc3c030.us.nortel.com> From: "Mo Zonoun" To: "'iptel@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C202A6.E7AC05F4" Subject: [IPTEL] (no subject) Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Thu, 23 May 2002 15:12:19 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C202A6.E7AC05F4 Content-Type: text/plain Unsubscribe izikor mzonoun@nortelnetworks.com ------_=_NextPart_001_01C202A6.E7AC05F4 Content-Type: text/html

Unsubscribe izikor mzonoun@nortelnetworks.com

------_=_NextPart_001_01C202A6.E7AC05F4-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri May 24 11:16:43 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01807 for ; Fri, 24 May 2002 11:16:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4OFB6N32171; Fri, 24 May 2002 11:11:06 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4OFAeN32158 for ; Fri, 24 May 2002 11:10:40 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4OFBVUL064761 for ; Fri, 24 May 2002 11:11:31 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 4A5DE4439E; Fri, 24 May 2002 11:10:35 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 0E7A64439D for ; Fri, 24 May 2002 11:10:35 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4OFAXk33981 for ; Fri, 24 May 2002 11:10:33 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by dusty; Fri May 24 11:05:40 EDT 2002 Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4OFAQIZ002981; Fri, 24 May 2002 08:10:26 -0700 (PDT) Received: from cisco.com (rtp-vpn1-420.cisco.com [10.82.225.164]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA22157; Fri, 24 May 2002 08:10:14 -0700 (PDT) Message-ID: <3CEE57D6.50C7CC2@cisco.com> From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Yu, James" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Comments on RFC2806bis References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 24 May 2002 11:10:14 -0400 Content-Transfer-Encoding: 7bit "Yu, James" wrote: > -- Flemming Andreasen wrote -- > > > > Maybe so, but as far as I can tell, it gets routed > > incorrectly here. Let's say I > > dial 1010321+0 to reach an alternate IXC operator. 2806bis > > explains, that I > > shall not put the dial-string in the tel-URI, but rather the > > telephone number, > > which in this case is "0". The CIC is "0321", so my tel-URI > > becomes something > > like "tel:0;cic=+10321". Now, if nobody understands the CIC > > parameter, the call > > ends up at the presubscribed IXC operator, and not the > > alternate operator. That > > doesn't seem right. > > [JY] We are addressing VoIP issues. If the caller is using a specific > service provider for outbound calls, then he had better make sure that his > "presubscribed" service provider supports the "cic;" otherwise, the way you > describe will not work (but the call will still be completed, serviced by > his service provider). If that service provider does not support the "cic" > and the caller really wants the "carrier selection," then he just need to > send that particular SIP INVITE message to the host associated with the > selected carrier/service provider (if his SIP UA can be easily configured to > do this once in a while task). > I think this needs to be pointed out clearly in the draft, as it is not what I would have expected. > > > > > > > That sounds like fixing the sympton, not the problem IMO. If > > this is what you > > envision, then the limitations and pitfalls shold be pointed > > out clearly. As it > > stands now, the CIC parameter is useless as far as I can tell > > (since you can't > > depend on it), and we should rather simply require mapping > > such a selection to > > an appropriate domain name and then use SIP-URIs instead of > > tel-URIs. Am I > > missing something here ? > > [JY] The "cic" is designed for supporting freephone service (e.g., used > within the networks by the carriers/service providers). Carrier selection > is a side product. A carrier/service provider can support the "cic" for > carrier selection and use it as a selling point. I view "carrier selection" > as a feature, which may or may not offered by a carrier/service provider. > If an end user cannot get this feature from a carrier/service provider, he > can always turn to another for such a service. That was not my understanding of current (US) legislation for telephony, but I'm not an expert on this. If you insist on keeping these semantics, then the document needs to point this out as well as the consequences more clearly. Thanks Flemming _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri May 24 11:36:54 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02728 for ; Fri, 24 May 2002 11:36:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4OFb5N32481; Fri, 24 May 2002 11:37:05 -0400 Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4OFaTN32468 for ; Fri, 24 May 2002 11:36:29 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4OFbJUL065259 for ; Fri, 24 May 2002 11:37:19 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 6CEFE4439E; Fri, 24 May 2002 11:36:23 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3BD144439D for ; Fri, 24 May 2002 11:36:23 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4OFaLk36704 for ; Fri, 24 May 2002 11:36:22 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com ([161.44.11.97]) by dusty; Fri May 24 11:31:30 EDT 2002 Received: from cia.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4OFaevn013884; Fri, 24 May 2002 11:36:46 -0400 (EDT) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AAW63206; Fri, 24 May 2002 11:31:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20020524112323.03eecee0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Yu, James" From: Michael Hammer Subject: Re: [IPTEL] Comments on RFC2806bis Cc: Flemming Andreasen , iptel@lists.bell-labs.com In-Reply-To: <3CEE57D6.50C7CC2@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 24 May 2002 11:36:08 -0400 James, Could you clarify, if a service provider does not support these parameters (cic= and rn=) how this information is mapped into SIP? Does this mean that there is more than one way to support this? Are you suggesting that sip: uris are preferred over tel: uris for ISUP to SIP translation? I would assume that in certain regulatory environments that the ability to dial and be routed to a "1010-XXX" type number would be mandatory. Mike At 11:10 AM 5/24/2002 -0400, Flemming Andreasen wrote: >"Yu, James" wrote: > > > -- Flemming Andreasen wrote -- > > > > > > Maybe so, but as far as I can tell, it gets routed > > > incorrectly here. Let's say I > > > dial 1010321+0 to reach an alternate IXC operator. 2806bis > > > explains, that I > > > shall not put the dial-string in the tel-URI, but rather the > > > telephone number, > > > which in this case is "0". The CIC is "0321", so my tel-URI > > > becomes something > > > like "tel:0;cic=+10321". Now, if nobody understands the CIC > > > parameter, the call > > > ends up at the presubscribed IXC operator, and not the > > > alternate operator. That > > > doesn't seem right. > > > > [JY] We are addressing VoIP issues. If the caller is using a specific > > service provider for outbound calls, then he had better make sure that his > > "presubscribed" service provider supports the "cic;" otherwise, the way you > > describe will not work (but the call will still be completed, serviced by > > his service provider). If that service provider does not support the "cic" > > and the caller really wants the "carrier selection," then he just need to > > send that particular SIP INVITE message to the host associated with the > > selected carrier/service provider (if his SIP UA can be easily > configured to > > do this once in a while task). > > > >I think this needs to be pointed out clearly in the draft, as it is not what I >would have expected. > > > > > > > > > > > > > > That sounds like fixing the sympton, not the problem IMO. If > > > this is what you > > > envision, then the limitations and pitfalls shold be pointed > > > out clearly. As it > > > stands now, the CIC parameter is useless as far as I can tell > > > (since you can't > > > depend on it), and we should rather simply require mapping > > > such a selection to > > > an appropriate domain name and then use SIP-URIs instead of > > > tel-URIs. Am I > > > missing something here ? > > > > [JY] The "cic" is designed for supporting freephone service (e.g., used > > within the networks by the carriers/service providers). Carrier selection > > is a side product. A carrier/service provider can support the "cic" for > > carrier selection and use it as a selling point. I view "carrier > selection" > > as a feature, which may or may not offered by a carrier/service provider. > > If an end user cannot get this feature from a carrier/service provider, he > > can always turn to another for such a service. > >That was not my understanding of current (US) legislation for telephony, >but I'm >not an expert on this. If you insist on keeping these semantics, then the >document needs to point this out as well as the consequences more clearly. > >Thanks > > Flemming > > > > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun May 26 19:58:29 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29584 for ; Sun, 26 May 2002 19:58:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4QNwEN22639; Sun, 26 May 2002 19:58:14 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4QNvIN22626 for ; Sun, 26 May 2002 19:57:18 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4QNw3UL084980 for ; Sun, 26 May 2002 19:58:03 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 74BD94439E; Sun, 26 May 2002 19:57:13 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 4C6EC4439D for ; Sun, 26 May 2002 19:57:13 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4QNvBk59049 for ; Sun, 26 May 2002 19:57:12 -0400 (EDT) Received: from cundall.co.uk ([193.118.205.3]) by dusty; Sun May 26 19:52:18 EDT 2002 Received: from [193.118.205.14] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090214 for ; Mon, 27 May 2002 00:57:20 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 (Unverified) Message-Id: To: iptel@lists.bell-labs.com From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [IPTEL] small comments on 2806bis-04 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 27 May 2002 00:57:06 +0100 Hi Henning, folks, Two comments for 2806bis-04. Typos: line 187: Clarification - should 'URI schemes' be 'URI scheme'? similarly... line 322: these URI schemes/this URI scheme/ ? line 308: c/be /been/ Possibly add a sentence in the IANA considerations section to state: 'Any parameter that should be considered as mandatory should be prefixed by "m-" as described in section 5.3'. Apart from that, I for one think it's fine. I can read it, can understand how to test it, and the URI syntax is much cleaner. (Now we can complicate it with 'tel:' URI parameter drafts :). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun May 26 20:20:51 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29747 for ; Sun, 26 May 2002 20:20:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4R0LAN22856; Sun, 26 May 2002 20:21:10 -0400 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4R0KjN22843 for ; Sun, 26 May 2002 20:20:45 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4R0KjEF052293 for ; Sun, 26 May 2002 20:20:45 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 559CB4439E; Sun, 26 May 2002 20:20:40 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2A1D14439D for ; Sun, 26 May 2002 20:20:40 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4R0Kck60026 for ; Sun, 26 May 2002 20:20:39 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Sun May 26 20:15:35 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA16393; Sun, 26 May 2002 20:20:17 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-41-243.mad.east.verizon.net [138.89.41.243]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4R0KF2i008394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 26 May 2002 20:20:16 -0400 (EDT) Message-ID: <3CF17C31.4040401@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lawrence Conroy Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] small comments on 2806bis-04 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 26 May 2002 20:22:09 -0400 Content-Transfer-Encoding: 7bit Thanks for catching these straggler plurals. I think I nuked them all. While I was in the IANA section, I also added a note that mandatory ``tel'' parameters must be documented in an informational or standards-track RFC. I don't think this is strictly necessary, but it greatly helps interoperability, I believe. This ensures some review, as a proliferation of mandatory parameters would not be helpful. Are we ready for an informal WGLC? (As noted, this will also need to be reviewed in SIPPING and SIP, but I wanted to make sure that this WG is reasonably happy first.) Lawrence Conroy wrote: > Hi Henning, folks, > > Two comments for 2806bis-04. > Typos: > line 187: Clarification - should 'URI schemes' be 'URI scheme'? > similarly... > line 322: these URI schemes/this URI scheme/ ? > line 308: c/be /been/ > > Possibly add a sentence in the IANA considerations section to state: > 'Any parameter that should be considered as mandatory should be prefixed > by "m-" as described in section 5.3'. > > Apart from that, I for one think it's fine. > I can read it, can understand how to test it, and the URI syntax is much > cleaner. > > (Now we can complicate it with 'tel:' URI parameter drafts :). > > all the best, > Lawrence _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 29 05:52:01 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09201 for ; Wed, 29 May 2002 05:51:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4T9jAN09907; Wed, 29 May 2002 05:45:10 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4T9iCN09888 for ; Wed, 29 May 2002 05:44:12 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4T9ipUL010832 for ; Wed, 29 May 2002 05:44:51 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id AD9E34439E; Wed, 29 May 2002 05:44:06 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.bell-labs.com (Postfix) with ESMTP id 7A1C34439D for ; Wed, 29 May 2002 05:44:06 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4T9i5k43261 for ; Wed, 29 May 2002 05:44:05 -0400 (EDT) Received: from mail1.telekom.de ([62.225.183.235]) by dusty; Wed May 29 05:39:08 EDT 2002 Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for iptel@lists.bell-labs.com; Wed, 29 May 2002 11:31:21 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 11:31:24 +0200 Message-Id: From: "Alexeitsev, D" To: iptel@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] Question on RFC2806bis Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 29 May 2002 11:31:23 +0200 Hello All Is the tel URI draft is thought to be only the definition of the syntax, or it will define the procedures and use of it, by SIP or whatever, as well? i.e. how to convert the user dialled string into the E.164 number and where to put it into the tel URI. Greetings, Denis Alexeitsev _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed May 29 08:52:51 2002 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14641 for ; Wed, 29 May 2002 08:52:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4TCr6N11312; Wed, 29 May 2002 08:53:06 -0400 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4TCqCN11299 for ; Wed, 29 May 2002 08:52:12 -0400 Received: from lists.bell-labs.com (H-135-104-27-211.research.bell-labs.com [135.104.27.211]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4TCqpUL012381 for ; Wed, 29 May 2002 08:52:51 -0400 (EDT) Received: by lists.bell-labs.com (Postfix) id 5465E4439E; Wed, 29 May 2002 08:52:07 -0400 (EDT) Delivered-To: iptel@sunny.research.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.bell-labs.com (Postfix) with ESMTP id 2604A4439D for ; Wed, 29 May 2002 08:52:07 -0400 (EDT) Received: from dusty.research.bell-labs.com (dusty.research.bell-labs.com [135.104.2.7]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with SMTP id g4TCq5o57427 for ; Wed, 29 May 2002 08:52:05 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed May 29 08:47:07 EDT 2002 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4TCpxMk027076; Wed, 29 May 2002 08:51:59 -0400 (EDT) Received: from cs.columbia.edu (pool-138-89-40-59.mad.east.verizon.net [138.89.40.59]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4TCpv2i000498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 29 May 2002 08:51:58 -0400 (EDT) Message-ID: <3CF4CF42.2000005@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexeitsev, D" Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Question on RFC2806bis References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 29 May 2002 08:53:22 -0400 Content-Transfer-Encoding: 7bit Alexeitsev, D wrote: > Hello All > > Is the tel URI draft is thought to be only the definition of the > syntax, or it will define the procedures and use of it, by SIP or > whatever, as well? i.e. how to convert the user dialled string into > the E.164 number and where to put it into the tel URI. No, this isn't planned. There's a large variety of ways this happens in practice. Generally, IETF protocol descriptions limit themselves to "bits on the wire" (and their processing), rather than implementation issues. > > Greetings, > > Denis Alexeitsev > > _______________________________________________ IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel